Stufen der Autonomie von Agenten

• Agentic Engineering entwickelt sich vom Schreiben von Prompts hin zu Operations Design; für jede Aufgabe muss festgelegt werden, welche Autonomie erlaubt ist und welche Validierungsverfahren sie absichern
• Ein eindimensionales Leiter-Modell ist nützlich, um Vertrauen in einen einzelnen Agenten als Zahl auszudrücken; Fähigkeiten im Umgang mit mehreren Agenten gleichzeitig sollte man jedoch entlang der zwei Achsen agency und orchestration betrachten
• Das 0–5-Stufenmodell reicht von Assist, bei dem der Agent nur Vorschläge macht, bis zu Managed-by-exception orchestration, bei der Menschen nur in Ausnahmefällen eingreifen; je höher die Stufe, desto klarer müssen Ziel, Umfang, Evidenz, Berechtigungen und Budget sein
• Eine Analyse von Claude Code durch Anthropic zeigt anhand von rund 400.000 Sessions und etwa 235.000 Nutzerinnen und Nutzern, dass Menschen etwa 70 % der Planungsentscheidungen treffen, während Claude rund 80 % der Ausführung übernimmt
• Reifer Einsatz von Agenten besteht nicht darin, hohe Autonomie zur Schau zu stellen, sondern calibrated autonomy passend zu Risiko und Reversibilität anzuwenden und Validierungsengpässe zu managen

---

Agentic Engineering bewegt sich vom Prompt-Schreiben zum Operations Design

• Der Schwerpunkt von Agentic Engineering verlagert sich vom Schreiben von Prompts hin zu Operations Design
• Software-Fabriken, Ziele, Loops, Background Sessions, Subagenten, Hooks, Sandboxes und Verfahren, bei denen Agenten andere Agenten freigeben, rücken in den Vordergrund
• Claude Code und Codex werden als repräsentative Produkte für diesen Wandel behandelt
• Engineers können niedrige Autonomie einsetzen, um Risiken zu reduzieren und Änderungen leichter rückgängig zu machen; für klar umrissene Aktivitäten oder groß angelegte Refactorings in großen Codebases können sie höhere Autonomie und parallele Agenten-Flotten nutzen
• Die zentrale Frage lautet, welches Maß an Autonomie für jede Aufgabe erlaubt sein soll und welche Validierung dieses Niveau verteidigen kann

Autonomie entlang zweier Achsen statt einer einzelnen Leiter

• Die in Steve Yegges „Welcome to Gas Town“ erwähnte eindimensionale Leiter ist nützlich, um Vertrauen in einen einzelnen Agenten als Zahl auszudrücken
• Anfang 2026 funktionierte eine einzelne Achse noch als grober Proxy für Risikomessung, selbst als sich Arbeit von Delegation hin zu Orchestrierung verschob
• Sobald mehrere Agenten gleichzeitig ausgeführt werden können, lässt sich Multi-Agent-Fähigkeit mit einer einzelnen Stufe nur schwer beschreiben
• Diskussionen über Autonomie vermischen häufig zwei unterschiedliche Fragen
  • Wie weit kann man einen einzelnen Agenten vom Menschen entfernen
  • Wie gut kann man mehrere Agenten koordinieren
• Um das zu trennen, braucht es zwei Achsen
  • agency: Wie autonom ein einzelner Agent Vorschläge, begrenzte Aufgaben oder Zielerreichung ausführt
  • orchestration: Wie gut von einem einzelnen Thread über mehrere Aufgabenbäume bis hin zu kontinuierlicher Arbeit auf Basis von Backlogs, Issue-Trackern und Zeitplänen koordiniert wird

Bedeutung von agency und orchestration

• Auf niedrigen Stufen der agency-Achse schlägt der Agent mögliche Handlungen vor und wartet auf die Entscheidung des Menschen
• Auf mittleren Stufen führt der Agent bestimmte Aufgaben aus, bleibt dabei aber im Umfang begrenzt und berichtet laufend mit Evidenz, sodass Menschen nachjustieren können
• Bei hoher agency experimentiert, lernt, testet, behandelt Blockaden, stellt Fragen und versucht andere Ansätze, um ein Ziel zu erreichen, und liefert dies als Evidenz zurück
• Die niedrige Stufe der orchestration-Achse ist ein Agent und ein Thread
• Auf mittlerer Stufe arbeiten mehrere Agenten jeweils in getrennten worktrees an unterschiedlichen Zielen
• Auf hoher Stufe verwandelt ein Orchestrator Backlog, Issue-Tracker, Zeitplan und Queue in kontinuierliche Arbeit; Menschen greifen nur bei Fehlern ein, also in einer Form von management by exception
• Beispiele für verwandte Funktionen und Produkte sind:
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, Subagenten, Hooks, Checkpoints, Delegation an Agenten und Verwaltungsweisen, Background Sessions, Agent-Team-Patterns, /schedule-Argumente
  • Codex: lokale und Cloud-Threads, Goal mode, worktree, Automations, Subagenten, Review-Panel, GitHub-Code-Reviews, Hooks, Sandbox, Auto-review, rerun

