An agent harness is the code, configuration and execution logic that wraps a language model and turns it into an agent: the system prompt, the tools and their descriptions, memory, orchestration, the sandbox the agent works in, and the checks that decide when its work is done. The model supplies the reasoning. The harness decides what the model sees, what it is allowed to do, and whether the result counts.
Agent = model + harness
The clearest statement of the idea is a formula LangChain published in March 2026: Agent = Model + Harness, where the harness is "every piece of code, configuration, and execution logic that isn't the model itself." Put simply, the model contains the intelligence and the harness is what makes that intelligence useful.
The formula matters because it moves the reliability question. When an agent gives a wrong refund amount or loops on a tool call, the cause is rarely the model's raw capability. It is usually something the harness did or failed to do: a tool description that invited the wrong call, a context window that dropped the policy, a missing check before the answer went out. The same model behaves very differently in two harnesses, which is why teams now treat the harness as the thing they engineer.
What a harness contains
Harnesses differ by use case, but most production harnesses assemble the same parts.
| Part | What it does | Example |
|---|---|---|
| Instructions | Tell the model its role, rules and output format | System prompt, policy text, few-shot examples |
| Tools | Let the model act on the world, and describe when to use each | Search, a refunds API, code execution, MCP servers |
| Context and memory | Decide what the model sees on each turn | Retrieval, conversation summaries, user preferences |
| Orchestration | Control the flow between steps and agents | Planning loops, sub-agent handoffs, model routing |
| Workspace | Give the agent somewhere safe to work | A sandbox, a file system, a browser |
| Checks | Decide whether an action or an answer is allowed through | Schema validation, permission checks, tests, human approval |
| Telemetry | Record what happened, step by step | Traces of every model call and tool call |
Frameworks give you building blocks for these parts. The harness is your particular assembly of them, running your agent against your users.
Guides and sensors
A useful way to sort the parts comes from Birgitta Böckeler's April 2026 article on harness engineering. Guides are feedforward controls: they anticipate the agent's behaviour and steer it before it acts. Instructions, tool descriptions and retrieved context are guides. Sensors are feedback controls: they observe after the agent acts and help it correct. Tests, validators, linters and review are sensors.
A mature harness has both, and places each sensor as early as it can run. A schema check runs on every response. A test suite runs before merge. Some sensors are too slow or too expensive for the request path and run later, against the traffic the agent has already handled. That last group is where most harnesses thin out.
The half most harnesses are missing
Look at where the sensors in a typical harness sit. Nearly all of them run before release or inside a single request. Very few run against what the agent does in production over days and weeks, and fewer still feed what they find back into the harness.
Source: LangChain, State of Agent Engineering, n=1,340, December 2025. Figures are among organizations with agents in production.
The gap between those two numbers is the missing half. Teams collect the traces, so the evidence of every failure exists. What is missing is the loop that reads it: something that notices the same failure happening a hundred times, names it, decides whether it matters, produces a fix, and makes sure the fix holds. Without that loop, a fixed failure is fixed by hope. Nothing stops the next prompt edit or model upgrade from bringing it back.
Coding agents widened the gap. Building and changing the harness is now fast, so it changes often, and every change is a chance to reintroduce a failure someone already fixed. The build half of the lifecycle got automated. The half that checks whether the agent still works in front of real users mostly did not.
What a self-healing harness does
A self-healing harness closes that loop. Production failures flow back into the harness as fixes and as new sensors, so the harness gets stricter every time the agent fails. The loop has five steps, and each one needs a specific capability.
- Observe. Read every run from the traces the harness already emits: each model call, tool call and outcome, grouped into sessions.
- Diagnose. Group failing sessions into named failure modes, so a thousand bad conversations become a short list of problems with evidence behind each one.
- Evaluate. Score runs with judges, and check those judges against labels from the domain experts who know what good looks like. A judge that disagrees with the experts is not a sensor yet.
- Fix. Propose a change to the prompt, a tool contract or the flow, and prove it against the failures that caused it and against every past correction before a person merges it.
- Gate. Turn the confirmed failure mode into a regression test with a tracked baseline, and run it on every release. This is the step that makes the fix permanent.
The last step is the one that separates healing from patching. A patch fixes today's failure. A gate turns that failure into a sensor, so the harness checks for it on every change from then on. Over time the harness accumulates a test suite written by production itself, made of the failures that actually happened rather than the ones someone imagined.
Two properties keep the loop trustworthy. Every fix goes through human review, so the loop proposes and proves while a person decides. And every judge is measured against human experts, so the automated verdicts stay tied to the people who define quality.
Adding the missing half to the harness you have
You do not need a new harness to close the loop. The steps below work with any stack.
- Emit complete traces. Record every model call, tool call and final outcome, with a session id that ties a conversation together. OpenTelemetry is the common format, and many agent frameworks export it with configuration alone.
- Pick one agent and one outcome. Choose the agent closest to a number someone is measured on, such as containment, resolution time or cost per case. Start there.
- Name the failures. Read failing sessions until patterns repeat, then give each pattern a name and a definition. Grouping by similarity speeds this up once volume grows.
- Write a judge per failure mode, then check it. Have a domain expert grade a sample. Measure how often the judge agrees, and fix the judge before you trust it.
- Turn each confirmed failure into a regression test. Build a dataset from its real evidence sessions, set a baseline pass rate, and fail the release if the rate drops.
- Prove fixes before merge, and watch them after. Run the proposed fix against the failure's evidence and the existing tests, merge through normal review, then confirm in production that the failure rate fell.
Each step is useful on its own. Together they give the harness a feedback path it did not have: production teaches it, and it does not forget.
Questions
What is the difference between an agent and a harness?
The agent is the model and the harness together. The model supplies the reasoning; the harness supplies everything else: the instructions, the tools, the memory, the control flow and the checks that decide when work is done.
Is a harness the same as an agent framework?
No. A framework is a library you build a harness with. The harness is your specific assembly: your prompts, your tools, your routing and your checks, running your agent.
What is harness engineering?
The discipline of designing and improving the harness rather than the model: what the agent sees, what it may do, and how its output is checked. Much of an agent's reliability comes from this work, because the same model behaves very differently in different harnesses.
What makes a harness self-healing?
A closed loop from production back into the harness. Failures in real traffic are detected, grouped into named failure modes, scored by judges checked against human experts, fixed, and turned into regression tests, so a failure that was fixed cannot silently return.
Do I need to replace my harness to make it self-healing?
No. The loop reads the traces your harness already emits and returns fixes and tests to your repository through the review process you already use. The harness keeps running the agent.
Sources
- Vivek Trivedy, The Anatomy of an Agent Harness, LangChain, 10 March 2026.
- Birgitta Böckeler, Harness engineering for coding agent users, martinfowler.com, 2 April 2026.
- LangChain, State of Agent Engineering, n=1,340, December 2025.