Tools bepalen wat een AI-agent in het ERP kan doen

De agent had de prijsafspraak van een klant op eigen houtje verlengd. We ontdekten het in een testrun, toen we een agent voor orderverwerking (een AI-systeem dat handelt, niet alleen antwoordt) voor de livegang beoordeelden. Een order was mislukt omdat de afspraak de dag ervoor was verlopen, en de agent loste dat op de meest directe manier op. Gelogd, technisch toegestaan, en buiten alles wat de business had goedgekeurd.

De instructies beperkten de agent tot het aanmaken van verkooporders en het doorgeven van uitzonderingen. Maar zijn enige tool, de verbinding waarmee hij handelde, kon elke functie van het ERP aanroepen, het centrale bedrijfssysteem, onder een account met brede verkooprechten. De IT security lead van de klant stelde de vraag die wij nu bij elke agent stellen: wat kan dit systeem werkelijk doen in het ERP? De instructies beschreven de ene reikwijdte, de tool gaf een andere, en in de praktijk geldt die van de tool.

Die beoordeling bepaalde hoe wij agents bouwen: de lijst met tools is de specificatie en de grens, en de instructies zijn richtlijnen daarbinnen.

Tools zijn zakelijke stappen, geen open toegang

De snelste manier om een agent aan een ERP te koppelen, is de volledige programmeerinterface als tools beschikbaar te maken. Het is ook de breedste toegang: die interface is gebouwd voor ontwikkelaars die documentatie lezen en hun code testen, en biedt elke bewerking van het systeem.

Een agent heeft het omgekeerde nodig: een paar handelingen die passen bij de stappen van het bedrijfsproces en elk één ding doen. Zoek de prijsafspraak op voor deze klant en dit artikel. Maak een conceptorder aan. Geef dit geval met deze reden aan een mens. Elke handeling hoort bij een stap op de afgesproken proceskaart, en er bestaat geen tool buiten die kaart.

Het engineeringartikel van Anthropic over tools voor agents (september 2025) zegt iets vergelijkbaars: bestaande interfaces één op één overnemen levert zelden goede tools op, en tools horen te passen bij de taken die de agent echt uitvoert. In een bedrijf gaan we verder. De tools begrenzen bevoegdheid en verdienen dezelfde zorg als een gebruikersrol in het ERP.

De sterkste controle is een waarde die het model niet kan zetten

Een tool die naar een bedrijfssysteem schrijft, controleert eerst zijn invoer, en niet alleen het type: de klant bestaat en is niet geblokkeerd, het artikel is verkoopbaar in deze verkooporganisatie, de hoeveelheid past bij de historie van de klant, de leverdatum ligt niet in het verleden.

De prijs is helemaal geen invoer. Conceptorders halen prijzen uit de afspraak, en het model kan er geen aanleveren. Een waarde weglaten is een sterkere controle dan haar controleren: als een model een waarde nooit mag bepalen, hoort de tool haar niet te accepteren. Anthropic noemt het idee in "Building effective agents" (december 2024) poka-yoke, naar de Japanse term voor foutvermijding aan de productielijn, en gebruikt het om agents nauwkeuriger te maken. In een ERP doet het nog iets: functiescheiding, die wie prijzen vaststelt scheidt van wie orders aanneemt, afgedwongen door de vorm van de tool.

Weigeringen zeggen wat de volgende stap is

De weigeringsmelding van een tool is onderdeel van het ontwerp. "Validatie mislukt, code 4012" geeft een model niets om mee te werken, dus probeert het graag iets creatiefs. Zo werd de prijsafspraak verlengd.

Onze tools zeggen wat er gebeurde en wat de agent nu mag doen: "Geen geldige prijsafspraak voor klant 4471 en artikel X op de gevraagde datum. Maak de order niet aan. Geef het geval aan sales operations met reden: ontbrekende prijsafspraak." De melding is een klein stukje proces, geschreven door iemand die het proces kent. In onze ervaring voorkomen goed geschreven weigeringen meer verkeerde acties dan welke instructie ook.

