Tiny Agents und die Kompressionsgrenze

In Tool-Calling im Betrieb steht, was am einzelnen Werkzeugaufruf zerbricht: sechs Übersetzungsschichten, ein Fehlerkatalog, erzwungene Syntax, Reparatur. Diese Seite fängt eine Etage darüber an.

Denn wenn der Agent nicht mehr fünf Werkzeuge bedient, sondern zweihundert, stellt sich eine Frage, die der einzelne Aufruf gar nicht kennt: Welche davon zeigt man dem Modell überhaupt? Und gleich dahinter die zweite, teurere: Was passiert eigentlich mit dem, was diese Werkzeuge zurückgeben?

Zwei Probleme, die dauernd verwechselt werden

Der Branchentrend geht zu immer größeren Agenten: lange Systemprompts, dutzende Fähigkeiten, hunderte Werkzeuge. Was dabei schiefgeht, sind zwei voneinander unabhängige Fehlerquellen - und sie liegen um Größenordnungen auseinander:

Die erste Zeile erzeugt Geisteraufrufe, erfundene Parameternamen, die falsche Wahl zwischen zwei fast gleich klingenden Werkzeugen. Die zweite Zeile erzeugt 40.000 Token gescrapten HTML-Text für eine einzige Zahl - und einen Kontext, der nach drei Aufrufen voll ist.

Das ist die eine Idee, an der auf dieser Seite alles hängt: Es sind zwei Probleme, nicht eines.

Wer filtert, löst das billigere Problem

Die naheliegende Antwort auf zu viele Werkzeuge ist, weniger davon zu zeigen: ein Abruf sucht zur Laufzeit die passenden fünf heraus, der Rest bleibt draußen. Das funktioniert - für die obere Zeile der Tabelle. Aus zweihundert Definitionen werden fünf, aus 40.000 Token Werkzeugbeschreibung werden 1.000.

Nur ändert das an der unteren Zeile nichts. Die fünf ausgewählten Werkzeuge laufen anschließend in demselben Kontext, in dem auch der Dialog steht, und schütten ihre Rohausgaben genau dort aus. Wer nur filtert, hat das Problem gelöst, das je Werkzeug 200 Token kostet, und das ungelöst gelassen, das je Aufruf das Hundertfache kostet.

Für die untere Zeile hilft kein Filter. Da hilft nur eine Grenze.

Eine Grenze statt eines Filters

Die Bauform dahinter hat zwei Ebenen und dazwischen genau eine Naht:

Zwei Ebenen, eine Grenze

Host-Agent

Großes Modell, langer Dialog - und dauerhaft genau drei Werkzeuge im Kontext, egal wie viele Fähigkeiten registriert sind.

• find_capabilityGibt es für dieses Ziel überhaupt jemanden?
• delegateTeilaufgabe abgeben - mit Ziel und den Feldern, die zurückkommen müssen.
• expandIm Rohmaterial nachfragen, das die Zusammenfassung weggelassen hat.

Kompressionsgrenze

Nach oben passiert nur Verdichtetes: Zusammenfassung, geforderte Felder, ein Handle auf das Original.

• web-readerLiest eine Seite und beantwortet eine Frage dazu.
• crm-lookupSchlägt einen Kontakt im CRM nach.
• calendar-readerLiest Termine und findet freie Zeiten.

Jeder Tiny Agent: eigener frischer Kontext, 1-5 Werkzeuge, festes Ausgabeschema, hartes Token-Budget. Fünf davon oder fünfhundert - oben ändert sich nichts.

Ein Tiny Agent ist auf genau eine Fähigkeit spezialisiert: eigener frischer Kontext, ein bis fünf Werkzeuge, ein festes Ausgabeschema, ein hartes Token-Budget. Sein Auftrag ist ausdrücklich nicht „ruf das Werkzeug auf“ - sein Auftrag ist verdichten. Die 40.000 Token entstehen weiterhin, aber sie entstehen unterhalb der Grenze und bleiben dort.

Der Unterschied zum Filter ist der Ort, an dem gespart wird. Ein Filter entscheidet, was in den Kontext hineingeschrieben wird. Die Kompressionsgrenze entscheidet, was ihn überhaupt erreichen darf. Deshalb bleibt der Hauptkontext konstant klein - unabhängig davon, ob fünf oder fünfhundert Fähigkeiten registriert sind. Das ist die Zielgröße dieser Architektur, und es ist eine ungewöhnliche: nicht Trefferquote, sondern Token-Verbrauch im Hauptkontext je gelöster Aufgabe.

Drei Werkzeuge, und dabei bleibt es

Was der Host-Agent sieht, wächst nicht mit. Es sind immer dieselben drei:

• find_capability beantwortet die Frage „gibt es dafür jemanden?“, bevor der Agent sie dem Nutzer zusagt. Und zwar ohne einen einzigen Modellaufruf - die Antwort kommt aus einem Abruf über die angemeldeten Fähigkeiten.
• delegate gibt eine abgegrenzte Teilaufgabe ab. Übergeben wird dabei nicht die Aufgabe im Wortlaut, sondern wonach gesucht wird: ein Ziel in einem Satz und die Felder, die zurückkommen müssen. Diese Explizitheit ist der halbe Trick - was der Host nicht benennen kann, kann er auch nicht delegieren.
• expand fragt im Rohmaterial nach. Denn der Spezialist verdichtet, ohne die Gesamtaufgabe zu kennen; er wirft womöglich genau den Absatz weg, den der Host gebraucht hätte.

Das dritte Werkzeug ist das, was die Kompression überhaupt erträglich macht. Ohne es wäre Verdichtung eine Einbahnstraße: was weggelassen wurde, ist weg. Weil die Rohausgabe unten liegen bleibt statt gelöscht zu werden, ist sie rückholbar - der Host bekommt die kurze Antwort und behält den Zugriff auf das Original. Das ist der Unterschied zwischen einer Zusammenfassung und einem Verlust.

Ein vierter Fall gehört dazu, auch wenn er kein Werkzeug ist: Wenn für ein Ziel niemand zuständig ist, muss das System das sagen dürfen. Ein Abruf liefert immer einen besten Treffer, auch für Unsinn; ohne Schwellwert landet „mach mir ein Butterbrot“ beim nächstbesten Spezialisten. Die ehrliche Fehlanzeige ist hier kein Ausfall, sondern eine Funktion - und nebenbei die ehrlichste Roadmap, die man haben kann: Sie zählt mit, welche Fähigkeit am häufigsten gefehlt hat.

Blätter, keine Bäume

Eine Sache ist an dieser Architektur bewusst unspektakulär: Es gibt genau zwei Ebenen. Tiny Agents dürfen selbst nicht delegieren - sie haben das Werkzeug schlicht nicht.

Das klingt nach einer Einschränkung und ist eine Entlastung. Eine strikte Zwei-Ebenen-Hierarchie macht Rekursion strukturell unmöglich und die Kostenabschätzung trivial: höchstens ein Sprung, immer. Mehrstufige Delegation klingt mächtiger, holt sich aber sofort Zyklenerkennung, vererbte Budgets und Fehler ins Haus, die über drei Ebenen weiterwandern. Wer je einen Agenten debuggt hat, der einen Agenten aufruft, der einen Agenten aufruft, gibt das gern auf.