Skip to content

What an AI Harness Is

Ayub Roti

8 min read 0 comments

An AI harness is the layer between an agent’s decision and the world’s consequence. The agent chooses what to do. The harness decides whether that is allowed, does it inside limits a person set, and writes down what happened. It is the part of an agent system that does not think, and that is the point.

Why the word fits

A harness on a horse does not make the horse slower or less capable. It makes the horse’s strength usable. It transmits force in the direction the driver chose, it keeps the animal within the shafts, and when something goes wrong it is the harness, not the driver’s voice, that holds.

That is the right picture for an AI agent. A language model in a loop with tools is strong and wilful. Shouting instructions at it in a prompt is the driver’s voice. It works most of the time. A harness is what works the rest of the time, because it is built of things the model cannot talk its way past: an API that refuses, a container that cannot see the host, a ceiling that pauses the run, a record that cannot be edited afterwards.

The short version: an agent is intelligence, a harness is accountability, and the two are different components with different owners. The model vendor supplies the first. You own the second.

Why the usual answers fall short

Three things get called a harness that are not one. Each is useful. None is sufficient.

Prompt rules. “Never delete files. Always ask before sending email.” These live in the model’s context and are obeyed by a probabilistic reader. They fail silently, they fail under pressure from the task, and they fail when someone pastes text into the context that says otherwise. A rule the model can be argued out of is advice, not a control.

A sandbox. A container, a VM, a restricted user. This bounds what the agent can damage, which matters. But a sandbox answers one question, “what can it reach”, and stays silent on the others: should it have done that, who asked for it, what did it cost, and what will we know afterwards. A sandboxed agent can still loop for an hour against a wall, spend the month’s budget, or run the right tool at the wrong target inside its bounds.

Guardrails. Filters on input and output: block this topic, redact that pattern. They inspect text. An agent’s risk is in actions, and the text an action produces is not the action. A guardrail can stop the model from printing a credential and do nothing about the tool call that used it.

The gap all three share is the same. They try to shape what the model does from inside the model’s world. A harness stands outside it, at the one place every action has to pass: the call from the model to a tool.

Anatomy

Every action an agent takes passes through the harness on its way to the world, and every result passes back through it on the way to a person.

Anatomy of an AI harness: the agent on the left never touches the world directly; the harness translates, checks, isolates, limits and records, declared work reaches the world and the record reaches a person

The harness sits between the agent and everything it can touch. Drawn as text, rendered by Vizo.

The agent is on the left and never touches the right side directly. The harness translates what the agent wants into something declared, checks it, runs it in isolation, keeps it under limits, and records it. The record is what a person reads, and it is also what feeds back into the harness as learning. The arrow from record to translate is the only way the system gets smarter, and it carries advice, never permission.

The six duties

A harness has six jobs. Drop any one and the others leak.

  1. Translate. The agent expresses an intent, “scan these hosts”, and the harness turns it into a declared workload: a named tool, a fixed image, exact arguments. The agent chooses which. The declaration fixes how. Free-form shell is the absence of this duty.
  2. Check. Before anything runs, one checkpoint asks: is this tool on the agent’s allowlist, are the arguments inside its scope, does this serve a step of its plan, and has any ceiling already been hit. The check happens at the API, where the model’s words carry no weight.
  3. Isolate. The work runs where it can do only what it was declared to do: a container on an execution node, and the model’s own turns on a worker that holds no database, no provider key and no long-lived credential.
  4. Limit. Turns, tokens, wall clock, repetition, failures, drift and spend each have a ceiling. When one trips, the run pauses and asks a person. Limits only ever narrow as work is handed down.
  5. Record. Every decision, allowed or denied, with the actor, the accountable person, the version in force and the arguments, redacted. Append-only and hash-chained, so the record can be verified by someone who does not trust the operator.
  6. Learn. Failures become patterns that warn about or block the next matching attempt. Working specs become templates. But learning changes what the system tries, never what it may do. A person promotes every lesson.

The first five are about one run. The sixth is about the next one.

What each approach can promise

Question Prompt rules Sandbox Guardrails Harness
Can the agent reach only what it should? No Yes, within the box No Yes, per tool and per argument
Can it be argued out of a rule? Yes No Sometimes No
Does it stop a loop or a spend spike? No No No Yes, by ceiling
Does it know who asked and who is accountable? No No No Yes, on every action
Is there a record a third party can verify? No Logs, if kept No Yes, append-only and chained
Can the agent widen its own permissions? Yes No Yes No, a person reviews every change
Does it get better from failures? By editing the prompt No No Yes, by reviewed learnings

The table is not an argument against the other three. A good harness contains a sandbox and may well use guardrails on model output. It is an argument against calling any of them a harness on its own.

How Cazi carries each duty

Cazi is the harness we run our own agents through, and it is the reason this post can be concrete. One line per duty.

  • Translate. Tools are YAML workload specs and saved templates with a TARGET placeholder. An agent picks one over MCP. It never gets a shell.
  • Check. One interceptor in front of every tool call tests the pinned allowlist, the argument-level scope, the plan step and the breakers. The API repeats the check for every request made with a run’s credential.
  • Isolate. Each task is a container on an execution node. Model turns run on agent workers that hold no database, no provider key and a job token good only for that turn.
  • Limit. Eleven breakers, from tokens and turns to drift and daily spend. A trip pauses the run for a person. Budgets narrow down the delegation tree and never widen.
  • Record. Every unit of work names the actor, the accountable person and the route in. The activity log is hash-chained per tenant by a database trigger, and the chain head can be copied somewhere Cazi cannot write.
  • Learn. Failures and tripped breakers become proposed learnings. A person promotes them to warn or block. Agents may propose, capped at warning, and nothing they propose changes an allowlist.

The design is written up in more depth in our two earlier posts, one on Cazi’s architecture and one on what an agent is.

Five questions to ask of any harness

The word is becoming popular, so here is how to tell whether a thing deserves it. Ask these of the vendor, or of your own team.

  1. Where is the check? If the answer involves the prompt, the system prompt or “the model is instructed to”, it is not a check. The check lives at the API, where the model’s words are data.
  2. What does a new agent start with? The right answer is nothing. An agent that starts with every tool and is trimmed down later has already run once with everything.
  3. Can the agent change its own permissions? Through any path: editing itself, creating a helper agent with more rights, promoting a rule. Every path should end in a person’s approval.
  4. What happens at the ceiling? A harness pauses and asks. A system that merely logs the overrun, or retries, has a monitor rather than a limit.
  5. Could an auditor who distrusts you verify the record? Append-only is necessary and not sufficient. The record has to carry who, for whom, under which version, and a chain that shows if anything was removed.

If the answers are good, the agent can be as clever and as autonomous as you like. That is what the harness is for. It does not make the horse slower. It makes it safe to let it run.

Discussion 0

Markdown supported 0 / 2,000

No comments yet

Be the first to share a perspective.