Amazon Bedrock AgentCore Architecture Diagram: Runtime, Gateway, Memory & Identity (2026)

How to diagram Amazon Bedrock AgentCore — Runtime, Gateway, Memory, Identity, Browser Tool, Code Interpreter, and Observability for production AI agents — with prompt templates.

Ryan·Senior AI Engineer

·Last updated July 1, 2026

Amazon Bedrock AgentCore is a suite of modular, composable AWS services purpose-built for securely deploying and operating AI agents at scale in production. It GA'd in October 2025 to address a gap that generic model APIs and simple agent builders don't solve: once an agent moves from prototype to production, it needs a secure runtime, durable memory, tool access that doesn't require hand-built integrations, credential management for non-human identities, sandboxed execution for risky actions like running code or browsing the web, and step-by-step observability into what the agent actually did.

The defining property of AgentCore is that it is framework-agnostic (works with CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK, and Strands Agents), protocol-agnostic (supports MCP or A2A for tool and agent-to-agent communication), and model-agnostic (Amazon Nova, OpenAI, Gemini, Anthropic models, and others). Its seven components can be adopted independently or combined, and billing is pay-per-use per component — you are not locked into a single agent-building framework to get AWS's production operational infrastructure. This guide covers each AgentCore component and gives prompt templates for generating AgentCore architecture diagrams.

The seven AgentCore components

AgentCore Runtime

AgentCore Runtime is a secure, serverless runtime purpose-built for deploying and scaling dynamic AI agents built with any framework. Rather than standing up your own container infrastructure to host a LangGraph or CrewAI agent, you deploy the agent code to Runtime and AWS handles scaling, isolation, and session management. In your diagram, show Runtime as the execution boundary that hosts your agent's code — draw it as a distinct box around the framework logic (LangGraph graph, CrewAI crew, or whatever framework you used to build the agent) to make clear that the framework and the runtime are separate layers.

AgentCore Memory

AgentCore Memory is fully managed infrastructure for storing and recalling context, enabling personalized, context-aware multi-turn agent experiences. It removes the need to build your own session store or long-term memory database for conversation history, user preferences, or facts learned across sessions. On your diagram, show Memory as a component the agent reads from and writes to on every turn, positioned alongside — not inside — the Runtime, since memory persists across sessions and potentially across different agent invocations.

AgentCore Gateway

AgentCore Gateway turns existing APIs, AWS Lambda functions, and other services into agent-callable tools automatically, without hand-building integrations. Instead of writing a custom tool wrapper for every internal API your agent needs to call, you point Gateway at the API definition and it exposes a tool interface the agent can invoke — typically over MCP. In your diagram, show Gateway sitting between the agent and your backend systems (internal APIs, Lambda functions, third-party services), with each exposed tool labeled by the underlying API or function it wraps.

AgentCore Browser Tool

AgentCore Browser Tool lets agents browse the web and fill out forms inside a secure, managed sandbox. This is for agent tasks that require interacting with sites that don't have an API — checking a status page, filling out a web form, navigating a legacy admin console. On your diagram, draw the Browser Tool inside an explicit sandbox boundary, since it is executing untrusted, agent-directed actions against the open web and should be visually distinguished from calls to your own trusted internal systems.

AgentCore Code Interpreter

AgentCore Code Interpreter lets agents safely write and execute code in a sandbox to improve accuracy on complex tasks — data analysis, calculations, or generating and testing a script before returning a final answer. Like Browser Tool, this is sandboxed execution of agent-generated content that should never run in the same trust zone as your production services. Show it as a sandboxed node the agent invokes for a specific sub-task, with results flowing back into the agent's reasoning loop rather than being returned directly to the user unchecked.

AgentCore Identity

AgentCore Identity is built for non-human/machine identities and automated workloads — it handles authentication, authorization, and credential management for agents and the tools they call, supporting AWS SigV4, OAuth 2.0 flows, and API keys. This solves a problem generic IAM wasn't designed for: an autonomous agent acting on a user's behalf needs scoped, short-lived credentials to call downstream tools without the agent itself ever holding long-lived secrets. In your diagram, show Identity as the credential broker sitting between the agent and every external tool call (through Gateway, Browser Tool, or Code Interpreter), issuing scoped tokens rather than the agent holding static credentials.

