AI-agentorkestratie: fouten, goedkeuringen en nieuwe pogingen

Meerdere agents die aan hetzelfde project werken: het klinkt uiterst efficiënt. De een plant het werk, een ander neemt het ontwerp voor zijn rekening en een derde schrijft de code. Het werkt, totdat het niet meer werkt. En dat gebeurt vaker dan je zou willen.

Om zulke fouten te voorkomen is zorgvuldige workflow-engineering nodig. Laten we daarom ontrafelen wat georkestreerde workflows onbetrouwbaar maakt en best practices voor orkestratie verkennen die zorgen voor betrouwbaarheid in productie.

Orkestratie van AI-agents coördineert meerdere AI-agents, modellen en tools om een taak met meerdere stappen uit te voeren. Maar iemand — of iets — moet nog steeds bepalen welke agent als eerste draait, welke informatie die krijgt en wat er gebeurt nadat die klaar is. Dat is de rol van de orchestrator: een AI-agent die optreedt als manager, of een door software aangestuurde uitvoeringslaag.

Simpel gezegd splitst een orkestratielaag een doel op in kleinere taken, houdt afhankelijkheden bij, delegeert de uitvoering aan de juiste agents, beheert gedeelde context en brengt de resultaten samen.

Diagram van de uitvoeringsengine voor orkestratie: doel en plan, routering naar agents, geïsoleerde uitvoering van tools, gestructureerde resultaten, persistente workflowstatus en een stap voor valideren en beslissen die opnieuw probeert, terugkeert, pauzeert, wacht of doorgaat naar de volgende taak.

Laten we bekijken wat er gebeurt nadat je een orchestrator een taak hebt gegeven.

Neem een voorbeeld uit de Computer-workshop van Perplexity: het bouwen van een dashboard met accountinzichten op basis van gegevens uit Salesforce, Snowflake, e-mail, agenda en recent nieuws.

Begrijp het doel en plan het werk. De orchestrator begint bij het gevraagde resultaat en splitst dat op in taken met expliciete afhankelijkheden. In ons dashboardvoorbeeld betekent dat informatie verzamelen uit verschillende bronnen en die omzetten in een afgerond eindproduct. De planner legt vast welke stappen van andere afhankelijk zijn en welke onafhankelijk kunnen worden uitgevoerd.
Routeer taken naar de juiste agents. De orchestrator bepaalt welke taken aan hun afhankelijkheden voldoen en delegeert werk aan gespecialiseerde agents of modellen. Afhankelijke taken wachten op hun voorwaarden. Perplexity Computer gebruikt meerdere frontier-modellen en routeert verschillende delen van de workflow naar systemen die geschikt zijn voor die taken. Zo kan onafhankelijk werk ook parallel worden uitgevoerd.
Voer toolaanroepen uit in gecontroleerde omgevingen. Agents communiceren met hun omgeving via tools, zoals zoeken op het web, API’s, gekoppelde applicaties, bestandsbewerkingen of het uitvoeren van code. De uitvoeringslaag voert deze acties uit en stuurt de resultaten terug naar de agents.
Geef resultaten en context door tussen agents. Zodra een agent zijn taak heeft voltooid, heeft de volgende agent verderop in de keten de relevante output nodig om verder te kunnen. Een overdrachtsrecord kan een taak-ID, outputverwijzing, schemaversie en bronmetadata bevatten. De orchestrator coördineert deze overdrachten en bewaart de context die nodig is voor de volgende stappen. Belangrijk is dat agents niet de volledige geschiedenis van het werk van alle andere agents in hun eigen contextvensters hoeven mee te dragen.
Leg de uitvoeringsstatus vast los van de agentcontext. Wanneer agents taken starten, voltooien of daarin falen, werkt de uitvoeringsengine een persistent workflowrecord bij met taakstatussen, uitvoeringspogingen, outputverwijzingen en resterend werk. Met dit record kan de orchestrator de voortgang bijhouden en na onderbrekingen verdergaan, zonder dat een LLM de workflow uit de gespreksgeschiedenis hoeft te reconstrueren.
Valideer resultaten en bepaal wat er daarna gebeurt. Wanneer een taak terugkomt, controleert de orkestratielaag of de output aan het verwachte contract voldoet en of aan de afhankelijkheden van de volgende taak is voldaan. Als er een probleem wordt gevonden, kan de workflow terugkeren naar een eerdere stap voor correctie of worden gepauzeerd. Anders gaat de workflow verder richting voltooiing.

