Het kiezen van de juiste architectuur voor een AI-agent is bepalend voor of je automatisering betrouwbaar werkt of vastloopt bij de eerste onverwachte input. De structuur van je agent bepaalt hoe fouten worden opgevangen, hoe snel taken worden uitgevoerd en of het systeem schaalbaar is. Voor een MKB’er betekent dit: de verkeerde keuze leidt tot dure stilstand, de juiste keuze tot een systeem dat je kunt vertrouwen.

Wat er aan de hand is

In een blogpost op de website van n8n worden de belangrijkste architectuurpatronen voor AI-agents uitgelegd. De kern is dat er twee lagen zijn waarop je keuzes moet maken: gedragspatronen (hoe één agent denkt en handelt) en topologische patronen (hoe meerdere agenten samenwerken). De auteur stelt dat de grootste fout die ontwikkelaars maken, is dat ze zich blindstaren op de code die een model aanstuurt, terwijl de echte uitdaging zit in hoe data stroomt en waar beslissingen worden genomen. Een verkeerd gekozen patroon kan volgens de post leiden tot storingen die geen enkele aanpassing in de prompt kan oplossen. Het artikel onderscheidt onder andere het patroon van ‘tool use’, waarbij een agent eenvoudige, directe acties uitvoert zoals het controleren van een voorraad of het bijwerken van een CRM-rij. Dit patroon is snel en heeft lage latentie, maar is volledig afhankelijk van het vermogen van het model om een strikt schema te volgen. De faalmodus hier is dat het model niet-bestaande tools aanroept of ongeldige argumenten meegeeft, vooral bij oudere modellen of zelf-gehoste systemen.

Wat dit betekent

Voor een MKB’er betekent dit dat de keuze voor een architectuurpatroon directe gevolgen heeft voor de betrouwbaarheid van je automatisering. Als je een eenvoudig proces automatiseert, zoals het ophalen van een actuele voorraadstand uit je webshop, dan is het ‘tool use’-patroon een veilige en snelle keuze. Maar als je een complexe workflow bouwt met meerdere stappen, zoals een klantenservice-robot die een bestelling moet annuleren, een terugbetaling moet starten én een e-mail moet sturen, dan heb je een ander patroon nodig. De impact is dat je niet alleen naar de functionaliteit moet kijken, maar ook naar hoe fouten worden afgehandeld. Een enkele hallucinatie of een API-time-out mag niet je hele proces laten vastlopen. Voor bedrijven met een lage fouttolerantie, zoals een boekhoudkundige verwerking, is een patroon met meer controle en stapsgewijze uitvoering noodzakelijk. Voor snelle, eenmalige acties, zoals het genereren van een productbeschrijving, is snelheid belangrijker dan foutloosheid.

Hoe je dit kunt toepassen

Als je een webshop runt en voorraadstanden automatisch wilt bijwerken. Je zou kunnen beginnen met het ‘tool use’-patroon. Dit is het eenvoudigste patroon: de agent krijgt een duidelijke functie om een API aan te roepen die de voorraad uitleest. Het voordeel is dat het snel is en weinig rekenkracht kost. Een optie is om dit patroon alleen te gebruiken voor acties die geen grote gevolgen hebben bij een fout, zoals het ophalen van data. Als de agent een verkeerde waarde teruggeeft, is dat vervelend maar niet rampzalig.

Als je een team aanstuurt en een AI-agent inzet voor het plannen van afspraken. Overweeg om een stapsgewijs patroon te gebruiken in plaats van een volledig autonome loop. In een autonome loop kan de agent zelf beslissen welke stap hij als volgende zet. Dat is flexibel, maar ook risicovol. Een stapsgewijs patroon dwingt de agent om elke stap te doorlopen: eerst checken of de klant bestaat, dan de beschikbaarheid opvragen, dan een voorstel doen. Dit is trager, maar veel betrouwbaarder voor processen waar fouten niet mogen voorkomen.

Als je in de logistiek werkt en meerdere agenten wilt laten samenwerken. Een mogelijkheid is om een centraal coördinatiepunt te vermijden. Het artikel waarschuwt dat centraliseren van controle in een omgeving met hoge latentie elke overdracht kan vertragen. In plaats daarvan kun je overwegen om agenten onafhankelijk van elkaar te laten werken en alleen bij specifieke overdrachtspunten te laten communiceren. Dit verhoogt de fouttolerantie omdat een vastgelopen agent niet het hele systeem blokkeert.

Als je een klein budget hebt en een eenvoudige automatisering wilt bouwen. Begin met het eenvoudigste patroon dat werkt voor jouw use case. Het ‘tool use’-patroon is het goedkoopst in termen van ontwikkeltijd en rekenkracht. Je kunt dit patroon later uitbreiden naar een complexere structuur als je merkt dat de foutgevoeligheid te hoog is. Een optie is om te testen met een niet-kritisch proces, zoals het genereren van social media posts, voordat je het inzet voor klantgerichte processen.

Als je een proces automatiseert waar fouten grote financiële gevolgen hebben. Overweeg om een patroon te kiezen met expliciete foutafhandeling. Het artikel noemt dat een verkeerd patroon faalmodi introduceert die geen prompt engineering kan oplossen. In de praktijk betekent dit dat je een aparte stap moet inbouwen die controleert of de output van de agent logisch is voordat deze wordt uitgevoerd. Bijvoorbeeld: een agent die een factuur moet genereren, moet eerst een validatiestap doorlopen die controleert of het bedrag en de klantgegevens kloppen.

Bron: n8n blog (https://blog.n8n.io/ai-agent-architecture-patterns/)