On July 30, 2026, Amazon Bedrock Agents, the service AWS launched in 2023 for building tool-using AI agents, closes to new customers. AWS has renamed it Bedrock Agents Classic and pointed everyone at its successor. If your team demoed an agent prototype this quarter, someone is about to ask you what it should actually run on in production. The answer AWS wants you to reach is Amazon Bedrock AgentCore.
That deadline is a good excuse to understand AgentCore properly, because it is not a bigger version of the old Agents service. It is a different idea. Agents Classic was a builder: you configured an agent inside the AWS console and AWS ran it its way. AgentCore is a platform: you bring an agent you built with any framework (LangGraph, CrewAI, Strands, or plain code) calling any model, hosted on Bedrock or not, and AgentCore provides the production infrastructure around it. This post walks through that infrastructure component by component, then follows a real request through the whole system, and looks at how it fails.
The big picture
The problem AgentCore addresses is easy to state. Building an agent takes an afternoon. Running one in production means solving session isolation, persistent memory, credential handling for tool calls, converting your existing APIs into tools, tracing non-deterministic behavior, and stopping the agent from doing things it should not. None of that is agent logic. All of it is mandatory.
AgentCore packages those concerns as composable services that work together or independently: Runtime hosts the agent, Memory gives it persistent knowledge, Gateway connects it to tools, Identity governs who can call what, Code Interpreter and Browser are managed built-in tools, Observability traces everything, and the newer Policy and Evaluations services govern behavior and measure quality. A managed abstraction called the harness wires the primitives together for teams who want an agent running with two API calls.
The design bet is worth naming before the details: AWS decided the framework wars are not theirs to win. Rather than pushing a proprietary agent definition like Agents Classic did, AgentCore is deliberately un-opinionated about how you build the agent and treats everything around it as the product.
Runtime: one session, one microVM
Runtime is where your agent code lives. You package your agent as a container, and Runtime deploys it as a serverless, auto-scaling endpoint. So far, that sounds like AWS Lambda with extra steps. The differences are exactly the properties agents need and Lambda lacks.
The first is the isolation model. Each user session runs in a dedicated Firecracker microVM with its own isolated CPU, memory, and filesystem, the same virtualization technology that underpins Lambda itself. One session equals one microVM. When the session ends, the entire microVM is terminated and its memory sanitized. This is a deliberately stronger boundary than shared containers, and the reason is specific to agents: an agent holds a user's conversation, their retrieved documents, and their credentials in working state, while executing model-generated behavior that is not fully predictable. MicroVM isolation makes cross-session contamination structurally impossible rather than merely unlikely.
The second difference is statefulness. A Lambda function terminates after each request. A Runtime session persists: it is identified by a runtimeSessionId that your application provides on the first invocation, and subsequent invocations with the same ID are routed to the same microVM, preserving in-memory state, environment variables, running processes, and filesystem contents. Sessions move through three states: Active while processing, Idle while holding context between invocations, and Terminated. A session ends after 15 minutes of inactivity or upon reaching its maximum lifetime of 8 hours. That 8-hour ceiling is not a rounding error in the design; it exists because real agent workloads include long-running research tasks and multi-step workflows that no request-scoped compute model can host.
Deployment mechanics follow familiar AWS patterns. Every update to an agent creates an immutable version, and named endpoints point at versions, so promoting to production or rolling back is a matter of repointing an endpoint, with no downtime. Billing is consumption-based on what the agent actually computes, which suits agents well because they spend much of their life waiting on model responses and API calls rather than burning CPU.
Memory: events in, records out
A microVM gives a session continuity, but everything in it dies with the session. Memory is the service that survives. Its architecture is a two-tier pipeline, and understanding the tiers separately is the key to using it well.
Short-term memory is raw material. Each interaction is written as an event via CreateEvent, tagged with two identifiers: a sessionId scoping the conversation and an actorId scoping the user or agent-user pair. Events are complete, unprocessed exchanges with a configurable retention period, and they let an agent replay conversation context within and across invocations.
Long-term memory is refined output. Asynchronously after events land, an extraction process powered by an LLM analyzes them and produces memory records according to the memory strategies you configure. The built-in strategies map to different kinds of note-taking: semantic memory extracts facts and knowledge, user preferences builds a persistent profile of choices and styles, and summarization condenses sessions. Custom strategies let you override prompts and models for the extraction itself. Records are stored under namespaces you define, and retrieval is semantic search over them. In December 2025 AWS added an episodic capability, which extracts records of what the agent did and how it went, letting agents learn from prior task executions rather than only prior conversations.
Two operational facts matter more than any feature list. First, if you configure no strategies, no long-term extraction happens at all; short-term events simply expire. Second, extraction is asynchronous with a real delay (on the order of a minute), so an agent cannot write a fact and retrieve it as a long-term record in the same breath. Design around eventual consistency or read recent events directly.
Gateway: your APIs, dressed as tools
An agent without tools is a chatbot. The industry's answer to tool connectivity is the Model Context Protocol (MCP), an open standard that lets any compliant agent discover and call any compliant tool server. Gateway's job is to make your existing infrastructure speak it.
A gateway is a managed MCP server that fronts one or more targets, where a target is a backend you want exposed as tools. Supported target types include:
- Lambda functions, for custom logic in any language, invoked directly by the gateway
- OpenAPI specifications, turning existing REST APIs into tools with automatic protocol translation
- Amazon API Gateway REST APIs, exposing API ecosystems you already operate
- Smithy models, particularly useful for generating tools that call AWS services
- Existing MCP servers, aggregated behind the gateway endpoint
- Built-in connectors for popular services such as Salesforce, Slack, Jira, Asana, and Zendesk
The gateway aggregates everything into a single unified MCP interface: an agent sees one consolidated tool list regardless of how many targets sit behind it. That creates an obvious scaling problem, because an enterprise gateway can front hundreds of tools, and stuffing hundreds of tool definitions into a model's context window costs tokens, latency, and reasoning accuracy. Gateway's answer is semantic tool search: instead of receiving every tool, the agent queries for the tools relevant to its current task and receives only the top matches. This is a small feature with a large architectural consequence, since it decouples the size of your tool catalog from the size of your prompts.
Gateway has also grown beyond tools. It can front other agents and HTTP services through passthrough targets, including Agent2Agent (A2A) traffic, and route inference requests across model providers, positioning it as a general checkpoint for agentic traffic rather than a tool adapter only.
Identity: agents as first-class principals
Here is the question that breaks most homegrown agent deployments: when an agent calls a tool, whose credentials is it using? Bake a service account's API key into the agent and every user acts with the same overly broad permissions. Hand the agent the user's raw credentials and you have built a credential-leaking machine that executes model-generated code.
Identity's answer is to make the agent itself a principal. Every agent gets a workload identity, a distinct identity with its own ARN, managed in a central directory. It is neither an IAM role nor a user account; it says who the agent is, separate from who the user is. Authentication then splits into two halves that are worth memorizing as a slogan. Inbound auth is who may invoke the agent: either IAM SigV4 for service-to-service calls inside AWS, or JWT bearer tokens from any OIDC-compatible identity provider (Cognito, Okta, Entra ID) for human-initiated calls. A given runtime uses one or the other, not both. Outbound auth is what the agent may access on the way out: OAuth 2.0 client-credentials flow for machine-to-machine access, or authorization-code flow when the agent acts on behalf of a specific user who has granted consent.
Between the two sits the token vault, which stores OAuth tokens, client credentials, and API keys encrypted with KMS keys. Its critical property is the binding model: a stored token is bound to a specific agent-user pair, so a token stored for user A on agent X can never be retrieved for user B or by agent Y. Token refresh is handled by the service. In agent code, SDK decorators like @requires_access_token reduce the whole dance to an annotation.
Built-in tools: Code Interpreter and Browser
Two capabilities are so common that AgentCore ships them as managed tools. Code Interpreter gives agents sandboxed code execution for data analysis and computation. Browser gives them a cloud browser for interacting with websites, with session replay for auditing what the agent actually did. Both use the same one-session-one-microVM isolation as Runtime: each tool session gets a dedicated Firecracker microVM with its own kernel, memory space, and network namespace, destroyed completely at session end. The rationale is the same as before, only sharper: these tools execute model-generated code and browse untrusted web content, the two most dangerous things an agent can do, so they get the strongest available boundary.
Observability: tracing the non-deterministic
Traditional monitoring assumes that failures announce themselves through errors and latency. Agents violate that assumption. A production agent can return a plausible but wrong answer, loop through reasoning steps indefinitely, or pick the wrong tool, all while every conventional metric stays green.
Observability addresses this by instrumenting agents with OpenTelemetry and capturing the full interaction record as spans: the user's prompt, each model invocation, each tool call with its parameters and result, and the final response, flowing into Amazon CloudWatch as traces, metrics, and structured logs. The unit of debugging becomes the trajectory rather than the request. When something misbehaves, you open the trace and see the decision chain: which tools the agent considered, what it called, where it went off track. Because the telemetry is OTel-native, it also ports to third-party observability stacks without re-instrumenting.
Policy and Evaluations: governing behavior, measuring quality
The newest layer of AgentCore, announced at re:Invent in December 2025, answers the question every security review eventually asks: what stops the agent from doing something it should not?
Policy is the enforcement half. It applies deterministic, real-time controls on agent actions, evaluated outside the agent's own code. The placement is the entire point. Prompt instructions are suggestions to a probabilistic system; a policy attached to the gateway is a wall in front of the tool call. Policies deploy in two modes: enforce, which blocks violating actions, and log, which records what would have been blocked while allowing it, so teams can validate rules against real traffic before turning them on. The prudent rollout is exactly that sequence: deploy in log mode, watch, refine, then flip to enforce.
Evaluations is the measurement half, and its central architectural fact is that it evaluates telemetry, not live traffic. It consumes the OpenTelemetry spans that Observability already collects and scores them with evaluators (LLM-as-judge and built-in quality dimensions such as correctness, goal completion, and tool-selection accuracy), producing scores you can dashboard, alert on, and use as regression gates in CI/CD. Where Policy prevents specific bad actions, Evaluations detects gradual quality drift, the failure class nothing else catches.
The harness: the primitives, pre-wired
Everything above is composable, which is a polite word for "assembly required." In its first year, AWS watched every team wire Runtime to Memory to Gateway to Identity in roughly the same shape, and productized the wiring. The harness, generally available since June 2026, is a managed abstraction over the primitives: CreateHarness defines an agent (model, system prompt, tools, memory configuration, skills, execution limits) and InvokeHarness runs it. The agent gets an isolated environment with a filesystem and shell, persistent memory across sessions, web browsing, tool access through Gateway or MCP, and streamed step-by-step output, without the team assembling any of it.
Two harness capabilities deserve architectural attention. Model choice is per-invocation: you set a default model at creation and can override it on any single invocation, switching providers mid-session without losing context, which turns model selection from an architecture decision into a runtime parameter. And versioning mirrors Runtime's: every update creates an immutable version, and named endpoints like PROD stay pinned until explicitly promoted, so rollback is repointing, not redeploying.
The trade-off is the usual one with managed abstractions: the harness covers the common shape quickly, and teams with unusual orchestration needs drop down to the primitives. Since both layers are the same services underneath, the choice is not a fork; it is a question of who does the wiring.
Lifecycle of a request
Components make sense only in motion, so follow one request end to end. A user asks a support agent: "What's the status of my refund, and cancel my other pending order."
The client application calls InvokeAgentRuntime with the user's JWT and a runtimeSessionId. Runtime validates the token against the configured identity provider (inbound auth), finds no existing microVM for this session, and provisions one, booting the agent container inside it. Runtime exchanges the validated JWT for a workload access token: from this point the agent acts as itself, scoped to this user.
The agent needs context, so it queries Memory: recent events for this sessionId for conversational continuity, and a semantic retrieval over long-term records for this actorId, which surfaces a record extracted last week noting the user's open refund case. The agent's model reasons over the request and decides it needs tools. Rather than loading the company's full tool catalog, it uses Gateway's semantic tool search and receives the handful of relevant tools: get_refund_status, list_orders, cancel_order.
The agent calls get_refund_status through Gateway over MCP. Gateway authenticates the caller, checks the attached Policy (reading refund status is permitted), fetches the appropriate downstream credential via Identity's token vault, translates the MCP call into a request against the refunds API's OpenAPI target, and returns the result. The cancel_order call takes the same path but hits a policy rule: cancellations above a threshold require the order to be in a pending state, which Policy verifies deterministically before the call is allowed through. Every hop of this (model invocations, memory reads, tool calls with parameters, policy decisions) is emitted as OpenTelemetry spans into CloudWatch.
The agent composes its answer and streams it back. The exchange is written to Memory as an event. The microVM idles, holding state. If the user replies within 15 minutes, the same microVM resumes with full context; otherwise it is terminated and sanitized. Minutes later, Memory's asynchronous extraction processes the new events and updates the user's long-term records. Later still, Evaluations scores the interaction's spans for correctness and tool-selection accuracy, feeding the dashboards that tell the team whether last Tuesday's prompt change made the agent better or worse.
Failure modes and fault tolerance
Agents inherit every failure mode of distributed systems and add several of their own. AgentCore's design is best judged by how it handles each class.
Runaway behavior. An agent can enter a reasoning loop, retrying a failing tool or re-planning indefinitely. The structural backstops are Runtime's hard limits (the 8-hour session ceiling and configurable execution limits) plus consumption-based billing that at least makes the loop visible on a bill. Detection is an Observability job: metric filters over agent logs can alarm on loop signatures before users report anything.
Unauthorized actions. The model is a probabilistic component that can be manipulated through its inputs; prompt injection via a retrieved document or web page is a real path to a bad tool call. The defense is that authority never lives in the prompt. Identity means the agent physically holds only scoped, per-user credentials; Policy means a violating action is blocked outside the agent's code even when the model has been convinced to attempt it.
Silent quality failures. The agent answers fluently and wrongly, and every infrastructure metric stays green. Nothing at the infrastructure layer can catch this, which is precisely why Evaluations exists as a separate measurement plane over the telemetry.
State loss and contamination. Session termination is aggressive by design (15 idle minutes), so durable state must live in Memory, not in the microVM; treating the microVM filesystem as persistent is the classic early mistake. The reverse failure, state leaking between users, is handled structurally by microVM isolation and the token vault's agent-user binding rather than by application-level discipline.
Dependency failures. Model providers throttle, downstream APIs time out, OAuth tokens expire mid-task. Identity absorbs the credential class with automatic token refresh. Throttling and timeouts surface in traces and metrics with enough granularity to distinguish "the model was slow" from "our refunds API was down," which is the distinction on-call engineers actually need at 3 a.m.
The complete picture
Summary
The deepest idea in AgentCore is separation of trust from intelligence. The model, the one genuinely intelligent component, is treated as the least trusted one: it runs inside a disposable microVM, holds only scoped credentials it cannot leak across users, faces deterministic policy walls it cannot argue past, and leaves a complete telemetry trail that a separate measurement plane scores for quality. Every architectural choice (Firecracker isolation, the inbound/outbound identity split, policy enforcement outside agent code, evaluation over telemetry) is the same decision made at a different layer: never let correctness depend on the model behaving.
That is also the honest answer to the migration question that opened this post. Agents Classic assumed you would trust AWS's orchestration; AgentCore assumes you will trust no orchestration at all, and builds the platform accordingly. For a class of software that acts with limited human oversight, that is not paranoia. It is the only architecture that scales.
Related on this blog: Architecture series