De authority gap: waarom langlopende software agents niet aan meer compute maar aan een scheiding van verantwoordelijkheden kapotgaan

De paradox van autonome software-ontwikkeling is dat het probleem er niet uitziet als het probleem is. Op het eerste gezicht is langlopende code-productie een compute- of contextprobleem: hoe houd je een agent bij de les over duizenden stappen, honderden bestanden en een specificatie die steeds verder van het werkende systeem afdrijft. Dat beeld is verleidelijk en structureel fout. SlopCodeBench (arXiv:2603.24755) meet onafhankelijk wat er werkelijk gebeurt: geen enkele agent lost een probleem end-to-end over 11 modellen op, de hoogste checkpoint solve-rate is 17,2%, en de kwaliteit erodeert in 80% van de trajecten. Het probleem is niet dat de agent niet lang genoeg doorrekent. Het is dat hij, naarmate hij langer doorloopt, zijn eigen verantwoordelijkheden door elkaar gaat halen.

Wat het rapport materieel beweert

Harness-of-Harness (HoH) is een framework van Shanghai AI Lab en SJTU dat een bestaande coding-agent-harness (Codex, OpenCode of Pi) in een iteratieve planning-coding-testing-lus plaatst. Het bouwt niet opnieuw, het verbetert ook geen harness- of modelkeuze: het organiseert de uitvoering van een vaste harness-model-combinatie in een loop van drie rollen:

• Project Planner (read-only op de artifact) combineert de globale specificatie met het evidence uit eerdere iteraties en kiest één begrensde, lokaal complete increment.
• Developer (single writer, warm-start vanuit de vorige artifact) realiseert het plan en test lokaal tijdens implementatie (shift-left).
• QA Tester (read-only op een bevroren candidate) evalueert het resultaat onafhankelijk met complementaire white-box en black-box tests, en produceert een gestructureerd evidence-rapport dat de volgende planning voedt.

Het deterministische runtime-contract is de kern: het bepaalt wat elke rol mag lezen, wijzigen en opleveren, zonder voor te schrijven hoe de rol haar werk doet. Alleen de Developer mag de artifact wijzigen; de Planner en Tester mogen inspecteren maar niet aanpassen. De Tester krijgt de artifact als bevroren, read-only candidate zodat zij niet stilletjes kan repareren wat zij moet evalueren.

De resultaten zijn op drie benchmarks (GameCraft-Bench, FrontierSWE, ProgramBench) en drie harness-model-paren consistent: gemiddelde relatieve verbetering van 52,25%, maximum 82,86% na drie iteraties [C1]. De GameCraft-scores stijgen van 49,58 naar 71,52 (Codex+GPT-5.5), van 26,90 naar 48,98 (OpenCode+DeepSeek-V4-Pro) en van 42,16 naar 58,78 (Pi+MiniMax-M3). FrontierSWE-rewards van 0,31 naar 0,54, 0,23 naar 0,31 en 0,26 naar 0,55. ProgramBench test-pass-rates van 60,41 naar 66,50, 45,27 naar 57,56 en 35,83 naar 52,68.

De ablatie is het echte bewijs

De benchmarkcijfers zijn indrukwekkend maar zeggen op zichzelf niets over het mechanisme; een betere score kan immers uit meer compute komen. Twee controle-experimenten isoleren de werkelijke verklaring.

De pass-controlled vergelijking ontkracht de compute-hypothese. Op GameCraft-Bench haalt HoH@2 een score van 64,84 met 5,67M tokens; herhaalde Vanilla-ontwikkeling haalt 58,24 met 6,33M tokens over drie passes [C4]. HoH wordt dus niet alleen beter van meer passes of meer tokens; het is efficiënter én beter bij een vergelijkbaar of kleiner budget. De winst zit niet in de rekenkracht maar in de structuur.

