Audit · 3 June 2026
Brain vs cold execution — a measured A/B on a real build task
Two isolated worktree agents, identical pre-clarified task, A = no graph vs B = graph. The graph roughly halved total token spend and eliminated one human review round — by preventing a silent convention breach rather than fixing it later.
Setup
Two general-purpose agents, each in its own isolated git worktree, given the same feature with the load-bearing design fork pre-answered — so neither needed clarification, isolating execution cost. The task: a “Saved Investigations” feature — an authenticated route where a user creates an investigation, chats with an agent, findings persist per-user, and investigations list on return visits.
- Agent A (cold): forbidden from reading the graph; explores the code like a fresh hire.
- Agent B (graph): told to read the knowledge graph first and use it as the index.
The only difference. Neither was told whichcontracts to watch — both got the same open-ended “list the contracts your change depends on.” The reviewer audited both diffs against ground truth independently — never against the agents' self-reports.
Measured token consumption
Harness counters, not self-reported.
| Phase | Cold (A) | Graph (B) |
|---|---|---|
| Scoping (prior round) | 32.3K | 35.2K |
| Build | 94.5K | 77.3K |
| Correction round (RSC fix) | 104.7K | 0 — shipped correct |
| Human review rounds | 1 (+ the catch) | 0 |
| Total | 231.5K | 112.5K |
Build alone was within ~18%. The gap that matters opened in the correction round: a single fix loop cost 104.7K tokens — larger than the entire original build — and the graph agent paid none of it.
What actually separated them
Both agents produced working code, scoped every query to the authenticated user, kept the shared state shapes aligned, and routed the server tool correctly. The difference was one silent convention breach: the cold agent tagged a route-level file as a client component. It compiles, runs, passes typecheck — and silently disables server rendering down the whole route subtree, against the repository's documented convention.
Why the cold agent got it wrong is the interesting part: the only working example of that pattern in the repository was itself the grandfathered exception. The cold agent pattern-matched the most salient example. Only the graph carried the convention that the exception was an exception. Salience is not truth — reproduced live, in a build.
And the measured fix is the cheap version: it assumes a reviewer notices a breach that compiles and runs. In reality that detection often slips to PR review — or to production. Detection is the un-budgeted cost.
Takeaways
- 1
The cost of a silent breach is the loop, not the breach. Detect → describe → fix → re-verify. Here, ~104K tokens plus a human review cycle for a one-line structural mistake.
- 2
The graph converts an expensive correction into a cheap prevention. ~3K extra tokens up front — reading and confirming the notes — avoided a 100K+ round. The token-amortization thesis observed, not asserted.
- 3
The improvement class matters. This was not a lint or typecheck catch — it was a silent convention. No deterministic gate sees it; only encoded knowledge prevents it. Exactly what the graph exists for.
- 4
The graph made its agent soberer. 62% vs 70% self-reported confidence — and the lower confidence was the correct one. The confident cold agent is the one that shipped the breach.
- 5
The graph is not strictly dominant. On one design fork both agents made defensible calls. The measured edge is convention-adherence and silent-contract awareness, not raw build speed.
The caveat
A 20-file repository — close to the worst case for amortization, since a cold read is cheap there. The gap should widen on larger codebases, where “read the salient example and infer” gets more expensive and more wrong. The graph agent also spent ~3K tokens re-verifying citations; the in-the-moment win fully lands once consumers trust the graph enough to skip re-verification — which is what the mechanical citation checker and the independent validator exist to earn.
One run is one run. The standing commitment: this same A/B is re-run on each design partner's repository as it onboards, and the results are published here — win or lose.