AI-agent-workflowpatronen: 7 patronen en wanneer ze echt winnen (2026)

AI-agent-workflowpatronen: 7 patronen en wanneer ze echt winnen (2026)

AI-agent-workflowpatronen hebben eindelijk cijfers: in januari 2026 evalueerde Google Research 180 agentconfiguraties en vond dat dezelfde coördinatiewijziging paralleliseerbare financiële redeneertaken met 80,9% verhief, terwijl hij sequentiële planning op PlanCraft met tot 70% verpletterde. Zelfde hendel, tegengestelde uitkomsten. De variabele die beslist is de decomposeerbaarheid van de taak, niet het aantal agenten, en de zeven patronen hieronder worden beoordeeld tegenover gepubliceerde data in plaats van vendor-diagrammen.

• Zeven patronen tellen: sequentieel, routing, parallelisering, orchestrator-workers, reflectie, ReAct en plan-and-execute.
• De decomposeerbaarheid van de taak beslist de winnaar. Paralleliseerbaar werk wint; sequentieel werk gaat achteruit.
• Begin met één agent. Voeg pas een tweede toe als één agent onder de ~85% nauwkeurigheid blijft hangen.

AI-agent-workflowpatronen in één overzicht: wat de data zegt

De zeven AI-agentpatronen zijn sequentieel (prompt chaining), routing (handoff), parallelisering (fan-out/fan-in), orchestrator-workers, reflectie (evaluator-optimizer), ReAct en plan-and-execute. Vijf vendor-docs benoemen ze anders, maar deze zeven vormen dekken elke indeling die Anthropic, OpenAI, Vercel, Microsoft en Google Cloud momenteel publiceren. Human-in-the-loop is niet één van de zeven: het is een controlelaag die elk van hen omhult.

Lees de meetkolom sceptisch. Drie rijen dragen echte cijfers; vier dragen 'geen openbare meting', wat in 2026 de eerlijke stand van het veld is. Vijf vendors publiceren vijf verschillende namen voor wat in werkelijkheid drie of vier onderliggende vormen zijn. De laatste kolom bestaat zodat je elk van die namen kunt terugkoppelen naar de onderliggende vorm; de rest van dit artikel pakt per beurt één familie uit.

Twee kolommen die niemand op de SERP bespreekt, zijn tokenkosten en latentiebudget. Sequentieel en routing verbruiken van beide het minst; orchestrator-workers van beide het meest; parallelisering ruilt tokenverbruik tegen doorlooptijd. Kies het patroon op de resource die jouw taak echt beperkt, niet op het diagram dat het indrukwekkendst oogt.

Wat zijn AI-agent-workflowpatronen (en wat zijn de 4 fasen van een AI-workflow)?

AI-agent-workflow-ontwerppatronen zijn herbruikbare vormen om LLM-aanroepen, toolgebruik en controlelogica tot een systeem te schikken. De zeven die terugkeren in elke vendorclassificatie zijn sequentieel, routing, parallelisering, orchestrator-workers, reflectie, ReAct en plan-and-execute. Elk van hen ruilt tokenkosten, latentie en nauwkeurigheid anders in, dus de juiste keuze hangt af van de structuur van de taak in plaats van het framework dat je toevallig gebruikt.

Een typische AI-agent-workflow doorloopt vier fasen, in een lus:

1. Plan: het model bepaalt wat de volgende stap is, gegeven het doel en de geschiedenis tot nu toe.
2. Act: het roept een tool aan, wat in 2026 meestal een MCP-server of een functie-aanroep betekent. Model Context Protocol (MCP) standaardiseert die tool-laag over modellen heen.
3. Observe: het toolresultaat gaat als nieuw bericht terug de context in.
4. Reflect / loop: het model beoordeelt of het resultaat goed genoeg is en loopt dan door of stopt.

Elk patroon in dit artikel is een andere manier om die vier fasen te bedraden. Sequentieel legt de volgorde vast in code. ReAct laat het model elke beurt de volgende fase kiezen. Orchestrator-workers verdeelt de lus over meerdere modellen.

