AI-agents bouwen: patronen die in de praktijk werken

Geschatte leestijd: 9 minuten

Inhoudsopgave

1. Wat zijn AI-agents?
2. Wanneer zet je wel of geen agent in?
3. Wanneer en hoe gebruik je frameworks?
4. Bouwstenen: van losse aanroep tot volledige agent
5. Patronen combineren en aanpassen
6. Samenvatting: drie principes
7. In de praktijk: twee toepassingen
8. Prompt engineering voor je tools
9. Veelgestelde vragen

Wij bouwen zelf AI-agents voor klanten en zien vaak hetzelfde patroon: het beste resultaat komt niet uit een ingewikkeld framework, maar uit een paar eenvoudige, herbruikbare bouwblokken. Anthropic trok die conclusie na een jaar samenwerken met tientallen teams die LLM-agents in productie namen.

In dit artikel zetten we die inzichten op een rij, aangevuld met wat wij bij And AI zelf tegenkomen als we agents bouwen voor Nederlandse bedrijven.

Wat zijn AI-agents?

Er bestaat geen eenduidige definitie van "agent". Sommige teams noemen elk systeem dat zelfstandig meerdere stappen zet een agent. Andere teams reserveren de term voor systemen die volledig autonoom werken, zonder vast script. Anthropic maakt een helder onderscheid tussen twee soorten agentic systemen:

• Workflows: systemen waarin een taalmodel en losse tools via een vooraf bepaald pad worden aangestuurd.
• Agents: systemen waarin het taalmodel zelf bepaalt welke stappen het zet en welke tools het inzet.

Het verschil is niet alleen theoretisch. Een workflow is voorspelbaar en makkelijk te testen. Een agent is flexibeler, maar ook lastiger te controleren.

Wanneer zet je wel of geen agent in?

Begin bij de simpelste oplossing die het werk doet, en voeg pas complexiteit toe als dat nodig blijkt. Dat betekent vaak: geen agent bouwen. Agentic systemen kosten meer tijd en geld per taak dan een directe aanroep van een taalmodel, in ruil voor betere prestaties op complexere taken. Die ruil is niet altijd het waard.

Voor taken met een vaste structuur werkt een workflow meestal beter: voorspelbaar en consistent. Een agent is de betere keuze zodra flexibiliteit en zelfstandige besluitvorming zwaarder wegen dan controle. Voor veel toepassingen is één goed ingerichte aanroep van een taalmodel, met de juiste voorbeelden en context, trouwens al genoeg.

Wanneer en hoe gebruik je frameworks?

Er zijn genoeg frameworks die het bouwen van agentic systemen makkelijker maken, van SDK's tot drag-and-drop workflowbouwers. Ze nemen standaardwerk uit handen: een taalmodel aanroepen, tools definiëren en uitkomsten aan elkaar knopen.

Het nadeel: frameworks voegen een laag abstractie toe die precies verbergt wat er onder de motorkap gebeurt, waardoor debuggen lastiger wordt. Ze nodigen ook uit tot meer complexiteit dan nodig is. Ons advies: begin met de API van het taalmodel rechtstreeks. Veel patronen vragen maar een paar regels code. Kies je toch voor een framework, zorg dan dat je begrijpt wat er onder de oppervlakte gebeurt. Verkeerde aannames over de werking zijn een veelvoorkomende foutbron.

Bouwstenen: van losse aanroep tot volledige agent

De aangevulde taalmodel

De basis van elk agentic systeem is een taalmodel met extra vermogens: het kan zoekopdrachten formuleren, tools kiezen en zelf bepalen welke informatie het onthoudt. Richt deze mogelijkheden toe op je eigen use case en zorg voor een heldere, goed gedocumenteerde interface tussen het model en de tools. Het Model Context Protocol is daarvoor een bruikbare standaard: het koppelt een taalmodel aan een groeiend aanbod van externe tools via één simpele client.

Workflow: prompt chaining

Prompt chaining knipt een taak op in een reeks stappen, waarbij elke aanroep de uitkomst van de vorige verwerkt. Tussen de stappen kun je programmatische controles inbouwen om te checken of het proces nog op koers ligt.

Deze aanpak werkt goed als een taak zich netjes laat opdelen in vaste deeltaken en je liever iets meer tijd inlevert voor hogere nauwkeurigheid. Denk aan het schrijven van marketingtekst die je vervolgens vertaalt, of het opstellen van een overzicht dat je eerst toetst voordat je het volledige document uitschrijft.

