Build an AI Support Agent on Amazon Bedrock AgentCore (2026 Guide)

Amazon Bedrock AgentCore is modular infrastructure for running AI agents in production — you bring your own agent code in any Python framework and wire in only the pieces you need: Runtime to host it, Memory for recall across sessions, Gateway to expose tools, and a Knowledge Base for grounding answers in your own documents.

If you've tried to ship an agent past the demo stage, you already know the hard part isn't the model. It's everything around it. This post covers what each AgentCore component does, how they compose into a support agent, and what the build actually looks like at the command line.

What AgentCore is — and how it differs from Bedrock Agents

The naming is genuinely confusing, and it's the single most common point of confusion for people arriving at this.

Bedrock Agents (the original) is a fully managed, configuration-driven service. You define action groups and prompts in the console, and AWS runs the orchestration loop. It's fast to start and rigid: your use case either fits the box or it doesn't.

Bedrock AgentCore is the opposite trade. It's a set of independent primitives you assemble yourself. You own the agent loop — in Strands, LangGraph, CrewAI or plain Python — and AgentCore provides the production infrastructure underneath it.

Choose AgentCore when you need control over the agent loop. Choose Bedrock Agents when you don't and want to be done this afternoon.

The four building blocks

Runtime — hosts your agent code in a managed, session-isolated sandbox with long execution windows. No servers, no scaling configuration. This is what makes AgentCore an alternative to running the agent yourself on Fargate or EKS.

Memory — short-term within a session, long-term across them. The long-term side extracts durable facts and summaries from conversations, so the agent knows who it's talking to on their second visit. You choose extraction strategies when you create it (SEMANTIC, SUMMARIZATION) rather than writing that pipeline.

Gateway — turns Lambda functions, MCP servers and existing APIs into tools the agent can call, exposed through a single MCP endpoint with an authorizer in front. The agent gets one consistent way to discover and invoke tools instead of bespoke integration per tool.

Knowledge Base — retrieval over your documents. Connected as a Gateway target, so from the agent's perspective, searching your docs is just another tool call.

The architecture

A support agent that's actually useful looks like this:

Customer → API Gateway → Lambda → AgentCore Runtime (your Strands agent)
                                     ├── Memory        (recall across sessions)
                                     └── Gateway (MCP) → search_docs → Knowledge Base
                                                       → create_ticket     (Lambda)
                                                       → escalate_to_human (Lambda)

Three behaviours fall out of that shape:

1. It answers from your docs rather than from the model's training data, so it's right about your product.
2. It remembers the customer, so returning users don't re-explain their setup.
3. It knows when to stop — genuinely novel problems become a ticket or a human escalation instead of a confident guess.

That third one matters more than it sounds. An agent that escalates well is trusted; an agent that hallucinates a fix for an edge case gets switched off.

What the build looks like

The CLI generates the project and wires each component as you add it:

# Scaffold the project
agentcore create --name customersupportagent

# Add the agent — Strands, auto-wired to the runtime
agentcore add agent

# Long-term recall across sessions
agentcore add memory --name customerMemory --strategies SEMANTIC,SUMMARIZATION

# The MCP endpoint that fronts every tool
agentcore add gateway --name support-gw --authorizer-type AWS_IAM

# Ground answers in your own documents
agentcore add gateway-target --type connector --connector bedrock-knowledge-bases

Each add writes configuration into the project rather than provisioning immediately. Deployment is a single step that builds your code and applies the CDK stack:

agentcore deploy --dry-run   # inspect what will change
agentcore deploy -y

Then exercise it:

agentcore status --runtime
agentcore invoke --runtime "My deployment is failing with an access denied error"

Observability is built in, which matters a lot when debugging why an agent chose a particular tool:

agentcore traces list
agentcore traces get <trace-id>

What to watch out for

Things that cost people time on a first build:

• Model access isn't automatic. Foundation models must be enabled in the Bedrock console for your region before anything works, and the failure looks like a permissions error rather than a setup step.
• Region availability varies. Not every AgentCore component is in every region. Pick a region where all of them exist and stay there — mixing regions produces confusing failures.
• Knowledge Base ingestion is asynchronous. Documents are not searchable the instant you upload them. If early queries return nothing, check ingestion finished before you start debugging retrieval.
• The agent's tool descriptions are its instructions. Vague descriptions produce an agent that calls the wrong tool. Treat them as prompt engineering, because that's what they are.
• Scope the IAM roles. The agent decides its own tool calls, so anything the execution role can reach is reachable by a model's decision. Narrow it.

Where this pattern goes beyond support

The same composition — retrieval over your documents, memory across sessions, tools for actions — is the general shape of most useful internal agents. An onboarding assistant, an internal ops bot and a documentation answer engine are the same architecture with different tools attached.

Which is the real argument for learning it once properly: you're not learning a support-bot recipe, you're learning the assembly.

Build it end to end

Reading about agents only gets you so far — the components make sense once you've seen them fail and fixed them.

The Bedrock AgentCore workshop builds this exact architecture step by step, validated against a live AWS account: project scaffold, Strands agent, Memory, Gateway with Lambda tools, a Knowledge Base over S3, and observability — plus a clean teardown so it costs you nothing to keep. More on this topic under Bedrock AgentCore and AI Agents.