Amazon Bedrock AgentCore ハーネスが一般提供開始：アイデアから数分で本番環境対応エージェントへ

A year ago, Simon Willison wrote one of the cleanest definitions of an agent that has stuck around:

An LLM agent runs tools in a loop to achieve a goal.

That definition stuck because it describes what every production agent actually does. Kiro, Amazon Q Developer, Quick Agents, Codex, Claude Code: under the hood, they all run the same shape. The agent loop is the common denominator.

But the loop was never the hard part. The hard part was everything around it.

Pick a framework. Wire up tools. Provision sandboxed compute. Configure storage, secrets, networking. Decide where memory lives. Bolt on observability. Get the right dependencies into the right container. Also, local prototyping tends to be the easy part: a single developer can stand up an agent on their laptop in an afternoon. Getting it into production is where the work explodes, and the moment it has to serve more than one user, a whole new layer of work shows up: concurrency, isolation, identity, state, scaling.

Worse, that overhead multiplied with every new use case. Teams that wanted to experiment, try a different model, swap a tool, point the agent at a new domain, found themselves repeating the same plumbing. The bottleneck wasn’t intelligence. It was orchestration and infrastructure.

When we launched the AgentCore harness in preview in April, we made a bet: the AgentCore primitives (Runtime, Memory, Gateway, Browser, Identity, Observability) already give teams everything they need to run agents in production; what they shouldn’t have to do is wire them up by hand every time. The harness handles that wiring as a managed abstraction, so it becomes something you configure rather than something you build.

Today, Amazon Bedrock AgentCore harness is generally available. Two API calls (CreateHarness to define an agent, InvokeHarness to run it), a quick walkthrough in the AgentCore CLI (as shown in the below gif), or a few clicks in the console, and you have an agent running in minutes. It runs in its own isolated environment with a filesystem and shell, so it can read files, run commands, and write code safely. It remembers users and conversations across sessions, picks up skills you point it at (including the AWS-curated catalog), browses the web, calls your tools through gateway or MCP, and switches model providers mid-session without losing context. Every step streams back to you in real time and is automatically traced to CloudWatch. There’s no need to write orchestration code or build a container, except if you want to.

What the harness offers you

A harness is everything an agent needs to run in production, wrapped behind two API calls. You point to the model, tools, skills, and instructions you want. AgentCore handles the sandboxed environment, the memory, the storage, the identity, and the observability that ties it all together. Capabilities new at GA are marked with * in the diagram below.

Any model: Use the right model for the job, switch when you need to

Different tasks need different models. Customers told us they want to plan with one model and execute with another, swap a provider for a price-performance test, or move off a model that just shipped a regression, all without losing the conversation. Pick a default model on CreateHarness, then override it on any single InvokeHarness call when you need to. The default stays in place for every other invocation. Set the matching field on model for the provider you want:

• bedrock for any model served on Amazon Bedrock, including Anthropic Claude, Amazon Nova, Meta Llama, DeepSeek, Qwen, Kimi, MiniMax, Cohere, Mistral and as of recently OpenAI GPT-5.5 and GPT-5.4 on Bedrock

• openAi for direct access to OpenAI’s API (api.openai.com)

• gemini for Google Gemini

• liteLlm for any third-party provider supported by LiteLLM, including Anthropic direct, Cohere, Mistral, Vertex, Azure OpenAI, and others

And the part that customers told us mattered most: switch providers at any point, even mid-session, and keep context. For example, you can use Claude Opus to plan, switch to GPT-5.5 to write code, switch to Gemini to summarize. The conversation continues. The harness handles the transition seamlessly.

If you’re using API keys to access any of the underlying model providers, they’re stored securely in AgentCore Identity’s token vault. The agent never sees raw credentials.

Tools as config: Connect your agent to the world without writing glue code

Tools are how the agent affects anything outside its own reasoning, and wiring them is the part most teams quietly hate. Customers told us they don’t want to write per-API adapter code, manage MCP server lifecycles, or build their own browser sandbox. They want to declare what the agent can use and let the harness handle the connection, the auth, and the execution.

tools on CreateHarness are a list. Each entry has a type and a config block, and the harness wires them in:

• agentcore_gateway: you can reference an AgentCore Gateway by ARN. Every target the gateway exposes (OpenAPI, Smithy, Lambda, MCP) shows up as a tool, with IAM/JWT auth, per-tool authorization, and outbound credential brokering handled for you.