Achter wat eenvoudige orkestratie van AI-agents lijkt, zitten veel bewegende onderdelen. Hoe je de coördinatie tussen agents organiseert, bepaalt hoeveel controle je hebt over de uitvoering. En al die coördinatie brengt natuurlijk overhead met zich mee. Het is dus niet altijd de moeite waard.

Overweeg orkestratie met meerdere agents wanneer verschillende delen van de taak specifieke expertise vereisen, onafhankelijk werk parallel kan worden uitgevoerd of je de volgende stap niet vooraf kunt bepalen.

Orkestratie is dus nuttig in drie scenario’s:

Taken vereisen verschillende specialisaties. Een codeerproject kan bijvoorbeeld baat hebben bij aparte agents voor planning, ontwerp, ontwikkeling en review.
Onafhankelijke taken kunnen parallel worden uitgevoerd. In plaats van één agent alles achter elkaar te laten doen, kunnen meerdere agents tegelijk werken en hun resultaten teruggeven aan een orchestrator.
Het probleem is open van aard. Agents moeten mogelijk verschillende benaderingen verkennen, beslissingen nemen en samenwerken in plaats van een vooraf bepaalde volgorde te volgen.

Verder is orkestratie gewoon een dure trend. Meer agents betekenen ook meer coördinatie en mogelijk hogere tokenkosten.

“Ik begin meestal met de eenvoudigste optie en bouw van daaruit verder. Als we de stappen kennen en ze herhaalbaar zijn, is het waarschijnlijk een workflow. Ik zie alleen een reden om meerdere agents in te zetten als ze verschillende verantwoordelijkheden, machtigingen of gebruikers hebben”, zegt Josh Spilker, hoofd zoekmachinemarketing bij AirOps.

Weeg zelfs dan de voordelen af tegen extra modelaanroepen, overdrachten, latentie en faalpunten.

Er zijn drie gangbare manieren om de coördinatie tussen agents te structureren: gecentraliseerde, gedecentraliseerde en hiërarchische orkestratie. De keuze voor de juiste architectuur komt neer op één vraag: wie heeft de regie over het werk, en hoe coördineren agents met elkaar?

Bij gecentraliseerde orkestratie beheert één orchestrator het proces. Die splitst de taak op, delegeert werk aan gespecialiseerde agents, volgt hun voortgang en brengt hun resultaten samen.

Diagram van gecentraliseerde orkestratie: één orchestrator ontvangt het verzoek van de gebruiker en delegeert aan agents voor onderzoek, analyse en ontwerp, die elk hun eigen tools gebruiken en waarvan de resultaten samenkomen in een definitief dashboard.

De afweging: Gecentraliseerde coördinatie maakt het makkelijker om de uitvoering te volgen en gemeenschappelijke regels toe te passen op één controlepunt. De orchestrator kan echter een knelpunt worden, en als die uitvalt, kan de hele workflow worden onderbroken, tenzij het systeem herstel ondersteunt.

Bij gedecentraliseerde orkestratie coördineren agents directer met elkaar, in plaats van te vertrouwen op één manager die elke beslissing neemt. Ze kunnen berichten uitwisselen, gedeelde status lezen en zelfstandig hun volgende stappen bepalen.

Diagram van gedecentraliseerde orkestratie: agents voor onderzoek, analyse, ontwerp en review communiceren rechtstreeks met elkaar en met gedeelde status en tools om een definitief dashboard te maken.

De afweging: Agents kunnen werken zonder te wachten op een centrale planner, waardoor deze aanpak nuttig is voor verkennend werk en onafhankelijke bijdragen. Maar coördinatie wordt lastiger wanneer agents het oneens zijn, gedeelde informatie bijwerken of tot een consistent resultaat moeten komen.

Hiërarchische orkestratie breidt de managerbenadering uit over meerdere niveaus. Een orchestrator op het hoogste niveau delegeert verantwoordelijkheid aan ondergeschikte orchestrators, die hun eigen groepen gespecialiseerde agents coördineren.

Denk aan een bedrijfsworkflow waarbij verkoop-, financiële en juridische teams betrokken zijn. Een orchestrator op het hoogste niveau kan elke werkstroom delegeren aan een domeinspecifieke coördinator. Die coördinatoren beheren vervolgens hun eigen gespecialiseerde agents en rapporteren geconsolideerde resultaten.

