Amazon Bedrock AgentCore, Explained

Part of a series on running AI workflows across model providers — this one covers AWS's answer to a question every agent-building team eventually asks: who handles all the infrastructure around the model?

In July 2025, AWS published a post titled "Introducing Amazon Bedrock AgentCore: Securely deploy and operate AI agents at any scale," and it's worth reading the title literally — AgentCore isn't a smarter model or a new agent framework. It's the infrastructure underneath one: session management, memory, identity, observability, and secure tool access, all as separately billed, composable services, so a team building an agent doesn't have to build that plumbing themselves.

What problem AgentCore is actually solving

Building a single AI agent demo is easy. Running one in production, safely, at scale, is a different problem entirely — you need somewhere to run the agent's code with proper isolation between users, a way to remember context across a long-running session, a way to grant the agent access to internal tools and third-party services without hardcoding credentials, a way to see what the agent actually did when something goes wrong, and a way to let the agent browse the web or run generated code without that turning into a security incident. AWS's framing is that most teams spend months building this scaffolding before they can ship anything agent-specific — AgentCore packages it as ready-made services instead.

The seven services, plainly

Seven separately billed, composable services — you use the ones your agent actually needs, not a fixed bundle.

Real dates, since this launched recently and is still moving

AgentCore was announced in preview on July 16, 2025. A free trial period ran through mid-September 2025, after which standard AWS consumption-based pricing began. It reached general availability on October 13, 2025, adding VPC and AWS PrivateLink connectivity, CloudFormation support, and resource tagging — the features enterprise security teams typically require before approving production use. At GA, AgentCore Runtime also gained support for the Agent-to-Agent (A2A) protocol and extended execution windows up to eight hours, and the service launched across nine AWS regions spanning North America, Asia Pacific, and Europe.

It isn't locked to AWS-native agents

This is the detail that surprises people: AgentCore explicitly supports open-source agent frameworks — Strands Agents, LangChain, LangGraph, LlamaIndex, and CrewAI are named directly in AWS's own documentation — and works with foundation models "in or outside of Amazon Bedrock," including OpenAI's and Google's models, not just Amazon's own. AWS's pitch isn't "switch to our framework," it's "run whatever framework you're already using on infrastructure that handles the operational parts for you."

A single request touches several AgentCore services on its way through — each one replacing infrastructure a team would otherwise build itself.

How billing actually works

AgentCore uses consumption-based pricing with no upfront commitment — you pay for what you use, and each service is billed independently. Runtime billed as microVMs charges only for active CPU and memory, with idle time free; Runtime billed as instances charges the underlying EC2 cost plus a management fee. AWS's own reasoning for this model is that agentic workloads typically spend a large share of their time — by AWS's estimate, 30 to 70 percent — waiting on I/O (a tool call, an API response, a human approval) rather than actively computing, and per-second consumption billing avoids paying for that idle waiting the way a fixed-capacity server would.

A real use case: an internal support agent that needed real tool access

A software company building an internal IT-helpdesk agent didn't need a new model — they needed the agent to actually do things: look up a ticket in their existing ticketing system, check a user's account status in an internal admin tool, and post an update to a Slack channel, all without giving the agent's code direct, hardcoded credentials to any of those systems. AgentCore Gateway turned their existing internal APIs into agent-callable tools without custom glue code, and AgentCore Identity handled the OAuth flow into Slack, so the agent authenticated with scoped, revocable access rather than a shared secret sitting in a config file. The framework running the actual agent logic didn't need to be AWS-specific — the value was entirely in not having to build the tool-access and identity layer themselves.

Frequently asked questions

Is AgentCore required to use Bedrock's models?

No — you can call Bedrock's foundation models directly through the standard API without touching AgentCore at all. AgentCore is specifically for the agent-infrastructure layer around a model, not the model call itself.

Does AgentCore replace agent frameworks like LangGraph or CrewAI?

No — it explicitly supports them. AgentCore is the infrastructure layer underneath a framework, not a competing framework.

Do I have to use every AgentCore service?

No. Each of the seven services is separately billed and composable — a team might use only Runtime and Observability and skip the rest.

Is AgentCore only for models hosted on Bedrock?

No — AWS's own documentation states it supports foundation models "in or outside of Amazon Bedrock," including models from other providers.

The Bottom Line

Next in this series: what happened to the original "Bedrock Agents" feature now that AgentCore exists, and a real deadline every team still using it should know about.

Read part four: Bedrock Agents Classic Is Being Retired. Explore dnotifier.com.