Ein KI-System, das nur antwortet, ist eine bessere Suchmaschine. Ein KI-System, das handelt, ist ein Agent. Diese Unterscheidung ist nicht semantisch — sie entscheidet darüber, ob Sie 30 % oder 70 % Automatisierungsquote erreichen.
Was Tool-Use technisch bedeutet
Tool-Use beschreibt das Pattern, in dem ein LLM strukturierte Aufrufe an externe Funktionen produziert — Buchungen, Anlagen, Updates, Benachrichtigungen. Statt einer Antwort entsteht eine ausgeführte Aktion. Anthropic, OpenAI und Google bieten dafür native Schnittstellen (function calling, tool use). Die wirkliche Komplexität liegt jedoch nicht im LLM-Aufruf — sondern in dem, was dahinter passiert.
Aktor statt Datenquelle: drei Beispiele aus der Praxis
Beispiel 1 — Rechnung in SAP buchen
Ein Eingangsrechnungs-Agent klassifiziert das Dokument, extrahiert Lieferant, Beträge und Kostenstelle, gleicht gegen eine Bestellung ab und bucht direkt in SAP. Bei Abweichungen oberhalb einer definierten Schwelle eskaliert er an die Buchhaltung. Keine Mensch-als-Klick-Bote-Schleife.
Beispiel 2 — Lead-Update in HubSpot/Salesforce
Ein Vertriebs-Agent liest eingehende E-Mails, identifiziert Themenwechsel und aktualisiert direkt die CRM-Pipeline-Stufe. Bei kritischen Statuswechseln (z. B. „”) legt er eine Aufgabe für den verantwortlichen Vertriebsmitarbeiter an.
Beispiel 3 — Dokument in DMS anlegen
Ein Document-Intelligence-Agent erstellt automatisch Dokumente aus Vorlagen (z. B. Angebote, Verträge, Reports), legt sie versioniert im DMS ab und triggert einen Genehmigungs-Workflow.
Was schreibende Aktionen anders machen als lesende
Lesende Tool-Use ist trivial — schreibende nicht. Drei Themen müssen geklärt sein, bevor ein Agent schreiben darf:
Idempotenz: Was passiert, wenn der Agent denselben Aufruf doppelt absetzt (Retry, Netzwerk-Hick)? Ohne Idempotenz-Schlüssel landet die Buchung zweimal.
Berechtigungs-Scoping: Welche Daten darf der Agent schreiben — und welche nicht? Ein Service-Account mit allen Rechten ist ein Compliance-Risiko.
Audit-Trail: Jede schreibende Aktion braucht einen Datensatz: Wer hat sie ausgelöst, mit welchen Eingaben, welchem Modell-Output, welcher Tool-Antwort. Sonst wird Fehlersuche unmöglich.
Tool-Bibliothek statt Tool-Wildwuchs
Mit der Anzahl der Tools wächst der Fehlerraum exponentiell. Daher kapseln wir Tools in eine kuratierte, getestete Bibliothek — nicht jeder Agent darf jedes API rufen. Jedes Tool hat:
- Ein präzises JSON-Schema für Inputs (validiert via zod/pydantic).
- Definierte Erwartungen an Antwort und Fehlerklassen.
- Einen Wrapper, der Auth, Retries, Rate-Limiting und Logging übernimmt.
- Tests gegen Live- und Mock-Systeme.
Welche Systeme als Aktoren in Frage kommen
In unseren Projekten haben sich folgende Systeme als Aktoren bewährt:
- ERP: SAP (über RFC, OData oder das Cloud SDK), Microsoft Dynamics, DATEV.
- CRM: HubSpot, Salesforce, Pipedrive — alle bieten saubere REST-APIs.
- DMS: SharePoint, M-Files, Confluence, Nextcloud.
- Kommunikation: Microsoft 365, Google Workspace, Slack, Teams, Mailcow.
- Custom-APIs: REST, SOAP, GraphQL — sofern dokumentiert und stabil.
Fazit
Tool-Use ist kein Feature — es ist die Voraussetzung dafür, dass aus einer KI-Antwort eine KI-Aktion wird. Wer diesen Schritt nicht macht, automatisiert nicht den Prozess, sondern nur die Beratung. Der Mehrwert liegt im Aktor.