• remote_mcp: you can connect directly to any MCP server by URL. Good when the server is already secured and you don’t need Gateway’s governance layer in front of it.

• agentcore_browser: a full browser sandbox as a one-line reference. Click, type, navigate, screenshot.

• agentcore_code_interpreter: sandboxed Python and Node execution, same one-line pattern.

• inline_function: a tool schema the harness emits as a tool-use event in the stream and waits for you to respond on. Use it for human-in-the-loop approvals or for tools that have to run on your side.

"tools": [
  { "type": "agentcore_browser" },
  { "type": "agentcore_code_interpreter" },
  { "type": "remote_mcp",
      "name": "X_tool",
      "config": { "remoteMcp": { "url": "https://mcp.X_tool/mcp" } } },
  { "type": "agentcore_gateway",
      "name": "Y_tool",
      "config": { "agentCoreGateway": { "arn": "arn:aws:bedrock-agentcore:..." } } }
]

Every session also gets built-in shell (run commands inside the microVM) and file_operations (read and write on the agent’s filesystem) without you listing them. They’re what make the stateful filesystem and shell story usable from the model.

You have the same options on InvokeHarness for per-call edits, where you can pass new tools to change tools for a single call, or strip the list down to a focused set for that invocation via the allowed_tools parameter. Defaults are set at create time, but you can easily override at invoke time.

Built-in memory: Your harness remembers users and conversations

Customers want their agent to recognize a returning user, pick up where the last conversation left off, and remember preferences without anyone replaying message history. In preview, you had to provision an AgentCore Memory resource separately and pass its ARN, which worked but was a second API call and an easy thing to forget on the way to production.

At GA, omitting memory on CreateHarness provisions a managed memory automatically, with sensible defaults: SEMANTIC + SUMMARIZATION strategies, 30-day event expiry, AWS-owned encryption, and multi-tenant isolation by default through namespace templates that key on actorId. It’s a real, customer-owned Memory resource, provisioned for you. Memory isn’t mandatory. If your agent is stateless, set memory: { disabled: {} } and the harness skips memory entirely. If you’d rather attach an AgentCore Memory resource you already own, pass agentCoreMemoryConfiguration with its ARN. Those three paths look like the following:

// Configure built-in memory 

"memory": { 
 "managedMemoryConfiguration": { 
    "strategies": ["SEMANTIC", "SUMMARIZATION"], 
    "eventExpiryDuration": 30 
  } 
} 

// BYO existing memory 

"memory": { "agentCoreMemoryConfiguration": { "arn": "arn:aws:bedrock-agentcore:..." } } 

// Stateless agent 
"memory": { "disabled": {} } 

Switching to your own memory is one UpdateHarness call. Pass agentCoreMemoryConfiguration with your memory ARN and the previously managed memory disassociates immediately. It’s still a regular AgentCore Memory resource in your account, so you can keep using it anywhere, attach it to another harness, query it directly, or delete it on your own terms. When you delete the harness, the managed memory is cascade-deleted by default (deleteManagedMemory: true). Pass deleteManagedMemory: false if you want to keep it.

The managed memory is automatic but not opaque. It’s a real, addressable AWS resource you can query, attach to a different agent, audit, or hand to an analytics pipeline.

Skills: Give your agent the right expertise on the right task

Customers want their agent to know how to handle a specific task before it tries it. For example, how to format an Excel report, how to file a JIRA ticket the way their team files them, or how to follow AWS-recommended procedures for accessing their data on AWS. Skills are how you give the agent that knowledge on demand. They’re bundles of files, scripts, and instructions. The harness loads skill metadata and pulls full content into context only when the task actually calls for it.

At GA, HarnessSkill is a union with four sources, so you can attach skills declaratively without baking them into a container or shelling in:

• awsSkills – turn on the AWS-curated skill bundle.

• git – clone a public or private repo over HTTPS, pinned to a commit or a branch.

• s3 – pull a skill bundle from your own Amazon Simple Storage Service (Amazon S3) bucket.

• path – reference a path that already exists in the container you brought in.

"skills": [ 
 { "awsSkills": {*} }, 
  { "git": { "uri": "https://github.com/anthropics/skills", "path": "document-skills/xlsx" } }, 
  { "s3":  { "uri": "s3://my-bucket/skills/team-sops/" } } 
] 