Eén onderscheid is belangrijk vóór de catalogus. Een workflow is vooraf bepaalde codepaden; een agent geeft de controle aan het model. Anthropic trekt de grens zo in Building Effective Agents: "Workflows bieden voorspelbaarheid en consistentie voor goed gedefinieerde taken, terwijl agenten de betere optie zijn wanneer flexibiliteit en modelgestuurde besluitvorming op schaal nodig zijn."

Als je hier aankwam op zoek naar de klassieke typen agenten in AI (simple reflex, model-based, goal-based, learning): die indeling is ouder dan LLM's; de zeven patronen hierboven zijn degenen die bepalen of jouw build ook scheep gaat.

De deterministische patronen: sequentieel, routing en parallelisering

Drie patronen houden de controle in je code in plaats van in het model. Ze zijn het goedkoopst om te draaien en het makkelijkst om te debuggen, en het advies van het Claude-team van maart 2026 is onomwonden over waar te beginnen: "Begin met het eenvoudigste patroon dat je probleem oplost. Kies standaard voor sequentieel."

Sequentieel (prompt chaining)

Eén aanroep voedt de volgende. Je splitst een lastige taak in geordende stappen en elke stap krijgt de output van de vorige als input. De winst is leesbaarheid: je kunt elk tussenresultaat inspecteren en elke stap cachen. Vermijd het als de subtaken onafhankelijk zijn, want je betaalt dan latentie voor een volgorde die je niet nodig hebt. Als status tussen stappen of over sessies heen bewaard moet blijven, is dat een geheugenprobleem en geen kettingprobleem; zie onze gids over agentgeheugen voor de scheiding. Het enige gepubliceerde pleidooi ervoor is een standaardadvies: geen enkele studie meet winst van chaining zelf, omdat het de baseline is die elk ander patroon tegen extra kosten moet verslaan.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Routing (handoff)

Een goedkope classificator leest de invoer en stuurt die door naar een specialistprompt of -model. OpenAI omschrijft het in de Agents SDK-docs: "Een triage-agent stuurt het gesprek door naar een specialist, en die specialist wordt de actieve agent voor de rest van de beurt." Vermijd routing als de classificator onbetrouwbaarder is dan gewoon één algemeen pad draaien, want elke verkeerde route is een stilzwijgend fout antwoord. De benoemde faalmodus hier is contextverlies over de handoff: de specialist ziet alleen wat de router doorstuurt. De volledige trace meedragen is een context engineering-beslissing, en dat verkeerd aanpakken is waarom geroute systemen vergeetachtig aanvoelen. De tokenrekensom pleit toch voor routing: de classificator draait op een klein model (hierboven gpt-4o-mini), dus een router voegt een paar honderd goedkope tokens per verzoek toe in plaats van een tweede dure aanroep.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Parallelisering (fan-out/fan-in)

Onafhankelijke subtaken draaien tegelijk, waarna een samenvoegstap ze combineert. Anthropic splitst dit in sectioning (het werk verdelen) en voting (dezelfde taak meerdere keren draaien en vergelijken). Dit is de vorm die Google Research in januari 2026 mat op +80,9% ten opzichte van één agent op paralleliseerbare financiële redeneertaken, precies omdat de taak schoon decomposeerde. Vermijd het zodra stap n+1 afhangt van de output van stap n; een afhankelijkheidsketen paralleliseren herschikt de foute antwoorden alleen maar sneller. Latentie is de andere helft van de winst: onafhankelijke aanroepen lopen gelijktijdig, dus de doorlooptijd daalt ruwweg met het aantal workers terwijl het totale tokenverbruik gelijk blijft.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct vs plan-and-execute: welk redeneerpatroon gebruik je?