De ablatiestudie localiseert de winst in de cross-iteration state. Drie varianten die één mechanisme uitschakelen, dalen allemaal ten opzichte van de volle HoH@3 (71,52): zonder plan-update (−8,13 tot 63,39), zonder evidence-feedback (−6,28 tot 65,23), en zonder warm-start (−7,85 tot 63,67) [C2, C3]. Zonder warm-start stijgt het tokenverbruik bovendien van 8,41M naar 11,12M per taak, vanwege herhaalde reconstructie. De drie mechanismen, het bijwerken van het plan met nieuwe evidence, het gebruiken van uitvoerings-evidence bij herplanning, en het voortbouwen op de voorgaande implementatie, dragen samen de kwaliteitswinst.

Dit is het onderscheid tussen "interessant" en "belangrijk". Dat HoH betere games maakt dan een losse harness is interessant. Dat een deterministische state-overdracht tussen loop-iteraties, onafhankelijk van het model en de harness, de kwaliteitsverklaring is, is belangrijk: het betekent dat het mechanisme overdraagbaar is naar elke agentic architectuur.

De eigen analytische bijdrage: de runtime-contract als capability-authority boundary

De auteurs framen HoH primair als een engineering-framework voor software-ontwikkeling. De grotere consequentie, die het paper niet benoemt, is architectonisch en governance-kundig. HoH is feitelijk een capability-authority boundary die in het deployment-systeem is geïmplementeerd, niet in het model of de prompt.

In agentic-systemen onderscheiden we twee principes: CAPABILITY ≠ AUTHORITY (een model dat iets kan hoeft daar niet toe gemachtigd te zijn) en PROMPT ≠ POLICY (instructies in een prompt zijn geen beveiligingsbeleid). HoH vertaalt dit naar een operationeel ontwerp. De capability wordt gevormd door de LLM-harness (wat het model kan produceren). De authority wordt gevormd door het deterministische runtime-contract: welke rol mag lezen, wie mag schrijven, wie mag accepteren. De authority is niet geparametriseerd in een prompt die een agent kan negeren of omzeilen, maar is afgedwongen in de uitvoeringsomgeving zelf.

Drie specifieke mechanismen operationaliseren dit:

De single-writer boundary verhindert de confused-deputy-overlap. Wanneer dezelfde agent zowel produceert als accepteert, is er geen onafhankelijkheid: de producent heeft een belang bij zijn eigen completion-claim, en die claim kan niet als bewijs voor correctheid dienen. HoH forceert dat alleen de Developer de artifact schrijft [de authority], en dat de Tester een bevroren candidate beoordeelt die niet meer kan veranderen terwijl geëvalueerd wordt. Dit is dezelfde principiële scheiding als acceptatie die losstaat van productie, de kern van elke audit- en assurance-functie.

De evidence-state maakt acceptatie tot een controleerbare beslissing. De QA Tester mag een criterium alleen als vervuld registreren wanneer candidate-gebonden records dat ondersteunen; onvervulde vereisten, regressies en onvoldoende bewijs worden geregistreerd als gaps, niet als impliciete succesvolle afronding. Dat is het verschil tussen "de developer zegt dat het werkt" en "er is traceerbaar bewijs dat het werkt, gebonden aan een specifieke artifact-versie". De acceptatie-eenheid is dus het traject en zijn effecten, niet de zelfrapportage van een producent.

De progressieve onthulling en versiehistorie vervangen geheugen door artefacten. In plaats van een geheugenmodule die kan overstromen of vervuilen, persisteert HoH plannen, rapporten en historie in het bestandssysteem en stelt ze stapsgewijs beschikbaar via een geïndexeerde index. Het kan na een regressie terugkeren naar eerder geverifieerde states en put bij herhaalde fouten uit eerdere diagnose. Geheugen is geen eigenschap van het model, maar van het deployment-systeem dat de levenscycli van artefacten en evidence beheert.

Dit is de overgang die de paper aantoont: van "het model is de verantwoordelijkheidsdrager" naar "het deployment-systeem is de autorisatie-eenheid." Het model is een capability-aanbieder; het runtime-contract is de policy boundary. Dat is precies waar secure-by-design aan de bouwtekening moet zitten, niet in een aparte review-laag erbovenop.

