# Building Agentic AI on AWS: From Bedrock Agents to Multi-Agent Orchestration with AgentCore > Source: > Published: 2026-08-04 07:00:45+00:00 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. 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 ──────────────┘ │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────┐ │ 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) │ └─────────────────────────────────────────────────────────────────┘ ``` 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). | 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 | **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" } } ``` For complex problems, a single agent isn't enough. Multi-agent collaboration lets specialized agents work together: ``` ┌──────────────────┐ │ Supervisor Agent │ User ────────→│ (Routes tasks) │ └────────┬─────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────────┐ ┌───────────┐ ┌──────────────┐ │ Research Agent│ │ Code Agent│ │ Review Agent │ │ (RAG + Web) │ │ (CodeGen) │ │ (Validation) │ └──────────────┘ └───────────┘ └──────────────┘ ``` | 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. AgentCore is the runtime infrastructure for deploying agents at scale. It provides the "boring but critical" capabilities agents need in production: | 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 | 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): 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. For teams wanting more control, AWS released **Strands Agents SDK** — an open-source Python framework for building agents that runs on AgentCore: `@tool` decorator, auto-generating schemas ``` python 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") ``` | 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 | Without knowledge, agents hallucinate. Knowledge Bases provide RAG (Retrieval-Augmented Generation): The latest option — fully managed RAG without provisioning anything: 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 | Guardrails attach to: **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. Best for: Customer support, multi-domain queries. One supervisor routes to specialist workers. Workers don't talk to each other. Best for: Document processing, content creation. Agent A → Agent B → Agent C. Each stage enriches output. Best for: Research, data gathering from multiple sources. Multiple agents work simultaneously, results aggregated. Best for: High-stakes decisions, code review. Generator agent produces output, critic agent evaluates quality, iterate until criteria met. Before deploying agents to production: The agentic AI space on AWS is evolving rapidly: Building agentic AI on AWS in 2026: 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.*