The Harness: Why AI Agent Reliability Depends on the Code Around the Model
When we talk about AI Agent engineering, "models" often dominate the discussion — which model is stronger, how large the context window is, how fast the inference speed. But one problem has been chronically underestimated: what exactly does the engineering shell built around the model mean?
In his book Understanding AI Agents: Design Principles and Engineering Practices, Li Bojie borrows a term already existing in software engineering to describe this shell — Harness.
Starting from the original meaning of a word
Harness originally refers to the straps and reins put on a horse. This set of equipment is not meant to tie the horse down, but to directionally transmit the horse's power — allowing a powerful yet unpredictable animal to precisely complete tasks like pulling a plow or driving a cart.
In the context of Agent engineering, this metaphor is very precise:
- Horse → Large Language Model (powerful but unpredictable)
- Reins → System Prompt, constraint rules, Safety Filter (conveying directional instructions)
- Harness → Tool Calling, Memory, workflow orchestration (directionally outputting power)
- Driver → User / Business logic layer
- Direction the cart moves → Reliable completion of the task goal
Harness does not weaken the model's capabilities; it allows the model's capabilities to be controllably released along the task trajectory.
What is "Human Prior"
To understand the value of Harness, one must first understand what it compensates for.
Every constraint rule we write in Agent engineering today implicitly contains a judgment about the model's current state:
| Harness Rule | Implicit Judgment |
|---|---|
| Output must be valid JSON | The model will output randomly |
| Tool call count limit of N times | The model will get stuck in an infinite loop |
| Destructive operations require a second confirmation | The model is not cautious enough about destructive operations |
| Mandatory source citation after RAG recall | The model will hallucinate and fabricate |
These judgments are not learned from the current batch of data, but are brought into the system in advance by engineers based on existing experience — this is the "Human Prior." It is efficient in the short term, but is essentially a manual compensation for the current boundaries of the model's capabilities.
The Bitter Lesson and a reasonable concern
In "The Bitter Lesson" published in 2019, Rich Sutton reviewed a pattern that has repeatedly played out over seventy years of AI research: researchers time and again encode their understanding of a domain into a system, which works in the short term, but in the long term always loses to general methods — search and learning — that can continuously scale with computing power and data volume.
- The opening libraries carefully constructed by chess experts were crushed by AlphaZero's self-play.
- Hand-designed grammar rules in NLP were replaced by the brute-force pre-training of Transformers.
Viewing today's Harness engineering from this perspective, a reasonable concern arises: Are the constraint rules we write today just a new round of "Human Prior," destined to be internalized and eliminated by more powerful models?
This concern is not unfounded.
Harness is not resistance, but a relay
But the book's stance is not an evasion of this concern, but a direct response to it: Agree on the direction, be pragmatic on the pace.
Directionally, it acknowledges that Sutton is right. Models will get stronger, today's constraints will be gradually internalized, and every layer in the Harness will eventually have a day when it can be removed.
Pace-wise, this process of "being internalized" is much slower than intuition suggests. Model training is measured in months and cannot digest all the constraints and preferences of real business at once. The current capability boundary of the model is precisely the current value of the Harness.
This brings a dynamic engineering paradigm:
Where the model is still unstable, Harness fills the gap first; Every time the model internalizes a layer, Harness sheds that layer and shifts to cover the new capability frontier.
A specific evolutionary path might look like this:
Today: JSON format validation, hallucinated citations, loop count limits, deletion second confirmations — these are all handled by the Harness because the model is still unstable in these dimensions.
After the model gets stronger: Format output and source citation are internalized, and the corresponding Harness layer is removed. But the autonomy of tool calling and the reliability of multi-step planning become the new capability frontier, and Harness shifts here.
Even stronger later: Old planning constraints are removed, and Harness continues to move forward, covering the new capability boundaries that the model has not yet mastered at that time.
This is not trying to stop a cart with a mantis' arms; this is moving in the same direction as the Bitter Lesson — using engineering methods to ensure system reliability within the time window before the model completes its internalization.
Practical significance for engineers
Understanding this has a direct impact on the design of Agent systems.
Every Harness rule should have a clear exit condition. It is not a permanent architectural decision, but a temporary compensation for the current model capability boundary. When designing, it should be clear: at what level of which metric the model reaches, this rule can be removed or simplified.
The complexity of the Harness is a mirror of the model's capabilities. If your Harness is becoming increasingly heavy, either you are dealing with real capability boundaries, or you are using engineering complexity to cover up a system that shouldn't be online. Both situations are worth examining.
Removing a layer of Harness is itself an engineering milestone worth tracking. It means the model's capability in a certain dimension can independently take responsibility. This is a sign of the system's evolutionary maturity, just like deleting a piece of compatibility code that is no longer needed.
Conclusion
The essence of Harness engineering is maintaining a dynamic balance between model capability and business reliability. It is not a denial of the fact that "stronger models will eventually arrive," but the responsibility that engineers owe to system stability before that happens.
A harness will not stay on the same horse forever. But before the horse is fully tamed, the straps and reins are the necessary condition for making it truly usable.