Wie AI Agents Tools nutzen (Function Calling erklärt)

Ein AI Agent nutzt ein Tool per Function Calling: Das Modell liest die Aufgabe, gleicht sie mit den Tools ab, die es erhalten hat, und gibt eine strukturierte Anfrage aus, die das Tool und die genauen Übergabewerte benennt. Ihre Anwendung, bei gehosteten Tools der AI-Anbieter selbst, führt diese Anfrage gegen ein echtes System aus und liefert das Ergebnis zurück, das das Modell liest, bevor es entscheidet, was als Nächstes zu tun ist. Function Calling ist der Mechanismus, der ein Sprachmodell von etwas, das nur Text schreibt, zu etwas macht, das einen Kalender prüfen, einen CRM-Datensatz aktualisieren oder eine Erstattung auslösen kann.

Das ist längst kein Nischenthema mehr. Gartner prognostiziert, dass bis Ende 2026 40 % der Unternehmensanwendungen aufgabenspezifische AI Agents enthalten werden, gegenüber weniger als 5 % im Jahr 2025, und nahezu jeder dieser Agents ist auf Function Calling angewiesen, um mehr zu tun, als eine Antwort zu erzeugen. Wer einen Agent baut oder kauft, für den ist es der Unterschied zwischen einem wirklich nützlichen Agent und einem, der in der Demo beeindruckt und in der Produktion auseinanderfällt, zu verstehen, wie Tool-Aufrufe tatsächlich funktionieren und wo sie scheitern.

Vom Reden über eine Aufgabe zum Erledigen

Ein Modell ohne Tools kann beschreiben, was geschehen sollte: „Ich empfehle, das auf Donnerstag zu verschieben und eine Bestätigung zu senden.“ Ein Modell mit Tools kann es geschehen lassen. Es ruft ein Kalender-Tool auf, um die Verfügbarkeit am Donnerstag zu prüfen, ruft ein Messaging-Tool auf, um die Bestätigung zu senden, und meldet zurück, dass es erledigt ist. Das ist der ganze Unterschied zwischen Chatbot und Agent, ausführlicher in Wie AI Agents funktionieren behandelt: Wahrnehmung speist das Schlussfolgern, das Schlussfolgern wählt ein Tool, und das Tool verändert tatsächlich etwas außerhalb des Modells.

Das Konzept hat in der AI-Literatur einen Namen: Tool Use, je nach Anbieter auch Function Calling genannt. Die Definition in einfachen Worten samt Business-Einordnung liefert Was Tool Use ist. Dieser Artikel geht eine Ebene tiefer und konzentriert sich darauf, was zählt, sobald Sie einen Agent tatsächlich betreiben: wie ein Tool-Aufruf aufgebaut ist, wie das Modell entscheidet, einen auszulösen, was bei Fehlern passiert und wie sich ein wachsender Satz von Tools verwalten lässt, ohne im Chaos zu enden.

Der Aufbau eines Tool-Aufrufs

Jedes Tool, das ein Agent nutzen kann, wird grundsätzlich gleich definiert, unabhängig vom AI-Anbieter. Drei Teile bilden die Definition, und das Modell sieht nie mehr als das, was Sie in diese drei Teile schreiben. Diese Struktur ist bei Anthropics Tool-Use-Plattform und jedem anderen großen Anbieter einheitlich dokumentiert:

Wenn das Modell ein Tool nutzen will, führt es selbst keinen Code aus. Es gibt ein strukturiertes Objekt aus, das das Tool benennt und die Parameter füllt, etwa „rufe check_order_status mit order_id: 48213 auf.“ Ihr System, bei Tools wie der Websuche, die auf Anbieterseite laufen, die gehostete Infrastruktur des Anbieters, führt diesen Aufruf gegen das echte Bestellsystem aus und sendet das Ergebnis in derselben Konversation zurück. Das Modell liest das Ergebnis als neue Information und macht weiter, genau wie die Schleife aus Wahrnehmen, Schlussfolgern, Handeln und Beobachten es beschreibt.

