Agent = Model + Harness: what we learned putting agents in production

There is a formula that made the rounds this summer and it captures our last two years fairly well: agent = model + harness. The model is the part you do not control. The harness is everything else: the instructions, the tools, the limits, the validations, the memory, and the machinery that catches things going wrong.

What makes the framing interesting is the inversion of responsibility. For a while the expectation was that the model would handle safety, execution accuracy, remembering what matters, and coordinating long tasks. The industry landed on the opposite conclusion: the model is treated as a frozen reasoning calculator, and everything else is solved by the infrastructure wrapped around it.

What sits in our harness

When we started running agents against real client systems, the first instinct was to write better prompts. It barely helped. What moved the needle was building the structure around them.

A written contract. We keep a rules file that every agent reads before touching the repository. These are not style suggestions: they are concrete prohibitions born from mistakes we already paid for. "Never sync to production by hand." "Never hard delete records, use soft deletes." "Never start processes outside the process manager." Every line in that file exists because something broke once.

A narrow tool catalog. An agent that can do anything will do anything. Ours get a small set of actions, each with its own validation, and when they need something outside the catalog they have to ask.

Verifiers. After every task, a check runs that does not depend on the agent: the site responds, the test passes, the file exists. If the agent says "done" and the verifier disagrees, the verifier wins.

A human approval point. Actions that cannot be undone stop and wait. Not because the agent is careless, but because the cost of being wrong is asymmetric.

The uncomfortable part

The reported figure is that the vast majority of agent projects never reach production. Our read, having been on both sides of it, is that they almost always fail at the harness and almost never at the model. Swapping models is an afternoon. Building the scaffolding that makes one trustworthy is the actual job.

That is good news if you build things: the part that determines the quality of the outcome is exactly the part you control.

What this looks like for a client

In our chat-driven webmaster service, a client asks for a change to their site and it goes live in minutes. Behind that simplicity sits a fairly boring harness: the request gets interpreted, translated into a concrete task, applied in a separate working environment, verified so the site still responds, and only then published. If anything fails along the way, it rolls back and reports.

The client sees none of that. They see that they asked for something and it worked. That distance between what the user perceives and what runs underneath is, more or less, the definition of the craft.