Tools anbinden

Ein Sprachagent, der etwas auslöst, ruft dafür ein Tool auf. Die Mechanik dahinter steht in Agenten und Harness, Kapitel 02 und Grundkurs, Kapitel 09. Hier geht es um die Sekunden, bis das Ergebnis da ist, und um die Frage, wer in dieser Zeit spricht.

Der Aufruf der Reihe nach

Der Ablauf ist bei OpenAI und Google derselbe. Das Modell legt die Argumente in den Gesprächsverlauf. Laut der Beschreibung des Tool Calls bei OpenAI (externe Seite, developers.openai.com) erkennt die Anwendung diese Einträge und führt mit den Argumenten ihren eigenen Code aus.

Danach schickt die Anwendung das Ergebnis zurück und bittet um eine Antwort.

Anfangs hieß das: Bis das Ergebnis da ist, steht das Gespräch. Googles Seite zum Tool Call (externe Seite, ai.google.dev) nennt das die Voreinstellung. Die Aufrufe laufen der Reihe nach, die Verarbeitung hält an, bis das Ergebnis jedes Aufrufs da ist, und so lange lässt sich mit dem Modell nicht weitersprechen.

Im Chatfenster ist das unauffällig. Wer eine Buchung anstößt, sieht einen Ladebalken. Im Gespräch entsteht an derselben Stelle Stille, und je nachdem, was das Tool tut, dauert sie eine halbe Sekunde oder zehn.

Die neueren Modelle reden weiter

OpenAI hat das mit gpt-realtime im August 2025 geändert. Laut der Ankündigung (externe Seite, openai.com) stört ein lang laufender Aufruf den Fluss der Sitzung seither nicht mehr: Das Modell führt das Gespräch weiter, während es auf das Ergebnis wartet. GPT-Live, die neuere Bauform aus Kapitel 02, gibt Tool Calls ganz an ein zweites Modell ab. Die Anleitung dazu (externe Seite, developers.openai.com) hält fest, dass Gespräch und abgegebene Arbeit getrennt weiterlaufen. Ist die Arbeit im Hintergrund fertig, heißt das dort ausdrücklich noch nicht, dass der Anrufer die Antwort gehört hat.

Google zog am 15.09.2026 mit Gemini 3.8 Live nach. Dort ist der Aufruf ohne Warten die Voreinstellung, so steht es in der Änderungsliste (externe Seite, ai.google.dev) der Schnittstelle. Nur das als Vorgänger geführte Gemini 3.1 Flash Live arbeitet weiter ausschließlich der Reihe nach.

Ob Stille entsteht, entscheidet damit die Wahl des Modells. Was sich dadurch an Arbeit in die Anwendung verschiebt, steht in Tiefe 2.

Die Ansage davor

Der einfachste Griff ist, die Wartezeit anzukündigen. Der Hersteller führt das als eigenes Bauteil und nennt es Preamble, also Vorspann. Beide Seiten davon stehen im Leitfaden zum Anweisen (externe Seite, developers.openai.com) direkt nebeneinander. Gut eingesetzt, versichert die Ansage dem Nutzer, dass der Assistent arbeitet. Schlecht eingesetzt, wird sie zum Füllsel und verlängert die gefühlte Wartezeit.

Der zweite Satz ist der wichtigere. Eine Ansage, die nichts sagt, macht das Warten länger, weil sie es benennt, ohne es zu verkürzen. Die Dokumentation (externe Seite, developers.openai.com) wird deshalb konkret. Angesagt wird, wenn gleich ein Tool aufgerufen wird, das spürbar Zeit brauchen kann, wenn Unterlagen geprüft werden, oder wenn eine Übergabe ansteht. Weggelassen wird die Ansage, wenn die Antwort ohnehin sofort kommt, wenn jemand nur bestätigt oder widerspricht, und wenn der Aufruf schnell ist.

Auch die Formulierungen stehen dort. Zu vermeiden sind „Let me think…“ und „One moment while I process that…“. Empfohlen sind Sätze, die die Handlung nennen: „I’ll check that order now.“ Der Unterschied liegt im Bezug. Das eine beschreibt den Zustand der Maschine, das andere die Sache, um die es geht.

Was sich dadurch nicht ändert

Die Kosten aus Agenten und Harness, Kapitel 02 gelten weiter. Im Normalfall steht jede Tool-Beschreibung in jeder Anfrage im Kontextfenster, und fünf Server mit je acht Tools sind vierzig Beschreibungen. Am Sprachkanal ändert das nichts. Was dazukommt, ist eine zweite Rechnung in einer zweiten Währung.

Läuft das Gespräch während eines Aufrufs weiter, verschiebt sich Arbeit von der Technik in die Anwendung. Google beschreibt die Stellschrauben dafür am genauesten.

