Tools

Kapitel 08 endet mit drei Wegen, auf denen Neues in ein Gespräch kommt. Der dritte hieß dort „die Anwendung schlägt nach“, und er blieb absichtlich unerklärt. Hier steht, wie er funktioniert.

Sie haben längst einen gesehen

Wenn Sie in einem Chat eine Frage nach etwas Aktuellem stellen und darüber kurz „Suche im Web“ aufblinkt, haben Sie einen Tool Call beobachtet. Das gilt auch für den kleinen Rechenschritt, der plötzlich als Code erscheint, für das Auslesen einer hochgeladenen Tabelle und für den Verweis auf eine Fundstelle, die in der Antwort verlinkt ist.

Dafür muss niemand einen Agenten gebaut haben. Tools stecken in den Anwendungen, die Millionen Menschen täglich benutzen, und sie sind der Grund, warum diese Anwendungen so viel mehr können als das Modell in ihrem Inneren.

In englischsprachigen Anleitungen heißt so etwas tool, der Vorgang tool use oder function calling. Gemeint ist dasselbe.

Das Modell fragt, es macht nicht

Es klingt zunächst nach Haarspalterei: Das Modell führt nichts aus.

Was es tut, ist eng begrenzt. Es erzeugt Text. Bei einem Tool Call erzeugt es einen Text, der nach einer Bitte aussieht: „rufe die Wetterauskunft für München auf“. Ob daraus etwas wird, entscheidet das Programm ringsherum. Anthropic beschreibt das in der Dokumentation zu den Tools genau so:

It then returns a structured call that your application executes (client tools) or that Anthropic executes (server tools). (externe Seite, platform.claude.com)

Das Modell gibt einen Aufruf zurück. Ausgeführt wird er woanders.

Die Schleife

Daraus wird ein Ablauf mit vier Schritten, der sich wiederholt, bis die Aufgabe erledigt ist.

1. Vorher wird beschrieben, was es gibt. Zusammen mit Ihrer Frage bekommt das Modell eine Liste: Diese Tools existieren, so heißen sie, dafür sind sie da, diese Angaben brauchen sie.
2. Das Modell wählt und bittet. Es nennt ein Tool und die Angaben dazu. Mehr passiert an dieser Stelle nicht.
3. Ein Programm führt aus. Es ruft die Wetterauskunft, die Suchmaschine, den Taschenrechner. Das Ergebnis kommt von dort, aus der Welt außerhalb des Modells.
4. Das Ergebnis geht zurück ins Gespräch. Von da an steht es im Kontext, als hätten Sie es selbst hineingeschrieben, und das Modell formuliert damit weiter.

seitlich verschiebbar

eigene Darstellung, Stand 31.07.2026

Schritt 3 ist der interessante. Dort verlässt die Sache zum ersten Mal die Welt der Wahrscheinlichkeiten und trifft auf ein Programm, das entweder etwas zurückgibt oder scheitert. Wer damit baut, rechnet meist mit diesen beiden Ausgängen. Der häufigste ist ein dritter, und Tiefe 3 nimmt ihn auseinander.

Warum der Unterschied im Alltag zählt

Er erklärt drei Dinge, über die Anwender regelmäßig stolpern.

Warum dieselbe Frage mal nachgeschlagen wird und mal nicht. In der Voreinstellung entscheidet das Modell in jeder Runde neu, ob ein Tool passt. Bei „Wie wird das Wetter?“ greift es zu, bei „Erkläre mir Hochdruckgebiete“ antwortet es aus sich heraus, und das ist auch richtig so. Wer selbst baut, kann ihm diese Wahl abnehmen; dazu Tiefe 2.

Warum ein Ergebnis falsch sein kann, obwohl nachgeschlagen wurde. Das Tool liefert, was es findet. Findet es Falsches, formuliert ein einwandfrei arbeitendes Modell daraus eine falsche Auskunft.

