AgentCore's Managed Agent Runtime
What the managed harness handles vs what you still own.
//
Busca en todas las páginas de la documentación
What the managed harness handles vs what you still own.
Amazon Bedrock AgentCore is AWS's platform for running agents in production, not for calling a foundation model directly. If Bedrock's Converse API answers "how do I get a reply from a model," AgentCore Runtime answers "where does my agent's code actually run, and who keeps it isolated, scaled, and observable." This page draws the line between what the managed runtime takes off your plate and what remains your responsibility as the agent's author.
AgentCore is a fast-moving 2026 preview capability at the time of writing. The shape described here - a managed runtime with a control plane and a data-plane invoke surface - reflects AWS's public direction, but exact operation names and payload fields should be verified against current AWS documentation before you build against them.
Think of AgentCore Runtime as the difference between "code that calls a model" and "a service that runs that code for any number of concurrent users, safely."
Before AgentCore, teams hosting an agent in production had to solve a familiar but tedious set of problems themselves: where does the process live (Lambda, ECS, EC2), how is one user's conversation kept separate from another's, how does it scale under bursty traffic, and how do you wire in logging and guardrails consistently. None of that is specific to any one agent's logic - it is infrastructure every agent needs.
AgentCore Runtime is AWS's answer: a managed compute layer purpose-built for hosting agent workloads. You provide the agent - typically as a small entrypoint function that AWS's SDK/CLI tooling packages - and the runtime takes care of provisioning, isolating, and invoking it.
# --- Python (boto3) --- illustrative shape only, verify exact operation/params at build time
import boto3
client = boto3.client("bedrock-agentcore", region_name="us-east-1") # data-plane client
resp = client.invoke_agent_runtime(
agentRuntimeArn="arn:aws:bedrock-agentcore:us-east-1:111122223333:runtime/my-agent",
payload=b'{"prompt": "Summarize this quarter\'s sales."}',
)
print(resp["response"].read())// --- TypeScript (AWS SDK v3) --- illustrative shape only, verify exact operation/params at build time
import { BedrockAgentCoreClient, InvokeAgentRuntimeCommand } from "@aws-sdk/client-bedrock-agentcore";
const client = new BedrockAgentCoreClient({ region: "us-east-1" }); // data-plane client
const resp = await client.send(new InvokeAgentRuntimeCommand({
agentRuntimeArn: "arn:aws:bedrock-agentcore:us-east-1:111122223333:runtime/my-agent",
payload: new TextEncoder().encode(JSON.stringify({ prompt: "Summarize this quarter's sales." })),
}));
console.log(resp.response);Note the shape rather than the exact names: a data-plane client sends a payload to a deployed runtime by ARN and gets a response back. The client name, operation name, and payload envelope are the parts most likely to shift as AgentCore moves out of preview - treat the snippet as directional.
AgentCore splits, like most AWS services, into a control plane and a data plane.
The control plane (likely a bedrock-agentcore-control client family) is where you create and configure a runtime: point it at your packaged agent code, set the execution role it runs under, and deploy a version. This is a one-time or occasional operation, similar to creating a Lambda function.
The data plane (a bedrock-agentcore client, illustrated above) is where you invoke that deployed runtime at request time - one call per user turn or task, the same way you'd call Converse on Bedrock Runtime, except now you're invoking your own agent's entrypoint rather than a raw model.
Inside a single invocation, the runtime is described by AWS as isolating each session at a strong boundary - AWS's own materials describe microVM-level isolation, so that state, memory, and any in-flight tool calls for one user's session cannot bleed into another's, even under concurrent load. The runtime also handles scaling the underlying compute up with demand and down to near-zero when idle, so you are not paying for always-on servers between invocations.
What still lives entirely in your code: the model you call and how (Bedrock Converse, a specific model id, your inference config), your system prompt and reasoning strategy, which tools are available and how their results feed back into the loop, and any framework (or lack of one) you use to orchestrate multi-step reasoning. The runtime does not author or improve any of that - it only gives that code a production home.
AgentCore Runtime is one piece of a larger AgentCore family that this section covers: Gateway turns existing APIs and functions into tools an agent can call, Memory persists state across invocations, and Observability integrates with CloudWatch so you can see what a hosted agent actually did. Runtime is the piece that makes the other pieces meaningful - without a hosted process to invoke, there is nothing for Gateway to feed tools into or for Observability to trace.
A natural question is how this compares to simply running your agent loop in a Lambda function or a container on ECS yourself. You certainly can - AgentCore is not the only way to host an agent on AWS. The trade-off is that hand-rolled hosting means you own session isolation, scaling policy, and the observability wiring yourself, repeated for every agent you build. AgentCore centralizes that plumbing so multiple agents, possibly built with different frameworks, share one operational model.
It is worth being explicit about what this is not. AgentCore is not the Anthropic Claude Agent SDK, and it is not a client-side "managed agents" feature of the Claude API - those are Anthropic products for building and hosting agents against Anthropic's own infrastructure. AgentCore is AWS's own product for hosting agents - regardless of which model or framework powers them - on AWS infrastructure, governed by IAM and billed as an AWS service. An agent built with the Strands Agents SDK calling Claude via Bedrock, and deployed to AgentCore Runtime, uses three separate AWS/Anthropic concerns at once: the framework, the model, and the hosting layer.
Converse call runs one model turn; an AgentCore Runtime invocation runs your entire hosted agent process, which may itself make several model and tool calls before responding.No. It hosts whatever orchestration you already have - a framework's loop or your own - and handles the surrounding infrastructure: isolation, scaling, and invocation. The reasoning logic itself stays yours.
AWS describes Runtime as framework-agnostic, built to host agents regardless of the orchestration library used internally, as long as the agent is packaged as an entrypoint the runtime can invoke. Verify current framework support notes against AWS docs before committing.
No, they are unrelated products from different companies. AgentCore is AWS's platform for hosting agents on AWS infrastructure; it can host an agent that happens to call Claude via Bedrock, but it does not replace or wrap Anthropic's own SDK.
AWS describes strong, microVM-level isolation per session, so concurrent invocations for different users or tasks cannot see each other's in-flight state. Treat the exact isolation mechanism as AWS's implementation detail, not something you configure directly.
Yes. Your hosted agent code still chooses a model (typically via Bedrock's Converse API), builds the prompt, and manages any tool-use loop. AgentCore only changes where that code runs.
It was labeled preview at the time of writing. Treat method names, payload shapes, and CLI commands shown across this section as directional, and re-check AWS's current documentation before shipping production code against them.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+). Amazon Bedrock AgentCore is a fast-moving 2026 preview capability - verify exact API/CLI surface against current AWS docs before relying on specific method names.
Revisado por Chris St. John·Última actualización: 24 jul 2026