AI-agenten in productie: bouw eerst de controlelus.

Een agent is geen chatbot met extra knoppen

Een chatbot geeft meestal een antwoord. Een agent krijgt een doel, kiest mogelijk meerdere stappen en kan via tools iets buiten het model doen. Denk aan een dossier opzoeken, een order controleren of een conceptactie klaarzetten.

Dat verschil is precies waarom productie ingewikkelder wordt. Een fout antwoord is vervelend; een verkeerde toolactie kan data wijzigen, een klant verkeerd informeren of een proces blokkeren. Daarom begin ik bij de controlelus: wat komt erin, welke context krijgt het model, welke actie mag eruit komen en hoe controleren we het resultaat?

Stap 1: schrijf de route uit vóór je een agent bouwt

Pak één terugkerende beslissing. Niet “beantwoord alle vragen van klanten”, maar bijvoorbeeld: “controleer of een orderverzoek compleet is en zet ontbrekende informatie klaar voor een medewerker”.

Schrijf vervolgens vijf dingen op:

• welke invoer de agent ontvangt;
• welke bronnen betrouwbaar genoeg zijn;
• welke uitkomst iemand nodig heeft;
• welke acties alleen mogen worden voorgesteld;
• wanneer de agent moet stoppen en een mens moet inschakelen.

Als je dit niet kunt opschrijven, is het probleem nog niet scherp genoeg om een agent aan te sturen.

Stap 2: geef context, maar maak er geen grabbelton van

Een model heeft niet automatisch de juiste bedrijfsinformatie. Je moet bepalen welke context het krijgt en hoe je controleert of die context relevant is. Bij RAG haal je bijvoorbeeld documenten op voordat het model antwoordt. Dat is geen garantie op waarheid; het is een manier om het model met actuele, geselecteerde informatie te laten werken.

Gebruik voor ieder document minimaal een bron-id, versie of datum. Laat de agent bij ontbrekende of tegenstrijdige informatie niet gokken. De juiste uitkomst kan dan zijn: “onvoldoende informatie, review nodig”.

Wil je dit deel verder uitwerken, lees dan ook mijn uitleg over context en LLM-workflows.

Stap 3: behandel tools als gevaarlijke uitgangen

Een tool-call is geen gewone tekst. Het is een verzoek om iets te lezen, te schrijven of te veranderen. Geef een agent daarom niet één algemene “doe alles”-tool, maar kleine tools met een duidelijke naam, invoerschema en bevoegdheid.

MCP kan een gestandaardiseerde manier bieden om AI-applicaties met externe systemen, data en tools te verbinden. Het protocol maakt de verbinding begrijpelijker, maar het is niet automatisch je autorisatielaag. De policy- of uitvoerlaag moet nog steeds controleren of deze gebruiker, deze actie en deze gegevens bij elkaar passen.

Gebruik in het begin drie actieniveaus:

• Lezen: mag automatisch, met logging en toegangscontrole.
• Voorstellen: de agent maakt een concept, een mens bevestigt.
• Wijzigen: alleen met expliciete policy, beperkte scope en een herstelpad.

Stap 4: maak evaluatie onderdeel van de bouw

Je kunt niet verbeteren wat je niet kunt vergelijken. Maak daarom een kleine set echte of zorgvuldig geanonimiseerde voorbeelden. Zet per voorbeeld de gewenste uitkomst, toegestane bron en grensgevallen erbij.

Een eenvoudige testset kan al vragen beantwoorden als:

• haalt de agent het juiste document op?
• verzint hij iets wanneer informatie ontbreekt?
• kiest hij de juiste tool?
• stopt hij bij een risicovolle actie?
• blijft de uitvoer bruikbaar als de tool faalt?

Bewaar deze voorbeelden buiten je prompt. Anders test je vooral of je prompt nog hetzelfde is. Evals zijn bedoeld om systeemgedrag herhaalbaar te meten; de OpenAI Evals-documentatie beschrijft dezelfde basisgedachte van testdata, beoordelingscriteria en runs.

Stap 5: zet menselijke controle op het juiste moment

Human-in-the-loop betekent niet dat iemand iedere zin moet goedkeuren. Het betekent dat je bepaalt bij welke onzekerheid, impact of bevoegdheid een mens nodig is.

Een praktische grens is:

uitkomst = agent.run(verzoek)

if not policy.allows(uitkomst.tool_call):
    return "review nodig"

if not evaluatie.is_betrouwbaar(uitkomst):
    return "review nodig"

return uitvoerder.execute(uitkomst.tool_call)

Dit is pseudocode, geen complete beveiligingslaag. Het laat wel de volgorde zien: het model stelt iets voor, een onafhankelijke policy controleert het en pas daarna mag een uitvoerder iets doen.

Stap 6: kijk naar het systeem, niet alleen naar het antwoord

Log voor iedere run minimaal een trace-id, gebruikte bronnen, toolkeuze, duur, fouttype en eindstatus. Log geen gevoelige inhoud omdat het toevallig makkelijk is. Maak vooraf duidelijk welke data je bewaart en hoe lang.

De belangrijkste productiemeting is niet alleen “was de tekst mooi?”. Kijk ook naar taakvoltooiing, menselijke correcties, veilige stops, doorlooptijd en kosten. Een agent die soms een prachtig antwoord geeft maar vaak niet weet wanneer hij moet stoppen, is nog niet productierijp.

Mijn startchecklist

• Kan ik het doel in één zin beschrijven?
• Zijn invoer, bronnen en gewenste uitvoer concreet?
• Heeft iedere tool een minimale bevoegdheid?
• Is er een veilige stop bij ontbrekende context?
• Heb ik grensgevallen om mee te testen?
• Kan ik terugzien waarom de agent een actie koos?
• Is duidelijk wanneer een mens beslist?
• Kan ik een fout herstellen zonder handmatig in een database te zoeken?

Conclusie

Autonomie is niet het startpunt van een goede agent. Controleerbaarheid is dat wel. Begin met een kleine route, beperkte tools, een echte testset en een duidelijke menselijke grens. Voeg pas meer autonomie toe wanneer je kunt aantonen dat het systeem in de normale én afwijkende gevallen doet wat je verwacht.

Wil je de volgende stap bekijken, lees dan hoe coding agents je ontwikkelworkflow veranderen of neem contact op over een AI-proces dat betrouwbaar moet werken.