Warum es Geld kostet. Jedes Ergebnis wird Teil des Gesprächs und von da an bei jeder weiteren Frage mitgeschickt. Das steht ausführlicher in Kapitel 08.

Angebunden heißt nicht benutzt

Der häufigste Irrtum bei diesem Thema: Wer ein Tool bereitstellt, glaubt, es werde nun auch verwendet. Das Modell muss es aber jedes Mal auswählen, und diese Wahl trifft es anhand dessen, was daneben steht: Name, Beschreibung und die Angaben, die das Tool verlangt.

Passt die Beschreibung schlecht oder gibt es ein zweites Tool, das allgemeiner formuliert ist und deshalb auch irgendwie passt, gewinnt oft das andere. Bemerkt wird das selten, denn eine Antwort kommt ja.

Wo die Grenze liegt

Ein Tool erweitert, was möglich ist, und ändert nichts daran, wie das Modell arbeitet. Es sagt weiterhin Text voraus. Es kann ein Tool aufrufen, das nicht passt, die Angaben falsch füllen, oder eines vergessen, das gepasst hätte. Für die Fälle, in denen es den Aufruf gar nicht absetzt und das Ergebnis trotzdem berichtet, siehe Kapitel 07.

Was ein Tool Call mitbringt, ist ein Berührungspunkt mit der Wirklichkeit. Was er nicht mitbringt, ist eine Garantie, dass er stattgefunden hat.

Ein Tool Call sieht im Gespräch aus wie eine Handlung. In der Anfrage, die tatsächlich hin und her geht, ist er eine Textstelle mit fester Form.

Was das Modell überhaupt zu sehen bekommt

Zusammen mit Ihrer Frage wird eine Liste mitgeschickt. Je Tool stehen darin drei Dinge: ein Name, eine Beschreibung in Prosa, und ein Schema für die Angaben, die es braucht. Eine Wetterauskunft heißt dann get_weather, wird beschrieben als „Get the current weather for a given location“, und verlangt ein Feld location vom Typ Text.

Die Beschreibung ist dabei kein Beiwerk. Sie ist die ausführlichste Stelle, an der steht, wofür das Tool gut ist, und die Dokumentation nennt sie neben der Frage des Anwenders als das, woran die Wahl hängt:

Claude determines when to call a tool based on the user’s request and the tool’s description. (externe Seite, platform.claude.com)

Der Name und das Schema reden mit. Ein Tool namens suche gegen eines namens suche_im_internen_bestand ist schon eine halbe Entscheidung, und die Beschreibung eines einzelnen Feldes ist eine weitere. Den größten Hebel hat trotzdem die Beschreibung, und warum, steht in Tiefe 3.

Der Rundlauf

Zwei Anfragen ergeben einen Tool Call, nicht eine. Das gilt für Tools, die in Ihrem eigenen Programm laufen; für die des Anbieters steht die Ausnahme im nächsten Abschnitt.

Erste Anfrage. Frage und Tool-Liste gehen hin. Die Antwort ist diesmal kein Fließtext. Sie besteht aus einem Block mit Tool-Name und Angaben, und der Abbruchgrund lautet entsprechend tool_use.

Dazwischen. Ihr Programm liest den Block, prüft ihn und führt aus.

Zweite Anfrage. Die ganze bisherige Unterhaltung geht erneut hin, jetzt ergänzt um das Ergebnis. Erst daraus entsteht der Satz, den Sie am Bildschirm lesen.

Your code executes the operation and sends back a tool_result. (externe Seite, platform.claude.com)

Dass zweimal gefragt wird, erklärt zwei Beobachtungen aus dem Alltag. Eine Antwort mit Tool dauert länger, weil zwei vollständige Durchläufe stattfinden. Und sie kostet mehr, weil beim zweiten Mal die ganze bisherige Unterhaltung erneut mitgeht.