Workflow: routing

Routing classificeert een binnenkomende vraag en stuurt die door naar een gespecialiseerde vervolgstap. Dat voorkomt dat een prompt die geoptimaliseerd is voor het ene type vraag, slechter gaat presteren op een ander type.

Denk aan het verdelen van klantvragen (algemene vragen, terugbetalingen, technische support) over aparte processen en tools, of het sturen van eenvoudige vragen naar een kleiner, goedkoper model en lastige vragen naar een zwaarder model.

Workflow: parallellisatie

Bij parallellisatie werken meerdere aanroepen tegelijk aan een taak, waarna de uitkomsten programmatisch worden samengevoegd. Dat gebeurt op twee manieren: sectioning splitst een taak in onafhankelijke deeltaken die tegelijk lopen, voting laat dezelfde taak meerdere keren lopen voor verschillende uitkomsten.

Sectioning werkt goed voor guardrails, waarbij één aanroep de vraag beantwoordt en een tweede los controleert op ongepaste inhoud. Voting is bruikbaar bij het controleren van code op kwetsbaarheden met meerdere onafhankelijke doorlopen, of bij het beoordelen van content waarbij je meerdere stemmen wilt wegen tegen elkaar.

Workflow: orchestrator-workers

Bij dit patroon breekt een centrale aanroep de taak zelf op, verdeelt de deeltaken over losse "worker"-aanroepen en voegt de resultaten weer samen. Het verschil met parallellisatie: de deeltaken liggen niet vooraf vast, de orchestrator bepaalt ze op basis van de specifieke input.

Dit patroon past bij complexe taken waarbij je vooraf niet kunt voorspellen welke deeltaken nodig zijn, zoals een codewijziging die meerdere bestanden raakt, of een zoektaak die informatie uit uiteenlopende bronnen moet verzamelen.

Workflow: evaluator-optimizer

Hier genereert één aanroep een antwoord, terwijl een tweede aanroep dat antwoord beoordeelt en feedback teruggeeft, in een lus. Dit werkt goed zodra je duidelijke beoordelingscriteria hebt en itereren aantoonbaar waarde toevoegt: bijvoorbeeld literaire vertaling waarbij een eerste versie nuances mist die een tweede beoordeling wel oppikt, of een zoektaak die meerdere rondes nodig heeft voordat het beeld compleet is.

Agents

Agents komen in productie naarmate taalmodellen beter worden in complexe input begrijpen, redeneren en plannen, tools betrouwbaar inzetten en herstellen van fouten. Een agent start met een opdracht of gesprek met de gebruiker, plant vervolgens zelfstandig en voert die planning uit, en keert terug naar de gebruiker voor extra informatie of een oordeel wanneer nodig.

Belangrijk tijdens de uitvoering: de agent moet op elk moment grond onder de voeten krijgen uit de omgeving zelf, bijvoorbeeld via resultaten van een toolaanroep of het uitvoeren van code, om de eigen voortgang te kunnen beoordelen. Bouw checkpoints en stopcondities in, zoals een maximumaantal stappen, om controle te houden.

Zet een agent in voor open taken waarbij je vooraf niet kunt voorspellen hoeveel stappen nodig zijn en waarbij een vast pad niet werkt. Daar staat tegenover: hogere kosten en het risico dat kleine fouten zich opstapelen. Test uitgebreid in een afgeschermde omgeving en bouw de juiste vangrails in voordat een agent los mag op productiedata.

Patronen combineren en aanpassen

Geen van deze bouwblokken is een blauwdruk. Het zijn herkenbare patronen die je naar eigen inzicht kunt combineren en aanpassen aan je eigen situatie. De sleutel tot succes is, zoals bij elke toepassing van een taalmodel, het meten van de prestaties en het bijsturen op basis daarvan. Voeg pas complexiteit toe zodra die aantoonbaar iets oplevert.

Samenvatting: drie principes

Succes met taalmodellen zit hem niet in het meest verfijnde systeem, maar in het juiste systeem voor jouw situatie. Begin met een eenvoudige prompt, optimaliseer die op basis van gedegen evaluatie, en voeg pas een agentic systeem toe zodra simpelere oplossingen tekortschieten. Drie principes helpen daarbij:

