Hand an agent a bug to fix, some data to analyze, or an incident to writeup, and it already does a convincing job. Execution is the part that looks solved. The question that follows is how to hand it more, and the default answer is to ask more of the agent itself: a bigger task, more access, less oversight. One prompt that says build the whole thing and make no mistakes. Sometimes that works, which is why every team tries it.
But eventually the agent's context window fills and the middle of the work goes missing. Splitting the job across sub-agents trades one failure for another: they cooperate imperfectly, and a single hallucinated sub-step quietly throws off the run. So a person stays camped beside the agent, redirecting by hand, and every increase in ambition is paid for in more manual intervention.
The way to keep the ambition without the price is a harness: a mix of agentic inference and deterministic code. Agent sessions run where inference is genuinely needed; ordinary code runs before, between, and after. The harness routes work, validates output, feeds checked results back in, and executes every step that needs no judgment at all.
Everything added to a harness is capability you can engineer. The deterministic parts are tested like any other code, the inference parts are evaluated against a standard, and the line between them is a decision you own: what to infer and what to simply execute. How much an org can hand its agents, and how sure it can be of what comes back, is a property of the harness, not of the model.
This guide follows a team whose agent writes software. They ended up with everything the default story promises: real features shipping overnight and unattended. They got there by giving the agent less. The inference multiplied into more sessions with narrower jobs, while capabilities left the agent one by one and came back as ordinary code in the harness. Building it was how they learned, stage by stage, where inference belongs and where plain code will do, and how to structure and orchestrate the inference itself.
Harness engineering is the practice of increasing what agents can take on while keeping the quality of what they produce demonstrably high. This guide walks that practice in stages, each opening on the general lesson the stage taught. The ending up front: the team never came to trust the agent more. They built a system that does not require trust.
The stages ahead are told in the vocabulary of Working with Robots, Go Between's framework for how an engineering org decides where to invest in AI: four domains of work, divided into disciplines, each with an investment tier that describes how deep a team has gone. Every stage ahead closes with a readout of where this team's investments sit. One principle runs under everything that follows. What comes out of an agent is a function of the system around it and of what is handed to it. The framework names this principle , and the framework itself is the place to go deeper.
General lessons
The whole guide in miniature: skim the six lessons without the story, or follow one into the stage that taught it.
Every harness begins as a loop that stops when its person does, and is defined by the act it performs without waiting for a person. Choose that act before the first run, and fence it: bound what it may touch so the worst case stays small.
Humans and machines should keep one set of books. Whatever record your harness runs on belongs on one surface both can read and write, and every handoff between person and machine should happen through it.
An agent's claim to have done the work is not evidence it did. Never let the agent be the reporter of record: have it request side effects, let deterministic code perform them, and check what happened by re-running the harness's own checks, not by reading the agent's summary.
Write down which rules the system enforces and which are only requests in a prompt, then close the gap. A boundary that is only implicit is discovered by the next incident.
Run the harness in a second home, a project it has never seen, and it tells you what it actually is. The context agents work from belongs to the home; the machinery that injects it belongs to the harness, and the interface you are forced to declare is exactly that boundary.
A harness is proven on its bad days. List what can break while nobody is watching, and give each failure its machinery: bounded repair attempts, stops that record their reason, a record to read in the morning.
Followed to the end, the lessons build a steady state that spans all four domains of the framework.
- Context
Sessions are fed the issue, the index file the task needs, and the handoff state, assembled from records that survive between sessions.
The system maintains its own memory of the codebase, a record people read but never have to keep.
- Control
Side effects are requested by agents and performed by deterministic code, and every enforced rule is also written where people can read it.
The workbench is verified before work starts and healed when broken; every limit ends in a stop with its reason recorded.
- Observability
Every run leaves a typed trail in the tracker and a queryable database: people read both, and so do the machines.
- Improvement
Judging the harness stayed deliberately Expert-led, and what proved out propagated to every project at install time.
Stages
Every harness begins as a loop that stops when its person does, and is defined by the act it performs without waiting for a person. Choose that act before the first run, and fence it: bound what it may touch so the worst case stays small.
Start smaller than feels serious. A harness begins the day the team stops redirecting an agent by hand and writes that hand-work down as code. The machine does the work; the person does everything around the work: aiming the loop, feeding it, checking it, keeping the books.
That delegated act, the consequential thing the system does with no person in the loop, is what makes this a harness; a system where every consequential action waits for sign-off is a tool. The assistant in the sibling evaluations field guide holds an act of its own, answering a customer unsupervised. Swap one act for the other and the stages ahead barely change.
Every delegated act needs its fence, and the biggest delegation decision is which class of work the loop may touch at all. That decision stays with a person. So does the other one: what to build is never handed over. That is the framework's principle at its earliest and its largest.
- Human judgment
- The operator. Runs the loop one feature at a time, keeps the books by hand, and marks the state when a session fails.
- AI labor
- The feature itself: implementation and a fresh-eyes review, merge included.
Framework investments
- . Both decisions visible from day one. The review session merges its own PR, and what to build never leaves the person. : one person's rules.
- . A reset script returns the workbench to a known state; the test suite is the only gate.
- . An append-only log that exists because one person keeps it: Expert-led.
Techniques
- . The JSON state file the harness treats as authoritative: structured state resists quiet rewriting better than prose.
- . The full test run as the one gate a feature must clear before the merge.
Humans and machines should keep one set of books. Whatever record your harness runs on belongs on one surface both can read and write, and every handoff between person and machine should happen through it.
Every harness runs on a record. A delivery harness works from a queue of planned work; the evaluations guide's practice runs on a log of every customer conversation its assistant has handled. Yours runs on something else. The stage-zero arrangement, machine state in one file and a human-readable copy in another, is double bookkeeping. The copies drift: an agent told to keep both current will sometimes update only one. Collapse them into one record that humans and machines both read and write, kept where the team already looks.
A shared record does three jobs. The machine's work becomes visible for free, because the state is the status and nobody writes status updates. The machine gains a surface it can be held to: a transition either happened on the record or it did not. And the record becomes the counter where person and machine trade work. People put in what the machine should do, and read out what it did. Every handoff, in either direction, happens through it.
Filling the record is its own craft, a planning conversation that turns intent into scoped issues, and it is the only place a harness takes work from.
- Human judgment
- The backlog author. Fills the tracker through a human-led planning conversation, presses start, and watches.
- AI labor
- Finding its own next piece of work: the loop drains the backlog without being re-aimed.
Framework investments
- . What to do next is read from the board: the first responsibility delegated to the system rather than the session.
- . State becomes visible where the team already looks.
- . The issue becomes the context feed. Every session opens on the ticket pulled live.
Techniques
- . The state file's shape lifted into the tracker's workflow states, now enforced by machinery instead of kept by habit.
- . The live integration that makes the tracker readable and writable from inside the loop: the board is the state, not a copy.
An agent's claim to have done the work is not evidence it did. Never let the agent be the reporter of record: have it request side effects, let deterministic code perform them, and check what happened by re-running the harness's own checks, not by reading the agent's summary.
A harness can run unattended long before it can be trusted to. The gap is made of claims: the agent reports that it ran its checks, performed its side effects, updated the record, and it is sometimes wrong, confidently. The machinery re-runs the checks itself and reads the exit codes. The agent's account of what happened is never the gate again.
The counterintuitive half is what to do with the agent's tools: not extending the agent's reach as trust grows, but reversing it. The agent stops executing side effects entirely. It requests them in a structured form its output carries, and deterministic harness code performs them.
The immediate payoff is that a side effect performed by code is an observation, not a report. A prohibition becomes a fact: "may not touch the PR" is a request while the agent holds the tools, and an impossibility once it no longer does. The mechanical layer becomes engineerable, too. Retries, race guards, and idempotent re-runs are fixed once in ordinary code rather than in prompts, where guidance is only ever followed sometimes.
Every capability left inside the agent is paid for in trust on every run; every capability moved into the harness is paid for once, in engineering. That is the principle, applied to actions instead of information.
- Human judgment
- The mechanic. Fixes the harness between the agent's overnight PRs, and leaves the happy path to the machine.
- AI labor
- The whole delivery path, executed rather than claimed: checks re-run by the machine, side effects performed by deterministic code on the agent's signal.
Framework investments
- . The verification gate climbs to . The checks fire inside the machinery on every run.
- . The agent requests side effects, software performs them. Unsupervised scope went up the same week the agent's direct reach went down.
- . From one person's prose log to a record nothing can skip: typed comments on the issue, a database underneath. Structural.
Techniques
- . The agent asks for each side effect through a typed marker in its output; the harness performs the action in deterministic code.
- . Lint, tests, and end-to-end checks re-run by the harness after every session, exit codes as the gate.
- . Every message, tool call, and harness event is written to an append-only local database.
Write down which rules the system enforces and which are only requests in a prompt, then close the gap. A boundary that is only implicit is discovered by the next incident.
Enforcement accumulates faster than anyone writes it down. By now, what a harness enforces versus what it merely asks for is implicit, scattered across prompts and harness code. So write the contract: one document a person can read, naming the roles the machine plays, what each may and may not do, and which rules are backed by code. Its standing rule holds anywhere. If a rule is enforced in code, it is a hard requirement; if it lives only in a prompt, it is guidance the agent may or may not follow. The inform-versus-enforce boundary is written down first, then built.
Each role deserves a tool surface chosen on purpose, and what a role is denied matters as much as what it is granted. The most deliberate denial is context: a reviewer that cannot see the implementor's reasoning cannot inherit the implementor's assumptions.
A machine can only hand work between its own sessions through state that survives them. Nothing in a context window does.
The shared record from Stage 1 and the typed trail from Stage 2 make the handoff possible at all.
- Human judgment
- The rule-writer. Writes the contract and decides which of its rules the harness will also enforce in code.
- AI labor
- Its own working memory: the machine ends a session running low on context and hands the successor the state.
Framework investments
- . The boundary becomes in one place, each written rule paired with enforcement: written where people read it, enforced where the machine acts.
- . Each session's tool surface is decided and written down. No session holds a tool its contract does not grant.
- . A fresh session is fed exactly the state it needs, assembled by the machine from the record.
Techniques
- . One document naming each session's entry and exit states, required outputs, and do-not lines, with the code-enforced rules marked.
- . The harness detects a session nearing its context ceiling and writes the fresh session's briefing itself from the typed comments.
- . On a failed check, a narrow repair session carries the failure output and every prior attempt. The loop is capped at a fixed number of cycles and ends in a human's hands.
Run the harness in a second home, a project it has never seen, and it tells you what it actually is. The context agents work from belongs to the home; the machinery that injects it belongs to the harness, and the interface you are forced to declare is exactly that boundary.
The tell that a harness is ready to leave home is fixes ferried by hand between the copies of it living inside each project.
Leaving home forces the system to declare what it needs from any host, and to surrender everything it had merely gotten used to. The second home does not have to be a codebase: for the evaluations guide's assistant, it is a second product's customers and policies. And a harness that will only ever have one home still profits from asking what it would need from one, because the interface it would have to declare measures what it has coupled to.
That is the line extraction draws. A harness never runs in a vacuum; it runs primed with its home's context. The context belongs to the home, and the mechanism that injects it belongs to the harness.
investment survives people turnover; extraction makes a harness survive project turnover. Even institutional memory moves into the machinery, as an agent-maintained index of what has been built, which humans consult but never have to keep.
- Human judgment
- The installer. Sets up each host's side of the interface: the check scripts, the orientation docs, the conventions.
- AI labor
- Knowing the codebase: the index is written by the machine and read by the machine; humans consult it instead of maintaining it.
Framework investments
- . Verification points at the workbench itself. The host interface is checked before any session runs.
- . The index is kept current by a hook in the harness's own lifecycle, and the updater is itself an agent session: nobody's chore.
- . An improvement made once reaches every host at install time.
Techniques
- . The host's own orientation file, read at the start of every session: stack knowledge lives with the stack.
- . An agent-readable index of what has been built, routing a session from its task to the one file it needs.
- . The install script re-copies the harness into a host, so one repo's improvements ship everywhere on the next install.
- . Each session type gets its own model and reasoning budget in one config file: the strongest models on planning and review, a cheaper one on execution.
A harness is proven on its bad days. List what can break while nobody is watching, and give each failure its machinery: bounded repair attempts, stops that record their reason, a record to read in the morning.
Budget a closing stretch of work that exists only for the bad days. None of it adds capability; all of it teaches the machine to have its bad day alone.
The record laid down in Stage 2 is what absence runs on.
Not every discipline needs the climb; a deliberate stop is an investment decision too.
For a three-person team's internal tooling, with the record making the expert's read cheap, Expert-led was the right tier. The principle in practice: a tier says where you are, not how you rank. is the discipline the evaluations field guide climbs all the way to .
And the run went unattended only because people had done the scoping in advance.
- Human judgment
- Absent. Before the run, planning the backlog; after it, reading the record; during it, nothing.
- AI labor
- The bad day: broken main, state races, cancelled issues, network failures, its own stuck sessions.
Framework investments
- . Structural as a steady state. The workbench is checked and healed before work begins, and every limit ends in a recorded stop.
- . Deliberately Expert-led from first stage to last: no written standard, no benchmark. The record made the expert's read cheaper; the standard stayed in their heads.
- . The closing readout. Unsupervised scope at its maximum, the agent's direct hold on side effects at its minimum.
Techniques
- . The harness counts the attempts, stops the loop, and records why, so a stuck run surfaces as a request a person can act on.
- . One record read three ways: a live monitor, the expert's after-run queries, and the agents' own lookups.
What steady state can do
Step back and the human's seat climbs a ladder as the machine absorbs the work below: operator, backlog author, mechanic, rule-writer, installer, and finally nobody inside the loop at all. The history runs opposite to the story the guide opened on. The most dangerous action was delegated on day one, the agent's direct hold on side effects only ever shrank, and what grew for seven months was the structure around it. The team never came to trust the agent more; they no longer needed to.
The structure alone never bought the unattended hours. The final run needed both: a harness that let the hours pass unattended, and a scoped, criteria-fenced backlog that made them productive. A perfect harness fed vague intent ships vague software overnight. What comes out is a function of the system and of what was handed to it. The second factor is its own practice, and it deserves a guide of its own.
The definition of done is neither a finished feature list nor a system that must be worked on forever. Development went quiet at month seven; the run a month later shipped a whole product anyway. A harness is done enough when its development stopping is not an event: the improvement loop idles, small flaws persist because they cost nothing, and the system keeps delivering.
To place your own team, start with the question this journey turns on: what is your system's merge? Name the delegated act, the thing your system does with nobody watching, and the fence that makes its worst case survivable. Then ask what it would take to run your harness in a second home. Whatever that answer enumerates is your real interface; the rest is what your system has merely gotten used to. From there, read the tiers of Delegation and Environment honestly. This guide walked one path; yours will hold a different act and touch the same disciplines in a different order.
Put it to work.
Feel these trade-offs for yourself on a worked example, or take the framework, this guide included, to the agents your team already uses.
Feel it in play.
The game hands you a hypothetical: your team is shipping an authentication service with AI in the loop, and you have eight chips of investment to spread across the twelve disciplines. Place them and you get back a memo reporting how the next six months went under those bets. Move a chip and the memo rewrites, so you can feel exactly where the trade-offs live.
Take it with you.
The bundle is the whole framework in files your agent can read. Give it to Claude, Cursor, or whatever you already use, then ask where your own org stands. It is plain reference material: no code, nothing that runs.
Or install it with one line
mkdir -p ~/.claude/skills && curl -fL https://gobetweenlab.com/working-with-robots/working-with-robots-framework.tar.gz | tar -xz -C ~/.claude/skillsOther field guides
Browse the framework
The agent has what it needs to act.
- CollectionGetting context in: gathering the artifacts an agent needs to orient.
- ManagementKeeping the context your agents read current as decisions and conventions change.
- DisclosureFeeding context in efficiently: routing the agent to the slice it needs, not a data dump.
The agent can only do what it should.
- CapabilityWhat the agent can do: the tools you connect, and the ones you deliberately withhold.
- DelegationWhat the agent should do: the responsibilities you hand over, and the ones you reserve.
- EnvironmentThe system the agent works within: the tests and gates its work must clear, and the points where a human takes over.
The human can see what happened.
- CaptureMaking sure every run leaves a raw record.
- AvailabilityPutting the record of agent work where your team can query and review it.
- TraceWalking back through a single run, end to end, with the reasoning alongside the decisions.
The team gets better over time.
- EvaluationMeasuring whether your processes work, by the numbers and by gut-check.
- PrioritizationChoosing what to change and where to invest next.
- ConvergenceMaking a change stick across the team.