Bei langen Agentenläufen entsteht ein Fehlschlag selten durch einen einzigen schlechten Prompt. Häufig greifen unklare Werkzeugbeschreibungen, fehlende Hilfsfunktionen, ungeeignete Abbruchregeln und kleine Steuerungsfehler ineinander. AutoSaddler soll genau diese äußere Agentenschicht automatisch verbessern: den Harness aus Prompts, Tools, Middleware und Kontrolllogik. Für Unternehmen ist das interessant, weil damit nicht nur das Modell, sondern der ausführbare Prozess zum Optimierungsgegenstand wird. Es erhöht aber auch das Risiko, dass eine automatisch erzeugte Verbesserung an anderer Stelle eine Regression oder eine neue Berechtigungslücke verursacht.
Wie AutoSaddler einen Harness verändert
Die Autoren beschreiben AutoSaddler als Offline-Lernverfahren über Ausführungstraces. Ein vorhandener Harness wird auf einem Mini-Batch von Aufgaben ausgeführt. Anschließend diagnostiziert ein Agent die fehlgeschlagenen Verläufe, sucht nach Ursachen im Harness und erzeugt gezielte Patches. Diese können Promptregeln, Werkzeugdefinitionen und -implementierungen, Middleware-Hooks oder die Agentenschleife betreffen. Der Ansatz behandelt den Harness damit als versionierbaren Code statt als lose Sammlung manueller Prompt-Anpassungen.
Nicht jeder lokal erfolgreiche Patch wird übernommen. AutoSaddler vergleicht Ergebnisse, hält Lernerfahrungen in einer Entwicklungshistorie fest und prüft Kandidaten auf einem separaten Validierungssatz. Ziel sind Änderungen, die über den beobachteten Einzelfehler hinaus generalisieren. Laut Ablationen der Autoren helfen dabei drei Elemente: tiefgehende Fehlerdiagnose statt kurzer Selbstreflexion, strukturierte Eingriffe statt freier Änderungen und eine Auswahl, die Generalisierung ausdrücklich bewertet.
Was die Benchmarks zeigen – und was nicht
Die Autoren berichten gegenüber den jeweiligen Basisharnesses Verbesserungen von 9,0 Prozentpunkten auf GAIA2, 9,6 Punkten auf SWE-Bench Pro und 10,0 Punkten auf Terminal-Bench 2.0. Die öffentlich dokumentierten Pass@1-Werte steigen dabei von 53,0 auf 62,0 Prozent, von 37,3 auf 46,9 Prozent und von 40,0 auf 50,0 Prozent. Diese Ergebnisse sprechen dafür, dass die Methode in unterschiedlichen langen Aufgabenformaten nützliche Harness-Änderungen finden kann.
Sie sind jedoch keine Garantie für einen Unternehmensprozess. Die Arbeit setzt Trainingsaufgaben mit Goldantworten und einer eindeutigen Erfolgsmetrik wie bestanden oder fehlgeschlagen voraus. Solche Labels fehlen in vielen realen Abläufen oder sind teuer zu erstellen. Außerdem untersuchen die Autoren zustandslose, voneinander unabhängige Aufgaben. Prozesse mit dauerhaftem Gedächtnis, wechselnden Nutzerrechten oder gemeinsamem Zustand liegen außerhalb des nachgewiesenen Umfangs. Auch die Übertragbarkeit auf weitere Modellfamilien bleibt laut Paper offen.
Entscheidungsrahmen für einen sinnvollen Pilot
- Klares Zielsignal: Für jede Pilotaufgabe existiert ein prüfbares Ergebnis, nicht nur eine subjektive Qualitätsbewertung.
- Repräsentative Traces: Fehlgeschlagene Läufe dürfen analysiert werden und enthalten keine unkontrolliert weitergegebenen Geheimnisse oder Personendaten.
- Begrenzter Änderungsraum: Zulässige Prompt-, Tool- und Middleware-Patches sind vorab definiert; Berechtigungen dürfen nicht automatisch wachsen.
- Getrennter Testsatz: Ein unabhängiger Validierungssatz schützt davor, einzelne Fehlerfälle zu reparieren und den Gesamtprozess zu verschlechtern.
- Reversibler Betrieb: Jeder Kandidat ist versioniert, überprüfbar und mit einem getesteten Rollback verbunden.
Am besten eignet sich zunächst ein interner, häufig wiederholter Prozess mit messbarem Ausgang und begrenztem Schaden. Ein Coding- oder Recherche-Agent in einer isolierten Umgebung ist plausibler als ein Agent, der ohne Freigabe Zahlungen, Verträge oder Kundendaten verändert. Fehlt ein verlässliches Erfolgssignal, optimiert das System sonst möglicherweise nur eine unvollständige Kennzahl.
Vier Gates für sichere Harness-Updates
- Daten-Gate: Traces minimieren, sensible Inhalte entfernen und Aufbewahrung sowie Zugriffsrechte dokumentieren.
- Qualitäts-Gate: Kandidaten gegen Basisversion, Validierungssatz und gezielte Regressionstests vergleichen.
- Sicherheits-Gate: Neue Tools, Hooks und Kontrolllogik auf Rechteausweitung, Injection-Pfade und unerlaubte Datenflüsse prüfen.
- Betriebs-Gate: Änderung, Begründung, Testergebnisse, Modellversion und Rollback in der normalen Freigabekette festhalten.
Im Sicherheits-Gate zählen Angriffsmöglichkeiten, Datenabfluss und unerlaubte Werkzeugaufrufe. Das Qualitäts-Gate verhindert, dass ein lokaler Erfolg den Prozess insgesamt verschlechtert. Das Betriebs-Gate verlangt eine reproduzierbare Bereitstellung und einen schnellen Rollback. Erst wenn alle vier Perspektiven bestehen, sollte ein Kandidat erweitert oder auf weitere Aufgaben übertragen werden.
Zusätzlich braucht jeder Pilot eine klare Eigentümerschaft. Das Fachteam definiert richtige Ergebnisse und akzeptable Ausnahmen, Engineering verantwortet Harness und Testumgebung, Security prüft Rechte und neue Angriffspfade. Vorab festgelegte Abbruchkriterien verhindern, dass steigende Erfolgswerte problematische Änderungen verdecken. Ein Lauf muss gestoppt werden, wenn ein Patch neue Datenquellen erschließt, Freigaben umgeht, den Validierungssatz verschlechtert oder nicht eindeutig auf eine überprüfte Version zurückgeführt werden kann.
Für die Kostenplanung reicht die Erfolgsquote allein nicht. Relevant sind auch Laufzeit, Tool-Aufrufe, wiederholte Testausführungen und Review-Aufwand. Tiefere Diagnose kann manuelle Analyse sparen, verbraucht aber Rechenbudget. Wirtschaftlich wird AutoSaddler erst, wenn wiederverwendbare Verbesserungen diese Zusatzkosten über mehrere Aufgaben und Versionen hinweg übertreffen. Deshalb sollten Budgetgrenzen pro Iteration und pro akzeptiertem Patch bereits im Pilot definiert sein.
Die betriebliche Konsequenz
AutoSaddler verschiebt Agentenoptimierung in Richtung Software-Engineering: Fehlschlag-Traces liefern Evidenz, Patches ändern den ausführbaren Harness und Validierung entscheidet über die Übernahme. Das ist substantieller als spontanes Prompt-Tuning. Gerade deshalb darf die Automatisierung nicht bis zur unkontrollierten Produktion reichen. Unternehmen sollten mit einem schmalen Änderungsraum, getrennten Testdaten und einem menschlichen Merge-Gate beginnen. Erst wenn Verbesserungen wiederholt generalisieren, keine Rechte ausweiten und betrieblich reversibel bleiben, ist eine schrittweise Ausdehnung vertretbar.