Warum KI-Agenten am Harness scheitern — nicht am Modell

Writer zeigt ein günstigeres Agenten-Setup

Viele Teams suchen bei teuren KI-Agenten reflexhaft nach einem stärkeren oder billigeren Modell. Der Writer-Befund dreht genau diese Intuition um. Laut dem von VentureBeat beschriebenen Setup wurden nicht die Foundation Models ausgetauscht, sondern die Schicht darum herum optimiert: der sogenannte Harness, also die Orchestrierung aus Prompt-Aufbau, Kontextverwaltung, Tool-Routing und Fehlergrenzen. Ergebnis laut Quelle: deutlich weniger Tokens pro Aufgabe, spürbar niedrigere Kosten und kürzere Laufzeiten, ohne dass die Aufgabenerfüllung sichtbar einbrach.

Für B2B-Leser ist das deshalb relevant, weil hier ein anderer Hebel sichtbar wird als in vielen Modellvergleichen. Wenn die eigentlichen Kosten im laufenden Betrieb nicht nur durch den Preis pro Token entstehen, sondern durch die Zahl der immer wieder gesendeten Tokens pro Task, dann liegt ein großer Teil der Wirtschaftlichkeit in einer Schicht, die Unternehmen selbst beeinflussen können. Das ist kein kleiner Architekturhinweis, sondern eine Management-Frage: Wer seinen Agenten-Stack produktiv skaliert, entscheidet nicht nur über Modellqualität, sondern über Unit Economics. Genau deshalb lohnt auch der Blick auf unseren Kontextbeitrag Warum KI-Agenten nicht am Modell scheitern, sondern am Kontext.

Was die Writer-Studie wirklich gemessen hat

Gerade weil die versprochenen Einsparungen attraktiv klingen, ist die Einordnung wichtiger als die Prozentzahl. Laut VentureBeat wurden sechs Modelle über mehrere Anbieter hinweg auf 22 festen Enterprise-Aufgaben verglichen, während die zugrunde liegenden Modelle konstant blieben und nur der Agenten-Harness verändert wurde. Das ist methodisch sinnvoll, weil es den Effekt der Orchestrierung isolieren soll. Gleichzeitig bleibt der Befund herstellernah: Die Studie stammt aus dem Writer-Umfeld, die öffentlich zugängliche Darstellung läuft über einen Medienbericht, und im vorliegenden Material ist keine unabhängig replizierte Benchmark-Version des vollständigen Versuchsaufbaus belegt.

Das heißt nicht, dass der Befund wertlos wäre. Im Gegenteil: Als Architektur-Signal ist er stark. Aber er ist kein Freifahrtschein für die Aussage, jeder Agent werde automatisch 40 Prozent billiger, sobald ein Team ein paar Prompts umsortiert. Die tatsächliche Wirkung hängt an Workload, Tool-Landschaft, Modellstärke, Wiederholungsgrad und daran, wie chaotisch der bestehende Loop heute schon ist. Wer die Zahlen sauber liest, sieht daher eher eine belastbare Richtung als ein universelles Leistungsversprechen.

So funktioniert der Harness als Kostenschicht

Der Begriff Harness klingt technisch, meint aber etwas sehr Praktisches: die Betriebslogik zwischen Nutzeranfrage und Modellantwort. Dort wird entschieden, welche Anweisungen immer gleich bleiben, welche Informationen der Agent in diesem Schritt wirklich sehen muss, welche Tools überhaupt im Kontext landen und wann ein Lauf gestoppt wird.

Ein zentraler Hebel ist Prompt-Caching. OpenAI beschreibt in der eigenen API-Dokumentation, dass Caching an wiederkehrenden Prompt-Präfixen hängt. Übersetzt in Alltagssprache: Wenn ein Team seine dauerhaften Regeln, Tool-Schemata und Standardanweisungen stabil am Anfang hält und die wechselnden Nutzerdaten später anhängt, kann derselbe Präfix öfter wiederverwendet werden. Damit wird Prompt-Layout plötzlich zu einer Kostenentscheidung statt zu bloßer Formatkosmetik.

Der zweite Hebel ist Kontext-Offloading. Writer beschreibt in seinem Engineering-Material Context Engineering als Disziplin des Speicherns, Auswählens, Komprimierens und Isolierens von Kontext. Statt jede Zwischenantwort, jeden Tool-Output und jede Fehlermeldung in einen immer größeren Monolithen zu kippen, lagert ein reifer Harness Historie und Artefakte außerhalb des Fensters aus und zieht nur das zurück, was der aktuelle Schritt wirklich braucht. Das ist wichtig, weil viele Agenten nicht am Denken scheitern, sondern am ständigen Wiederholen von bereits Bekanntem.