ReAct wisselt redeneren af met actie: het model denkt, roept een tool aan, observeert het resultaat en bepaalt pas dan de volgende stap. Plan-and-execute schrijft het volledige plan voordat er een tool draait en voert de stappen daarna op volgorde uit. ReAct past zich halverwege aan verrassingen aan; plan-and-execute betaalt vooraf voor één grote planningsaanroep en vertrouwt op de route.

ReAct bepaalt de volgende stap na elke observatie; plan-and-execute legt de hele route vast vóór de eerste tool-aanroep.

ReAct komt van Yao et al. (arXiv 2210.03629, v1 oktober 2022, v3 maart 2023), dat +34% absoluut succes op ALFWorld en +10% op WebShop rapporteerde ten opzichte van imitatie- en reinforcement-learning-baselines, met slechts één of twee in-context voorbeelden. Het is de standaardlus achter de meeste tool-gebruikende agenten, en het is een gat in het SERP-resultaat op plek 3: het 7.133 woorden tellende orchestration-document van Microsoft Learn laat ReAct volledig weg. Dat observeer-beslis-ritme is waarom ReAct open taken ("blijf browsen tot je X vindt") beter aankan dan welk vooraf gemaakt plan dan ook: het plan zou moeten raden wat de pagina's bevatten voordat het ze leest.

Plan-and-execute komt van Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), dat eerst een plan opstelt dat de taak in subtaken verdeelt en die vervolgens uitvoert. Het paper rapporteert een overwinning op zero-shot chain-of-thought op alle tien geëvalueerde datasets; we citeren geen afzonderlijk cijfer omdat de abstract van het paper er geen publiceert. Gebruik het als de route voorspelbaar is en herplannen na elke stap tokens zou verspillen. De keerzijde is broosheid: als stap drie faalt, heeft een plan-and-execute-lus een expliciete herplan-hook nodig, terwijl ReAct per constructie herplant.

De rij gemeten bewijs is de eerlijke tell. ReAct heeft een paper uit 2022 met cijfers op taakniveau; plan-and-execute heeft een tien-dataset-sweep en geen kopcijfer, wat één reden is waarom het vaker geciteerd wordt dan gebenchmarkt.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

Die iteratielimiet is niet optioneel. Een ReAct-lus zonder uitgang brandt tokens tot je budget op is; max_steps is de goedkoopste vangrail in dit hele artikel. Plan-and-execute heeft dezelfde vangrail een niveau hoger nodig: limiteer de herplanningen en niet alleen de stappen, anders regenereert een falend plan zichzelf oneindig.

De kwaliteitspatronen: reflectie, evaluator-optimizer en human-in-the-loop

Kwaliteitspatronen besteden extra tokens om de outputkwaliteit te verhogen, en ze renderen alleen wanneer kwaliteit meetbaar is. Reflectie (Anthropic noemt het evaluator-optimizer) draait een generator en een criticus in een lus: het ene model schrijft, het andere bekritiseert, de versie verbetert. Als je de output niet kunt scoren met een test, een rubric of een grader-model, is de criticus gewoon extra tokens die tegen zichzelf praten. Die scorer bouwen is het lastige deel; onze gids over AI-agents evalueren in productie behandelt wat een bruikbare scorefunctie vergt. Waar de voorwaarde geldt, is het patroon een goedkope verzekering: Anthropic beschrijft evaluator-optimizer als twee LLM-aanroepen in een lus, één die genereert en één die bekritiseert, wat een meetbare kwaliteitswinst koopt voor een paar seconden extra latentie.

De faalmodus die niemand tekent, is doorslaande reflectie: criticus en generator draaien eindeloos door, of erger, ze oscilleren. De fix is een harde iteratielimiet plus een geen-verbetering-break, geschreven in code in plaats van gevraagd in de prompt:

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Human-in-the-loop is een controlelaag en geen achtste patroon. Het omhult elk van de zeven: een mens keurt goed voordat een onomkeerbare stap draait. Slechts 2 van de 6 top-SERP-resultaten behandelen het überhaupt. Plaats de poort bij onomkeerbare acties, echte uitgaven en alles wat je systeem verlaat als externe communicatie. Al het andere moet onbeheerd draaien of niet draaien. De poort zelf moet domme code zijn en geen ander LLM: een goedkeuringswachtrij, een uitgavedrempel, een domein-allowlist. Een model de baas maken over de vraag of een mens moet meekijken verslaat het doel.

