Wat gebeurt er als je 100 agenten in een kamer zet en ze vraagt kapot te maken

Er is een soort bijeenkomst die elk bureau kent. Zeven mensen in een ruimte. Eentje verdedigt een besluit. De anderen trekken aan. Iemand vindt het gat in de redenering. Het besluit wordt sterker, of het wordt vervangen. Het is langzaam en duur en het werkt.

Microsoft voerde net diezelfde bijeenkomst uit met machinenelheid, met meer dan 100 AI-agents gericht op de Windows codebase. Het systeem, MDASH, vond 16 eerder onbekende kwetsbaarheden in één Patch Tuesday-cyclus. Dit is geen benchmarkscore. Dit zijn echte bugs die live zouden zijn gegaan.

Hoe MDASH echt werkt

De architectuur is niet exotisch als je er goed naar kijkt. MDASH zet meerdere gespecialiseerde agents in debat met elkaar. Sommige agents stellen aanvalsvectoren voor. Anderen bestrijden ze, testen aannamen, signaleren zwakke redeneringen. Een coördineerlaag bepaalt wat het debat overleeft.

Dit is dezelfde logica als red team versus blue team security testing, behalve dat het red team nooit moe wordt, nooit om vijf uur stopt, en horizontaal schaalt zonder inhuurbegroting. De debatstructuur is belangrijker dan het vermogen van één agent. Een enkel model dat code scant op kwetsbaarheden zal dingen missen. Een model dat zijn bevindingen moet verdedigen tegen 99 collega's mist minder.

Het getal 16 verdient aandacht. Beveiligingsonderzoekers die conventionele staticanalyse en fuzzing-tools gebruiken op een volgroeide codebase als Windows vinden meestal in één cyclus kwetsbaarheden in enkelgetallen, en dat werk vergt aanzienlijke menselijke tijd. MDASH produceert vergelijkbare output autonoom, binnen dezelfde tijdschaal als een maandelijkse releasecyclus.

Waarom dit relevant is voor bureaus, niet alleen beveiligingsteams

De voor-de-hand-liggende lezing is dat MDASH een verhaal over Microsoft en cyberbeveiliging is. De minder voor-de-hand-liggende lezing, die de moeite waard is, is dat het een proof of concept is voor een klasse systeemontwerp die vrijwel overal van toepassing is waar mensen nu gestructureerde kritiek doen.

Bureaus voeren voortdurend gestructureerde kritiek uit. Designreviews. Content audits. Strategie valideren. QA voordat een product live gaat. De gemeenschappelijke vorm is: iemand produceert iets, anderen beoordelen het, de groep oppervlakt problemen, het ding wordt beter. Die vorm past rechtstreeks op wat MDASH aan het doen is.

De beperking was altijd dat kritiek duur is. Je hebt geschoolde mensen nodig. Je hebt agendatijd nodig. Dus de meeste bureaus doen het minder dan ze zouden moeten. Één designreview in plaats van drie. Één ronde copyqa in plaats van een goed adversariaal leeswerk. Het ding gaat live met het gat er nog in.

Multi-agent debatsystemen lossen niet elk kritiekprobleem op. Ze zijn echt goed in taken die een duidelijke succesvoorwaarde hebben, waar fout zijn een meetbare consequentie heeft, en waar de ruimte van mogelijke fouten groot genoeg is dat één recensent ze systematisch mist. Kwetsbaarheidontdekking voldoet aan alle drie. Net als toegankelijkheidsaudit. Net als controleren of een componentbibliotheek interne tegenstellingen heeft. Net als beoordelen of een UX-flow breekt op een specifieke klasse randegevallen.

Het orchestratieprobleem waar niemand over spreekt

Hier is het deel dat in de meeste stukken over agentiële systemen wordt overgeslagen: 100 agents laten nuttige output produceren vraagt meer ontwerpwerk dan één agent laten nuttige output produceren, niet minder.