Drei Epochen und sechs Stufen

• Liest man die Leiter von unten nach oben, wirkt es so, als würden agency und orchestration gleichzeitig erhöht
• Die sechs Stufen lassen sich in drei Epochen unterteilen
  • Die Epoche, in der Menschen am Steuer sitzen, Agenten assistieren und auf menschliche Bedienung warten
  • Die Epoche, in der Agenten begrenzte Aufgaben oder Ziele übernehmen, Menschen aber steuern und validieren
  • Die Orchestrierungs-Epoche, in der das System Arbeit auf mehrere Agenten verteilt und Menschen vor allem eingreifen, wenn Probleme auftreten
• In der realen Engineering-Praxis ist es natürlich, im Laufe eines Tages zwischen mehreren Stufen zu wechseln

Level 0: Assist

• Der Agent macht meist gute und manchmal perfekte Vorschläge, aber der Mensch entscheidet immer, ob sie ausgeführt werden
• Beispiele sind Autocomplete, Inline-Edit-Vorschläge oder Situationen, in denen Änderungen, die noch niemand besitzt, im Chat diskutiert werden
• Geeignet für teure Fehler, sehr kleine Änderungen und Arbeiten, bei denen sich das Urteil noch bildet
• Validierung erfolgt größtenteils lokal

Level 1: Supervised action

• Der Agent editiert oder führt Befehle stellvertretend aus, fragt aber vor wichtigen Ausführungen den Menschen um Erlaubnis
• Das entspricht in etwa der Standardhaltung, die die meisten Menschen verwenden
• Dies kann in einer lokalen Sandbox mit Freigabe vor Anwendung von Änderungen oder in einer interaktiven Session erfolgen
• Jede Freigabe dient als unabhängige Validierung, ob die jeweilige Änderung übernommen werden darf
• Der wichtigste Fehlermodus ist Approval Fatigue
  • Alle Freigaben können sich gleich anfühlen, egal was genehmigt wird
  • Man kann darauf reagieren, indem man Diffs nur überfliegt, Heuristiken folgt, andere Personen um Bestätigung bittet oder dem Agenten erlaubt, Verantwortung zu übernehmen
• Codex Auto-review adressiert dieses Problem, indem es die finale Freigabe von Randbedingungen an einen separaten Reviewer-Agenten delegiert

Level 2: Scoped task delegation

• In dieser Stufe wird dem Agenten eine begrenzte Aufgabe übergeben
• Die Aufgabe braucht ein klares Ziel, Einschränkungen und eine Arbeitsdefinition des fertigen Zustands
• Menschen bleiben in der Nähe und können abbrechen, sind aber meist nicht direkt beteiligt
• In der Softwareentwicklung wird diese Stufe als ziemlich zentral behandelt
• Validierung verschiebt sich von direkter menschlicher Prüfung hin zu Evidenz, die der Agent erzeugen kann
  • Bestandene automatisierte Tests
  • Passende Typen
  • Lint-Vorschläge
  • Screenshots
  • Reproduktionsschritte
  • Quellen auf Basis von Beispielen

Level 3: Goal-driven autonomy

• Der Agent erledigt, was nötig ist, um ein Ziel zu erreichen, bis bestimmte Bedingungen erfüllt sind
• Im Prompt-Modus wird der Prompt selbst zum Ziel
  • Beispiel: „Kannst du die Time-to-Interactive dieser Seite auf unter 1 Sekunde senken?“
