Agent Harness vs Agent Framework: What's Actually Different?

What Is an Agent Framework?

An agent framework gives you the building blocks to assemble an agent. It provides structure and abstractions; you provide the logic that ties them together.

A typical framework hands you:

• A way to define steps. Nodes in a graph, roles in a crew, functions in a chain.
• A way to connect them. Edges, conditions, handoffs, sequences.
• A state model. Usually a typed schema you declare, threaded through every step.
• Model bindings. Adapters so the same code runs against different providers.
• Execution. A runner that walks your structure until it terminates.

LangGraph is the clearest example. You declare nodes, edges and a shared state schema, and it executes until a node returns END. CrewAI takes a different shape with the same idea: declare agents with roles and tasks, and let it run them sequentially or hierarchically. Microsoft Agent Framework, which merged AutoGen and Semantic Kernel at its 1.0 release in April 2026, does the same for .NET and Python.

A framework works best when:

• Your workflow has a required shape, and deviating from it is a correctness problem
• You need conditional branching, parallel fan-out, or loops back to earlier stages
• Different steps need different models, prompts or tool sets
• You want the execution path to be legible in code, not inferred from a prompt
• A human has to approve at one specific point in the flow

What Is an Agent Harness?

An agent harness is the runtime layer around an LLM that turns it into a reliable, long-running agent. Not primitives for building a loop. The loop itself, already built.

A model on its own reasons but can't act. Give it a task and you get a plan and nothing else. It can't open a file, call an API, run the code it just wrote, or remember what it decided three turns ago. The harness closes that gap and keeps closing it for the length of the run.

A typical harness handles:

• The execution loop. Plan, call a tool, read the result, decide what's next, repeat.
• Context management. Compaction, deferred tool loading, offloading oversized tool responses, so a long run doesn't blow the window or the budget.
• Sandboxing. Isolated execution for code, files and shell commands.
• Approvals. Pausing before destructive tool calls and waiting for a human.
• Session state. Persistence across reconnects, restarts and multi-turn conversations.

TrueForge, Claude Agent SDK, opencode, Pi and OpenHands are all harnesses. You supply tools and instructions; you don't supply the loop.

A harness works best when:

• The path is discovered rather than designed, and the next step depends on what the last step found
• You want an agent working this week rather than a workflow architecture
• Runs are long enough that context management becomes the thing that breaks
• The agent executes code or touches a filesystem and needs isolation
• You'd rather tune prompts and tools than maintain a state machine

Core Differences

Both get you to a working agent. They differ in what you're responsible for.

Two questions that tell them apart

Product pages won't settle this, so use these instead.

Do you write the loop?

If you're declaring edges, conditions, or a sequence of steps, that's a framework. If you're supplying tools and instructions and pressing go, that's a harness.

Does it manage context for you?

‍Frameworks generally hand you the state schema and let you decide what goes in the window. Harnesses have to manage it, because they own the loop and a long run will otherwise fill the window and stop working. If nothing in the docs mentions compaction, offloading or deferred tool loading, you're probably looking at a framework.

Why the Terms Get Confused

Three reasons, and the first is the big one.

Some products are genuinely both. deepagents is LangChain's harness built on top of LangGraph, which is a framework. It ships a complete loop with planning, a virtual filesystem, subagents and memory, so it behaves like a harness. Underneath, it's a graph. Microsoft Agent Framework does something similar, shipping both the orchestration primitives and an opinionated harness layer on top.

Marketing follows search volume. "Framework" has been the established term for years and carries more traffic. "Harness" only started appearing in 2026. Plenty of harnesses still call themselves frameworks because that's the word buyers type.

The line moves as products mature. Frameworks add opinionated defaults and start feeling like harnesses. Harnesses expose hooks and start feeling like frameworks. Microsoft shipping an Agent Harness layer inside Agent Framework is exactly this, and there will be more of it.

None of that makes the distinction useless. It just means you have to check the behavior rather than the label.

They Are Not Mutually Exclusive

The framing that trips teams up is treating this as a choice. Most production systems use both, at different layers.

A harness handles the agent loop and everything that has to happen every turn. A framework handles orchestration between agents, or the deterministic workflow a harness-driven agent sits inside. Fan out to five agents, wait for all of them, run a validation step, then hand off. That's a framework's job, and the thing at each node can be a harness.

The mistake is using a framework to rebuild a loop that already exists. Authoring a graph for an agent whose path is genuinely open-ended means writing a worse version of what a harness gives you for free, and paying for it in maintenance forever. The opposite mistake is real too: forcing a harness to follow a rigid compliance workflow by describing the sequence in a prompt and hoping.

TrueForge: Best Agent Harness for Production Teams

TrueForge is the MIT-licensed harness we open-sourced in August 2026, and the same runtime behind our own AskTFY agent. We built it because we wanted managed-agent ergonomics without handing the model decision to a vendor, and nothing open source covered the whole surface.

