Het verschil tussen een werkende AI-demo en een systeem dat dagelijks draait, zit hem niet in de prompt maar in de onderliggende architectuur. De keuze voor een bepaald patroon bepaalt of je chatbot fouten netjes afhandelt of vastloopt bij een onverwachte vraag.

Wat er aan de hand is

De blog van n8n, een platform voor workflow-automatisering, beschrijft hoe je AI-agenten structureert voor productieomgevingen. De kern is dat er twee lagen zijn waar je keuzes maakt: gedragspatronen (wat één agent kan doen) en topologische patronen (hoe meerdere agenten samenwerken). Zonder bewuste keuzes op beide lagen riskeer je een systeem dat in isolatie werkt, maar faalt zodra het echte gebruikers bedient. Volgens n8n is de echte uitdaging niet de code om een model aan te roepen, maar het ontwerp van hoe controle stroomt tussen componenten, hoe taken worden uitgevoerd en hoe fouten worden opgevangen. Een verkeerd patroon introduceert fouten die geen enkele prompt-engineering kan oplossen.

Wat dit betekent

Voor een MKB-ondernemer betekent dit dat de keuze voor een AI-chatbot of automatisering niet alleen over de juiste tool gaat, maar over de structuur erachter. Een autonome loop (waarbij de agent zelf beslist wat hij doet) werkt goed voor open vragen, maar kan vastlopen als je een vaste stappenreeks nodig hebt. Een centrale aansturing (één agent die alles regelt) kan traag worden bij veel gebruikers. De blog waarschuwt dat een verkeerd patroon leidt tot ‘failure modes’ die je niet kunt oplossen met betere prompts. Voor een klein team zonder eigen AI-engineer is het essentieel om een patroon te kiezen dat past bij de taak: simpele, directe acties zoals het opzoeken van een voorraad of het bijwerken van een CRM-rij vragen om een ander patroon dan een klantenservice-chatbot die meerdere stappen moet zetten.

Hoe je dit kunt toepassen

Als je een eenvoudige taak automatiseert, zoals het controleren van een voorraadniveau of het versturen van een factuur. Overweeg om het patroon ’tool use’ te gebruiken. Dit is het snelste en eenvoudigste patroon: je geeft de agent een set vaste functies (tools) die hij kan aanroepen op basis van een prompt. Het werkt goed voor directe, afgebakende acties. Het risico is dat de agent een niet-bestaande tool aanroept of verkeerde parameters meegeeft, vooral bij oudere modellen. Je zou kunnen beginnen met dit patroon voor taken die maar één stap nodig hebben en waar fouten makkelijk te herstellen zijn.

Als je een klantenservice-chatbot bouwt die vragen moet beantwoorden over bestellingen, retouren en openingstijden. Een mogelijkheid is om te werken met een vast stappenplan (step-by-step sequentie) in plaats van een volledig autonome agent. De blog waarschuwt dat een autonome loop kan vastlopen als er een vaste volgorde nodig is. Je zou de chatbot kunnen programmeren om eerst de vraag te categoriseren, dan de juiste database te raadplegen, en pas daarna een antwoord te formuleren. Dit patroon is minder flexibel, maar wel voorspelbaarder en makkelijker te debuggen.

Als je meerdere automatiseringen wilt laten samenwerken, bijvoorbeeld een chatbot die een bestelling plaatst én de voorraad bijwerkt. Overweeg om agenten te scheiden per taak in plaats van één centrale agent alles te laten doen. De blog noemt dit topologische patronen: hoe agenten samenwerken. Een centrale agent kan een bottleneck worden bij veel verkeer. Je zou kunnen kiezen voor een patroon waarbij een routeringsagent de vraag doorstuurt naar gespecialiseerde agenten (één voor voorraad, één voor bestellingen). Dit is complexer om op te zetten, maar schaalt beter en is beter bestand tegen fouten in één onderdeel.

Als je een systeem bouwt dat fouten moet kunnen opvangen zonder menselijke tussenkomst. Een optie is om per patroon expliciet na te denken over ‘failure containment’. De blog stelt dat een sterk raamwerk prioriteit geeft aan hoe fouten worden opgevangen. Je zou bijvoorbeeld een timeout kunnen inbouwen per agent, of een fallback-stap waarin de agent een standaardantwoord geeft als een API niet reageert. Overweeg om niet te vertrouwen op de modelkwaliteit alleen, maar de architectuur zo te ontwerpen dat een enkele hallucinatie of API-timeout niet de hele workflow stillegt.

De praktische toepassing hangt af van jouw situatie, maar het begint met de vraag: wat moet er gebeuren als het misgaat? De blog van n8n maakt duidelijk dat die vraag niet in de prompt thuishoort, maar in de architectuur.

Bron: n8n blog