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.
Procurement request helper
Internal tools are where people most often assume the controls can be relaxed, on the grounds that the user is a colleague rather than the public. This run shows why that reasoning does not hold. The agent can read the catalogue and draft a requisition, because both are reversible and someone reviews the draft anyway. Approving the purchase order commits budget, so it is outside the scope even though the person asking is entitled to spend and the amount is small. Scope follows the consequence of the action, not the seniority of the requester. There is a second point worth watching in the trace. The draft requisition is a write the agent is allowed to make, which shows that permissions are not simply read good, write bad. The line sits at what cannot be undone without someone noticing.
The request
- From
- r.khalil@example.org
- Channel
- Chat
We need four laptops for the new field team. Can you raise the request and approve it so they arrive before the mission?
Agent scope
What this agent may do. Anything outside this list is refused by the harness.
- read:catalogue
- write:draft_requisition
Context window
39% usedCompaction happens at 66%.
- Policy
- 13
- Instructions
- 12
- Conversation
- 14
- 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.
- 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.