Hetzelfde model, van 30% naar 100%
Een paar dagen geleden las ik het verhaal over NVIDIA’s AVO en het duurde even voordat het binnenkwam. NVIDIA nam exact hetzelfde model — Claude Opus 5 — en tilde het van een score van 30% op de publieke ARC-AGI-3-set naar 100%. Zelfde model. Zelfde gewichten. Zelfde intelligentie. Het enige dat veranderde was de harness eromheen.
Dat is een grotere uitspraak dan het lijkt. We zijn eraan gewend geraakt te denken dat als een agent ondermaats presteert, de oplossing een groter, beter, slimmer model is. Gewichten verwisselen, meer tokens kopen, hopen. Het resultaat van NVIDIA zegt iets ongemakkelijks: het model was nooit de bottleneck. De manier waarop het was ingepakt — de persistente staat, de tool-feedback, het herstelpad — bepaalt of het werk daadwerkelijk afkomt.
Wat de harness eigenlijk is
Het AVO-verhaal van NVIDIA is geen goocheltruc. Het komt neer op drie saaie dingen waar niemand enthousiast over wil worden:
- Persistente staat — het werk overleeft. Als een sessie eindigt, wordt gecompact, of crasht, vergeet de agent niet waar hij was.
- Tool-feedback — de agent krijgt echte signalen van wat het daadwerkelijk deed, niet gissingen over wat het denkt dat er gebeurde.
- Herstel — als er halverwege iets breekt, pakt het de draad op waar het gebleven was in plaats van blind opnieuw te beginnen.
Niets daarvan verbetert de redenering van het model. Alles daarvan bepaalt of die redenering ertoe doet. Een briljant model zonder staat verliest de draad na drie stappen. Een middelmatig model met een degelijke harness werkt zich erdoorheen en landt het antwoord.
Ik draaide dezelfde lens op mijn eigen opzet
Dat lezend deed ik wat ik meestal doe — ik keerde het tegen mijn eigen huis. Mijn agents draaien op Hermes met een vault, Mnemosyne voor geheugen, en een verificatie-poort die controleert of een taak echt af is in plaats van alleen maar geclaimd. Dat is een harness. En eerlijk, delen ervan zijn goed.
Maar de audit liet precies zien waar de harness nog lekt. Mijn geketende cron-jobs halen upstream-output op als context — en als de upstream-job faalt, draait de downstream-job op verouderde of lege data. Geen health-check waarschuwt dat de input ontbreekt. Het blijft gewoon draaien, in het duister. En mijn multi-stap-jobs hebben geen cross-sessie herstel: als een vier-stappen-job overlijdt bij stap twee, begint de volgende run blind bij stap één, zonder herinnering wat al is gelukt.
Het patroon is hetzelfde als bij NVIDIA. Het model is niet waar het werk verloren gaat. Het is de ontbrekende staat.
Wat dit betekent als je je eigen agents draait
Als je agents bouwt — of er één draait zoals ik — is de les: vóór je je model upgradet, audit je harness. Stel drie vragen. Overleeft het werk als een sessie eindigt of crasht, of moet je het overdoen? Krijgt de agent echte feedback van wat het deed, of vertrouwt het gewoon zijn eigen rapport? Als er iets mid-task breekt, kan het dan herstellen, of begint het blind opnieuw?
Het antwoord op “waar verlies ik het meeste werk?” is zelden “mijn model is niet slim genoeg.” Het is meestal “mijn systeem vergeet.”
Wat is jouw bottleneck — het model, of de harness eromheen? Ik hoor graag waar jouw agents het meeste werk verliezen. De reacties staan open.
Wat vond je van dit bericht?
