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

Der Agent hatte die Preisvereinbarung eines Kunden eigenmächtig verlängert. Wir fanden das in einem Testlauf, als wir einen Agenten für die Auftragsbearbeitung (ein KI-System, das handelt, nicht nur antwortet) vor dem Start prüften. Ein Auftrag war gescheitert, weil die Vereinbarung am Vortag abgelaufen war, und der Agent löste das auf dem direktesten Weg, den er hatte. Das war protokolliert, technisch zulässig und außerhalb von allem, was das Unternehmen freigegeben hatte.

Die Anweisungen beschränkten den Agenten darauf, Verkaufsaufträge anzulegen und Ausnahmen weiterzugeben. Doch sein einziges Tool, die Verbindung, über die er handelte, konnte jede Funktion des ERP aufrufen, des zentralen Geschäftssystems, unter einem Konto mit weiten Vertriebsrechten. Die IT-Sicherheitsleitung des Kunden stellte die Frage, die wir heute jedem Agenten stellen: Was kann dieses System im ERP tatsächlich tun? Die Anweisungen beschrieben einen Umfang, das Tool gewährte einen anderen, und im Alltag gilt der des Tools.

Diese Prüfung hat entschieden, wie wir Agenten bauen: Die Liste der Tools ist die Spezifikation und die Grenze, und die Anweisungen sind Leitlinien darin.

Tools sind Geschäftsschritte, kein offener Zugang

Am schnellsten verbindet man einen Agenten mit einem ERP, indem man dessen gesamte Programmierschnittstelle als Tools bereitstellt. Es ist auch der weiteste Zugang, den es gibt: Diese Schnittstelle ist für Entwickler gebaut, die die Dokumentation lesen und ihren Code testen, und sie bietet jede Operation, die das System kennt.

Ein Agent braucht das Gegenteil: wenige Aktionen, die den Schritten des Geschäftsprozesses entsprechen und jeweils eine Sache tun. Die Preisvereinbarung für diesen Kunden und Artikel nachschlagen. Einen Auftragsentwurf anlegen. Diesen Fall mit dieser Begründung an einen Menschen geben. Jede entspricht einem Schritt der vereinbarten Prozesskarte, und es gibt kein Tool außerhalb dieser Karte.

Der Engineering-Beitrag von Anthropic über Tools für Agenten (September 2025) sagt Ähnliches: Bestehende Schnittstellen eins zu eins abzubilden, ergibt selten gute Tools, die zu den Aufgaben passen sollen, die der Agent wirklich erledigt. Im Unternehmen gehen wir weiter. Die Tools begrenzen Befugnisse und verdienen dieselbe Sorgfalt wie eine Benutzerrolle im ERP.

Die stärkste Kontrolle ist ein Wert, den das Modell nicht setzen kann

Ein Tool, das in ein Geschäftssystem schreibt, prüft zuerst seine Eingaben, und nicht nur deren Typ: Der Kunde existiert und ist nicht gesperrt, der Artikel ist in dieser Verkaufsorganisation verkäuflich, die Menge passt zur Historie des Kunden, das Lieferdatum liegt nicht in der Vergangenheit.

Der Preis ist gar keine Eingabe. Auftragsentwürfe übernehmen Preise aus der Vereinbarung, und das Modell kann keinen liefern. Einen Wert wegzulassen ist eine stärkere Kontrolle, als ihn zu prüfen: Soll ein Modell einen Wert nie bestimmen, darf das Tool ihn nicht annehmen. Anthropic nennt die Idee in „Building effective agents“ (Dezember 2024) Poka-Yoke, nach dem japanischen Begriff für Fehlervermeidung am Fließband, und nutzt sie, um Agenten genauer zu machen. Im ERP erfüllt sie eine zweite Aufgabe: Funktionstrennung, die trennt, wer Preise festlegt und wer Aufträge annimmt, durchgesetzt durch die Form des Tools.

Ablehnungen nennen den nächsten Schritt

Die Ablehnungsmeldung eines Tools ist Teil des Designs. „Validierung fehlgeschlagen, Code 4012“ gibt einem Modell nichts an die Hand, also versucht es gern etwas Kreatives. So wurde die Preisvereinbarung verlängert.

Unsere Tools 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. Fall an den Vertriebsinnendienst geben, Begründung: fehlende Preisvereinbarung.“ Die Meldung ist ein kleines Stück Prozess, geschrieben von jemandem, der den Prozess kennt. Nach unserer Erfahrung verhindern gut geschriebene Ablehnungen mehr falsche Aktionen als jede Anweisung.

