A language model can propose a tool call, but it cannot execute the call, retain the result, or decide when to stop without software around it. That surrounding software is the harness.

A recent breakdown shared by @shao__meng on X, discussing the essay "What is a Harness?" by Earendil co-founder Colin Daymond (@pidotdev), gives a compact formulation:

Model ≠ Agent. What transforms a language model into an agent is the Harness:
Agent = Model + Harness
A model generates predictions. The harness supplies tools, state, execution rules, and the loop that lets the model act on results.

Where the model stops

I use harness for the code that turns model output into a running process. It supplies instructions and tool definitions, executes approved calls, stores the results, sends them back to the model, and decides whether the run may continue. Some harnesses also translate tool schemas between model providers, but that is an implementation choice rather than part of the definition.

The distinction matters most when something fails. If a tool is called with bad arguments, the harness decides whether to reject it, retry it, ask the user, or stop. If a write needs approval, the harness enforces that boundary. Changing the model may improve the proposed action; changing the harness changes what actions are possible and how they are controlled.

Local execution, custom tools, and provider routing are capabilities a harness may expose, not a four-part taxonomy shared by every product. I would check those capabilities directly rather than infer them from the word agent or from whether a product has a chat interface.

"We wield the hammer, rather than allowing the hammer to wield us."
— Colin Daymond, Earendil

Primary links and resources