Het verschil tussen een AI-agent die leuk werkt in een demo en een die betrouwbaar is in de praktijk, zit hem in de onderliggende structuur. De architectuur bepaalt of je automatisering overeind blijft bij onverwachte input, API-storingen of hallucinaties van het model. Een verkeerde keuze leidt tot fouten die geen enkele prompt-tweak kan oplossen.
Wat er aan de hand is
De blog van n8n, een platform voor workflow-automatisering, beschrijft de belangrijkste architectuurpatronen voor AI-agenten. Het onderscheidt twee lagen: gedragspatronen (wat één agent kan doen) en topologische patronen (hoe meerdere agenten samenwerken). Zonder een bewuste keuze op beide vlakken riskeer je een agent die in isolatie werkt, maar faalt zodra hij onderdeel wordt van een groter systeem.
De kern van het probleem: veel ondernemers bouwen een prototype dat werkt met een paar testinputs, maar stuit op instabiliteit zodra echte gebruikers, wisselende data of API-timeouts om de hoek komen kijken. De blog benadrukt dat het beheersen van deze afwegingen het verschil maakt tussen een functionele agent en een betrouwbare.
Wat dit betekent
Voor Nederlandse ondernemers betekent dit dat de keuze voor een AI-agent niet alleen een technische is, maar een strategische. Een simpele chatbot voor klantvragen vraagt een andere structuur dan een geautomatiseerd inkoopproces dat meerdere systemen aanstuurt.
De blog noemt het patroon ’tool use’ als voorbeeld: een agent krijgt gestructureerde functies mee, zoals ‘check voorraad’ of ‘update CRM-rij’. Dit werkt snel en eenvoudig voor directe acties. Maar het faalt als het model hallucineert en een niet-bestaande tool aanroept of verkeerde parameters meegeeft. Voor een webshop die automatisch voorraadstanden bijwerkt, is dat risico klein. Voor een financiële workflow die betalingen verwerkt, is dat onacceptabel.
De valkuil is dat ondernemers vaak kiezen voor het patroon dat het makkelijkst te bouwen is, niet het patroon dat het beste past bij de complexiteit en foutgevoeligheid van hun proces.
Hoe je dit kunt toepassen
Als je een eenvoudige chatbot voor klantvragen bouwt. Het ’tool use’-patroon is hier je beste keuze. Je geeft de agent een paar vaste functies mee, zoals ‘zoek in FAQ’ of ’toon openingstijden’. De snelheid is hoog, de complexiteit laag. Een mogelijke toepassing is een chatbot op je website die alleen antwoord geeft op basis van een vaste kennisbank. Overweeg om te beginnen met dit patroon en pas uit te breiden als de vragen complexer worden.
Als je een workflow automatiseert met meerdere stappen, zoals orderverwerking. Hier heb je een topologisch patroon nodig, geen enkelvoudige agent. Denk aan een sequentieel patroon: stap 1 controleert de voorraad, stap 2 boekt de betaling, stap 3 genereert het verzendlabel. Elke stap is een aparte agent met een eigen taak. Dit voorkomt dat één hallucinatie de hele keten platlegt. Een optie is om per stap een foutafhandeling in te bouwen, zoals een melding naar je team als een API-timeout optreedt.
Als je een complex proces hebt met onvoorspelbare input, zoals een offertegenerator voor maatwerk. Gebruik een supervisor-patroon: één centrale agent die subtaken uitdeelt aan gespecialiseerde agenten. De supervisor beoordeelt of het resultaat klopt voordat het naar de volgende stap gaat. Dit kost meer ontwikkeltijd, maar voorkomt dat een foutieve offerte naar de klant gaat. Overweeg om te beginnen met een prototype in een tool als n8n of Make, waarin je de supervisor-logica visueel kunt bouwen zonder code.
Als je een bestaande automatisering hebt die onbetrouwbaar is geworden. Analyseer waar de fouten ontstaan. Is het een hallucinatie in een vrije tekststap? Voeg dan een validatiestap toe die het model dwingt om binnen een schema te blijven. Is het een API-timeout die de hele workflow stillegt? Bouw dan een timeout-handler die de stap opnieuw probeert of een fallback activeert. De blog stelt dat misplaatste patronen vaak de oorzaak zijn van instabiliteit die niet met prompts is op te lossen.
De praktische toepassing hangt af van jouw situatie, maar het principe is universeel: begin met het eenvoudigste patroon dat past bij de complexiteit van je proces, en breid alleen uit als de foutgevoeligheid dat vereist.
Bron: n8n blog