Wat dit verandert aan de enterprise-architectuur

Voor wie agentic-systemen in een enterprise-omgeving ontwerpt, verschuift het zwaartepunt van de assurance-inspanning. Niet naar betere modellen of grotere contextvensters, maar naar het expliciet modelleren van de rollen, hun authorities, en de evidence die acceptatie moet dragen.

In TOGAF-termen is HoH een referentie-implementatie van een principieel punt: de Technology Architecture moet de capability-authority boundary dragen, niet de applicatie of de prompt. Concreet betekent dit voor een architect:

• Authorities als bouwstenen, niet als prompt-context. Wie mag schrijven (single writer), wie mag lezen, wie mag accepteren (onafhankelijke rol). Dit zijn building blocks die je modelleert, niet beschrijft.
• De artifact en de evidence als twee separate states. De code is niet genoeg; je hebt de gevalideerde kennis nodig over waarom wijzigingen zijn gekozen, welke fouten openstaan en welk gedrag al geverifieerd is. Dit is de audit-trail.
• Acceptatie als evidence-gebonden, niet als completion-claim. Een criterium is alleen vervuld met candidate-gebonden records. Dit is de borging dat acceptatie niet samenvalt met productie.
• Progressive disclosure en versiehistorie als governance-primitief. Terugkeer naar geverifieerde states, hergebruik van diagnose, traceerbaarheid van de levenscyclus.

Dit sluit aan bij een breder architectuurpatroon: de assurance-laag zit in het deployment-systeem (de runtime-contract, de state-historisatie, de rol-scheiding), niet als een losse contentfilter of een extra review-prompt bovenop het model. Voor agentic-workloads is per-request-classificatie de verkeerde granulariteit; de autorisatie-eenheid is het traject en zijn effecten.

Grenzen van het bewijs

De pass-controlled claim is het sterkste punt, maar verdraagt hier precisie. HoH@2 (64,84) overtreft Vanilla-3pass (58,24), wat aantoont dat de winst niet louter door meer passes komt. Maar dit is één benchmark en één configuratie (GameCraft, Codex+GPT-5.5); de extrapolatie naar alle configuraties rust op inferentie, niet op een volledige pass-controlled matrix. De taalsterkte moet hier laag blijven: de pass-controlled winst is consistent met de state-carried hypothese, niet een definitieve ontkrachting van elke mogelijke compute-bijdrage.

De ablatie toont dat de drie cross-iteration mechanismen samen de kwaliteit dragen, maar de ablatie is uitgevoerd op GameCraft-Bench met één configuratie (Codex+GPT-5.5). De relatieve bijdrage van de mechanismen kan op andere benchmarks en modellen verschillen. De FrontierSWE-verdieping (HoH@10: van 22% naar 72,67% dominance, verbetering op HoH@3 met 33,34 punten) suggereert dat de verbetering over meer iteraties aanhoudt, maar dit is één taakset en één configuratie.

De methodologische beperking die het meest relevant is voor adoptie: de evaluatie meet artifact-kwaliteit op benchmarks met bounded, taak-provided checks (screenshots, smoke tests) en in de Fusepoint-case op een combinatie van black-box en white-box testen. De onafhankelijke QA is zelf een LLM-invocation van dezelfde vaste harness-model-combinatie. Dat betekent dat "onafhankelijkheid" hier institutioneel is (een andere rol met andere authorities), niet epistemisch (een andere model-denkwijze). De QA Tester is een andere rol met read-only authority, maar dezelfde onderliggende model-capability. In een deployment waar dezelfde model-familie zowel produceert als accepteert, blijft een residueel risico op gedeelde blinde vlekken; de QA kan competent zijn in regels volgen maar dezelfde onvolledigheid delen als de developer.

Het beslissend falsificatie-experiment

De centrale claim, dat de runtime-contract en de evidence-state, niet het model of de compute, de kwaliteitswinst dragen, is falsifieerbaar. Het beslissend experiment is tweeledig.

