# Multi-agent deadlocks detecteren en herstellen

[Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[Appsapps.llmnet.nlReviews van AI-apps en open-source repo's, met tips voor wie zelf bouwt.](https://apps.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fradar.llmnet.nl%2Fmulti-agent-deadlocks-detecteren-en-automatisch-herstellen&text=Multi-agent%20deadlocks%20detecteren%20en%20herstellen)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fradar.llmnet.nl%2Fmulti-agent-deadlocks-detecteren-en-automatisch-herstellen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fradar.llmnet.nl%2Fmulti-agent-deadlocks-detecteren-en-automatisch-herstellen&title=Multi-agent%20deadlocks%20detecteren%20en%20herstellen)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fradar.llmnet.nl%2Fmulti-agent-deadlocks-detecteren-en-automatisch-herstellen&text=Multi-agent%20deadlocks%20detecteren%20en%20herstellen)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fradar.llmnet.nl%2Fmulti-agent-deadlocks-detecteren-en-automatisch-herstellen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fradar.llmnet.nl%2Fmulti-agent-deadlocks-detecteren-en-automatisch-herstellen&title=Multi-agent%20deadlocks%20detecteren%20en%20herstellen)[](#)

 
# Multi-agent deadlocks detecteren en automatisch herstellen

 Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

 Wanneer meerdere autonome taalmodellen samenwerken in een netwerk van tools, geheugenbuffers en berichtenwisselingen, verandert softwareontwikkeling van een deterministische keten in een dynamisch complex systeem. Waar een enkel model kan blijven hangen in een herhalende redeneerlus, manifesteren falende interacties tussen meerdere actoren zich vaak als een klassieke patstelling. Deze multi-agent deadlocks leggen de uitvoering volledig stil, verbruiken tokens zonder voortgang te boeken en zorgen voor torenhoge rekeningen bij API-aanbieders.

 In traditionele databasesystemen en besturingssystemen zijn deadlocks wiskundig helder gedefinieerd rondom exclusieve locks op binaire bronnen. Binnen multi-agent architecturen zien we echter zowel binaire als stochastische blokkades optreden. Twee agents kunnen wachten op elkaars output, maar ze kunnen ook gevangen raken in een semantische beleefdheidslus waarin ze over en weer vragen om verduidelijking. Om deze systemen betrouwbaar in productie te laten draaien, is een robuuste combinatie van graafgebaseerde cyclusdetectie, semantische monitoring en deterministische circuit breakers noodzakelijk.

 
## De anatomie van deadlocks in LLM-omgevingen

 Een deadlock in een multi-agent systeem ontstaat wanneer twee of meer actoren niet verder kunnen met hun taak omdat ze elk wachten op een gebeurtenis of input die alleen door een andere wachtende actor kan worden geleverd. We onderscheiden in de praktijk twee fundamentele categorieën: structurele synchronisatiedeadlocks en semantische redeneerdialogen.

 Structurele deadlocks lijken sterk op hun tegenhangers in gedistribueerde systemen. Denk aan een situatie waarin een onderzoeksagent een schrijftoegang vergrendelt op een gezamenlijk werkdocument, terwijl hij wacht op de validatie van een controle-agent. Als die controle-agent op hetzelfde moment wacht op het vrijgeven van het werkdocument om zijn eigen context op te bouwen, ontstaat er een onoverbrugbare blokkade. Dit risico groeit naarmate frameworks complexere state machines en gedeelde geheugenlagen invoeren. In het overzicht over [agent-orchestratie-frameworks van juli 2026](https://radar.llmnet.nl/agent-orchestration-frameworks-juli-2026) zagen we al hoe orchestrators worstelen met het afdwingen van betrouwbare synchronisatie tussen asynchrone processen.

 Semantische deadlocks zijn subtieler en typisch voor grote taalmodellen. Hier is geen sprake van een vastgelopen netwerkverbinding of een geblokkeerde mutex, maar van een inhoudelijke cirkelredenering. Agent A genereert een半分 uitgewerkt voorstel en vraagt Agent B om ontbrekende randvoorwaarden in te vullen. Agent B interpreteert de instructie zo dat hij eerst nadere specificaties van Agent A nodig heeft alvorens de data te kunnen berekenen. Beide agents blijven volstrekt valide API-aanroepen produceren, maar het systeem als geheel boekt geen enkele inhoudelijke vooruitgang.

 
## Wachtgrafen en gerichte cyclusdetectie in runtime-engines

 Om structurele patstellingen formeel te detecteren, modelleert de runtime-engine de interacties als een gerichte graaf: de zogeheten Wait-For-Graph (WFG). In deze graaf representeren de knooppunten de actieve agents of tools, en de gerichte kanten de actieve afhankelijkheden. Zodra er een gesloten cyclus ontstaat in deze gerichte graaf, is een deadlock wiskundig bewezen.

 Het realtime onderhouden van een WFG vereist dat elke interactie, gereedschapsaanroep en geheugenvergrendeling geregistreerd wordt via een centrale event-bus of state store. Telkens wanneer een agent overgaat naar een geblokkeerde toestand (bijvoorbeeld wachtend op een gereedschapsresultaat van een sub-agent), wordt een gerichte pijl toegevoegd. Vervolgens kan een algoritme zoals het algoritme van Tarjan voor sterk samenhangende componenten worden uitgevoerd om lussen direct te signaleren.

 interface DependencyNode {
 agentId: string;
 waitingFor: string[]; // agentIds of resourceKeys
 timestamp: number;
}

class DeadlockDetector {
 private graph: Map<string, Set<string>> = new Map();

 public registerWait(sourceId: string, targetId: string): boolean {
 if (!this.graph.has(sourceId)) {
 this.graph.set(sourceId, new Set());
 }
 this.graph.get(sourceId)!.add(targetId);
 return this.hasCycle(sourceId);
 }

 public releaseWait(sourceId: string, targetId: string): void {
 const targets = this.graph.get(sourceId);
 if (targets) {
 targets.delete(targetId);
 if (targets.size === 0) this.graph.delete(sourceId);
 }
 }

 private hasCycle(startId: string): boolean {
 const visited = new Set<string>();
 const stack = new Set<string>();

 const dfs = (current: string): boolean => {
 visited.add(current);
 stack.add(current);

 const neighbors = this.graph.get(current) || new Set();
 for (const neighbor of neighbors) {
 if (!visited.has(neighbor)) {
 if (dfs(neighbor)) return true;
 } else if (stack.has(neighbor)) {
 return true; // Cyclus aangetroffen
 }
 }

 stack.delete(current);
 return false;
 };

 return dfs(startId);
 }
}

 Bovenstaand type detectie werkt uitsluitend als het mechanisme achter de wachtstatus expliciet is. In asynchrone Python- of Node.js-architecturen moet elke wachtoperatie worden ingekapseld in een contextmanager die zichzelf registreert bij de orchestrator. Zodra hasCycle een waarheidswaarde teruggeeft, hoeft het systeem niet te wachten op een generieke timeout, maar kan direct een gerichte herstelactie worden geïnitieerd.

 
## Semantische patstellingen en herhalende lussen identificeren

 Semantische deadlocks worden niet zichtbaar in een traditionele WFG omdat de processen technisch gezien niet stilstaan. De agents blijven tokens consumeren en berichten uitwisselen. Om dit op te sporen, moeten we kijken naar de informatiedichtheid en de semantische afstand tussen opeenvolgende berichten.

 Een beproefde meetmethode bestaat uit het bijhouden van een glijdend venster van embeddings over de laatste $N$ interacties tussen twee agents. Als de cosinus-gelijkenis tussen opeenvolgende berichten van dezelfde agent structureel boven de $0.92$ blijft, terwijl de contextlengte lineair toeneemt, wijst dit op een semantische kringloop. De modellen parafraseren dan simpelweg eerdere bezwaren zonder nieuwe feiten of beslissingen in te brengen. Ook het herhaaldelijk falen van syntax- of typesystemen valt hieronder; om te begrijpen hoe je dit bij codegenererende agents strak dichttimmert, lees je over [determinisme afdwingen bij agentic code-generatie](https://radar.llmnet.nl/determinisme-afdwingen-bij-agentic-code-generatie) om ongeldige interacties direct op syntaxisniveau te blokkeren.

 
 
 
 
 Symptoom | 
 Type Deadlock | 
 Primaire Detectiemethode | 
 Herstelactie | 
 

 
 
 
 CPU/I/O op 0%, geen tokenverbruik | 
 Structureel (Mutex / Resource lock) | 
 Wait-For-Graph cyclusanalyse | 
 Resource preemptie en geforceerde unlock | 
 

 
 Continu tokenverbruik, herhalende teksten | 
 Semantisch (Beleefdheids- of verduidelijkingslus) | 
 Embedding cosine-similarity > 0.92 | 
 Injectie van syntheserol / scheidsrechter | 
 

 
 Wisselende agentfouten op tool-level | 
 Cascaderend (Protocol mismatch) | 
 Transitie-teller per taak-ID (> max hops) | 
 Staat terugrollen en prompt-aanpassing | 
 

 
 Time-out op externe API-integratie | 
 Infrastructuur (Dangling promise) | 
 Gedistribueerde heartbeat monitor | 
 Graceful degradation naar fallback-model | 
 

 
 
 

 
## Dynamische timeouts versus exponentiële backoff met jitter

 De meest basale verdedigingslinie tegen oneindig wachtende processen is een statische time-out. In complexe multi-agent systemen leidt een harde, statische time-out echter vaak tot onnodige afbrekingen van zware, valide rekentaken of juist tot veel te lange periodes van inactiviteit bij daadwerkelijke crashes.

 Een effectievere aanpak is het toepassen van dynamische timeouts die gekoppeld zijn aan de verwachte tokengeneratiesnelheid en het aantal actieve sub-taken. Als een agent een taak delegeert, berekent de runtime een tijdvenster op basis van historische latentiecijfers voor dat specifieke prompttype. Wanneer een agent merkt dat een afhankelijke service of collega-agent niet reageert, moet herhaling niet simultaan plaatsvinden. Als vijf agents tegelijkertijd een mislukte tool opnieuw aanroepen, veroorzaken ze een zogeheten thundering herd die de onderliggende modelgateway overbelast.

 Om dit te voorkomen combineert de architectuur exponentiële backoff met willekeurige ruis (jitter). Hierbij wordt de wachttijd per herhaalde poging progressief verdubbeld en vermenigvuldigd met een toevalsfactor. Dit spreidt de belasting over de tijd en geeft vastgelopen deelsystemen de ruimte om interne wachtrijen leeg te werken zonder dat het hele netwerk vastslaat. Mocht een onderliggende API-infrastructuur geheel niet meer reageren, dan schakelt de orchestrator automatisch door via patronen voor [provider-failover om storingen direct op te vangen](https://api.llmnet.nl/provider-failover-automatisch-omzetten-bij-een-storing) zonder dat de bovenliggende agentcyclus blokkeert.

 
## Scheidsrechter-patronen en deterministische circuit breakers

 Wanneer een semantische lus of naderende deadlock wordt vastgesteld, schiet reguliere agent-communicatie tekort. Twee agents die elkaar tegenspreken, kunnen zichzelf zelden zonder externe interventie corrigeren. Hier komt het scheidsrechter-patroon (Judge of Arbiter Pattern) in beeld.

 De scheidsrechter is een geprivilegieerde toezichthouder die buiten de reguliere agent-interactie staat. Deze component luistert mee op de berichtenbus en grijpt in zodra de deadlock-detectoren alarm slaan. De scheidsrechter krijgt een strikt deterministische opdracht: analyseer de vastgelopen discussiehistorie, identificeer het conflictpunt en hak een definitieve knoop door. Deze uitspraak wordt als een bindend feit in de contextbuffers van beide strijdende agents geïnjecteerd.

 Daarnaast fungeert een circuit breaker als hardwarematige noodstop. Als een specifieke combinatie van agents binnen een taak meer dan een vooraf ingesteld aantal iteraties (bijvoorbeeld 6 interacties) uitvoert zonder de status van het artefact te wijzigen, slaat de circuit breaker direct door naar de toestand OPEN. De runtime breekt de berichtenstroom af, logt de volledige stacktrace en schakelt over naar een deterministisch noodscenario of retourneert een gecontroleerde foutmelding aan de eindgebruiker.

 
## Staatstransities, snapshots en rollback-mechanismen

 Het doorbreken van een deadlock is waardeloos als het systeem achterblijft in een inconsistente of corrupte toestand. Wanneer Agent A halverwege een SQL-mutatie strandt omdat Agent B weigert het validatietoken af te geven, mag de database niet in een half-gemuteerde toestand blijven hangen. Het beheer van state moet daarom transactie-gebaseerd zijn.

 Elke significante interactie tussen agents vormt een discrete staatstransitie binnen een centrale state graph. Voordat een agent een actie uitvoert die invloed heeft op externe bronnen of het centrale werkgeheugen, maakt de runtime een onveranderlijke momentopname (snapshot) van de globale status. Wordt er een deadlock gedetecteerd die niet via een semantische hint kan worden opgelost, dan voert de orchestrator een rollback uit naar het laatste consistente knooppunt.

 Tijdens zo'n rollback worden niet alleen variabelen hersteld, maar worden ook eventuele caching-lagen gewist of juist bijgewerkt om te voorkomen dat het model direct weer in dezelfde deterministische foutroute stapt. Hoe je dergelijke geheugensystemen en tussenopslagen schaalbaar inricht, ontdek je in de gids over [caching-architecturen voor complexe multi-agent loops](https://radar.llmnet.nl/caching-architecturen-voor-complexe-multi-agent-loops), waarin het balanceren tussen herbruikbare context en schone buffers centraal staat.

 
## Gedistribueerde observatietracering in productie

 Het achteraf analyseren van een vastgelopen multi-agent interactie is nagenoeg onmogelijk zonder gedetailleerde distributed tracing. Omdat agents parallel opereren en asynchroon berichten uitwisselen, volstaan traditionele logbestanden met platte tijdstempels niet. We hebben contextuele correlatie-ID's en causale boomstructuren nodig.

 Door elke taak te voorzien van een uniek TraceID en elke individuele stap van een SpanID en ParentSpanID, ontstaat een helder overzicht van wie op wie wachtte op het moment van blokkade. OpenTelemetry-compatibele spans kunnen metadata bevatten zoals het tokenverbruik, de specifieke toolnaam en de berekende cosine similarity van het bericht. Om te zien hoe je deze meetgegevens effectief visualiseert en correleert in je operationele dashboards, raadpleeg je het overzicht over [agent-observability en monitoring](https://community.llmnet.nl/agent-observability-zien-wat-je-agent-deed-en-waarom) voor praktische richtlijnen rondom trace-analyse.

 
## Ontwerppatronen om deadlocks fundamenteel te voorkomen

 Hoewel detectie en automatisch herstel onmisbaar zijn als vangnet, is het structureel voorkomen van deadlocks door slim softwareontwerp altijd superieur. Door de interactie-topologie van het agent-netwerk zorgvuldig te beperken, kan een aanzienlijk deel van de potentiële cirkelredeneringen al ontwerptijd worden geëlimineerd.

 Drie architectuurpatronen bieden hierbij uitkomst:

 1. Hiërarchische DAG-topologieën (Directed Acyclic Graphs): Laat agents uitsluitend communiceren volgens een strikte topologische volgorde. Een planningsagent mag taken delegeren aan uitvoerende agents, maar uitvoerende agents communiceren nooit horizontaal met elkaar zonder tussenkomst van de planner. Waar geen cyclus in de communicatiestructuur kan bestaan, is een structurele communicatiedeadlock topologisch onmogelijk.

 2. Asymmetrische prioriteitstoewijzing: Ken aan elke agent een vaste prioriteitsindex toe. Wanneer twee agents strijden om dezelfde resource of elkaar tegenspreken in een validatieslag, wint altijd de actor met de hoogste rangorde. De lagere agent moet zijn transactie direct afbreken en zijn toestand herzien.

 3. Strikte scheiding tussen plannen en uitvoeren: Meng redeneerprocessen over 'wat er moet gebeuren' niet met de daadwerkelijke 'uitvoering via tools'. Door de planningfase deterministisch af te sluiten voordat de executiefase van start gaat, voorkom je dat agents tijdens het uitvoeren van gereedschapsaanroepen plotseling de opdrachtdoelen gaan heronderhandelen.

 
## Veerkrachtige architecturen bouwen

 Multi-agent architecturen bieden enorme mogelijkheden voor het automatiseren van complexe, meerstaps bedrijfsprocessen. De stochastische aard van taalmodellen zorgt er echter voor dat klassieke aannames over procesvolgorde en systeembetrouwbaarheid niet zonder meer opgaan. Een robuust productiesysteem kan niet vertrouwen op de hoop dat modellen altijd harmonieus samenwerken.

 Door wiskundige cyclusdetectie via gerichte grafen te combineren met semantische afstandsberekeningen, geautomatiseerde circuit breakers en transactiegerichte state rollbacks, ontstaat een betrouwbare runtime-laag. Hierdoor transformeren multi-agent experimenten van fragiele demonstraties naar veerkrachtige softwaresystemen die autonoom kunnen herstellen van onverwachte patstellingen.