How an AI harness works

A model on its own produces text. Everything that makes an agent useful, and everything that makes it safe to deploy, sits in the code around the model. That code is the harness. It assembles the context, receives the tool requests the model emits, decides which to honour, writes checkpoints, keeps the window inside its limit, checks the output and stops at the point where a person has to take responsibility. The simulator below runs a single agent request through those six parts so you can watch where each one acts. Nothing here calls a model. Every step is derived from a scenario you can read, change and share.

Simulator

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% used

Compaction happens at 72%.

Policy
14
Instructions
11
Conversation
18
Tool results
0
  1. 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.

Everything stays on your machine. Sharing puts the scenario in the link itself, not on a server.

The six parts of a harness

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.

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.

Common questions

What is an AI harness?
A harness is the code that runs around a model to turn it into an agent. It builds the context the model reads, executes the tool calls the model asks for, enforces what the agent may and may not do, and decides when to stop. The model supplies judgement. The harness supplies control.
How is a harness different from an agent framework?
A framework is a library you adopt. A harness is the specific set of controls your system enforces, whether you wrote them yourself or inherited them from a framework. Adopting a framework does not tell you where your permission boundary sits or who approves an outgoing message. Those remain decisions you have to make and be able to evidence.
What is the difference between permissions and guardrails?
Permissions decide what the agent may do, before it acts. Guardrails inspect what the agent produced, after it acts. A permitted action can still produce the wrong text, and a well-worded output can still have come from an action that should never have run. They sit at different points and neither substitutes for the other.
Why do checkpoints matter?
Long runs fail part way through. Without a checkpoint the only option is to start again, which costs tokens and can repeat side effects that already happened, such as a message already sent. A checkpoint lets the harness resume from the last known good state instead.
Where should the human sit?
At the point where an action becomes hard to reverse or leaves the organisation. Reading a record is routine. Moving money, changing a booking or sending a message to a member of the public is not. Putting a person in front of every step produces review fatigue and the approvals stop being real.
What can a harness not catch?
It cannot tell you the model reasoned badly within its permissions. If an agent is allowed to read a case and summarises it wrongly, every control here passes and the output is still wrong. That is why output checks and human approval exist at the end, and why the scope of what an agent may do should stay narrow.

Worked 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.
  • 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.

Related reading: agentic AI governance, the AI agents track, and the AI glossary.