Elke stap ziet alleen zijn eigen tools

Agents kiezen beter uit korte lijsten. Elke extra tool is een extra plausibele verkeerde keuze en meer oppervlak dat onverwachte invoer kan raken, dus tools worden per stap beperkt. De stap die een inkooporder leest, ziet documenttools. De stap die de klant controleert, ziet leestools voor klant, kredietlimiet en afspraken. Alleen de conceptstap kan een conceptorder aanmaken, en geen stap kan er een vrijgeven.

Elke tool draait ook onder een eigen login met alleen de ERP-rechten die hij nodig heeft, zodat de grens standhoudt als de code van de agent fout is: ze wordt afgedwongen door wat de agent wordt aangeboden en door wat het ERP accepteert.

Tools per stap beantwoorden ook een beveiligingsvraag die instructies niet kunnen beantwoorden. De stap die de inkooporder van een klant leest, leest tekst die iedereen buiten het bedrijf kan schrijven. Simon Willison noemde de gevaarlijke combinatie de lethal trifecta (juni 2025): toegang tot privédata, blootstelling aan inhoud van buitenaf en een manier om data naar buiten te sturen. Een agent met alle drie kan worden overgehaald te lekken wat hij ziet. Geen stap bij ons heeft alle drie. De stap die het binnenkomende document leest, kan niet schrijven, versturen of andere klanten opzoeken.

De toollijst is een controledocument

Voor elke agent die we leveren, publiceren we de tools als lijst: naam, wat de tool zakelijk doet, welk systeem hij raakt, of hij leest of schrijft, welke login hij gebruikt en wat hij weigert. Een paar pagina's voor mensen die geen code lezen, voor de livegang beoordeeld door de IT lead en gelezen door auditors. Elke tool moet vijf vragen doorstaan:

• Is het doel in één eenvoudige zakelijke zin te zeggen?
• Welke waarden levert het model aan, en zou een daarvan beter uit een systeem komen?
• Wat gebeurt er als hij twee keer met dezelfde invoer wordt aangeroepen?
• Wat weigert hij, en zegt de weigering wat de volgende stap is?
• Onder welke login draait hij, en wat zou die login nog meer kunnen?

Een tool die zakt voor de eerste vraag, is te breed. Wijzigingen gaan door de normale goedkeuring van de klant, zoals elke wijziging in een gebruikersrol, want dat zijn ze, en worden voor de release getest op de afgesproken testgevallen.

Elke weigering wordt ook gelogd per tool en oorzaak. Een CIO ziet hoe vaak de agent wilde bestellen zonder geldige afspraak, en een auditor neemt steekproeven uit weigeringen net zo makkelijk als uit orders. Een tool die nooit weigert, krijgt alleen schone invoer of controleert niets.

Drie verzoeken die we afwijzen

Een algemene zoektool, ook een die alleen leest. Sommige gerespecteerde engineeringteams raden die aan voor agents die ontwikkelaars helpen, en voor een ontwikkelaar die zijn eigen data verkent, is het een goed idee. Binnen een organisatie is het het omgekeerde. Vrije leestoegang is hoe een agent de prijzen van de ene klant aan een andere noemt, en een vrije zoekopdracht valt niet op een lijst te zetten. We voegen smalle leestools toe voor vragen die echt voorkomen, één voor één.

Een tool die beslist en handelt, zoals "goedkeuren en boeken". Beslissen en handelen zijn aparte stappen met aparte eigenaren, en de grens tussen tools is waar die scheiding echt wordt.

"De instructies zeggen dat hij het niet mag doen" als controle. Instructies sturen gedrag in de gevallen waaraan u dacht. Tools begrenzen het in de gevallen waaraan u niet dacht.

Vroeg of laat vraagt een IT lead of auditor naar het ergste dat een agent kan doen. Schrijf de toollijst voor de instructies, en het antwoord is een pagina die in een minuut is gelezen. Is het eerlijke antwoord "alles wat het systeem toestaat", dan is de agent niet klaar, hoe goed zijn instructies ook zijn.