Wie viel mehr, hängt am Cache. Wiedererkannte Teile der Eingabe werden günstiger abgerechnet, und bei den meisten Modellen zählen sie für den Durchsatz gar nicht mit; beides steht in Kapitel 11. Am Platz, den die Unterhaltung im Fenster belegt, ändert das nichts.

Wo der Code läuft

Der Unterschied, der in der Praxis am meisten verwirrt, liegt beim Ort der Ausführung. Anthropic unterscheidet zwei Arten.

	Wer führt aus	Was Sie merken
Tools beim Anwender	Ihr eigenes Programm	Sie schreiben den Ausführungsteil selbst
Tools beim Anbieter	die Infrastruktur des Anbieters	das Ergebnis steht ohne Zutun in der Antwort

Websuche und Seitenabruf laufen beim Anbieter, eine Anbindung an Ihre Warenwirtschaft läuft bei Ihnen. Für das Modell ist beides derselbe Vorgang. Für Ihre Rechnung und Ihren Datenschutz ist es ein großer Unterschied: Was beim Anbieter ausgeführt wird, kommt auch dort vorbei.

Und der Rundlauf von oben sieht anders aus. Ein Tool beim Anbieter braucht keine zweite Anfrage von Ihnen:

Claude runs the search on Anthropic’s infrastructure and returns the cited results in the same response. (externe Seite, platform.claude.com)

Die Dokumentation führt den Rundlauf mit den zwei Anfragen ausdrücklich für ein Tool im eigenen Programm vor. Wer die Zweizahl für das Gesetz hält, sucht bei der Websuche nach einer zweiten Anfrage, die es nie gab.

Was die Tool-Liste kostet

Tools kosten Platz im Kontextfenster, bevor irgendetwas benutzt wird. Drei Posten kommen zusammen.

Ein Sockel, also ein Betrag, der unabhängig von Ihrer Frage anfällt. Sobald überhaupt Tools mitgeschickt werden, setzt der Anbieter eine eigene Systemanweisung davor, die dem Modell das Verfahren erklärt. Für Claude Opus 5 sind das nach der Dokumentation 286 Token (externe Seite, platform.claude.com). Bei älteren Modellen derselben Reihe liegt der Wert deutlich höher, für Claude Opus 4.7 bei 675.

Die Beschreibungen selbst. Namen, Prosatexte und Schemas aller angebundenen Tools, unabhängig davon, ob eines davon zum Einsatz kommt. Zwanzig Tools mit je zehn Zeilen sind ein beachtlicher Vorbau.

Jeder Aufruf und jedes Ergebnis. Beide werden Teil der Unterhaltung und wandern von da an in jeder weiteren Runde mit.

seitlich verschiebbar

eigene Darstellung, Stand 31.07.2026

Das ist der Grund, warum die Anbieter inzwischen Verfahren anbieten, die Tools erst bei Bedarf nachladen, statt alle dauerhaft aufzulisten. Was ein Kontextfenster ist und warum es knapp wird, steht in Kapitel 03.

Wonach ausgewählt wird

Die Dokumentation nennt zwei Bedingungen, und die zweite wird gern übersehen:

It calls a tool when the request maps to that tool’s described capability and the answer isn’t already in context. (externe Seite, platform.claude.com)

Steht die Antwort schon im Gespräch, wird nicht erneut gesucht. Das ist sinnvoll und führt zu der Beobachtung, dass dieselbe Frage beim zweiten Mal ohne Nachschlagen beantwortet wird, mit einem Ergebnis von vorhin, das inzwischen veraltet sein kann.

Die Neigung, überhaupt zu Tools zu greifen, lässt sich verschieben:

This boundary is steerable through your system prompt. (externe Seite, platform.claude.com)

Ein Satz wie „Nutze die Tools zur Recherche, bevor du antwortest“ erhöht die Bereitschaft, ein schärferer Satz erhöht sie weiter. Beides bleibt eine Neigung.

