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.
Clinic scheduling assistant
Health is where the difference between a narrow and a broad permission stops being theoretical. The agent here can read a schedule, but the scope is written against scheduling fields rather than the patient record, so a diagnosis or a medication list is not in reach even though it sits in the same system. That is sandboxing doing its job: the boundary is drawn around what the task needs, not around what the database happens to hold. The blocked call is a lab test. Ordering one is a clinical decision with a cost and a consequence, and no amount of plausible reasoning from a model makes it the model decision to take. The reply then waits for clinical staff, because a message to a patient carries weight that a message about a parcel does not. The same structure appears across the AI in health use cases on this site.
The request
- From
- Patient 9043
- Channel
I cannot make Thursday. Can you move my appointment and also check whether my blood test is due?
Agent scope
What this agent may do. Anything outside this list is refused by the harness.
- read:schedule
Context window
43% usedCompaction happens at 70%.
- Policy
- 16
- Instructions
- 12
- Conversation
- 15
- 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.
- 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.