The word harness is useful because it names the part people often forget: the surrounding software.
An agent harness typically handles things like:
- the system prompt and runtime rules
- tool definitions
- execution of requested tools
- memory or state management
- retries and stopping conditions
- logging, permissions, and safety checks
Why the harness matters
Two products can use the same underlying model and still feel completely different because their harnesses are different.
The harness determines what the model is allowed to do, what information it sees, how it recovers from failure, and when it stops. In many real systems, that surrounding design matters just as much as the choice of model.
So when evaluating an “agent,” it helps to separate:
- model capability
- tool access
- harness design
- task definition
That separation makes discussions about agents much clearer and much more practical.