Amazon Bedrock AgentCore is AWS’s answer to a problem most teams hit about three weeks after their first AI agent demo: the prototype works, and now nobody knows how to run it in production. Where does the agent live? Who hands it credentials? What happens when 10,000 sessions arrive at once? AgentCore is a set of managed services that answers those questions so you don’t have to build the plumbing yourself. This post is a high-level tour: what it is, what each service does, what it costs, and my honest take on when it’s worth adopting.
What Is Amazon Bedrock AgentCore?
AgentCore is AWS’s platform for deploying and operating AI agents at scale. It went into preview in July 2025 and reached general availability on October 13, 2025. Since then it has grown fast: as of mid-2026, the official docs list thirteen modular services under the AgentCore umbrella.
Two design choices define it, and both are worth pausing on.
First, it’s framework-agnostic and model-agnostic. You can bring agents built with LangGraph, CrewAI, LlamaIndex, Strands Agents, the OpenAI Agents SDK, or your own custom loop. You can call Claude, Nova, GPT, Gemini, Llama, or anything else, hosted on Bedrock or not. That’s a quiet admission from AWS that the orchestration layer got commoditized. The frameworks are free and interchangeable; the hard, valuable part is secure hosting, identity, memory, and observability. AgentCore sells exactly that part.
Second, it’s modular. Every service works independently. You can use Gateway to expose your APIs as agent tools while hosting the agent itself anywhere, or use Memory from an agent running on your own Kubernetes cluster. Nothing forces you to go all-in, which is rare for a cloud platform and genuinely useful.
The AgentCore Services, Grouped by Job
Thirteen services is a lot to hold in your head, so here’s the mental model I use: four jobs. Run the agent, connect it to the world, govern it, and watch it.
Run the agent
- Runtime is the core: a serverless environment purpose-built for agents. Each session runs in its own isolated microVM, cold starts are fast, and long-running asynchronous work is supported. You bring a container; AWS handles scale.
- Harness is the newer, higher-level option: a managed agent loop you invoke with a single API call. You specify a model, a system prompt, and tools inline, and Harness handles orchestration, tool execution, and memory. Sessions get filesystem and shell access inside a microVM. It’s the closest thing AWS offers to “just give me an agent.”
Connect it to tools and data
- Gateway converts your existing APIs, Lambda functions, and OpenAPI specs into Model Context Protocol (MCP) tools that any compatible agent can call. This is the service I’d adopt first: it makes years of existing backend work usable by agents without rewrites.
- Memory gives agents short-term conversational context and long-term memory that persists across sessions, including episodic memory that lets agents learn from past runs.
- Identity handles who the agent is and what it may access, plugging into Cognito, Okta, or Entra ID, and managing OAuth flows to third-party services like Slack and GitHub.
- Browser and Code Interpreter are managed sandboxes: a cloud browser for web interaction (Playwright-compatible) and an isolated environment for executing Python, JavaScript, or TypeScript the agent writes.
Govern it
- Policy intercepts every Gateway tool call and checks it against rules you write in natural language or Cedar. Think “agents may issue refunds up to $100; anything larger needs a human.” This is deterministic control, not a prompt asking the model nicely.
- Registry is a governed internal catalog of agents, MCP servers, and tools, with review and approval workflows.
- Evaluations scores agent quality with thirteen pre-built evaluators (correctness, safety, tool-selection accuracy, goal success) and can sample live traffic continuously.
- Optimization and Payments round things out: AI-suggested config improvements validated by A/B tests, and x402-protocol micropayments so agents can pay for APIs.
Watch it
- Observability traces every reasoning step, tool call, and model interaction in OpenTelemetry format, stored in CloudWatch. When an agent does something weird in production (it will), this is how you find out why.
What Deploying on Amazon Bedrock AgentCore Looks Like
The developer experience is deliberately thin. You wrap your existing agent function, whatever framework it uses, in a small adapter and deploy it with the starter toolkit:
from bedrock_agentcore.runtime import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
@app.entrypoint
def invoke(payload):
user_message = payload.get("prompt")
# your agent logic here: LangGraph, Strands, CrewAI, custom...
return {"result": run_my_agent(user_message)}
app.run()
That entrypoint becomes a session-isolated endpoint that scales on demand. Identity, memory, and tracing attach through configuration rather than code. Compare that with what the same capability costs to self-build: a queue, a container fleet, a secrets manager, session state storage, and a tracing pipeline, all before your agent does anything useful.
How AgentCore Pricing Works
Pricing is consumption-based with no upfront commitment, and the headline numbers from the official pricing page are reasonable. Runtime, Browser, and Code Interpreter bill at $0.0895 per vCPU-hour and $0.00945 per GB-hour, in per-second increments. The detail I like most: I/O wait and idle time are free. Agents spend most of their wall-clock time waiting on model responses, so billing only active CPU is the difference between a fair bill and a padded one.
The other services bill on their own units. Gateway costs $0.005 per 1,000 tool invocations. Memory runs $0.25 per 1,000 short-term events and $0.75 per 1,000 long-term records per month. Policy authorization checks are $0.000025 per request. Observability bills through standard CloudWatch rates.
Now the criticism: that’s more than a dozen independently billed components across different units (vCPU-hours, invocations, records, tokens, requests). No single line item is expensive, but estimating a real workload’s monthly bill requires modeling every service you touch. If you adopt AgentCore seriously, build a cost model early and watch it for the first month. Nobody enjoys surprise line items, and this bill has many places to hide them.
Who’s Actually Running It
According to AWS’s own numbers, the AgentCore SDK passed two million downloads within five months of preview. More interesting are the named production stories. CloudZero, working with Caylent, migrated off the older Bedrock Agents and reports responses five times faster, with time-to-first-token dropping from 30-plus seconds to 2 to 4 seconds per step. S&P Global Market Intelligence uses Memory as the shared state layer across hundreds of specialized agents. The PGA TOUR built a multi-agent system that drafts articles for its digital platforms.
The usual caveat applies: these are AWS-published case studies, so treat them as best-case numbers. But they do show the platform holding up beyond demos.
AgentCore vs. the Old Bedrock Agents
Don’t confuse AgentCore with “Agents for Amazon Bedrock,” the older feature. That was a closed box: Bedrock models only, AWS’s orchestration only, configured through the console. AgentCore inverts the model. It assumes you build the agent however you want and provides infrastructure primitives around it. The CloudZero migration above is one data point that the new approach is a real upgrade, not a rename.
Should You Use It?
My take, having watched the agent-infrastructure space closely: AgentCore makes sense if you’re on AWS and moving agents from prototype to production, especially if session isolation, enterprise identity, or audit trails are requirements you can’t dodge. Gateway alone justifies a look, because turning existing APIs into MCP tools is tedious work nobody wants to hand-roll.
Skip it, or wait, if you’re still experimenting on a laptop. A self-hosted stack is cheaper at tiny scale and teaches you what the managed services abstract away. We run one ourselves, described in our OpenClaw overview, and there are open-source AWS reference designs like Loom for AWS that occupy the middle ground. The trade is the usual one: managed convenience against portability and cost transparency. AgentCore’s modularity softens the lock-in, but CloudWatch-native observability and Cedar policies don’t move clouds with you.
FAQ
Does AgentCore require Amazon Bedrock models?
No. Runtime and Harness work with any foundation model, including OpenAI and Gemini models hosted outside AWS.
Is there a free tier?
There’s no permanent AgentCore free tier, but new AWS customers get up to $200 in Free Tier credits, and preview services like Registry currently include free monthly allowances.
Which services are still in preview as of August 2026?
Policy, Evaluations, Registry, and Payments launched in preview (Policy and Evaluations at re:Invent 2025). Check the docs for current status before betting production workloads on them.
Can I use just one AgentCore service?
Yes. Every service works standalone. Using Gateway or Memory with an agent hosted elsewhere is a supported, sensible pattern.
The Bottom Line
Amazon Bedrock AgentCore is AWS betting that agent infrastructure, not agent frameworks, is where the production value sits. Based on what’s shipped since GA, that bet looks right. Start with Gateway, price out Runtime for one real workload, and keep your cost model honest. If you want a second opinion on your agent architecture before committing, the comment section is open, and our earlier deep-dives on agent deployment patterns on AWS are a good place to compare notes.
Disclosure: illustrations and diagrams in this post are AI-generated.
