Agent Harness
The model proposes the next move. The harness makes that move executable, bounded, observable, and recoverable.
Minimum Responsibilities
| Layer | Responsibility |
|---|---|
| Loop | alternate model turns, tool calls, results, and stopping conditions |
| Context | select instructions, history, files, and retrieved evidence |
| Tools | validate arguments, execute calls, return structured results |
| Policy | enforce scope, permissions, approvals, budgets, and safety boundaries |
| State | preserve task progress, artifacts, and resumable checkpoints |
| Reliability | timeouts, retries, idempotency, cancellation, and failure reporting |
| Observability | traces, logs, token/cost data, and tool-call evidence |
| Evaluation | test outcome quality on representative tasks |
An agent that merely loops until the model says “done” has orchestration, but not a dependable harness.
Practical Design Order
- Define the outcome and an external success check.
- Expose the smallest useful tool set.
- Separate read-only actions from writes and irreversible actions.
- Preserve artifacts and evidence outside the conversational transcript.
- Add time, token, retry, and concurrency limits.
- Trace model turns and tool calls with sensitive-data controls.
- Replay representative tasks before changing the default model or reasoning level.
Model-Agnostic Rule
The harness owns quality gates; the model is a replaceable component. A more capable model may reduce retries or instruction complexity, but it does not remove the need for evidence, permissions, and end-to-end checks.
That is why model selection belongs in a dated Model & API Radar, while this note changes only when the architecture itself changes.