Deze structuur kan helpen wanneer workflows te omvangrijk zijn om door één orchestrator effectief te worden beheerd.

Diagram van hiërarchische orkestratie: een orchestrator op het hoogste niveau delegeert aan orchestrators voor verkoop, financiën en juridische zaken, die elk twee gespecialiseerde agents aansturen en waarvan het werk samenkomt in een geconsolideerd resultaat.

De afweging: Met hiërarchieën kunnen teams coördinatieverantwoordelijkheden verdelen en mogelijk storingen binnen afzonderlijke takken afhandelen. Ze brengen echter extra overdrachten, complexer statusbeheer en meer operationele overhead met zich mee. Lokaal herstel hangt bovendien af van hoe checkpoints en uitvoeringsstatus zijn geïmplementeerd.

Zo verhouden deze architecturen zich tot elkaar:

Criteria	Gecentraliseerd	Gedecentraliseerd	Hiërarchisch
Eigenaarschap van uitvoering	Eén orchestrator beheert de delegatie	Agents coördineren via peers of gedeelde status	Verantwoordelijkheid is verdeeld over orkestratieniveaus
Consistentie van status	Makkelijker te coördineren via één controlepunt	Vereist expliciete synchronisatie en conflictafhandeling	Vereist coördinatie binnen en tussen takken
Isolatie van storingen	Centrale controller kan een kritieke afhankelijkheid worden	Afzonderlijke agents kunnen onafhankelijk uitvallen, maar gedeelde infrastructuur blijft kritiek	Storingen kunnen binnen takken worden ingedamd als het systeem is ontworpen voor herstel
Beleidshandhaving	Gemeenschappelijke controles kunnen centraal worden afgedwongen	Beleid moet consistent worden gehandhaafd bij alle deelnemers	Controles kunnen op globaal niveau en op domeinniveau worden toegepast
Operationele complexiteit	Over het algemeen lager	Hogere coördinatiecomplexiteit	Hogere complexiteit door meerdere orkestratielagen

Er is nog één onderscheid dat het begrijpen waard is. De architectuur bepaalt wie de agents coördineert. Het uitvoeringspatroon bepaalt hoe hun taken verlopen.

Dit zijn drie uitvoeringspatronen:

Sequentiële workflows: Agents werken in een vooraf bepaalde volgorde, waarbij het resultaat van de ene agent de input van een andere wordt.
Parallelle uitvoering: Onafhankelijke agents werken tegelijkertijd.
Uitvoering op basis van overdracht: De controle gaat over tussen gespecialiseerde agents naarmate de taak vordert. Dit is handig wanneer een andere agent beter is toegerust om de volgende stap uit te voeren, al moet bij elke overdracht de informatie behouden blijven die nodig is om verder te gaan.

De patronen sluiten elkaar niet uit en komen niet één-op-één overeen met orkestratiearchitecturen. Het doel is om de eenvoudigste structuur te kiezen die past bij de afhankelijkheden, coördinatievereisten en aanvaardbare operationele overhead van je workflow.

Bij orkestratie kan van alles misgaan, van simpele vergissingen tot complexe blokkades. Soms lijkt een agent zelfs zijn werk correct te doen, terwijl de workflow als geheel faalt. Op basis van de ervaringen van mensen uit de praktijk hebben we enkele veelgemaakte fouten verzameld die ten grondslag liggen aan onbetrouwbare georkestreerde workflows — let er goed op:

Overdrachten tussen agents met informatieverlies. Een orchestrator geeft een samengevat plan door aan een gespecialiseerde agent, maar in de samenvatting ontbreken beperkingen, afhankelijkheden of implementatiedetails.
Voortijdige fan-in-uitvoering. Een downstream-agent begint resultaten samen te voegen voordat alle upstream-taken zijn voltooid.
Niet-deterministische updates van gedeelde status. Parallelle agents schrijven naar dezelfde statussleutels zonder goed gedefinieerde merge-semantiek. Afhankelijk van hoe het framework updates verwerkt, kan dit leiden tot verloren schrijfbewerkingen, gedupliceerde gegevens, volgordeafhankelijke output of conflicterende wijzigingen.
Divergentie tussen checkpoints en neveneffecten. Een taak voert een externe bewerking uit, maar de succesvolle uitvoering wordt niet duurzaam vastgelegd voordat de worker uitvalt. Bij het herstel ziet de orchestrator een onvoltooide taak en voert die opnieuw uit.
Race conditions bij hervatten na menselijke goedkeuring. Het pauzeren en hervatten van de uitvoering brengt eigen synchronisatieproblemen met zich mee.
Delegatielussen en zichzelf versterkende herhaalpogingen. Agents schuiven werk herhaaldelijk naar elkaar door omdat hun verantwoordelijkheden overlappen, afhankelijkheden circulair zijn of voltooiingsvoorwaarden dubbelzinnig zijn.
Controles op instructieniveau aangezien voor uitvoeringsbeveiliging. Een orchestrator kan agents opdragen bepaalde resources niet te benaderen of geen gevoelige acties uit te voeren, maar modelinstructies dwingen geen besturingssysteemrechten, netwerkbeperkingen of autorisatiegrenzen af. Het onderzoek naar security engineering van Perplexity laat zien waarom agents beveiligingsgrenzen kunnen overschrijden terwijl ze legitieme doelen nastreven, zelfs zonder kwaadwillende instructies

