Amazon Bedrock AgentCore Architecture Diagram: The Complete Guide (2026)

An Amazon Bedrock AgentCore architecture diagram shows how a production AI agent is built on top of AWS's modular agent infrastructure suite. AgentCore was introduced in preview in July 2025, reached general availability in October 2025, and has continued to expand since — Policy and Evaluations entered preview at re:Invent 2025 in December 2025, Policy reached GA in March 2026, and the managed AgentCore harness (which wraps an entire production agent behind two API calls) reached GA in June 2026. Unlike Agents for Amazon Bedrock, which is a single opinionated agent-building service, AgentCore is a set of composable, framework-agnostic services — you can bring an agent built with any framework (LangGraph, CrewAI, Strands, the raw OpenAI or Anthropic SDKs) and adopt only the pieces of AgentCore you need: secure hosting, tool integration, memory, identity, observability, or all of them together.

Diagramming an AgentCore deployment matters for a different reason than diagramming a single-model application: AgentCore is explicitly a composition of independently billed, independently scaled services, and the value of the platform comes from how they wire together — which agent framework runs inside which Runtime session, which tools are exposed through Gateway, where conversation memory is stored and consolidated, and which identity a tool call executes under. A clear diagram is the fastest way to communicate that composition to a security reviewer, a new engineer, or your own future self six months later.

The core components of an AgentCore architecture

AgentCore Runtime

AgentCore Runtime is the secure, serverless hosting layer for agents and tools. Each user session runs in a dedicated microVM with isolated CPU, memory, and filesystem — complete separation between sessions that prevents cross-session data contamination even though the underlying agent reasoning is non-deterministic. When a session ends, the microVM is terminated and its memory is sanitized. Runtime supports long-running agent invocations (well beyond typical Lambda timeouts) and works with any agent framework, since it just hosts your containerized agent code. In your diagram, show Runtime as the execution boundary around your agent's code, with one microVM icon per active session and an explicit note on the isolation guarantee — this is the detail security reviewers ask about first.

AgentCore Gateway

AgentCore Gateway is the tool-integration layer. It turns existing APIs, AWS Lambda functions, OpenAPI specs, and Smithy models into Model Context Protocol (MCP)-compatible tools without custom integration code — zero-code "MCP-ification" of systems you already have. Gateway also fronts other agents and HTTP services through passthrough targets (including agent-to-agent traffic) and can front existing MCP servers so multiple tool sources present a single unified MCP endpoint to your agent. It handles both inbound authentication (who is allowed to call the gateway) and outbound authentication to each target (IAM for Lambda/Smithy targets, API keys or two-legged OAuth for OpenAPI/REST targets). In your diagram, draw Gateway as the single entry point between your agent and every external tool, with one edge per target type (Lambda, OpenAPI, Smithy, or passthrough) and the auth method labeled on each edge.

AgentCore Memory

AgentCore Memory is the managed context-retention layer. Short-term memory stores the raw event stream of a session — each turn is saved via a CreateEvent call keyed by session ID and actor ID, giving the agent conversation continuity within a session. Long-term memory runs asynchronously in the background, extracting and consolidating durable facts from that raw history using one or more of four built-in strategies: Semantic, User Preference, Summary, and Episodic. Extracted memories are organized under namespaces you define, and advanced use cases can override the extraction prompts and models per strategy. In your diagram, show Memory as a store the agent both writes to (every turn) and reads from (retrieval before the next turn), with the short-term event log and the long-term consolidated store as two distinct sub-components and the active strategies labeled.

AgentCore Identity

AgentCore Identity manages how an agent and its tool calls authenticate — both the agent's own identity when it's invoked, and the credentials it uses to act on a user's behalf against downstream systems. It integrates with AWS IAM natively and with external identity providers (Okta, Microsoft Entra, Amazon Cognito) and popular SaaS apps (Slack, Zoom) for OAuth-based delegated access. In your diagram, show Identity as the credential broker sitting alongside Gateway: label which identity provider issues the token, whether the agent is acting as itself or on-behalf-of a specific user, and which downstream scopes are granted.

AgentCore Browser Tool and Code Interpreter

Browser Tool gives an agent a managed, sandboxed browser session to navigate and extract information from live websites at scale — useful when the tool the agent needs doesn't have an API. Code Interpreter gives the agent a secure sandbox to execute generated code (data analysis, calculations, file transformations) without running arbitrary code on your own infrastructure. Both run as isolated, ephemeral sessions similar in spirit to Runtime's microVM model. In your diagram, show these as specialized tool nodes the agent calls through Gateway (or directly via their own APIs), with the sandbox boundary drawn explicitly — this is the detail that answers "where does untrusted code actually run."