Dritter Hebel ist Tool-Routing. Wenn ein Modell bei jeder Aufgabe einen ganzen Werkzeugkasten im Prompt mitträgt, steigen Tokens und Verwechslungsgefahr zugleich. Writer argumentiert im RAG-MCP-Beitrag deshalb für ein System, das relevante Tools zuerst semantisch auswählt, komprimiert und nur die passende Teilmenge in den laufenden Kontext gibt. Der technische Punkt dahinter ist simpel: Ein Modell trifft bessere Entscheidungen, wenn es weniger irrelevanten Ballast mit sich herumschleppt.

Viertens geht es um harte Grenzen für Agenten-Loops. OpenAI beschreibt agentische Abläufe im Codex-Loop-Beitrag ausdrücklich als Systemproblem mit Planung, Werkzeugen und iterativen Schritten. Genau deshalb darf Kostenkontrolle nicht an das Modell delegiert werden. Ein produktiver Harness braucht Budgetgrenzen, Limits für Schritte und Tool-Calls sowie Regeln dafür, wann ein fehlschlagender Lauf abgebrochen wird. Sonst wird aus einer schlechten Aufgabe schnell die teuerste Aufgabe des Tages.

Was 38 Prozent weniger Tokens und 41 Prozent weniger Kosten bedeuten

Der wichtigste Satz fuer Entscheider lautet nicht, dass Tokens billiger geworden sind, sondern dass unnoetige Tokens pro Aufgabe zu einem strukturellen Kostenproblem werden. Genau dort setzt der Writer-Befund an: Wenn ein Agent bei jedem Schritt denselben Kontext erneut mitsendet, Suchergebnisse roh in die Hauptkonversation kippt und Fehler in endlosen Schleifen bearbeitet, wachsen Kosten und Wartezeiten oft schneller als die sinkenden Modellpreise sie ausgleichen.

Deshalb sind die berichteten Verbesserungen betriebswirtschaftlich interessanter, als sie auf den ersten Blick wirken. Weniger Tokens pro Task bedeuten nicht nur niedrigere API-Rechnungen. Sie bedeuten oft auch kuerzere Antwortzeiten, weniger Last in Folgeprozessen und besser vorhersehbare Grenzkosten pro Workflow. Das ist fuer Unternehmen entscheidend, die von Pilotprojekten in produktive Volumina gehen. Ein Agent, der im Demo-Umfeld funktioniert, kann in Produktion ploetzlich an genau dieser Mathematik scheitern.

Hinzu kommt ein qualitativer Punkt: Wenn die Erfolgsrate laut Quelle trotz sinkender Tokenzahl in etwa stabil blieb, dann spricht das gegen die verbreitete Annahme, dass mehr Kontext automatisch mehr Qualitaet bringt. In vielen Faellen ist das Gegenteil plausibler: Mehr Kontext bedeutet auch mehr irrelevantes Material, mehr Wiederholung und mehr Chancen fuer den Agenten, sich in seinem eigenen Verlauf zu verheddern. Redaktionell eingeordnet heisst das: Nicht jede Sparmassnahme macht den Agenten besser, aber ein sauberer Harness kann Kosten senken, ohne die Aufgabe inhaltlich zu entkernen.

Daran erkennen Teams unnötige Token-Kosten

Die erste Diagnosefrage lautet: Welche Teile Ihres Systemprompts sind bei hundert Aufrufen identisch, werden aber jedes Mal voll neu mitgeschickt? Wenn die Antwort lautet "fast alles", bleibt vermutlich Cache-Potenzial liegen.

Die zweite Frage: Wie viel Verlauf sieht der Agent wirklich — und wie viel davon braucht er fuer den aktuellen Schritt? Wenn jede Fehlermeldung, jede Suchantwort und jeder Zwischenstand einfach an den bisherigen Verlauf angehaengt wird, ist das kein Zeichen von Robustheit, sondern oft von fehlender Kontextdisziplin.

Dritte Frage: Muss der Hauptagent wirklich alle Tools gleichzeitig kennen? Oder koennte eine vorgelagerte Auswahl nur die relevante Teilmenge bereitstellen? Gerade bei breiten MCP- oder API-Setups ist das ein typischer Ort fuer stillen Token-Muell.

