A framework gives you building blocks for an agent. A harness is those blocks already assembled, with defaults, policy and a record around every run.
The two words are used loosely, and the difference decides who writes the code that keeps an agent safe: your team, or the software you adopt. This guide sets out the four layers of an agent stack, what each one owns, what a harness adds on top of a framework, and how to choose.
Updated · 9 sources
An agent framework is a library of abstractions — an agent loop, model adapters, a tool interface — that developers assemble into an agent. An agent harness is the assembled system around the model: it ships with prompts, tools, context management, approvals, failure handling and run records already in place. In agent harness vs agent framework, the framework hands you parts and the policy decisions; the harness makes those decisions by default and runs every agent under them.
LangChain’s Harrison Chase drew the line in October 2025: a framework’s main value is its abstractions; a harness comes “with batteries included”. Read each row as the question “who decides this?”.
Abstractions for writing agents. You choose the model, write the loop’s policy, wire the tools and decide what happens when something fails.
An opinionated, assembled agent system. Prompts, tools, planning, context handling and safety checks are there before you write a line.
LangChain’s March 2026 definition is the cleanest: a harness is every piece of code, configuration and execution logic that isn’t the model — hence Agent = Model + Harness. These are the parts it usually contains.
Where the word came from. Engineers have long called the code that drives a program under test a “test harness”. When Anthropic renamed its SDK in September 2025, it described it as “the agent harness that powers Claude Code”.
Published results point the same way: change what surrounds the model and the same model performs very differently. That is why the layer you adopt or build deserves as much scrutiny as the model you pick.
Anthropic’s guidance on long-running agents shows the same thing in practice: the fix for agents that lose track across sessions was harness work — an initial session that writes a feature list and a progress file, and later sessions that pick one feature, test it and commit — rather than a different model.
The layers stack, and products often span two of them. Place a tool on this line by asking how many decisions it has already made before your agent’s first run.
Take one agent: it reads supplier invoices, matches them to purchase orders and proposes payment holds. The model and the prompt are the same either way. What differs is the list of things someone must build and keep working.
agent = Agent(
model = "your-model",
instructions = INVOICE_PROMPT,
tools = [read_invoice, find_po, hold_payment],
)
# still yours to write and run:
# - which users may call hold_payment
# - pause hold_payment for a person
# - trim context on 80-page invoices
# - retry or switch model on failure
# - keep a record of every step
# - cap spend per team
result = run(agent, invoice)Neither path is wrong. The framework path is quicker to a demo and gives full control; the harness path is quicker to a second, third and fiftieth agent, because every one of them inherits the same answers.
Anthropic’s advice for builders is to start with model APIs directly and, if you use a framework, to understand the code underneath. The question that settles the rest is who will keep the policy working once the first agent is live.
Who must the agent answer to once it is live?
Every Botminds agent runs inside one enterprise harness. The parts a framework leaves to you ship with their rule already in place, and the rule holds whichever model is underneath.
| Agent framework | Botminds agent harness | |
|---|---|---|
| What it is | A library to build agents with | The running system every agent lives in |
| Tool access | Whatever the code passes in | Granted by name and checked on every call; read-only basics by default |
| People in the loop | Build it yourself | Approve, reject or edit, on the tools you choose |
| Context and memory | Build it yourself | Budgeted tiers, two kinds of memory, a preview of the exact prompt |
| When a model fails | Build it yourself | On document and background runs, the next model in a pool across providers and regions |
| Spend | Outside its scope | Token quotas checked at the one door every run passes |
| Ways to run | One loop | Fast, thinking, auto and autonomous on one harness |
| Who maintains it | Your engineers | The platform, for every agent at once |
Read the full design in the agent harness. To build one yourself, start with agent anatomy and tools and functions in the Academy.
In agent harness vs agent framework, a framework is a library of abstractions you assemble into an agent, and you decide tool access, approvals, context handling, recovery and logging yourself. A harness is the assembled system around the model, with those decisions made by default for every agent it runs.
An agent harness is every piece of code, configuration and execution logic around a language model that lets it work as an agent: the loop, the system prompt, the tools, context management, approvals, recovery and the record of each run. LangChain summarises it as Agent = Model + Harness.
LangChain describes its core library as an agent framework, its durable-execution layer as an agent runtime, and a separate batteries-included package as its agent harness. The company itself notes that the boundaries are still fuzzy.
A runtime keeps agent runs alive in production: durable execution, streaming, persistence and pauses for a person. A harness decides what happens inside each run: the prompt, the tools, the context and the checks. Many products combine both.
Anthropic calls it a harness. When the Claude Code SDK was renamed in September 2025, Anthropic described it as the agent harness that powers Claude Code, usable for many other kinds of agent.
No. Orchestration decides which step or agent runs next. A harness governs what happens inside one agent’s run — what it sees, which tools it may call, when a person must approve, and what is recorded.
Harness engineering is improving an agent by changing what surrounds the model — its prompt, tools, tool descriptions, context handling and checks — rather than the model itself. Published results show harness changes alone can move an agent a long way on benchmarks.
Build one if you have a single agent and the engineers to own its safety parts for its whole life. Adopt one when many teams will run many agents, because tool policy, approvals, recovery and audit then need to be solved once and inherited by all of them.
Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.