AgentCore Observability

AgentCore Observability provides dashboards, tracing, and metrics built on OpenTelemetry, giving visibility into agent reasoning steps, tool calls, latency, and token usage across every AgentCore service. It integrates with Amazon CloudWatch (including CloudWatch GenAI Observability) so agent traces sit alongside your existing AWS observability stack rather than in a separate silo. In your diagram, show a single Observability node collecting traces from Runtime, Gateway, and Memory, with an arrow into CloudWatch — this makes clear that observability is cross-cutting, not bolted onto one component.

AgentCore Policy and Evaluations

Policy (GA March 2026) provides centralized, fine-grained controls over what actions an agent and its tools are allowed to take — a governance layer that sits above individual IAM permissions, letting security teams define and audit agent behavior rules in one place. Evaluations provides continuous quality monitoring of agent outputs against defined criteria, so regressions in agent behavior are caught after deployment, not just in a pre-launch test run. Both entered preview at re:Invent 2025 alongside the rest of the AgentCore suite. In your diagram, show Policy as a control plane connected to every tool-invocation edge, and Evaluations as an offline/async process sampling production traffic from Observability.

AgentCore harness

The AgentCore harness (GA June 2026) is the newest and highest-level piece: a managed abstraction that wraps an entire production agent — model, tools, skills, memory, identity, and observability — behind two API calls, CreateHarness to define the agent and InvokeHarness to run it. It composes Runtime, Gateway, Memory, Identity, and Observability under the hood automatically, supports switching between model providers (Bedrock, OpenAI, Gemini, and others via LiteLLM) mid-session without losing context, and removes the need to hand-wire the individual services yourself. In your diagram, harness-based deployments can often be drawn as a single "AgentCore harness" box with the individual services shown as an expandable inset — useful for executive-level diagrams where the composition detail is less important than the fact that AWS manages it end-to-end.

Common AgentCore architecture patterns

Pattern 1: Bring-your-own-framework agent on Runtime + Gateway

The most common AgentCore adoption path for teams with existing agent code: an agent built with LangGraph, CrewAI, Strands, or a custom loop is containerized and deployed to AgentCore Runtime for isolated, serverless hosting. Tool access goes through AgentCore Gateway, which exposes existing Lambda functions and internal REST APIs as MCP tools with no custom integration code. Identity brokers the credentials for each downstream call. This pattern lets teams keep their existing agent logic and adopt AgentCore purely for secure hosting and tool integration.

Pattern 2: Full AgentCore stack with Memory and Observability

Production customer-facing agents typically wire in every core service: Runtime hosts the agent, Gateway connects it to tools, Memory persists short-term session events and long-term semantic/summary/episodic facts across visits, Identity handles both the agent's own credentials and on-behalf-of user access to downstream systems, and Observability traces every reasoning step and tool call into CloudWatch. This is the pattern to use for anything with multi-session users — support copilots, personal assistants, account-management agents — where remembering the user across conversations is the point.

Pattern 3: Managed deployment with AgentCore harness

Teams that want the fastest path to production skip hand-wiring the individual services and declare their agent through CreateHarness — model, tools, skills, and instructions — then call InvokeHarness to run it. The harness handles environment, compute, memory, identity, networking, and observability automatically, and supports mid-session model-provider switching. Best for teams standing up a new agent from scratch who don't need to control the individual service wiring.

Pattern 4: Governed multi-tool agent with Policy and Evaluations

Regulated or high-risk deployments (financial services, healthcare, anything that takes real-world actions) layer Policy on top of Gateway to centrally define which tool actions are permitted under which conditions, and Evaluations to continuously sample production traffic and score it against quality/safety criteria. Observability feeds both: Policy decisions and Evaluation scores are traced alongside the underlying agent reasoning so an auditor can reconstruct exactly why an action was allowed or blocked.

Prompt templates for AgentCore diagrams

Basic Runtime + Gateway agent

Full-stack customer support agent with Memory

Managed deployment with AgentCore harness

Governed multi-tool agent with Policy and code execution

AgentCore component reference

What a good AgentCore architecture diagram must show

