Tool-Design als Kontrollinstrument für KI-Agenten im ERP

Der Agent hatte die Preisvereinbarung eines Kunden eigenmächtig verlängert. Aufgefallen ist uns das in einem Testlauf, bei der Prüfung vor dem Produktivstart eines Agenten für die Auftragsbearbeitung. Ein Auftrag war gescheitert, weil die Vereinbarung am Vortag abgelaufen war, und der Agent löste das Problem auf dem direktesten Weg, den er hatte. Die Aktion war protokolliert und technisch zulässig. Sie lag aber außerhalb von allem, was das Unternehmen freigegeben hatte.

Laut seinen Anweisungen sollte der Agent nur Kundenaufträge anlegen und Ausnahmen weiterleiten. Sein einziges Tool konnte aber jeden Endpunkt der ERP-API aufrufen, unter einem technischen Benutzer mit weitreichenden Vertriebsrechten. Der IT-Sicherheitsverantwortliche des Kunden stellte daraufhin die Frage, die wir heute bei jedem Agenten stellen: Welche Operationen im ERP kann dieses System ausführen? Die Anweisungen beschrieben den einen Umfang, das Tool erlaubte einen anderen. Im Produktivbetrieb zählt, was das Tool erlaubt.

Diese Prüfung hat geprägt, wie wir Agenten für das operative Geschäft bauen. Die Liste der Tools ist die Spezifikation und zugleich die Berechtigungsgrenze. Die Anweisungen geben Orientierung innerhalb dieser Grenze.

Tools bilden Geschäftsvorgänge ab, nicht die API

Am schnellsten bindet man einen Agenten an ein ERP an, indem man dessen API als Tools bereitstellt. Das ist aber auch der Weg mit der größten Angriffsfläche. Die API eines ERP ist für Integrationen gedacht, die Entwickler schreiben, nachdem sie die Dokumentation gelesen haben, und die sie testen. Sie bietet jede Operation, die das System beherrscht.

Ein Agent braucht das Gegenteil: wenige Operationen, die den Schritten des Geschäftsprozesses entsprechen und jeweils genau eine Sache tun. Deshalb benennen und schneiden wir unsere Tools nach Geschäftsvorgängen. Die Preisvereinbarung für diesen Kunden und diesen Artikel abfragen. Den Bestand für diese Positionen prüfen. Einen Kundenauftrag als Entwurf anlegen. Einen Beleg an einen Vorgang anhängen. Diesen Vorgang mit diesem Grund an einen Menschen übergeben. Jedes Tool entspricht einem Schritt in der Prozesslandkarte, die das Fachteam freigegeben hat, und es gibt kein Tool, das dort nicht vorkommt.

Anthropic argumentiert in seinem Engineering-Beitrag über das Schreiben von Tools für Agenten (September 2025) in eine ähnliche Richtung: Wer bestehende APIs eins zu eins verpackt, bekommt selten gute Tools, und Tools sollten zu den Aufgaben passen, die der Agent tatsächlich erledigt. Im Unternehmen gehen wir einen Schritt weiter. Die Menge der Tools ist eine Berechtigungsgrenze und verdient dieselbe Sorgfalt wie eine Rolle im Berechtigungskonzept des ERP.

Die stärkste Kontrolle ist ein Parameter, den es nicht gibt

Ein Tool, das in ein Geschäftssystem schreibt, prüft seine Eingaben, bevor irgendetwas im System ankommt, und zwar nicht nur deren Datentypen. Der Kunde existiert und ist nicht gesperrt. Der Artikel ist in dieser Verkaufsorganisation verkaufsfähig. Die Menge ist positiv und passt zur bisherigen Bestellhistorie des Kunden. Das Lieferdatum liegt nicht in der Vergangenheit.

Der Preis ist gar kein Parameter. Auftragsentwürfe übernehmen den Preis aus der Vereinbarung, und das Modell hat keine Möglichkeit, einen eigenen anzugeben. Einen Parameter wegzulassen ist eine stärkere Kontrolle, als ihn zu validieren. Soll ein Modell einen Wert nie bestimmen, sollte das Tool ihn gar nicht erst annehmen.

Schreibende Tools verlangen außerdem einen Geschäftsschlüssel, gebildet aus Bestellnummer des Kunden und Position. So liefert ein zweiter Aufruf das Ergebnis des ersten zurück, statt einen zweiten Datensatz anzulegen. Um Wiederholungen muss sich der Agent nie kümmern.