Merk op hoe verschillend deze fouten zijn. Een voortijdige schedulerovergang of een dubbelzinnige externe schrijfbewerking kan allebei tot een onjuist resultaat leiden, maar ze ontstaan in verschillende delen van de uitvoeringslevenscyclus. Daarom vraagt betrouwbare orkestratie om meer dan het verbeteren van prompts of het toevoegen van herhaalpogingen.

Vage doelen en een onduidelijke definition of done leiden vaak tot teleurstellende resultaten van agents. De oplossing is een promptcontract (een werkomschrijving voor een agent): spreek het doel, de beperkingen, het outputformaat en de faalvoorwaarden af voordat de uitvoering begint.

Zo zou je bijvoorbeeld een contract kunnen opstellen voor een agent die een af en toe falende integratietest moet repareren:

Doel: De oorzaak van een flaky integratietest voor de checkout-API vinden en oplossen.
Invoer: Broncode van de test, CI-foutlogs, recente commits en relevante applicatiecode.
Beperkingen: Schakel geen tests uit, versoepel geen asserties en wijzig geen ongerelateerd applicatiegedrag.
Verwachte output: Een codepatch, een uitleg van de hoofdoorzaak en de resultaten van de testuitvoering.
Acceptatiecriteria: De eerder falende test slaagt bij 10 opeenvolgende runs en de relevante regressiesuite slaagt.
Faalvoorwaarden: De hoofdoorzaak kan niet worden vastgesteld, de fix introduceert regressies of de vereiste testomgeving is niet beschikbaar.

Maar er is nog een belangrijk onderdeel: wanneer moet de agent stoppen?

Een agent moet niet eindeloos blijven itereren omdat hij nog geen bevredigend resultaat heeft opgeleverd. Bepaal wat geldt als succesvolle voltooiing, wanneer een gedeeltelijk voltooide taak moet worden teruggegeven en wanneer er moet worden gestopt omdat niet aan een vereiste kan worden voldaan. Stel een maximale delegatiediepte en iteratielimieten of uitvoeringsbudgetten in, zodat onopgeloste taken geen eindeloze lussen worden.

Terug naar ons CI-voorbeeld. Je zou de volgende stopvoorwaarden kunnen definiëren:

Succes: De fix doorstaat 10 opeenvolgende testruns en de relevante regressiesuite.
Iteratielimiet: De agent mag maximaal twee kandidaat-fixes proberen.
Uitvoeringsbudget: De agent moet na 60 minuten stoppen, zelfs als het probleem nog niet is opgelost.
Delegatielimiet: De agent mag werk delegeren aan één gespecialiseerde agent, zonder verdere delegatie aan subagents.
Gedeeltelijke voltooiing: Als beide pogingen mislukken of de tijdslimiet verstrijkt, geeft de agent zijn bevindingen, geprobeerde wijzigingen en testresultaten terug.
Geblokkeerde uitvoering: Als de testomgeving niet beschikbaar is, stopt de agent en meldt hij de blokkade in plaats van succes te claimen.

Soms geven ontwikkelaars een orchestrator te veel verantwoordelijkheden, en in plaats van gespecialiseerde agents te coördineren, gaat hij zelf code schrijven, debuggen of gedetailleerde reviews uitvoeren. Dit creëert een knelpunt: de orchestrator besteedt zijn contextbudget aan implementatiedetails, stelt delegatie uit en vertroebelt de verantwoordelijkheid voor de resultaten.