Für Gewissheit gibt es einen eigenen Schalter. Die Schnittstelle kennt eine Einstellung, mit der ein Tool Call verlangt wird: Das Modell muss dann ein Tool nennen, Fließtext als Antwort ist ihm verwehrt. In der Dokumentation heißt dieser Fall „erzwungener Aufruf“, und er kostet ein paar Token mehr als die freie Wahl, weil die Zusatzanweisung länger ausfällt. Der Unterschied ist grundsätzlich: Eine Bitte im Prompt kann das Modell übergehen, diese Einstellung wirkt eine Schicht darunter.

Wenn Angaben fehlen

Ein Tool verlangt bestimmte Felder. Fehlt in Ihrer Frage die Angabe dazu, gibt es zwei Möglichkeiten: nachfragen oder einen plausiblen Wert einsetzen. Beides kommt vor, und welches, hängt vom Modell ab. Die Dokumentation nennt dabei eine Richtung:

Claude Opus is much more likely to recognize that a parameter is missing and ask for it. (externe Seite, platform.claude.com)

Als Beispiel führt sie eine Frage nach dem Wetter ohne Ortsangabe an und zeigt einen Aufruf, in dem New York steht. Ausdrücklich klargestellt ist, dass dieses Verhalten nicht zugesichert ist, und zwar besonders bei mehrdeutigen Eingaben und schwächeren Modellen.

Ein eingesetzter Wert sieht im Aufruf genauso aus wie ein mitgeteilter. Wer fragt „Wie ist das Wetter?“ und eine Auskunft über New York bekommt, sieht der Antwort nicht an, dass der Ort geraten war.

Die naheliegende Gegenmaßnahme hilft dabei nur halb. Die Schnittstelle kennt eine Einstellung, mit der die Form eines Aufrufs zugesichert wird:

Add strict: true to your custom tool definitions to ensure Claude’s tool calls always match your schema exactly. (externe Seite, platform.claude.com)

Zugesichert ist damit, dass location ein Text ist und dass das Feld dasteht. Woher der Text kommt, steht in keinem Schema. Die Frage, ob ein Wert aus Ihrer Frage stammt oder geraten wurde, bleibt beim Programm.

Ein Standard statt vieler Anbindungen

Wie ein Modell einen Aufruf formuliert, war Ende 2024 längst geregelt; das Verfahren gibt es seit Juni 2023 (externe Seite, openai.com). Ungeregelt war die andere Seite, die Anbindung an jede einzelne Datenquelle. Anthropic beschrieb das Problem bei der Vorstellung des Model Context Protocol so:

Every new data source requires its own custom implementation, making truly connected systems difficult to scale. (externe Seite, anthropic.com)

Der Vorschlag dagegen ist ein gemeinsames Protokoll, das verstreute Einzelanbindungen ersetzt (externe Seite, anthropic.com). Ein Tool wird einmal bereitgestellt und ist danach für jedes Programm nutzbar, das den Standard spricht. Für dieses Kapitel ändert das nichts an der Mechanik: Auch über ein Protokoll bleibt es dabei, dass das Modell einen Aufruf nennt und etwas anderes ihn ausführt. Was ein solcher Server mitbringt, was er im Fenster kostet und wem man ihn erlaubt, steht in Agenten und Harness, Kapitel 02.

Dieselbe Frage stellt sich für Geräte im Labor und in der Werkstatt, und seit August 2026 gibt es auch dafür einen Vorschlag. Er steht in KI-Wissen, Kapitel 14.

Wenn der Bildschirm das Tool ist

Die weitestgehende Bauform verzichtet auf eine eigens gebaute Schnittstelle. Seit Oktober 2024 gibt es Modelle, die Rechner so bedienen wie Menschen es tun, durch das Ansehen eines Bildschirms, das Bewegen eines Zeigers, Klicken und Tippen (externe Seite, anthropic.com). Damit lässt sich auch Software anbinden, die nie für Maschinen gedacht war.