It ships as three pieces rather than one. A core server runs the loop: streaming, approval gates on sensitive actions, subagent delegation, compaction, and sessions that survive reconnects. An HTTP API with a TypeScript SDK (@truefoundry/trueforge-sdk) gives your code everything the UI can do. And a chat UI with its own SDK (@truefoundry/trueforge-ui) is there to use as-is, theme, or embed. That third piece is what separates it from most of this list, which stops at the terminal.

The design choice that moves your bill most: TrueForge treats the sandbox as a tool. It spins one up only when the agent actually needs to run code, instead of wrapping the whole session in a container. One server handles many agents at once, and turns that never touch code stay cheap.

What it adds on top of the loop is the context work, because that's what decides whether long runs stay affordable. Deferred tool loading means MCP tool schemas load on demand rather than filling the window upfront. Code Mode lets the agent chain several tool calls inside one sandbox script so only the printed summary enters context. Oversized tool responses get written to a sandbox file and replaced with a path and a preview. Compaction triggers at 80% of the model's context length and replaces old history with a structured summary. Subagents run with their own clean context and return only the result.

On DevRev's Enterprise-Bench, which is 14 cross-system tasks over three MCP servers with a fresh session each time and a blind LLM judge, TrueForge on Opus 4.8 solved the same tasks as Claude Managed Agents at $8.5 per run against $11.8, on 3.8M tokens against 10M. Swapping to GLM-5.2 took it to $2.9 per run. Against deepagents on the same model it used under a quarter of the tokens.

It's MIT-licensed, maintained by us, and developed in the open. The strengths are those three surfaces, on-demand sandboxing, a documented path from npx all the way to Helm with Postgres, Redis, replicas and OIDC, and published benchmark numbers you can check. The obvious weakness is age. It's the youngest project here, so the third-party extension ecosystem is thin compared to what opencode has.

Try it in 60 seconds: npx @truefoundry/trueforge or star it on GitHub.

An Open-Source Alternative to Claude Managed Agents, Up to 75% Cheaper

Run production-ready AI agents on your own infrastructure with TrueForge, using your choice of models, tools, and sandbox providers.

View on GitHub

Docs

FAQ

Q: What is an agent harness?

‍A: An agent harness is the runtime layer around an LLM that turns it into a reliable, long-running agent. It owns the execution loop and handles context management, sandboxing, approvals and session state, because a model on its own can reason but can't act, execute or remember across turns.

Q: What is the difference between an agent harness and an agent framework?

‍A: A framework gives you primitives to build an agent and expects you to author the control flow. A harness is the finished runtime with the loop already written, so you supply tools and instructions instead. Frameworks are for building agents; harnesses are for running them.

Q: Is LangGraph an agent harness or a framework?

‍A: LangGraph is a framework. You declare nodes, edges and a state schema, and it executes your graph. deepagents, which is built on LangGraph, is a harness, because it ships a complete loop you don't have to write. A product can contain both layers.

Q: Do I need both?

‍A: Often, but at different layers. Use a harness for the agent loop and a framework for orchestration between agents or for a deterministic workflow the agent sits inside. What you shouldn't do is use a framework to hand-build a loop that a harness would give you for nothing.

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

‍A: Yes, with an open source one. TrueForge runs from a single npx command locally, or through Docker Compose and Helm for team deployments with Postgres, Redis, replicas and OIDC login. TrueFoundry's managed version also runs self-hosted, on-prem, air-gapped or hybrid, so no data leaves your domain.

Q: How do I govern models and MCP servers across many agents?

‍A: Through a gateway layer. TrueFoundry's AI Gateway puts 1,000+ LLMs behind one OpenAI-compatible API at roughly ~3–4 ms of added latency and 350+ RPS on a single vCPU, with RBAC, budgets, guardrails and credential rotation, plus an MCP Gateway for tool-level access control and OpenTelemetry traces into Grafana, Datadog or Prometheus.

Related reading

• Best Agent Harness in 2026: Top 5 Options Compared: the field, once you've decided you want a harness
• Introducing TrueForge: the open-source agent harness we run in production: architecture and design decisions
• TrueForge vs Claude Managed Agents: Up to 75% Cheaper: what the harness layer does to cost
• Why Agent Harnesses Should Be Open: the case against renting this layer
• How TrueFoundry's own AskTFY runs on TrueForge: a production agent built on a harness

Conclusion

The short version: a framework is for building an agent, an agent harness is for running one. If you find yourself writing the loop, you picked a framework. If the loop came with the box, you picked a harness. Plenty of teams need both, at different layers, and the expensive mistake is using one to rebuild what the other already does.

If what you want is the loop without writing it, TrueForge is on GitHub and npx @truefoundry/trueforge takes about a minute. If you want to see how the same harness runs governed, with budgets, RBAC and unified traces, that's the TrueFoundry Agent Harness.