AI agents in de praktijk: deel 3
Dit artikel is onderdeel van AI agents in de praktijk. In deel 1 leggen we uit wat AI agents zijn en hoe function calling werkt. In deel 2 behandelen we waar agents wel en niet voor werken. In dit deel: hoe bouw je er daadwerkelijk één?
Spoiler: de techniek is het makkelijke deel. Het echte werk zit ergens anders.
De technische drempel is laag
Met tools als n8n, Make.com of Langchain kun je in een middag een werkende agent hebben. Je kiest je tools, schrijft een prompt, verbindt de boel en je hebt iets dat dingen doet. Dat is geen overdrijving, de technische drempel is echt laag.
Het slechte nieuws? Dat is ook precies waar het gevaar zit. Begin daarom met no-code. Niet omdat het beter is, maar omdat je sneller leert waar de problemen zitten. Als je dat weet, kun je altijd nog naar een framework switchen.
Het maken van agents is niet het probleem. Het testen van agents, dat is het probleem. En zorgen dat ze doen wat jij wilt dat ze doen.
Elke agent heeft drie lagen
Voordat je begint met bouwen, moet je drie dingen bepalen. In deze volgorde.
Laag 1: welke tools heeft hij nodig?
De gereedschappen van een agent zitten in API’s. Toegang tot je mail, je CRM, Google Analytics, Slack, een database. De eerste vraag is simpel: welke externe diensten heeft hij nodig om zijn taak uit te voeren?
Hoe je die tools aanbiedt maakt uit. Met het Model Context Protocol (MCP) kun je tools op een gestandaardiseerde manier beschikbaar maken, zodat je agent dezelfde toolset kan gebruiken ongeacht het onderliggende model. Dat scheelt werk als je later van provider wisselt of meerdere modellen wilt inzetten.
Dit is ook het moment om na te denken over risico’s. Elke API die je toevoegt is een potentiële failure mode, en elke API met schrijfrechten is een potentieel probleem.
Laag 2: wat mag hij wel en niet?
Hier wordt het interessant. Je hebt grofweg twee soorten rechten:
Leesrechten
Data ophalen. Relatief veilig. De agent haalt informatie op uit je systemen en doet er iets mee. Je data gaat wel een model in, maar er verandert niets.
Schrijfrechten
Dingen aanpassen. Hier wordt het spannend: een mail versturen, een ticket aanmaken, een campagne starten, budget uitgeven. Dit is waar het mis kan gaan.
Ons advies: begin altijd met alleen leesrechten. Laat de agent data verzamelen en analyseren. Pas als dat stabiel werkt, voeg je schrijfrechten toe, één voor één.
Je wilt niet dat je eerste experiment met agents een AI is die geld mag uitgeven. Dat is vragen om problemen.
Laag 3: hoe instrueer je hem?
Dit is de system prompt. De eerste instructie die de agent krijgt voordat hij iets doet. Hier definieer je:
- Wie hij is: “Jij bent een marketingassistent voor bedrijf X”
- Wat hij moet doen: “Je analyseert campagnedata en maakt wekelijkse rapporten”
- Wat hij wel en niet mag: “Je mag geen mails versturen zonder goedkeuring”
- Hoe hij moet reageren: “Wees bondig, gebruik cijfers, geen marketingtaal”
Het probleem? Je moet hopen dat hij die prompt correct genoeg volgt, en dat jij die prompt goed genoeg hebt uitgelegd voor alle edge cases, wat bijna onmogelijk is.
Impliciete kennis is het echte obstakel
Dit is waar de meeste agentprojecten stranden, en bijna niemand praat erover.
Jouw organisatie heeft een manier van werken. Impliciete regels. Historische context. Dat zit in hoofden van mensen, niet in systemen.
Stel je vraagt een agent om Google Ads data te analyseren. Maar weet hij welk account hij moet gebruiken als je er meerdere hebt? Dat campagne X experimenteel is en campagne Y je core business? Dat vorige maand een storing was waardoor de data onbetrouwbaar is? Of wat vandaag de datum is?
Elk stukje missende context is een potentiële fout. En het vervelende: de agent weet niet dat hij context mist. Hij maakt aannames en gaat door. De output ziet er compleet uit, maar is gebouwd op een fundament van gaten.
Als mensen hun kennis niet kunnen overdragen aan het model, doet het model wat. En “wat” is zelden wat je bedoelde.
Voordat je een agent bouwt, moet je eerst inventariseren welke kennis nu in hoofden zit en een manier vinden om die kennis opvraagbaar te maken. Dat is vaak meer werk dan het bouwen van de agent zelf.
Van demo naar productie is waar het misgaat
Een werkende demo is snel gebouwd, maar een betrouwbare agent in productie is een ander verhaal. Er zijn drie dingen die bijna elk agentproject onderschat:
Modelupdates veranderen het gedrag
Modellen worden geüpdatet, en een nieuw model kan zich anders gedragen. Beter in benchmarks betekent niet beter voor jouw use case. Als je model verandert, moet je opnieuw testen. En als je niet kunt meten hoe goed de agent het doet, weet je ook niet of de update je workflow kapot heeft gemaakt.
Elke schrijfrecht is een risico
Als je een agent toegang geeft tot systemen, geef je een AI de keys to the castle. Stel jezelf vier vragen: wat is het worst case scenario, is het terug te draaien, wie is verantwoordelijk, en hoe detecteer je dat het mis is gegaan? Geen goed antwoord? Begin dan niet met schrijfrechten.
Zonder logging ben je blind
Als iets misgaat, moet je kunnen terugkijken wat de agent deed: welke API-calls, welke parameters, welke conclusies. Zonder goede logging zie je alleen de output, niet de tientallen stappen die eraan vooraf gingen.
Elke keer dat het model geüpdatet wordt, heb je eigenlijk een nieuwe medewerker die misschien subtiel anders werkt dan de vorige.
Conclusie: test voordat je bouwt
De moeilijkste vraag is niet hoe je een agent bouwt, maar hoe je weet of hij doet wat je wilt. Zonder een duidelijke manier om de output te beoordelen, is je agent geen tijdsbesparing maar een nieuwe bron van onzekerheid.
Begin met leesrechten
Laat de agent eerst data ophalen en analyseren. Pas als dat stabiel werkt, voeg je schrijfrechten toe.
Los het contextprobleem op
Inventariseer welke kennis nu in hoofden zit. Maak die opvraagbaar voordat je gaat bouwen.
Test obsessief
Definieer je scope absurd specifiek en test elke edge case. Met kapotte data, missende velden en extreme waarden.
Log alles
Elke API-call, elke beslissing. Zonder logging is debugging onmogelijk.
Voordat je begint met bouwen, stel jezelf deze twee vragen: hoe ga je testen of de agent doet wat je wilt, en wie gaat de output beoordelen? Als je daar geen antwoord op hebt, begin dan niet met bouwen maar met nadenken over die vragen.
En als je wilt weten waar agents wel en niet voor werken, lees dan eerst deel 2. Het red button probleem en het contextprobleem zijn essentiële achtergrond voor elke agent die je bouwt.
Hulp nodig bij het bouwen van agents?
We helpen bedrijven om AI agents te bouwen die daadwerkelijk werken. Van strategie tot implementatie, met de lessen die we zelf hebben geleerd.