Laat orchestrators dus hun werk doen en dwing overdrachten af door te verwijzen naar concrete artefacten: de oorspronkelijke taak, relevante inputs, outputartefacten, de uitvoeringsstatus en eventuele openstaande problemen.

Neem dit voorbeeld: status: completed verwijst naar het toegewezen werk van de agent, niet naar de hele workflow. Omdat de tests nog pending zijn, mag de orchestrator het eindresultaat niet goedkeuren.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

De gespreksgeschiedenis van een agent is geen betrouwbaar overzicht van de voortgang van een workflow. Wanneer het contextvenster volloopt, kan automatische compactie belangrijke details laten wegvallen. En als een worker crasht, moet de volgende agent weten welke stappen daadwerkelijk zijn voltooid.

Als de coding-agent bijvoorbeeld een patch genereert en vervolgens crasht, moet de volgende worker het opgeslagen artefact ophalen en verdergaan vanaf de vastgelegde workflowstatus. Maar als de agent ook een externe CI-run heeft gestart, moet de orchestrator die run apart afstemmen voordat de actie wordt herhaald

Houd de uitvoeringsstatus dus gescheiden van de werkcontext van de agent. Sla taakstatussen, uitvoeringspogingen, voltooide stappen en verwijzingen naar artefacten op in duurzame opslag. Laad intussen alleen de instructies, inputs en resultaten die relevant zijn voor de huidige taak van de agent, in plaats van de volledige uitvoeringsgeschiedenis in het contextvenster te proppen.

Stel dat je CI-agent een testrun start, maar dat het API-verzoek een time-out krijgt. Is de testrun niet gestart, of heeft de CI-service hem in de wachtrij gezet en is de respons verloren gegaan?

Een time-out betekent niet per se dat een bewerking is mislukt. Daarom moet je onderscheid maken tussen fouten voordat je bepaalt wat er vervolgens gebeurt:

Tijdelijke fouten (429, 503): Probeer het opnieuw met begrensde exponentiële backoff en jitter, en respecteer Retry-After als die wordt meegegeven.
Validatie- of machtigingsfouten (400, 403): Stop of corrigeer het onderliggende probleem in plaats van hetzelfde verzoek te herhalen.
Onduidelijke uitkomsten (time-out na een mogelijke schrijfbewerking): Controleer of de bewerking is geslaagd voordat je het opnieuw probeert.

Opmerking: Ook fouten die opnieuw geprobeerd kunnen worden, hebben limieten nodig. Stel een time-out in voor elke toolaanroep, begrens het aantal herhaalpogingen en de totale tijd daarvoor, en hanteer een algemene deadline voor de workflow, zodat geneste agents niet steeds dezelfde bewerking opnieuw kunnen starten. Als een afhankelijkheid herhaaldelijk faalt, gebruik dan een circuit breaker om verzoeken tijdelijk te stoppen.

Wijs voor bewerkingen met externe neveneffecten een stabiele idempotentiesleutel toe aan elke logische actie en hergebruik die bij alle herhaalpogingen. Als de API deduplicatie aan de serverzijde ondersteunt, kan die herhaalde verzoeken herkennen zonder de actie twee keer uit te voeren. Als dat niet zo is, raadpleeg het externe systeem dan met een correlatie-ID of een andere gezaghebbende referentie.

Als je niet kunt vaststellen wat er is gebeurd, stop dan en escaleer.

Een voorbeeld van de retrylogica voor onze CI-agent, uitgedrukt in pseudocode:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Opmerking bij de code: Het voorbeeld gaat ervan uit dat de CI-API het opzoeken van runs op basis van een request-ID ondersteunt. De request_id voorkomt alleen duplicaten als de provider idempotentie expliciet garandeert. bounded_retry() is illustratieve pseudocode. In productie moeten herhaalpogingen worden begrensd door zowel een retrybudget per bewerking (maximaal aantal pogingen of verstreken tijd) als de algemene deadline van de workflow.

Overweeg voor langere workflows die meerdere services omvatten het Saga-patroon om compenserende acties te coördineren wanneer latere stappen mislukken. Onthoud wel dat compensatie niet altijd een volledige rollback is. Je kunt een database-update terugdraaien, maar een verzonden e-mail haal je niet terug.

Er zijn hier twee dingen die je in balans moet brengen: hoeveel modelcapaciteit elke taak nodig heeft en hoeveel taken je tegelijkertijd kunt uitvoeren. Zit je bij een van beide verkeerd, dan loop je het risico dat agents met elkaar concurreren om gedeelde API-quota of uitsluitend op dure redeneermodellen leunen.

