The Harness Has to Learn

A useful agent harness gives a model instructions, tools, context, and a loop. That turns a language model into a worker that can inspect a repository, make a change, run a command, and react to what happened. The mechanism matters. Without it, the model can describe work but cannot carry the work through its consequences.

Still, a tool loop is easy to overvalue. If every run begins with a generic prompt, a broad tool list, and no memory of prior failure, the harness has only automated the session. A person still has to explain the environment, watch the worker, spot the same bad turn, and restate the correction next time. The typing moved. The management did not.

The durable asset is not the shell around the model. It is the operating experience encoded inside that shell: which context arrives for this kind of task, which worker gets the route, where a critic interrupts, what evidence counts, and how a failed run changes the next one. That is where a harness stops being a convenience and starts becoming machinery.

One agent can plan, build, inspect, and declare itself finished. It can also carry one misunderstanding through every stage. The same context that made a choice look reasonable during planning will make that choice look reasonable during review. Asking the worker to become its own critic does not create independence. It creates a second explanation from the same point of view.

Separate roles create useful pressure. A planner has to make the objective specific enough for someone else to execute. A worker has to produce the change and the trace. A critic has to attack the assumptions, not polish the answer. A verifier has to reproduce the result under conditions the builder did not choose. The handoffs force hidden beliefs into artifacts another stage can reject.

This is not a request for an army of agents chatting in a circle. Every role needs a narrow purpose, a bounded input, and a decision that changes the route. If the critic can object forever without blocking or repairing anything, it is theater. If verification accepts the builder's story instead of independent evidence, it is narration. Roles earn their place by changing what happens next.

Teams often collect instructions in files and call the collection a system. The files may contain excellent advice. That does not mean the advice governs the work. If the agent can skip the instruction, choose an easier check, or finish without producing the required evidence, the skill is documentation with optimistic branding.

A real skill changes the route through the harness. It determines what must be read, which tools are available, what shape the output takes, which checks run, and where the work must stop. It turns a known way of doing the job into an executable boundary. The model can still reason inside that boundary, but it cannot quietly redefine the job after seeing the result.

This is why the model is rarely the lasting advantage. Models improve and prices move. The route remains: the context selection, permissions, budgets, role boundaries, acceptance gates, and recovery behavior. Build those controls around replaceable workers and the system can adopt a better model without forgetting how the business works.

The easiest way to waste expert judgment is to trap it in a review comment. Someone notices that a request was ambiguous, a permission was too broad, or a test proved the wrong thing. The immediate work gets fixed. Then the next run enters through the same route and charges the organization for the same lesson again.

A learning harness sends the correction upstream. Ambiguity changes the planning template. Missing context changes retrieval. An authority mistake narrows a permission. A weak test changes the acceptance gate. A repeated failure changes routing or budget. The lesson becomes part of the environment every later worker inherits, regardless of which model is underneath it.

Not every correction belongs in a prompt. Some belong in schemas, policy, tests, tool boundaries, or monitoring. That distinction is important because prose is the easiest control for an agent to reinterpret. Put deterministic knowledge in deterministic machinery. Reserve model judgment for the places where the answer genuinely depends on context.

A good demo proves that an agent can complete a path once. A production harness has to prove that the path gets better after it fails. Ask what survives the session. Ask which correction changes the next run, who can inspect that change, and whether the improvement still holds when the model, repository, or operator changes.

Our prediction is that repeatable coordination around software work will move into these systems. Fewer people will be needed to package context, relay instructions, watch routine runs, and repeat standards the machinery can retain. Human judgment moves toward choosing objectives, defining consequences, and deciding which lessons deserve to become controls. That shift will eliminate roles built around manual coordination; pretending otherwise will not slow it down.

The harness is where the worker meets the work. Make that meeting accumulate experience. Give each role a decision, give each decision a gate, and give every meaningful failure a path back into the system. The model will change. The tools will change. The part worth owning is the machinery that remembers what the organization learned.