• Session isolation: Make Runtime's per-session microVM boundary explicit. This is the primary security guarantee reviewers will ask about, and it is easy to gloss over if you draw Runtime as a generic compute box.
• Tool provenance: For every tool reachable through Gateway, label whether it's a Lambda, OpenAPI, Smithy, or passthrough target, and which auth method secures it. A single Gateway node hides real differences in trust level between an internal Lambda and a third-party OpenAPI target.
• Memory read/write paths: Show short-term event writes on every turn separately from the asynchronous long-term consolidation process, and label which strategies (Semantic, User Preference, Summary, Episodic) are active — this determines what the agent actually remembers.
• Identity delegation: Distinguish credentials the agent uses as itself from credentials it uses on behalf of a specific user. Conflating the two is a common and serious security-review finding.
• Sandbox boundaries: If the agent uses Browser Tool or Code Interpreter, draw the sandbox explicitly. These exist specifically to contain untrusted actions, and that containment should be visible in the diagram, not implied.
• Observability coverage: Show Observability as a cross-cutting node collecting traces from every other service, not attached to just one. Gaps in trace coverage are gaps in your ability to debug agent behavior in production.
• Governance layer: If Policy or Evaluations are in use, show which tool-invocation edges Policy governs and what Evaluations samples — this is the artifact compliance teams will ask to see first.

Frequently asked questions about Amazon Bedrock AgentCore architecture

What is Amazon Bedrock AgentCore?

Amazon Bedrock AgentCore is a suite of modular, framework-agnostic AWS services for deploying and operating AI agents in production. It includes Runtime (secure serverless hosting), Gateway (tool integration via MCP), Memory (short- and long-term context retention), Identity (agent and delegated-user authentication), Observability (OpenTelemetry-based tracing), Browser Tool and Code Interpreter (sandboxed web and code execution), Policy (centralized action governance), Evaluations (continuous quality monitoring), and the newer harness (a managed abstraction over all of the above behind two API calls). Each service can be adopted independently or together, and you pay only for what you use. AgentCore reached general availability in October 2025, with Policy, Evaluations, and the harness reaching GA through the first half of 2026.

How is AgentCore different from Agents for Amazon Bedrock?

Agents for Amazon Bedrock is a single opinionated service: it defines the agent's ReAct reasoning loop, action groups, and session state within Bedrock's own agent-building model. AgentCore is infrastructure that sits underneath any agent, regardless of which framework built the reasoning logic — LangGraph, CrewAI, Strands, a hand-rolled loop, or Agents for Bedrock itself. In practice: use Agents for Bedrock when you want AWS to define how the agent reasons; use AgentCore when you already have (or want to build) your own agent logic and need secure hosting, tool integration, memory, identity, and observability around it. The two are complementary rather than competing — an Agents for Bedrock agent can be deployed on AgentCore Runtime and use AgentCore Gateway for tool access.

How do I diagram AgentCore Gateway and tool integration?

Draw Gateway as a single node between your agent and every external tool it can call. For each tool, add an edge labeled with its target type — Lambda (IAM-based egress auth), OpenAPI (API key or two-legged OAuth), Smithy (IAM-based), or passthrough (fronting another agent or MCP server, including agent-to-agent traffic). Show the inbound authentication that gates who can call Gateway at all, separately from the outbound authentication to each target — these are two distinct trust boundaries that are easy to conflate in a diagram but matter a great deal to a security reviewer.

Do I need to use every AgentCore service to adopt it?

No. AgentCore is explicitly designed so each service — Runtime, Gateway, Memory, Identity, Observability, Browser Tool, Code Interpreter, Policy, Evaluations — can be used independently. A common starting point is adopting only Runtime (for secure hosting) and Gateway (for tool integration) while keeping your own conversation-state and logging approach; Memory, Identity, Policy, and Evaluations can be layered in later as the agent matures toward production. Your diagram should reflect exactly which services are in use today versus planned — don't draw the full nine-component suite if only two are wired up.

What is the AgentCore harness and when should I use it instead of wiring services myself?

The AgentCore harness (GA June 2026) is a managed abstraction that composes Runtime, Gateway, Memory, Identity, and Observability behind two API calls: CreateHarness to declare the agent (model, tools, skills, instructions) and InvokeHarness to run it. Use the harness when you want the fastest path to a production-grade agent and don't need fine control over how the underlying services are wired — it also supports switching model providers mid-session without losing context. Wire the individual AgentCore services yourself when you need specific control over one piece (a custom Memory strategy, a particular Gateway auth configuration, or a non-default Observability pipeline) that the harness's defaults don't expose.

Related guides: AWS Bedrock architecture diagrams, AI agent architecture diagrams, MCP architecture diagrams, multi-agent orchestration patterns, and AI guardrails architecture.