Die Qualität von Beschreibung und Schema entscheidet über den Großteil des Ergebnisses. Ein Tool namens update_record ohne Angabe, um welche Art von Datensatz es geht oder welche Felder es akzeptiert, gibt dem Modell fast nichts an die Hand. Ein Tool, das das Modell falsch einsetzen kann, weil ein Parameter nur lose typisiert ist, etwa ein Freitextfeld date statt eines strikten Formats, wird irgendwann mit einem Wert aufgerufen, mit dem niemand gerechnet hat.

Wie das Modell entscheidet, ob es ein Tool aufruft

In jedem Zug trifft das Modell eine kleine Entscheidung: Braucht diese Anfrage ein Tool, oder kann es aus dem antworten, was es schon weiß? Eine Frage zu Ihrer Erstattungsrichtlinie lässt sich vielleicht direkt beantworten, wenn der Richtlinientext bereits im Kontext liegt. Eine Frage zur Bestellung eines bestimmten Kunden braucht ein Tool, weil das Modell diese Daten nicht kennt und nie kennen wird, solange es sie nicht nachschlägt.

Zwei Dinge prägen diese Entscheidung. Erstens, wie gut die Beschreibung des Tools zur Anfrage passt: Eine vage Beschreibung wird übersprungen oder falsch angewendet. Zweitens, wie der System Prompt oder die Agent-Konfiguration das Verhalten steuert. Einem Agent lässt sich auftragen, vor jeder Antwort immer eine Knowledge Base zu prüfen, Tools nur zu nutzen, wenn es ausdrücklich nötig ist, oder in einem bestimmten Szenario vor jeder Antwort einen Tool-Aufruf zu verlangen. Das ist in den meisten Agent-Frameworks eine einstellbare Größe, kein festes Verhalten. Deshalb können sich zwei Agents auf demselben zugrunde liegenden Modell sehr unterschiedlich verhalten, je nachdem, wie direkt sie angewiesen werden, zu Tools zu greifen.

Dieser Entscheidungspunkt ist genau der „Reason“-Teil des Agent-Loops. Wie AI Agents funktionieren behandelt den vollständigen Zyklus ausführlicher. Der hier beschriebene Moment der Tool-Auswahl ist der Punkt, an dem Schlussfolgern zu Handeln wird. Einen genaueren Blick darauf, was auf der Reasoning-Seite geschieht, bevor überhaupt ein Tool aufgerufen wird, bietet Wie AI Agents schlussfolgern.

Einzelne, sequenzielle, parallele und bedingte Aufrufe

Nicht jede Aufgabe braucht nur einen Tool-Aufruf. Echte Agent-Arbeit fällt meist in eine von vier Formen:

Der AI Meeting Scheduler Agent-Blueprint ist ein sauberes sequenzielles Beispiel: Verfügbarkeitsabfrage, dann Buchung, dann Bestätigung, wobei jeder Schritt vom vorherigen abhängt. Der AI Research Agent-Blueprint stützt sich auf parallele und sequenzielle Aufrufe zusammen: Er fragt mehrere Quellen gleichzeitig ab und liest dann jedes Ergebnis, um die nächste Suche zu bestimmen. Der AI Support Triage Agent-Blueprint ist der bedingte Fall: Die Klassifikation bestimmt, ob der nächste Tool-Aufruf eine Knowledge-Base-Abfrage, eine Routing-Aktion oder eine Eskalation ist.

Wie Tools in Produktions-Blueprints aussehen

Abstrakte Beschreibungen reichen nur bis zu einem gewissen Punkt. So sehen Tool-Sets bei echten Aufgaben aus.

Der AI SDR Agent ruft ein Recherche-Tool auf, um firmografische Daten zu einem Ziel-Account zu holen, ein CRM-Tool, um bestehende Beziehungen zu prüfen und Ansprachen zu protokollieren, und ein E-Mail-Tool, um die Sequenz zu versenden. Drei Tools, drei verschiedene Systeme, eine stimmige Aufgabe.