Voor modelselectie stem je de modelcapaciteit en de redeneerinspanning af op de complexiteit van de taak — eenvoudig, maar vaak over het hoofd gezien. Je kunt zelf routeringsregels configureren en modellen evalueren, of een orkestratieplatform gebruiken dat de modelselectie voor je regelt.

Met de Effort Mode van Perplexity Computer kies je bijvoorbeeld hoeveel inspanning een taak verdient, zonder handmatig een model te selecteren. Kies Light, Standard, High of Ultra, en Perplexity selecteert automatisch het orkestrerende model en het bijbehorende redeneerniveau. Die orchestrator delegeert vervolgens subtaken aan ondersteunende agents, die modellen van verschillende providers kunnen gebruiken.

Perplexity evalueert modelconfiguraties op kwaliteit en kosten, met een voorkeur voor goedkopere opties die vergelijkbare resultaten opleveren. Je kunt ook de Custom-instellingen gebruiken als je het model en het redeneerniveau liever zelf kiest.

Voor parallellisme moet de limiet voortkomen uit je infrastructuur en externe afhankelijkheden. Controleer de rate limits voor verzoeken en tokens van gedeelde API's en voer vervolgens een loadtest uit op je workflow met toenemende concurrency. Kijk of de doorvoer verbetert of dat verzoeken in de wachtrij belanden, trager worden of 429-fouten retourneren.

Om het resourceverbruik voorspelbaar te houden, dwing je resourcelimieten en planningscontroles af:

Beheers concurrency en verzoeksnelheden: Begrens het aantal lopende aanroepen per service en zet overtollig werk in de wachtrij. Onthoud dat een concurrencylimiet op zichzelf geen limieten voor verzoeken per minuut of tokens per minuut afdwingt.
Houd token- en kostenbudgetten bij: Breng het gebruik over de hele workflow in kaart, inclusief subagents, en start geen nieuw werk meer wanneer het resterende budget onvoldoende is.
Dwing uitvoeringsdeadlines af: Stel tijdslimieten in voor taken en workflows, en geef annuleringen door aan actieve agents waar dat wordt ondersteund.
Respecteer afhankelijkheden: Start downstream-taken pas wanneer de vereiste inputs beschikbaar zijn, in plaats van alle agents tegelijk te starten.

Vraag het model nooit om zelf te beslissen of zijn eigen acties veilig zijn. Geef agents in plaats daarvan rechten volgens het principe van minimale bevoegdheden en dwing risicogebaseerde goedkeuringsregels af in de applicatiecode. Als agents code uitvoeren, isoleer die uitvoering dan van je hostomgeving en beperk de toegang tot bestanden, netwerken en inloggegevens. Zo beperk je de schade als de agent een fout maakt of onveilige code uitvoert.

“Ik sta sceptisch tegenover overdreven ingewikkelde multi-agentsystemen, vooral wanneer agents elkaars werk beoordelen en goedkeuren. Je kunt dan eindigen met meerdere agents die vol vertrouwen dezelfde fout aan elkaar doorgeven, zonder dat iemand die daadwerkelijk opmerkt”, waarschuwt Spilker.

Diagram van een goedkeuringsproces: een agent stelt een bewerking voor met parameters, doelresource en statusversie; een mens keurt die goed of af; goedgekeurde bewerkingen worden opnieuw gevalideerd en uitgevoerd in een geïsoleerde omgeving met beperkte toegang tot bestanden, netwerk en inloggegevens. Afgewezen of verlopen verzoeken worden gesloten, en gewijzigde verzoeken hebben een nieuwe goedkeuring nodig.

Voor acties die menselijke goedkeuring vereisen, pauzeer je de uitvoering en sla je de exacte voorgestelde bewerking op:

de parameters
de doelresource
de commit- of statusversie
het besluit van de reviewer

Bepaal ook wat er gebeurt als goedkeuring wordt afgewezen, verloopt of escalatie vereist. Dit is essentieel voor hervatbare frameworks, omdat bij het hervatten van een onderbroken node de code vanaf het begin van die node opnieuw wordt uitgevoerd. Eventuele neveneffecten vóór de onderbreking kunnen opnieuw optreden.

Als goedkeuring dus wordt afgewezen of verloopt, wordt het verzoek gesloten. Als de doelcommit, parameters of rechten vóór de uitvoering veranderen, maak de goedkeuring dan ongeldig en vraag een nieuwe aan.

