Amazon Bedrock AgentCore Harness: What It Is, How It Works, and Key Features

Building an AI agent that works in a demo is relatively easy. Building one that can reliably execute tasks, use tools, manage context, and operate in a production environment is much harder. That is where an agent harness comes in.

An agent harness sits between the model and the systems it needs to interact with. It manages the agent loop, tool execution, context, memory, sandboxing, and other runtime concerns needed to turn an LLM into a working agent.

Amazon Bedrock AgentCore Harness is a proprietary, managed service from AWS that provides a pre-built agent loop and runs within AgentCore Runtime.

In this guide, we'll break down how AgentCore Harness works, how it differs from AgentCore Runtime, and how it compares with TrueForge across model support, context management, sandboxing, extensibility, deployment, and control over the agent loop.

What Is AgentCore Harness?

AgentCore harness is a managed agent harness inside Amazon Bedrock AgentCore. It entered public preview in April 2026 and is now generally available. The orchestration loop is provided for you, powered by Strands Agents, and you describe the agent rather than build it.

The practical shape of that: you declare a model, a system prompt, a set of tools, memory settings and execution limits as configuration. AWS runs the loop. Most changes that would normally mean a code edit and a redeploy are a single config field instead. Switching from one model provider to another is a field. Adding a tool is a field.

Every harness session is stateful by default and runs in an isolated microVM. The agent gets its own filesystem and shell, so it can write a file, execute code, and carry memories and files across sessions rather than starting cold each time.

Two API calls get you running. CreateHarness defines the agent, InvokeHarness runs it. There is also an AgentCore CLI path and a console path if you would rather click than curl.

How Does AgentCore Harness Work?

AgentCore Harness is built around a configuration-driven approach to agent execution.

Instead of writing an agent loop such as:

response = model.generate(...)
if response.has_tool_call():
    result = execute_tool(response.tool_call)
    messages.append(result)
else:
    return response

you define the components the agent needs and let the harness manage the loop.

At a high level, an AgentCore Harness consists of:

• Model - the model the agent uses for reasoning and generation
• Instructions - the system-level behavior and instructions for the agent
• Tools - capabilities the agent can invoke, including MCP servers and AgentCore tools
• Memory - state that can be retained across interactions
• Skills - additional capabilities and instructions that can be made available to the agent
• Execution settings - controls around how the agent operates

The harness then coordinates these components during execution.

For example, if an agent needs to research a topic, it can reason about the task, call a tool to retrieve information, incorporate the result into its context, and continue the loop until it reaches a final response.

This abstraction means developers don't have to build every part of the orchestration layer themselves.

However, it also means that the execution model is largely determined by the harness. If you need to change the underlying loop or introduce custom orchestration logic, you have less flexibility than you would with an open-source harness where the loop itself is accessible.

You never see the loop. That is the entire point of the product, and it is also the source of most of its constraints.

What Ships With It?

The managed harness covers a wide surface with no code required:

Model selection spans Bedrock, OpenAI, Gemini and LiteLLM, and you can switch provider mid-session. Built-in shell and file_operations tools come standard, as do Agent Skills. Memory arrives in both short-term and long-term forms, the latter covering semantic, summarization, user-preference and episodic memory, with per-user scoping by actor ID.

The other AgentCore primitives plug in as configuration rather than SDK calls: Gateway, Browser, Code Interpreter, and remote MCP server tools. Filesystem options include service-managed session storage, an EFS access point, or an S3 Files access point.

On the security side, inbound auth supports IAM SigV4 and OAuth, outbound auth runs through the Identity token vault for OAuth tokens and API keys, and sessions are isolated with VPC networking available. Observability, streaming responses, versioning and endpoints all work without custom code.

One exception worth knowing: inline and client-side tools still require you to write and maintain an implementation, even on the harness.

AgentCore Harness vs AgentCore Runtime

This is the comparison that sends most people to the docs, so it is worth being precise. The two solve different parts of the same problem, and the aws agentcore harness is layered on top of the other.

AgentCore harness is a managed abstraction that runs inside Runtime. CloudTrail even records harness operations under AWS::BedrockAgentCore::Runtime, which tells you where the boundary actually sits.