F1 (model-substitutie): Wissel het onderliggende model van de QA Tester. Draai HoH met de Developer op model A en de QA Tester op model B uit een andere familie, en vergelijk met HoH waar beide op model A draaien. Als de kwaliteit significant verbetert bij een cross-model QA, is de onafhankelijkheid epistemisch (een andere denkwijze vangt meer); als er geen verschil is, is de winst primair institutioneel (de rol-scheiding en de evidence-contracten). Dit discrimineert de twee concurrerende verklaringen voor waarom de QA-scheiding werkt.

F2 (evidence-ontkoppeling): Verwijder specifiek de evidence-state uit de Tester-uitvoer (laat de Tester alleen een score, geen gestructureerd gap-rapport teruggeven) terwijl het plan- en warm-start-mechanisme intact blijven. De ablatie toont al een daling van −6,28, maar het isoleren van de evidence-richting (welke gaps het planner-gedrag in de volgende iteratie sturen) zou het specifieke mechanisme vastpinnen waarlangs de winst loopt.

De negatieve controle hoort hier expliciet: HoH met een niet-bevroren candidate (QA mag herstellen). Dit test of de bevroren-candidate-eis, die de QA voorkomt haar eigen test te repareren, werkelijk bijdraagt, of dat de QA-scheiding op zichzelf genoeg is.

Voor de Nederlandse publieke sector

Voor overheidsorganisaties die agentic-code of AI-systemen inzetten, is de relevante les niet dat autonome software-ontwikkeling nu "werkt". De les is architectonisch: scheid productie van acceptatie, bind acceptatie aan candidate-gebonden evidence, en model de authorities in het deployment-systeem, niet in de prompt.

Dit sluit direct aan op de assurance-verplichtingen die er al staan. De evidence-state die HoH onderhoudt, gevalideerd gedrag, openstaande gaps, versiehistorie, is in wezen de audittrail die organisaties voor AI-systemen eisen om verantwoordelijkheid te kunnen dragen. De acceptatie-regel (een criterium is alleen vervuld met candidate-gebonden records) is dezelfde discipline als "geen acceptatie zonder bewijs" die van een volwassen security- of kwaliteitsorganisatie wordt verwacht.

De randvoorwaarde is dat dit rust op de rol-scheiding als afdwingbaar primitief. Dat vereist dat identiteit en authority in het deployment-systeem zijn gemodelleerd, niet vertrouwend op prompt-compliance. Een organisatie die deze bouwstenen opneemt, bouwt haar assurance in de architectuur; een organisatie die dat niet doet, vertrouwt erop dat een model zichzelf verantwoord houdt, en dat is precies wat SlopCodeBench meet dat niet werkt.

Conclusie

HoH is geen argument dat autonome software-ontwikkeling nu productierijp is. Het is een argument dat de kwaliteitswinst komt van een deterministische scheiding van verantwoordelijkheden, niet van het model of de compute. De ablatie lokaliseert de winst in de cross-iteration state; de pass-controlled vergelijking ontkracht de compute-hypothese; de single-writer boundary en de evidence-gebonden acceptatie maken acceptatie tot een controleerbare beslissing.

Voor de architect die agentic-systemen ontwerpt, is de bouwtekening helder: model de authorities in het deployment-systeem, scheid productie van acceptatie, en bind acceptatie aan candidate-gebonden evidence. De capability zit in het model; de authority zit, of zou moeten zitten, in de runtime-contract. Dat is secure-by-design dat werkt, omdat het niet afhangt van prompts maar van de architectuur zelf.

---

Bronnen: Harness-of-Harness (arXiv:2609.01481, Shanghai AI Lab/SJTU, 1 sep 2026); triangulatie: GameCraft-Bench (arXiv:2606.17861), SlopCodeBench (arXiv:2603.24755) en FrontierSWE (Proximal, 2026) ter bevestiging van het long-horizon degradatie-probleem en de grenzen van onafhankelijke frontier-agenten. Volledig claim ledger, concurrerende hypothesen H1-H6 en afgeleide berekeningen in het assurance-artefact.

Lees de paper op arXiv