Spilker is ook geen voorstander van het idee dat volledig autonome end-to-end agents het doel zouden moeten zijn. “Voor mij is de betere aanpak om een paar gerichte agents te bouwen met duidelijke verantwoordelijkheden, gedefinieerde rechten en menselijke review op de juiste momenten. Je bereikt nog steeds efficiëntie zonder de volledige controle op te geven”, concludeert hij.

Heb je ooit meegemaakt dat een agent Success rapporteerde terwijl hij eigenlijk had gefaald? Vervelend, zo niet ronduit frustrerend, en het oplossen gaat niet snel, omdat het laatste bericht van de agent je niet per se vertelt waar het misging.

Om dit te onderzoeken, traceer je wat er tijdens de uitvoering is gebeurd en verifieer je de resultaten onafhankelijk. Laten we dus wat tijd besteden aan het isoleren en oplossen van het probleem.

Leg het volledige uitvoeringspad vast voordat je de prompts van een agent gaat debuggen. Je hebt een trace nodig die agentaanroepen, toolaanroepen, fouten en herhaalpogingen binnen dezelfde workflowrun met elkaar verbindt.

De GenAI semantic conventions van OpenTelemetry bieden een gestandaardiseerde manier om deze bewerkingen te beschrijven. Zo identificeert invoke_workflow de uitvoering van een workflow, invoke_agent een agentaanroep en execute_tool een toolaanroep. Elke bewerking kan worden vastgelegd als een span met de bijbehorende timing, status en relevante metadata.

Deze stap geeft je een trace van het uitvoeringspad, zodat je kunt zien waar een agent haperde.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Een illustratieve uitvoeringstrace.

Gebruik waar mogelijk programmatische controles. Valideer output aan de hand van JSON-schema's, voer unit- en integratietests uit, controleer of vereiste artefacten bestaan en raadpleeg externe systemen om te bevestigen dat acties daadwerkelijk zijn geslaagd.

Voor output die een subjectief oordeel vereist — en die dus niet met programmatische controles kan worden beoordeeld — zet je een onafhankelijke reviewer-agent in. Een mogelijke aanpak is een implementer–reviewer–resolver-lus, waarbij één agent een artefact produceert, een reviewer met een frisse context problemen signaleert en een resolver ze oplost voordat de validatie opnieuw wordt uitgevoerd.

Je moet de bevindingen van de reviewer waar mogelijk nog steeds valideren, en als je op LLM's gebaseerde beoordelaars gebruikt voor herhaalde evaluaties, kalibreer hun oordelen dan aan de hand van door mensen beoordeelde voorbeelden.

Tot nu toe heb je nagegaan wat de agents hebben uitgevoerd en gecontroleerd of hun output correct was. Maar wat gebeurt er als een worker halverwege een taak crasht of als een API een time-out geeft nadat een verzoek is geaccepteerd? Verrassend genoeg kan je workflow onder normale omstandigheden prima werken, maar tijdens het herstel falen.

Test dit door in een testomgeving bewust fouten te injecteren:

API-time-outs simuleren
Workers laten crashen tussen externe schrijfacties en checkpoints
Onjuist opgemaakte tooloutput retourneren
Goedkeuringen laten verlopen

Bekijk na elke test de uitvoeringstrace om te zien welke stappen zijn uitgevoerd, waar de workflow is hervat en of er acties zijn herhaald of overgeslagen. Controleer daarna de werkelijke resultaten.

Stel dat je CI-agent een verzoek stuurt om een testrun te starten, maar dat het API-antwoord een time-out geeft. De agent probeert het opnieuw, ontvangt een succesvol antwoord en meldt Success. Alles lijkt in orde, totdat je de CI-service controleert en ontdekt dat er twee testruns zijn aangemaakt in plaats van één.

Daarom moet je zowel de vastgelegde status van de workflow als de werkelijke wijzigingen in externe systemen verifiëren. Een hersteltest mag alleen slagen als de workflow de verwachte status bereikt zonder onbedoelde neveneffecten.

Voeg fouten die je ontdekt toe aan je regressietests, zodat toekomstige wijzigingen ze niet opnieuw introduceren.

Uiteindelijk betekent succes dat de workflow de vereiste controles heeft doorstaan en dat de externe resultaten zijn geverifieerd.