Is multi-agent 15× de tokens waard? Wat de benchmarks echt zeggen

Orchestrator-workers is het zevende patroon: een hoofdagent decomposeert een taak, delegeert stukken aan worker-agenten en voegt samen wat ze teruggeven. "Multi-agent" is dit patroon tot het extreme doorgetrokken en geen aparte vorm, dus de vraag is eigenlijk wanneer de orchestrator zijn overhead verdient.

Wanneer gebruik je multi-agent in plaats van één agent? Alleen wanneer één agent onder de circa 85% nauwkeurigheid blijft hangen op de taak. Die vuistregel circuleerde op r/AI_Agents (2026-04-23) naast de Google Research-studie, en hij strookt met de gemeten data: boven die grens voegen extra agenten kosten en foutversterking toe zonder nauwkeurigheidswinst.

Hier is elk gepubliceerd cijfer dat we konden verifiëren, naast elkaar:

Eén kanttekening voordat je doorklikt: elk Google Research-cijfer hierboven komt uit de blogpost van 2026-01-28, en het paper erachter (arXiv 2512.08296) is sindsdien herzien, dus de huidige versie rapporteert 260 configuraties en R² = 0,373 in plaats van de 180 en 0,513 uit de blog. De richting houdt in beide gevallen stand; de exacte cijfers hangen af van welke versie je leest.

Twee van deze rijen worden stelselmatig verkeerd geciteerd, dus hier is de rekensom. Het 15×-cijfer van Anthropic is gemeten ten opzichte van een chatinteractie, en hun single-agent-cijfer is 4×. Dus multi-agent kost ruwweg 15 / 4 = 3,75× de tokens van één agent, niet 15×. En de foutversterking van Google Research van 17,2× voor onafhankelijke agenten versus 4,4× voor gecentraliseerde betekent dat een orchestrator ruwweg 17,2 / 4,4 = 3,9× minder foutversterking bevat dan agenten onbeheerd laten draaien.

Lezen we de uitwerking van Anthropic tegen de cijfers van Google Research aan, dan is onze conclusie dat decomposeerbaarheid, niet het aantal agenten, de beslissende variabele is. De research-taak van Anthropic splitste schoon op in parallelle sub-zoekopdrachten, dus meer agenten hielpen. De sequentiële planningstaken van Google splitsten niet op, dus meer agenten liepen elkaar in de weg.

Dat strookt met wat practitioners zeggen zodra systemen in productie draaien. Op r/AI_Agents kwam een thread met de titel "Multi agent systems are a total nightmare in production" (2026-04-23, 56 punten, 68 reacties) van een OP die 20+ klantssystemen heeft opgeleverd: "The ones that actually stay running… are almost embarrassingly simple" en "every time one agent talks to another, you lose context. It's like that game of Telephone." De topreactie vat de hele sectie samen: "try to solve your problem with a single agent. If this agent has >85% accuracy a multi agent system will not add any more value."

Voordat je een agent toevoegt, probeer eerst de goedkope fixes die Anthropic mat: één verbeterde toolbeschrijving leverde 40% minder taakvoltooiingstijd op, en parallelle tool-aanroepen verkortten de researchtijd met tot 90%. Beide verslaan een tweede agent op kosten. Ga je toch multi-agent in een echte tool, dan zijn Claude Code-subagents orchestrator-workers die je regel voor regel kunt inspecteren.

Zelfde patroon, vijf namen: een Rosetta-tabel voor frameworks

