Harness Economics

A team choosing between two agent harnesses for the same coding task does the obvious thing: run it through both, hold the model constant, and compare the bill. Harness A finishes for sixty cents. Harness B finishes for two dollars and change — more than three times as much. On a spreadsheet built to minimize spend, the decision looks made before Harness B’s pull request is even reviewed. Then the review comes back: Harness A’s change missed a config file it never read and needs a second session to fix; Harness B’s shipped clean on the first pass. The number that looked decisive picked the wrong harness.

This is not an invented scenario. Volume I opened this Library with a benchmark worth returning to now for a different column: the same model, run through roughly seventeen agent harnesses, on matched tasks. Chapter 1 read that benchmark for what it said about quality — harness architecture, not model choice, decided whether a task got done well. Read instead for cost, the same benchmark makes an equally sharp point: the identical task, on the identical model, comes out several times more expensive in one harness than in another. Nothing about the model changed between runs. The multiplier lives entirely in the vehicle wrapped around it.

Three ways to spend more on the same task

Harness architecture is not one lever that moves cost up or down. It is at least three, and a harness’s total spend on a given task is the sum of choices made at each: how much context it reads before acting, how much planning and verification it does around each action, and how large and how verbose its tool surface is. None of the three is inherently wrong to spend more on — each trades token cost against a specific failure it is trying to prevent — which is exactly why a raw cost comparison between two harnesses, taken alone, cannot tell a team which one is actually cheaper.

Reading more before acting

The first lever is context-reading depth, and it is the same tension Volume II names in its account of static versus just-in-time loading: a harness can load a broad slice of a repository into context before the first tool call, or it can hand the agent a directory listing and a file-read tool and let it pull in exactly what a step turns out to need. The first approach spends tokens early and predictably — a wide read, done once, whether or not most of it ends up mattering. The second spends tokens narrowly and repeatedly, one just-in-time fetch per genuine need, at the cost of occasionally missing something the agent had no reason yet to ask for. A harness that reads too little too late pays for that gap later, as a retry or a fix-up session the wider read would have prevented; a harness that reads too much too early pays for context nobody ends up using. Neither failure shows up on the invoice for the turn where it happens — only on the one after.

Planning and verifying more before finishing

The second lever is how much a harness plans before acting and checks after. A harness that decomposes a task into a feature list before writing code, and that runs its own tests before marking work complete, spends tokens on both passes that a leaner harness skips entirely. Anthropic’s own account of building long-running agent harnesses makes the trade concrete: giving an agent a structured verification step — testing its own work before calling it done, rather than marking a feature complete on faith — costs tokens in the moment and saves them across the session, because the agent stops guessing at what a prior, unverified step actually did. The alternative is not free. It is deferred: work that skips verification does not skip the cost of being wrong, it just moves that cost downstream, to whichever human ends up as the reviewer — precisely the mechanism Volume I’s Review Bottleneck chapter describes at the pipeline level. A harness that verifies less can be paying, in review time it never measures, for every token it saved in the session.

A bigger, louder tool roster

The third lever is the tool surface itself: how many tools a harness exposes and how verbose their results are by default. Anthropic’s guidance on designing tools for agents makes the cost concrete with an example few teams think to check — the same lookup returning 206 tokens in a detailed response format against 72 tokens in a concise one, nearly a threefold difference for identical information, multiplied across every call a session makes. A harness with a large, unfiltered tool roster and no default truncation pays that tax on every turn; one with a small, curated set of tools and sane default formatting — the discipline the next chapter develops as tool design in its own right — does not. This lever is the cheapest of the three to fix, because unlike context depth or verification depth it trades against almost nothing: a well-designed tool rarely needs to be verbose to be correct.

Plan-heavy versus lean, side by side

Put the three levers next to each other and the trade-off becomes a table rather than a debate. A plan-heavy, context-rich harness and a lean, just-in-time harness are not a “better” and a “worse” configuration of the same thing — they are tuned for different failure profiles, and mismatching the tuning to the task is where most naive cost comparisons go wrong.

Read this way, the table is not a recommendation for one column over the other. It is a description of what a team is actually buying when it picks a harness — or builds one — and a reminder that the column that looks cheaper on a single-session invoice is the column making an implicit bet about how well-specified the work already is.

The comparison that actually matters

Here is the counterintuitive part, and it is why a naive per-token comparison is the wrong instrument for this decision. A harness that looks cheap because it reads less context and verifies less work can be the more expensive harness once the retry it triggered and the failed review it caused are counted back against it. The plan-heavy harness that looked expensive on the first invoice can be the cheaper one once its second invoice — the one for the session that did not have to happen — is never sent.

This is Volume I’s Cost Per Outcome argument, applied one layer down. That chapter made the case at the level of a team’s monthly spend: the number worth minimizing is never raw dollars, it is dollars per durable, successfully completed outcome, because two sessions with an identical bill can produce entirely different value. The same logic holds at the level of a single harness choice. The right comparison between Harness A and Harness B was never their per-task token cost. It was their cost per task that actually shipped, reviewed cleanly, and stayed shipped — and on that measure, a harness engineered to read enough and verify enough can beat a leaner one that looks better on the first invoice and worse on every one after it.

The cheap-looking harness and the cheap harness are not the same harness. Counting only the first invoice is how a team pays for the second one without noticing.

What to check before trusting either number

None of this argues for defaulting to the most expensive-looking harness available, which is its own way of avoiding the actual measurement. It argues for checking, per task category, whether a harness’s token spend is buying fewer retries and cleaner reviews or simply spending more for the same outcome. Operon does not yet have a published, team-scale dataset breaking harness cost down against retry rate and review outcome, and this chapter will not manufacture one. What follows is the shape that telemetry should take, not a measured result.

Spend and capability, not opposed

The mechanism behind all three levers connects to a finding this Library has cited since Chapter 1 and returns to here for a reason: in Anthropic’s account of its own multi-agent research system, token usage by itself explained roughly 80% of the variance in how well an agentic system performed its task. Agentic workflows run about four times the token volume of an equivalent chat exchange; multi-agent workflows, roughly fifteen times. The additional spend was not waste sitting alongside the capability — to a real degree, it was the capability.

The practical implication for a team choosing or building a harness follows directly. Minimizing token cost in isolation, without measuring what that minimization costs in retries, failed reviews, and rework, is optimizing the wrong number — exactly the trap this Library named for the token bill in Chapter 1, now shown to hold one layer down, at the level of harness design itself. A harness is not cheap because its invoice is small. It is cheap because its outcomes are large relative to that invoice, and only one of those two facts shows up without being asked for.