Harness Engineering and the Rule of Law for AI Agents

Harness engineering is not about intelligence alone

A lot of discussion around AI still assumes that the main problem is model capability. People compare reasoning quality, context length, coding scores, benchmark performance, and tool use, as if better intelligence will eventually solve everything else.

It will not.

The real difficulty begins after the model has produced an answer. An agent does not live in a benchmark. It acts inside systems. It reads files, edits code, calls tools, triggers workflows, touches data, and sometimes makes changes that are expensive to undo. In that setting, raw intelligence is only one component. The harder question is whether the system around that intelligence is structured well enough to make its behaviour dependable.

That is where harness engineering becomes important.

The harness is the part that decides how an agent is allowed to operate, what it must prove before moving forward, where it must stop, what can be done automatically, what has to be reviewed, how actions are recorded, and how failures are turned into new controls. In other words, the harness is not the mind. It is the governing structure around the mind.

That distinction matters. A clever agent without a strong harness is like a talented but unsupervised operator: occasionally brilliant, often useful, but not yet trustworthy enough for serious work.

The legal analogy is stronger than it first appears

At first sight, comparing harness engineering with the British legal tradition may sound like an overextended metaphor. But the comparison holds up surprisingly well.

The British legal system is not sustained by statutes alone. It works through an accumulated mix of rules, interpretation, precedent, procedure, evidence, institutional memory, and practical judgement. It develops by meeting real disputes, exposing gaps, and absorbing those lessons into a more stable body of doctrine.

Harness engineering follows a similar pattern.

An agent produces an output that looks convincing but cites no evidence. A tool call succeeds technically but violates a business boundary. A code change solves one problem while quietly breaking three others. A workflow takes the most direct path when it should have taken the safest path. The team looks at the trace, identifies the failure mode, and then updates the system: add a validator, narrow permissions, split planning from execution, require a checklist, force a structured artefact, or insert a human approval gate.

That is more than debugging. It is closer to doctrine-building.

The important point is that the system improves not only by changing the model, but by refining the rules, procedures, and boundaries within which the model acts. That is why the comparison with common law feels natural. Experience does not remain anecdotal. It is converted into operating discipline.

But the deeper similarity is not precedent. It is governance.

The most interesting parallel is not that both law and harnesses learn from cases. It is that both exist to govern uncertainty.

Law is often described as a body of rules, but that is only a small part of what makes a legal order work. A real legal system also has to answer questions such as these:

What counts as evidence?
Who has authority to act?
Which procedures must be followed?
How are exceptions handled?
What happens when something goes wrong?
How does the system adapt when it meets a situation that the original rules did not anticipate?

Harness engineering is beginning to answer the same class of questions for AI systems.

A mature harness does not merely tell an agent what to do. It defines what counts as a justified action. It decides when evidence is sufficient, when a task must be decomposed, when autonomy is acceptable, when review is mandatory, and how the system distinguishes a plausible answer from a reliable one.

This is why I think many people still describe harness engineering too narrowly. They treat it as workflow design, or prompt layering, or tool orchestration. Those are parts of it, but not the core of it. At its heart, harness engineering is a governance problem.

Procedure matters more than people expect

One of the reasons modern societies depend on legal systems rather than wise rulers is that judgement alone does not scale. Even very capable people are inconsistent. They get tired, overconfident, distracted, or rushed. The role of procedure is to reduce the damage caused by all of those very ordinary failures.

The same applies to agents.

A surprising number of agent systems are still built as if good judgement will somehow emerge from stronger models plus a few broad instructions. That may work in a demo. It may even work for a while in low-risk situations. But once the environment becomes messy, the absence of procedure becomes obvious.

Without procedure, agents skip verification because the answer looks plausible. They take shortcuts because the shortest path appears efficient. They carry hidden assumptions from one task into another. They overgeneralise from incomplete context. They perform actions in the wrong order. They succeed often enough to appear useful, but fail unpredictably enough to remain dangerous.

A good harness introduces procedure precisely to counter this. It requires certain steps to happen in order. It forces evidence before conclusion. It separates planning from execution where necessary. It narrows the scope of action. It creates checkpoints between thought and consequence.

This is not glamorous work, which is why it is easy to underestimate. But it is usually the difference between an interesting system and a usable one.

The harness is closer to a constitutional layer than a prompt layer

This, I think, is the deeper insight.

People often talk about the harness as if it sits outside the model like some optional wrapper. In practice, it functions more like a constitutional layer. It decides what powers the agent has, what limits cannot be crossed, what must remain inspectable, what evidence is admissible, and what kinds of action require higher levels of scrutiny.

That is not a minor implementation detail. It is a decision about power.