The same shape works on InvokeHarness for per-call layering. The harness materializes each skill onto the session filesystem on session start, or during a new invocation if the Skills configuration changes.

The big unlock for AWS builders: the AWS skills repository ships curated skills covering the AWS surface area, from core skills (SDK usage, infrastructure as code (IaC), AWS Identity and Access Management (IAM), Amazon CloudWatch, and Amazon Bedrock) to service-specific deep workflows for analytics, databases, Amazon Elastic Compute Cloud (Amazon EC2), networking, security, serverless, and storage.

To make this even simpler, GA introduces a first-class awsSkills toggle: turn on the AWS skill bundle with zero plumbing, no URL, no network fetch (the skills are brought in the harness’s underlying runtime, whenever you need them).

aws bedrock-agentcore-control create-harness \ 
  --harness-name myAgent \ 
  --skills '[{"awsSkills": {}}]' 

# OR scope to specific bundles with a paths glob 
aws bedrock-agentcore-control create-harness \ 
  --harness-name myAgent \ 
  --skills '[{"awsSkills": {"paths": ["core-skills/*", "specialized-skills/operations-skills/*"]}}]' 

Environment and filesystem: Run your agent in the environment it needs

Most agents run fine on the harness’s default environment, which includes Python and bash. When you need more (a private dependency, a runtime version, a CLI tool, or persistence across sessions), two knobs let you shape the agent’s runtime to match your stack: the *container image* and the *filesystem*.

Container image. If Python and bash aren’t enough, you can package your source code, dependencies, runtimes, and tools into a custom container, push it to Amazon Elastic Container Registry (Amazon ECR), and reference it in CreateHarness. The agent then uses that exact environment. You can also pair it with InvokeAgentRuntimeCommand, an API that runs a shell command directly inside the agent’s microVM session, for session-specific setup that varies per invocation (clone a particular branch, seed test data, or pull credentials). It’s deterministic, doesn’t go through the model, and doesn’t burn tokens.

Filesystem. Agents often need files to outlive a single response: a shared knowledge base, a working directory across sessions, or a place to drop produced documents back into your bucket. The harness gives you three filesystem options, each with different reach and persistence characteristics.

Type

Managed

Virtual private cloud (VPC) required

Persistence

Managed session storage

Yes

No

Across stop/resume cycles of the same runtimeSessionId.

Amazon Elastic File System (Amazon EFS) access point

BYO

Yes

Across all sessions, sharable across harnesses.

Amazon Simple Storage Service (Amazon S3) Files access point

BYO

Yes

Across all sessions and harnesses, with full Amazon S3 durability, versioning, and history.

Reach for managed session storage for working files that need to survive microVM restarts within a session. Reach for EFS when multiple harnesses or sessions need to share reference data, prompts, or skill bundles. Reach for S3 Files when you want the agent to read and write through standard file operations while changes are automatically synchronized with the backing S3 bucket (the agent writes a report, the report appears in your S3 bucket as it goes).

Unified observability: See what your agent did, in one place

When something goes wrong, customers want to know in one place what the agent ran, what it called, where it slowed down, and where it failed. A typical harness invocation crosses runtime + memory + gateway + a built-in tool or two, and stitching that picture together used to mean opening five tabs.

At GA, every harness page in the AgentCore console shows a single observability widget: an aggregate row that summarizes the harness across every primitive it touched, plus per-primitive sections that appear only for the primitives the harness is configured with or has used.

For deeper analysis, CloudWatch GenAI Observability has a new Harnesses tab alongside Runtime and other primitives. Drill from a harness, into a session, into a single trace, and see exactly what the agent did, in what order, how long each step took, and where it failed. Logs from every primitive (memory, gateway, browser, code interpreter) surface inline at the right span, so you stop hopping between log groups to piece together what happened.

Evaluate and optimize: Keep improving your agent in production

Once your agent is in production, the question shifts from “does it work?” to “is it improving?” Customers want a way to score how their agent is actually doing on real traffic, get suggestions on what to change, and validate those changes before rolling them out. GA brings two pieces that close that loop:

• AgentCore Evaluations score harness traces with built-in large language model (LLM)-as-a-judge evaluators (helpfulness, faithfulness, safety), or with custom evaluators you author. Run them online (scoring every session as it happens), on-demand for a single trace, in batch over historical traces, against a fixed test dataset, or as a simulation with synthetic users to stress-test before going live.

AgentCore optimization reads those evaluator scores and generates prompt and tool-description rec