• In Codex entspricht dies dem Goal mode, bei dem der Agent plan -> act -> test -> review wiederholt und stoppt, wenn die Erfolgskriterien nicht mehr erfüllt werden
• In Claude Code entsprechen dem die Befehle /goal, /loop und /schedule
• Damit diese Stufe nützlich ist, müssen Stoppbedingungen auf automatisierbare Weise messbar sein
• Vage Ziele wie „die User Experience insgesamt verbessern“ oder „die Codebase testbarer machen“ sind nicht geeignet
• Besser geeignete Ziele müssen konkret, messbar und automatisierbar sein
  • Produktionsbugs finden, die statische Analyse umgehen
  • Ladezeiten reduzieren
  • Einen strikten TypeScript-Build ohne explizites any sicherstellen
  • Alle Abhängigkeiten klassifizieren, sodass nur verständliche und testbestehende Abhängigkeiten übrig bleiben
• Um Produktionsbugs zu finden, muss sich der Agent in einer produktionsähnlichen Umgebung befinden

Level 4: Parallel delegation

• In dieser Stufe arbeiten mehrere Agenten parallel
• Jeder Agent übernimmt einen getrennten Teil der Arbeit
• Der größte Engpass ist die Zerlegung, also zu bestimmen, welche Teile delegiert werden
• Unterstützende Funktionen sind Subagenten, Background Sessions, /batch, worktree und Agent-Teams
• Der wichtigste Fehlermodus ist falsche Parallelität
  • Wenn mehrere Agenten gleichzeitig überlappende Teile bearbeiten, erzeugen sie statt mehr Arbeit Merge Conflicts und doppelte Entscheidungen
• Für guten Betrieb müssen Agenten voneinander isoliert sein
  • Jeder braucht eigene Dateien und eigenen Zustand
  • Jeder braucht auch eine eigene Review-Queue
• Jeder Agent verursacht Token-Kosten, proportional zur Zahl der gleichzeitig laufenden Agenten
• Auf menschlicher Seite steigen die Grenzkosten zusätzlicher Agenten ab einer gewissen Anzahl wegen der Orchestrierungssteuer

Level 5: Managed-by-exception orchestration

• Menschen definieren Erfolg und die anzuwendenden Policies, und ein Manager-Agent wacht aufgrund von Triggern auf und verteilt Arbeit
• Beispiele für Trigger sind neue Issues, neue Aufgaben und die Uhr
• Der Manager-Agent setzt Worker-Agenten ein, überwacht den Fortschritt, validiert Ergebnisse und versucht es bei Fehlern erneut
• Wenn Bedingungen erfüllt sind, eskaliert er an einen fähigeren Agenten oder an einen Menschen, aggregiert Ergebnisse und gibt Arbeitsartefakte wie PRs samt Evidenz an externe Systeme zurück
• Diese Stufe wird mit einer Fabrik verglichen
  • Eingaben sind Issue-Tracker oder Backlog
  • Ausgaben sind mehrere gelöste Issues oder Bugs
• Agenten arbeiten in isolierten Umgebungen mit ausreichenden Grenzen und, falls nötig, Auswegen
• Was diese Fabrik tun soll, bestimmt das vom Manager-Agenten definierte Betriebssystem
• OpenAI hat eine spec für Symphony vorgeschlagen, mit einem Linear-Board im Zentrum
  • Jedes Issue hat seinen eigenen Agent-Workspace
  • Der Agent prüft, ob er weiterhin Fortschritt in Richtung des Ziels macht, das in der spec-Datei seines Workspaces definiert ist
• Die vorderste Front der Orchestrierung besteht darin, kontinuierliche Agenten-Fabriken mit Hunderten oder Tausenden laufenden Agenten zu bauen
• Auf dieser Stufe wird unabhängige Validierung noch wichtiger
  • Trennung von Implementierer und Reviewer
  • Trennung von Test Runner und QA
  • Trennung von Sicherheitsprüfung
  • Trennung von Prozess-Gates für die Abnahme

Risiko und Reversibilität bestimmen die Obergrenze der Autonomie

• In Anthropics Studie zu Claude Code stellte Claude Code bei einigen der schwierigsten Aufgaben mehr als doppelt so häufig Klärungsfragen wie Nutzerinnen und Nutzer unterbrachen
• Erfahrene Nutzerinnen und Nutzer, definiert als solche mit etwa 750 Sessions, nutzten automatische Freigaben und Unterbrechungen häufiger als Nutzerinnen und Nutzer mit weniger als 50 Sessions und beobachteten tendenziell den Fortschritt
• Anthropics umfassendere Analyse umfasst von Oktober 2025 bis April 2026 rund 400.000 Sessions von etwa 235.000 Nutzerinnen und Nutzern
• In jeder Session ließen sich Entscheidungen wie die Zahl der vom Nutzer pro Prompt angeforderten Aktionen, automatisch freigegebene Elemente und die Häufigkeit von Unterbrechungen erfassen
• Menschen treffen etwa 70 % der Planungsentscheidungen, Claude übernimmt etwa 80 % der Ausführung
• Hohe Autonomie bedeutet nicht, Menschen aus dem Loop zu entfernen, sondern sie von der Ausführung jedes einzelnen Schritts hin zur Festlegung der nächsten Richtung zu verlagern
• Um zu beurteilen, ob ein großes AI-System mit hoher Autonomie arbeiten kann, braucht es drei Fragen
  • Wie schnell kann man erkennen, was es falsch macht
  • Wie sauber kann man rückgängig machen, was es tut
  • Was beweist, dass das, was es tut, richtig ist
