Most AI agent prototypes work fine in a notebook and fall apart the moment real users show up. The prompt logic is not the hard part. The hard part is session isolation, credential handling, tool permissions, memory that survives a restart, and knowing why an agent failed at 2 a.m. without digging through logs.
Amazon Bedrock AgentCore exists specifically for that production gap. It is a modular platform for building, deploying, connecting, securing, observing, evaluating, and optimizing AI agents at scale, without requiring teams to build and operate all of that supporting infrastructure themselves.
This guide covers what AgentCore actually is, how its pieces fit together, where it differs from other Bedrock capabilities, and what matters when you move an agent from a working demo to something running in production.
What Amazon Bedrock AgentCore Actually Is ?
AgentCore is a modular, framework-agnostic platform for deploying and operating AI agents in production. It is not a single service. It is a set of composable AWS services, including a managed runtime, memory, tool integration, identity, observability, and several supporting components, that you can adopt individually or together.
The framework independence matters more than it sounds. AgentCore works with agents built on LangGraph, CrewAI, LlamaIndex, Strands Agents, Google's ADK, the OpenAI Agents SDK, or custom code, and with models from Amazon Bedrock, OpenAI, Google Gemini, Anthropic, or other providers. You are not locked into a specific agent framework or a specific model family to use it. AgentCore reached general availability on October 13, 2025, following its July 2025 preview, and AWS has continued expanding the platform since then.
The core idea is simple: modern frameworks have made it much easier to build agents that reason, call tools, and maintain conversational state, but operating those agents reliably for many concurrent users is a different problem. Production systems still need isolated execution, identity, controlled tool access, persistent state, observability, evaluation, and operational safeguards. AgentCore is designed to address those production concerns while preserving flexibility in the frameworks and models you use.
Bedrock vs. AgentCore: Two Different Layers
Amazon Bedrock and Amazon Bedrock AgentCore solve different problems, even though they share a name and often get confused.
Bedrock is the foundation model and managed AI capabilities layer. It gives you access to models like Anthropic's Claude and Amazon's Nova, along with capabilities such as Knowledge Bases for retrieval, Guardrails for content controls, and Amazon Bedrock Agents, a low-code way to configure an agent rather than write one.
Amazon Bedrock AgentCore is the newer modular agentic platform for building and operating production agents. AgentCore Runtime lets you deploy custom agent code and orchestration using frameworks of your choice, while AgentCore Harness provides a managed, configuration-driven orchestration layer where you declare the model, tools, skills, and instructions instead of implementing the agent loop yourself.
| Amazon Bedrock | Amazon Bedrock AgentCore | |
| Purpose | Access to foundation models and managed AI capabilities | Infrastructure for running custom-built agents in production |
| You control | Prompts, model choice, and managed AI configurations | Agent framework, orchestration logic, execution flow |
| Orchestration | Managed orchestration through Bedrock agent capabilities | Flexible: custom orchestration with your framework, or managed orchestration with AgentCore Harness |
| Best fit | Fast, low-code agents; simple internal tools | Custom multi-agent systems needing fine-grained control |
You do not have to choose one over the other in every situation. A team that wants a fast, low-code agent for an internal tool might reasonably use Amazon Bedrock Agents. A team building a custom multi-agent system that needs fine-grained control over reasoning, tool routing, and session behavior is the team AgentCore is built for. AWS positions AgentCore as its purpose-built platform for deploying and operating production agents at scale.
How AgentCore Works: The Components That Matter Most
AgentCore is made up of several services. Rather than listing every component, it helps to understand the services that matter most in a typical production architecture. One caveat applies to all of them: AgentCore can scale the agent itself, but the downstream APIs, databases, and third-party services it calls can still become the real bottleneck, since their own rate limits and concurrency caps do not scale just because your agent traffic did.
AgentCore Runtime is the execution environment, and it is the piece most teams adopt first. By default, each session runs in an isolated, serverless microVM with its own CPU, memory, and filesystem, so one user's session cannot see or interfere with another's, and MicroVM-based sessions can run for up to eight hours, while the Instances compute type supports sessions of up to 14 days. Runtime also offers an Instances option that runs agents on managed EC2 in your own account, useful for sustained, GPU-backed, or multi-day workloads that outgrow the microVM's session limit. Pick microVMs for lightweight, fast-scaling workloads that complete within hours, and Instances for long-running, stateful, collaborative, or GPU-backed workloads.
AgentCore Gateway is a single, secure entry point for agentic traffic, and it does more than convert tools. It turns APIs, Lambda functions, and OpenAPI specs into Model Context Protocol (MCP) tools, proxies requests directly to other agents and HTTP services, and routes inference calls across multiple model providers through one endpoint. New tools become available through the Gateway endpoint without redeploying the agent itself, and Gateway handles both the authentication an agent needs to call a target and any authentication the target needs to reach the underlying system.
AgentCore Memory gives agents persistent context. It supports short-term conversational memory and long-term memory strategies that can extract and retrieve durable facts, summaries, preferences, and episodic information across sessions, and a memory resource can also be used by multiple agents when the architecture requires shared memory. This is what makes an agent capable of remembering a user's preferences from last week instead of starting from zero every session.
AgentCore Identity provides authentication and authorization capabilities for agent workloads and their interactions with users and external services. It integrates with existing identity providers such as Amazon Cognito, Okta, and Microsoft Entra ID, and it manages outbound credentials so an agent can securely act against third-party services like Slack or GitHub on a user's behalf, without holding a raw long-lived secret.
AgentCore Observability gives you a trace of what the agent actually did: which tools it called, in what order, with what inputs and outputs, and where time was spent. AgentCore provides observability through Amazon CloudWatch, including service-provided metrics and, when enabled, traces and logs. It also supports OpenTelemetry, including ADOT, for teams that want to integrate AgentCore telemetry with an existing observability stack.
AgentCore also provides capabilities such as Browser, Code Interpreter, Policy, and Harness for specialized production requirements. Most production architectures will not touch every component. They will typically combine Runtime, Gateway, Memory, and Identity, then add Observability once the agent is handling real traffic.
AgentCore Runtime vs. AgentCore Harness
Runtime and Harness are often confused because both host agents, but they sit at different levels of control. Runtime is the lower-level option: you bring your own agent code and orchestration logic, written with whichever framework you chose, and AgentCore provides the managed execution environment underneath it. Harness sits a level higher. It gives you a managed orchestration loop, defined through a single API call with a model, system prompt, and tools, so you do not have to implement the reasoning loop yourself, and it runs on the same underlying Runtime infrastructure.
The choice comes down to how much control you need. Pick Runtime when you need full control over framework, orchestration logic, or a custom multi-agent setup. Pick Harness when you want to move faster and a standard agent loop is enough, without giving up the session isolation and managed infrastructure Runtime already provides underneath it.
AgentCore vs. Knowledge Bases: Not Competing Services
A common point of confusion is whether AgentCore replaces Amazon Bedrock Knowledge Bases. It does not, since they solve different layers of the same problem.
Knowledge Bases is a managed retrieval-augmented generation (RAG) service. It handles connecting to data sources, chunking and embedding documents, managing a vector store, and retrieving relevant context at query time. Its job is making your organization's documents queryable by a model.
AgentCore is the runtime and operational layer for the agent that uses that retrieved context to reason and act. In practice, Knowledge Bases can be integrated with an AgentCore-based agent as a retrieval capability or tool; Gateway can be used when exposing the relevant capability through an agentic interface, so the agent can call it the same way it calls any other tool. You are not choosing between the two. A well-built enterprise agent commonly uses both: Knowledge Bases for grounding responses in your data, and AgentCore for everything involved in running that agent securely and reliably in front of real users.
A Practical Production Architecture
Consider a hypothetical scenario: an internal support agent for a mid-size software company that answers employee questions from internal documentation, looks up ticket status in an existing helpdesk system, and escalates certain requests to a human. This is a hypothetical example to illustrate architecture, not a real deployment or customer story.
The agent runs on Runtime, with each employee session isolated from every other. It reaches internal documentation through Amazon Bedrock Knowledge Bases and accesses the helpdesk system through a REST API exposed through Gateway, so no custom integration code is needed for either. Identity authenticates the employee and brokers the credentials the agent needs to call the helpdesk API on their behalf, so no static API key ever sits in the agent's code. Memory means a follow-up the next day does not require the employee to repeat context, and Observability traces every tool call, which matters the first time someone reports that the agent returned the wrong ticket status.
This is where the difference between a prototype and a production system becomes concrete. A prototype can hardcode an API key and skip session isolation entirely. A production deployment handling real employee data across a whole company cannot.
Figure : A simplified request flow through AgentCore Runtime, Gateway, Memory, Identity, and Observability in a production agent architecture.
Security: What AgentCore Handles and What It Does Not
AgentCore provides meaningful security infrastructure, but it does not make an agent immune to AI-specific risks. Treating it as if it does is a mistake worth naming directly.
What AgentCore genuinely strengthens: session isolation prevents one user's data or state from leaking into another's session. Identity separates the agent's own workload identity from the end user's, scopes permissions precisely instead of granting broad standing access, and brokers short-lived credentials for third-party services instead of embedding static secrets. AgentCore Policy lets you define fine-grained authorization rules for agent actions using Cedar, with the Gateway policy engine able to evaluate those rules and allow or deny tool calls before they execute. VPC support and AWS PrivateLink, available since general availability, can provide private network connectivity and reduce exposure to the public internet.
None of that solves prompt injection. If an agent reads untrusted content, a webpage through the Browser tool, an email, a document from a knowledge base, that content can contain instructions trying to manipulate its behavior. AgentCore's controls reduce the blast radius of a successful injection by constraining what tools and permissions are reachable in the first place. They do not detect or prevent the injection itself. That still requires input validation, careful system prompt design, and treating any tool that can take a consequential action (sending money, deleting data, sending external communications) as one that needs explicit confirmation or human review, not just a tool the agent has technical access to call.
When AgentCore Makes Sense
AgentCore is a strong fit when you are moving a working agent prototype toward production and need real session isolation, tool governance, and observability, when you want framework flexibility instead of being locked into a single vendor's orchestration model, or when you are building an internal agent platform that multiple teams will build on top of and need centralized identity and policy control.
It is likely overkill for a simple, low-traffic internal tool where Amazon Bedrock Agents gets you to a working result faster, or for early-stage prototyping where you are still validating whether the concept works before investing in production infrastructure.
Conclusion
Start with Runtime and Identity if session isolation and access control are the immediate problem, then add Gateway once tool sprawl becomes a maintenance burden, and treat Observability as non-negotiable the moment real users are involved, since debugging an agent's decisions after the fact without a trace is close to impossible. AgentCore uses usage-based pricing across its components, so production cost should be evaluated alongside model inference, tool usage, and observability costs, not assumed to be free just because the platform itself has no upfront fee.
The infrastructure AgentCore provides removes a genuine category of engineering work. It does not remove the need for careful thinking about what an agent is allowed to do, and under what conditions, once it is turned loose on real data and real systems.
Frequently Asked Questions (FAQs)
- Is Amazon Bedrock AgentCore the same as Amazon Bedrock Agents?
No. Amazon Bedrock Agents is a configuration-driven, low-code way to build an agent within Bedrock's own orchestration model. AgentCore is a separate, framework-agnostic infrastructure platform for running custom-built agents in production, with its own runtime, memory, identity, and observability services.
- Does AgentCore require using Amazon Bedrock foundation models?
No. AgentCore works with models from Amazon Bedrock as well as OpenAI, Google Gemini, and other providers, and with open-source agent frameworks including LangGraph, CrewAI, LlamaIndex, and Strands Agents. You are not required to use Bedrock-hosted models to use AgentCore.
- Does AgentCore protect against prompt injection?
Not directly. AgentCore's isolation, identity, and policy controls limit what an agent can do and reduce the damage a successful attack can cause, but they do not detect or block prompt injection itself. Input validation, careful tool permissioning, and human review for sensitive actions are still necessary on top of AgentCore's infrastructure controls.
