Toen we voor het eerst een AI-agent uitrolden voor een productieclient — de taak: rapportages automatiseren uit meerdere systemen — startten we naïef met een eenvoudige lus: één LLM en een reeks tools. Het werkte... zolang niets anders liep dan verwacht. Zodra één tool een onverwachte uitvoer teruggaf, raakte de agent in een lus en genereerde hij 40 minuten lang tokens totdat we hem handmatig stopten. Het probleem was niet het model. Het probleem was de architectuur — niet ontworpen voor reële omstandigheden.
Vandaag bestaan er drie dominante patronen voor AI-agentarchitecturen: ReAct, Plan-and-Execute en reflectie. Elk heeft zijn plek, elk heeft zijn beperkingen. Dit artikel is een beslisraamwerk — wanneer welk patroon te kiezen, wat u ervan kunt verwachten en waar het u in de problemen brengt.
Waarom architectuurkeuze ertoe doet
De keuze van architectuur is niet alleen een technisch detail. Het heeft directe invloed op vier metrics die in productie ertoe doen:
- Betrouwbaarheid — hoe de agent reageert op onverwachte tool-uitvoer of fouten
- Kosten — hoeveel tokens per taak worden verbruikt
- Latency — hoe snel de gebruiker een resultaat krijgt
- Debugbaarheid — hoe eenvoudig u kunt achterhalen waar en waarom de agent faalde
Belangrijke kanttekening: ReAct, Plan-and-Execute en Reflexion zijn academische patronen uit 2022–2023 (Yao et al. 2022 voor ReAct). LangGraph, AutoGen, CrewAI en andere frameworks *implementeren* deze patronen — maar ze hebben ze niet uitgevonden. De keuze van framework is een secundaire beslissing. De primaire beslissing is de keuze van patroon.
ReAct: Reason-Act-Observe-lus
ReAct (Reasoning + Acting) is het eenvoudigste en meest verspreide patroon. De agent werkt in een lus:
- 1.Reason — op basis van de huidige staat en geschiedenis "denkt" het LLM na (genereert tekst die het redeneerproces beschrijft)
- 2.Act — kiest een tool en roept die aan met concrete parameters
- 3.Observe — ontvangt de tool-uitvoer en voegt die in de context in
- 4.Herhaalt dit totdat het doel bereikt is of een eindbeslissing is genomen
De kracht van ReAct is aanpasbaarheid. Als er iets verandert tijdens de uitvoering — een tool geeft een onverwacht resultaat, een API wijzigt het formaat — ziet de agent dat in de Observe-fase en kan de aanpak aanpassen. Niet op basis van een vooraf geschreven plan, maar reactief.
Waar ReAct goed werkt
- Taken met 2–4 stappen en een helder doel (zoek X op, verwerk Y, schrijf Z weg)
- Interactieve tools waarbij de context in real-time wijzigt
- Prototyping — ReAct is het snelst te implementeren
- Wanneer u een zo eenvoudig mogelijk audit-log wilt (elke Reason-Act-Observe-stap is zichtbaar)
Waar ReAct faalt
- Lange taken met veel stappen — elke nieuwe stap voegt de volledige geschiedenis aan de context toe; de kosten groeien kwadratisch
- Parallelle taken — ReAct is sequentieel en kan niet meerdere vertakkingen tegelijk uitvoeren
- Zonder `max_steps`-limiet is het gevaarlijk — dit is geen overdrijving. Een agent zonder ingestelde staplimiet kan 's nachts in een lus vastlopen en duizenden overbodige API-aanroepen genereren — met een rekening van duizenden euro's tot gevolg. We zien dit in de praktijk; het is geen hypothetisch risico.
Belangrijke correctie van een wijdverbreid misverstand: het woord "Reason" in ReAct *betekent niet* dat de agent daadwerkelijk correct redeneert. De Reason-stap is een taalkundige uitvoer — het LLM genereert tekst die eruitziet als redeneren. Die tekst kan vol fouten zitten, en het model geeft dit op geen enkele manier aan. Niet-verifieerbaar "denken" is een van de meest voorkomende oorzaken van stille fouten bij ReAct-agents.
Kostenprofiel van ReAct
Een typische ReAct-taak verbruikt 2 000–3 000 tokens bij 3–4 stappen. Bij 8+ stappen kan het verbruik oplopen tot 10 000–20 000 tokens per taak, omdat de volledige geschiedenis in elk contextvenster herhaald wordt. Bij productiebelasting merkt u dit op de factuur.
Plan-and-Execute: eerst plannen, dan uitvoeren
Plan-and-Execute (P&E) splitst de agent in twee fasen:
- 1.Planner — ontvangt het doel en genereert een expliciet stappenplan (bijv. "stap 1: laad data via API, stap 2: transformeer formaat, stap 3: sla op in database, stap 4: verstuur rapport")
- 2.Executor — voert de stappen één voor één uit volgens het plan, zonder opnieuw te plannen
Het cruciale voordeel: de planner en de executor hoeven niet hetzelfde model te zijn. Dit is economisch interessant — een duur, sterk model (bijv. een model van de klasse Claude Opus of GPT) doet de planning, waar kwaliteit telt. Een goedkoop, snel model doet de uitvoering, waar snelheid en prijs tellen. Voor lange taken met N stappen kan dit goedkoper uitvallen dan puur ReAct.
Waar P&E goed werkt
- Lange, gestructureerde taken (5+ stappen met een heldere logica)
- Batchverwerking — wanneer u 1 000 documenten via dezelfde procedure moet verwerken
- Auditeerbare pipeline — het plan is een expliciet document dat de klant vóór de start kan inzien
- Weerstand tegen prompt injection — onderzoek wijst uit dat P&E een zekere inherente voordeel heeft: de executor heeft geen toegang tot de planningsinstructies, waardoor een aanvaller in de data hem moeilijker kan omleiden (dit is echter geen volledige bescherming)
Waar P&E faalt
Basis-P&E heeft een vast plan. Als de omstandigheden tijdens de uitvoering veranderen — een API geeft een ander formaat terug, stap 3 mislukt — gaat de agent door op het oude plan of loopt hij vast. Dynamic replanning (opnieuw plannen na een fout) is een uitbreiding, geen basiseigenschap van P&E. U moet het expliciet implementeren.
Nog een misverstand om recht te zetten: P&E is *niet altijd nauwkeuriger* dan ReAct. Voor dynamische omgevingen waar de omstandigheden tijdens de uitvoering veranderen, is ReAct aanpasbaarder. P&E is beter waar de omgeving voorspelbaar is en het plan tot het einde geldig blijft.
Kostenprofiel van P&E
Een typische P&E-taak verbruikt 3 000–4 500 tokens (inclusief de planningsfase). Op het eerste gezicht duurder dan ReAct. Maar voor taken met 8+ stappen is het totale verbruik lager — de executor werkt met een kortere context dan een ReAct-lus die de volledige geschiedenis accumuleert. Aanbeveling: voor korte taken (2–4 stappen) kiest u ReAct; voor lange taken (6+ stappen) overweegt u P&E.
Reflectie en self-critique
Reflectie (Reflexion, Shinn et al. 2023) voegt een zelfbeoordelingslaag toe bovenop ReAct of P&E:
- 1.De agent voert de taak uit (ReAct of P&E)
- 2.De reflectiemodule evalueert het resultaat — "is het doel bereikt? Waar zijn fouten opgetreden?"
- 3.Op basis van de reflectie wordt het geheugen van de agent bijgewerkt, of wordt de stap herhaald met een aangepaste aanpak
Voorbeeld van resultaten: op CodeContests-taken steeg GPT-4 van circa 19 % slagingspercentage bij een eenvoudige prompt naar circa 44 % met een iteratieve test-driven aanpak (gepubliceerde AlphaCodium-flow). Dit is een reële verbetering — met name bij taken met deterministische verificatie.
Waar reflectie helpt
- Codeertaken met deterministische verificatie (de code slaagt voor de tests of niet)
- Iteratieve uitvoer — wanneer de eerste versie nooit voldoende is en u automatische verbetering wenst
- Complexe analyses waarbij u een tweede blik op het resultaat nodig heeft
Beperkingen van reflectie
Cruciale beperking: wanneer hetzelfde model zowel de uitvoer als de kritiek genereert, heeft reflectie de neiging dezelfde fouten te herhalen. Het model ziet de blinde vlekken in zijn eigen redenering niet. Replicatiestudies uit 2025 bevestigen dit — single-agent Reflexion in iteratieve cycli convergeert naar hetzelfde (verkeerde) antwoord. De oplossing is ofwel een ander model voor verificatie, ofwel een externe deterministische verificator (tests, linter, schemavalidatie).
Meer over hoe guardrails voor AI-agents helpen deze fouten op te vangen voordat ze de gebruiker bereiken.
Wanneer één LLM-aanroep volstaat
Voordat u een agentarchitectuur kiest, is de vraag: *heb ik eigenlijk wel een agent nodig?*
Naar onze schatting kan 40–50 % van de use-cases waarmee klanten met een agentvraag komen, worden afgehandeld met één of twee LLM-aanroepen zonder enige lus. Voorbeelden:
- Documentclassificatie (één aanroep, structured output)
- Veldextractie uit een factuur (één aanroep + JSON mode)
- Rapportgeneratie vanuit voorbereide data (één aanroep, lange prompt)
- Samenvatting met citaten (één aanroep + agentic RAG pipeline)
De vuistregel: als u van tevoren precies de invoer, uitvoer en transformatie kunt definiëren, heeft u geen agent nodig. Een agent voegt waarde toe wanneer de stappen niet op voorhand bekend zijn of de omgeving dynamisch is.
Verwante beslissing: chatbot vs copilot vs agent — waar precies de grenzen tussen deze begrippen liggen.
Beslisraamwerk
In plaats van een tabel (die de trade-offs zou vereenvoudigen) bieden we een reeks vragen:
1. Hoeveel stappen telt de taak? - 1–3 stappen → één LLM-aanroep of eenvoudige ReAct - 4–7 stappen, voorspelbare omgeving → Plan-and-Execute - 8+ stappen met parallelle logica → P&E + DAG-executor of multi-agent
2. Verandert de omgeving tijdens de uitvoering? - Nee (batchverwerking, deterministische procedure) → P&E - Ja (interactief, real-time data, onvoorspelbare API) → ReAct
3. Heeft u een auditeerbare uitvoer nodig? - Ja, de klant wil het plan vóór de start zien → P&E - Nee, het resultaat telt → ReAct (kortere opstarttijd)
4. Hoe groot is de impact van een fout? - Laag (intern tool, eenvoudig te herstellen) → ReAct met max_steps-limiet - Hoog (klant, gereguleerde sector) → P&E + reflectie + human-in-the-loop
5. Heeft u een dedicated team voor onderhoud? - Nee → zo eenvoudig mogelijk patroon. ReAct met duidelijke max_steps, logging van elke stap. - Ja → u kunt P&E + dynamic replanning + reflectie aan.
Hybride architecturen in de praktijk
In productie zien we bijna nooit puur ReAct of puur P&E. Veelvoorkomende combinaties:
- P&E + ReAct-executor — de planner genereert de stappen, elke stap wordt uitgevoerd door een mini-ReAct-agent met toegang tot tools
- ReAct + reflectie — na afronding van de ReAct-lus start een reflectiemodule die de kwaliteit van de uitvoer beoordeelt
- P&E + dynamic replanning — bij het mislukken van een stap wordt het volledige plan herzien, niet alleen die stap
LangGraph is vandaag de de-facto standaard voor de implementatie van deze hybride patronen in Python. Alternatieven zoals AutoGen (Microsoft) of CrewAI zijn sterk voor multi-agentcoördinatie, maar LangGraph heeft het grootste ecosysteem en de meeste productiestabiliteit.
Een breder perspectief op wat een agent in productie kost, inclusief per-aanroep-prijsstelling en optimalisatiemethoden, vindt u in een apart artikel.
Debugbaarheid — de onderschatte dimensie
Architectuur beïnvloedt ook hoe eenvoudig u een fout kunt vinden. Uit de praktijk:
ReAct: elke Reason-Act-Observe-stap is zichtbaar in het trace-log. Wanneer de agent faalt bij stap 7, ziet u precies welke Observe-invoer hij ontving en welke Reason hij genereerde. Goed debugbaar — als u elke stap correct logt.
P&E: het plan is een expliciet document — u ziet eenvoudig waar de executor afweek van het plan. Maar fouten in het plan zelf (verkeerde logica van de planner) zijn moeilijker te ontdekken, omdat de planner slechts één keer draait en zijn beslissingen niet incrementeel zijn.
Reflectie: het moeilijkst te debuggen. Iteratieve cycli produceren veel logs, en wanneer het model in elke cyclus dezelfde fout herhaalt, kan het lastig zijn de grondoorzaak te bepalen.
Meer over het opzetten van observability voor AI-agents — tracing, logging en alerting — bij productie-uitrol.
Veelgestelde vragen
Wat is de ReAct-architectuur en waar komt die vandaan?
ReAct (Reasoning + Acting) is een patroon voor AI-agents ontworpen door Yao et al. in 2022 (academische publicatie). De agent werkt in een Reason–Act–Observe-lus: het LLM denkt na, kiest een tool, ontvangt het resultaat en herhaalt. LangGraph, LangChain en andere frameworks implementeren dit patroon, maar hebben het niet uitgevonden.
Wanneer kiest u Plan-and-Execute boven ReAct?
Plan-and-Execute is geschikt voor lange, gestructureerde taken (6+ stappen) met een voorspelbare omgeving, waarbij u vóór de start een auditeerbaar plan wilt. ReAct is beter voor korte, dynamische taken waarbij de omstandigheden tijdens de uitvoering veranderen. Voor 1–3 stappen overweegt u of u überhaupt een agent nodig hebt.
Is Plan-and-Execute altijd nauwkeuriger dan ReAct?
Nee. P&E heeft een voordeel bij gestructureerde, voorspelbare taken. Voor dynamische omgevingen waar de omstandigheden tijdens de uitvoering veranderen, faalt P&E — de agent gaat door op een verouderd plan. ReAct is aanpasbaarder omdat het op elke Observe-uitvoer reageert.
Waarom is het gevaarlijk een ReAct-agent zonder max_steps-limiet te starten?
Zonder ingestelde staplimiet kan de agent in een lus terechtkomen (bijv. herhaaldelijk een tool aanroepen die een fout teruggeeft, zonder dat de agent dit als terminale staat herkent). Zo'n ongecontroleerde agent kan 's nachts duizenden aanroepen genereren — en een rekening van duizenden euro's. Elke productieagent moet een expliciet max_steps- of max_iterations-parameter hebben.
Kan ik ReAct en reflectie combineren?
Ja, hybride architecturen zijn in productie gebruikelijk. Typische combinatie: een ReAct-lus voor de uitvoering van stappen, gevolgd door een reflectiemodule die de kwaliteit van de uitvoer beoordeelt. Belangrijke kanttekening: reflectie werkt alleen betrouwbaar wanneer de uitvoer wordt beoordeeld door een ander model of een externe deterministische verificator (tests, schemavalidatie) — niet door hetzelfde model dat de uitvoer genereerde.
*Als u overweegt een AI-agent in uw bedrijf uit te rollen en niet zeker weet welke architectuur geschikt is voor uw use-case, beoordelen wij graag de concrete situatie. Bij MP Industrial Solutions helpen we klanten de aanpak te kiezen die aansluit bij hun reële eisen op het gebied van betrouwbaarheid, kosten en teamcapaciteit — niet de aanpak die er het indrukwekkendst uitziet in een demo.*