Der AI Invoice AP Agent ruft ein Dokumentenextraktions-Tool auf, um Positionen von einer Rechnung zu ziehen, ein Lieferanten-Lookup-Tool, um sie mit einer Bestellung abzugleichen, und ein ERP-Tool, um die freigegebene Zahlung zu buchen. Jeder Tool-Aufruf hat hier echte finanzielle Folgen. Genau deshalb sitzt zwischen Extraktion und Buchung ein Freigabeschritt, statt den Agent einfach durchlaufen zu lassen.

Beachten Sie das Muster: Die Tools, auf die ein Agent Zugriff hat, definieren die Obergrenze dessen, was er kann, nicht mehr. Ein Agent mit einem schreibgeschützten CRM-Tool kann Datensätze nachschlagen, aber nicht ändern. Ein Agent mit einem schreibfähigen Tool kann es. Diese Grenze ist eine Designentscheidung, kein Zufall, und meist das Erste, was sich zu prüfen lohnt, wenn ein Agent etwas tut, womit Sie nicht gerechnet haben.

Wenn Tool-Aufrufe scheitern: Fehler, Wiederholungen und Grenzen

Tool-Aufrufe scheitern häufiger, als Demos vermuten lassen. Die typischen Fehlerbilder:

• Falsche oder fehlende Parameter. Das Modell rät einen Wert, den es nicht erhalten hat, besonders bei mehrdeutigen Anfragen. Ein gut gebauter Agent stellt bei allem Folgenreichen eine Rückfrage, statt zu raten.
• Berechtigungsfehler. Das Tool existiert, aber die Zugangsdaten des Agents erlauben diese konkrete Aktion nicht. Das ist eine Schutzmaßnahme, die bestehen bleiben sollte, statt sie durch erweiterten Zugriff zu „beheben“.
• Das Tool existiert nicht oder wurde falsch erinnert. Das kommt bei großen, schlecht organisierten Tool-Sets häufiger vor als bei einem kleinen, klar abgegrenzten.
• Timeouts und Ausfälle. Das nachgelagerte System ist langsam oder down, und der Agent braucht einen definierten Fallback, statt zu hängen oder ein Ergebnis zu erraten.

Skalierung verändert dieses Problem. Der Function-Calling-Leitfaden von OpenAI empfiehlt, die Zahl der in einem einzelnen Zug verfügbaren Tools klein zu halten, in der Regel unter 20, weil die Genauigkeit sinkt, wenn das Modell zwischen immer mehr ähnlich aussehenden Optionen unterscheiden muss. Für Agents, die wirklich eine große Tool-Bibliothek brauchen, ist die Lösung nicht, alle in jeden Prompt zu packen. Sie besteht darin, nur die für die aktuelle Aufgabe relevante Teilmenge zu laden, damit das Modell aus einer kurzen, relevanten Liste wählt statt aus einer überwältigenden.

Der Beobachtungsschritt fängt das meiste davon ab. Ein gut gestalteter Agent prüft, ob ein Tool-Aufruf tatsächlich erfolgreich war, bevor er ihn als erledigt behandelt, wiederholt bei einem vorübergehenden Fehler und übergibt an einen Menschen, statt zu raten, wenn ein Fehler sich wiederholt. Ein Agent, der einen Tool-Aufruf abfeuert und annimmt, er habe funktioniert, ist die häufigste Ursache hinter „Die AI sagte, sie habe die E-Mail gesendet, aber das hat sie nicht.“

Function Calling und das Standardisierungsproblem

Eine Zeit lang war jede Tool-Integration Individualarbeit: ein maßgeschneiderter Connector für Ihr CRM, ein weiterer für Ihren Kalender, ein weiterer für Ihren Support Desk, und jeder brach auf seine eigene Weise, wenn sich die zugrunde liegende API änderte oder Sie den AI-Anbieter wechselten. Das Model Context Protocol löst das, indem es standardisiert, wie ein Modell Tools entdeckt und aufruft, sodass ein einmal gebautes Tool bei verschiedenen AI-Anbietern funktioniert, statt für jeden neu gebaut zu werden.

