AI-agents in productie: waarom 95% faalt

“AI-agents in productie” betekent een agent die een gecrashte procesinstantie, een vastgelopen API-aanroep of een taak van zes uur in plaats van zes seconden overleeft — geen demo die één keer werkt, in een stille kamer, op het beste-geval-pad. Dat onderscheid weegt medio 2026 zwaarder dan een jaar geleden: vier verschillende frameworks brachten binnen zes weken tijd stabiele, duurzame uitvoeringsprimitieven (durable execution) uit, en de betrouwbaarheidsrekensom verklaart waarom dat niet toevallig is.

Waarom de meeste agent-pilots nooit productie halen

MIT's NANDA-initiatief vond dat ongeveer 95% van de generatieve-AI-pilots bij bedrijven geen meetbare zakelijke impact oplevert, op basis van 300 implementaties en interviews bij 150 organisaties. Richting 2026 is de vraag verschoven van “werkt dit model” naar “overleeft deze agent het contact met een echt systeem.” De faalfactor is zelden een fout model. Het is de agent die zijn status kwijtraakt: een tool-aanroep loopt vast, een server herstart, een goedkeuring duurt vier uur in plaats van vier seconden, en de hele run moet opnieuw — of erger, herhaalt stilletjes een actie die al is uitgevoerd.

Dit stuk gaat over de infrastructuurhelft van dat faalpercentage — gecrashte processen, verloren status, vastgelopen tool-aanroepen. De niet-technische helft — scope, sponsorschap, datagereedheid — behandelen we in onze gids over waarom AI-pilots mislukken.

Dezelfde MIT-analyse vond dat inkopen bij een gespecialiseerde leverancier of bouwen via een samenwerking in ongeveer 67% van de gevallen slaagde, tegenover ruwweg een derde daarvan bij puur interne bouwtrajecten — niet omdat interne teams slechtere code schrijven, maar omdat zij dezelfde durable-execution-loodgieterij opnieuw uitvinden die elke leverancier al heeft opgelost. Dat is het praktische argument om onderstaande frameworks te zien als infrastructuur om over te nemen, niet als iets om per project opnieuw uit te vinden.

De betrouwbaarheidsrekensom maakt het onderliggende probleem concreet. Stel dat een agent vijf tool-aanroepen aan elkaar knoopt voor één taak — een binnenkomende e-mail lezen, de order opzoeken in uw ERP, voorraad checken, een offerte opstellen, versturen — en elke stap slaagt op zichzelf 85% van de tijd, een realistisch cijfer voor een goed afgestelde agent, geen slordige. De keten als geheel slaagt dan slechts 0,85⁵ ≈ 44% van de tijd. Voeg een tweede goedkeuringsstap en een vervolgactie toe — tien stappen in totaal — en diezelfde 85% betrouwbaarheid per stap valt terug naar 0,85¹⁰ ≈ 20%. Vier van de vijf runs lopen ergens in de keten vast. Geen hoeveelheid prompt-tuning lost dat op; het is een infrastructuurprobleem, en durable execution is het infrastructuurantwoord.

Wat durable execution werkelijk oplost

Durable execution legt elke voltooide stap van een workflow vast als event-log en speelt dat log opnieuw af bij een storing, waarbij de run hervat vanaf de laatst voltooide stap in plaats van vanaf het begin. Temporal, de durable-execution-engine achter dit patroon, haalde in februari 2026 een Series D van $300 miljoen op bij een waardering van $5 miljard en bracht in maart 2026 een algemeen beschikbare integratie met de OpenAI Agents SDK uit — OpenAI, Replit en Lovable bouwen er allemaal productie-agents op. Het punt is niet om nóg een leverancier aan uw stack toe te voegen; het is om een LLM-aanroep niet langer als fire-and-forget te behandelen. Een durable agent kan uren pauzeren in afwachting van menselijke goedkeuring, een serverherstart midden in een taak overleven, en alleen de mislukte stap opnieuw proberen — niet de hele run.

Vier frameworks, vier keuzes — wat in juni en juli 2026 verscheen

De afgelopen zes weken leverden meer productierijpe agent-tooling op dan het hele voorgaande jaar, en elke release zet in op een andere laag van hetzelfde probleem.

• Pydantic AI v2 werd op 23 juni 2026 stabiel na zeven bèta's en verving het vorige model door één “capabilities”-primitief — één samengestelde eenheid met de tools, hooks, instructies en modelinstellingen van een agent. Durable execution verhuist naar diezelfde capability-laag, zodat een Python-first agent herstarts en lange human-in-the-loop-pauzes overleeft zonder aparte orkestratie-engine.
• LlamaIndex Workflows 1.0 werd een dag eerder stabiel, op 22 juni 2026, als eigen zelfstandig package. Het voegt getypeerde workflow-status toe in zowel Python als TypeScript, resource-injectie voor databaseclients, en observability op basis van OpenTelemetry — expliciet gericht op meerstaps document- en onderzoeksagents die in productie debugbaar moeten zijn, niet alleen demonstreerbaar in een notebook.
• Claude Agent SDK kreeg op 10 juni 2026 hiërarchische subagents (Claude Code v2.1.172): een subagent kan nu eigen subagents starten, tot vijf niveaus diep, elk in een geïsoleerde context. Anthropics eigen onderzoek liet zien dat vijf niveaus vrijwel elke praktische engineeringworkflow dekt — voor een bouwteam is de winst contextisolatie en parallelle deeltaken zonder de prompt van de hoofdagent op te blazen.