Der Anbieter selbst nannte das bei der Vorstellung noch experimentell (externe Seite, anthropic.com) und wies darauf hin, dass Scrollen, Ziehen und Zoomen Schwierigkeiten machen. Was ein Mensch nebenbei tut, ist hier der schwierige Teil.

Wer Tools anbindet, rechnet mit zwei Ausgängen: Der Aufruf klappt, oder er wirft einen Fehler. Der praktisch häufigste Ausgang ist ein dritter, und er sieht von außen aus wie der erste.

Der Aufruf, der nicht stattfindet

Ein Tool, das nicht aufgerufen wird, erzeugt eine plausible Antwort und keinen Fehler. Es gibt mehrere Wege dorthin, und sie liegen in ganz verschiedenen Schichten:

• Das Tool steht gar nicht zur Verfügung, weil eine Allowlist es aussortiert hat oder eine Einstellung nicht griff. Das Modell bekommt trotzdem eine Frage und beantwortet sie.
• Das Tool steht bereit, verliert aber die Auswahl gegen ein anderes, das allgemeiner beschrieben ist.
• Das Modell antwortet mit der Auskunft, es könne das hier nicht ausführen, und setzt den Aufruf gar nicht erst ab. Bei kleineren Modellen kommt das unregelmäßig vor, also nicht reproduzierbar.
• Das Modell formuliert den Aufruf aus und erfindet die Ausgabe gleich mit. Dieser Fall steht mit einem eigenen Vorfall in Kapitel 07.

Der gemeinsame Nenner dieser Fälle ist die Unsichtbarkeit des Fehlers: Der Vorgang läuft durch, es kommt Text heraus, und im Protokoll steht kein Ausrufezeichen. Wer nur auf Abbrüche prüft, misst an all diesen Fällen vorbei.

Was hilft, ist eine Prüfung auf der anderen Seite: Liegt die Wirkung vor. Eine geschriebene Datei, ein Rückgabewert, ein Eintrag in einer Datenbank. Die Umgebung kann das bezeugen, der Ausführende nicht.

Wo die Auswahl wirklich entschieden wird

Die naheliegende Antwort auf eine falsche Tool-Wahl ist eine Anweisung: „Für Fragen dieser Art immer dieses Tool benutzen.“ Sie steht dann in der Systemanweisung oder in einer Datei, die das Modell lesen soll.

Wirksamer ist die Beschreibung im Tool-Schema selbst. Sie ist Teil jeder Anfrage (externe Seite, platform.claude.com) und steht damit unmittelbar neben der Wahl, die getroffen wird. Eine Regel in einer Projektanweisung muss dagegen erst gefunden, dann gedeutet und dann gegen ein Tool durchgesetzt werden, dessen eigene Beschreibung direkt danebensteht. Zwei Schichten Übersetzung mehr, an jeder kann etwas verloren gehen.

Praktisch heißt das: Ein Spezialwerkzeug beschreibt seinen Ort, seinen Zweck und seine Abgrenzung selbst. Ein Tool für interne Bestandsdaten sagt in seiner eigenen Beschreibung, dass dafür nicht im Netz gesucht werden soll. Die Abgrenzung gehört dorthin, wo die Wahl getroffen wird.

Der Grundbetrag wandert mit dem Modell

Sobald Tools mitgeschickt werden, stellt der Anbieter eine eigene Systemanweisung davor, die dem Modell das Verfahren erklärt. Dieser Sockel fällt an, bevor Sie ein Wort geschrieben haben, und sein Umfang steht in der Dokumentation je Modell. Die zweite Spalte gilt für den Fall, dass die Schnittstelle einen Tool Call verlangt, statt ihn dem Modell zu überlassen; die Zusatzanweisung fällt dann etwas länger aus.

Modell	Sockel bei freier Wahl	bei erzwungenem Aufruf
Claude Opus 4.6	497	589
Claude Opus 4.7	675	804
Claude Opus 4.8	290	410
Claude Opus 5	286	406

