KI-Agenten, die Ihre APIs aufrufen: Ein praktischer Leitfaden zu Tool-Calling

Ein Chatbot beantwortet Fragen. Ein Agent erledigt Arbeit. Der Unterschied ist Tool-Calling: Das Sprachmodell erzeugt nicht nur Text, es entscheidet, welche Ihrer Funktionen es mit welchen Argumenten aufruft, und arbeitet mit den Ergebnissen weiter. Gut umgesetzt wird so aus einem mehrstufigen Geschäftsprozess (Kunde anlegen, USt-IdNr. prüfen, Willkommensmail senden) ein kurzes Gespräch.

Schlecht umgesetzt wird daraus ein Modell, das Parameter rät und in Ihre Datenbank schreibt. Dieser Leitfaden handelt vom ersten Fall.

So funktioniert Tool-Calling

Sie beschreiben dem Modell Ihre Tools: einen Namen, eine kurze Beschreibung und ein JSON-Schema für die Argumente. Das Modell antwortet entweder mit Text oder mit der Bitte, ein Tool aufzurufen. Ihr Code führt den Aufruf aus, schickt das Ergebnis zurück, und die Schleife läuft weiter, bis die Aufgabe erledigt ist.

{
  "name": "crm_lookup",
  "description": "Kunden anhand der E-Mail-Adresse finden",
  "parameters": {
    "type": "object",
    "properties": { "email": { "type": "string", "format": "email" } },
    "required": ["email"]
  }
}

Das Modell greift nie direkt auf Ihre Systeme zu. Es schlägt nur Aufrufe vor; Ihr Backend entscheidet, ob sie ausgeführt werden.

Die Geschäftslogik bleibt im Backend

Die wichtigste Designregel: Das Modell orchestriert, das Backend entscheidet. Validierung, Berechtigungen, Preise, Bestände und jede Geschäftsregel bleiben in Ihren bestehenden Services. Tools sollten dünne Hüllen um APIs sein, denen Sie bereits vertrauen – keine neue Logik, die für das Modell geschrieben wird.

Das hat drei Vorteile: Das Verhalten bleibt vorhersehbar, Sie können die Tools ohne KI testen, und Sie können das Modell (Cloud oder lokal) austauschen, ohne Regeln neu zu schreiben.

Workflows definieren, nicht nur Tools

Einem Modell fünfzig Tools und ein vages Ziel zu geben, funktioniert im Produktivbetrieb selten. Was funktioniert, ist eine Workflow-Definition: die Schritte eines Prozesses, welche Eingaben jeder Schritt braucht, welches Tool er aufruft und was bei einem Fehler passiert. Die Aufgabe des Modells wird deutlich schmaler:

• verstehen, was der Nutzer will, und es einem Workflow zuordnen,
• fehlende Eingaben beim Nutzer erfragen,
• Tool-Argumente aus dem Gespräch befüllen,
• Ergebnisse und Fehler verständlich erklären.

Workflows können in JSON oder einer Datenbanktabelle liegen, sodass Fachabteilungen Schritte ohne Deployment ändern können.

Fragen statt raten

Fehlt ein Pflichtargument, sollte der Agent nachfragen. Ein bewährtes Muster ist ein eigenes ask_user-Tool mit einer klaren Frage. Zusammen mit Schema-Validierung verschwinden damit die meisten erfundenen Parameter: Kann das Modell ein Feld nicht aus dem Gespräch füllen, muss es danach fragen.

Alles validieren, Wichtiges bestätigen lassen

• Jeden Tool-Aufruf vor der Ausführung gegen sein Schema prüfen. Ablehnen und den Fehler an das Modell zurückgeben – meist korrigiert es sich selbst.
• Lese- und Schreib-Tools trennen. Lesen darf sofort laufen; Schreiben, das Geld, Verträge oder Kundendaten ändert, zeigt eine Zusammenfassung und wartet auf Bestätigung.
• Tools idempotent machen, wo möglich, damit ein Retry keinen zweiten Auftrag anlegt.
• Jeden Schritt protokollieren: Prompt, Tool-Aufruf, Argumente, Ergebnis. Das brauchen Sie für Debugging und Audits.

Fehler abfangen

APIs fallen aus. Der Agent sollte die Fehlermeldung sehen und entscheiden: erneut versuchen, den Nutzer um eine Korrektur bitten (etwa bei einer ungültigen Postleitzahl) oder abbrechen und an einen Menschen übergeben. Begrenzen Sie die Schritte pro Aufgabe, damit ein verwirrtes Modell nicht endlos schleift.

Messen, bevor Sie skalieren

Bauen Sie ein kleines Evaluationsset: realistische Gespräche mit den erwarteten Tool-Aufrufen. Lassen Sie es bei jeder Prompt- oder Modelländerung laufen. Messen Sie, wie oft der Agent den richtigen Workflow wählt, Argumente korrekt befüllt und die Aufgabe abschließt. Genau das macht aus einer Demo etwas, das Sie Kunden zeigen können.

Cloud- oder lokales Modell?

Beides funktioniert. Cloud-Modelle sind von Haus aus stark im Tool-Calling. Lokale Modelle (zum Beispiel über Ollama) reichen für klar definierte Workflows und halten die Daten im Haus – in Deutschland oft das entscheidende Argument. Da die Logik im Backend liegt, können Sie mit einem starten und später wechseln.

Wenn ein Prozess jede Woche Stunden manueller Klickarbeit kostet, ist ein Agent mit einer Handvoll klar definierter Tools oft der schnellste Gewinn. Gern skizziere ich einen für Ihren Fall in einem kostenlosen Gespräch.