• Wenn die Antwort lautet: „Man kann es nicht schnell erkennen, es ist schwer rückgängig zu machen, und man muss der Zusammenfassung vertrauen“, dann ist es keine hohe Autonomie

Was in den Vertrag vor einer Agentenausführung gehört

• Vor jeder Agentenausführung braucht es einen Vertrag, der definiert, was getan werden soll
• Der Vertrag sollte folgende Punkte enthalten
  • Ziel: das zu erreichende Ergebnis, nicht eine Aktivität oder Technik
  • Umfang: die zu bearbeitende Domain und die erlaubten Techniken
  • Nicht-Ziele: was nicht Teil des Ziels ist
  • Tools und Berechtigungen: wie der Agent mit der Außenwelt interagiert
  • Stoppbedingungen: wann gestoppt wird, möglichst anhand messbarer Variablen
  • Evidenz: Tests, Screenshots, Logs, Datenbankeinträge usw., mit denen Abschluss unabhängig geprüft werden kann
  • Eskalation: in welchen Situationen wer eingreift und wer den Agenten ausführt
  • Budget: Zeit, Aufwand und Token-Limit
• Tokens sind das Budget großer AI-Modelle und können auch Grenzen für die Zahl der Versuche und den Grad der Parallelität umfassen

Metriken machen Autonomie etwas vertrauenswürdiger

• Metriken erst im Nachhinein festzulegen, reicht möglicherweise nicht aus
• Metriken können vorab in einem knappen Dokument platziert werden und Autonomie vertrauenswürdiger machen
• Beispiele für Metriken, die je nach Autonomiestufe verfolgt werden können, sind:
  • Durchschnittliche Zeit zwischen Eingriffen
  • Längste unbeaufsichtigte Laufzeit für akzeptierte Arbeit
  • Verhältnis von in der Sandbox ausgeführten Handlungen zu eskalierten Handlungen
  • Verhältnis von automatisch freigegebenen zu abgelehnten Handlungen
  • Durchschnittliche Zahl von Agentenhandlungen pro menschlicher Anweisung
  • Rate von Klärungsanfragen
  • Rate von Unterbrechungsanfragen
  • Review-Zeit pro akzeptierter Änderung
  • Rework-Rate nach Vertrauensniveau
  • Defect-Escape-Rate nach Vertrauensniveau
  • Token-Kosten pro akzeptierter Änderung
• Ein einzelner Agent, der ständig mit von Menschen übergebenen Aufgaben beschäftigt ist, liegt eher bei Level 4 mit Dashboard; ein konservativer Agent mit automatisierter Annahme, Retries und der Regel, ohne ausreichende Evidenz nicht fortzufahren, liegt eher bei Level 5 mit echten Gates

Bereitschaft und Wahl der Autonomiestufe

• Aufgaben sollten nach Risiko und Reversibilität klassifiziert werden
• Autonomie sollte konservativ angewandt und nur erhöht werden, wenn sich Evidenz ansammelt, die eine höhere Stufe stützt
• Ein Refactoring einer Payment Engine mit starken Tests, Reviewer-Agenten und sauberem Rollback-Pfad kann höhere Autonomie unterstützen als die Automatisierung von Dokumentationsarbeit ohne richtige Antwortkriterien
• Die Autonomiestufe sollte nicht dem Aufgabennamen folgen, sondern dem Validierungsprozess

Vier Autonomie-Anti-Patterns

• Autonomy as status

  • Die Autonomie-Einstufung eines Agenten funktioniert wie ein bedeutungsloses Statusabzeichen
  • Hohe Autonomie wird als Beweis von Fähigkeit statt Sicherheit behandelt, und Agenten laufen auf einer Stufe, die durch Validierung nicht gestützt wird
  • Menschen, die die richtige Autonomiestufe wählen und Grenzen nicht überschreiten, sollten gelobt und belohnt werden