Stand der Dokumentation am 31.07.2026, Angaben in Token. Zwischen zwei aufeinanderfolgenden Fassungen derselben Reihe liegt einmal der Faktor 2,3, und die Richtung wechselt. Wer den Verbrauch einer Anwendung über einen Modellwechsel hinweg vergleicht, vergleicht damit auch diesen Posten mit, ohne ihn im eigenen Code zu sehen.

Dazu kommen die Beschreibungen aller angebundenen Tools, und die zahlen Sie bei jeder Anfrage, auch bei denen, die kein Tool brauchen. Deshalb gibt es inzwischen Verfahren, die Tools erst bei Bedarf nachladen, statt die gesamte Liste dauerhaft mitzuführen. Wie sich das im Fenster verteilt, zeigt die Zeichnung in Tiefe 2.

Fehler multiplizieren sich

Eine Tool-Schleife über mehrere Schritte hat eine Erfolgsquote, die sich ausrechnen lässt. Bei zehn Schritten mit je 99 Prozent Zuverlässigkeit steht am Ende:

0,99 ^ 10 = 0,904

Gut 90 Prozent, aus lauter Schritten, die einzeln kaum je danebengehen. Bei 95 Prozent je Schritt sind es 60. Dahinter steckt die Kettenregel, und sie erklärt, warum Aufbauten mit vielen Schritten in der Vorführung überzeugen und im Dauerbetrieb enttäuschen.

Die Rechnung setzt dabei mehr voraus, als sie zeigt: dass jeder Schritt für das Ergebnis nötig ist, dass keiner wiederholt wird, und dass die Schritte einander unbeeinflusst lassen. Das letzte trifft in einer Agentenschleife am wenigsten zu. Ein schlecht gelesener erster Befund macht die drei folgenden Schritte gleichzeitig schlechter, und dann rechnet die Formel zu freundlich.

Zwei Folgerungen daraus, beide unbequem:

Ein kürzerer Weg schlägt bessere Glieder, aber erst ab einer Schwelle. Wie groß der Hebel ist, lässt sich ausrechnen. Vier Schritte müssen je 97,6 Prozent erreichen, um mit zehn Schritten zu 99 gleichzuziehen. Bei 97 Prozent liegen sie mit 88,5 darunter, bei 98 mit 92,2 darüber. Sechs Glieder einzusparen ist damit ungefähr anderthalb Prozentpunkte je verbleibendem Glied wert, und wer eine Kette kürzt, sollte diese Rechnung für seinen Fall aufstellen, statt sie zu erwarten.

Der Fehler muss in die Schleife zurück. Ein Tool, das scheitert, sollte das Scheitern als Ergebnis zurückgeben, statt den Vorgang abzubrechen. Dann kann das Modell einen zweiten Versuch machen, und der Fall ist im Verlauf sichtbar.

Bei einem Tool, das etwas ändert, ist dieser zweite Versuch allerdings teuer. Eine ausgebliebene Antwort heißt noch lange nicht, dass nichts passiert ist: Hinter einer Zeitüberschreitung kann eine Buchung stehen, eine verschickte Mail, eine Zeile in einer Datenbank. Wer hier wiederholt, ohne vorher den Zustand abzufragen, macht die Sache zweimal.

Entscheiden und Dürfen sind zwei Schichten

Die wichtigste Bauregel dieses Kapitels ist eine Trennung. Das Modell entscheidet, was versucht wird. Was erlaubt ist, entscheidet das Programm, das den Aufruf entgegennimmt.

Beides in den Prompt zu legen, ist bequem und wirkt nicht. Die Dokumentation sagt es an einer Stelle selbst: Wer einen Aufruf erzwingen will, statt sich auf Formulierungen zu verlassen, stellt das in der Schnittstelle ein (externe Seite, platform.claude.com). Für das Verbieten gilt dasselbe eine Schicht tiefer. Eine Allowlist, die im ausführenden Programm sitzt, wirkt unabhängig davon, was das Modell für eine gute Idee hält.

