Module 2 · Lesson 3 of 8
Our assistant has requested a calendar check. Who sends that request? Who returns the answer to the model? What happens if the connection fails?
These are software responsibilities. The model does not independently manage the application around it.
The harness operates the agent
The surrounding software that runs an agent is often called its harness. A useful comparison is a workshop: the worker needs equipment, a workspace, records of the job, and boundaries on what can be done. The workshop does not supply every judgment, but it makes useful work possible.
The analogy has limits. A model is not a person in a room. In practice, the harness is code that assembles model inputs, processes outputs, dispatches tool requests, and manages execution.
Follow one request through the harness
Suppose the model asks to check Riverside Hall. The harness checks that this is an available operation and that its arguments are valid. It calls the calendar service, receives the response, and includes the relevant result in the next model input.
If the service returns an error, the harness can apply a retry rule or expose the failure to the model. If the run reaches its limit, the harness can stop it even if the model requests another action.
The prompt is only one part
A prompt can say “Do not book without approval.” The booking operation should also check approval in code. Otherwise, a sentence in the model's instructions is carrying a responsibility that belongs in the execution system.
The same principle applies to budgets. The assistant can reason about affordability, while an actual payment tool enforces an allowed amount and account access.
What belongs in a harness?
The term varies between projects. It commonly covers the model-and-tool execution loop and context handling. A broader implementation may also manage saved progress, permissions, logs, timeouts, and the workspace used by tools.
For our event assistant, useful records include which venues were checked and which quotes are still current. A record that a tool was called is different from proof that a reservation succeeded; the result matters too.
For one concrete implementation, Anthropic separates its harness, session record, and execution environment in Scaling Managed Agents.
Harness and loop are related, but different ideas
The loop describes the repeated behavior. The harness is the software operating that behavior. A graph, which we will introduce shortly, describes how the wider work is connected.
These boundaries need not match separate products or code packages. One application can implement all three. Naming them helps us ask better questions about responsibility.
If a model chooses a useful action but the tool is never called, look at execution. If the model repeatedly sees outdated information, look at context handling. Improving an agent can mean improving the software around the model.