Independent Convergence

Independent convergence is when unrelated third parties arrive at the conclusion you built on — in their own words, on their own problems, without knowing you exist. It is the only form of external proof we consider defensible: named authors, dated publications, checkable claims. This page is our running record of it. Every entry states who said it, when, and the caveat that rides with it — because a receipt with its caveat stripped is not a receipt.

The record clusters around three conclusions. We wrote about the first in The Model Is the Smallest Part; the sources below extend it.

1. The system, not the model

The strongest entry is the most controlled one. In July 2026, a team at the University of Illinois Urbana-Champaign published SwarmResearch (arXiv:2607.02807) — a study of orchestrated coding agents that held the model constant across every method it compared and attributed the outcome differences entirely to harness design. Their words: they treat it as "a harness-engineering problem." That is the exact experimental shape our thesis predicts: same model, different system, different results.

The practitioners got there first, from unrelated directions. Akimitsu Takeuchi spent eighteen months and roughly 140,000 messages across three model families and titled his conclusion The Model Wasn't the Bottleneck. The Configuration Was (AI Advances, June 2026). Jaroslaw Wasowski, analysing a frontier coding stack (Level Up Coding, June 2026), reported that a harness alone moved an agent from outside the top 30 to the top 5 with the model unchanged — his point being that you should evaluate the whole system, never a single leaderboard number. Kapil Viren Ahuja put it in five words from the methodology side: "the harness is not the method" (Medium, May 2026).

And the market voted. Sakana AI shipped Fugu (June 2026): a planner that writes the full workflow up front and a small router that assigns each step to a worker from a swappable pool of unchanged models — orchestration as the product. In the same window, Anthropic moved dynamic workflows into Claude Code: the agent holds its plan in a script, runs adversarial checkers against its own output, and checkpoints long jobs. The layer everyone treated as glue became the thing both labs decided was worth building. One caveat we carry with the Fugu entry: its performance numbers are vendor-reported, so the receipt is the shipped architecture, not the benchmarks.

One boundary worth stating, because the SwarmResearch team found it and honesty demands it travel with the thesis: the direction of the prescription flips with how open the task is. For contract delivery — build exactly this — instruction specificity helps. For open-ended exploration, the same study found that when the orchestrator prescribes specific ideas, the agents collapse into the orchestrator's own idea basin. The system still explains the variance in both regimes; what the system should do differs.

Three more arrived after July. Gennaro Cuofano (The Business Engineer, August 2026) describes a four-layer stack, model → harness → method → finished work, and locates performance in the fit between the layers rather than in the model; his line for it is "A great model in a chat window answers. A great model in a harness owns a job." Google's own 51-page whitepaper, The New SDLC With Vibe Coding (Osmani, Saboo and Kartakis, May 2026), reduces the point to an equation, Agent = Model + Harness, and treats the instructions, tools, gates and observability around the model as the engineering work. And MANTA (Huang, Wang, Lai et al., Cornell / UIUC / Academia Sinica, arXiv:2607.28527, July 2026) built a system that adapts its agent topology mid-run, then found in its own ablation that the largest gain came from the planning done before execution, not from the mid-flight changes — the win was choosing constraints well up front. Figures are the authors'.

The evidence against, stated here too. In September we decomposed Table 1 of Google's procedural-graphs paper (Lu, Chen, Wu, Arık, 2026): four models against eight methods on six benchmarks. Which model you use explains between 52% and 96% of the variation in results; which method you use explains between 2% and 31%. We published that in The Pigeon Was Not Superstitious, and it narrows this cluster's claim. We no longer say the system beats the model. We say structure is a consistent second effect, and the one you can keep, inspect and correct. The sources above support the narrower claim. None of them establishes the stronger one, and this page will not either.

2. The verifier decides

Fareed Khan's automated security pipeline (AI Advances, June 2026) states the discipline in eight words: "a crash, not the model, decides what counts." His system discards whatever the agent claims it found; a finding exists only when the host reproduces the failure itself. He also publishes his unproven candidates next to the proven ones — the flop beside the win, which is its own kind of receipt.

Lilian Weng's write-up on self-improving harnesses (July 2026) adds the structural version of the same rule: the evaluator and the permission to change things must sit outside the loop that is being improved — otherwise the system grades its own homework and drifts toward reward hacking.

Jesse Vincent (blog.fsck.com, June 2026) supplied the field test. He pre-registered twenty-five experiments on his own agent harness — prediction written down before each run — and, tellingly, found three bugs in his own measurement harness that only manual inspection caught, including one claimed improvement that re-measured to a much smaller honest one. The verifier-decides rule applies to the verifier too.

The July 2026 wave of writing on "graph engineering" landed on the same rule from the security side. eigent.ai argued that a self-improving system needs an anchor: an external fixed reference the optimizer is forbidden to rewrite, a held-out eval, a frozen spec, or a human judgement. AI Builder Club put the companion rule beside it: a separate, read-only verifier that never certifies its own work. Both are what we run, and neither author knows we exist. One caveat the field itself supplied: LangChain pointed out that graph-based orchestration is three years old, so the term is contested; the two disciplines are not.

Google's SDLC whitepaper (May 2026) states the verifier-decides rule for software teams: tests and evaluations are a contract with the AI, written before implementation, and output evaluation (is the artifact correct?) is separated from trajectory evaluation (did the agent take sensible steps to get there?). We score both and have said in A Green Build Is Not Knowledge that joining the two per job is still open work on our side.

3. The self-improving harness

Weng's piece also lays out a full reference architecture for improving the harness itself: mine failure patterns from complete execution traces, propose bounded edits only on surfaces explicitly marked editable, and promote a change only when it fixes the weakness it targeted and nothing else regresses on held-out work.

Here the honest framing matters most, so we state it plainly: this is convergence on a design, not a claim that we run the full loop. Parts of it are in production; the proposal and gated-promotion stages are mid-build. What this entry shows is narrower and still worth showing — the reference design we have been building toward is the one an independent researcher published, without knowing we exist.

The strongest entry since then is the procedural-graphs paper from Google, Georgia Tech and Peking University (Lu, Chen, Wu, Arık, arXiv:2609.09153, September 2026). Its offline loop is Weng's architecture with numbers attached: propose edits to the agent's procedural map from contrasted traces, keep a batch only if a held-out score does not fall, and remember the rejections so a bad idea is not proposed twice. On one benchmark an uncorrected expert map scored below having no map at all; the corrected one beat both. We wrote it up in A Hand-Written Map Can Be Worse Than No Map, where we also state the gap on our side: our proposals run at volume and the part that measures whether a promotion helped had measured six. Convergence on the design; not a claim the loop is closed.

Two smaller receipts sit beside it. Shi and Li, Topological Necessities (arXiv:2609.11014, September 2026), recover from successful runs the stages every successful executor must pass through, and show they transfer across very different executors: procedure kept outside the model, corrected from what happened. Google's SDLC whitepaper names the shape the factory model: the developer designs the system that produces code, tests verify the output, failures are fed back. One difference worth stating plainly: that factory learns from failures only. We also record why a passing run passed, because a pass with no reason cannot be reused.

Convergence, not endorsement

None of the authors on this page validated Bouletteproof. None of them know we exist. They were solving their own problems and publishing what they found — which is precisely why their work is worth citing. This page will never present a worldview essay as a technical receipt, never count vendor guidance as an independent discovery, and never strip a caveat to make a claim stronger. When a new source converges, it gets added with its date and its limits. When one doesn't hold up, it doesn't appear here.