# Multi-agent en handoff: taken verdelen over agents

[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/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fmulti-agent-en-handoff-patronen&text=Multi-agent%20en%20handoff%3A%20taken%20verdelen%20over%20agents)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fmulti-agent-en-handoff-patronen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fmulti-agent-en-handoff-patronen&title=Multi-agent%20en%20handoff%3A%20taken%20verdelen%20over%20agents)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fmulti-agent-en-handoff-patronen&text=Multi-agent%20en%20handoff%3A%20taken%20verdelen%20over%20agents)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fmulti-agent-en-handoff-patronen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fmulti-agent-en-handoff-patronen&title=Multi-agent%20en%20handoff%3A%20taken%20verdelen%20over%20agents)[](#)

 
# Multi-agent en handoff: taken verdelen over agents

 Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · 15 augustus 2026

 Wanneer een enkele AI-agent verantwoordelijk wordt gemaakt voor een complex bedrijfsproces, ontstaan er al snel structurele knelpunten in productie. Een prompt die twintig verschillende tools, dertig uitzonderingsregels en vijf uiteenlopende vakdomeinen moet verenigen, verliest betrouwbaarheid door instructieverwatering. Het model raakt overbelast met overtollige context, kiest verkeerde functies of negeert subtiele randvoorwaarden. De oplossing voor dit schaalprobleem ligt in specialisatie: het opknippen van een omvangrijke taak over autonome, gefocuste agents die via gestructureerde handoffs werk, status en context aan elkaar overdragen.

 In dit artikel analyseren we hoe handoff-mechanismen werken, welke architectuurpatronen beschikbaar zijn, hoe context en status veilig tussen agents migreren, en welke specifieke risico's optreden bij gedistribueerde agentsystemen. Voor een fundamenteel overzicht van hoe individuele agents redeneren en functies aanroepen, biedt de handleiding over [promptpatronen voor agents](https://community.llmnet.nl/prompt-patronen-voor-agents) essentiële achtergrondkennis over tool orchestration en loop-structuren.

 
## De limieten van de monolithische agent

 Een enkele monolithische agent lijkt bij de start van een project aantrekkelijk vanwege de minimale orchestratie-overhead. Er is slechts één systeemprompt nodig, alle beschikbare tool-definities worden aan één API-aanroep meegegeven, en het taalmodel beslist zelfstandig over de te nemen stappen. In productieomgevingen loopt deze opzet echter tegen harde operationele en cognitieve grenzen aan.

 Ten eerste neemt de foutkans bij functiekeuze exponentieel toe naarmate de functiecatalogus groeit. Wanneer een model moet kiezen uit tientallen JSON-schema's met overlappende parameterstructuren, ontstaan semantische verwarringen en foutieve argumenten. Ten tweede verbruikt een monolithische opzet disproportioneel veel tokens. Bij iedere iteratieve stap in een redeneerloop moet de volledige functielijst en systeemprompt opnieuw door het contextvenster worden verwerkt. Dit verhoogt niet alleen de kosten per interactie, maar vertraagt ook de responstijd (Time To First Token) aanzienlijk.

 Ten derde introduceert een monolithische agent substantiële beveiligingsrisico's. Gereedschappen met verstrekkende bevoegdheden, zoals het wijzigen van een database of het uitvoeren van een betaling, bevinden zich in dezelfde uitvoeringsruimte als gereedschappen die onbetrouwbare gebruikersinvoer parseren. Door het systeem modulair op te splitsen in domeinspecifieke componenten — zoals een triage-agent, een verificatie-agent en een mutatie-agent — blijft de toegekende macht per stap strikt ingekaderd.

 
## Wat is een handoff precies?

 Een handoff (taakoverdracht) is het gecontroleerde mechanisme waarbij de actieve uitvoeringscontrole, conversatiegeschiedenis en applicatiestatus van de ene agent naar de andere worden overgedragen. Waar een standaard functie-aanroep (tool call) slechts data ophaalt en de controle direct teruggeeft aan dezelfde agent, beëindigt een handoff de actieve cyclus van de zendende agent en wijst hij een nieuwe agent aan als primaire uitvoerder.

 Technisch gezien wordt een handoff gemodelleerd als een gespecialiseerde tool call of een expliciet routeringssignaal. Een triage-agent beschikt bijvoorbeeld over een functie zoals transfer_to_billing(reason, customer_id, context_summary). Zodra het taalmodel deze functie selecteert, onderschept de applicatieruntime dit signaal. De runtime sluit de huidige uitvoeringscontext af, laadt de systeemprompt en tool-definities van de doelagent, transformeert de status, en start de redeneerloop van de nieuwe specialist.

 Het cruciale verschil met een statische pipeline of een klassieke functie-aanroep zit in de autonomie: de ontvangende agent krijgt de vrijheid om binnen zijn eigen domein een eigen redeneerlus te doorlopen, eigen tools aan te roepen, en eventueel op zijn beurt weer een handoff te initiëren naar een volgende specialist of terug naar de triage-laag.

 
## Architectuurpatronen voor multi-agent samenwerking

 De topologie van de onderlinge communicatie bepaalt hoe robuust en beheersbaar het agentsysteem functioneert. In moderne architecturen onderscheiden we drie dominante patronen, elk met eigen sterktes en operationele uitdagingen:

 
 
 
 
 Patroon | 
 Topologie | 
 Voordelen | 
 Nadelen & Risico's | 
 

 
 
 
 Supervisor / Router | 
 Centrale orchestrator stuurt gespecialiseerde sub-agents aan | 
 Strakke controle, eenvoudige auditability, geen directe koppeling tussen werkers | 
 Enkel storingspunt (SPOF) bij de router; extra latency door centrale triage | 
 

 
 Gedecentraliseerde Handoff (Swarm) | 
 Peer-to-peer overdracht tussen agents zonder centrale baas | 
 Flexibel, lage overhead, natuurlijke gespreksvoering bij complexe trajecten | 
 Risico op oneindige ping-pong lussen; lastiger te traceren en te debuggen | 
 

 
 Hiërarchische Graph | 
 Gelaagde structuur met expliciete statusovergangen en beslisbomen | 
 Deterministische routering, formele statusgaranties, robuuste foutafhandeling | 
 Vereist formele graafdefinitie en strikt statusbeheer vooraf | 
 

 
 
 

 Bij het ontwerpen van complexe systemen met formele statusovergangen is het cruciaal om te begrijpen hoe overgangen tussen toestanden worden vastgelegd; lees de gids over [de overgang van prompt- naar graph-engineering](https://community.llmnet.nl/van-prompt-naar-graph-engineering) om te zien hoe deterministische grafen het gedrag van agents reguleren.

 
### 1. Het supervisor-patroon

 In het supervisor-model fungeert één centrale LLM-agent als verkeersleider. De supervisor analyseert het inkomende verzoek, bepaalt welke specialist de taak moet uitvoeren, delegeert het werk en ontvangt het eindresultaat. De sub-agents communiceren nooit rechtstreeks met elkaar; alle data stroomt via de centrale orchestrator. Dit maakt logging en compliance eenvoudig, maar creëert een bottleneck wanneer de supervisor subtiele nuances uit het gebruikersgesprek verkeerd interpreteert.

 
### 2. Het peer-to-peer handoff-patroon (Swarm)

 In een peer-to-peer model (vaak aangeduid als een swarm-architectuur) kunnen agents de controle direct aan elkaar overdragen zonder tussenkomst van een centrale manager. Agent A stelt vast dat een vraag buiten zijn domein valt en draagt de sessie direct over aan Agent B. Dit verlaagt de latency en voorkomt dat een centrale supervisor bij elke stap geraadpleegd moet worden. De uitdaging ligt hier in governance: zonder centrale controle moeten overdrachten strikt begrensd worden om circulaire delegatielussen te voorkomen.

 
### 3. Het hiërarchische netwerk

 Voor enterprise-workflows worden supervisors en peer-to-peer transfers gecombineerd in een hiërarchische structuur. Een hoofdtriage delegeert aan een domein-cluster (bijvoorbeeld 'Klantenservice'), waarbinnen gespecialiseerde agents (zoals 'Facturatie', 'Retouren' en 'Accountbeheer') peer-to-peer handoffs uitvoeren. Pas wanneer het volledige domeinprobleem is opgelost, keert de controle terug naar het bovenliggende orchestratieniveau.

 
## Context- en statusbeheer tijdens de overdracht

 Het succes van een handoff staat of valt met de manier waarop data tussen agents migreert. Wanneer een gebruiker al vijf minuten bezig is met het verstrekken van ordernummers en foutmeldingen aan een intake-agent, mag de ontvangende specialist die informatie onder geen beding opnieuw uitvragen. Tegelijkertijd willen we voorkomen dat het contextvenster van de specialist vervuild raakt met irrelevante tussenstappen van de intake.

 Er bestaan twee primaire strategieën voor statusoverdracht:

 
### Strategie A: Volledige chathistorie dupliceren

 Bij deze aanpak wordt de complete lijst met eerdere gebruikers- en assistentberichten gekopieerd naar het contextvenster van de nieuwe agent. De nieuwe agent krijgt simpelweg een eigen systeemprompt en de bestaande berichtenreeks.

 Voordeel: Geen informatieverlies; alle context blijft letterlijk behouden.
 Nadeel: Snelle toename van tokenverbruik, hogere latentie, en kans op hallucinaties doordat de nieuwe agent eerdere tool calls ziet die niet tot zijn eigen gereedschapsset behoren.

 
### Strategie B: Gestructureerde state payload (Context Slicing)

 In dit patroon extraheert de zendende agent de relevante gegevens en verpakt deze in een gevalideerd JSON-object. De nieuwe agent start met een schone lei: een specifieke systeemprompt, de compacte status-payload, en uitsluitend de meest recente interacties.

 Voordeel: Minimaal tokenverbruik, scherpe focus van het model, en strikte scheiding van verantwoordelijkheden.
 Nadeel: Risico op dataverlies als de zendende agent een essentieel detail niet opneemt in de payload.

 
## Voorbeeld: Implementatie van een handoff-mechanisme in Python

 Hieronder volgt een concrete en robuuste implementatie van een peer-to-peer handoff-architectuur in Python. We gebruiken een aangepaste exceptie-klasse om de controleflow vanuit tool-aanroepen te onderbreken en over te dragen aan de runtime:

import json
from typing import Dict, Any, List, Optional

class HandoffException(Exception):
 """Signaal om de huidige agentloop te onderbreken en over te dragen."""
 def __init__(self, target_agent: str, payload: Dict[str, Any]):
 self.target_agent = target_agent
 self.payload = payload

# Tool definitie voor de triage agent
def transfer_to_technical_support(issue_type: str, severity: str, context_notes: str):
 """Draag het gesprek over aan de tweedelijns technische ondersteuning."""
 raise HandoffException(
 target_agent="tech_support",
 payload={
 "issue_type": issue_type,
 "severity": severity,
 "context_notes": context_notes
 }
 )

# Definities van beschikbare agents
AGENT_REGISTRY = {
 "triage": {
 "system_prompt": "Je bent de triage-assistent. Analyseer het probleem en draag over.",
 "tools": [transfer_to_technical_support]
 },
 "tech_support": {
 "system_prompt": "Je bent de technische specialist. Los bugs en serverproblemen op.",
 "tools": []
 }
}

class AgentOrchestrator:
 def __init__(self, max_handoffs: int = 3):
 self.max_handoffs = max_handoffs
 self.global_state: Dict[str, Any] = {}

 def execute_session(self, initial_agent: str, user_input: str) -> str:
 current_agent_name = initial_agent
 handoff_count = 0
 messages: List[Dict[str, str]] = [{"role": "user", "content": user_input}]

 while handoff_count <= self.max_handoffs:
 agent_config = AGENT_REGISTRY[current_agent_name]
 
 try:
 # Simuleer de LLM-stap en eventuele tool-executie
 # In productie roept de runtime hier de provider API aan
 if current_agent_name == "triage" and "server down" in user_input.lower():
 # De triage agent besluit de handoff tool aan te roepen
 transfer_to_technical_support(
 issue_type="infrastructure_outage",
 severity="critical",
 context_notes="Klant meldt complete downtime van productieserver."
 )
 
 # Als er geen handoff plaatsvindt, retourneert de agent het antwoord
 return f"[{current_agent_name}] Probleem succesvol verwerkt."

 except HandoffException as handoff:
 handoff_count += 1
 current_agent_name = handoff.target_agent
 
 # Werk de globale applicatiestatus bij met de payload
 self.global_state.update(handoff.payload)
 
 # Context Slicing: reset berichten met een compacte statusinjectie
 messages = [
 {
 "role": "system",
 "content": f"{agent_config['system_prompt']}\nContext: {json.dumps(self.global_state)}"
 },
 {
 "role": "user",
 "content": f"Vervolg actie vereist voor issue: {self.global_state.get('issue_type')}"
 }
 ]
 continue

 raise RuntimeError("Maximale handoff-drempel overschreden: mogelijke oneindige lus.")

 
## Veelvoorkomende faalmodi en randgevallen

 Bij het overstappen van één agent naar meerdere samenwerkende agents verschuiven de problemen van prompt-formulering naar netwerk- en applicatiedynamiek. Er zijn vier specifieke faalmodi die structureel optreden:

 
### 1. De oneindige ping-pong cyclus

 Wanneer twee agents elkaars domeingrenzen overlappen, kan er een situatie ontstaan waarin Agent A de taak overdraagt aan Agent B, waarna Agent B besluit dat een subtak alsnog door Agent A moet worden afgehandeld. Zonder actieve detectie leidt dit tot tientallen API-aanroepen binnen enkele seconden. Een robuuste orchestrator houdt een gerichte graaf (DAG) van handoffs bij binnen de sessie en breekt de cyclus af zodra een herhaalde transitie optreedt.

 
### 2. Context-erosie (Het fluisterspel-effect)

 Wanneer een keten bestaat uit drie of meer opeenvolgende handoffs waarbij telkens een samenvatting wordt doorgegeven, treedt context-erosie op. Net als bij het bekende fluisterspel verliest elke abstractielaag specifieke details, zoals serienummers, exacte foutmeldingen of tijdstippen. De mitigatie hiervoor is het scheiden van vluchtige dialoogcontext en een onveranderlijke globale databuffer (immutable session state) die direct door de host-applicatie wordt beheerd.

 
### 3. Zwevende asynchrone taken (Zombie executions)

 Als een agent een langdurige tool-aanroep start (zoals het genereren van een financieel rapport) en direct daarna een handoff initieert, kan de tool-output arriveren wanneer de nieuwe agent al actief is. Als de nieuwe agent het binnenkomende callback-formaat niet herkent, crasht de sessie. Handoffs moeten daarom atomair zijn: een overdracht mag pas worden geformaliseerd wanneer alle actieve IO-processen van de huidige agent zijn afgerond.

 
### 4. Ambigue intenties bij multi-domein vragen

 Wanneer een gebruiker twee vragen in één bericht stelt ("Waar blijft mijn bestelling en hoe wijzig ik mijn IBAN?"), faalt een eenvoudige router vaak door slechts één van beide vragen te selecteren. Een geavanceerd handoff-patroon vereist in dat geval een splitsingsmechanisme (Fork-Join) waarbij twee gespecialiseerde agents parallel worden geactiveerd, waarna een aggregator de antwoorden samenvoegt.

 Wanneer agentlussen vastlopen of onverwacht gedrag vertonen, helpt het stappenplan voor [het debuggen van agentic loops](https://community.llmnet.nl/agentic-loops-debuggen) om recursieve aanroepen, ontbrekende breekvoorwaarden en foutieve tool-responses systematisch te isoleren.

 
## Token-economie en latency: de verborgen kosten

 Hoewel multi-agent architecturen de precisie verhogen, introduceren ze specifieke kostenoverwegingen die per architectuurtype verschillen. Het is een misvatting dat multi-agent systemen per definitie duurder zijn dan monolithische agents; de werkelijke kosten hangen af van de gekozen contextstrategie.

 
 
 
 
 Architectuur | 
 Prompt Tokens per Stap | 
 Aantal Model Calls | 
 Gemiddelde Latency | 
 Kostenprofiel | 
 

 
 
 
 Monoliet (Groot Contextvenster) | 
 Hoog (alle tools & regels bij elke stap) | 
 Laag tot gemiddeld | 
 Gemiddeld per stap | 
 Hoog bij lange sessies door cumulatieve input-tokens | 
 

 
 Supervisor / Router | 
 Laag bij specialisten, gemiddeld bij router | 
 Hoog (router call + specialist call) | 
 Hoog (sequentieel wachten op routering) | 
 Voorspelbaar; bespaart op specialist-aanroepen | 
 

 
 Peer Handoff met Context Slicing | 
 Zeer laag (compacte payload per agent) | 
 Minimaal (geen tussenliggende supervisor) | 
 Laag (directe overgang) | 
 Meest kostenefficiënt bij complexe, lange workflows | 
 

 
 
 

 Bij het berekenen van de totale operationele kosten moet rekening worden gehouden met de handoff-overhead: elke overdracht vereist minimaal één generatiestap voor de payload en één initiële promptverwerking voor de ontvangende agent. Wanneer een taak echter meer dan vijf iteratieve tool-stappen omvat, compenseert de besparing van een compact contextvenster deze initiële overhead ruimschoots.

 
## Meetmethoden en observability voor handoff-systemen

 Het evalueren van een gedistribueerd agentsysteem vereist specifieke metrieken die verder gaan dan traditionele responstijden en token-tellers. Om de gezondheid van de architectuur te bewaken, worden vier kerndialoog-statistieken gehanteerd:

 1. First-Pass Routing Accuracy: Het percentage initiële handoffs waarbij de ontvangende agent de taak succesvol kan afronden zonder dat er een correctieve overdracht naar een derde agent nodig is. Een score onder de 85% wijst meestal op onduidelijke tool-beschrijvingen in de router.

 2. Handoff Depth & Churn Rate: Het gemiddelde aantal overdrachten per gebruikerssessie. Een plotselinge stijging in de handoff-diepte duidt vaak op onduidelijke domeinafbakening tussen agents, waardoor taken heen en weer worden geschoven.

 3. Payload Completeness Ratio: De mate waarin de ontvangende agent direct kan handelen zonder ontbrekende entiteiten opnieuw aan de gebruiker te moeten vragen. Dit kan geautomatiseerd gemeten worden met een LLM-as-a-judge evaluatietest.

 4. Transitie-latentie: De pure verwerkingstijd tussen het moment dat Agent A de handoff initieert en Agent B zijn eerste token genereert. Deze metriek legt bottlenecks in database-I/O of status-serialisatie bloot.

 Om te valideren of een samengestelde agentketen daadwerkelijk beter presteert dan een enkele prompt, biedt het overzicht over [het evalueren van AI-agents](https://benchmark.llmnet.nl/agent-evaluatie) gedetailleerde benchmarks voor trajectanalyse en succespercentages.

 
## Praktijkvoorbeeld: Een e-commerce retour- en fraudeflow

 Laten we een realistische productieomgeving bekijken: een e-commerce platform dat retouraanvragen verwerkt. Dit proces omvat drie gespecialiseerde agents:

 Triage Agent: Verwelkomt de klant, identificeert het ordernummer en stelt de intentie vast (retour, defect product of klacht). Beschikt uitsluitend over lees-tools om orders op te zoeken.

 Fraud & Policy Agent: Evalueert of de retour binnen de 30-dagen termijn valt en controleert het risicoprofiel van het account. Heeft toegang tot interne betaalgeschiedenis en frauderegisters.

 Fulfillment Agent: Genereert het retourlabel, boekt het tijdslot bij de pakketdienst en werkt de voorraadstatus bij. Beschikt over schrijfrechten in het ERP-systeem.

 Wanneer een klant meldt dat een apparaat defect is gearriveerd, ziet het handoff-traject er als volgt uit:

 1. De Triage Agent extraheert het ordernummer en roept transfer_to_policy(order_id="ORD-9812", reason="damaged_on_arrival") aan.
 2. De Policy Agent valideert de aankoopdatum en concludeert dat direct omruilen is toegestaan. Deze agent roept vervolgens transfer_to_fulfillment(action="instant_replacement", return_type="prepaid_label") aan.
 3. De Fulfillment Agent genereert het label en stuurt de bevestiging naar de klant.

 Elke agent opereert binnen zijn eigen strikte veiligheidskaders. De Triage Agent kan onmogelijk per ongeluk een retourlabel genereren of frauderegisters inzien, simpelweg omdat die functionaliteit ontbreekt in diens context en toolschema.

 
## Conclusie en richtlijnen voor implementatie

 Multi-agent systemen en handoff-patronen transformeren monolithische, kwetsbare prompts in modulaire, testbare softwarecomponenten. Door agents te laten excelleren in één specifiek domein en hun onderlinge communicatie te reguleren via gevalideerde payloads en harde transitielimieten, ontstaat een robuuste architectuur die bestand is tegen complexe productie-eisen.

 Begin bij het bouwen van een nieuw systeem altijd zo eenvoudig mogelijk: start met een enkele agent met een beperkte toolset. Pas wanneer instructieverwatering optreedt, de tokenkosten per stap onhoudbaar worden, of strikte beveiligingsgrenzen tussen tools vereist zijn, is de overstap naar een multi-agent structuur met expliciete handoffs gerechtvaardigd.