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.
Registration support agent
A registration support agent sits between a person asking a question and a case management system holding their record. The question is ordinary: when is my appointment, and can it move. Answering it needs two different kinds of access. Reading the case is routine and the agent is scoped for it. Changing the appointment affects a real slot in a real office, so the agent is not. The run below shows what happens when the model asks for both. The refusal is not an error. The harness returns it to the model as a result, and the model carries on with one option removed. The draft that comes out at the end goes to a caseworker rather than to the person, because the standing rule is that outgoing messages to a beneficiary are approved by a human. That is the whole shape of a harness: the model proposes, the harness decides, and a person signs the part that leaves the building.
The request
- From
- Case 48213
- Channel
- SMS
Hello, I have an appointment this week but I cannot travel. Can you tell me the date and move it to next month?
Agent scope
What this agent may do. Anything outside this list is refused by the harness.
- read:case
- read:appointment
Context window
43% usedCompaction happens at 72%.
- Policy
- 14
- Instructions
- 11
- Conversation
- 18
- 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
- Order refund agent A customer wants money back. The agent can read the order but cannot issue the refund, and the reply waits for a human.
- 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.