Der Aufruf ohne Warten

Google führt für die Live-Schnittstelle eine Einstellung, mit der ein Tool im Hintergrund arbeitet, während das Gespräch weitergeht. Bei Gemini 3.8 Live ist sie seit dem 15.09.2026 die Voreinstellung, der blockierende Aufruf bleibt als Schalter für ältere Anwendungen erhalten. Die Fassung mit ausgedehntem Denken kennt nur den Weg ohne Warten. So steht es in der Vergleichstabelle der Seite zu den Fähigkeiten (externe Seite, ai.google.dev).

Ein Ergebnis, das eintrifft, während jemand redet, ist eine Aufgabe für sich. Für den Zeitpunkt nennt Google drei Arten, und die Anwendung legt sie je Ergebnis fest. Das Modell unterbricht sich und sagt es sofort, es wartet, bis es mit dem laufenden Satz fertig ist, oder es nimmt das Ergebnis still auf und benutzt es später im Gespräch. So beschreibt es die Seite zum Tool Call (externe Seite, ai.google.dev). Bei der Fassung mit ausgedehntem Denken fehlt diese Wahl.

Was die drei Arten offenlassen, bleibt bei der Anwendung. Ein Ergebnis kann veraltet sein, oder es gehört zu einer Frage, die inzwischen zurückgezogen wurde. OpenAI schreibt für GPT-Live dieselbe Regel in die Anleitung (externe Seite, developers.openai.com): Ändert jemand seinen Wunsch von Freitag auf Donnerstag, arbeitet die Anwendung mit Donnerstag weiter und verwirft die Ergebnisse der veralteten Anfrage für Freitag.

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Zwei Seiten, zwei Stände

An dieser Stelle lohnt es sich, mehr als eine Seite der Dokumentation zu lesen. Unter der Beschreibung des nicht blockierenden Aufrufs vermerkt die Seite zum Tool Call (externe Seite, ai.google.dev), dass Gemini 3.1 Flash Live den Aufruf ohne Warten noch nicht beherrscht. Das Modell fängt dort erst an zu antworten, wenn das Ergebnis zurückgeschickt ist.

Bis September war das die neueste Fassung des Live-Modells. Die Seite zu den Fähigkeiten (externe Seite, ai.google.dev) führt sie inzwischen als ältere Vorabfassung und empfiehlt den Wechsel auf Gemini 3.8 Live.

Die Seite zum Tool Call hatte den Wechsel am 05.10.2026 noch nicht nachgezogen. Ihre Vergleichstabelle stellt weiter 3.1 Flash Live neben 2.5 Flash Live, und als Voreinstellung nennt sie den Aufruf der Reihe nach. Der Fall steht für eine ganze Klasse: Eine Her­stel­ler­do­ku­men­ta­tion belegt, dass es eine Fähigkeit gibt. Welches Modell sie hat und was dort voreingestellt ist, steht oft auf einer anderen Seite, und die beiden Seiten sind nicht immer gleich alt.

Was das für die Ansage bedeutet

Wenn das Gespräch während des Aufrufs weiterläuft, wird die Ansage trotzdem gebraucht. Sie ändert nur ihre Aufgabe. Vorher überbrückte sie eine Stille, jetzt kündigt sie an, dass gleich etwas nachkommt, das zum vorherigen Thema gehört.

Aus einem Leitfaden für ein Textmodell ist dieselbe Regel notiert, und sie liest sich für den Sprachfall unverändert. OpenAIs Leitfaden zu GPT-5.5, wiedergegeben in einem Weblogeintrag vom 25.04.2026 (externe Seite, simonwillison.net), empfiehlt vor den Tool Calls einer Aufgabe mit mehreren Schritten eine kurze Nachricht an den Nutzer, ein oder zwei Sätze lang: Sie bestätigt die Anfrage und nennt den ersten Schritt.

Den ersten Schritt nennen. Gemeint ist der erste Handgriff. Wer sagt, was er als Nächstes tut, hat eine Ansage gemacht, die auch dann noch stimmt, wenn der Rest anders läuft.

Die Spezifikation, auf der die meisten Tool-Anbindungen stehen, macht eine Vorgabe, die in einem Kanal ohne Bildschirm zur offenen Frage wird.

Zustimmung ohne Bildschirm

Der Satz steht in den Sicher­heits­grund­sätzen von MCP (externe Seite, modelcontextprotocol.io) und ist eindeutig: Ein Host muss die ausdrückliche Zustimmung des Nutzers einholen, bevor er irgendein Tool aufruft. Durchsetzen kann das Protokoll diese Grundsätze selbst nicht, auch das sagt die Spezifikation. Sie liegen bei den Programmen, die es benutzen, und für die empfiehlt sie eine klare Oberfläche zum Prüfen und Freigeben.