Dezelfde vier vormen verschijnen onder verschillende namen in de docs van elke vendor, en de naamgeving draagt niet over tussen frameworks. Microsoft's "magentic" en "group chat" betekenen niets in de OpenAI SDK tot je ze vertaalt, en die vertaalbelasting is een reële kost die deze tabel wegneemt.

Vijf vendors, vijf woordenschatten, drie of vier echte vormen. De praktische kost verschijnt wanneer je van framework wisselt: een team dat van Microsoft's Agent Framework naar de OpenAI SDK verhuist, moet "magentic" herleiden naar agents-as-tools en "group chat" naar een handoff-grafiek voordat er één regel code meeverhuist. De elf namen tellende indeling van Google Cloud is de langste, de lijst van zeven namen van Anthropic de meest geciteerde, en de drie namen van de Claude-blog zijn degenen die je als eerste implementeert. Lees de vorm, lees daarna de SDK. De kolomkoppen zijn de docs zelf: Anthropic, de Claude-blog, de OpenAI Agents SDK, de Vercel AI SDK, Microsoft Learn en Google Cloud. Zodra je de vormen ziet, is een framework kiezen een aparte beslissing; ons overzicht van de beste AI-agent-frameworks van 2026 en de vergelijking LangGraph vs CrewAI vs de OpenAI Agents SDK dekken die af.

Wanneer gebruik je beter helemaal geen agent-workflow?

Vaak niet. De meest-upgevotte beslisboom op r/AI_Agents (2026-03-09) zegt het plat: "If if…then statements will work use that. Then if traditional workflows will work use that. Otherwise use agentic AI." Twee van de top-drie SERP-resultaten zijn clouddocumentatie die je structureel niet kunnen vertellen om minder te bouwen. Wij kunnen dat wel. De data in dit artikel wijzen dezelfde kant op: de twee grootste gemeten winsten (+80,9% en +90,2%) kwamen allebei van taken die schoon decomposeerden, en het grootste gemeten verlies (−70%) kwam van agenten dwingen op een taak die dat niet deed.

De faalmodi hebben namen en elk heeft inmiddels een cijfer:

• Contextverlies over handoffs: elk agent-naar-agent-bericht laat status vallen (de "Telephone"-klacht op r/AI_Agents, 2026-04-23).
• Foutversterking: 17,2× voor onafhankelijke agenten versus 4,4× gecentraliseerd (Google Research, 2026-01-28).
• Doorgeslagen reflectielussen: limiteer iteraties en breek af bij geen verbetering, zoals in de code hierboven.
• Degradatie van sequentiële taken: 39 tot 70% slechter wanneer je werk paralleliseert dat niet decomposeert (Google Research, 2026-01-28).
• Kostenexplosie: ruwweg 15× chattokens voor een multi-agent systeem (Anthropic, 2025-06-13).

Elke faalmodus heeft een limiet die je in tien regels code schrijft, en de limiet is altijd goedkoper dan de agent die je wilde toevoegen.

Walden Yan van Cognition maakte dezelfde zaak van de bouwerskant in Don't Build Multi-Agents (2025-06-12): "Share context, and share full agent traces, not just individual messages" en "Actions carry implicit decisions, and conflicting decisions carry bad results." De vergelijking op r/AI_Agents is degene waar we op blijven terugkomen: "multi agent starts looking a lot like microservices. powerful when the boundaries are real, painful when they're invented."

Hoe Techsy patronen kiest

De ladder hieronder is onze lezing van de bevindingen van Google Research en Anthropic plus de practitioner-threads, geen eigen gemeten resultaat. We lopen hem van boven naar beneden af en stoppen bij de eerste rij die past:

Drie dingen volgen uit de data in dit artikel. Begin sequentieel, want Anthropic zegt het en niets op de SERP spreekt het tegen. Paralleliseer alleen wat decomposeert, want dezelfde coördinatiewijziging die +80,9% mat, mat ook −70%. En behandel een tweede agent als laatste redmiddel, want de tokenrekening is echt en de foutversterking is gemeten. De rode draad is dat agenten toevoegen een schaalzet is en geen kwaliteitszet: de benchmarks belonen het alleen waar het werk splitst, en de practitioner-threads bevestigen het overal elders. Wil je een second opinion over een architectuur voordat je bouwt, vraag dan een gratis consult aan.

