Amazon Bedrock AgentCore is not one service. It is a set of primitives — a body for the model to run in — and the fastest way to stop the names from blurring is to ask, for each one, which organ it is. The model is the brain; every AgentCore piece is a part of the body around it: the part that holds state, the part that reaches tools, the part that proves who is calling.
The names invite the confusion. Gateway does auth, Identity does auth, Policy does auth. Runtime runs agents, and so does the Harness. Depending on which post you read there are six components, or seven, or twelve. Read as a list, it is a pile. Read as a body, it is a map — and this post is the map: one pass over every piece, what problem it solves, and how they compose. It is the post I wish I had read before I wired anything.
The one distinction that unlocks the rest
The primitives are à la carte. You adopt them one at a time — AWS is explicit that you can run any single piece, Memory or Browser or a Gateway, inside an app on your own compute without adopting the rest. You do not have to take the whole body to use a hand.
That is the reframe. The useful question is not "how do I set up AgentCore" but "which organ do I need" — and the answer is almost never the whole body at once.
The pieces sort into three groups by the job they do.
BODY (run the agent) REACH (touch the world) GOVERN (prove & watch)
Runtime — isolated compute Gateway — tools over MCP Identity — who the caller is
Memory — state across turns Browser — a real browser Policy — who may call what
Harness — wires them together Code Interpreter — a sandbox Observability — what happened
Read it left to right and it is a sentence: something runs the agent, something lets it reach the world, something governs and records what it did. Every name below lands in one of those three columns.
Body: the pieces that run the agent
Runtime is the compute. Every session gets its own isolated Linux microVM with a real filesystem and shell, sessions can run up to eight hours, and you are not billed for the time the agent spends waiting on I/O. This is the piece that exists because a Lambda — fifteen-minute ceiling, no session persistence — is the wrong shape for an agent that thinks, calls a tool, waits, and thinks again. Runtime is the "where does the loop actually execute" answer.
Memory is state that outlives a turn. Short-term memory within a session and long-term memory across sessions, so an agent can pick up a conversation, or a project, where it left off even after the underlying microVM has been recycled. Without it, every session starts from zero; with it, the agent accumulates context the way a colleague does.
Harness is the wiring. This is the piece most likely to confuse you, because it is not a new capability — it is the managed assembly of the others. You describe an agent in configuration — its model, its tools, its instructions — and the Harness runs the orchestration loop, manages the context window, persists state, and isolates the session, using Runtime and Memory underneath. Before the Harness you hand-wired those primitives every time; the Harness makes that wiring something you configure instead of something you build. If Runtime is the muscle and Memory is the recall, the Harness is the nervous system that coordinates them.
Reach: the pieces that touch the world
Gateway is the front door to tools. It takes any API, Lambda, or MCP server and presents it to agents as a tool over the Model Context Protocol, aggregating everything behind one endpoint so an agent connects once and sees the whole menu. This is the piece I have written about most, because it is the one you hit first: how a Gateway turns any API into an agent tool is the mechanics, and the managed WebSearch connector is the same primitive with an Amazon-operated search index behind it instead of your own Lambda. Gateway is the "how does my agent call things" answer.
Browser is a real, managed browser the agent can drive — AWS-managed Chromium in an isolated session — for the tasks that have no clean API and only exist behind a web UI. It is the escape hatch for the long tail of the web that never got an endpoint.
Code Interpreter is a sandbox where the agent writes and runs code against a real shell and filesystem, safely isolated. It is how an agent does arithmetic it can trust, transforms a file, or runs a script instead of hallucinating the output.
Govern: the pieces that prove and watch
This is the column where the auth confusion lives, and separating the three pieces is most of the fix.
Identity answers who the caller is, on both sides of the agent. Inbound, it validates the identity of whoever invoked the agent. Outbound, it lets the agent act as that user against a downstream service — holding the real tokens for GitHub, Slack, or your own APIs outside the agent, so the agent never sees a raw credential. Identity is about establishing and carrying identity, especially the outbound, act-as-the-user direction.
Policy answers who may call what. It is a Cedar policy engine that sits on a Gateway and evaluates every tool call before it runs: the principal comes from the caller's identity, the action is the tool name, and conditions can read the caller's claims or even the tool's own arguments. Default-deny, forbid-overrides-permit. This is the piece that is easy to fold into Identity by mistake, because both say "auth" — but they answer different questions. Identity says this is Alice; Policy says Alice may call this tool, with these arguments, and no one else may.
Observability answers what happened. Every step the agent takes — every tool call, every reasoning turn — is traced automatically into CloudWatch, in one unified view instead of scattered across log groups. It is the piece that turns "the agent did something weird" into a trace you can actually read.
How they compose
The pieces are à la carte, but they are built to snap together. A representative full path looks like this:
flowchart TD
ID["Identity: who is the caller"] --> POL{"Policy: may they call this?"}
POL -->|allow| RUN["Runtime: the agent runs"]
RUN --- MEM["Memory: state across turns"]
RUN --- HAR["Harness: wires it together"]
RUN --> REACH["reach the world"]
REACH --> GW["Gateway: tools over MCP"]
REACH --> BR["Browser"]
REACH --> CI["Code Interpreter"]
RUN --> OBS["Observability: every step traced"]
POL -->|deny| STOP["blocked before the tool runs"]
But you rarely start with all of it. My own path started at Gateway — one endpoint, a few tools — because "let my agents call things" was the first real need. Identity and Policy became interesting only once an external caller entered the picture. Runtime and Memory matter when the agent moves off my laptop and needs to persist. That incremental path is the intended one: adopt the organ the current problem demands, not the whole body on day one.
What this unlocks
The map is abstract until you ask what it lets you ship. Three business shapes fall out of the primitives above — and each one maps to wiring the rest of this series actually builds and verifies, not to a roadmap slide. The market is already moving toward all three: Gartner projects that 40% of enterprise applications will embed task-specific agents by the end of 2026, up from under 5% in 2025.
B2B: multi-tenant tool access with per-customer rules. If you sell software, your customers' agents will want to call your platform — Forrester expects 30% of enterprise app vendors to ship their own MCP servers in 2026. The hard part is not exposing the tools; a Gateway does that in one endpoint. The hard part is identity inheritance: when an agent reads a customer's Jira tickets or updates their Salesforce opportunities, it must operate inside that user's exact permissions, not a shared service account, and it must be scoped to the specific resources the task needs rather than the full breadth of what the user can access. That is Identity plus Policy: the caller's identity becomes the Cedar principal, and a policy decides the call per user, per tool, per argument, default-deny, before the tool runs. I wired exactly this and watched the same refund call get allowed at $450 and denied at $600 — the difference was one condition in a policy, not a code change. That per-argument, per-tenant gate is the primitive under any "let our customers' agents integrate, safely" B2B story.
B2C: an assistant that acts as the user, consenting once. Consumers are now handing execution rights to agents directly — ChatGPT's agent mode acts across a user's email and calendar, AI browsers like Perplexity's Comet shop and book from inside the tabs, and the whole category trades on a phrase that should make any security engineer pause: agents "being handed the keys to real accounts." The only safe way to hold those keys is to not let the agent hold them. That is the browser-front-door plus the outbound identity flow: the user consents once at the web app, AgentCore holds the real tokens outside the agent, and the agent acts as the user afterward. I ran this end to end — the agent read a GitHub profile as the authorizing user, with the token held in the vault, never exposed to the agent code. Consent once, act many times, credentials never in the agent: that is the consumer-assistant primitive, and it is the difference between delegated access and a credential leak waiting to happen.
Internal / corporate: automation that acts as itself, fully traced. Inside a company, most agents are not acting for an end user — they are back-office automation reconciling data, watching systems, running scheduled work against internal APIs, where organizations report 60–80% reductions in routine task-handling time and single teams have deployed hundreds of internal agents — one automation vendor now runs more internal agents than it has employees. Here the agent is its own principal: it authenticates machine-to-machine, reaches internal tools through one governed Gateway, and every step it takes is traced automatically into CloudWatch. I verified the machine-to-machine flow — the agent obtained a scoped token where the principal was the agent, not any user — which is the right shape when there is no human in the loop. This is also where the failures cluster: Gartner argues that runtime inspection and policy-as-code is the single most critical pillar for scaling agents safely, because static access controls cannot halt a malfunctioning agent, and it names deep observability — answering "why did the agent do that?" — as the other half. Governed endpoint, machine identity, policy gate, full trace: that is the internal-automation primitive.
One pattern runs through all three, and it is the reason the governance column exists: the model is never the thing that is trusted. Identity proves the caller, Policy decides the call, the Gateway is the only door, and Observability records it. The business use case changes; the governed shape underneath does not. That is also why the projects that fail, fail — industry surveys put the abandonment rate for agentic projects north of 40%, and the named cause is governance, not model quality. The primitives in this column are the part most demos skip and most production deployments live or die on.
What's missing
This map is a snapshot, and the surface is still moving. The count of "official" components has already gone from six primitives at launch to a longer list as Harness, Policy, and evaluation tooling landed, and third-party guides inflate it further by counting preview features and adjacent services. Treat any exact number as a date-stamped claim, not a fixed truth — including this one.
The harder omission is that a map is not a manual. Knowing that Policy is the Cedar layer does not tell you how to write a policy that holds up, and knowing Identity carries outbound tokens does not tell you how the three-legged OAuth flow actually feels to wire. Each organ has its own depth, its own sharp edges, and its own moment where the abstraction leaks. This post is the index; the mechanisms are their own posts, and I am writing them as I actually run each piece rather than from the documentation alone.
So what
The reason to hold the map before the mechanics is that it stops you from adopting the wrong organ for the problem in front of you. Most of the confusion in the AgentCore surface is not difficulty — it is that three pieces all say "auth" and two pieces all say "run the agent," and without the map you cannot tell which one you actually need. With it, the question gets small: what is the agent missing right now — a place to run, a way to reach a tool, a way to prove who is calling — and which single organ supplies it.
The build order follows the work: adopt the organ the current problem demands, then the next when the next problem is real. That is how the body gets assembled — one organ at a time, not by standing up the whole anatomy and hoping you needed it.
This is the map for a series working through Amazon Bedrock AgentCore by building on it. The deep dives: Two Ways to Authorize an Agent Tool (the Gateway's front-door auth), Who May Call What (per-user authorization with Cedar), and Two Things I Almost Called AgentCore Gaps (how to tell a real gap from a layer AgentCore delegates to).
Top comments (0)