Geïsoleerde agents kunnen hun afzonderlijke taken correct uitvoeren en toch samen inconsistente resultaten opleveren. Stel je voor dat een verkoopagent om 10.00 uur klantvoorwaarden ophaalt, een prijsagent om 10.05 uur een offerte berekent met bijgewerkte prijzen en een juridische agent een contract controleert dat om 10.07 uur is gewijzigd. Elke agent werkt met een andere momentopname van het bedrijf, waardoor hun output elkaar kan tegenspreken.

Op ondernemingsschaal wordt het probleem nog duidelijker, omdat agents interactie hebben met meerdere systemen die onafhankelijk van elkaar worden bijgewerkt, met verschillende rechten werken en niet per se context of uitvoeringsstatus delen.

Stel limieten in op meerdere niveaus: een maximumaantal nieuwe pogingen voor toolaanroepen, een maximumaantal agentiteraties, een maximale delegatiediepte en een algemene deadline voor de workflow. Classificeer fouten voordat je het opnieuw probeert. Respecteer bij tijdelijke 429-responsen Retry-After als die wordt meegegeven. Gebruik anders begrensde exponentiële backoff met jitter.

Probeer ongewijzigde verzoeken niet opnieuw na validatie- of rechtenfouten. Als een downstreamservice herhaaldelijk faalt, kan een circuitbreaker voorkomen dat agents extra belasting genereren.

Het herstelmechanisme hangt af van je runtime. Bij LangGraph slaat een persistente checkpointer zoals PostgresSaver de graafstatus op onder een thread_id, zodat de uitvoering kan worden voortgezet vanaf de opgeslagen status. Bij Temporal kan een andere worker een workflow reconstrueren door de eventgeschiedenis opnieuw af te spelen. Tijdens het opnieuw afspelen worden eerder vastgelegde activiteitsresultaten hergebruikt.

Als de applicatie opnieuw wordt geïmplementeerd terwijl er nog workflows actief zijn, zijn opgeslagen statussen en uitvoeringsgeschiedenissen mogelijk niet meer compatibel. Temporal pakt dit aan met Worker Versioning en workflowpatching. Plan voor op checkpoints gebaseerde systemen schemamigraties en test het herstel op basis van bestaande opgeslagen statussen voordat je incompatibele wijzigingen uitrolt.

Voer dezelfde representatieve taken meerdere keren uit en maak onderscheid tussen pass@k (of ten minste één van de k pogingen slaagt) en pass^k (of alle k pogingen slagen)

Meet resultaten per taakcategorie en workflowversie in plaats van te vertrouwen op één totaal slagingspercentage. Houd het slagingspercentage bij de eerste poging bij, evenals de consistentie over herhaalde runs, de p95-latentie, de kosten per voltooide taak en het aandeel taken waarvoor menselijke tussenkomst nodig is. Rapporteer steekproefgroottes en onzekerheidsintervallen voor slagingspercentages.

Wat is orkestratie van AI-agents?

Hoe orkestratie van AI-agents werkt: een kijkje in de uitvoeringsengine

Wanneer moet je orkestratie van AI-agents gebruiken?

Architecturen voor orkestratie van AI-agents en hun afwegingen

Gecentraliseerde orkestratie

Gedecentraliseerde orkestratie

Hiërarchische orkestratie

Sequentiële, parallelle en op overdracht gebaseerde uitvoering

Veelvoorkomende fouten bij AI-agentorkestratie

7 best practices voor AI-agentorkestratie voor betrouwbaarheid in productie

1. Definieer expliciete taakcontracten, acceptatiecriteria en stopvoorwaarden

2. Houd orchestrators slank en dwing gestructureerde overdrachten af

3. Sla de workflowstatus persistent op en beheers de groei van de context

4. Ontwerp foutbewuste herhaalpogingen en herstelbare tooluitvoering

5. Routeer en paralleliseer werk met expliciete resourcebudgetten

6. Dwing goedkeuringen af en isoleer de uitvoering van agents

7. Verifieer output onafhankelijk en test het herstelgedrag

Traceer de workflow om te achterhalen wat er misging

Beoordeel de output onafhankelijk

Injecteer fouten om het herstel te testen

Veelgestelde vragen over AI-agentorkestratie

Waarom lopen geïsoleerde AI-agents vast op ondernemingsschaal?

Hoe voorkom je oneindige retry-lussen bij AI-agents?

Hoe hervat je een AI-agentworkflow na een crash?

Hoe test je de betrouwbaarheid van AI-agentorkestratie?