Once you see it that way, a lot of current problems in agent design become easier to explain. Many systems look impressive in short demonstrations because they have reasoning ability, tool access, and initiative. But they feel fragile in production because they lack constitutional order. They have capability, but not a settled regime for governing that capability.

That is why some agent systems feel energetic but unsafe. They are operating under permission without doctrine.

A model may be able to reason its way toward an answer. But the harness decides whether that reasoning is allowed to have effect, under what conditions, with what proof, and with what traceability. The harness therefore does not just organise work. It allocates authority.

Harness engineering is more interventionist than law

There is, however, one important way in which harness engineering goes beyond the legal analogy.

A judge usually interprets the rules of a system that already exists. A harness engineer can redesign the environment itself.

When an AI system fails, the response does not have to be limited to a narrower interpretation of the rule. The engineer can change the entire setting in which the behaviour occurs. They can remove a tool, add a validator, divide one agent into several specialised roles, enforce a new output schema, require staged execution, restrict file access, insert approval gates, or change the structure of memory and logging.

This is a much more direct form of governance. The harness does not merely judge conduct after the fact. It shapes the conditions under which conduct becomes possible in the first place.

So the best version of the analogy is not simply that harness engineering resembles case law. It is closer to a combination of common law, civil procedure, evidentiary standards, institutional design, and enforcement. That is one reason it will probably become more important than most people currently realise.

The goal is not perfect judgement. It is controlled failure

Another useful comparison with law is this: a good legal system is not one that is never wrong. It is one that limits arbitrariness, reduces serious mistakes, makes errors reviewable, and creates ways to correct them.

Harness engineering should be judged in the same way.

The aim is not to build an agent that never fails. That is unrealistic. The aim is to build a system in which failure is less arbitrary, less expensive, more visible, and easier to correct. A strong harness does not eliminate mistakes. It changes the shape of mistakes.

It pushes failure toward cheaper stages. It makes risky actions harder to take without justification. It keeps important decisions inspectable. It reduces the chance that a plausible but false answer turns directly into an irreversible action. It ensures that when a system fails, the failure leaves behind a useful trace rather than a mystery.

This is a much more mature way to think about AI systems. The right question is not, “How often is the model right?” The right question is, “When it is wrong, what kind of wrong is it allowed to be?”

That is a governance question, not an intelligence question.

The real commercial moat is likely to be doctrine

From a business point of view, this may matter even more than model quality.

Model capability will continue to spread. More companies will gain access to strong foundation models, competent coding systems, larger context windows, and better tool use. That part of the stack is already moving toward commoditisation.

What is much harder to copy is the operational doctrine that sits around those models.

A production-grade harness contains accumulated experience. It reflects the specific ways tasks should be decomposed, the points at which review becomes necessary, the evidence standards that matter in a domain, the failure patterns already observed, the risks the organisation is willing to accept, and the logs required for accountability. None of that appears automatically just because a company has access to a strong model.

This is why I suspect the long-term moat in agent systems will not simply be “having agents”. It will be having a tested and disciplined doctrine for governing them.

That doctrine will often look unremarkable from the outside. Much of it will consist of constraints, procedures, validation rules, escalation paths, audit formats, and exception handling. But that is exactly the point. Mature systems are often held together by things that seem boring until they are absent.

From rule by vibes to rule by doctrine

If I had to compress the whole argument into one line, it would be this:

Harness engineering is the move from rule by vibes to rule by doctrine.

A lot of current AI work still operates on loose intention. The system is given broad goals, generous autonomy, and a rough set of instructions. Sometimes the results are genuinely impressive. But the consistency is weak because the discipline is weak.

Doctrine is different. Doctrine means the system has explicit operating principles. It means there are settled ways to justify action, settled ways to review outputs, settled ways to handle exceptions, and settled ways to record what happened.

That does not make the system rigid. Quite the opposite. Well-formed doctrine allows flexibility without collapse. It allows the system to adapt without becoming arbitrary.

That, in the end, is why the legal analogy works so well. The value of law is not that it removes judgement. It is that it gives judgement a structure. Harness engineering is trying to do the same for autonomous systems.

Conclusion

Harness engineering should not be understood as a temporary fashion or a smarter way to write prompts. It is the beginning of something more serious: the attempt to build governed environments for machine agency.

The comparison with the British legal tradition is useful because it directs attention to the right place. Reliable systems are not built from intelligence alone. They are built from doctrine, procedure, evidence, constraint, memory, and review.

But the comparison also has limits, and those limits reveal something important. Harness engineering is, in some ways, even more ambitious than law. It does not only interpret behaviour. It redesigns the environment in which behaviour happens.

That is why I think the future of agent systems will be decided less by who has the most impressive model demo, and more by who can build the most credible regime around autonomous work.

The real shift is not from weak AI to strong AI. It is from ungoverned agency to governed agency.

And that is a much bigger step than it first appears.