AgentCore Runtime is a serverless hosting environment. You bring agent code written in any framework or none, wrap it with the AgentCore SDK's BedrockAgentCoreApp entrypoint, package it into an ARM64 container, push it to Amazon ECR, and deploy. Runtime handles isolation, scaling, sessions, auth gating and observability plumbing. The orchestration loop is yours.

The pattern across almost every feature is the same. On the harness it is configuration with no code. On Runtime it is supported, but you maintain the implementation.

What AgentCore Harness Can't Do

AWS publishes these limitations in its own feature grid. Four capabilities are marked as unsupported in the harness:

No choice of agent framework. The loop is built around Strands Agents. If your team has already built on LangGraph, CrewAI, or another framework, that code does not come with you.

No non-agent-loop patterns. Graph-shaped and workflow-shaped applications are out. If only one step of your pipeline needs a model and the rest is deterministic code, the harness has no way to express that workflow.

No hooks. You cannot inject your own logic at specific points in the loop. That rules out use cases such as a compliance check or business rule that needs to run at an exact point in the execution cycle rather than whenever the model decides to call a tool.

No bidirectional streaming. The harness does not support bidirectional streaming, limiting applications that need continuous two-way communication between the client and the agent.

There is a fifth item that is less a missing feature than a design decision, and it matters more for long-running agents: context handling uses truncation.

When the context window fills up, older content is removed. This keeps the agent within its context limits, but it also means earlier information can disappear.

An alternative approach is compaction: summarize older history into a structured record and retain that summary. Instead of simply dropping earlier turns, the agent preserves a condensed version of what happened, helping it maintain continuity over longer runs.

For a short support agent, truncation may be perfectly adequate. For a multi-hour research or migration task, the difference can become much more noticeable: the agent has to work with less of its earlier context as the run gets longer.

When to Use AgentCore Harness

It is a strong fit when:

• Your infrastructure is already AWS and staying there, and IAM, VPC and CloudTrail are how your security team wants agents governed
• You want an agent this week and would rather configure than build
• You are already using AgentCore Memory, Gateway, Browser or Code Interpreter, since the harness turns all of them into config fields instead of SDK calls
• The agent's work is a genuine loop, with no deterministic pipeline wrapped around it
• Internal tools, where fast delivery matters more than portability

That is a real set of advantages, and for an AWS-committed team building an internal agent, the amazon bedrock agentcore harness will get you there faster than anything you would assemble yourself.

TrueForge: An Open-Source Alternative to AgentCore Harness

‍

TrueForge takes a different approach to the agent harness problem. Instead of providing a fixed, managed orchestration loop, TrueForge is an MIT-licensed, open-source agent harness that you can run on your own infrastructure.

The core server is open source, so developers can inspect and modify the execution loop rather than treating it as a black box. You can run TrueForge locally, with Docker Compose, or deploy it using Helm.

That changes the tradeoff considerably. With AgentCore Harness, AWS manages the loop and the surrounding infrastructure for you. With TrueForge, you get more control over how the agent actually runs.

Bring Your Own Model and Tools

TrueForge is model-neutral and works with OpenAI-compatible endpoints. You can point the harness at the model provider or endpoint you want without changing the underlying agent implementation.

The same applies to the tools the agent uses. TrueForge supports MCP servers and lets you bring your own sandbox rather than tying the agent to a single managed execution environment.

This makes the harness layer independent from the model and infrastructure underneath it:

Model → TrueForge → MCP / tools / sandbox

You can change the model endpoint without rebuilding the agent around a different provider.

Control the Agent Loop

One of the biggest differences from AgentCore Harness is that the TrueForge loop is open source.

That means developers can inspect how the harness handles execution and modify it when they need behavior that isn't available as a configuration option.

This is useful when an agent needs custom logic around:

• Tool execution
• Approvals
• Context management
• Subagents
• Sandboxing
• Execution policies
• Custom orchestration

Rather than waiting for a managed harness to expose a particular hook or configuration option, the underlying implementation is available to change.

Context Management

TrueForge also takes a different approach to context management.

Instead of relying only on truncation when the context gets too large, TrueForge uses compaction along with techniques such as deferred tool loading, Code Mode, and response offloading.

The goal is to reduce the amount of context that needs to remain in the active conversation while retaining the information the agent needs to continue working.

