Waarom betere AI-agents soms minder tools nodig hebben
De valkuil: elke agent-fout oplossen met nóg een tool
Veel AI-agent projecten beginnen logisch. Een team bouwt een agent voor een afgebakende taak, ziet dat de output nog niet betrouwbaar genoeg is en voegt een extra tool toe. Daarna komt er memory bij, vervolgens toegang tot een extra databron, daarna een koppeling met een intern systeem en daarna een fallback-route. Op papier lijkt de agent steeds capabeler. In de praktijk wordt het gedrag vaak juist moeilijker te voorspellen.
Dat patroon is herkenbaar voor AI-teams die van prototype naar productie willen. In een demo werkt een agent indrukwekkend, omdat de context gecontroleerd is. Zodra echte gebruikers, rommelige data en wisselende uitzonderingen erbij komen, blijkt dat elke extra mogelijkheid ook een extra faalpad is. De agent moet niet alleen weten wat hij kan doen, maar vooral wanneer hij iets níet moet doen.
De interessante les uit recente discussies rond agent-ontwerp is daarom niet dat je altijd radicaal moet schrappen. De les is dat tools geen gratis vermogen zijn. Elke tool die je toevoegt, wordt een onderhoudsverplichting. Als niemand kan uitleggen waarom een tool bestaat, wanneer hij gebruikt moet worden, hoe succes wordt gemeten en wie eigenaar is van de foutafhandeling, bouw je waarschijnlijk vooral complexiteit rond je model.
Wat een AI-harness eigenlijk is
Bij Funnel Adviseur gebruiken we het woord harness voor de laag rond het AI-model. Het model is belangrijk, maar het werkt nooit in isolatie. Daaromheen zitten prompts, tooldefinities, toegangsregels, contextvensters, routing, evaluaties, logging, permissies, escalatieregels en beheerafspraken. Die combinatie bepaalt of een agent in een echte bedrijfsomgeving bruikbaar wordt.
Een betere onderliggende modelversie lost die laag niet automatisch op. Sterker nog: wanneer modelgedrag verandert, kan een bestaande agent-flow ineens anders reageren op dezelfde toolbeschrijving of dezelfde context. Ook bedrijfsdata verandert. Productinformatie wordt aangepast, CRM-velden krijgen een andere betekenis, API-output wijzigt, rechtenstructuren veranderen en gebruikers gaan andere vragen stellen zodra ze ontdekken wat de agent kan.
Daarom is agentkwaliteit niet alleen een bouwvraag, maar vooral een onderhoudsvraag. De eerste versie van je agent bewijst dat iets technisch kan. De volgende fase bewijst of je team het beheersbaar kan houden. Dat is een ander vak: minder spektakel, meer discipline.
Waarom minder tools betrouwbaarder kan zijn
Een agent met twintig tools lijkt veelzijdig, maar moet bij elke taak kiezen uit twintig mogelijke routes. Sommige tools overlappen. Andere tools hebben vergelijkbare namen. Weer andere tools leveren data terug in een vorm die niet precies past bij de vervolgstap. Daardoor groeit de kans dat de agent een plausibele maar verkeerde route kiest.
Minder tools kan betrouwbaarder zijn wanneer je daarmee de keuzeruimte versmalt tot routes die goed beschreven, getest en gemeten zijn. Dat is geen bezuiniging op ambitie. Het is productdenken. Je maakt de agent niet beter door hem alles te laten proberen, maar door hem de juiste dingen consequent goed te laten doen.
Belangrijk is de nuance: minder is niet automatisch beter. Een agent die een taak echt moet uitvoeren, heeft soms juist toegang nodig tot een specifiek systeem. Schrappen wordt pas waardevol wanneer tools redundant, risicovol, slecht onderhouden of nauwelijks aantoonbaar nuttig zijn. Het doel is dus niet een zo kaal mogelijke agent, maar een agent waarvan elke mogelijkheid verdedigbaar is.
De onderhoudsvraag vóór je een tool toevoegt
Voordat je een nieuwe tool toevoegt, hoort het team een paar praktische vragen te beantwoorden. Welke taak wordt hiermee beter uitgevoerd? Hoe meten we dat? Wat is de verwachte foutreductie? Welke gebruikerssituatie rechtvaardigt deze extra route? Als het antwoord vooral is dat de agent ‘dan meer kan’, is dat meestal te vaag.
Daarna komt eigenaarschap. Wie onderhoudt de koppeling? Wie controleert permissies? Wie ziet het wanneer de API-output verandert? Wie beslist dat een tool tijdelijk uit moet? Wie analyseert mislukte runs? In veel agent-pilots zijn dit impliciete taken. Zolang het experiment klein is, lukt dat nog. Bij productiegebruik wordt impliciet beheer een risico.
Ook verwijdercriteria horen vooraf op tafel. Een tool moet niet eeuwig blijven bestaan omdat hij ooit handig leek. Spreek af wanneer een tool opnieuw beoordeeld wordt. Bijvoorbeeld na een modelupgrade, na een wijziging in databronnen, na een reeks fouten of na een periode waarin de tool wel vaak gekozen wordt maar weinig bijdraagt aan taakvoltooiing.
Een praktisch besliskader voor AI-teams
Begin met een tool-inventarisatie. Zet alle tools van je agent in één overzicht en label ze als essentieel, onzeker, redundant of risicovol. Essentieel betekent: zonder deze tool kan de agent zijn kerntaak niet uitvoeren. Onzeker betekent: mogelijk nuttig, maar de bijdrage is niet bewezen. Redundant betekent: de functie overlapt met een andere route. Risicovol betekent: de tool kan schade veroorzaken bij verkeerd gebruik, bijvoorbeeld door data te wijzigen of berichten te versturen.
Meet vervolgens niet alleen of een tool gebruikt wordt, maar of hij helpt. Veel gebruik is geen bewijs van waarde. Een agent kan een tool vaak kiezen omdat de beschrijving breed is, niet omdat de tool de taak beter afrondt. Kijk daarom naar taakvoltooiing, foutreductie, herstelacties, escalaties en menselijke correcties. Juist die signalen laten zien of de harness slimmer wordt of alleen drukker.
Plan daarna een vaste agent-maintenance review. Niet als vrijblijvende nabespreking, maar als onderdeel van productbeheer. Bespreek welke tools blijven, welke scherper beschreven moeten worden, welke permissies aangepast moeten worden en welke routes verwijderd kunnen worden. Voor teams die meerdere AI-flows beheren, is dit net zo belangrijk als backlog grooming of security review.
Van pilot naar productie: bouw onderhoudbare autonomie
De stap naar productie vraagt een andere mentaliteit dan de pilotfase. In de pilot wil je bewijzen dat de agent iets kan. In productie wil je bewijzen dat de agent betrouwbaar genoeg blijft wanneer omstandigheden veranderen. Dat betekent dat je autonomie niet maximaliseert, maar begrenst tot wat je kunt meten en onderhouden.
Een goede eerste productieflow is daarom vaak smal. Kies één taak met duidelijke input, duidelijke output en duidelijke escalatie. Laat de agent daarin aantoonbaar presteren voordat je hem bredere toegang geeft. Dat voelt minder indrukwekkend dan een alleskunner, maar het is veel bruikbaarder voor teams die verantwoordelijkheid dragen voor klantcontact, salesprocessen, support of interne operatie.
Voor Funnel Adviseur is dit de kern: AI-automatisering moet niet alleen slim lijken, maar beheerbaar waarde leveren. De volwassen agentstrategie gaat minder over maximale vrijheid en meer over onderhoudbare autonomie. Bouw dus niet de agent met de meeste tools. Bouw de agent waarvan je precies begrijpt waarom elke tool bestaat, hoe hij faalt en wanneer hij weer mag verdwijnen.
