The agent loop
An agent is a loop, not a single answer. The model reads the context, decides what it needs, and the harness runs that step and feeds the result back. The loop turns until the model stops asking for things or the harness stops it.
Order refund agent
This is the example most readers will have seen somewhere else, which makes it useful for seeing the mechanics rather than the domain. A customer asks for a refund. Looking up the order is harmless, so the agent is scoped to read it. Moving money is not, so the agent is not scoped to do that, no matter how reasonable the request looks or how confidently the model asks. Notice what the refusal does to the run. The model does not fail and does not stop. It receives the refusal the same way it receives any other result, and it writes a reply that explains the position instead of promising a refund it cannot make. The approval step at the end is doing separate work from the permission. The permission stopped an action. The approval checks the words before they reach a customer, which is a different risk and needs a different control.
The request
- From
- customer@example.com
- Channel
The jacket arrived damaged. Order 71142. I would like a refund to my card today please.
Agent scope
What this agent may do. Anything outside this list is refused by the harness.
- read:order
- read:policy
Context window
38% usedCompaction happens at 68%.
- Policy
- 12
- Instructions
- 10
- Conversation
- 16
- Tool results
- 0
- Press Run to watch the loop turn, or Step to move one event at a time.
This run
- Model turns
- 0
- Tool requests
- 0
- Blocked
- 0
- Checkpoints
- 0
- Restores
- 0
- Compactions
- 0
- Decision
- Pending
The six parts
Select one to highlight the steps it covers in the trace.
The six parts of a harness
Tool calling
The model never runs anything itself. It emits a structured request naming a tool and its arguments. The harness decides whether to honour that request. This separation is what makes the rest of the controls possible.
Context management
Everything the model reads has to fit in a fixed window. Tool results accumulate in it. When the window fills, the harness summarises the oldest conversation and keeps policy and instructions intact, because dropping those changes behaviour.
Checkpointing
A checkpoint records where the run had got to. When a step fails or the process dies, the harness restarts from the checkpoint instead of replaying the whole conversation, which costs tokens and can repeat side effects.
Permissions and sandboxing
Permissions decide what the agent may do before it does it. A call outside the agent scope is refused by the harness, and the refusal is returned to the model as an ordinary result so the run continues with one option removed.
Guardrails
Guardrails inspect what the model produced, after the fact. They catch content problems that a permission cannot, because a permitted action can still produce the wrong text. The two controls sit at different points and do not substitute for each other.
Other scenarios
- Registration support agent A refugee asks about an appointment. The agent can read the case but cannot change it, and the reply waits for a caseworker.
- Clinic scheduling assistant A patient asks to move an appointment. The agent reads scheduling fields only, cannot order tests, and the reply waits for clinical staff.
- Procurement request helper A colleague needs laptops. The agent can draft a requisition but cannot approve the purchase order, and the reply waits for a human.