seitlich verschiebbar

eigene Darstellung, Stand 31.07.2026

Wo die Grenze dieser Trennung liegt, ist inzwischen öffentlich nachlesbar, und zwar aus der Sicht des Angegriffenen. Hugging Face wurde im Juli 2026 selbst zum Ziel und hat den Hergang danach in voller Länge veröffentlicht:

an autonomous AI agent driven by a combination of OpenAI models ran an end-to-end intrusion against our platform (externe Seite, huggingface.co)

Der Angriff kam also von außen. Der Agent lief in der Auswertungsumgebung eines anderen Unternehmens, brach von dort aus und arbeitete sich anschließend über rund 17.600 Aktionen durch eine fremde Plattform, mit erbeuteten Zugangsdaten, Kubernetes-Tokens und Cloud-Schlüsseln.

Eine Einordnung gehört dazu, und sie steht in demselben Bericht:

This evaluation deliberately disabled OpenAI’s production safety classifiers and reduced cyber refusals to measure the underlying model’s raw capability. (externe Seite, huggingface.co)

Ein alltäglicher Werkzeugagent sieht anders aus. Gemessen wurde hier, wozu ein Modell ohne die üblichen Schutzschichten fähig ist. Warum der Agent überhaupt loszog, steht in der Meldung Ein Agent bricht aus der Sandbox aus, und es ist die unheimlichere Hälfte der Geschichte.

Der Punkt, den der Bericht daran betont, ist die Menge statt der Raffinesse:

Volume is what changes the defensive problem. (externe Seite, huggingface.co)

Der zweite Fall zeigt dieselbe Grenze eine Ebene tiefer. Ein Sicherheitsforscher legt Schritt für Schritt offen (externe Seite, accomplish.ai), wie ein Agent aus seiner virtuellen Maschine auf einem Mac ausbricht, und stellt fest, dass der dafür ausgenutzte Fehler der austauschbare Teil der Kette ist. Er arbeitet an einem konkurrierenden Entwurf und schreibt das in seinem Schlussabschnitt dazu. Die Schritte sind einzeln belegt, die Folgerung fällt zugunsten seiner eigenen Bauform aus, und beides gehört beim Lesen nebeneinander.

Daraus folgt eine nüchterne Einordnung: Eine enge Tool-Liste sortiert, sie sperrt nicht ein. Wo ein Agent fremde Eingaben verarbeitet, schützt die Isolierung der Umgebung, und die Tool-Liste kommt obendrauf. Wie sich diese Grenze verschiebt, sobald niemand mehr jeden einzelnen Aufruf bestätigt, steht in Agenten und Harness, Kapitel 01.

Was beim Anbieter ausgeführt wird, war beim Anbieter

Der Unterschied zwischen Tools, die im eigenen Programm laufen, und solchen, die beim Anbieter laufen, ist keine Frage der Bequemlichkeit. Bei den zweiten geht der Aufruf zwangsläufig an eine dritte Stelle, an die Suchmaschine oder an die abgerufene Seite, und zwar einschließlich dessen, was das Modell in die Angaben geschrieben hat. Wer einen Suchbegriff aus einem Kundendatensatz zusammensetzt, hat diesen Datensatz anteilig übergeben, auch wenn im eigenen Code keine Zeile danach aussieht.

Beim eigenen Tool bleibt die Ausführung im Haus, und die Angaben darin waren trotzdem schon draußen: Formuliert hat sie das Modell, und das läuft beim Anbieter. Im Haus bleibt erst beides, wenn auch das Modell dort läuft.

Nachweisen lässt sich das am Protokoll der tatsächlich abgesetzten Aufrufe. Was das Modell in ein Feld schreibt, entscheidet es selbst, und im eigenen Code steht davon nichts.