Veelgestelde vragen

Wat zijn de 7 AI-agentpatronen?

De zeven zijn sequentieel (prompt chaining), routing (handoff), parallelisering (fan-out/fan-in), orchestrator-workers, reflectie (evaluator-optimizer), ReAct en plan-and-execute. Ze keren onder verschillende namen terug in elke vendorclassificatie, van Anthropic tot Google Cloud. Human-in-the-loop wordt ernaast besproken maar is een controlelaag die elk van de zeven omhult, geen achtste patroon.

Wat zijn de 4 fasen van een AI-agent-workflow?

Plan, act, observe, reflect. Het model plant een volgende stap, handelt door een tool aan te roepen, observeert het toolresultaat dat de context binnenkomt en reflecteert dan op of het doel gehaald is, en loopt door of stopt. Elk patroon in dit artikel is een andere manier om die vier fasen aan elkaar te bedraden.

Wat is het verschil tussen een AI-workflow en een AI-agent?

Een workflow volgt vooraf bepaalde codepaden; een agent laat het model zijn eigen controlestroom sturen. De regel van Anthropic: workflows voor voorspelbaarheid op goed gedefinieerde taken, agenten voor flexibiliteit wanneer modelgestuurde beslissingen op schaal nodig zijn. De meeste productiesystemen zijn workflows met een paar agentstappen erin.

ReAct vs plan-and-execute: welke moet ik gebruiken?

Gebruik ReAct wanneer de volgende stap afhangt van wat de laatste tool teruggaf en de route halverwege kan veranderen. Gebruik plan-and-execute wanneer de route vooraf voorspelbaar is en herplannen na elke stap tokens zou verspillen. ReAct mat +34% op ALFWorld (Yao et al., 2022); plan-and-execute versloeg zero-shot CoT op tien datasets (Wang et al., 2023).

Heb ik een framework zoals LangGraph nodig voor deze patronen?

Nee. Elk codeblok in dit artikel is een kale SDK-aanroep, en de patronen zijn ouder dan de frameworks die ze benoemen. Een framework verdient zijn brood bij statepersistentie, retries en tracing, niet bij het patroon zelf. Als je er een kiest, dekt onze frameworkvergelijking de afwegingen.

Hoe voorkom ik dat een reflectielus oneindig doorloopt?

Twee vangrails, beide in code: een harde iteratielimiet (wij gebruiken 4 rondes) en een geen-verbetering-break die stopt zodra de herschreven versie van de criticus niet beter scoort dan de huidige versie. Vertrouw niet op de prompt om de lus te beëindigen; het model heeft geen benul wat dingen kosten.

Wanneer is één agent genoeg?

Wanneer hij ruwweg 85% nauwkeurigheid haalt op de taak. Die vuistregel circuleerde op r/AI_Agents (2026-04-23) naast de Google Research-studie en strookt met de benchmarks: boven die grens voegen extra agenten kosten en foutversterking toe zonder nauwkeurigheidswinst. Meet de single-agent-baseline voordat je iets groters ontwerpt.

Waar vind ik voorbeelden van AI-agent-workflowpatronen met code?

De vijf Python-blokken hierboven dekken sequentieel, routing, parallelisering, ReAct en reflectie, allemaal als kale SDK-aanroepen die je direct kunt overnemen. Voor vendor-varianten: de Vercel AI SDK scheept uitvoerbare TypeScript per patroon mee en de OpenAI Agents SDK-docs dekken handoffs en agents-as-tools. Links naar beide staan in de bronnenlijst hieronder.

Bronnen

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); paper: arXiv 2512.08296
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang et al., Plan-and-Solve Prompting (ACL 2023)
• Claude by Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (updated 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)