For long-running agents, this distinction matters. An agent working through a large codebase or a multi-step research task can accumulate a substantial amount of tool output and intermediate context. Simply removing older messages can make that information unavailable; compaction provides a way to retain a condensed representation instead.

Sandbox as a Tool

TrueForge also treats the sandbox differently.

With AgentCore Harness, the session runs inside an isolated microVM. TrueForge instead treats the sandbox as a tool that can be provisioned when the agent actually needs to execute code.

That means the sandbox does not have to be the environment for the entire agent session. It becomes another capability that the agent can invoke when required.

This reflects a broader difference in philosophy:

AgentCore Harness: managed environment around the agent.

TrueForge: open runtime where capabilities such as sandboxing can be composed into the agent.

Where TrueForge Fits

The distinction ultimately comes down to control.

AgentCore Harness is designed to give developers a managed path to running agents without building the orchestration loop themselves. TrueForge is designed for developers who want the harness itself to remain customizable and independent of a particular cloud provider or agent framework.

That makes TrueForge particularly relevant when you need to control the agent loop, change how context is managed, choose your own model endpoint, or run the harness on your own infrastructure.

‍

FAQ

Q: What is AgentCore harness?

A: AgentCore harness is AWS's managed agent harness inside Amazon Bedrock AgentCore, generally available as of 2026. The orchestration loop is provided and powered by Strands Agents, so you declare the agent as configuration, covering model, system prompt, tools, memory and execution limits, rather than writing the loop yourself. Sessions are stateful by default and run in an isolated microVM with their own filesystem and shell.

Q: What is the difference between AgentCore harness and AgentCore Runtime?

A: Runtime is serverless hosting and the harness is a managed loop that runs inside it. With Runtime you bring your own agent code in any framework, package it as an ARM64 container, push it to ECR, and write the orchestration yourself. With the harness there is no container and no loop to write. AWS logs harness operations under AWS::BedrockAgentCore::Runtime, which is the clearest signal of how the two relate.

Q: Can I use LangGraph or another framework with the agent harness AgentCore provides?

A: Not on the harness. AWS marks choice of agent framework as unsupported, because the loop is Strands Agents. You can run LangGraph, CrewAI or custom code on AgentCore Runtime, since Runtime is framework-agnostic by design, but moving to the harness means leaving that code behind. This is the main reason framework-committed teams stay on Runtime.

Q: Can I run an agent harness in my own VPC or on-prem?

A: With a self-hosted harness, yes. TrueForge runs from a single npx command locally, or via Docker Compose and Helm for team deployments with Postgres, Redis, replicas and OIDC login. TrueFoundry's managed platform also runs self-hosted, on-prem, air-gapped or hybrid, so no data leaves your domain. AgentCore harness supports VPC networking, but it runs in AWS.

Q: How do I govern models and MCP servers across a lot of agents?

A: Through a gateway layer, once per-team keys stop scaling. TrueFoundry's AI Gateway puts 1,000+ LLMs behind one OpenAI-compatible API at roughly 3 to 4 ms of added latency and 350+ RPS on a single vCPU, with RBAC, budgets, guardrails and credential rotation, plus OpenTelemetry traces into Grafana, Datadog or Prometheus. Agents on AgentCore, TrueForge or anything else get governed the same way.

Related reading

• Agent Harness vs Agent Framework: What's Actually Different?: the category distinction underneath this post
• Best Agent Harness in 2026: Top 5 Options Compared: how the field stacks up
• Best Open Source Agent Harness: the open options, if you're ruling out managed
• Claude Managed Agents Alternatives: the same decision with Anthropic's managed harness
• Amazon Bedrock Agents vs. The Control Plane: the wider AWS architecture question

Conclusion

AgentCore harness is a good product with a clearly marked boundary. It removes the loop, the container and most of the orchestration work, and in exchange it takes the framework choice, the hooks, the non-loop patterns and the context strategy. AWS is upfront about all of it, which makes the decision easier than it usually is.

So the question is not whether the harness is good. It is whether you want to own the loop your agents run on. If the answer is yes, or if long-running tasks are your normal case, an open harness is worth the extra day of setup.

npx @truefoundry/trueforge gets you a running agent in about a minute, or see how TrueForge handles context on long runs.

‍

‍