Het verschil tussen een AI-agent die het in een demo goed doet en een die in de praktijk betrouwbaar werkt, zit hem niet in de prompt maar in de onderliggende architectuur. De keuze voor een sequentieel, parallel of failover-patroon bepaalt of je automatisering overeind blijft bij onverwachte input, API-timeouts of modelhallucinaties.

Wat er aan de hand is

In een blogpost op n8n.io wordt uitgelegd dat de echte uitdaging bij het bouwen van productieklare AI-agenten niet de code is, maar de structuur van de onderliggende logica. De auteur onderscheidt twee lagen: gedragspatronen (hoe een individuele agent denkt en beslist) en topologische patronen (hoe meerdere agenten samenwerken). De kernboodschap is dat een verkeerde architectuurkeuze faalmodi introduceert die geen enkele prompt engineering kan oplossen. Zo kan een autonome loop vastlopen waar een stap-voor-stap sequentie nodig is, en centraliseer je controle beter niet in een omgeving met hoge latentie.

Wat dit betekent

Voor ondernemers en professionals in het MKB betekent dit dat de keuze voor een AI-agent niet alleen draait om welk model je gebruikt, maar vooral om hoe je de taken structureert. Een sequentieel patroon is geschikt voor processen waarbij elke stap afhankelijk is van de vorige, zoals het verwerken van een bestelling waarbij eerst de voorraad wordt gecheckt, dan de betaling wordt verwerkt en pas daarna de verzending wordt gestart. Een parallel patroon werkt beter voor taken die onafhankelijk van elkaar kunnen worden uitgevoerd, zoals het tegelijkertijd controleren van meerdere leveranciers. Een failover-patroon is essentieel wanneer een enkele fout het hele proces niet mag laten stoppen, bijvoorbeeld bij een kritieke klantenservice-query die anders verloren gaat.

Hoe je dit kunt toepassen

Als je een webshop runt met orderverwerking. Overweeg om een sequentieel patroon te gebruiken voor het orderproces: eerst voorraadcheck, dan betalingsverificatie, dan verzendlabel aanmaken. Dit patroon voorkomt dat er een verzendlabel wordt gegenereerd voor een product dat niet op voorraad is. Je zou kunnen beginnen met het in kaart brengen van de afhankelijkheden in je huidige orderstroom en die vertalen naar een vaste volgorde van agent-stappen.

Als je een team aanstuurt dat klantenservice automatiseert. Een parallel patroon is een optie voor het gelijktijdig raadplegen van verschillende bronnen, zoals orderstatus, retourenbeleid en klanthistorie. De agent kan dan in één keer alle relevante informatie verzamelen voordat hij een antwoord formuleert. Dit versnelt de responstijd aanzienlijk. Een mogelijkheid is om te experimenteren met een eenvoudige test waarbij je twee of drie onafhankelijke databronnen tegelijk laat bevragen.

Als je werkt met kritieke bedrijfsprocessen, zoals betalingsverwerking of logistiek. Een failover-patroon is hier de aangewezen keuze. Als de primaire agent uitvalt door een API-timeout, neemt een tweede agent het over. Dit patroon vereist dat je dubbele systemen of redundante API-endpoints hebt. Overweeg om dit alleen in te zetten voor processen waar uitval direct omzet of klanttevredenheid kost, en begin met een eenvoudige fallback naar een handmatige melding.

Als je een hybride proces hebt, zoals een offerte-aanvraag die zowel standaard- als maatwerkproducten bevat. Je zou een combinatie van patronen kunnen overwegen: een sequentieel pad voor standaardproducten en een parallel pad voor het ophalen van maatwerkopties. De keuze voor het juiste patroon hangt af van de vraag of stappen van elkaar afhankelijk zijn. Een praktische eerste stap is het tekenen van een stroomdiagram van je proces en per stap noteren of deze kan worden uitgevoerd zonder de uitkomst van een andere stap.

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