Der Standard ist schnell gewachsen. Anthropic, das MCP ursprünglich entwickelt hat, meldete im Dezember 2025 mehr als 10.000 aktive öffentliche MCP-Server, gegenüber einigen Hundert beim Start ein Jahr zuvor, und das Protokoll liegt heute unter den meisten großen Agentic-Plattformen, statt neben ihnen. Wenn Sie einen Agent an einen wachsenden Satz von Business-Tools anbinden, ohne die Integrationsebene bei jedem Modellwechsel neu zu bauen, ist Was das Model Context Protocol ist die vertiefende Referenz, einschließlich der Sicherheitsaspekte, die mit der Anbindung einer breiteren Menge an Servern einhergehen.

Guardrails: Was ein Tool nie frei tun dürfen sollte

Nicht jeder Tool-Aufruf verdient dasselbe Vertrauen. Eine schreibgeschützte Abfrage und eine Aktion, die Erstattungen auslöst, bergen sehr unterschiedliche Risiken, wenn der Agent sich irrt, und beide gleich zu behandeln ist der Weg, auf dem aus einem kleinen Reasoning-Fehler echter finanzieller oder kundenseitiger Schaden wird.

Das Muster, das funktioniert: jedes Tool auf die engste Berechtigung beschränken, die die Aufgabe noch erledigt, für Tools, die finanziell, unumkehrbar oder im großen Maßstab kundenseitig sind, einen menschlichen Freigabeschritt verlangen und jeden Aufruf protokollieren, damit eine falsche Aktion im Nachhinein nachvollziehbar ist statt ein Rätsel. Das ist dieselbe Disziplin wie in AI-Agent-Guardrails, und sie trennt einen Agent, den man bedenkenlos laufen lassen kann, von einem, der technisch funktioniert, bis zu dem Tag, an dem er es nicht mehr tut. Das Autonomous-Agent-Muster geht näher darauf ein, warum Tool-Calling-Schleifen der risikoreichste Teil jedes Agent-Designs sind, da jeder Aufruf eine Chance ist, realen Zustand zu verändern.

Key Facts

• Function Calling funktioniert über drei Teile: einen Tool-Namen, eine Beschreibung in Klartext und ein Parameter-Schema. Das Modell führt selbst nie Code aus. Es gibt eine strukturierte Anfrage aus, die Ihr System ausführt.
• Das Modell entscheidet über einen Tool-Aufruf, indem es die Anfrage mit den Tool-Beschreibungen abgleicht und den Anweisungen folgt, die es dazu erhalten hat, wann es zu einem Tool greift und wann es direkt antwortet.
• Tool-Aufrufe treten in vier Formen auf: einzeln, sequenziell, parallel und bedingt, oft kombiniert innerhalb eines Agent-Durchlaufs.
• Die Genauigkeit sinkt, wenn die Zahl verfügbarer Tools wächst. OpenAI empfiehlt, die aktive Tool-Liste bei etwa 20 oder darunter zu halten und bei größeren Bibliotheken zusätzliche Tools bei Bedarf zu laden.
• Das Model Context Protocol standardisiert die Tool-Integration über AI-Anbieter hinweg, und das Ökosystem ist auf über 10.000 aktive öffentliche Server gewachsen.

Wie es weitergeht

Tool Use gibt einem Agent Hände. Kombinieren Sie es mit der Reasoning-Seite der Schleife in Wie AI Agents schlussfolgern, um zu sehen, wie ein Modell entscheidet, zu welchem Tool es greift und wann es aufhört, und lesen Sie Wie AI Agents funktionieren für die vollständige Schleife, in die sich diese Tool-Aufrufe einfügen. Wenn Sie Plattformen zum Aufbau vergleichen, zeigen die Übersicht der Automatisierungs-Tools und der Leitfaden zu den besten No-Code-Automatisierungs-Tools, wo Tool-Calling-Fähigkeiten in den heute kaufbaren Produkten auftauchen.