Ein neuer Satz aus der Agenten-Forschung klingt erst einmal trocken: Tool Calls sollen Code werden. Aber wenn das stimmt, dann verschiebt sich gerade, worum es bei guten KI-Agenten wirklich geht. Servus, ich bin Lissy. Heute geht es um den Werkzeugkasten drumherum: wie Agenten Tools aufrufen, wie sie ihren eigenen Arbeitsaufbau verbessern, wie sie üben, und wie man misst, ob sie wirklich besser werden.
Fangen wir mit dem Paper The Bitter Lesson of Tool Calling an. Die Kernidee ist ziemlich simpel und ziemlich folgenreich. Heute funktionieren viele Agenten so: Das Modell wählt ein Werkzeug, füllt ein JSON-Objekt aus, und das System führt den Aufruf aus. Das ist ordentlich, kontrollierbar und für Produktteams angenehm. Aber es ist auch steif. Sobald ein Agent Werkzeuge verketten oder parallel starten soll, wird aus einem sauberen Tool Call schnell ein Orchestrierungsproblem. Das Paper testet deshalb programmatic tool calling. Die Werkzeuge werden dem Modell als typisierte Python-Stubs gegeben. Der Agent schreibt also nicht nur Argumente in ein JSON-Feld, sondern erzeugt ein kleines Stück Code, das Tools kombiniert, Ergebnisse speichert und bei Bedarf mehrere Dinge parallel auslöst. Getestet wurde auf BFCL v4 über vierzehn Sprachmodelle. Programmatic tool calling erreicht oder übertrifft klassisches JSON-Tool-Calling bei elf von vierzehn Modellen. Bei der GPT-5.6-Familie nennen sie 10,6 Prozent Verbesserung gegenüber der JSON-Baseline. Unter parallelem Fan-out ist der Ansatz bei dreizehn von vierzehn Modellen mindestens gleich gut oder besser. Und bei sogenanntem Context Rot bleibt er stabiler, während die Baseline im Schnitt um 2,3 Prozent nachgibt. Für alle, die Automatisierung bauen, steckt darin eine unangenehme Wahrheit: Vielleicht ist der Chatbot mit Knöpfen nur eine Zwischenform. Wenn Modelle gut genug Code schreiben, dann wollen sie Werkzeuge eher wie Entwickler benutzen, nicht wie Formularausfüller. Der Vorteil ist klar: mehr Flexibilität, weniger starre Router, mehr echte Arbeitsabläufe. Der Preis auch: Sobald das Modell Code schreibt, braucht man Sandboxing, Rechte, Logging, Tests und klare Aktionsgrenzen. Ein Agent, der sein Werkzeugprogramm selbst baut, ist mächtiger. Aber er ist auch ein Stück weniger gemütlich zu kontrollieren.
Dazu passt HarnessOpt-Bench. Das ist ein Benchmark, der eine Sache misst, die in Produktgesprächen oft untergeht: Das Modell zählt, aber der ganze Harness zählt mit. Also Prompts, Tools, Kontrollfluss, Memory und Auswertungen. Viele Teams reden über Agenten so, als wäre die Frage nur: Nehme ich Modell A oder Modell B. In der Praxis ist das oft zu grob. Zwei Systeme mit demselben Modell können völlig unterschiedlich arbeiten, wenn eines bessere Tool-Beschreibungen, bessere Zwischenschritte und bessere Fehlerkontrolle hat. HarnessOpt-Bench schaut deshalb darauf, ob ein LLM den Harness selbst verbessern kann. Ein System schlägt Änderungen am Setup vor. Danach wird auf gehaltenen Aufgaben gemessen, ob die Änderung wirklich besser ist. Sonst optimiert man sich nur auf die Beispiele schön, die man gerade vor der Nase hat. Für mich ist das einer der praktischen Punkte des Tages. Wenn Agenten in Firmen nützlich werden sollen, reicht das neueste Modell nicht. Man muss den Arbeitsaufbau iterieren wie Software: versionieren, testen, zurückrollen, messen. Das klingt weniger sexy als Frontier-Modell, spart aber wahrscheinlich mehr Geld. Und da wird es unternehmerisch interessant. Ein kleines Team kann nicht immer das teuerste Modell in jede Aufgabe werfen. Aber ein kleines Team kann oft den besseren Harness bauen. Es kann Tools genauer beschreiben, Fehlerfälle sammeln, Rechte eng schneiden und den Ablauf an den eigenen Betrieb anpassen. Das ist kein Zauber. Das ist gutes Systemdesign. Genau deshalb ist dieses Thema mehr als Agenten-Nerdkram. Der Wettbewerb verschiebt sich von der Frage, wer den größten Motor kauft, hin zur Frage, wer das bessere Getriebe baut. Und das ist eine viel offenere Frage.
Das dritte Puzzleteil heißt EnvACE. Dahinter steckt ein Problem, das jeder versteht, der schon einmal einen Agenten länger als drei Schritte laufen ließ: Training über echte Umgebungen ist teuer und fragil. Wenn ein Agent Browser, Terminal, Dateien oder APIs bedienen soll, kostet jede Trainingsspur echte Ausführung. Bei langen Arbeitsabläufen wird das teuer, langsam und schwer reproduzierbar. EnvACE schlägt dafür World Rehearsal vor. Der Agent soll Teile der Umgebungsdynamik intern üben, statt immer wieder echte Tools auszuführen. Vereinfacht gesagt: Das Modell lernt wahrscheinliche Folgen von Aktionen und probt damit Zwischenwege, bevor reale Verifikation nötig wird. Das ist kein Freifahrtschein für Fantasie-Agenten. Im Gegenteil. Wenn die interne Welt falsch driftet, trainiert man einem Agenten sehr selbstbewusstes Wunschdenken an. Der Nutzen entsteht nur, wenn interne Probe und echte Prüfung sauber getrennt bleiben. Erst üben, dann an der Realität messen. Trotzdem ist die Richtung wichtig. Agenten werden nicht zuverlässig, indem man ihnen einfach mehr Kontext gibt und hofft. Sie brauchen Übungsschleifen. Sie brauchen Umgebungen, in denen Fehler billig sind. Und sie brauchen Prüfstellen, die zeigen, ob eine Aktion wirklich etwas bewirkt hat. Für Unternehmen heißt das: Die Zukunft guter Agenten liegt wahrscheinlich nicht in einem einzelnen großen Prompt. Sie liegt in Trainings- und Testumgebungen für konkrete Arbeitsabläufe. Ein Agent für Buchhaltung, Support oder Security wird erst dann interessant, wenn er billig üben kann, bevor er echte Rechte bekommt.
Und dann kommt AV-AIVAT mit einer Zahl, die hängen bleibt: bis zu 74-mal günstigere Agenten-Evaluation im getesteten Setting. Das Paper arbeitet mit Spielen mit unvollständiger Information, vor allem Poker-ähnlichen Umgebungen. Klingt erst einmal weit weg von Office-Agenten, ist aber als Messproblem extrem passend. Wenn zwei Agenten gegeneinander antreten, weiß man nicht sofort, welcher besser ist. Glück, Zufall und Varianz überdecken die eigentliche Fähigkeit. Bei festen Eval-Budgets zahlt man oft zu lange weiter, oder man stoppt zu früh und hält Rauschen für Fortschritt. AV-AIVAT kombiniert Varianzreduktion mit anytime-valid stopping. Die Auswertung schaut laufend auf die Evidenz und darf stoppen, sobald sie reicht, ohne die statistische Garantie kaputtzumachen. Im Abstract nennen die Autoren, dass rohe Ergebnisse im Median 74-mal so viele Hände brauchen wie AIVAT-korrigierte Ergebnisse, um mit einer asymptotischen Confidence Sequence zu stoppen. Das ist nicht automatisch 74-mal billiger für jeden Coding-Agenten oder jedes Backoffice-System. Die Domäne ist speziell. Aber die Lektion ist größer als Poker. Agenten sind teuer zu bewerten, weil ihre Leistung über lange, variable Abläufe entsteht. Wenn Evaluation billiger und auditierbarer wird, können Teams häufiger testen. Genau das trennt Demo und Betrieb. Das verbindet alle heutigen Papers. Tool Calls als Code machen Agenten flexibler. Harness-Optimierung verbessert den Aufbau. World Rehearsal verbilligt Üben. Evaluation zeigt, ob es geholfen hat. Mei, das klingt weniger nach Science-Fiction als nach Maschinenraum. Aber genau dort entscheidet sich, ob Agenten irgendwann echte Arbeit schaffen oder nur schöne Bildschirmaufnahmen produzieren.
Worauf ich heute komme: Bei KI-Agenten wird der unsichtbare Teil wichtiger. Entscheidend ist, welche Werkzeuge ein Modell bekommt, wie es sie kombiniert, wie es übt und wie streng man misst. Für Gründer und kleine Teams ist das eigentlich eine gute Nachricht. Man muss nicht überall das größte Modell kaufen. Man kann oft beim Aufbau gewinnen: bessere Tool-Grenzen, bessere Tests, klarere Rechte, mehr echte Rückmeldung. Wenn euch solche Folgen helfen, schreibt mir gern eine Mail, die Adresse steht in den Shownotes. Oder lasst eine Bewertung auf Spotify oder Apple Podcasts da. Das war die Daily AI News mit Lissy. Pfiat euch und bis morgen.