AgentCore Observability

AgentCore Observability provides step-by-step visualization of agent execution with metadata tagging, custom scoring, trajectory inspection, and debugging filters. Because agents make multi-step, non-deterministic decisions, standard request/response logging is insufficient — you need to see the full reasoning trajectory: which tools were called, in what order, with what arguments, and why. On your diagram, show Observability as a trace path that taps every component (Runtime, Gateway, Memory, Identity, Browser Tool, Code Interpreter) rather than a single log sink at the edge.

AgentCore component reference

Component	Purpose	What to show on your diagram
Runtime	Secure, serverless hosting and scaling for agents built with any framework	Execution boundary around the framework logic (LangGraph, CrewAI, Strands, etc.)
Memory	Managed storage and recall of context for multi-turn, personalized sessions	Read/write path from the agent, persisted across sessions
Gateway	Converts APIs and Lambda functions into agent-callable tools automatically	Tool boundary between agent and backend systems, each tool labeled by source API/function
Browser Tool	Sandbox for agents to browse the web and fill out forms	Explicit sandbox boundary around web-facing actions
Code Interpreter	Sandbox for agents to write and execute code for complex sub-tasks	Sandboxed node invoked for a sub-task, results returned to the reasoning loop
Identity	Authentication, authorization, and credential management for non-human/agent identities (SigV4, OAuth 2.0, API keys)	Credential broker between the agent and every tool call — scoped, short-lived tokens, not static secrets
Observability	Step-by-step execution visualization, metadata tagging, custom scoring, trajectory inspection	Trace path tapping every other component, not a single edge log sink

AgentCore vs. Agents for Amazon Bedrock

AWS also offers Agents for Amazon Bedrock, the native, simpler agent builder covered in our general AWS Bedrock architecture guide. That feature implements a built-in ReAct loop with action groups backed by Lambda functions — it is the fastest path to a working agent if you are comfortable building it inside Bedrock's own agent framework and don't need to bring another framework or deep operational tooling.

AgentCore is a different layer of the stack. It is for teams that need production-grade operational infrastructure — non-human identity and credential management, sandboxed tool execution, durable cross-session memory, and step-by-step observability — wrapped around agents built with any framework, not just Bedrock's built-in agent builder. A team already standardized on LangGraph or CrewAI does not need to rewrite their agent logic to get AWS-managed runtime, memory, and identity; they deploy their existing agent to AgentCore Runtime and adopt the other components as needed. On an architecture diagram, the distinction is worth calling out explicitly: Agents for Bedrock is a single integrated component, while AgentCore is a set of independent services you compose around an agent that may have been built entirely outside Bedrock.

Prompt templates for AgentCore architecture diagrams

LangGraph agent on AgentCore Runtime with Gateway and Memory

"Architecture diagram for a customer support agent built with LangGraph and deployed on Amazon Bedrock AgentCore Runtime. The LangGraph graph (intent classification node, retrieval node, response generation node using Claude claude-sonnet-4-6) is deployed as a container to AgentCore Runtime, which handles scaling and session isolation per conversation. On each turn, the agent reads prior conversation state and user preferences from AgentCore Memory before invoking the model, and writes updated state back after generating a response. The agent needs to look up order status and issue refunds — instead of custom Lambda wrappers, these are exposed through AgentCore Gateway, which wraps the internal OrdersAPI and RefundsAPI (both REST services in a private VPC) as MCP tools the agent can call directly. Gateway requests are authenticated through AgentCore Identity, which issues a short-lived OAuth 2.0 token scoped to the specific customer's order history rather than granting the agent standing access to the full orders database. The frontend chat widget calls the agent through an API Gateway endpoint; AgentCore Observability traces every step — the LangGraph node transitions, the Gateway tool calls, and the Memory reads/writes — into a single inspectable trajectory per conversation."

