AI-agent orkestratie is het coördineren van meerdere gespecialiseerde AI-agents, en de mensen achter hen, zodat één klantvraag op het juiste moment en met de juiste context bij de juiste agent terechtkomt. Een orchestrator, ofwel een leidende agent, ofwel de code rond de agents, bepaalt wie als volgende handelt, wat er wordt doorgegeven en wanneer het werk klaar is.
In het kort
- Orkestratie bepaalt welke agent elke stap van een gesprek afhandelt, welke context hij krijgt en wanneer een mens het overneemt.
- De meeste supportopstellingen combineren een paar patronen: een router of supervisor vooraan, opeenvolgende stappen voor gereguleerde acties, en overdrachten tussen agents en naar mensen.
- Gesprekken met meerdere agents breken op de naden: context die verloren gaat bij een overdracht, lussen tussen agents, de verkeerde agent die handelt, en gesprekken die worden gesloten voordat het werk klaar is.
- Dashboards per agent verbergen die fouten, omdat elke agent er goed kan uitzien terwijl de klantreis mislukt.
- Doe kwaliteitscontrole op de klantreis, niet op de beurt: voeg elk segment van agent en mens samen tot één record, scoor de naden en wijs elke fout toe aan het segment dat hem veroorzaakte.
Wat is AI-agent orkestratie?
AI-agent orkestratie is de laag die meerdere AI-agents binnen één systeem coördineert. IBM beschrijft het als het coördineren van gespecialiseerde agents richting gedeelde doelen, met een orchestrator die een centrale agent of een framework kan zijn. In de klantenservice maakt het van een triagebot, een facturatieagent, een retouragent en je menselijke team één ervaring.
Een AI-agent (in het Engels) is één model met instructies en tools dat naar een doel toewerkt. Orkestratie is de verkeersregeling tussen meerdere daarvan, en beantwoordt bij elke beurt vier vragen:
- Wie handelt als volgende? Een triageagent, een specialist, een mens, of niemand (het gesprek is klaar).
- Wat krijgen ze mee? Het volledige transcript, een samenvatting, of alleen de velden die ze nodig hebben.
- Wat mogen ze doen? Data lezen, een bestelling wijzigen, een terugbetaling doen, of alleen antwoorden.
- Wanneer stopt het? Het doel is bereikt, een limiet voor het aantal beurten is bereikt, of een mens moet goedkeuren.
Anthropic noemt systemen waarin “LLMs and tools are orchestrated through predefined code paths” (LLM’s en tools via vooraf vastgelegde codepaden worden georkestreerd) workflows, en systemen waarin modellen “dynamically direct their own processes and tool usage” (hun eigen processen en toolgebruik dynamisch sturen) agents. De meeste orkestratie in support mengt beide: vaste paden voor terugbetalingen en identiteitscontroles, het oordeel van de agent voor open vragen. Onze uitleg over wat agentische AI is (in het Engels) behandelt de bredere categorie.
Wie is een AI-orchestrator? Technisch gezien het onderdeel (een leidende agent of een framework) dat het werk verdeelt. Organisatorisch de persoon of het team dat eigenaar is van hoe agents en mensen het werk verdelen: routeringsregels, escalatietriggers en de kwaliteitsstandaard voor de volledige klantreis.
Wat zijn de belangrijkste patronen voor AI-agent orkestratie?
Een handvol patronen dekt bijna elke supportopstelling: een router die elke vraag naar één specialist stuurt, een supervisor die de regie houdt en specialisten aanroept als tools, een vaste reeks stappen, parallelle agents die aan dezelfde input werken, een hiërarchie van supervisors, overdrachten tussen agents en naar mensen, en een maker-checkerlus. Echte implementaties combineren ze.
Leveranciers geven ze verschillende namen. Het Azure Architecture Center van Microsoft noemt sequential, concurrent, group chat, handoff en magentic orchestration (in het Engels) en merkt op dat handoff ook routing, triage, transfer, dispatch of delegation heet. De OpenAI Agents SDK (in het Engels) onderscheidt “agents as tools”, waarbij een manager de regie houdt, van “handoffs”, waarbij de specialist het overneemt. IBM voegt gecentraliseerde, gedecentraliseerde, hiërarchische en gefedereerde modellen toe. De woorden verschillen; de vragen voor support niet. De tabel hieronder beschrijft elk patroon in supporttermen.
Het belangrijkste onderscheid voor een supportmanager is wie eigenaar is van de klant na de wissel. In een opstelling met een supervisor blijft de leidende agent verantwoordelijk voor het eindantwoord. Bij een overdracht neemt de ontvangende agent het volledige eigenaarschap over, zoals de documentatie van Microsoft over handoff (in het Engels) uitlegt. Dat bepaalt wie je verantwoordelijk houdt als QA een slecht antwoord vindt.
De tabel met orkestratiepatronen: fouten en controles voor support
Elk orkestratiepatroon faalt op zijn eigen manier, dus elk heeft zijn eigen controle nodig. De tabel koppelt elk patroon aan een voorbeeld uit de support, de fout die je kunt verwachten en waar je bij de beoordeling op let. Kopieer hem in je QA-plan en houd de rijen die passen bij hoe je agents nu zijn opgezet.
| Patroon | Hoe het werkt | Voorbeeld uit de support | Typische fout | Wat je controleert |
|---|---|---|---|---|
| Router (triage) | Een triageagent classificeert de vraag en draagt hem over aan één specialist | “Waar blijft mijn terugbetaling?” gaat naar de facturatieagent | Verkeerde route: de orderagent beantwoordt met grote stelligheid een facturatievraag | Was de eerste route juist? Bleef de specialist binnen zijn scope? |
| Supervisor (manager) | Een leidende agent houdt het gesprek en roept specialisten aan als tools | De leidende agent vraagt de beleidsagent of een late retour is toegestaan | De leidende agent negeert of herschrijft het antwoord van een specialist; de klant krijgt een mix van beide | Komt het eindantwoord overeen met wat de specialist teruggaf? |
| Sequentieel (pipeline) | Vaste stappen, die elk de output van de vorige gebruiken | Identiteit verifiëren, voorwaarden controleren, terugbetaling doen, samenvatting sturen | Een vroege fout loopt door in elke stap (verkeerd ordernummer leidt tot de verkeerde terugbetaling) | Werd de output van elke stap gevalideerd voordat de volgende stap hem gebruikte? |
| Concurrent (parallel) | Meerdere agents werken tegelijk aan hetzelfde bericht | Het opstellen van een antwoord en een beleidscontrole lopen naast elkaar | Tegenstrijdige resultaten slecht samengevoegd; de klant ziet twee antwoorden | Als agents het oneens waren, welke won er dan, en was dat de juiste regel? |
| Hiërarchisch | Supervisors sturen per domein teams van agents aan | Een logistieke supervisor routeert tussen een track-and-trace-agent en een retouragent | Een vraag valt tussen twee supervisors en niemand is eigenaar | Is er op elk niveau één eigenaar voor elke klantreis? |
| Overdracht van agent naar agent | Elke agent beslist wanneer hij het gesprek doorgeeft | De orderagent geeft een geval met een beschadigd artikel door aan de retouragent | Lussen (A naar B naar A), verloren context, de klant moet dezelfde gegevens twee keer geven | Hoeveel overdrachten? Kwam een agent twee keer voor? Moest de klant informatie herhalen? |
| Overdracht naar een mens | Een agent escaleert met een samenvatting naar een persoon | De retouragent escaleert een betwiste afschrijving naar een medewerker | Escalatie te laat, of zonder samenvatting, zodat de medewerker bij nul begint | Juiste trigger, juiste moment, en had de medewerker de context die hij nodig had? |
| Maker-checker | Eén agent maakt een concept, een andere keurt het goed of stuurt het terug | Een agent stelt een coulanceaanbod op; een checker toetst het aan het beleid | De checker laat een fout concept door, of de lus draait tot een limiet en verstuurt toch de laatste versie | Wat doet de checker als hij de limiet voor iteraties bereikt? |
Overdrachten van agent naar agent hebben het grootste risico op lussen en verloren context, en bij overdrachten naar mensen merken klanten fouten het eerst. Onze gids over de overdracht tussen AI-agent en medewerker scoren gaat dieper in op die rij.
Waar breken supportgesprekken met meerdere agents?
Supportgesprekken met meerdere agents breken op de naden tussen agents, niet in de agents zelf. De vier fouten die het zwaarst wegen, zijn verloren context bij een overdracht, lussen tussen agents, de verkeerde agent die op een vraag handelt, en een gesprek dat wordt gesloten voordat het probleem is opgelost. Elk daarvan kan gebeuren terwijl elke afzonderlijke agent er correct uitziet.
Verloren context. Overdrachten geven minder door dan de meeste teams aannemen. In de handoff-orkestratie van Microsoft Agent Framework worden berichten van gebruiker en agent tussen agents gesynchroniseerd, maar content die met tools te maken heeft, wordt niet doorgegeven. De volgende agent ziet wat er gezegd is, niet noodzakelijk wat de vorige agent opzocht of deed. Als de facturatieagent de bestelling die de orderagent ophaalde niet kan zien, vraagt hij het de klant opnieuw, of werkt hij vanuit een aanname.
Lussen. Twee agents kunnen een vraag heen en weer spelen, of één agent kan dezelfde stap herhalen. De architectuurgids van Microsoft noemt “infinite handoff loops” (eindeloze overdrachtslussen) als valkuil van het handoffpatroon en raadt limieten op het aantal iteraties aan. In de autonome modus laat het handoffframework elke agent standaard tot 50 beurten draaien voordat er input van de gebruiker nodig is, veel meer dan een klant ooit verdraagt.
De verkeerde agent die handelt. Een verkeerd gerouteerde vraag komt bij een agent die met grote stelligheid antwoordt buiten zijn domein. Het antwoord klinkt vloeiend, dus niemand merkt het tenzij iemand het toetst aan het juiste beleid.
Te vroeg gesloten. Agents kunnen stoppen voordat het werk klaar is, of helemaal niet weten wanneer ze klaar zijn.
Onderzoek bevestigt dit. Een paper uit 2025, Why Do Multi-Agent LLM Systems Fail? (in het Engels), annoteerde 1.642 uitvoeringstraces uit zeven frameworks en vond 14 faalwijzen. Herhaling van stappen kwam voor in 15,7% van de traces, het niet herkennen dat de taak klaar was in 12,4% en verlies van context in 2,8%. De auteurs vonden ook dat geslaagde runs niet foutloos zijn. De traces kwamen uit programmeer-, wiskunde- en algemene taken, niet uit de klantenservice, dus zie de percentages als waarschuwing, niet als benchmark. De les is wel overdraagbaar: een uitkomst “opgelost” kan fouten onderweg verbergen, zoals ons artikel over stille fouten van AI-agents laat zien.
Wat moet je monitoren in een georkestreerde supportorganisatie?
Monitor de klantreis, niet alleen elke agent. Scores per agent tonen of de facturatieagent facturatievragen goed beantwoordt, niet dat klanten langs drie agents stuiterden voordat ze bij hem uitkwamen. Volg in plaats daarvan een klein aantal signalen over de klantreis: overdrachten, lussen, herhaalde klantgegevens, juistheid van de eerste route, escalaties met context, en het verschil tussen oplossing op agentniveau en op klantreisniveau.
De startregels hieronder zijn van ons, geen standaard uit de sector: meet vier weken je eigen baseline en stel dan bij.
| Signaal | Hoe je het meet | Startregel |
|---|---|---|
| Overdrachten per gesprek | Tel de wissels van agent in het gesprekslog | Beoordeel elk gesprek met meer dan 3 overdrachten |
| Herhaalde agent (lus) | Dezelfde agent komt twee keer voor in één gesprek, met een andere agent ertussen | Beoordeel ze allemaal; elke stijgende trend is een routeringsfout |
| Percentage herhaalde vragen | De klant geeft dezelfde identificatie (ordernummer, e-mail) twee keer | Onderzoek bij meer dan 5% van de gesprekken met meerdere agents |
| Juistheid van de eerste route | Aandeel eerste routes dat een beoordelaar als juist markeert | Onderzoek de router bij minder dan 90% |
| Escalatie met context | Aandeel overdrachten naar mensen waarbij de medewerker niets opnieuw hoefde te vragen | Mik op 95% of meer |
| Oplossingskloof | Percentage “opgelost” per agent min het percentage juist opgeloste klantreizen | Een kloof van meer dan 5 punten betekent dat fouten zich tussen agents verstoppen |
| Limiet voor beurten of iteraties bereikt | Gesprekken die eindigden omdat een limiet werd bereikt | Beoordeel ze allemaal; dit zijn vastgelopen lussen |
De richtlijnen van Microsoft maken hetzelfde punt vanuit de engineeringkant: instrumenteer alle acties en overdrachten van agents, en gebruik scoringsrubrics of evaluatie met een model als judge in plaats van tests op exacte overeenkomst, omdat de output van agents varieert. Voor dashboards en alerts, zie onze gids over AI-agent monitoring.
Hoe doe je kwaliteitscontrole op een klantreis die langs meerdere agents en mensen loopt?
Om kwaliteitscontrole te doen op een klantreis met meerdere agents, maak je het volledige gesprek de eenheid van beoordeling. Voeg elk segment van agent en mens samen tot één record, scoor elk segment tegen zijn eigen taak, scoor de naden met criteria voor de klantreis en wijs elke fout toe aan het segment dat hem veroorzaakte. Los dat deel daarna op en scoor opnieuw.
Stap 1: voeg de klantreis samen. Eén gespreks-ID volgt de klant langs elke agent en elke mens. Loggen je agents op verschillende plekken, dan is de eerste QA-taak het volledige transcript, met de naam van de agent bij elke beurt, in de helpdesk of in één beoordelingswachtrij te krijgen.
Stap 2: scoor elk segment tegen zijn taak. Juistheid van facturatie voor de facturatieagent, routering voor de triageagent, oplossing voor de medewerker. Een gedeelde kern van criteria houdt segmenten van mensen en AI vergelijkbaar; onze gids over één scorecard voor medewerkers en AI-agents laat zien hoe je die bouwt.
Stap 3: voeg criteria voor de klantreis toe. Dit zijn de vragen die geen enkel segment alleen kan beantwoorden:
- Was de eerste route juist?
- Moest de klant gegevens herhalen?
- Kwam een agent twee keer voor, of liep het gesprek in een lus?
- Gaf elke overdracht de data mee die de volgende agent nodig had?
- Als een mens het overnam, gebeurde de escalatie dan op de juiste trigger, met een bruikbare samenvatting?
- Was het echte probleem van de klant aan het eind opgelost, ongeacht wie het oploste?
Stap 4: wijs de fout toe. Elke mislukte klantreis krijgt één segment als grondoorzaak: de router, een specialist, het overdrachtsmechanisme of de medewerker. Zonder toewijzing is een mislukte klantreis ieders probleem en niemands oplossing.
Stap 5: los op en scoor opnieuw. Stuur de bevinding naar de eigenaar van dat deel (prompt, routeringsregel, kennisartikel, escalatietrigger) en scoor daarna hetzelfde type klantreis opnieuw om te bevestigen dat de oplossing standhoudt. Test wijzigingen voordat ze live gaan; zie onze gids over AI-agents testen.
Een uitgewerkt voorbeeld (illustratie, cijfers verzonnen om de rekensom te tonen)
Een supportteam handelt 40.000 gesprekken per maand af met een triageagent, drie specialistische agents en een menselijk team:
- 26.000 gesprekken (65%) gaan van triage naar één specialist en eindigen daar.
- 10.000 (25%) gaan langs twee of meer AI-agents.
- 4.000 (10%) eindigen bij een mens.
De dashboards per agent zien er gezond uit: elke specialist slaagt voor meer dan 90% van zijn eigen criteria. Dan scoort de QA-lead een willekeurige steekproef van 200 klantreizen met meerdere agents op de criteria voor de klantreis hierboven. 34 mislukken (17%): 14 klanten moesten hun ordernummer herhalen, 9 gesprekken liepen terug naar triage, 6 werden beantwoord door de verkeerde specialist, en 5 werden gesloten voordat de terugbetaling was bevestigd.
Opgeschaald is 17% van 10.000 ongeveer 1.700 mislukte klantreizen per maand. Als klantreizen met één agent in 5% van de gevallen mislukken, zijn dat 1.300 fouten op 26.000. Het kwart van de gesprekken dat langs meerdere agents loopt, levert meer fouten op dan de twee derde die dat niet doet.
De steekproef toont ook de grenzen van steekproeven. Met 200 gesprekken en een foutpercentage van 17% is de foutmarge bij 95% betrouwbaarheid ongeveer plus of min 5,2 punten (1,96 × √(0,17 × 0,83 / 200)). Het bereik bij 95% loopt van ongeveer 1.200 tot 2.200 mislukte klantreizen. En de 14 herhaalde vragen wijzen naar één oplossing: het opzoekresultaat van de orderagent komt bij de overdracht niet aan bij de facturatieagent.
Zie het op je eigen gesprekken. Kaizo scoort 100% van je supportgesprekken, van medewerkers en AI-agents, tegen je eigen scorecard, en koppelt elke score aan het bewijs in het gesprek. Demo boeken.
Welk framework of platform voor AI-agent orkestratie kies je?
Het beste framework voor AI-agent orkestratie is het framework dat je agentleverancier of engineeringteam al goed ondersteunt; supportmanagers kiezen het zelden alleen. Wat jij moet vastleggen, zijn de eisen: zichtbare routering per gesprek, context die bij een overdracht wordt doorgegeven, limieten op het aantal beurten, escalatie naar een mens met een samenvatting, en transcripten die terechtkomen waar je QA-team werkt.
De opties vallen in drie groepen uiteen:
- Ingebouwd in je platform voor AI-agents. Platformen voor klantenserviceagents routeren tussen hun eigen agents en naar je menselijke team. Het minste werk, de minste controle.
- Frameworks voor ontwikkelaars. Microsoft Agent Framework, de OpenAI Agents SDK, LangChain en CrewAI, onder andere. Volledige controle, en je engineers zijn eigenaar van elke regel.
- Orkestratielagen voor enterprises. Producten zoals IBM watsonx Orchestrate coördineren agents, tools en workflows vanuit één centrale laag in het hele bedrijf.
In welke groep je ook zit, stel vóór de livegang vijf vragen:
- Kunnen we per gesprek zien welke agent bij elke beurt handelde en waarom hij overdroeg?
- Wat wordt er precies doorgegeven bij een overdracht: het transcript, een samenvatting, toolresultaten, klantgegevens?
- Wat zijn de limieten voor beurten en iteraties, en wat gebeurt er als er één wordt bereikt?
- Hoe neemt een mens het over, en wat ziet die mens als eerste?
- Waar komt het volledige transcript terecht, en kan ons QA-team het daar scoren?
Is het antwoord “dat kunnen we je niet laten zien”, dan kun je ook geen kwaliteitscontrole op de klantreis doen.
Wanneer is orkestratie met meerdere agents niet voor jou?
Orkestratie met meerdere agents is niet voor jou als één goed afgebakende AI-agent met de juiste tools en een duidelijk escalatiepad je volume aankan. De richtlijnen van Microsoft zeggen dat je het laagste niveau van complexiteit moet gebruiken dat betrouwbaar aan je eisen voldoet, en noemen één agent met tools vaak de juiste standaard voor enterprisetoepassingen. Elke extra agent voegt overdrachten, vertraging, kosten en faalwijzen toe.
Praktijkmensen op fora over customer success maken een vergelijkbaar punt: de winst komt meestal van een AI-agent die een smalle set vragen goed afhandelt, niet van een agent die alles probeert te dekken. Handelt je AI-agent een paar honderd gesprekken per maand af in één domein, sla orkestratie dan over, lees de transcripten wekelijks en steek de moeite in de kennisbank en de escalatietrigger.
De routering zelf komt van je agentplatform of een van de frameworks hierboven. De rol van Kaizo begint na het gesprek: het scoort afgehandelde gesprekken uit Zendesk of Salesforce tegen je scorecard.
Hoe je deze week begint
Je kunt deze week beginnen met het beoordelen van georkestreerde klantreizen zonder nieuwe tools: teken hoe je agents zijn opgezet en scoor daarna een kleine set klantreizen met meerdere agents op de criteria voor de klantreis. Het doel van week één is geen dashboard; het is de naad vinden die het vaakst faalt.
- Teken je opzet. Zet elke AI-agent op een rij, wie aan wie kan overdragen en waar mensen instappen, met het patroon uit de tabel hierboven.
- Haal 30 klantreizen met meerdere agents op, plus 10 die bij een mens eindigden.
- Scoor ze op de zes criteria voor de klantreis, en noteer bij elke fout het segment dat de grondoorzaak is.
- Kies de slechtste naad. Meestal één overdracht die context laat vallen of één routeringsregel die misgaat.
- Benoem een eigenaar voor elke agent en elke overdrachtsregel.
Als de handmatige beoordeling het patroon bevestigt, automatiseer het dan. Kwaliteitscontrole van AI-agents met Kaizo scoort gesprekken van AI-agents op dezelfde scorecard als die van je team, inclusief criteria voor overdrachten, zoals of de agent op de juiste trigger escaleerde en de context doorgaf, en AutoPilot scoort elk gesprek op het moment dat het is afgehandeld. Voor het bredere beeld begin je met onze gids over agentische klantenservice; voor de regels die die agents volgen, zie AI-agent governance.
Veelgestelde vragen
Is ChatGPT een agent of een LLM?
ChatGPT is een product gebouwd op grote taalmodellen (LLM’s). Bij het beantwoorden van één vraag gedraagt het zich als een chatinterface voor een LLM. Gebruikt het tools, surft het op het web of werkt het zelfstandig een taak met meerdere stappen af, dan gedraagt het zich als een agent. Het verschil zit in wat het systeem mag doen, niet in het model.
Wat is het verschil tussen een multi-agentsysteem en agentische AI?
Agentische AI beschrijft AI die met enige autonomie naar een doel toe handelt. Een multi-agentsysteem is één manier om dat te bouwen: meerdere gespecialiseerde agents, gecoördineerd door orkestratie, in plaats van één agent die alles doet. Eén agent kan agentisch zijn; een multi-agentsysteem voegt de overdrachten toe, en daarmee de naden die je moet controleren.
Is Kubernetes een orkestratietool?
Ja, maar voor containers, niet voor AI-agents. Kubernetes plant en schaalt de software waarop je services draaien. AI-agent orkestratie bepaalt welke agent welk deel van een gesprek afhandelt en welke context hij krijgt. Een agentsysteem kan op Kubernetes draaien, maar Kubernetes routeert geen vragen tussen agents.
Wat is een orkestratielaag voor AI-agents?
De orkestratielaag zit boven de afzonderlijke agents en bepaalt routering, het doorgeven van context, rechten en stopregels. Het kan een leidende agent zijn, een framework in je eigen code of een centraal product. Voor QA moet die laag ook het verslag leveren van wie handelde en waarom.
Hoe evalueer je een klantenservicesysteem met meerdere agents?
Evalueer het op twee niveaus: elke agent tegen zijn eigen taak, en de volledige klantreis tegen criteria zoals een juiste eerste route, geen herhaalde gegevens, geen lussen en een juiste eindsituatie. Onze gids over AI-agents evalueren behandelt de methoden, van testsets tot het scoren van live gesprekken.