Agenten und Harness, Kapitel 02 beschreibt, wie das aussieht: ein Dialog, ein Klick, gegebenenfalls ein Haken für „nicht mehr fragen“, und die Ermüdung, die daraus entsteht. Jeder Teil dieser Beschreibung setzt einen Bildschirm voraus.

Im Gespräch wird daraus eine Rückfrage, und damit ändern sich drei Dinge auf einmal.

Die Zustimmung kostet einen Zug. Fragen, antworten, bestätigen: Das sind drei Wechsel statt eines Klicks, jeder mit dem vollen Latenzbudget aus Kapitel 03.

Die Zustimmung ist nicht schriftlich. Was jemand am Bildschirm angeklickt hat, steht als Ereignis im Protokoll. Was jemand gesagt hat, steht als Abschrift darin, und eine Abschrift ist eine Erken­nungs­leis­tung. „Ja“ und „Nein“ sind kurze Wörter, und Kapitel 02 zeigt, woran die Erkennung scheitert.

Die Ermüdung wirkt schneller. Wer dreimal hintereinander gefragt wird, ob er wirklich möchte, sagt beim vierten Mal ja, ohne zuzuhören. Am Bildschirm gibt es dagegen den Haken, der die Frage abschaltet. Im Gespräch verschiebt derselbe Wunsch die Grenze zwischen dem, was ohne Rückfrage passiert, und dem, was gar nicht passiert.

Daraus folgt eine Bauregel, die es am Bildschirm so nicht braucht: Die Liste der Tools, die ein Sprachagent ohne Rückfrage benutzen darf, muss vorher feststehen. Wer sie zur Laufzeit entscheidet, entscheidet sie über eine Rückfrage, die niemand mehr ernst nimmt.

An derselben Stelle im Ablauf sitzt eine zweite Vorkehrung, bei der niemand gefragt wird: Ein Guardrail am Tool Call kann ihn überspringen, seine Ausgabe ersetzen oder den Lauf abbrechen. Der Unterschied liegt in der entscheidenden Instanz, hier ein Mensch, dort eine Regel. Kapitel 07 nimmt beides auseinander.

Was beim Hineinreden mit einem laufenden Aufruf passiert

Kapitel 03 beschreibt, was beim Barge-in geschieht: Das Modell wirft seine angefangene Erzeugung weg, und die Anwendung muss ihren Abspielpuffer selbst leeren.

Ein laufender Tool Call ist davon nicht erfasst. Er läuft in der Anwendung. Das Modell weiß nichts von ihm, und der Abbruch der Erzeugung hält ihn nicht an. Wer eine Buchung angestoßen hat und dann unterbrochen wird, hat die Buchung trotzdem angestoßen. OpenAI schreibt das für GPT-Live inzwischen selbst in die Anleitung (externe Seite, developers.openai.com): Wer das gesprochene Gespräch unterbricht, lässt die Arbeit im Hintergrund weiterlaufen. Bevor die Anwendung einen gescheiterten Aufruf wiederholt, soll sie deshalb prüfen, ob die Handlung schon stattgefunden hat, damit eine verlorene Antwort keine zweite Buchung auslöst.

Damit steht dieselbe Frage wie beim Abspielpuffer, eine Ebene tiefer. Die Anwendung führt einen Zustand, den das Modell nicht kennt, und sie muss entscheiden, was mit ihm geschieht, wenn das Gespräch die Richtung wechselt. Drei Antworten sind vertretbar: den Aufruf zu Ende laufen lassen und das Ergebnis wegwerfen, ihn abbrechen, wo das möglich ist, oder ihn erst gar nicht starten, solange keine Bestätigung da ist.

Welche davon richtig ist, hängt daran, ob der Aufruf etwas verändert. Das ist dieselbe Grenze, die Kapitel 01 zwischen Antworten und Handeln zieht, und sie fällt hier zum zweiten Mal ins Gewicht.

Eine Beschreibung, die jemand anderes geschrieben hat

Der letzte Punkt ist der, den man im Sprachkanal am ehesten übersieht. Agenten und Harness, Kapitel 02 hält fest, dass eine Tool-Beschreibung fremder Text im eigenen Kontextfenster ist und als unver­trau­ens­würdig gilt.

Am Bildschirm kann man sie ansehen. Im Gespräch entscheidet das Modell allein anhand dieser Beschreibung, welches Tool es aufruft, und der Anrufer bekommt davon nichts mit. Ihm bleibt das Ergebnis, vorgelesen. Der Weg dorthin ist an keiner Stelle sichtbar.