Harness engineering

Harness engineering is the practice of designing everything around a language model that makes an agent reliable. The harness includes the instructions the model receives, the tools it can call and what each is allowed to do, the context it is shown, the checks that run on its outputs, the points where a person must approve, and the logs that let someone reconstruct what happened.

The shortest way to state the idea is that an agent equals a model plus its harness. The term came into wide use in 2026 after the writing in the article on harness engineering. I use it in the same sense.

In practice

When an agent fails, the first question I ask is whether the harness let it fail. A wrong answer that reached a customer is usually a missing check, a tool with too much permission or context that was not selected carefully. Only after those are ruled out do I look at the model.

In my enterprise work, most of the reliability comes from the harness. That is also where the engineering effort should go, and where the evaluation results should point.

Example

[Composite] An agent that updated purchase orders made a duplicate update after a timeout. The model was not changed. The harness gained an idempotency key on each tool call and a rule that a retry must check the current state first. The duplicates stopped, and the change was covered by the regression evaluations.

Common mistakes

• Spending most of the effort on the prompt and little on the tools and checks.
• Giving the agent tools with broad permissions because narrow ones take longer to design.
• Logging only the final answer. The sequence of calls is what a reviewer needs.