Amazon Bedrock AgentCore Architecture Diagram: Runtime Memory Gateway & Policy

The AgentCore overview lists Harness, Runtime, Memory, Gateway, Identity, and Policy as modules you can combine. The harness versus Runtime page says Harness is a config loop inside Runtime, and Runtime is where you bring the loop. A May 21, 2026 multi-tenant post places those pieces in silo, pool, and bridge layouts. This diagram is the request path.

What this Amazon Bedrock AgentCore architecture diagram shows

A caller hits either your own code on Runtime or a Harness definition. Tool calls go through AgentCore Gateway. The overview says Policy intercepts every tool call before it runs. Memory sits beside the session: short-term for the turn, long-term across sessions. Observability is OpenTelemetry-compatible telemetry; the May 21, 2026 post says that path is powered by Amazon CloudWatch. Evaluations score sessions, traces, and spans off the hot path.

The problem this architecture is solving

The overview’s pitch is any framework and model without you running the host. The harness page says what you still own. On Runtime you wrap code with BedrockAgentCoreApp, push an ARM64 image to Amazon ECR, and keep the loop. You call Memory, Gateway, Browser, Code Interpreter, or outbound Identity yourself. On Harness you declare model, prompt, tools, memory, and limits. A model change is config, not a redeploy. CloudTrail logs harness calls as AWS::BedrockAgentCore::Runtime, so Harness is not a second host.

The May 21 post, part 1 and not a benchmark, adds tenant isolation, identity, observability, data isolation, cost attribution, and noisy neighbors. A demo is not the production shape.

Main components and trust boundaries

The overview calls Runtime a serverless host with session isolation and names CrewAI, LangGraph, LlamaIndex, Google ADK, the OpenAI Agents SDK, Strands, MCP, and A2A. The harness grid marks your own framework, bidirectional streaming, and non-loop workflows as unsupported on Harness and custom on Runtime. Session isolation is yes for both, with no extra code. Each Harness session is an isolated microVM with a filesystem and shell. The May post says Runtime starts a lightweight microVM per session, with its own file system, and that tenant context arrives in custom HTTP headers beside the token. Those lines agree. They do not name two machines.

Overview Memory is short-term across turns and long-term across sessions, shareable, and able to learn from experience. The harness page names long-term strategies: semantic, summarization, user preference, and episodic, scoped by actor id. The May post adds five logical levels — global, strategy, tenant, user, session — with resource policies and attribute checks. A pool store uses a namespace such as tenant-a:user-123. A silo store is dedicated per tenant. The diagram shows one Memory service. Silo, pool, and bridge sit beside the request path, not as five products.

Gateway turns APIs, Lambda functions, and existing services into MCP tools and can attach to MCP servers. The overview’s examples include Salesforce, Zoom, Jira, and Slack. The May post adds API Gateway, OpenAPI, Smithy, interceptors, and resource policies. Identity keeps your IdP. Both pages name Cognito, Okta, and Microsoft Entra ID; the overview also names Auth0. The May post prefers an on-behalf-of exchange, citing OAuth 2.0 RFC 8693, over impersonation, and attributes that exchange to AgentCore Identity. Inbound auth is IAM SigV4 or OAuth on both.

Policy is the one place these sources do not use the same language name. The overview says you author rules in natural language or in Dogwood, “which is compatible with Cedar,” and that Policy integrates with Gateway to decide tools, actions, and conditions. The May 21 post says policies are authored in natural language or directly in Cedar, and that Policy evaluates requests before tool access using identity and tool inputs. Do not pick Dogwood or Cedar as the only label. The diagram can say “policy language (overview: Dogwood, Cedar-compatible; May 2026 post: Cedar).”

Request or data path, step by step

In both silo and pool, the user gets a JWT with tenant context. A proxy calls InvokeAgent with that token. Runtime checks it with AgentCore Identity, starts a microVM session, and runs the agent. Silo adds a map from tenant to a dedicated runtime and a claim check that can refuse the wrong tenant. Memory is the runtime role’s store in silo, or a tenant-and-user namespace in pool.

The agent calls Gateway, which validates the JWT, reads the tenant, reaches a dedicated or pooled backend, and applies policy and interceptors. The overview places that intercept before the tool runs. Bridge means you may silo one layer and pool another, for example a shared runtime with a dedicated gateway. The post draws more than one mix, not a single required shape. Responses return through the gateway and the proxy, which the silo and pool narratives both say can format for the tenant.

The diagram: labeled boxes and failure or isolation edges

Center the caller, Identity, a microVM session, Memory, Gateway, Policy, and MCP tools. OTel goes to CloudWatch. Evaluations stay off the request path. Harness is config inside Runtime.

• Session wall: one microVM and file system per session. No shared disk arrow.
• Policy deny: the tool does not run. Label Dogwood versus Cedar instead of inventing syntax.
• Tenant wall: silo is a dedicated runtime, gateway, and memory. Pool shares them behind a namespace. Bridge mixes per layer.
• Delegation: the May post recommends on-behalf-of exchange over impersonation.
• Framework wall: a graph or workflow loop is Runtime code, not Harness.

What the source does not claim (preview, case study, or limits)

The doc pages read as current reference, not a beta banner. The May 21, 2026 article is part 1 and says a working pool and silo come later, so those flows are a design narrative, not a cloneable repo. Pricing is consumption-based with no upfront fee and no rates on these pages. The overview says AgentCore may store your content to improve your own use of the service, not other customers’ — a limit, not a feature. Harness cannot take your framework, bidirectional streaming, or a non-loop workflow. Browser, Code Interpreter, Payments, Optimization, and Registry stay off this drawing. None of the three sources states a latency SLO.

How this differs from a nearby pattern on ByteDiagram

The forecast-to-purchase-order diagram is one business flow. This page is the platform: session, memory, gateway, policy. The stateless MCP diagram is the 2026-07-28 server change, not the Gateway. Do not merge them.

FAQ

Is AgentCore Harness a different host from AgentCore Runtime?

No. The harness page says Harness runs inside Runtime, and CloudTrail records it as AWS::BedrockAgentCore::Runtime. Harness is configuration. Runtime is your code in an ARM64 ECR image and your own loop. Your own framework, bidirectional streaming, and non-loop workflows are unsupported on Harness.

Do the sources agree on the policy language?

No. The overview says natural language or Dogwood, described as compatible with Cedar, with Policy intercepting each Gateway tool call first. The May 21, 2026 post says natural language or Cedar directly. Keep both.

How does the May 2026 post isolate one tenant’s session and memory from another’s?

Runtime starts a microVM per session with its own file system. Tenant context rides in the JWT and custom headers. Memory is a dedicated store or one store split by namespace, such as a tenant-and-user actor id. The harness page names semantic, summarization, user-preference, and episodic long-term strategies.

Conclusion

The picture runs from Identity through an isolated session and namespaced Memory to Gateway, with a policy check before tools. Keep Dogwood and Cedar as the two source wordings. Cite the overview, the harness page, and the multi-tenant post. More diagrams are on the ByteDiagram blog.