De meeste bedrijven waarmee we spreken, willen een AI-agent. Als we vragen wat die agent concreet doet, krijgen we antwoorden als "hij kan alles aan", "hij communiceert met leveranciers, bewaakt facturen én plant diensten in". Daar zit het probleem. Een agent die alles doet, doet gewoonlijk niets betrouwbaar.
Dit artikel is een praktisch stappenplan — geen theorie, maar een beslissingskader dat we hebben gevalideerd in echte deployments. We leiden u van de keuze van de eerste use-case via de definitie van tools, guardrails en evaluatie tot aan de geleidelijke uitbreiding van de agent. En we vertellen u ook wat u in het begin beter kunt vermijden.
Stap 1: Kies een smalle, goed afgebakende use-case
De meest voorkomende oorzaak van mislukking bij de eerste agent is niet technisch. Het is een te brede scope.
Een goede eerste use-case voldoet aan de volgende criteria:
- Heldere invoer en uitvoer — de agent ontvangt iets concreets en retourneert iets concreets (niet "verwerkt een e-mail")
- Verifieerbaar resultaat — u of het systeem kan vaststellen of de agent de juiste actie heeft uitgevoerd
- Afgebakende tools — maximaal 3–5 tools, niet "toegang tot alle systemen"
- Tolereerbare foutmarge — als de agent een fout maakt, kunt u die onderscheppen voordat er impact is
Voorbeelden die in de praktijk als eerste project werken: een agent die elke ochtend nieuwe klachten uit de helpdesk ophaalt, categoriseert en een samenvatting schrijft naar Excel of een tabel; een agent die nieuwe bestellingen in het systeem controleert en voorgeschreven API-stappen aanroept als een bestelling aan gedefinieerde voorwaarden voldoet; een agent die op verzoek relevante documentatie ophaalt uit de interne kennisbank via RAG over industriële documentatie en een antwoord formuleert.
Wat we afraden als eerste project: een agent met gelijktijdige toegang tot meerdere afdelingen, een agent die e-mails verstuurt of facturen uitgeeft zonder toezicht, of een agent waarbij niet duidelijk is hoe u succes meet.
Stap 2: Definieer tools — niet "wat de agent kan", maar "wat de agent mag"
Tools zijn het hart van een agent. Een agent zonder tools is slechts een chatbot; een agent met te ruime tools is een beveiligingsrisico.
Doorloop bij het definiëren van tools twee stappen:
Wat heeft de agent fysiek nodig? - Lezen (database, API, bestanden, vector-DB) - Schrijven (record bijwerken, bericht versturen, wegschrijven naar een systeem) - Berekening of transformatie (formaat converteren, samenvatten, classificeren)
Wat krijgt de agent toestemming om te doen? Dit is de cruciale stap die wordt overgeslagen. Elke tool heeft een expliciete scope: de agent mag records lezen uit tabel X, maar niet verwijderen. Hij mag API-endpoint Y aanroepen met een read-only sleutel. Hij mag schrijven naar sectie Z, maar niet historische records aanpassen.
Een goed principe voor de eerste agent: schrijfbewerkingen alleen via een HITL-gate — dus met menselijke goedkeuring vóór uitvoering. Human-in-the-loop bij agenten is geen complexe architectuur; in LangGraph is het één interrupt()-aanroep. Het voegt latency toe ter hoogte van de menselijke reactietijd, maar voorkomt onomkeerbare fouten.
Het schema van elke tool moet machinaal valideerbaar zijn. Als de agent misvormde JSON teruggeeft als argument voor een tool, moet u dat opvangen en opnieuw proberen — niet stilletjes negeren. Dat is geen edge case; in productie is dit een veelvoorkomende bron van problemen.
Stap 3: Kies een eenvoudige architectuur
Voor de eerste agent raden we de ReAct-lus aan — Reason, Act, Observe in een eenvoudige graaf. De reden is simpel: dit is de best debugbare architectuur.
Als u het artikel Architecturen van AI-agenten hebt gelezen, weet u dat er geavanceerdere patronen bestaan (Plan-and-Execute, Reflexion, multi-agent). Die zijn valide — maar niet voor het eerste project. Elke extra stap is een extra bron van potentiële fouten en een extra laag waarvan u niet weet wat er precies gebeurt.
Concreet aanbevolen stack:
- Framework:
LangGraph— graafgebaseerd, expliciete toestand, ingebouwde checkpointing; productiegewijs bewezen voor enterprise-deployments - Model: begin met een goedkoop, snel model (Haiku-tier, Flash-tier of een lokaal model via
Ollama); frontier-modellen (Opus, GPT) pas inschakelen wanneer de basislogica werkt - Geheugen: kortetermijncontext in de graaftoestand; voor een langere horizon een vector-DB — maar alleen als de eerste use-case dat echt vereist
Een grote vergissing aan het begin: het krachtigste en duurste model kiezen omdat "we de beste resultaten willen", en dan verbaasd zijn waarom de kosten onhoudbaar zijn. Een model is eenvoudig te vervangen. Architectuur en tools zijn dat veel minder.
Één praktisch detail: stel een maximaal aantal iteraties in de lus in. Een agent zonder limiet kan bij onverwachte invoer blijven ronddraaien en 's nachts duizenden tokens verbruiken. Een waarde van 10–15 stappen per taak is een verstandig beginpunt voor de meeste use-cases.
Stap 4: Guardrails — niet als filter, maar als architectuur
Guardrails voor AI-agenten is een onderwerp dat bij het eerste project wordt onderschat en later pijnlijk wordt ingehaald.
Guardrails zijn niet alleen een uitvoerfilter ("controleer of het antwoord niets slechts bevat"). Guardrails zijn een meerlaagse architectuur:
- 1.Inputvalidatie — wat komt er bij de agent binnen? Is dat het formaat dat de agent verwacht? Bevat de invoer mogelijk gevaarlijke instructies?
- 2.Intent-classificatie — als de agent vrije tekst van gebruikers ontvangt, moet de intentie worden geclassificeerd vóór doorgave aan de agentlus
- 3.Tool permission scope — zoals hierboven beschreven: elke tool heeft toestemmingen
- 4.HITL-gate voor schrijfbewerkingen — kritieke acties vereisen menselijke bevestiging
- 5.Uitvoerfilter — semantische controle van het antwoord vóór verzending
Voor de eerste agent in een interne omgeving (niet blootgesteld aan externe gebruikers) volstaat het om te beginnen met punten 3 en 4. Inputvalidatie en intent-classificatie zijn noodzakelijk als de agent invoer ontvangt van externe of onbekende bronnen.
Prompt injection — een aanval waarbij gevaarlijke inhoud in de invoer de agent overhaalt iets anders te doen dan bedoeld — staat volgens de OWASP LLM Top 10 op de eerste positie als meest voorkomende beveiligingsdreiging voor AI-applicaties. Als uw agent externe inhoud inlaadt (e-mails, webpagina's, bestanden van klanten), moet u dit risico actief meenemen.
Stap 5: Observability — zonder dit laat u de agent niet in productie
Dit is een regel waarvan we niet afwijken: een agent zonder observability is geen productie-agent. Het is een proof-of-concept.
Wat u concreet moet weten over elke uitvoering van de agent:
- Wat was de invoer en uitvoer
- Hoeveel iteraties van de lus zijn doorlopen
- Welke tools zijn aangeroepen, met welke argumenten, wat ze hebben teruggegeven
- Waar een fout is opgetreden (als dat het geval was) en waarom de agent een bepaalde actie heeft gekozen
Tools die dit bieden: Langfuse (framework-agnostisch, self-hostable), LangSmith (diepe integratie met LangGraph), Arize Phoenix (OpenTelemetry-gebaseerd, geavanceerde eval-metrics). Observability van AI-agenten is vandaag een volwassen domein — er is geen reden om dit van nul op te bouwen.
Concreet voordeel in de praktijk: bij één deployment voor een klant uit de logistiek ontdekten we via traces dat de agent 94 % van de gevallen correct categoriseerde, maar voor één categorie consequent de tool aanriep met een foutief argument. Zonder observability hadden we dit pas ontdekt na tientallen foutieve records in het systeem.
Stap 6: Eval — hoe weet u dat de agent correct functioneert?
Eval (evaluatie) is de stap die bij het eerste project het vaakst wordt overgeslagen. Het gevolg: we weten niet of een wijziging in de prompt, het model of de tools de zaken heeft verbeterd of verslechterd.
Voor de eerste agent volstaat een eenvoudig eval-harness:
- Stel 20–50 testgevallen samen met gedefinieerde invoer en verwachte uitvoer of actie
- Voer de agent uit op deze gevallen na elke grotere wijziging
- Volg minimaal twee metrics: task completion rate (heeft de agent de taak voltooid?) en tool call accuracy (heeft de agent de juiste tools aangeroepen met de juiste argumenten?)
U hoeft niet meteen een complex eval-framework te deployen. Een script dat de agent uitvoert over de testset en een score uitprint, is beter dan geen enkele eval. Naarmate het systeem groeit, wordt evaluatie van RAG- en LLM-applicaties verfijnder — maar de basis blijft dezelfde: een referentieset hebben en daartegenover meten.
Wat u bij de eerste agent moet vermijden
Uit ervaring met deployments — dit zijn de meest voorkomende fouten die een project vertragen of doen stranden:
Te veel tools vanaf het begin. Elke tool is een extra bron van storingen. Begin met drie, breid uit op basis van werkelijke behoefte.
Geen HITL voor schrijfbewerkingen. De eerste schrijfactie die de agent fout uitvoert zonder mogelijkheid tot onderschepping, beëindigt gewoonlijk het project. Voeg goedkeuring toe — u kunt die later verwijderen als u vertrouwen hebt in de betrouwbaarheid.
Een multi-agent systeem als eerste stap. Een multi-agent systeem in de praktijk heeft zin wanneer één agent niet volstaat. Maar als u nog niet weet wat één agent fout doet, maakt het toevoegen van meer agenten de verwarring groter, niet kleiner.
Het model als de belangrijkste variabele. We hebben het meerdere keren gehoord: "We proberen GPT-5, dat zal de problemen zeker oplossen." In de praktijk komt de meerderheid van de problemen voort uit een slechte definitie van tools, ontbrekende validatie of een onduidelijke scope — niet uit de kwaliteit van het model. Los de architectuur op, niet het model.
Geen maximale limieten. Een agent zonder limiet op het aantal stappen, zonder timeout en zonder kostenalert kan 's nachts duizenden calls genereren. Stel limieten in vanaf dag één.
Geleidelijke uitbreiding: van prototype naar productie
De eerste werkende agent is een prototype. De weg naar productie vereist een aantal expliciete stappen:
- 1.Eval over de testset — minimaal 20–50 gevallen, task completion rate > 85 % als minimumvereiste
- 2.Shadow mode — de agent draait parallel aan het bestaande proces, maar grijpt niet in; u vergelijkt de uitvoer
- 3.HITL voor alle schrijfbewerkingen — in de eerste productiefase keurt een mens elke actie goed
- 4.Observability live — traces moeten beschikbaar zijn vanaf de eerste dag in productie
- 5.Geleidelijke afbouw van HITL — na 2–4 weken met goede metrics kunt u HITL verwijderen voor laagrisico-acties
Uitbreiding van scope (nieuwe tools, nieuwe use-cases) is altijd een iteratie van dezelfde cyclus: definieer, test in shadow mode, roll gefaseerd uit, volg de metrics.
Veelgestelde vragen
Welk model kiest u voor de eerste agent?
Begin met een goedkoop en snel model — Haiku- of Flash-tier, of een lokaal open-weight model zoals Ollama met Qwen of Llama. Schakel frontier-modellen (Opus, GPT) pas in wanneer de basislogica werkt en u precies weet waar het model tekortschiet. Een model vervangen is eenvoudig; een architectuur repareren niet.
Hoeveel tools mag de eerste agent hebben?
We raden maximaal 3–5 tools in de eerste versie aan. Elke tool is een extra bron van storingen en iets extra's om te testen. Drie goed geteste tools zijn beter dan tien met onduidelijke grenzen.
Moet ik LangGraph of een ander framework gebruiken?
Het is geen verplichting. Eigen code geeft volledige controle en soms minder abstractie dan nodig is. De reden waarom we LangGraph aanbevelen voor de eerste productie-deployments is de ingebouwde checkpointing, HITL interrupt() en goede traces — anders bouwt u die zelf van nul op.
Wanneer is een overstap naar multi-agent architectuur zinvol?
Wanneer één agent consistent tekortschiet — doorgaans door een te brede taakscope of de behoefte aan parallelle verwerking. Als een agent sequentieel 15 stappen uitvoert waarvan een aantal parallel zou kunnen lopen, is het tijd voor een multi-agent aanpak. Maar dat is het tweede of derde project, niet het eerste.
Hoe schat u de kosten van een agent in productie in?
De sleutelvariabele is niet alleen de prijs van het model, maar ook het aantal iteraties van de lus per taak en de retry rate. Als een agent gemiddeld 5 stappen uitvoert en de retry rate 12 % bedraagt, is het werkelijke aantal calls 12 % hoger — en in meerstaps-pipelines neemt deze overhead verder toe. Een uitgebreider kader voor kostenscenario's vindt u in het artikel Kosten van een AI-agent in productie.
*MP Industrial Solutions helpt bedrijven bij het definiëren, ontwerpen en deployen van hun eerste AI-agent — van de keuze van de use-case via de technische architectuur tot en met de productie-uitrol met observability en guardrails. Als u de eerste stap overweegt, beoordelen we graag uw concrete geval tijdens een vrijblijvend kennismakingsgesprek.*