2026 is the year AI moved from "answer questions" to "take actions." Agentic AI — systems that autonomously plan, reason, use tools, and execute multi-step tasks — has become the dominant pattern for building intelligent applications on AWS.
This post covers the full agentic AI stack on AWS: from single-agent basics to multi-agent orchestration, the infrastructure that runs them, and the guardrails that keep them safe in production.
What Makes AI "Agentic"?
Traditional AI: User asks question → Model generates answer → Done.
Agentic AI: User states goal → Agent plans steps → Agent calls tools → Agent evaluates results → Agent iterates → Goal achieved.
The difference is autonomy. An agent decides what to do, executes actions, and self-corrects — without human intervention at each step.
┌─────────────────────────────────────────────────────────────┐
│ AGENTIC AI LOOP │
│ │
│ User Goal → Plan → Act → Observe → Reason → Act → Done │
│ ↑ │ │
│ └───────── iterate ──────────────┘ │
└─────────────────────────────────────────────────────────────┘
The AWS Agentic AI Stack
┌─────────────────────────────────────────────────────────────────┐
│ APPLICATION LAYER │
│ Amazon Q (Business & Developer) | Custom agents via Bedrock │
├─────────────────────────────────────────────────────────────────┤
│ AGENT FRAMEWORKS │
│ Bedrock Agents | Strands Agents SDK | LangGraph on AgentCore │
├─────────────────────────────────────────────────────────────────┤
│ AGENT INFRASTRUCTURE (AgentCore) │
│ Runtime | Memory | Identity | Observability | Code Interpreter │
├─────────────────────────────────────────────────────────────────┤
│ TOOLS & KNOWLEDGE │
│ AgentCore Gateway (MCP) | Knowledge Bases (RAG) | Action Groups│
├─────────────────────────────────────────────────────────────────┤
│ SAFETY & GOVERNANCE │
│ Guardrails | IAM | CloudTrail | Model Evaluation │
├─────────────────────────────────────────────────────────────────┤
│ FOUNDATION MODELS │
│ Claude | Nova | Llama | Mistral | DeepSeek (via Bedrock) │
└─────────────────────────────────────────────────────────────────┘
Amazon Bedrock Agents: The Managed Path
Bedrock Agents is the fully managed way to build AI agents. You define the agent's instructions, connect tools and knowledge, and Bedrock handles the orchestration loop (ReAct-style reasoning).
Core Concepts
| Concept | What It Does |
|---|---|
| Instructions | System prompt that defines agent's role, behavior, and boundaries |
| Action Groups | Tools the agent can call (Lambda functions, APIs, or return-of-control) |
| Knowledge Bases | RAG — grounds agent responses in your data (documents, databases) |
| Guardrails | Safety controls (content filters, PII masking, denied topics) |
| Memory | Session persistence — agent remembers context across turns |
| Code Interpreter | Agent can write and execute code to solve problems |
How the Orchestration Loop Works
- User sends a message to the agent
- Agent's foundation model reasons about what to do (using instructions + context)
- Agent decides to call a tool (action group) or query knowledge (RAG)
- Tool executes and returns results
- Agent evaluates the results — decides if goal is met or needs more steps
- Repeat until goal is achieved or max iterations reached
- Agent returns final response to user
Building an Agent: Key Design Decisions
Choosing the model: Claude Sonnet or Nova Pro for complex reasoning. Haiku or Nova Micro for simple routing agents.
Instruction design: Be specific about the agent's role, what it should NOT do, and how to handle ambiguity. Vague instructions lead to unpredictable behavior.
Tool design: Each tool should do ONE thing well. Name them clearly (the model uses the name and description to decide when to call them). Include input/output schemas.
# Example: Defining an action group tool
{
"actionGroupName": "OrderManagement",
"description": "Manages customer orders - lookup, modify, cancel",
"apiSchema": {
"payload": "openapi-schema.json"
},
"actionGroupExecutor": {
"lambda": "arn:aws:lambda:us-east-1:123456789:function:order-api"
}
}
Multi-Agent Collaboration: Supervisor Pattern
For complex problems, a single agent isn't enough. Multi-agent collaboration lets specialized agents work together:
Architecture: Supervisor + Collaborators
┌──────────────────┐
│ Supervisor Agent │
User ────────→│ (Routes tasks) │
└────────┬─────────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌───────────┐ ┌──────────────┐
│ Research Agent│ │ Code Agent│ │ Review Agent │
│ (RAG + Web) │ │ (CodeGen) │ │ (Validation) │
└──────────────┘ └───────────┘ └──────────────┘
How It Works on Bedrock
- Supervisor agent — Receives user request, analyzes complexity, and routes to specialist agents
- Collaborator agents — Each has specific tools and knowledge. Execute their specialty and return results to supervisor.
- Supervisor synthesizes — Combines collaborator outputs into final response
When to Use Multi-Agent
| Scenario | Single Agent | Multi-Agent |
|---|---|---|
| FAQ chatbot | ✅ | Overkill |
| Code generation only | ✅ | Unnecessary |
| Research + summarize + format | ⚠️ Gets messy | ✅ Clean separation |
| Customer support (billing + tech + shipping) | ⚠️ Tool overload | ✅ Specialist routing |
| Complex analysis with validation | ⚠️ Context window limits | ✅ Divide and conquer |
Rule of thumb: If one agent would need >10 tools or >3 distinct responsibilities, split into multiple agents.
Amazon Bedrock AgentCore: Production Infrastructure
AgentCore is the runtime infrastructure for deploying agents at scale. It provides the "boring but critical" capabilities agents need in production:
AgentCore Components
| Component | Purpose |
|---|---|
| Runtime | Serverless execution environment for agents (auto-scaling, isolation) |
| Memory | Managed long-term memory across sessions (agent remembers past interactions) |
| Identity | Authentication for agent-to-service and agent-to-agent communication |
| Observability | Traces, metrics, and logs for debugging agent behavior |
| Code Interpreter | Sandboxed code execution (Python/JS) for data analysis tasks |
| Gateway | Converts APIs and Lambda functions into MCP-compatible tools |
AgentCore Gateway: The Tool Layer
The Gateway is particularly powerful — it transforms your existing APIs into tools that any agent can discover and use via the Model Context Protocol (MCP):
- Point Gateway at your OpenAPI spec or Lambda function
- Gateway auto-generates MCP-compatible tool definitions
- Agents discover tools at runtime (no hard-coding)
- Security: IAM-based access control per tool
This means agents don't need tools baked into their code. They discover capabilities dynamically — add a new API to Gateway, and all connected agents can immediately use it.
Strands Agents SDK: The Open-Source Path
For teams wanting more control, AWS released Strands Agents SDK — an open-source Python framework for building agents that runs on AgentCore:
Why Strands?
- Model-agnostic — works with any Bedrock model (or external models)
-
Tool-first — tools are defined with
@tooldecorator, auto-generating schemas - Memory built-in — integrates with AgentCore Memory for persistence
- MCP native — discovers tools from MCP servers at runtime
- Observable — built-in tracing compatible with AgentCore Observability
Basic Agent Structure
from strands import Agent, tool
from strands.models.bedrock import BedrockModel
@tool
def get_weather(city: str) -> str:
"""Get current weather for a city."""
# Call weather API
return f"Weather in {city}: 22°C, sunny"
@tool
def create_ticket(title: str, priority: str) -> str:
"""Create a support ticket in the ticketing system."""
# Call ticketing API
return f"Created ticket: {title} (priority: {priority})"
agent = Agent(
model=BedrockModel(model_id="anthropic.claude-sonnet-4-20250514"),
tools=[get_weather, create_ticket],
system_prompt="You are a helpful assistant that can check weather and create tickets."
)
response = agent("Check the weather in London and create a ticket if it's raining")
Strands vs Bedrock Agents: When to Use Which
| Criteria | Bedrock Agents (Managed) | Strands SDK (Code-first) |
|---|---|---|
| Setup complexity | Low (console/API) | Medium (write code) |
| Customization | Moderate | Full control |
| Orchestration logic | AWS-managed ReAct loop | Custom (you define the loop) |
| Multi-agent | Built-in supervisor pattern | Build your own topology |
| Deployment | Fully managed | AgentCore Runtime or self-hosted |
| Best for | Standard use cases, rapid prototyping | Complex custom logic, advanced patterns |
Knowledge Bases: Grounding Agents in Facts
Without knowledge, agents hallucinate. Knowledge Bases provide RAG (Retrieval-Augmented Generation):
How It Works
- Ingest — Upload documents (PDF, HTML, Markdown, Word, CSV) to S3
- Chunk & Embed — Knowledge Base splits documents into chunks, generates embeddings
- Store — Embeddings stored in vector database (OpenSearch Serverless, Aurora, Pinecone, or Managed KB)
- Retrieve — When agent needs information, relevant chunks are retrieved and injected into prompt
- Generate — Model generates response grounded in retrieved facts
Managed Knowledge Base (GA June 2026)
The latest option — fully managed RAG without provisioning anything:
- No vector database to manage
- Auto-scaling retrieval
- Multimodal ingestion (text, images, tables)
- Built-in re-ranking for relevance
- Agentic retrieval (multi-hop reasoning across documents)
Guardrails: Keeping Agents Safe
Agents that take actions need safety boundaries. Bedrock Guardrails provides:
| Policy Type | What It Does |
|---|---|
| Content filters | Block harmful content (hate, violence, sexual, misconduct) with configurable thresholds |
| Denied topics | Prevent agent from discussing specific topics (competitor info, legal advice, etc.) |
| Word filters | Block specific words or phrases |
| Sensitive information | Detect and mask PII (names, emails, credit cards, SSNs) |
| Grounding check | Detect hallucinations by comparing response against source documents |
| Contextual grounding | Verify response relevance to the user's query |
Applying Guardrails
Guardrails attach to:
- The agent itself (all interactions filtered)
- Specific Knowledge Base queries
- Individual nodes in a Bedrock Flow
Key insight: Apply guardrails on BOTH input (what users send) AND output (what agents respond). Users can craft prompts to bypass instructions — guardrails are the defense layer.
Orchestration Patterns
Pattern 1: Supervisor-Worker (Hierarchical)
Best for: Customer support, multi-domain queries.
One supervisor routes to specialist workers. Workers don't talk to each other.
Pattern 2: Pipeline (Sequential)
Best for: Document processing, content creation.
Agent A → Agent B → Agent C. Each stage enriches output.
Pattern 3: Parallel Fan-Out
Best for: Research, data gathering from multiple sources.
Multiple agents work simultaneously, results aggregated.
Pattern 4: Debate/Validation
Best for: High-stakes decisions, code review.
Generator agent produces output, critic agent evaluates quality, iterate until criteria met.
Production Checklist for Agentic AI
Before deploying agents to production:
- [ ] Guardrails configured — content filters, denied topics, PII masking
- [ ] IAM scoped — agent's execution role has minimum required permissions
- [ ] Tool permissions bounded — each tool can only access specific resources
- [ ] Observability enabled — traces for every agent invocation (debug failed reasoning)
- [ ] Cost controls — max iterations per invocation, token budgets
- [ ] Fallback behavior defined — what happens when agent can't solve the problem?
- [ ] Human-in-the-loop — for high-impact actions (delete, purchase, deploy), require approval
- [ ] Testing — evaluate against known good/bad inputs before production
- [ ] Rate limiting — prevent runaway agents from flooding APIs
- [ ] Audit trail — CloudTrail logging of all agent actions and tool invocations
What's Coming Next
The agentic AI space on AWS is evolving rapidly:
- Bedrock Flows — visual builder for chaining agents, prompts, and conditions without code
- Agent-to-agent communication — agents that discover and delegate to other agents autonomously
- Long-running agents — agents that persist across hours/days (not just request-response)
- AgentCore Memory improvements — structured memory with entity relationships, not just conversation history
- MCP ecosystem growth — more pre-built tool servers for common services (databases, APIs, SaaS platforms)
Summary
Building agentic AI on AWS in 2026:
- Start with Bedrock Agents for managed orchestration — fast to prototype, production-ready
- Use Strands SDK when you need custom orchestration logic or advanced patterns
- Deploy on AgentCore for production infrastructure (memory, identity, observability)
- Connect tools via AgentCore Gateway — MCP-based discovery, zero hard-coding
- Ground with Knowledge Bases — RAG prevents hallucination
- Protect with Guardrails — content filters, PII masking, grounding checks on every interaction
- Scale with multi-agent patterns — supervisor-worker for complex domains, pipeline for sequential processing
The shift from "chatbot that answers" to "agent that acts" is the defining pattern of cloud AI in 2026. The infrastructure is ready — the question is what you build on it.
Alpesh Kumbhare is an AWS Architect at Atos, specializing in AWS infrastructure automation and cloud AI solutions. Connect on LinkedIn.
Top comments (0)