Deploy an AI Agent in Minutes with AgentCore Managed Harness

I've been tracking the AgentCore story since re:Invent 2025. When AWS dropped the Managed Harness (preview) on April 22, 2026, I dropped what I was doing and spent an evening building with it. What follows is that evening, documented.

If you've ever tried to stand up an agent from scratch — orchestration loop, compute, sandboxing, auth, persistent storage, tool wiring — you know it easily burns a day before your agent does anything useful. The managed harness eliminates that entirely.

What is AgentCore Managed Harness?

In AgentCore, a harness is the orchestration foundation that turns a model into a running agent. It bundles: the agent loop (reason → select tool → act → respond), compute isolation, tool connections, memory, identity, networking, and observability.

Before the managed harness, you had to write all of this yourself — even with the AgentCore SDK. The managed harness is AWS providing that plumbing as a managed offering. You declare the model, system prompt, and tools as config. A working agent is the result.

The AgentCore CLI — one terminal to build, deploy, operate

Before the CLI, deploying an agent meant stepping outside your dev environment entirely. Now everything lives in one terminal. The help output shows the full picture:

The add command supports a rich menu of resources — harnesses, agents, memory, credentials, evaluators, gateways, A/B tests (preview), and config bundles.

Hands-on: creating a project from scratch

Step 1 — Create the project

I started with agentcore create. The flag --session-storage-mount-path mounts a persistent volume at /mnt/data inside the agent's microVM — useful when your agent needs to read/write files across turns.

Step 2 — Inspect the generated harness.json

The project scaffold drops a harness.json and a system-prompt.md in app/myawssol/. Everything about your agent is declared here.

Clean. The model is Claude Sonnet 4.6 on Bedrock (global inference profile). Memory is enabled by default — the harness will create a named memory resource to carry context across sessions. Session storage is mounted at /mnt/data.

Configuring the harness interactively with agentcore add

You can also build the harness interactively. The agentcore add wizard walks you through name → model provider → custom environment → memory → advanced settings → confirm.

The wizard walks through each option. The Advanced settings step is where things get interesting:

Adding tools to the harness

I added the AgentCore Browser tool — this gives the agent the ability to navigate web pages, extract content, and interact with UIs. One command:

This appended the tool entry to harness.json:

"tools": [
  {
    "type": "agentcore_browser",
    "name": "browser"
  }
]

No SDK import. No handler registration. No Lambda function. Just config.

Other available tool types you can wire in the same way:

• agentcore_code_interpreter — sandboxed code execution inside the microVM
• agentcore_gateway — route calls through an AgentCore gateway
• remote_mcp_server — attach any MCP server endpoint as a tool

Deploy — what happens under the hood

From the project root, agentcore deploy handles everything. It calls CDK behind the scenes but you never see CloudFormation directly unless you want to.

The deploy pipeline: validate → CDK synth → CloudFormation diff → publish assets → deploy to AWS. The agent endpoint URL, IAM role ARN, and session storage path are all available after deploy via agentcore fetch or agentcore status.

Bonus: Agent Toolkit for AWS

A week after the managed harness dropped, AWS announced another piece: the Agent Toolkit for AWS (May 2026). This is the successor to the MCP servers, plugins, and skills that lived on AWS Labs.

It's composed of three things:

Why this matters for AgentCore builders

The AWS Agents plugin is the key one for anyone using the managed harness. Point Kiro, Claude Code, or Cursor at it and your coding agent now understands AgentCore structure, best practices, harness config patterns, and CDK/CloudFormation implications — in context, at generation time.

Combined with the managed harness: you describe what you want in plain language to your coding agent, it generates a valid harness.json + system prompt aligned with AWS conventions, and agentcore deploy ships it. The time from idea to running agent continues to compress.

My takeaways

I've been building with Bedrock agents, Strands, and AgentCore for a while now. Here's where the managed harness sits in that progression from my perspective:

• The infrastructure tax is real — Every team building agents I've spoken to loses days to the same setup: compute, auth, tool wiring, session state. The harness eliminates that first hill entirely.
• Config as the contract — harness.json is your entire agent definition. Model, tools, memory, storage, networking. Versioned in git. Reviewable. Diffable. This is the right abstraction.
• The escape hatch is critical — When you need full control, you can export the harness orchestration as Strands-based Python code. You're never locked into the managed abstraction.
• One terminal is underrated — Before this, switching between my editor, AWS Console, CDK, and a separate deploy pipeline was constant friction. agentcore dev, agentcore deploy, agentcore invoke, agentcore logs — same terminal, same context.
• Agent Toolkit closes the loop — The coding agent that helps you write the harness config can now be equipped with current, curated knowledge of the harness itself. That's a flywheel.

We're in an era where the time from "I have an agent idea" to "I have a working agent in production" is measured in minutes, not days. This release is a meaningful part of that shift.

If you're building on AWS with Bedrock and haven't touched AgentCore's managed harness yet — spin up the CLI, run agentcore create, and see how far you get before dinner.