Het verschil tussen een AI-agent die werkt in een testomgeving en een die betrouwbaar draait in de praktijk, zit hem in de onderliggende architectuur. Voor een MKB’er betekent dit: de structuur van je AI-systeem bepaalt of je automatisering stabiel blijft bij onverwachte invoer, of dat hij vastloopt bij de eerste foutmelding.
Wat er aan de hand is
In een blog van n8n, een platform voor workflow-automatisering, worden de belangrijkste architectuurpatronen voor AI-agenten uitgelegd. Het onderscheid is cruciaal: er zijn gedragspatronen (hoe één agent denkt en beslist) en topologische patronen (hoe meerdere agenten samenwerken). De keuze tussen deze patronen bepaalt of een systeem schaalbaar is en fouten aankan. Een verkeerde keuze leidt tot storingen die je met prompt engineering niet kunt oplossen, zoals een autonome loop die vastloopt in een omgeving waar stap-voor-stap logica nodig is.
Wat dit betekent
Voor ondernemers betekent dit dat de architectuur van een AI-agent directe invloed heeft op de betrouwbaarheid en kosten van je automatisering. Een simpele chatbot die alleen een voorraadpeiling doet, heeft een andere structuur nodig dan een klantenservice-systeem dat meerdere systemen aanstuurt. De blog waarschuwt dat een verkeerd patroon leidt tot hallucinaties (de agent verzint parameters) of time-outs die de hele workflow blokkeren. Voor een MKB’er zonder eigen IT-afdeling is het essentieel om deze valkuilen te herkennen voordat je een systeem in productie neemt.
Hoe je dit kunt toepassen
Als je een simpele chatbot wilt bouwen voor bijvoorbeeld voorraadinformatie of prijsopvragingen. Het eenvoudigste patroon is ’tool use’: je geeft de agent een set vaste functies, zoals ‘check voorraad’ of ‘bereken verzendkosten’. Dit is snel en goedkoop, maar je bent afhankelijk van het vermogen van het taalmodel om exact de juiste parameters mee te geven. Een mogelijke aanpak is om te beginnen met een beperkt aantal tools en de output altijd te laten valideren door een eenvoudige regel, zoals een check op getalwaarden. Zo voorkom je dat een hallucinatie leidt tot een foutieve bestelling.
Als je een klantenservice-automatisering opzet die meerdere systemen aanstuurt, zoals CRM, facturatie en verzending. Hier heb je een topologisch patroon nodig: meerdere agenten die elk een eigen taak hebben. Een centrale supervisor-agent kan bijvoorbeeld bepalen of een vraag over retouren gaat en die doorsturen naar een gespecialiseerde retour-agent. Het risico is dat de centrale agent een knelpunt wordt bij veel verkeer. Overweeg om de supervisor te laten werken met een wachtrij en time-outs per agent in te stellen, zodat één trage agent niet de hele keten ophoudt.
Als je een proces automatiseert dat vaste stappen vereist, zoals een offerte-aanvraag die eerst controleert op kredietwaardigheid, dan voorraad checkt en daarna een prijs berekent. Gebruik geen autonome loop, maar een stap-voor-stap sequentie. De blog waarschuwt dat een autonome loop in zo’n situatie kan blijven hangen in herhaalde pogingen. Een praktische oplossing is om elke stap als een aparte functie te definiëren met een duidelijke invoer en uitvoer, en de volgende stap alleen te starten als de vorige succesvol is afgerond. Voeg een maximale doorlooptijd toe om oneindige loops te voorkomen.
Als je een systeem bouwt dat fouten moet kunnen opvangen zonder menselijke tussenkomst. De blog benadrukt dat architectuurkeuzes bepalen hoe fouten worden geïsoleerd. Een mogelijkheid is om per agent een ‘foutafhandelingsagent’ te koppelen die bij een time-out of hallucinatie een standaardantwoord geeft of de taak doorschuift naar een medewerker. Dit kost iets meer aan ontwerptijd, maar voorkomt dat een enkele fout de hele klantreis blokkeert.
Bron: n8n blog