Vierte Frage: Was passiert nach dem ersten Fehlschlag? Hat Ihr System danach einen kleineren Suchraum, haertere Regeln und klare Stop-Bedingungen? Oder darf der Agent einfach weiterprobieren, bis das Budget leer ist? Wer hier keine sauberen Grenzen hat, sollte den Artikel Warum smarter KI-Cache Systeme langsamer machen kann gleich mitdenken: Jede Optimierungsschicht spart nur dann Geld, wenn ihr eigener Overhead kleiner bleibt als das, was sie einspart.

Am Ende ist das die praktischste Lehre aus dem Writer-Fall: Viele Teams messen Modellkosten, aber nicht Kosten pro erfolgreicher Aufgabe. Genau dieser Perspektivwechsel ist noetig, sobald Agenten nicht mehr als Demo, sondern als Betriebsprozess laufen.

Wo die Harness-Idee noch an Grenzen stößt

So überzeugend die Richtung ist, so wichtig bleibt die Grenze: Mehr Orchestrierung ist nicht automatisch besser. Jede zusätzliche Schicht erzeugt selbst Tokens, Koordination und Betriebsaufwand. Wenn ein kleineres Modell einen großen Teil seiner knappen Kapazität darauf verwendet, Struktur, Delegation und Metaregeln zu verstehen, kann die angebliche Optimierung die Aufgabe sogar verschlechtern. Genau deshalb ist der Hinweis aus dem Brief zentral, dass Multi-Agenten-Delegation nicht für jedes Modell gleich zuverlässig wirkt.

Daraus folgt eine nüchterne Regel: Teams sollten Harness-Features nicht nach Eleganz, sondern nach Nettoeffekt bewerten. Spart eine neue Routing- oder Kompressionsschicht tatsächlich mehr Task-Tokens, als sie an Koordination kostet? Wenn nicht, gehört sie wieder raus. Diese Denkweise ist für viele KI-Projekte ungewohnt, weil dort lange das Motto galt: mehr Kontext, mehr Tools, mehr Schleifen gleich mehr Intelligenz. Im Produktionsbetrieb gilt oft das Gegenteil.

Hinzu kommt die methodische Grenze der Quelle. Die beschriebenen Ergebnisse liefern einen plausiblen und gut anschlussfähigen Mechanismus, aber keinen finalen Branchenbeweis. Wer große Architekturentscheidungen daraus ableitet, sollte deshalb die Idee übernehmen, nicht blind die Zahl. Das heißt konkret: eigene Baselines erfassen, Erfolgsmetriken pro Task definieren und zunächst dort optimieren, wo die Wiederholung am höchsten und das Schleifenrisiko am größten ist.

Was sich im Alltag von Agenten-Workflows ändert

Für CTOs und Plattformteams verschiebt sich damit die Priorität. Die Leitfrage lautet weniger: Welches Modell ist heute auf dem Papier am stärksten? Wichtiger wird: Welche Schicht kontrolliert, was der Agent sehen, nutzen, wiederholen und ausgeben darf? Wer den Harness besitzt, besitzt einen großen Teil der Kosten- und Betriebslogik.

Das verändert auch die Arbeitsaufteilung. Fachbereiche profitieren zwar von schnelleren, günstigeren Agenten-Workflows, aber die Hebel dafür liegen selten allein im Prompt eines einzelnen Use Cases. Sie liegen in gemeinsamen Regeln für Kontext, Tool-Zugriff, Budgets und Abbruchlogik. Genau deshalb nähert sich der Markt insgesamt Plattformmustern an, bei denen Runtime, Governance und Orchestrierung wichtiger werden — mehr dazu in Amazon, Microsoft und Google nähern sich derselben Agenten-Architektur an.

Die nüchterne Schlussfolgerung lautet daher: Unternehmen müssen nicht auf das nächste Wunder-Modell warten, um ihre Agenten wirtschaftlicher zu machen. Oft reicht es schon, die verschwenderischste Schicht des Systems ernst zu nehmen. Nicht jeder Workflow braucht einen ausgefeilten Harness. Aber jeder produktive Workflow braucht die Frage, ob er Kontext wiederkaut, Werkzeuge zu breit streut und Fehler zu teuer eskalieren lässt. Genau dort liegt meist der schnellere Hebel als im nächsten Modellwechsel.