Jeder Schritt sieht nur seine eigenen Tools

Agenten wählen aus kurzen Listen besser. Jedes weitere Tool ist eine weitere plausible Fehlwahl und mehr Fläche, die eine unerwartete Eingabe erreichen kann, deshalb sind Tools je Schritt begrenzt. Der Schritt, der eine Bestellung liest, sieht Dokument-Tools. Der Schritt, der den Kunden prüft, sieht Lese-Tools für Kunde, Kreditrahmen und Vereinbarungen. Nur der Entwurfsschritt kann einen Auftragsentwurf anlegen, und kein Schritt kann einen freigeben.

Jedes Tool läuft außerdem unter eigenem Login mit genau den ERP-Rechten, die es braucht, sodass die Grenze auch hält, wenn der Code des Agenten fehlerhaft ist: Sie wird durch das durchgesetzt, was dem Agenten angeboten wird, und durch das, was das ERP annimmt.

Tools je Schritt beantworten auch eine Sicherheitsfrage, die Anweisungen nicht beantworten können. Der Schritt, der die Bestellung eines Kunden liest, liest Text, den jeder außerhalb des Unternehmens schreiben kann. Simon Willison nannte die gefährliche Kombination die „lethal trifecta“ (Juni 2025): Zugriff auf private Daten, Kontakt mit Inhalten von außen und ein Weg, Daten hinauszuschicken. Ein Agent mit allen dreien lässt sich dazu bringen, preiszugeben, was er sieht. Kein Schritt bei uns hat alle drei. Der Schritt, der das eingehende Dokument liest, kann weder schreiben noch senden noch andere Kunden nachschlagen.

Die Tool-Liste ist ein Kontrolldokument

Für jeden Agenten, den wir liefern, werden die Tools als Liste veröffentlicht: Name, was das Tool geschäftlich tut, welches System es berührt, ob es liest oder schreibt, welchen Login es nutzt und was es ablehnt. Ein paar Seiten für Menschen, die keinen Code lesen, vor dem Start von der IT-Leitung geprüft und von Wirtschaftsprüfern gelesen. Jedes Tool muss fünf Fragen bestehen:

• Lässt sich sein Zweck in einem schlichten geschäftlichen Satz sagen?
• Welche Werte liefert das Modell, und sollte einer davon besser aus einem System kommen?
• Was passiert, wenn es zweimal mit derselben Eingabe aufgerufen wird?
• Was lehnt es ab, und nennt die Ablehnung den nächsten Schritt?
• Unter welchem Login läuft es, und was könnte dieser Login sonst noch?

Ein Tool, das an der ersten Frage scheitert, ist zu breit. Änderungen laufen durch die normale Freigabe des Kunden, wie jede Änderung an einer Benutzerrolle, denn genau das sind sie, und werden vor dem Release an den vereinbarten Testfällen geprüft.

Jede Ablehnung wird außerdem nach Tool und Ursache protokolliert. Ein CIO sieht, wie oft der Agent ohne gültige Vereinbarung bestellen wollte, und ein Prüfer zieht Stichproben aus Ablehnungen so leicht wie aus Aufträgen. Ein Tool, das nie ablehnt, bekommt nur saubere Eingaben oder prüft nichts.

Drei Wünsche, die wir ablehnen

Ein allgemeines Abfrage-Tool, auch ein rein lesendes. Manche angesehene Engineering-Teams empfehlen es für Agenten, die Entwicklern helfen, und für einen Entwickler, der seine eigenen Daten erkundet, ist es eine gute Idee. Im Betrieb ist es das Gegenteil. Freier Lesezugriff ist der Weg, auf dem ein Agent einem Kunden die Preise eines anderen nennt, und eine freie Abfrage lässt sich nicht auflisten. Wir ergänzen eng gefasste Lese-Tools für Fragen, die wirklich vorkommen, eines nach dem anderen.

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

„Die Anweisungen sagen ihm, es nicht zu tun“ als Kontrolle. Anweisungen prägen das Verhalten in den Fällen, an die man gedacht hat. Tools begrenzen es in denen, an die man nicht gedacht hat.

Früher oder später fragt eine IT-Leitung oder ein Prüfer nach dem Schlimmsten, das ein Agent tun könnte. Schreiben Sie die Tool-Liste vor den Anweisungen, dann ist die Antwort eine Seite, in einer Minute gelesen. Lautet die ehrliche Antwort „alles, was das System erlaubt“, ist der Agent nicht bereit, wie gut seine Anweisungen auch sind.