How it works
Harness engineering treats the model as an untrusted, capable worker and puts the engineering effort into the layer around it. You don't tune the agent to be safe; you build a structure that stays safe regardless of what the agent decides on any given run.
The layer is assembled from a few repeatable primitives:
- A bounded loop that decides, acts, and observes on a fixed budget of steps and tools, so a run cannot expand without limit.
- A permission surface that scopes what the agent can touch — read/write boundaries, least-privilege credentials, sandboxed execution — so capability is granted, not assumed.
- Checkpoints and reversibility so state can be snapshotted and rolled back, and every effect has an undo path.
- Approval gates on the small set of actions that are irreversible or high-blast-radius, where an operator's sign-off is required before the effect lands.
- Observability — structured traces of decisions, tool calls, and evidence — so a run is legible after the fact, not a black box.
The point is separation of concerns. The model supplies judgment inside the loop; the harness supplies the guarantees around it. A well-built harness makes strong claims about what can't happen even when the model is wrong, misled by injected content, or simply unlucky.
Why it matters in an agent harness
Models are stochastic. The same prompt can produce a good trajectory today and a destructive one next week, and no amount of prompt tuning removes that tail. Harness engineering is how you get production behavior out of a non-deterministic component: you stop trying to make the agent reliable and make the system reliable instead.
Concretely, the harness is where four properties come from. Control comes from bounded loops and tool budgets, not from asking the model to behave. Reversibility comes from checkpoints and undo paths, so a bad run is a rollback rather than an incident. Legibility comes from traces you can read, so you can evaluate what happened and improve it. Containment comes from least-privilege scoping and sandboxing, so a failure stays small.
This also changes how you evaluate agents. Once the harness records trajectories, you can run regression evals against real runs, gate deploys on them, and catch drift. Without the harness there is nothing durable to measure — only anecdotes about a prompt that used to work.
Harness engineering vs prompt engineering
Both improve agent behavior, but they act at different layers and fail differently. The distinction decides where you invest.
| Prompt engineering | Harness engineering | |
|---|---|---|
| Layer | Inside the model call | Around the model |
| Guarantee | Improves the average run | Bounds the worst run |
| Failure mode | Silent regression when the model or input shifts | Explicit, testable boundary |
| Durability | Brittle across model versions | Survives model swaps |
Prompting shapes the distribution of outputs; it never removes the dangerous tail. Harness engineering assumes the tail exists and makes it survivable. You still write good prompts — but you don't let a prompt be the thing standing between an agent and an irreversible action.
The Rifty take
We optimize for what can't happen over what usually happens. A harness earns its keep on the worst run, not the median one, so we spend our engineering budget on reversibility and approval gates rather than on squeezing another point of average quality out of a prompt. We accept slower, more gated execution as the price of an operation that holds together. The boundary we enforce is simple: an operator's judgment is carried in the structure, and nothing irreversible executes without it.
Implementation checks
- Enumerate every irreversible or high-blast-radius action and confirm each one sits behind an explicit approval gate.
- Give the agent least-privilege credentials scoped to the current task, not standing access.
- Snapshot state before a run and verify you can actually roll back, not just that you intended to.
- Cap loops with step and tool budgets so a run terminates on its own.
- Persist structured traces of decisions and tool calls, and make them the input to your evals.
- Sandbox tool execution so a bad call is contained to a disposable environment.
- Treat external content the agent reads as untrusted data, never as instructions to the harness.
Frequently asked questions
How is harness engineering different from just building an agent?
Building an agent focuses on the model's reasoning and tools. Harness engineering focuses on the control layer around it — permissions, budgets, checkpoints, and approval gates — so the system stays controllable and reversible even when the agent makes a wrong or manipulated decision on a given run.
Does a harness slow the agent down?
It adds gates on the actions that are irreversible or high-blast-radius, so those steps wait for an operator or a check. That is a deliberate tradeoff: you accept slower execution on risky actions in exchange for a system that fails small and recovers by rollback instead of incident.
Where does an operator's judgment live in a harness?
It lives in the structure, not in a person watching every step. Approval gates, scoped permissions, and defined reversibility encode which decisions require sign-off and which can proceed. This carried judgment lets an agent run autonomously on safe actions while pausing precisely where human judgment is required.
What are the core primitives of a harness?
A bounded agent loop with step and tool budgets, a least-privilege permission surface, sandboxed execution, checkpoints with real rollback, approval gates on irreversible actions, and structured observability. Together they let you make strong claims about what cannot happen regardless of what the model decides.
Isn't good prompting enough for reliability?
No. Prompting improves the average run but never removes the dangerous tail, and it silently regresses when the model or input shifts. Harness engineering assumes that tail exists and bounds the worst run with reversibility and gates, so reliability comes from the system rather than the prompt.