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, tijdens een beoordeling voor de livegang van een agent voor orderverwerking. Een order was mislukt omdat de afspraak de dag ervoor was verlopen, en de agent loste dat op de meest directe manier op die hij tot zijn beschikking had. De actie was gelogd en technisch geautoriseerd. Ze viel ook volledig buiten wat de business had goedgekeurd.

Volgens zijn instructies mocht de agent alleen verkooporders aanmaken en uitzonderingen doorsturen. Maar zijn enige tool kon elk endpoint van de ERP-API aanroepen, onder een serviceaccount met ruime verkooprechten. De IT security lead van de klant stelde toen de vraag die wij nu bij elke agent stellen: welke handelingen kan dit systeem in het ERP uitvoeren? De instructies beschreven de ene reikwijdte, de tool gaf een andere. In productie telt die van de tool.

Die beoordeling heeft bepaald hoe wij agents voor de bedrijfsvoering ontwerpen. De lijst met tools is de specificatie en tegelijk de grens van de bevoegdheden. De instructies zijn richtlijnen binnen die grens.

Tools zijn zakelijke handelingen, geen schil om de API

De snelste manier om een agent aan een ERP te koppelen, is de API van het ERP als tools beschikbaar te stellen. Het is ook de manier waarop u het meest blootgeeft. De API van een ERP is gebouwd voor koppelingen die engineers schrijven nadat ze de documentatie hebben gelezen en hun code hebben getest, en ze biedt elke handeling die het systeem ondersteunt.

Een agent heeft het omgekeerde nodig: een handvol handelingen die aansluiten op de stappen van het bedrijfsproces, elk met één taak. Onze tools krijgen daarom de naam en vorm van een zakelijke handeling. Zoek de prijsafspraak op voor deze klant en dit artikel. Controleer de voorraad voor deze orderregels. Maak een conceptverkooporder aan. Voeg een document toe aan een geval. Draag dit geval met deze reden over aan een medewerker. Elke handeling hoort bij een stap in de procesbeschrijving die het operationele team heeft vastgesteld, en een tool die daar niet in staat, bestaat niet.

Anthropic schreef in september 2025 over het ontwerpen van tools voor agents en kwam tot een vergelijkbare conclusie: bestaande API's één op één doorgeven levert zelden goede tools op, en tools moeten aansluiten op de taken die de agent werkelijk uitvoert. In een grote organisatie gaan wij nog een stap verder. De verzameling tools bepaalt wat de agent mag, en verdient daarom dezelfde zorg als een rol in het autorisatiemodel van het ERP.

De sterkste controle is een parameter die er niet is

Een tool die gegevens in een bedrijfssysteem vastlegt, controleert de invoer voordat er iets in dat systeem belandt, en kijkt daarbij verder dan het datatype. Bestaat de klant en is hij niet geblokkeerd? Mag dit artikel in deze verkooporganisatie worden verkocht? Is de hoeveelheid positief en past die bij wat deze klant normaal bestelt? Ligt de leverdatum niet in het verleden?

De prijs kan de agent helemaal niet meegeven. Een conceptorder haalt de prijs uit de afspraak, en het model heeft daar geen invloed op. Een parameter weglaten beschermt beter dan hem controleren. Als een model een waarde nooit mag bepalen, hoort de tool die waarde ook niet aan te nemen.

Tools die gegevens vastleggen, werken bovendien met een sleutel die is afgeleid van wat het record zakelijk voorstelt, zoals het ordernummer van de klant en de orderregel. Roept de agent de tool een tweede keer aan, dan krijgt hij het bestaande resultaat terug en ontstaat er geen tweede record. Over herhaalpogingen hoeft de agent dus nooit na te denken.

Een foutmelding vertelt het model wat het nu moet doen

Wat een tool terugmeldt als hij iets weigert, is onderdeel van het ontwerp. "Validatie mislukt, code 4012" zegt een model niets over de volgende stap, en een model zonder houvast gaat vaak iets creatiefs proberen. Zo werd de prijsafspraak verlengd.

Onze tools melden wat er is gebeurd en wat de agent vervolgens mag doen: "Geen geldige prijsafspraak voor klant 4471 en artikel X op de gevraagde datum. Maak de order niet aan. Draag het geval over aan sales operations met reden: prijsafspraak ontbreekt." Zo'n melding is een klein stukje proces, geschreven door iemand die het proces kent. In onze ervaring voorkomen goed geformuleerde weigeringen meer fouten dan welke instructie in de prompt ook.

Elke stap ziet alleen zijn eigen tools

Agents kiezen beter uit korte lijsten. Hoe meer tools er zijn, hoe groter de kans dat de agent een tool kiest die plausibel lijkt maar niet klopt, en hoe groter het deel van het systeem dat een onverwachte invoer kan bereiken. Tools worden daarom per stap beschikbaar gesteld. De stap die een inkooporder leest, ziet documenttools. De stap die de klant controleert, ziet leestools voor klant, krediet en afspraken. Alleen de stap die een concept maakt, ziet de tool die een conceptorder aanmaakt, en geen enkele stap ziet een tool die een order vrijgeeft.

Elke tool draait onder een eigen serviceaccount met alleen de ERP-rechten die hij nodig heeft, zodat de grens blijft staan, ook als er een fout in de code van de agent zit. De grens wordt dus twee keer bewaakt: door wat de agent aangeboden krijgt en door wat het ERP accepteert.

Het toolmanifest is een beheersdocument

Voor elke agent die we opleveren, leggen we de tools vast in een manifest: de naam van elke tool, wat die in zakelijke termen doet, welk systeem hij raakt, of hij leest of schrijft, onder welk account hij draait, wat hij weigert en waarom. Een paar pagina's, geschreven voor mensen die geen code lezen.

De IT lead beoordeelt het voor de livegang, en een auditor leest het om te begrijpen wat de automatisering wel en niet kan. Is een voorgestelde tool niet in één gewone zin te beschrijven, dan is hij te breed. Wijzigingen in het manifest lopen via het wijzigingsproces van de klant, net als elke wijziging in een gebruikersrol, want dat is het ook.

Drie verzoeken die we afwijzen

Een algemene querytool, ook niet als alleen-lezenversie. Leestoegang tot alles, vrij te combineren, is precies hoe een agent uiteindelijk de prijzen van de ene klant aan een andere noemt. We voegen smalle leestools toe voor de vragen die werkelijk voorkomen, één voor één.

Een tool die zowel beslist als uitvoert, zoals "goedkeuren en boeken". Beslissen en uitvoeren zijn aparte stappen met aparte eigenaren, en pas in de grens tussen tools wordt die scheiding echt.

"In de prompt staat dat hij dat niet mag" als beheersmaatregel. Een prompt stuurt gedrag in de gevallen waaraan u hebt gedacht. Tools begrenzen gedrag in de gevallen waaraan u niet hebt gedacht.

Het ergste wat hij kan doen

De eerste vraag die een IT lead of auditor over een agent stelt, is wat het ergste is dat hij kan doen. Met een goed manifest is het antwoord binnen een minuut te lezen. Luidt het eerlijke antwoord "alles wat de API toestaat", dan is de agent niet klaar, hoe goed zijn instructies ook zijn.