Ein Modell gibt einen Tool-Aufruf ab, bekommt das Ergebnis zurück und beginnt den nächsten Schritt. Der komplette bisherige Verlauf bleibt dabei im Kontext. Bei Aufgaben über Hunderte von Runden wird diese Schleife zum Kostentreiber: Jede Runde schickt Anweisungen, Werkzeugbeschreibungen und Historie erneut mit. Hier setzt Droid 1.0 an, der Agent-Harness von Factory. Das Team nennt das Update das bislang größte und verfolgt drei Ziele: bessere Ergebnisse auf komplexen Aufgaben, sparsamer Umgang mit Ressourcen und belastbare Kontrollen für den Einsatz in großen Unternehmen.
Der Anspruch ist messbar formuliert: Auf denselben Aufgaben mit denselben Modellen soll Droid bei geringeren Kosten höhere Werte erreichen als die nativen Harnesses der Modellanbieter, nach Angaben des Teams um bis zu 20 Prozent effizienter. Solche Zahlen sind eine Momentaufnahme aus einem bestimmten Testaufbau. Wer sie liest, sollte den Aufbau mitlesen. Wichtiger als der eine Spitzenwert ist die Frage, wie dieser Harness gebaut ist und warum er über verschiedene Modelle hinweg funktioniert.
Was ein Agent-Harness umfasst – und warum die Werkstatt-Metapher hilft
Ein Agent-Harness ist alles, was um das Modell herum liegt: die Prompts, die verfügbaren Werkzeuge, die Form, in der Werkzeugergebnisse zurückkommen, und die Schleife, die das Ganze am Laufen hält. Man kann sich das als Werkstatt vorstellen. Das Modell ist der Facharbeiter, der Harness ist die Werkstatt: wo die Werkzeuge hängen, wie das Material angeliefert wird, wie fertige Teile zurück auf den Tisch kommen und in welchem Takt gearbeitet wird. Ein gut sortierter Betrieb holt aus einem durchschnittlichen Handwerker ein solides Ergebnis. Eine schlecht organisierte Werkstatt ruiniert auch den besten.
Die Analogie zeigt den entscheidenden Punkt: Der Harness verändert nicht das Können des Modells, sondern wie viel davon auf der Strecke bleibt. Bei kurzen Aufgaben fällt das kaum auf. Bei Agenten, die Stunden oder Tage laufen, summiert sich jede unnötige Zeile im Kontext, jede doppelte Anweisung und jede Runde, in der das Modell nur nachfragt, ob ein Job fertig ist. Dort entstehen Kosten, und dort entstehen Fehler, weil spätere Schritte auf einem unaufgeräumten Verlauf aufbauen.
Factory bindet den Harness bewusst nicht an ein Modell. Nutzer können das jeweils beste Modell wählen oder den Router des Anbieters entscheiden lassen, der die Arbeit auf verschiedene Modelle verteilt. Das Team begründet das mit Qualität, nicht nur mit Wahlfreiheit: Wer einen Harness nur gegen ein einziges Modell abstimmt, kann echten Fortschritt kaum von Anpassungen an die Eigenheiten dieses Modells trennen.
Die Vergleichszahlen und was sie über Modellunabhängigkeit sagen
Die Ergebnisse, die das Team nennt, stammen aus Terminal-Bench 4 und vergleichen Droid mit den Harnesses, die üblicherweise direkt zu den Modellen gehören. Mit GPT-6.1 Sol liegt Droid laut diesen Angaben 3,5 Punkte über Codex und arbeitet dabei 12 Prozent günstiger; gegenüber OpenCode und Devin nennt das Team 6,6 bis 12,6 Punkte Vorsprung. Mit Claude Opus 5.5 ergibt sich ein Abstand von 3,0 bis 7,6 Punkten zu Cursor, OpenCode, Devin und Claude Code bei bis zu 24 Prozent geringeren Kosten.
Das sind Anbieterzahlen aus einem definierten Testaufbau. Sie ersetzen keine eigene Messung auf den eigenen Aufgaben. Der methodische Punkt dahinter bleibt relevant: Je länger ein Agent läuft, desto stärker wirkt jeder kleine Vorteil im Harness. Ein besserer Ablauf macht weniger Fehler, auf denen spätere Schritte aufbauen. Ein günstigerer Ablauf erlaubt mehr parallele Agenten im selben Budget. Der Unterschied wächst mit der Länge der Aufgabe, nicht mit dem Schwierigkeitsgrad des ersten Schritts.
Für den Quervergleich über Modelle gilt dasselbe wie für die Werkstatt. Funktioniert eine Verbesserung nur in einer Ecke, war sie wahrscheinlich eine Anpassung an diese Ecke. Funktioniert sie in mehreren, ist sie vermutlich echt. Deshalb prüft das Team nach eigenen Angaben jede Änderung gegen mehrere Modellfamilien, bevor sie ausgeliefert wird.
Programmatischer Tool-Aufruf: ein Arbeitsplan statt einzelner Handgriffe
Die größte Änderung in Droid 1.0 ist der programmatische Tool-Aufruf, englisch programmatic tool calling. Im klassischen Ablauf ruft das Modell ein Werkzeug nach dem anderen auf, und jedes Ergebnis landet direkt im Kontext. Beim programmatischen Aufruf schreibt der Agent stattdessen ein Programm, das die Werkzeuge aufruft, und führt dieses Programm dann in einem Zug aus. Das Prinzip ist nicht neu: CodeAct (Wang et al., 2024) zeigte über 17 Modelle hinweg, dass Handeln über Code bessere Ergebnisse liefert als Aufrufe in JSON oder Text; Cloudflare und Anthropic brachten das Verfahren Ende 2025 in die Produktion.
In der Werkstatt-Metapher heißt das: Der Facharbeiter fordert nicht mehr jeden Handgriff einzeln an und wartet dazwischen auf Antwort. Er schreibt eine Arbeitsanweisung, die die Werkstatt als Ganzes abarbeitet. Alles, was unterwegs an Material anfällt – ganze Dateien, Suchergebnisse, Logs –, bleibt im Programm und taucht nur als Zwischenergebnis in Variablen auf. Erst das, was am Ende gebraucht wird, geht zurück ans Modell.
Das Team nennt drei Gründe, warum dieser Weg zum Standard wurde. Erstens bleibt der Kontext sauber, weil nur die Ausgabe des Programms ankommt. Zweitens sinkt die Zahl der Modellanfragen, weil ein Programm viele Aufrufe bündelt. Drittens wird der Ablauf verlässlicher: Prüfungen und Schleifen laufen deterministisch im Code, und das Modell kann keinen Fall vergessen, den es ursprünglich geplant hatte.
Umgesetzt ist das als Script-Werkzeug. Das Modell schreibt JavaScript, das in einer Sandbox ohne eigenen Datei-, Netzwerk- oder Systemzugriff läuft. Ein Script kann hunderte Tool-Aufrufe in einer einzigen Anfrage ausführen. Voneinander unabhängige Aufrufe laufen parallel, die gedruckte Ausgabe ist in ihrer Größe begrenzt, und die vollständigen Ergebnisse werden an einer Stelle protokolliert, an der das Modell später suchen kann. Der Modus ist standardmäßig für mehrere Modelle aktiv, darunter GPT-6.1 Sol, Claude Opus 5.5, Claude Fable 5 und Kimi K3.
Zwei Beispiele aus den eigenen Sitzungen des Teams zeigen, woher die Ersparnis kommt; Namen und Kennungen sind für die Veröffentlichung geändert. Eine Linear-Aufräumaktion verschob 151 Tickets zwischen Warteschlangen und prüfte jede Verschiebung – 312 Tool-Aufrufe insgesamt. Mit direkten Aufrufen wären nach Schätzung des Teams 36 Anfragen und rund 3,1 Millionen Eingabe-Tokens nötig gewesen; als Script waren es zwei Anfragen und etwa 61.000 Tokens. Der zweite Fall, ein CI-Durchlauf, prüfte 5.384 Desktop-Jobs aus 547 Läufen mit 550 Tool-Aufrufen, jeweils 60 gleichzeitig, in zwei Anfragen statt geschätzter 59 bis 187. Das Modell sah am Ende nur eine Zusammenfassung aus fünf Zahlen, darunter 41 fehlgeschlagene Jobs. Weniger als 0,1 Prozent der Tool-Ergebnisse erreichten seinen Kontext.
Die Verteilung ist ungleich: Die meisten Scripts sind klein, und die Einsparung konzentriert sich auf die 12,5 Prozent, die sechs oder mehr Tool-Aufrufe machen. Insgesamt senkte der Script-Modus die Kosten auf Claude Opus 5.5 nach Angaben des Teams um 15 Prozent. Entscheidend ist also nicht die Zahl der Aufrufe, sondern wie viel davon am Ende im Kontext landet.
Designentscheidungen, an denen programmatische Aufrufe scheitern oder gelingen
Programmatische Tool-Aufrufe sind schnell eingebaut und leicht falsch gemacht. Das Team beschreibt eine Reihe von Entscheidungen, die den Unterschied ausmachen, und sie lesen sich wie Handwerksregeln. Programme bekommen echte Daten statt Auszüge: ganze Dateien sowie strukturierte, typisierte Suchergebnisse, damit Filtern und Zählen im Code stattfindet und keine Tokens kostet. Wörtlicher Text reist roh: Dateiinhalte, Patches und Befehle gehen als Rohblöcke in die Anfrage statt als maskierte Zeichenketten. Das spart Tokens und reduziert fehlerhafte Aufrufe.
Änderungen kommen kurz zurück. Ein Edit innerhalb eines Programms liefert dieselbe knappe Zusammenfassung wie ein direkter Edit, statt die ganze Datei erneut in den Kontext zu kleben. Der Agent blockiert nie auf einem langen Job: Ein Programm wartet bis zu fünf Minuten, gibt dann seine bisherige Ausgabe zurück. Alternativ startet es sofort im Hintergrund, während das Modell weiterarbeitet. Ob ein Hintergrundjob fertig ist, prüft ein eigenes Werkzeug. Droid weckt das Modell, wenn die Arbeit abgeschlossen ist, statt Anfragen fürs Nachfragen zu verbrennen.
Die Agent Factory: wie der Harness mit neuen Modellen Schritt hält
Der Script-Modus und die Entscheidung, ihn pro Modell an- oder abzuschalten, stammen aus derselben Schleife, aus der die meisten Änderungen an Droid kommen. Neue Modelle und Snapshots erscheinen alle paar Wochen; kein Team kann einen Harness für jedes davon von Hand nachziehen. Deshalb hat Factory eine interne Agent Factory gebaut: Eine Automatisierung verfolgt mehr als 20 Modelle, sobald eines zugänglich wird, prüft es gegen Verhaltenszusagen und nimmt es danach in laufende Umgebungen, QA und tägliche Benchmark-Läufe auf. Fehlerprotokolle aus dem Betrieb und die Reibung, die Nutzer in echten Sitzungen erleben, fließen in dieselbe Auswertung ein.
Ein einzelner Fehlschlag sagt wenig, deshalb sucht der auswertende Agent nach Ursachen, die sich über Aufgaben und Modelle hinweg wiederholen. Jeder Fund wird zu einem Vorschlag mit ausdrücklicher Hypothese, und ein kontrolliertes Experiment misst die Änderung auf jedem Modell, das sie betrifft. Ingenieure lesen den Vorschlag samt Belegen und entscheiden, was ausgeliefert wird. Damit Vorschlag und Prüfung dieselbe Vorstellung davon haben, was eine gute Änderung ist, gelten feste Prinzipien: jeden Token budgetieren, große Tool-Ergebnisse in Dateien halten, den Prompt-Cache pflegen, den heißen Pfad zur Inferenz profilieren, Hintergrundarbeit verfolgen und das Modell wecken, wenn sie fertig ist – und für den Fall, dass der Agent feststeckt, immer einen nächsten Schritt bereithalten.
Ein Detail zeigt, wie fein die Schleife greift. Damit ein Modell Dateien nicht über die Shell erneut liest, nur um Zeilennummern zu bekommen, wurden alle Zeilen jeder gelesenen Datei durchnummeriert. Das senkte die Kosten auf Opus in einer Aufgabe um 22 Prozent, kostete aber rund zwei Tokens pro Zeile zusätzlich. Auf GLM erhöhte es die Kosten um 8 Prozent, auf Kimi um 32 Prozent – Modelle, die davon nichts hatten. Ausgeliefert wurde es deshalb als Option, die das Modell anfordert, wenn es Zeilennummern braucht.
Was das für Enterprise-Entwicklung konkret bedeutet
Für Teams, die KI-Agenten in großen Codebasen einsetzen, verschiebt sich der Ort der Arbeit. Die Modellwahl bleibt wichtig, ist aber nicht mehr die einzige Stellschraube. Ein erheblicher Teil von Kosten, Geschwindigkeit und Zuverlässigkeit entsteht in der Schicht darüber: wie Werkzeuge beschrieben sind, wie Ergebnisse zurückkommen und wie viele Runden eine Aufgabe braucht. Wer diese Schicht als Wegwerf-Wrapper behandelt, verschenkt die Effizienz, die Droid 1.0 vorführt.
Skepsis bleibt angebracht. Die genannten Zahlen sind vom Anbieter berichtet, auf fremden Benchmarks erhoben und in einem herstellereigenen Testaufbau ermittelt; sie zeigen, was ein gut gebauter Harness leisten kann, nicht was er in deiner Umgebung leisten wird. Der praktisch prüfbare Kern ist unspektakulär: weniger Modellanfragen pro Aufgabe, weniger Rohdaten im Kontext, deterministische Prüfungen statt modellabhängiger Sorgfalt. Ob das zu deinen Repositories, Ticketsystemen und Freigabeprozessen passt, zeigt sich erst im eigenen Test.
Quelle: factory.com