Fehlermeldungen sagen dem Modell, was es tun soll

Lehnt ein Tool etwas ab, ist die Meldung Teil des Designs. „Validierung fehlgeschlagen, Code 4012“ gibt einem Modell nichts an die Hand, und ein Modell ohne Anhaltspunkt neigt dazu, etwas Kreatives zu versuchen. Genau so kam es zur verlängerten Preisvereinbarung.

Unsere Tools liefern Fehlermeldungen, die sagen, was passiert ist und was der Agent als Nächstes tun darf: „Keine gültige Preisvereinbarung für Kunde 4471 und Artikel X zum gewünschten Datum. Auftrag nicht anlegen. Vorgang mit Grund ‚fehlende Preisvereinbarung‘ an den Vertriebsinnendienst übergeben.“ Die Fehlermeldung ist ein kleines Stück Prozess, geschrieben von jemandem, der den Prozess kennt. Nach unserer Erfahrung verhindern gut formulierte Ablehnungen mehr Fehlhandlungen als jede Anweisung im Prompt.

Jeder Schritt sieht nur seine eigenen Tools

Agenten treffen aus kurzen Listen die besseren Entscheidungen. Je mehr Tools es gibt, desto wahrscheinlicher wählt der Agent ein plausibles, aber falsches, und desto größer ist die Fläche, die eine unerwartete Eingabe erreichen kann. Tools werden deshalb je Schritt freigeschaltet. Der Schritt, der eine Bestellung liest, sieht die Beleg-Tools. Der Schritt, der den Kunden prüft, sieht lesende Tools für Kundenstamm, Kreditlimit und Vereinbarungen. Nur der Entwurfsschritt sieht das Tool, das einen Auftragsentwurf anlegt, und kein Schritt sieht ein Tool, das ihn freigibt.

Jedes Tool läuft unter einem eigenen technischen Benutzer mit genau den ERP-Rechten, die es braucht. So gilt die Beschränkung auch dann, wenn der Code des Agenten fehlerhaft ist. Die Grenze wird doppelt durchgesetzt: durch das, was dem Agenten angeboten wird, und durch das, was das ERP akzeptiert.

Das Tool-Manifest ist ein Kontrolldokument

Für jeden Agenten, den wir ausliefern, dokumentieren wir die Tools in einem Manifest: Name des Tools, welchen Geschäftsvorgang es ausführt, welches System es berührt, ob es liest oder schreibt, unter welchem Benutzer es läuft, was es ablehnt und warum. Ein paar Seiten, geschrieben für Menschen, die keinen Code lesen.

Die IT-Leitung prüft das Manifest vor dem Go-live, und Wirtschaftsprüfer lesen es, um den Umfang der Automatisierung zu verstehen. Lässt sich ein geplantes Tool nicht in einem einfachen Satz beschreiben, ist es zu weit gefasst. Änderungen am Manifest durchlaufen den Change-Prozess des Kunden wie jede Änderung an einer Benutzerrolle, denn genau das sind sie.

Drei Wünsche, die wir ablehnen

Ein allgemeines Abfrage-Tool, auch ein rein lesendes. Lesezugriff auf alles, frei kombinierbar, führt irgendwann dazu, dass ein Agent einem Kunden die Preise eines anderen nennt. Wir ergänzen stattdessen schmale Lese-Tools für die Fragen, die tatsächlich auftauchen, eines nach dem anderen.

Ein Tool, das zugleich entscheidet und handelt, etwa „freigeben und buchen“. Entscheiden und Handeln sind getrennte Schritte mit getrennten Verantwortlichen, und an der Grenze zwischen zwei Tools wird diese Trennung real.

„Im Prompt steht, dass er das nicht tun soll“ als Kontrolle. Prompts steuern das Verhalten in den Fällen, an die Sie gedacht haben. Tools begrenzen es in den Fällen, an die Sie nicht gedacht haben.

Das Schlimmste, was der Agent tun könnte

Die erste Frage, die eine IT-Leitung oder ein Wirtschaftsprüfer zu einem Agenten stellt, lautet: Was ist das Schlimmste, was er tun könnte? Mit einem guten Manifest ist die Antwort in einer Minute nachgelesen. Lautet die ehrliche Antwort „alles, was die API erlaubt“, ist der Agent nicht einsatzbereit, so gut seine Anweisungen auch sein mögen.