Designing Harnesses

Ten chapters ago, this volume opened with a claim that felt almost too simple to need defending: as models converge, the harness — not the model — becomes the thing worth engineering. Everything since has been that claim taken apart and put back together. The loop underneath every agent turned out to be simple and old, borrowed from a research pattern years before anyone called it a harness. The tools an agent calls turned out to be an API surface with the same design discipline as any other API. Permissions, sandboxes, hooks, skills, memory, long-running orchestration, and the economics that fall out of all of it — each was its own chapter because each is its own engineering problem, with its own failure modes and its own literature.

It is worth naming the arc plainly before closing it. Chapters 1 and 2 established why the harness matters at all: model convergence removes the differentiator teams used to rely on, and the agent loop’s universality means every harness — no matter how branded — reduces to the same gather-act-observe-repeat shape. Chapters 3 through 8 then walked the actual engineering surface a harness comprises: tool design, permission architecture, sandboxing and blast radius, hooks and checkpoints, the isolation spectrum from skills to agent teams, and the memory layer that keeps a session alive through real infrastructure failure. Chapters 9 and 10 closed on the harder, less settled questions — how work that outlives one context window should be structured, and what a harness actually costs once token spend is measured against outcomes rather than against itself.

The single claim underneath all ten chapters

Say it plainly, because the rest of this chapter depends on it: a harness is not one design decision. It is a stack of them. Tool granularity is a decision. Permission tiering is a decision. Blast-radius budgeting is a decision. Hook coverage, isolation depth, checkpoint frequency, memory durability, background-agent structure, cost accounting — each is independently engineerable, each fails in its own particular way, and each has accumulated enough practice to be called a craft rather than a setting. A team that gets tool design right and permission architecture wrong has not half-solved the harness problem; it has solved a different layer than the one that is currently hurting them.

This is why benchmark tables comparing harnesses as monoliths — this one scored higher, that one is faster — understate the decision in front of most teams. Two harnesses can tie on an aggregate benchmark while one has permission gating tuned for a five-person startup shipping fast and the other has it tuned for a regulated enterprise that cannot tolerate an unreviewed write to a payments path. The benchmark saw one number. The teams needed six.

It also explains why “just switch harnesses” so rarely fixes the problem it was meant to fix. A team frustrated by an agent that keeps touching files outside its intended scope does not have a model problem or even, usually, a whole-harness problem — it has a sandboxing and blast-radius problem, specifically, and a new harness with the same loose isolation posture will reproduce the same incident under a different logo. Diagnosing which layer is actually failing, before reaching for a wholesale replacement, is most of the craft this volume tried to teach.

An evaluation rubric

What follows is not a new framework — this volume already spent its coinage budget on the isolation spectrum in Chapter 7. It is the set of questions the preceding ten chapters actually equip a reader to ask, whether the task is choosing a harness off the shelf or building one in-house.

• Tool design (Ch. 3): does the harness’s tool surface minimize wasted context — precise names, right-sized granularity, error messages an agent can act on — or does it force verbose, poorly scoped calls that burn tokens before any real work happens?
• Permission architecture (Ch. 4): does auto-approve, gate, and default-deny map to the actual risk of the work being done, or is the harness uniformly strict (slow, frustrating, ignored) or uniformly loose (fast, and one prompt injection from a bad day) regardless of task?
• Blast radius (Ch. 5): if something goes wrong — a bad edit, a runaway command, an injected instruction — what is the actual worst case, and was that bound deliberately through sandboxing and worktree isolation, or is it merely whatever the filesystem happened to allow?
• Hooks and checkpoints (Ch. 6): are team conventions — test-before-commit, no direct pushes to main, mandatory review at a plan boundary — enforced mechanically at defined lifecycle points, or do they live only in a senior engineer’s head and a Slack pin?
• Isolation spectrum (Ch. 7): does the harness’s posture — solo session, subagent delegation, or genuinely parallel agent team — match how the work is actually structured, or is it defaulting to whichever mode the vendor ships first?
• Memory and long-running work (Ch. 8, 9): does state survive a real crash, not just a clean shutdown, and does the harness have an actual pattern — initializer plus incremental agent, or something equivalent — for work that outlives a single context window, rather than hoping the window is big enough?
• Economics (Ch. 10): closing the loop — what does this harness cost per completed outcome, not per token or per session, and is anyone actually computing that ratio or just watching the invoice?

None of these questions has a universal right answer, and that is the point. A solo developer prototyping on a personal machine has a legitimate reason to run everything auto-approved with a wide blast radius — the cost of a mistake is an hour, not an incident review. A team shipping to a regulated production environment has an equally legitimate reason to gate almost everything and accept the friction. The rubric’s job is not to prescribe a setting. It is to make sure the setting was chosen, not defaulted into.

The rubric also travels in both directions. Applied to a harness a team is evaluating for purchase or adoption, it turns a vendor’s feature list into a set of pointed questions a sales call rarely answers unprompted — what actually happens on a forbidden write, not whether one is theoretically possible. Applied to a harness a team is building in-house, the same seven questions double as a design checklist, in roughly the order a build should tackle them: get tool design and permissions right first, because everything above them inherits their mistakes, then blast radius and enforcement, then isolation and memory, with economics as the standing scorecard that tells you whether the earlier layers were worth what they cost.

Most teams have not chosen a harness posture. They have inherited whatever the default happened to be, and mistaken the absence of a decision for the presence of a good one.

Where the Library goes next

This volume covered the execution substrate — the harness itself, as an engineering object. Volume V, AI Workflow Engineering, picks up what happens on top of it: treating a session not as a raw loop of tool calls but as a workflow with its own recurring patterns, including the Flight Plans and recovery mechanics that give a session structure a well-built harness alone does not provide. Volume VI, Multi-Agent Development, returns to the isolation spectrum’s most extreme point — agent teams, first named in Chapter 7 — and to the scale-wider question raised but not resolved in Chapter 9, developing both fully, including the contrarian evidence that most coding tasks do not actually benefit from more agents working at once.