Stell dir vor, du hast gerade eine Führungskraft von Weltklasse eingestellt.
Wir sprechen nicht von einer bloß kompetenten Managerin oder einem bloß kompetenten Manager. Diese Person ist außergewöhnlich. Sie hat jedes jemals geschriebene Lehrbuch zur Unternehmensstrategie verinnerlicht. Sie spricht zwölf Sprachen, fasst einen 300-seitigen Geschäftsbericht in wenigen Minuten zusammen und schreibt ein überzeugendes Memo für den Vorstand schneller, als die meisten Menschen eine Textnachricht tippen. Der Vorstand ist begeistert.
Dann gibst du ihr am ersten Arbeitstag ihr Büro: ein Raum im Keller ohne Fenster, ohne Computer, ohne Telefon und ohne Internetzugang. Die Tür wird von außen verschlossen. Wenn du eine Frage hast, werden Notizen unter der Tür hindurchgeschoben. Antworten kommen auf demselben Weg zurück.
Bittest du sie, eine Rede über die Prinzipien strategischer Führung zu entwerfen? Jedes Mal ein Meisterwerk. Fragst du sie „Wie hoch waren gestern exakt unsere Verkaufszahlen?“ oder „Kannst du dem VP of Engineering eine E-Mail schicken?“ oder „Wie ist der aktuelle Aktienkurs?“, bekommst du eine eloquente, ausführliche Erklärung, warum sie dir leider nicht helfen kann.
Genau das ist die Realität eines standardmäßigen Large Language Models. Außergewöhnlicher Intellekt. Vollständige Isolation.
Sein Wissen wurde an dem Tag eingefroren, an dem das Training endete. Es kann nicht zum Telefon greifen, keine Suche ausführen, keine Live-Datenbank prüfen und keine E-Mail versenden. Es kann brillant über die Welt nachdenken, aber nicht in sie hineingreifen. Und für eine große Klasse praktischer Aufgaben aus der realen Welt ist das eine fatale Einschränkung.
In diesem Kapitel geht es darum, die Bürotür aufzuschließen und unserer brillanten Führungskraft ein echtes Werkzeugset in die Hand zu geben. Wir betrachten das Tool-Use-Muster.
Im Dunkeln eingeschlossen: Warum statische Modelle an Grenzen stoßen
In den vorherigen Kapiteln haben wir Muster behandelt, die steuern, wie ein Modell denkt: Chaining (Dinge nacheinander tun), Routing (einen Pfad wählen), Parallelization (Dinge gleichzeitig tun) und Reflection (die eigene Arbeit prüfen). Diese Muster optimieren das interne Denken des Modells. Sie machen es besser darin, wie es Informationen verarbeitet.
Aber keines davon löst das grundlegendere Problem: Das Modell kann nur mit Informationen arbeiten, die es bereits besitzt oder die du ihm direkt im Prompt gibst.
In dem Moment, in dem ein Nutzer etwas fragt, das aktuelle Daten, persönliche Datensätze oder eine reale Aktion erfordert, trifft das Modell auf eine Wand. Es kann nicht aus dem Fenster schauen. Es kann keinen Browser öffnen. Es kann nicht in dein Postfach sehen. Es kann nur in reichem, wohlformuliertem Text seine eigene Hilflosigkeit beschreiben.
Das ist kein Makel seiner Intelligenz. Es ist eine strukturelle Begrenzung dessen, was ein Sprachmodell im Kern ist: ein Text-rein/Text-raus-System. Es hat keine Hände. Keine Verbindung zur Außenwelt. Die Führungskraft kann dich brillant zu jeder strategischen Option beraten, kommt aber physisch nicht an den Aktenschrank auf der anderen Seite des Raumes.
Das Tool-Use-Muster löst genau das. Anstatt dem Modell direkten, unkontrollierten Zugriff auf das Internet oder eine Datenbank zu geben, was enorme Sicherheits- und Zuverlässigkeitsprobleme erzeugen würde, arbeitet es über einen kontrollierten Mechanismus: Das Modell lernt, um das zu bitten, was es braucht, und das umgebende System holt es für ihn.
Zentrale Einsicht: Das LLM berührt nie direkt ein externes System. Es erzeugt lediglich eine strukturierte Anfrage, im Wesentlichen: „Hier ist die Person, die ich anrufen muss, und hier ist die Frage, die ich stellen möchte.“ Die Anwendungsschicht führt den eigentlichen Aufruf aus und meldet das Ergebnis zurück. Die Intelligenz liegt im Modell, die Ausführung in der Infrastruktur.
Der erste Anruf: Wie Tool Use tatsächlich funktioniert
So funktioniert der Mechanismus in der Praxis. Wenn wir der Führungskraft „Werkzeuge“ geben, stecken wir nicht einfach physisch ein Telefon in die Wand des Isolationsraums. Wir tun etwas Subtileres.
Wir schieben ein Verzeichnis unter der Tür hindurch: eine Liste aller verfügbaren Ressourcen. „Du kannst Sarah aus dem Finanzbereich anrufen. Dazu schreibst du ihren Namen und deine konkrete Frage auf einen grünen Zettel und schiebst ihn zurück unter der Tür durch. Du kannst den Wetterdienst anrufen. Dafür schreibst du den Stadtnamen auf einen blauen Zettel.“ Jeder Eintrag im Verzeichnis hat einen Namen, eine Beschreibung dessen, was die Ressource leisten kann, und ein exaktes Format für die Anfrage.
Die Führungskraft hat jetzt zwei Aufgaben. Erstens: die eingehende Notiz lesen und entscheiden, ob sie aus ihrem eigenen Wissen antworten kann oder ob sie einen Anruf machen muss. Zweitens: Wenn ein Anruf nötig ist, die Anfrage exakt im richtigen Format aufschreiben.
Von dort an folgt der Prozess einer sechsstufigen Übergabe.
Er beginnt, bevor das Gespräch überhaupt startet. Die Entwicklerin oder der Entwickler schreibt im Grunde ein Verzeichnis: eine präzise Beschreibung jedes verfügbaren Tools, wie es heißt, was es tut und welche Argumente es exakt akzeptiert. Das landet im Kontext des Modells so wie jede andere Anweisung auch; die Führungskraft liest das Verzeichnis, bevor sie überhaupt zum Hörer greift.
Wenn eine Nutzeranfrage eintrifft, liest das Modell sie zusammen mit diesem Verzeichnis und trifft eine Einschätzung. Kann es allein aus dem Gedächtnis antworten? Eine Frage zu Verhandlungsprinzipien braucht kein Tool. Eine Frage zum Wetter morgen in Berlin schon. Diese Entscheidung passiert still, innerhalb eines einzigen Forward Passes.
Wenn das Modell feststellt, dass es externe Daten braucht, sagt es nicht in einfachem Englisch „geh das Wetter nachschauen“. Es schreibt die Anfrage in exakt dem Format, das das System erwartet: ein strukturiertes JSON-Objekt mit Funktionsnamen und allen nötigen Argumenten, etwa {"function": "get_weather", "arguments": {"city": "Berlin"}}. Das ist keine Antwort an den Nutzer. Das ist ein Zettel, der unter der Tür zurückgeschoben wird.
Die Orchestrierungsschicht fängt ihn ab. Der Nutzer sieht ihn nie. Das System schlägt die Funktion nach, übergibt die Argumente und führt den eigentlichen Aufruf aus, zur echten Wetter-API, genau in diesem Moment. Das Modell wartet einfach, so wie du warten würdest, während eine Kollegin etwas für dich nachschaut.
Einen Moment später kommt das Ergebnis zurück: „Berlin morgen: 12 °C, teilweise bewölkt, 40 % Regenwahrscheinlichkeit am Nachmittag.“ Diese rohe Ausgabe wird als neue Information in den Kontext des Modells injiziert. Und erst jetzt formuliert das Modell seine Antwort, nicht aus Erinnerung, sondern auf Faktenbasis: „Wenn du für morgen in Berlin eine Veranstaltung im Freien planst, würde ich empfehlen, sie nach drinnen zu verlegen oder zumindest einen Plan B bereitzuhalten, da am Nachmittag wahrscheinlich Regen einsetzt und sich 12 °C mit Wind ziemlich kühl anfühlen werden.“
Der sechsstufige Zyklus: von der Nutzeranfrage über den Tool-Aufruf bis zur synthetisierten Antwort.
Der Nutzer sieht weder den Zettel noch die rohe API-Antwort. Er bekommt die ausgearbeitete Synthese der Führungskraft. Die Intelligenz lebt im Denken, die Daten leben in der realen Welt, und der Tool-Aufruf ist die Brücke zwischen beiden.
Die Kontaktliste der Führungskraft: Reale Anwendungsfälle
Das Verzeichnis, das wir der Führungskraft geben, kann fast alles enthalten. So sieht das in den häufigsten Anwendungen aus:
Die Kontaktliste der Führungskraft, jedes Tool eine direkte Leitung zu einer anderen Fähigkeit.
Die unmittelbarste Anwendung ist der Abruf von Echtzeitinformationen. Ein Nutzer fragt: „Wie ist das Wetter in London?“ Ein LLM ohne Tools liefert eine charmant nutzlose Antwort darüber, dass es keinen Zugriff auf aktuelle Wetterdaten hat, technisch korrekt, praktisch wertlos. Ein Agent mit Tool-Unterstützung schickt eine Anfrage an eine Wetter-API, erhält die tatsächlichen aktuellen Bedingungen und liefert im selben Atemzug eine brauchbare Antwort. Dasselbe Prinzip skaliert auf jede Live-Datenquelle: Aktienkurse, Sportergebnisse, Eilmeldungen, Flugstatus, Verkehrslage. Die Trainingsdaten des Modells mögen zwei Jahre alt sein, der Tool-Aufruf passiert genau jetzt.
Der Aktenschrank des Unternehmens
Einer der wertvollsten Enterprise-Anwendungsfälle besteht darin, einen Agenten mit privaten, proprietären Daten zu verbinden. Deine Kundendaten, deine Lagerdatenbank, Bestellhistorie oder interne Wissensbasis sind für jedes Modell von der Stange komplett unsichtbar. Es gibt keine Möglichkeit, dass ein allgemeines LLM deine konkreten Produkt-SKUs kennt, weiß, welche Kundenkonten überfällig sind, oder was im Engineering-Meeting letzten Donnerstag beschlossen wurde. Wenn du Tools definierst, die deine internen APIs und Datenbanken abfragen, verwandelst du ein allgemeines Modell in einen Spezialisten, der dein Unternehmen kennt. Ein Nutzer fragt: „Ist Produkt SKU-3847 auf Lager und wann wird es als Nächstes versendet?“ Das Modell ruft deine Inventar-API auf, erhält den aktuellen Bestand und den Versandplan und liefert innerhalb von Sekunden eine vollständige Antwort. Was früher eine zweiminütige Suche in einem Backend-Portal war, wird zu einer Frage in einem einzigen Satz.
Der Buchhalter im Raum
LLMs sind berüchtigt dafür, bei präziser Arithmetik zu schwächeln. Sie treffen oft die ungefähre Antwort, verstehen die Struktur des Problems vollkommen, aber man sollte ihnen nicht zutrauen, den exakten Gewinn über ein Portfolio von 47 Positionen mit Live-Marktdaten zu berechnen. Dafür sind sie nicht gebaut. Mit Tools kann das Modell jede numerische Aufgabe an einen Rechner, eine Python-Laufzeit oder eine Finanzbibliothek delegieren, die jedes Mal exakt richtig rechnet. Die Führungskraft rechnet nicht selbst; sie gibt es an den Buchhalter und zeichnet das Ergebnis ab.
Diktat an die Assistenz
Ein Agent mit Kommunikationstools kann den Sprung machen von über Aktionen nachdenken zu sie tatsächlich ausführen. „Schicke eine E-Mail an die Regionalleiter mit einer Zusammenfassung des heutigen Meetings.“ In einem System ohne Tools formuliert der Agent die E-Mail perfekt und stoppt dort, sodass weiterhin ein Mensch den Text kopieren, einfügen und versenden muss. Ist ein E-Mail-Tool definiert, extrahiert der Agent die Empfängerliste aus dem Gespräch, formuliert Betreff und Text, erstellt die Send-Anfrage im richtigen Format und führt sie aus. Die Führungskraft tippt ihre E-Mails nicht selbst; sie diktiert sie der Assistenz, die sie in ihrem Namen versendet. Die KI ist nicht mehr nur ein Formulierungshelfer, sondern ein Akteur.
Die Ingenieurin in der Sandbox
Für Coding-Agenten erreicht Tool Use seine stärkste Form: nicht nur Code schreiben, sondern ihn tatsächlich ausführen. Ein Code-Interpreter-Tool gibt dem Modell eine abgeschottete Umgebung, in der es Skripte ausführen, die Ausgabe oder Fehlermeldung sehen und den Code entsprechend überarbeiten kann. Das ist der Unterschied zwischen einer Entwicklerin, die eine Spezifikation liest und sich vorstellt, was der Code tun wird, und einer, die ihn wirklich ausführt und beobachtet, was passiert. Wenn der Code in Zeile 23 einen TypeError wirft, sieht der Agent den vollständigen Stack Trace, versteht genau, was schiefgelaufen ist, und behebt es, bevor die Antwort den Nutzer überhaupt erreicht.
Gebäudetechnik, IT und mehr
Das Muster reicht über IoT-Integrationen bis in die physische Welt. Ein Agent, der mit einer Smart-Home-Plattform verbunden ist, kann Thermostate anpassen, Türen verriegeln, Lichter ausschalten oder Sicherheitskameras prüfen, alles als Reaktion auf Anfragen in natürlicher Sprache. In industriellen Umgebungen können Agenten Aktoren auslösen, Sensordaten auslesen oder automatisch Wartungstickets eröffnen, wenn ein Schwellenwert überschritten wird. Die Kontaktliste der Führungskraft hat mit anderen Worten keine natürliche Obergrenze. Alles, was einen API-Endpunkt hat, kann zu einem Tool werden. Jede Aktion, die sich als Funktionsaufruf ausdrücken lässt, kann delegiert werden.
Mehr als eine Kontaktliste: Warum „Tool Calling“ größer ist als „Function Calling“
Als Entwickler dieser Fähigkeit zum ersten Mal begegneten, war der dominante Begriff „Function Calling“, eine technisch zutreffende Beschreibung dessen, was mechanisch passiert. Man definiert eine Funktion, das Modell entscheidet sich dafür, sie aufzurufen, und das System führt sie aus.
Aber diese Formulierung unterschätzt stillschweigend, was tatsächlich möglich ist.
Eine „Funktion“ suggeriert einen sauberen Codeblock in derselben Codebasis. Das mentale Bild ist lokal und begrenzt. Doch zunehmend sind die „Tools“, die ein Agent aufruft, komplexe externe Services, Enterprise-APIs mit Hunderten von Endpunkten oder, besonders wichtig, andere KI-Agenten.
Denk an eine Führungskraft, die ein Team leitet. Wenn intensive juristische Analyse nötig ist, verfasst sie den Vertrag nicht selbst; sie ruft die Rechtsabteilung an, die ihren eigenen mehrstufigen Prozess ausführt und eine strukturierte Empfehlung zurückgibt. Wenn sie eine tiefgehende Marktanalyse braucht, beauftragt sie das Research-Team, das seine eigenen Methoden und Datenquellen hat. Die Aufgabe der Führungskraft ist nicht, all diese Arbeit persönlich zu erledigen. Ihre Aufgabe ist zu wissen, wen sie anrufen muss, wann, und die Rückmeldungen in eine kohärente Entscheidung zu integrieren.
Genau das bringt „Tool Calling“ zum Ausdruck, was „Function Calling“ verfehlt. Ein primärer Orchestrator-Agent kann eine komplexe Datenanalyse an einen spezialisierten Analysten-Agenten delegieren. Er kann eine Retrieval-Aufgabe an einen dedizierten Agenten routen, der weiß, wie man sich in einer bestimmten Wissensbasis bewegt. Er kann Bildverarbeitung an ein vision-spezialisiertes Modell auslagern und erst zurückkehren, wenn das Ergebnis fertig ist. Die Tools sind nicht nur Funktionen. Sie sind Abteilungen. Und das LLM lernt, sie zu steuern.
Die Frameworks, die das Büro bauen
Du musst dieses gesamte System nicht von Grund auf selbst verdrahten. Drei Frameworks haben sich als Industriestandard für den Bau von Tool-fähigen Agenten etabliert:
LangChain
Das am weitesten verbreitete Framework. Es bietet einen @tool-Decorator, der jede Python-Funktion in etwas verwandelt, das ein Agent entdecken und verwenden kann. In Kombination mit create_tool_calling_agent und AgentExecutor läuft ein voll funktionsfähiger Tool-using-Agent in weniger als fünfzig Zeilen Code.
Google ADK
Kommt mit einem vorgefertigten Portfolio an Tools direkt ab Werk: Google Search, eine Code-Execution-Umgebung und Vertex AI Search, alles eng mit Geminis nativen Function-Calling-Fähigkeiten verzahnt. Wenn du auf Google Cloud baust, verkürzt ADK den Weg von der Idee zum produktiven Agenten erheblich.
LangGraph
Erweitert LangChain um ein graphbasiertes Ausführungsmodell. Statt einer simplen linearen Schleife aus „entscheiden, aufrufen, antworten“ erlaubt LangGraph komplexe Workflows mit bedingten Verzweigungen, Zyklen und mehreren parallelen Sub-Agenten. Es ist die erste Wahl, wenn Tool-Aufrufe andere Orchestratoren koordinieren müssen.
Das Werkzeugset ohne Code: Tool-fähige KI schon heute nutzen
An diesem Punkt hören die meisten technischen Artikel auf. Aber hier ist der entscheidende Punkt: Du musst keine einzige Zeile Code schreiben, um schon heute vom Tool-Use-Muster zu profitieren.
Jedes Mal, wenn du ChatGPT mit aktivierter Browsing-Funktion verwendest, nutzt du einen Agenten mit einem Web-Such-Tool. Jedes Mal, wenn du den Code Interpreter verwendest, um eine Tabelle zu analysieren, arbeitest du mit einem Agenten, der ein Python-Ausführungstool besitzt. Jedes Mal, wenn ein KI-Assistent ein hochgeladenes PDF liest und konkrete Fragen dazu beantwortet, läuft im Hintergrund ein Retrieval-Tool. Das Muster ist längst überall. Wenn du es verstehst, nutzt du es nur bewusster.
Bei allem, was zeitkritisch ist, solltest du auf Browsing statt auf Erinnerung setzen. Wenn du aktuelle Informationen brauchst, jüngste Ereignisse, Live-Preise, regulatorische Änderungen, alles, was sich im letzten Jahr verändert haben könnte, sag der KI ausdrücklich, dass sie suchen soll, statt sich zu erinnern: „Schau das bitte nach, bevor du antwortest. Ich will aktuelle Daten, nicht das, was du schon weißt.“ Damit instruierst du das Modell, nach seinem Tool zu greifen, statt sich auf potenziell veraltetes Training zu verlassen.
Verwende den Code Interpreter als Taschenrechner. Bitte eine KI nicht, exakte Arithmetik im Kopf zu erledigen. Füge deine Daten ein, beschreibe, was du brauchst, und sag ihr, sie soll ein Skript ausführen. Dann bekommst du ein exaktes Ergebnis statt einer selbstbewussten Näherung. Die Führungskraft schätzt die Quartalszahlen nicht. Sie gibt sie an den Buchhalter weiter.
Die eigentliche Stärke entsteht, wenn du Tools bewusst innerhalb eines einzigen Gesprächs verkettest. „Finde den aktuellen Preis von AAPL. Verwende dann den Code Interpreter, um meine Rendite zu berechnen, wenn ich vor sechs Monaten 100 Aktien gekauft hätte.“ Das ist ein Aufruf eines Such-Tools, gefolgt von einem Rechen-Tool, zusammengeführt in einer einzigen Antwort. Mit zwei Sätzen hast du einen kleinen Finanzagenten gebaut.
Und vielleicht die nützlichste Gewohnheit überhaupt: Antizipiere, was die KI nachschauen müsste, bevor du überhaupt fragst. Bevor du einen komplexen Prompt sendest, frag dich, welche Informationen ein kompetenter Mensch zuerst recherchieren müsste. Genau das solltest du der KI explizit erlauben abzurufen. Warte nicht darauf, dass das Modell selbst merkt, dass es aktuelle Daten braucht. Komm ihm zuvor. „Prüfe bitte die neuesten Zahlen dazu und gib mir dann deine Analyse.“
Der mentale Wechsel lautet: weg von „die KI weiß Dinge“ hin zu „die KI kann Dinge finden“. Dieser zweite Blickwinkel ist deutlich mächtiger und steht heute jedem offen, der Zugang zu einem modernen KI-Assistenten hat. Keine API-Keys, keine Python-Umgebung, keine Infrastruktur nötig.
Fazit: Die Führungskraft bekommt ein Telefon
Wir haben in einem Kellerbüro begonnen. Weltklasse-Talent. Vollständige Isolation. Beeindruckend innerhalb dieser Grenzen, aber letztlich auf Wissen beschränkt, das ankam, bevor die Tür verschlossen wurde.
Das Tool-Use-Muster öffnet die Tür.
Nicht indem es das Modell im abstrakten Sinn intelligenter macht, sondern indem es ihm einen strukturierten, kontrollierten Weg gibt, die Außenwelt zu erreichen: nachzuschlagen, was es nicht weiß, Berechnungen auszuführen, die es nicht schätzen sollte, Aktionen auszulösen, die reiner Text nicht leisten kann, und Spezialisten zu koordinieren, die das übernehmen, was es selbst nicht kann.
Das Modell liefert die Denkleistung. Die Tools liefern die Reichweite. Das Ergebnis ist ein Agent, der die Welt nicht nur beschreibt. Er interagiert mit ihr.
Eine Führungskraft mit enzyklopädischem Wissen, klarem strategischem Urteilsvermögen und jetzt auch: einem Telefon, einem Computer, einem Team und einer direkten Leitung zu jedem System in der Organisation.
Das ist nicht mehr nur ein Sprachmodell. Das ist ein Agent.
