Promptpatronen voor AI-agents: Tools aanroepen, planning en foutafhandeling

Het bouwen van autonome AI-agents vraagt om een heel andere benadering dan traditionele systeemprompts voor statische chatbots. Waar een standaard LLM vooral reageert op een enkele invoer, moet een agent iteratief redeneren, externe tools aanroepen, resultaten interpreteren en beslissen wanneer een taak volbracht is. Zonder strakke promptpatronen ontspoort een agent al snel in eindeloze lussen, maakt hij suboptimale toolkeuzes of loopt hij vast bij de eerste de beste fout.

In dit artikel behandelen we de belangrijkste patronen om agents betrouwbaar te laten functioneren. We baseren ons hierbij op bewezen technieken uit de praktijk van prompt engineering en agent-architectuur.

1. Het beschrijven van tools: Helderheid boven alles

Een agent is zo slim als de gereedschappen die hij tot zijn beschikking heeft én de manier waarop deze gereedschappen aan hem worden gepresenteerd. Veel ontwikkelaars onderschatten het belang van semantische precisie in tool-definities. Als een model niet exact begrijpt wat een tool doet, wanneer deze gebruikt moet worden en wat de verwachte invoer is, zal de agent onvoorspelbaar gedrag vertonen.

Bij het ontwerpen van tool-beschrijvingen in je prompt of schema's moet je letten op:

• Functienaam en domein: Gebruik actiegerichte namen zoals search_customer_database in plaats van vage benamingen zoals tool_1 of db_query.
• Explicitering van randvoorwaarden: Geef in de omschrijving aan wanneer je de tool wel en nadrukkelijk niet moet gebruiken.
• Typing en formaten: Definieer veldtypes streng. Vermeld bij datums altijd het verwachte formaat (bijv. YYYY-MM-DD).

Voor bredere concepten over hoe je modellen stuurt in complexe workflows kun je ook onze gids over prompt technieken raadplegen.

# Voorbeeld van een robuuste tool-beschrijving binnen een systeemprompt
TOOLS:
1. `calculate_shipping_costs`: 
   - Beschrijving: Berekent de verzendkosten op basis van gewicht en bestemming. Gebruik deze ALLEEN nadat het gewicht bekend is via de order-API.
   - Argumenten: 
     - weight_kg (float): Het gewicht in kilogrammen.
     - country_code (string): ISO 3166-1 alpha-2 landcode (bijv. 'NL', 'BE').
   - Waarschuwing: Gebruik deze tool niet voor internationale zendingen buiten de EU.

2. Scheiden van planning en uitvoering

Een veelgemaakte fout in agent-prompts is het vragen om directe actie zonder voorafgaande reflectie. Het model probeert dan tegelijkertijd te plannen en uit te voeren, wat resulteert in chaotisch gedrag zodra een stap mislukt.

Het patroon van ReAct (Reason + Act) of expliciete planning dwingt de agent om eerst een stappenplan op te stellen in een afgescheiden denkblok voordat hij overgaat tot een tool-aanroep. Dit sluit nauw aan bij geavanceerde methoden zoals prompt chaining.

Gebruik gedurende het proces altijd de volgende structuur in je antwoord:
[PLAN]: Wat is je volgende logische stap en waarom?
[ACTIE]: Welke tool roep je aan met welke parameters? (Laat leeg als je direct antwoord geeft)
[REDENERING]: Korte motivatie van de keuze.

Wijk hier niet van af. Als je alle informatie hebt, sla je [ACTIE] over en geef je direct het eindantwoord.

3. Foutafhandeling teruggeven aan het model

Wanneer een tool een foutmelding retourneert (bijvoorbeeld een 404 Not Found of een ongeldige API-parameter), stoppen slecht geconfigureerde agents vaak abrupt of raken ze in paniek. Een robuuste agent moet een foutmelding niet zien als een eindpunt, maar als nieuwe invoer om zijn strategie bij te stellen.

Instructeer de agent expliciet in de systeemprompt hoe om te gaan met uitzonderingen:

FOUTAFHANDELING:
Ontvang je een foutmelding van een tool? Voer dan de volgende stappen uit:
1. Analyseer de foutmelding in je [PLAN]-sectie.
2. Bepaal of de fout veroorzaakt werd door een onjuiste parameter (bijv. typefout in landcode).
3. Corrigeer de parameter en probeer de tool maximaal 1 keer opnieuw aan te roepen.
4. Blijft de fout aanhouden? Val dan terug op een alternatieve tool of vraag de gebruiker om opheldering. Geef nooit een ruwe stacktrace terug aan de eindgebruiker.

4. Het begrenzen van stappen en expliciete stopvoorwaarden

LLM's hebben de neiging om door te gaan zolang ze denken dat er nog iets te verbeteren valt. Zonder strikte grenzen leidt dit tot oneindige lussen (infinite loops) waarin de agent dezelfde tool blijft aanroepen met minimale variaties in parameters. Dit kost onnodige tokens en tijd.

Je kunt dit tegengaan door twee mechanismen in te bouwen:

• Hard limiet op stappen: Geef in de prompt mee hoeveel iteraties maximaal zijn toegestaan (bijv. "Je mag maximaal 5 tool-aanroepen doen voor deze taak").
• Expliciete stopvoorwaarden: Definieer glashelder wanneer het doel bereikt is.

STOPVOORWAARDEN:
Je stopt onmiddellijk met het aanroepen van tools zodra:
- Je het definitieve antwoord hebt gevonden dat direct antwoord geeft op de vraag van de gebruiker.
- Je de maximale limiet van 5 stappen hebt bereikt. Geef in dat geval de beste poging tot dan toe weer met een waarschuwing dat het proces is afgebroken.
- Een tool tweemaal achter elkaar dezelfde foutmelding geeft.

5. Waarom minder autonomie vaak beter presteert

Er bestaat een hardnekkige misvatting dat een agent beter is naarmate hij meer vrijheid krijgt. In de praktijk zien we vaak het omgekeerde: over-geautonomeerde agents presteren slechter. Als je een model te veel gereedschappen geeft en te vage doelen ("Los dit probleem maar op"), raakt het model verlamd door keuzestress of hallucineert het irrelevante workflows.

Het principe van minimale noodzakelijke autonomie houdt in dat je de speelruimte van een agent zo klein mogelijk houdt:

• Geef alleen toegang tot de tools die absoluut noodzakelijk zijn voor de specifieke subtaak.
• Gebruik voorspelbare paden waar mogelijk, en zet agents alleen in voor dynamische vertakkingen.
• Beperk de complexiteit van de prompt door taken op te hakken in kleinere, opeenvolgende ketens.

Voor diepgaande achtergronden over het structureren van complexe informatiestromen raden we ook aan om te lezen over RAG voor beginners, waar het filteren van irrelevante context hand in hand gaat met het effectief aansturen van taalmodellen.

Samenvatting

Het bouwen van productieklare agents vraagt om discipline in prompt design. Door tools uiterst specifiek te beschrijven, planning en uitvoering te scheiden, fouten op te vangen als feedback, en harde grenzen te stellen aan het aantal stappen, transformeer je een grillig taalmodel in een voorspelbare, krachtige softwarecomponent.