• Permission laundering

  • Wegen Approval Fatigue werden AI-Agenten und Tools weitergehende Zugriffsrechte eingeräumt als nötig
  • Grenzen wie Sandbox-Profile, schmal scoped Write-Roots, Allowlists für Befehle, Hooks und Auto-review müssen gestärkt werden

• Summary substitution

  • Die Arbeitszusammenfassung des Agenten ersetzt das Review
  • Ein Evidenzpaket wie bei einem manuellen Review sollte mitgeliefert werden
  • Es kann Diffs, Tests, Logs, Screenshots, Reviewer-Funde, Risiken und Lücken enthalten

• Fleet cosplay

  • Dutzende Agenten laufen parallel, aber Menschen koordinieren weiterhin alle Abhängigkeiten manuell
  • Gemeinsamer Zustand, Ownership-Regeln und bessere Abhängigkeitsverfolgung reduzieren den Bedarf an manueller Koordination
  • Kleinere WIP-Limits lenken den Fokus darauf, Koordinationsschritte zu codieren und zu dokumentieren, was zu automatisierter Orchestrierung führen kann

Sicher nach oben skalieren

• Als Kalibrierungsübung wird vorgeschlagen, die letzten 10 Aufgaben zu überprüfen, bei denen Agenten geholfen haben
  • Autonomiestufe jeder Aufgabe
  • Risiko
  • Wie leicht sie rückgängig zu machen war
  • Welche Evidenz erzeugt wurde, um die Validierungsanforderungen zu erfüllen
  • Review-Zeit
  • Ob Rework nötig war
  • Ob dieselbe Autonomiestufe beim nächsten Mal wieder passend wäre
• Man sollte jeweils nur eine Achse auf einmal erhöhen
• Ausgangspunkt ist ein einzelner supervised agent, der eine begrenzte Aufgabe erledigt und verteidigbare Erfolgsevidenz erzeugt
• Danach wird schrittweise in drei Richtungen erweitert
  • Leseorientierte Explorationsaufgaben parallelisieren
  • Schreibende Agenten in separaten worktrees mit begrenzten Regeln für Dateibesitz hinzufügen
  • Wiederholungsautomatisierung hinzufügen und danach agentengetriebene Orchestrierung auf Basis von Issues, Spracheingaben oder Ähnlichem ergänzen
• Jede höhere Stufe erfordert neue Schutzmaßnahmen gegen neue Fehlermodi
• Fehlermodi sind:
  • Lange Ausführung durch einen einzelnen Agenten: Drift, Kontext-Korruption, fehlende Kommunikation, Zielabweichung
  • Hintergrundarbeit: veraltete Annahmen, schwache Übergaben
  • Zu viel parallele Arbeit: Merge Conflicts, doppelte Entscheidungen
  • Zu viel wiederholte Arbeit: stille Token-Ausgaben, veraltete Prompts
  • Managed-by-exception: lange Review-Queues, Notification Fatigue
• Es geht nicht darum, stärker zu vertrauen, sondern den Umfang zu verkleinern, bessere Evidenz zu sichern, günstigere Rollback-Pfade zu schaffen, Gates zu stärken und Ownership-Regeln klarer zu machen

Passende Einsatzfälle nach Stufe

• Level 0 eignet sich am besten für heikle Arbeit und Situationen, in denen sich das Urteil noch bildet
• Level 1 eignet sich für die meisten Explorationen nahe gut verstandener Grenzen
• Level 2 eignet sich für die meisten begrenzten Aufgaben, bei denen unbekannte Abhängigkeiten und unerwartete Probleme auftreten können
• Level 3 eignet sich, wenn Erfolgskriterien ausreichend klar formuliert werden können
• Level 4 eignet sich, wenn Arbeit sauber nach Erfolgskriterien aufgeteilt werden kann
• Level 5 eignet sich, nachdem die notwendige Koordination und Kommunikation zwischen mehreren Erfolgskriterien vollständig codiert wurde

Validierung bleibt der Engpass

• Trotz des heutigen Vertrauens und Tool-Niveaus ist die Haltung reifer Engineering-Teams im Umgang mit AI-Agenten calibrated autonomy
• In naher Zukunft müssen Loops entworfen werden, die wissen, wann sie arbeiten, wann sie validieren und wann sie fragen
• Die Kompetenz von Engineers liegt weiterhin darin, die passende Autonomiestufe zu wählen und Muster sowie verteidigbare Evidenz zu schaffen, die deren dunkle Seiten verhindern