Tool-Use für AI-Agents designen: Werkzeuge, die ein Agent sicher bedienen kann

Wenn ein AI-Agent in der Praxis versagt, suchen die meisten Teams den Fehler im Prompt oder im Modell. Häufig liegt er woanders: in den Werkzeugen. Tool-Use, also die Fähigkeit eines Agenten, definierte Funktionen aufzurufen, ist die Stelle, an der aus Sprachverarbeitung Wirkung wird. Und die Qualität dieser Wirkung hängt weniger am Modell als daran, wie die Werkzeuge geschnitten, beschrieben und abgesichert sind.

Der Grundirrtum ist, eine bestehende API unverändert als Werkzeugsatz durchzureichen. APIs sind für Entwickler gebaut, die Dokumentation lesen, Randfälle kennen und im Zweifel debuggen. Ein Modell hat nichts davon. Es sieht nur Namen, Beschreibungen und Parameter, und aus genau diesen Texten leitet es ab, was es tun soll. Werkzeugdesign für Agenten ist deshalb Schnittstellendesign für einen sehr schnellen, sehr wörtlich nehmenden Bediener.

Werkzeug-Schnitt: eine Aufgabe pro Werkzeug

Die wichtigste Designentscheidung ist der Schnitt. Bewährt hat sich die Regel: ein Werkzeug, eine klar benennbare Aufgabe. Ein Werkzeug namens kunde_suchen, das nach Name oder Kundennummer sucht und eine Trefferliste liefert, ist für ein Modell gut bedienbar. Ein generisches Werkzeug, das beliebige Datenbankabfragen ausführt, ist das Gegenteil: maximal mächtig, maximal fehleranfällig und praktisch nicht absicherbar.

Zu breite Werkzeuge eröffnen dem Agenten unzählige falsche Pfade. Zu schmale Werkzeuge erzwingen lange Aufrufketten, in denen sich Fehler fortpflanzen. Die richtige Granularität orientiert sich an den fachlichen Arbeitsschritten, nicht an der technischen Struktur des Backends. Auch die Benennung gehört zum Schnitt: Name und Beschreibung sind die eigentliche Schnittstelle. Eine brauchbare Probe ist, die Werkzeugliste einem fachfremden Kollegen zu zeigen. Was der missversteht, missversteht das Modell auch.

Klare Parameter, sprechende Fehlermeldungen

Bei den Parametern gilt: so wenige wie möglich, so eindeutig wie möglich. Aufzählungstypen mit festen Werten schlagen Freitext, Pflichtfelder schlagen optionale Felder mit stillem Default, und mehrdeutige Formate, etwa Datumsangaben ohne definiertes Schema, sind eine verlässliche Fehlerquelle. Jeder Parameter braucht eine Beschreibung, die sagt, was gültig ist und woher der Wert kommen soll.

Genauso wichtig, und fast immer vernachlässigt, sind die Fehlermeldungen. Ein Agent liest die Antwort des Werkzeugs und entscheidet danach seinen nächsten Schritt. Eine Meldung wie Fehler 400 führt zu Raten. Eine Meldung wie Kundennummer nicht gefunden, das Format ist K plus sechs Ziffern, führt zur Korrektur. Fehlermeldungen sind in einem Agentensystem Teil des Prompts. Wer sie so schreibt, senkt die Zahl der Fehlversuche deutlicher als jede Prompt-Optimierung.

Idempotent oder wirkend: die wichtigste Unterscheidung

Nicht alle Werkzeuge tragen dasselbe Risiko. Die zentrale Trennlinie verläuft zwischen zwei Klassen:

• Idempotente oder lesende Aktionen: suchen, lesen, berechnen, einen Entwurf erzeugen. Sie lassen sich beliebig oft wiederholen, ohne Schaden anzurichten.
• Wirkende Aktionen: senden, buchen, löschen, bezahlen, einen Status ändern. Jede Ausführung verändert die Welt außerhalb des Systems.

Diese Unterscheidung ist deshalb so wichtig, weil Agenten wiederholen. Ein Zeitüberschreitungsfehler, eine unklare Antwort, ein abgebrochener Lauf, und das Modell versucht den Aufruf erneut. Bei einer Suche ist das harmlos. Bei einer Buchung ist es eine Doppelbuchung. Wirkende Aktionen sollten deshalb, wo immer möglich, technisch idempotent gebaut werden, etwa über eine Vorgangskennung, die dafür sorgt, dass derselbe Auftrag nur einmal ausgeführt wird, egal wie oft er ankommt.

Freigabepflicht für wirkende Aktionen

Für wirkende Aktionen hat sich ein Muster durchgesetzt: Der Agent führt sie nicht direkt aus, sondern erzeugt einen Vorschlag, den ein Mensch freigibt. Der Agent bereitet die E-Mail vor, der Sachbearbeiter sendet sie. Der Agent stellt die Stornierung zusammen, die Mitarbeiterin bestätigt sie. Das kostet einen Klick und kauft dafür die Eigenschaft, dass kein Fehlverhalten des Modells unmittelbar nach außen wirkt.

Wie streng die Freigabepflicht sein muss, ist eine Risikoabwägung. Aktionen mit geringer Tragweite können nach einer Bewährungsphase auch automatisch laufen, Aktionen oberhalb definierter Schwellen, etwa ab bestimmten Beträgen oder Empfängerzahlen, bleiben freigabepflichtig. Entscheidend ist auch hier die Durchsetzung: Die Freigabe wird in der Werkzeugschicht erzwungen, nicht im Prompt erbeten. Ein Werkzeug, das ohne Freigabe technisch nichts sendet, ist ein Guardrail. Eine Anweisung, vor dem Senden zu fragen, ist keiner.

Beobachtbarkeit: jeder Aufruf hinterlässt eine Spur

Ein Agentensystem ohne Protokoll ist im Fehlerfall nicht analysierbar. Deshalb gehört zu jedem Werkzeug von Anfang an: Welcher Aufruf kam wann, mit welchen Parametern, was war das Ergebnis, wie lange hat es gedauert, zu welchem Vorgang gehörte es. Erst diese Spur macht es möglich, einen missglückten Lauf Schritt für Schritt nachzuvollziehen und die Ursache zu finden, statt am Prompt zu raten.

Die Protokolle sind zudem eine Designrückmeldung. Wenn ein Werkzeug auffällig oft mit ungültigen Parametern aufgerufen wird oder regelmäßig in Wiederholungsschleifen auftaucht, ist das selten ein Modellproblem. Es ist ein Hinweis, dass Name, Beschreibung oder Parameter des Werkzeugs unklar sind. In der Praxis zeigt sich: Die Fehlerrate pro Werkzeug ist eine der ehrlichsten Metriken über die Qualität des eigenen Designs.

Fazit

Gutes Tool-Use-Design folgt wenigen, konsequent angewendeten Regeln: ein Werkzeug pro Aufgabe, eindeutige Parameter, Fehlermeldungen, die dem Modell den Weg zur Korrektur zeigen, eine harte Trennung zwischen idempotenten und wirkenden Aktionen, Freigabepflicht dort, wo Handlungen nach außen wirken, und eine lückenlose Spur jedes Aufrufs. Nichts davon ist spektakulär. Aber zusammengenommen entscheiden diese Regeln darüber, ob ein Agent ein verlässlicher Bediener der eigenen Systeme wird oder ein schneller Verursacher von Aufräumarbeit.