Research agent with Code Interpreter, Browser Tool, and Identity

"Architecture diagram for a research and analysis agent built with the Strands Agents framework and deployed on AgentCore Runtime. Given a research question, the agent plans a set of sub-tasks using Claude claude-opus-4-8: for tasks requiring current web information, it invokes AgentCore Browser Tool, which loads the target page inside a managed sandbox, extracts the relevant content, and returns it to the agent — the sandbox boundary is drawn explicitly since the agent is interacting with untrusted external sites. For tasks requiring numerical analysis, the agent invokes AgentCore Code Interpreter, which executes agent-generated Python in an isolated sandbox to compute statistics from the retrieved data and returns only the result values, not raw execution access, back to the agent. Both tools require credentials to reach any authenticated resource (an internal analytics API, a paid data provider) — those credentials are issued by AgentCore Identity as short-lived, tool-scoped tokens rather than being embedded in the agent or the sandbox image. AgentCore Observability captures the full trajectory: which sub-tasks were planned, which tool (Browser Tool vs. Code Interpreter) handled each one, the arguments passed, and the latency per step, so a reviewer can audit exactly how the agent arrived at its final research summary."

Key design principles for AgentCore diagrams

Draw the sandbox boundary explicitly: Browser Tool and Code Interpreter execute agent-directed actions against untrusted content (the open web, agent-generated code). Show them inside a clearly bounded sandbox, visually separated from calls to your own trusted internal systems.
Show the identity/credential flow, not just the data flow: Every tool call the agent makes — through Gateway, Browser Tool, or Code Interpreter — should show AgentCore Identity issuing a scoped, short-lived credential rather than depicting the agent as holding static secrets.
Separate the framework from the runtime boundary: The agent's reasoning logic (LangGraph graph, CrewAI crew, Strands agent) is framework code; AgentCore Runtime is the hosting boundary around it. Drawing these as one box hides an important architectural fact — the framework is swappable, the runtime is not part of the framework.
Route the observability trace through every component: AgentCore Observability should tap Runtime, Gateway, Memory, Identity, Browser Tool, and Code Interpreter — not just log the final response. Show it as a trace path threading through the whole diagram rather than a single sink at the edge.
Label components as independently adopted: Because AgentCore components are billed and used independently, annotate which ones a given architecture actually uses — a diagram that shows all seven when only Runtime and Gateway are in play overstates the system's complexity.

Frequently asked questions about Amazon Bedrock AgentCore

What is Amazon Bedrock AgentCore?

Amazon Bedrock AgentCore is a suite of modular AWS services — Runtime, Memory, Gateway, Browser Tool, Code Interpreter, Identity, and Observability — for securely deploying and operating AI agents at scale in production. It GA'd in October 2025 and is framework-agnostic (LangGraph, CrewAI, LlamaIndex, Google ADK, OpenAI Agents SDK, Strands Agents), protocol-agnostic (MCP or A2A), and model-agnostic (Nova, OpenAI, Gemini, Anthropic, and others). Components can be adopted independently and are billed pay-per-use.

Is AgentCore the same as Bedrock Agents?

No. Agents for Amazon Bedrock is a single, integrated agent builder with a built-in ReAct loop and Lambda-backed action groups — it is Bedrock's native, simpler way to build an agent. AgentCore is a separate, more granular set of operational services (identity, observability, sandboxed tool execution, durable memory, tool exposure via Gateway) designed to wrap around agents built with any framework, including ones built entirely outside Bedrock. See our general AWS Bedrock architecture guide for how Agents for Bedrock fits into the broader Bedrock picture.

Can I use AgentCore with a non-AWS agent framework like LangGraph or CrewAI?

Yes — AgentCore is explicitly framework-agnostic and supports CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK, and Strands Agents. You deploy your existing agent code to AgentCore Runtime and adopt Gateway, Memory, Identity, Browser Tool, Code Interpreter, and Observability as needed, without rewriting the agent's reasoning logic in a Bedrock-specific format.

Ready to try it yourself?

Start Creating - Free