Amazon announced Bedrock AgentCore in preview at the New York Summit on July 16, 2025, and made it generally available on October 13, 2025. The one-line pitch is the easiest thing to miss and the most important: it is a platform to "build, deploy, and operate highly capable agents securely at scale using any framework, model, or protocol." Read that clause twice. AWS is selling you the warehouse, the loading dock, the security cameras, and the forklift — and pointedly not the thing you put on the shelves.
That neutrality is not modesty. It is the strategy. Let me walk the seven services, then the numbers, then why the decoupling is the actual product.
The seven primitives
AgentCore is not one service; it's a set you compose:
- Runtime — serverless agent execution with complete session isolation and sessions up to 8 hours.
- Memory — managed short-term (session) and long-term memory, with a self-managed strategy at GA for teams that want control over the extraction and consolidation pipeline.
- Gateway — turns existing APIs, Lambda functions, and even other MCP servers into MCP-compatible tools, with semantic tool selection so an agent can pick from thousands of tools without bloating its prompt.
- Identity — agent authentication over OAuth and IAM, with inbound auth (who may call the agent) and outbound auth (what the agent may call on a user's behalf), and built-in providers for Google, GitHub, Slack, and Salesforce.
- Browser — a managed, isolated headless browser for web automation at scale.
- Code Interpreter — a sandboxed environment to generate and run code in Python, JavaScript, and TypeScript.
- Observability — OpenTelemetry-compatible telemetry into CloudWatch, organized as session → trace → span, with token usage, latency, and error metrics.
You can adopt one of these without the others. That modularity is the tell: each primitive solves a problem you would otherwise solve by hand, and AWS is betting you'll solve more of them here over time.
The numbers that actually distinguish it
Two figures carry most of the weight.
The first is 8 hours. AWS Lambda, the obvious place an engineer would first try to host an agent, caps a single execution at 15 minutes. For a chatbot that returns in two seconds, that's irrelevant. For an agent that researches for an hour, waits on a human approval, then resumes — the durable, long-horizon workloads agents are actually being pointed at — 15 minutes is a wall you hit on day one. AgentCore's 8-hour ceiling is roughly 32× longer, and that single number is most of why the Runtime exists as a separate product instead of a Lambda blueprint.
The second is the isolation model. Each session runs in its own Firecracker microVM — its own kernel, hardware-isolated memory — that is destroyed and sanitized when the session ends. The security boundary is the hypervisor, not OS-level networking rules. If you've ever worried that your container is not a sandbox, this is the answer phrased as infrastructure: one tenant, one microVM, gone at hangup.
The 8-hour ceiling tells you what AgentCore is for. The per-session microVM tells you who it's selling to: enterprises that need the isolation in writing.
Then there is the bill, which is where it gets genuinely novel and genuinely annoying at the same time. Runtime, Browser, and Code Interpreter bill per second on two axes — vCPU-hours (around $0.0895) and GB-memory-hours (around $0.00945) — and crucially, idle and I/O-wait CPU is not charged. Because agentic workloads spend an estimated 30–70% of wall-clock time waiting on model and tool calls, paying for CPU only when it's actually computing is a structurally different cost model from an always-on container that bills whether it's thinking or blocking. The catch: the platform spans roughly a dozen separate billing dimensions across the seven services, which is why a small industry of third-party AgentCore cost calculators sprang up within weeks of GA. The cost model is fairer and harder to predict at the same time. (Treat the exact rates as indicative and check the live pricing page; AWS rates drift and vary by region.)
Why the neutrality is the point
Here's the strategic read. AWS already tried selling a more opinionated agent product — the original Bedrock Agents, where you configured the agent inside AWS's own abstraction. AgentCore is the admission that developers don't want to author their agent in your console. They want to write it in LangGraph or CrewAI or AWS's own open-source Strands SDK, point it at whatever model is winning this quarter, and have somewhere reliable to run it. AgentCore wraps your existing agent — you don't rebuild it.
So AWS retreated to the layer it has always been strongest at and that has the longest shelf life: undifferentiated heavy lifting. Memory, identity, a place to run an 8-hour process, an MCP-native tool gateway, the telemetry to debug it. None of that depends on which model is state of the art, which means none of it goes stale when the leaderboard turns over.
That is the cleanest contrast in the agent-platform market right now. OpenAI's AgentKit bet on owning how you author an agent — and deprecated its visual centerpiece eight months after launch. AgentCore bet on owning where the agent runs, and stayed deliberately blank about everything above the runtime. The lock-in is real either way; with AgentCore it lives in the AWS operations plane — CloudWatch, IAM, VPC, the billing — rather than in your model choice. The question to ask before adopting it isn't "is this the best agent platform." It's "am I comfortable making AWS my agents' operating system." If the answer is yes, the neutrality above that line is exactly what you want. If it's no, the same neutrality makes it unusually easy to keep your agent code and walk.