1. Houd het ontwerp van je agent eenvoudig.
2. Maak de planning van de agent zichtbaar voor de gebruiker.
3. Besteed net zoveel aandacht aan de interface tussen agent en tools als je normaal aan documentatie en testen zou besteden.

Een framework helpt om snel te starten, maar wees niet bang om lagen abstractie weg te halen zodra je richting productie beweegt. Zo bouw je agents die niet alleen krachtig zijn, maar ook betrouwbaar, onderhoudbaar en te vertrouwen voor de mensen die ermee werken.

In de praktijk: twee toepassingen

Twee toepassingen springen eruit doordat ze aan dezelfde voorwaarden voldoen: een combinatie van gesprek en actie, duidelijke succescriteria, ruimte voor feedback en zinvol menselijk toezicht.

Klantenservice

Klantenservice combineert een vertrouwde chatinterface met extra vermogens via tools. Dat past goed bij een meer open agent: het gesprek volgt van nature een logische flow, tools kunnen klantdata, bestelgeschiedenis en kennisbank-artikelen ophalen, acties zoals terugbetalingen of ticketupdates kunnen programmatisch worden afgehandeld, en succes is direct meetbaar aan de hand van opgeloste vragen.

Coding agents

Softwareontwikkeling leent zich bij uitstek voor agents: codeoplossingen zijn te verifiëren met geautomatiseerde tests, een agent kan itereren op basis van testresultaten, het probleemgebied is goed afgebakend en de kwaliteit van de output is objectief te meten. Automatische tests helpen de functionaliteit te controleren, maar menselijke review blijft nodig om te checken of een oplossing ook past bij de bredere eisen van het systeem.

Prompt engineering voor je tools

Welk agentic systeem je ook bouwt, tools zijn meestal een belangrijk onderdeel. Tooldefinities verdienen net zoveel aandacht in je prompt als de rest van de instructie. Voor eenzelfde actie bestaan vaak meerdere formaten: je kunt een bestandswijziging bijvoorbeeld specificeren als een diff, of door het hele bestand opnieuw te schrijven. Sommige formaten zijn voor een taalmodel simpelweg lastiger te produceren dan andere.

Een paar richtlijnen bij het kiezen van een toolformaat:

• Geef het model genoeg ruimte om na te denken voordat het zichzelf vastzet.
• Houd het formaat dicht bij wat het model van nature al veel is tegengekomen in tekst.
• Voorkom overbodige overhead, zoals het precies moeten bijhouden van regelnummers of het moeten escapen van tekens.

Denk aan de tijd die in een goede interface voor mensen gaat zitten, en investeer evenveel in de interface tussen agent en computer. Zet jezelf in de schoenen van het model: is uit de beschrijving en de parameters meteen duidelijk hoe je een tool gebruikt? Geef voorbeelden, randgevallen en duidelijke grenzen tussen tools mee. Verander namen en beschrijvingen van parameters totdat ze vanzelfsprekend zijn, alsof je een docstring schrijft voor een net binnengekomen collega. Test hoe het model je tools daadwerkelijk gebruikt, en haal fouten zo veel mogelijk uit de tool zelf.

Veelgestelde vragen

Wat is het verschil tussen een workflow en een agent? +

Een workflow stuurt een taalmodel en tools via een vooraf vastgelegd pad aan. Een agent bepaalt zelf, stap voor stap, welke acties nodig zijn en welke tools daarbij horen. Workflows zijn voorspelbaarder, agents zijn flexibeler.

Wanneer moet je geen agent bouwen? +

Als een directe aanroep van een taalmodel, eventueel met wat extra context, de taak al goed genoeg oplost. Een agent kost meer tijd en geld per taak, dus die investering moet zich terugverdienen in betere resultaten.

Welke risico's horen bij het gebruik van agents? +

De autonomie van een agent brengt hogere kosten met zich mee en het risico dat kleine fouten zich opstapelen tot grotere problemen. Test daarom uitgebreid in een afgeschermde omgeving en bouw stopcondities en menselijke controlepunten in voordat een agent op productiedata werkt.

Heb je een framework nodig om een agent te bouwen? +

Niet per se. Veel patronen zijn met een paar regels code te bouwen via de API van een taalmodel. Een framework kan helpen om snel te starten, zolang je begrijpt wat er onder de motorkap gebeurt.