De faalinodes zijn specifiek. Agents kunnen te snel convergeren, wat betekent dat het debat instort in groepsdenken voordat het iets vindt. Ze kunnen te ver divergeren, wat betekent dat de output lawaai is. Het coördinatormodel moet weten wanneer een minderheidsstandpunt daadwerkelijk het signaal is, niet de uitbijter die je wegzet. Die inschatting is niet gratis.

Voor bureaus die nadenken over waar ze dit patroon toepassen, is de praktische implicatie dat de prompt engineering en de systeemarchitectuur onscheidbaar zijn. Je kunt niet zomaar 100 instanties van hetzelfde model starten en het een debat noemen. De agents hebben andere priors nodig, verschillende rollen, andere instructies. Sommige zouden optimistisch moeten zijn over of iets werkt. Sommige zouden structureel skeptisch moeten zijn. De ensemble slaat het individu alleen als de ensemble echt divers is in haar redenering.

Dit is vakwerk. Het ziet eruit als systeemontwerp maar het vergt het soort denken dat goede creatieve directeuren instinctief doen: wie zit in de ruimte, waar zijn ze naar geprikkeld om op te letten, en hoe bereikt de groep een besluit dat beter is dan het eerste inzicht van één persoon.

Wat die 16 bugs ons echt vertellen

Beveiliging is een nuttig domein om te bestuderen omdat de feedback ondubbelzinnig is. Een kwetsbaarheid bestaat of bestaat niet. Die helderheid maakt het een goed toetssteen of multi-agent debat echte waarde oplevert of slechts de schijn van grondigheid.

Het MDASH-resultaat zegt dat het echte waarde oplevert. Zestien geverifieerde bevindingen, in één cyclus, op een codebase die decennia lang onder continue professionele controle is geweest. Dat is een betekenisvol signaal.

Voor bureaus is de equivalente toets het vinden van een domein in je eigen werk waar de feedback eveneens ondubbelzinnig is. Waar fout zijn zichtbaar en consequentieel is. Begin daar. Niet met het werk dat het moeilijkst te beoordelen is, maar met het werk waar een mislukking achteraf duidelijk is en waar je nu minder van die mislukkingen vangt dan je weet dat je zou moeten.

Toegang is één kandidaat. Performance budgets een ander. Consistentie tussen een designsysteem en wat eigenlijk in productie terecht komt is een derde. Dit zijn allemaal domeinen waar een multi-agent review dingen zou kunnen oppikken die een enkelvoudige human review mist, en waar de kosten van missen echt zijn.

De breder geldigheid is dit. het meest interessante aan MDASH is niet dat het AI gebruikt. Het is dat het een proces neemt, gestructureerd adversariaal debat, dat mensen hebben uitgevonden en al vertrouwen, en het op een schaal en snelheid uitvoert die verandert wat economisch haalbaar is. Dat is de echte kans. Niet oordeelsvormend vervangen, maar het goedkoper maken om meer ervan toe te passen.

Waar te beginnen

Als je een productteam of designfunctie runt en je wilt dit patroon experimenteren, is het startpunt niet het gereedschap. Het is de vraag: waar doen we in ons proces nu één ronde kritiek terwijl we weten dat drie ronden een beter resultaat zouden opleveren?

Beantwoord dat eerst. Ontwerp dan de agent rollen rond de specifieke faalinodes die je probeert te vangen. Geef sommige agents de taak problemen vinden. Geef anderen de taak betogen dat de problemen niet echt zijn. Zorg dat de coördinatoren hun conclusie verdienen.

Het gereedschap om dit te bouwen bestaat vandaag. De ontwerpgedachte om het te laten werken is dezelfde ontwerpgedachte die je team al heeft. De kloof is vooral erkennen dat het patroon van toepassing is.

Microsoft voerde het experiment op schaal uit zodat de rest van ons het resultaat kan lezen. Zestien bugs. Één cyclus. Dat is een concreet getal gekoppeld aan een aanpak die zes maanden geleden vooral theoretisch was. Het is het waard ernstig te nemen.