• n8n bracht op 7 juli 2026 een ronde betrouwbaarheidsfixes uit (v2.29.7), en de productierichtlijn voor 2026 is expliciet: draai AI Agent-workflows in queue mode met PostgreSQL en Redis, niet in de standaard single-process-modus, specifiek om execution-timeouts bij langlopende agent-aanroepen te voorkomen.

Samen is dat Python-native code (Pydantic AI, LlamaIndex), Anthropic-native orkestratie (Claude Agent SDK) en low-code automatisering (n8n) — drie verschillende ingangen tot dezelfde durable-execution-verschuiving, met LangGraph 1.0 en Temporal daaronder als zwaargewicht-optie voor teams die volledige replay en audit trails nodig hebben.

Welke laag past bij een Nederlands mkb-bedrijf

De meeste mkb-bedrijven hebben Temporal nooit rechtstreeks nodig, en dat is de juiste keuze, geen compromis. Een installatiebedrijf of accountantskantoor van 20–50 fte dat offertes of factuurmatching tegen Exact Online, AFAS of e-Boekhouden automatiseert, haalt het grootste deel van de betrouwbaarheidswinst uit n8n in queue mode met een Postgres-gedekte executiegeschiedenis en één duidelijk gedefinieerde menselijke goedkeuringsstap voordat er iets verstuurd of geboekt wordt — geen aparte orkestratie-engine nodig. Een team met een eigen ontwikkelaar dat code wil bezitten in plaats van een abonnement op een workflow-bouwer, is beter geholpen met Pydantic AI v2 of de Claude Agent SDK: beide zijn Python- of code-first, beide leveren nu native durable-execution- of contextisolatie-primitieven, en beide leveren een codebase op die een ontwikkelaar daadwerkelijk kan reviewen. Temporal of LangGraph verdient de extra complexiteit pas zodra een agent uren of dagen draait, direct met geld of contracten werkt, of een volledig herspeelbaar audit trail nodig heeft voor compliance — in de praktijk vaker mid-market (250–500 fte) terrein dan mkb.

Durable execution lost geen verkeerde beslissing op

Niets van dit alles lost de andere helft van het betrouwbaarheidsprobleem op: een agent die betrouwbaar de verkeerde tool aanroept, is nog steeds fout, alleen efficiënter fout. Durable execution verhelpt infrastructuurstoringen — crashes, timeouts, herstarts, verloren status. Het doet niets aan een model dat een offerteaanvraag verkeerd leest of een terugbetaling goedkeurt die had moeten worden gemarkeerd. Die andere helft wordt nog steeds opgelost met evals die op tool-aanroepniveau scoren in plaats van alleen end-to-end, met expliciete guardrails over wat een agent zonder goedkeuring mag doen, en — zie hieronder — een mens in de loop bij alles wat onomkeerbaar is. Teams die een nieuw durable-execution-framework als vervanging voor evals behandelen, ruilen het ene faalpatroon in voor het andere, zonder er één weg te nemen.

Een checklist voor productierijpheid

Voordat u een agent “klaar” noemt, scheiden vijf vragen een demo van iets waar een bedrijf op kan draaien:

• Heeft elke tool-aanroep een gedefinieerd retry- en backoff-beleid, of doodt een timeout gewoon de hele run?
• Staat elke onomkeerbare actie — een e-mail versturen, een factuur boeken, geld verplaatsen — achter een expliciete menselijke goedkeuringsstap voordat deze doorgaat?
• Wordt de status buiten het draaiende proces opgeslagen, zodat een crash hervat vanaf de laatst voltooide stap in plaats van stap één?
• Kan iemand per run precies zien welke stap faalde en waarom — gestructureerde logs of OpenTelemetry-traces — in plaats van alleen “het ging stuk”?
• Dekt het testplan ook wat er gebeurt als een tool niet beschikbaar is, niet alleen het beste-geval-scenario?

Meer dan één keer “nee” op deze vragen is een betrouwbaar teken dat het project nog een pilot is, wat de verkoopdia ook beweert.

Waar MCP hieronder past

Deze durable-execution-golf zit direct bovenop de protocollaag die we behandelden in ons stuk over de MCP 2026-spec: de stateless kern en Tasks-extensie van MCP laten een server een task-handle teruggeven in plaats van een sessie open te houden — precies het primitief dat een durable agent nodig heeft om een herstart midden in een tool-aanroep te overleven. Bovenstaande frameworks zijn in feite de clientzijde van diezelfde verschuiving. Twijfelt u nog welke laag van de 2026-stack — MCP, RAG, agents of A2A — uw probleem eigenlijk nodig heeft, dat behandelen we in onze stack-uitleg, en agentgeheugen — een verwant maar apart faalpatroon — in ons stuk over agentgeheugen.

Waar begint u?

Breng eerst één workflow in kaart — die met de duidelijkste, meest herhaalbare stappen en de hoogste kosten als deze stilletjes faalt — voordat u een framework kiest. Draait er al een chatbotflow of WhatsApp- of e-mailintake in n8n of Make, voeg dan queue mode, een Postgres-gedekte geschiedenis en één goedkeuringsstap toe voordat u naar iets zwaarders grijpt. Bouwt uw team een meerstaps-agent vanaf nul, dan zijn Pydantic AI v2 of de Claude Agent SDK een beter te verdedigen 2026-standaard dan een zelfgebouwde retry-lus — en de moeite waard om af te zetten tegen de beveiligingskant van dezelfde verschuiving in ons dreigingsmodel voor agentbeveiliging. Lees hoe wij agent-bouwtrajecten scopen op onze pagina AI-agentontwikkeling, en wat een werkend systeem onderscheidt van een demo in onze gids productie-AI, geen demo's.

Veelgestelde vragen