AWS AgentCore Managed Harness — Three Calls, Vendor Lock-In

On April 22, 2026, AWS launched the AgentCore managed harness — a new layer on top of Amazon Bedrock AgentCore that reduces autonomous agent deployment to three API calls: specify a model, a system prompt, and a list of tools, and the agent runs. No orchestration code, no session management, no infrastructure wiring. AWS calls it “model agnostic.” What they mean is: it runs on AWS infrastructure, billed through Bedrock, governed by IAM, and exported — if you ever want out — as Strands-based Python. That is not neutrality. That is vendor gravity wearing an open-source jacket.

TL;DR

• What: AWS shipped a managed agent harness that handles the full agent loop — reasoning, tool selection, execution, streaming — in three API calls
• Lock-in vector: The “export” escape hatch produces Strands Agents code, which is AWS’s own open-source SDK (Apache 2.0) — you leave AgentCore only to land on AWS’s preferred framework
• Governance win: CDK-native deployment with audit trails makes agents governable as pull requests, not console clicks — first managed agent platform with a real enterprise change-management story
• Action: Use this for AWS-native internal tooling where you already run IAM and CloudWatch; do not build multi-cloud agent architectures here

AWS AgentCore Managed Harness — What Happened

The managed harness is currently in preview across four regions: US West (Oregon), US East (N. Virginia), Europe (Frankfurt), and Asia Pacific (Sydney). The CLI and skills components are generally available across 14 regions, but the harness itself has not reached GA yet. There is no additional charge for the CLI, harness, or skills — you pay only for model inference costs.

The technical pitch is straightforward. Developers declare which model the agent uses, which tools it can call, and what instructions it follows. The harness then manages the full agent loop: reasoning, tool selection, action execution, and response streaming. Every session is stateful by default and runs in a secure, isolated microVM with its own filesystem and shell access.

That microVM isolation is genuinely impressive. In a world where most agent platforms share execution contexts between sessions — creating a minefield of state leakage and security issues — AgentCore gives each conversation its own sandboxed environment. For regulated enterprises running agents that touch customer data, this is not a nice-to-have. It is a prerequisite.

# The "three API calls" pattern — simplified
import boto3

client = boto3.client("bedrock-agentcore")

# 1. Create agent with model, prompt, and tools
agent = client.create_agent(
    model="anthropic.claude-sonnet-4-20250514",
    system_prompt="You are an internal ops assistant...",
    tools=["search_tickets", "update_status", "query_database"]
)

# 2. Start a session (gets its own microVM)
session = client.create_session(agent_id=agent["id"])

# 3. Send a message, get streamed response
response = client.invoke(session_id=session["id"], message="...")

The deployment model is where things get interesting for platform teams. AgentCore’s CLI uses AWS CDK for infrastructure-as-code deployment with full audit trails. Agents become pull requests, not console clicks. Terraform support is announced as coming soon. This is, as far as I can tell, the first managed agent platform with a genuine enterprise change-management story — and for organizations where “who changed the agent’s system prompt last Tuesday” is a compliance question, not a curiosity, this matters enormously.

Why This Matters

The managed harness sits at a specific intersection that no competitor currently occupies: zero-ops agent deployment with enterprise governance built in. Anthropic’s Claude Managed Agents offer a cleaner API and tighter model integration, but they lock you to Claude models and lack the IaC deployment story. AWS locks you to AWS infrastructure but lets you swap models — Bedrock supports Claude, GPT-family models, Gemini, and self-hosted Llama. That model flexibility is real, even if the optimized path always leads back through Bedrock’s billing console.

The lock-in mechanics deserve scrutiny. AWS positions the “export as Strands-based code” feature as your escape hatch. When you outgrow the managed harness, you can export the orchestration logic as Python code built on Strands Agents, AWS’s open-source agentic SDK licensed under Apache 2.0. Sounds open. But Strands Agents is an AWS-incubated project — the SDK, the documentation, the community, the examples all assume Bedrock as the default runtime. You leave AgentCore and land on another AWS-adjacent surface. The gravity well has layers.

The benchmark data backs up the technical approach, though. According to published evaluations, Strands steering hooks achieved a 100% accuracy pass rate across 600 evaluation runs, compared to 82.5% for simple prompt-based instructions and 80.8% for graph-based workflows. Those numbers matter because they suggest that programmatic hooks intercepting and correcting agent behavior genuinely outperform both the “just write a better prompt” school and the LangGraph-style “hardcode every path” school.

On April 30, AWS followed up with a preview of A/B testing and AI-generated recommendations for agent optimization. The system analyzes production traces and evaluation outputs to create optimized system prompts and tool descriptions. This completes the observe-evaluate-improve loop — and it means AWS now automatically suggests changes to your agent’s behavior based on how it performs in production. Useful? Absolutely. But it also means your agent’s evolution is informed by AWS’s optimization layer, which further deepens the integration surface you would need to replicate if you ever migrate.

The managed harness is still in preview. Do not mistake preview availability in four regions for production readiness. The CLI is GA across 14 regions, but the harness itself has no announced GA date. Build prototypes here, not production systems — yet.

For teams already running on AWS with CDK pipelines, IAM policies, and CloudWatch dashboards, the managed harness removes genuine friction. The agent becomes another CDK construct. It fits into existing approval workflows, security reviews, and cost dashboards. No new vendor relationship, no new billing system, no new identity layer. That operational simplicity is the actual product — the agent runtime is just the delivery mechanism.

If you are evaluating AgentCore, test the export path early. Build a simple agent in the managed harness, export to Strands code, then try running that code on a non-AWS model provider. The friction you encounter in that exercise tells you exactly how much vendor gravity you are accepting.

The comparison to Kiro CLI’s headless agents is also instructive. Kiro operates at the developer tooling layer — CI/CD agents that run in your pipeline. AgentCore operates at the infrastructure layer — production agents that serve end users. They are not competitors; they are different altitudes. But both share the same structural assumption: AWS is the ground truth for your deployment story.

The Take

I would use the AgentCore managed harness for internal AWS-native tooling where I already have IAM, CloudWatch, and CDK in the pipeline. The microVM isolation, the CDK-native deployment model, and the audit trail story are genuinely the strongest in category for regulated enterprise environments. No other managed agent platform — not Anthropic’s, not Google’s Vertex Agent Builder — gives you agent governance as pull requests today.

What I would not do is build a multi-cloud agent architecture on AgentCore. The “model-agnostic” claim is technically true and strategically misleading. You can run GPT or Gemini through Bedrock, but every supporting feature — session management, observability, A/B testing, the optimization recommendations — lives on AWS. The export-to-Strands escape hatch is real code, not vaporware, but Strands itself is an AWS-incubated project. You are choosing between flavors of AWS, not between AWS and independence.

The honest framing: Anthropic locks you to Claude models but gives you a cleaner API. AWS locks you to AWS infrastructure but lets you swap models. Pick your poison before you ship the prototype, because the prototype becomes the production system faster than anyone plans for.