Amazon Bedrock AgentCore - architecture, components, and pricing
If you want the wider context, AgentCore is the managed runtime layer beneath the AWS Loom platform and one of the answers to agent sprawl. Here we focus on AgentCore itself: its architecture and its cost.
What is Amazon Bedrock AgentCore?
Bedrock AgentCore is a set of managed, composable AWS services for building, deploying, and operating AI agents in production. The key word is composable: it is not one monolithic “agent product”, but several independent services you can use together or selectively. Each one can be adopted on its own, with no commitment to the whole.
Two things worth settling up front:
- AgentCore is framework-neutral. It works with Strands Agents, LangGraph, CrewAI, Google ADK, and others. It does not force a single SDK.
- AgentCore is model-neutral. You do not have to use Bedrock models - you can point it at a model outside AWS. Bedrock is the default, not a requirement.
In practice, AgentCore is an “agent infrastructure as a service” layer: you bring your agent logic and get a ready-made runtime, tool access, memory, identity, and telemetry, without standing that up yourself on EC2 or EKS.
The sources we reference: the Amazon Bedrock AgentCore page and the AgentCore documentation.
AgentCore components
AgentCore consists of several services you can combine as needed. Here is what each one does.
| Component | Role | When you need it |
|---|---|---|
| Runtime | Serverless, isolated execution environment for the agent, with long-running sessions and per-session isolation | Always - it is the core the agent runs on |
| Gateway | Turns APIs, Lambda functions, and MCP servers into tools the agent can use, with a single access-control point | When the agent uses tools and external APIs |
| Memory | Short- and long-term memory (session context plus knowledge persisted across sessions) | When the agent needs to remember conversation or user context |
| Identity | Agent identity and permission propagation - the agent acts on behalf of the user, within their access scope | When the agent reaches data or systems on behalf of a user |
| Observability | Tracing, metrics, and insight into the agent's decisions, integrated with CloudWatch | Always in production - without it you cannot audit or debug |
| Browser | A managed, isolated browser for the agent's web tasks | When the agent has to click through and navigate pages |
| Code Interpreter | An isolated environment for the agent to execute code | When the agent generates and runs code (data analysis, calculations) |
The most important architectural observation: Runtime and Observability are the foundation you will use almost every time. The rest is optional and chosen per use case. A simple Q&A agent may need only Runtime + Observability. An agent that reaches internal systems and remembers context adds Gateway, Memory, and Identity. That is exactly what “composable” means.
How the components fit together
A typical flow for a production agent looks like this:
- Runtime runs the agent logic (written in e.g. Strands) in an isolated session.
- The agent calls a model - by default through Amazon Bedrock, optionally a model outside AWS.
- When the agent needs a tool (API, Lambda, MCP server), it goes through Gateway, which acts as a single access-control point.
- Memory supplies session context and knowledge persisted across sessions.
- Identity makes sure the agent acts with the user’s permissions, not its own over-broad ones.
- Observability collects traces and metrics for every step, so you can answer “which agent, did what, at what cost, and why”.
If searching internal documents (RAG) is in play, a vector-search layer sits underneath - and that is where the budget can surprise you. We return to it in the cost section. We laid out the RAG architecture itself in a separate article on RAG architecture on AWS.
Designing an agent on AgentCore and sizing the TCO?
Book a free 30-min call
What AgentCore costs - the cost model
AgentCore is billed by consumption: you pay for what you use, per component. There is no license fee for “AgentCore” as such - the cost is the sum of usage across the individual services plus the cost of model inference in Bedrock (billed separately, per token).
The cost of a production agent is made up of several layers:
| Cost layer | Billing model | Budget note |
|---|---|---|
| Runtime | For consumption of execution resources (session time and resources) | Scales with the number and length of agent sessions |
| Gateway | For tool calls passing through the gateway | Grows with the number of tool calls per session |
| Memory | For memory stored and processed | Long-term per-user memory can accumulate |
| Observability | Through CloudWatch (logs, metrics, traces) | Telemetry volume = cost; easy to underestimate |
| Model inference | Bedrock, per token (input + output), depending on the model | Usually the single biggest item at high traffic |
| Vector search (if RAG) | Most often OpenSearch Serverless - a fixed cost for minimum OCUs | This item surprises people most often - see below |
The line item almost everyone leaves out
If the agent does RAG (searches internal documents), there is usually OpenSearch Serverless underneath as the vector store. And OpenSearch Serverless has a minimum, fixed cost for OCUs (OpenSearch Compute Units) - on the order of a few hundred dollars a month for a minimal configuration, regardless of traffic. Even an agent that has not served a single query still generates that cost as long as the vector collection exists.
It is the most commonly underestimated line item in agent budgets, because everything else is consumption-based (“I pay for what I use”) while this one is a fixed entry threshold. With a single agent it is bearable. With ten separate vector collections it is a real sum that flows every month regardless of usage.
The practical FinOps takeaway: consolidate vector search wherever you can, instead of standing up a separate collection for every agent. It is exactly the same mechanism we described with agent sprawl - the cost comes from fragmentation, not from a single service.
AgentCore and Loom - how they relate
Briefly, because it is a common question: AgentCore is the managed building blocks (runtime, gateway, memory, identity, observability). Loom is an opinionated governance layer on top of them (UI, lifecycle, tagging, registry, human-in-the-loop).
In other words: you can use AgentCore without Loom - and for many teams that is the most sensible start (managed services plus a thin governance layer of your own). Loom adds a ready-made paved path, but as AWS Labs reference code that you take on to maintain. We laid out the full “adopt Loom, adapt it, or pick an alternative” analysis in the article on AWS Loom.
When AgentCore makes sense, and when it does not
| AgentCore fits when... | AgentCore is worth reconsidering when... |
|---|---|
| You want to run an agent in production without standing up your own runtime on EC2/EKS | You already have a mature, in-house agent runtime that meets your requirements |
| You value framework and model neutrality (Strands, LangGraph, a model outside AWS) | You are deliberately multi-cloud and do not want a runtime layer tied to AWS |
| You need ready-made identity, memory, and observability without writing them from scratch | Your use case is simple enough that managed components are overkill |
| You want to pay by consumption and see cost per component | You have steady, predictable volume where your own infrastructure is cheaper in TCO |
For a comparison of the model layer itself - Bedrock vs SageMaker vs self-hosting on EKS - we have a separate, detailed article on running LLM inference on AWS.
When it is worth bringing in an external partner
- Cost model and TCO. Consumption billing per component plus the fixed vector-search cost is hard to estimate without experience - and it drives the budget.
- Identity and least-privilege design. An agent acting on behalf of a user, with access to production data, needs a properly designed Identity layer.
- The choice: AgentCore, Loom, or your own layer. It is an architectural decision with a long maintenance tail, not a one-off deployment.
- RAG and vector-cost consolidation. Collapsing scattered collections into one shared layer is often the fastest return in an agent budget.
Summary
Bedrock AgentCore is a set of managed, composable services for running AI agents in production: Runtime and Observability as the foundation, with Gateway, Memory, Identity, Browser, and Code Interpreter chosen per use case. Framework- and model-neutral, billed by consumption.
Three things to remember:
- These are composable services, not a monolith. Use only the components you actually need - a simple agent is often just Runtime + Observability.
- Cost is the sum of the layers plus per-token inference in Bedrock. At high traffic, inference is usually the biggest item.
- Watch the fixed vector-search cost (OpenSearch Serverless) with RAG - a few hundred dollars a month regardless of traffic, per collection. Consolidate instead of multiplying.
Designing an agent on AgentCore and sizing the TCO?
Book a free 30-minute call. We help teams design an agent architecture on Bedrock AgentCore, estimate the real cost per component, and avoid underestimated line items like the fixed cost of vector search.
