Lang laufende Agenten – Was sich ändert, wenn Agenten tagelang laufen

• Ein neues Paradigma entsteht, in dem AI-Agenten nicht nur in einer einzelnen Chat-Sitzung arbeiten, sondern über Tage bis Wochen autonom laufen, zwischen mehreren Kontextfenstern und Sandboxes wechseln, sich von Fehlern erholen und an Unterbrechungspunkten fortsetzen
• Bisherige Agenten stoßen an strukturelle Grenzen einzelner Sitzungen wie erschöpfte Kontextfenster, übermäßiges Vertrauen in die eigene Bewertung und das erneute Einführen früherer Änderungen
• Führende Unternehmen wie Anthropic, Google und Cursor konvergieren auf Architekturen mit getrennten Modell-Loops, Ausführungs-Sandboxes und Sitzungsprotokollen
• Zentrale Herausforderungen lang laufender Agenten sind Verwaltung persistenter Zustände, Selbstverifikation und Kontextkomprimierung; dazu werden fünf Designmuster vorgestellt
• Der entscheidende Investitionsbereich für tatsächliche Produktivitätsunterschiede ist weniger das Modell selbst als vielmehr die Schicht für Zustand, Sitzungen und strukturierte Handoffs, die das Modell umgibt

---

Drei Bedeutungen von „lang laufend“

• Long-horizon reasoning: die Fähigkeit, über viele abhängige Schritte hinweg zu planen und auszuführen; primär ein Problem der Modellqualität. Laut dem time horizon-Indikator von METR verdoppelt sich seit 2019 ungefähr alle 7 Monate die Aufgabendauer, die Frontier-Modelle mit 50% Zuverlässigkeit abschließen können; bleibt dieser Trend bestehen, wären 2028 tageslange und 2034 jahrelange Aufgaben möglich
• Long-running execution: eine Struktur, in der der Agentenprozess über Stunden bis Tage läuft und das Modell tausendfach aufgerufen werden kann; primär ein Problem des Harness-Designs
• Persistent agency: eine Form, in der ein Agent über eine einzelne Aufgabe hinaus Identität behält, Erinnerungen ansammelt und Nutzerpräferenzen lernt. Ein typisches Beispiel ist Googles Memory Bank
• In realen Produktionsagenten kommen alle drei zusammen, doch die jeweiligen Engineering-Probleme und Lösungen unterscheiden sich

Warum lang laufende Agenten wichtig sind

• Ein Agent mit 10 Minuten Laufzeit eignet sich für Frage-Antwort-Aufgaben oder kleine Bugfixes, aber ein 10-Stunden-Agent kann komplette Features entwickeln, über 6 Quartale aufgestaute Migrationen abschließen oder Recherchen auf dem Niveau eines Junior-Analysten durchführen
• Bei der Vorstellung von Claude Sonnet zeigte Anthropic anhand interner Tests Beispiele für mehr als 30 Stunden autonomes Coding; in einem Lauf entstand eine Slack-ähnliche App mit 11.000 Zeilen Code
• In Project Vend betrieb eine Claude-Instanz einen Monat lang ein echtes Büroautomaten-Geschäft und übernahm Bestandsverwaltung, Preisgestaltung und Kommunikation mit Lieferanten. In der ersten Phase traten aussagekräftige Fehlschläge auf, in der zweiten gab es deutliche Verbesserungen
  • Entscheidend war nicht die Profitabilität, sondern die Beobachtung von Konsistenzproblemen, die entstehen, wenn ein Agent seine Identität nicht nur über Turns, sondern über Wochen hinweg beibehält

Drei Wände, auf die alle lang laufenden Agenten stoßen

• Endlicher Kontext: Selbst ein Fenster mit 1M Tokens erschöpft sich irgendwann, und noch bevor es voll ist, tritt bereits context rot auf, also eine allmähliche Verschlechterung der Modellleistung. Eine 24-Stunden-Ausführung passt derzeit in keine Roadmap für Kontextfenster
• Fehlender persistenter Zustand: Eine neue Sitzung beginnt als unbeschriebenes Blatt. Anthropic vergleicht das mit einem „Schichtingenieur, der zur Arbeit erscheint, ohne irgendetwas darüber zu wissen, was in der vorherigen Schicht passiert ist“
• Fehlende Selbstverifikation: Wenn ein Modell seine eigene Arbeit bewertet, zeigt es systematisch einen positiven Bias. Auf die Frage „Ist es fertig?“ antwortet es häufiger mit „Ja“, als es der Realität entspricht, und liefert ohne separates Verifikationssignal Ergebnisse schon bei 30% Fertigstellung mit voller Überzeugung ab

Die Ralph-Loop: eine einfache Umsetzung lang laufender Agenten für Praktiker

• Die Ralph-Loop (Ralph-Wiggum-Technik) ist ein von Geoffrey Huntley und Ryan Carson popularisiertes Muster für lang laufende Agenten in der Praxis; die Referenzimplementierung besteht aus einem einzigen bash-Skript
• Ablauf: unvollständige Aufgabe auswählen (prd.json) → Prompt aus Aufgabe, Kontext und Notizen zusammensetzen → Agent aufrufen → Tests ausführen → Ergebnis an progress.txt anhängen → Aufgabenliste aktualisieren → wiederholen
• Kernprinzip: Der Agent selbst ist amnestisch, aber das Dateisystem bewahrt Erinnerung. prd.json dient als Plan, progress.txt als Labornotizbuch und AGENTS.md als fortlaufendes Regelwerk
• Ryan Carsons Compound Product verkettet mehrere Loops in Form von Analyse-Loop (tägliche Reports lesen) → Planungs-Loop (PRD erzeugen) → Ausführungs-Loop (Code schreiben); das ist die Open-Source-Version der von Anthropic unabhängig erreichten Dreierstruktur planner-generator-evaluator
• Mit nur einem bash-Skript und JSON-Dateien lässt sich über Nacht ein funktionierender lang laufender Agent bauen. Was Google und Anthropic produktisiert haben, ist die Arbeit, dieses Muster wiederherstellbar, sicher und beobachtbar zu machen

Anthropic: vom Harness zur Trennung von Brain/Hands/Session

• Erster Ansatz (Harness-Struktur): ein 2-Agenten-Harness für autonome Full-Stack-Entwicklung. Der Initializer-Agent richtet die anfängliche Projektumgebung ein, erweitert den Prompt zu feature-list.json und schreibt ein Bootstrap-Skript (init.sh). Der Coding-Agent wacht wiederholt auf, arbeitet Feature für Feature, führt Tests aus, schreibt claude-progress.txt und committet
  • Regel des Test-Ratchet: „Tests zu löschen oder zu verändern ist nicht erlaubt“ — das verhindert einen häufigen Fehler, bei dem Agenten fehlschlagende Tests einfach entfernen, um grün zu werden
  • In der erweiterten InfoQ-Version entwickelt sich das zu einer Dreierstruktur aus planner, generator, evaluator. Die Trennung von Erzeugung und Bewertung ist wichtig, weil Modelle ihre eigene Arbeit zu großzügig beurteilen
• Zweiter Ansatz (Trennung von Brain/Hands/Session): die Architektur von Claude Managed Agents (Anfang April 2026 eingeführt)
  • Brain: Modell plus Harness-Loop
  • Hands: die sandboxisierte, temporäre Ausführungsumgebung, in der Tools tatsächlich laufen
  • Session: ein append-only Event-Log aller Gedanken, Tool-Aufrufe und Beobachtungen
• Das zentrale Framing von Anthropic lautet: „Jede Komponente des Harness kodiert Annahmen darüber, was das Modell nicht selbst tun kann“; werden sie gekoppelt, muss das ganze System geändert werden, sobald Annahmen veralten, und bei Trennung wird das Harness zustandslos und Sandboxes können als cattle, also Verbrauchsgut, behandelt werden
• Ein neuer Container kann mit wake(sessionId) aufgerufen werden und den Zustand aus dem Log rekonstruieren. Die time-to-first-token sank um etwa 60% bei p50 und um mehr als 90% bei p95 — weil das Reasoning beginnen kann, bevor die Sandbox bereitsteht
• Das Konzept des Session-Event-Logs ist der am meisten unterschätzte Teil. Es ist der Schlüssel dazu, lang laufende Agenten wiederherstellbar zu machen. Ohne dieses Log wird ein Containerfehler sofort zu einem Sitzungsfehler
• Stack für Scientific Computing: CLAUDE.md (ein lebendiger Plan, den der Agent beim Lernen bearbeitet), CHANGELOG.md (portable Labornotizen), tmux + SLURM + git (Ausführungs- und Koordinationsschicht), Ralph-Loop (erneute Prüfung, wenn Fertigstellung behauptet wird)
  • Ein typisches Beispiel ist ein von Claude Opus über mehrere Tage gebauter Boltzmann-Solver, der gegenüber der Referenzimplementierung von CLASS weniger als 1% Abweichung erreichte. Damit wurde Arbeit verdichtet, die Forschende sonst über Monate bis Jahre leisten würden

Cursor: Struktur aus Planner, Worker und Judge

• Bei der Skalierung von Cursors lang autonom laufendem Coding gab es drei Design-Iterationen
  • Erste Iteration (flache Koordination): gleichrangige Agenten schreiben per Lock in gemeinsam genutzte Dateien → Bottlenecks entstehen, Agenten werden risikoscheu und es kommt zu churning (ständiges Wiederholen ohne Commit)
  • Zweite Iteration (optimistische Nebenläufigkeitskontrolle): Bottlenecks werden entschärft, aber das Koordinationsproblem bleibt ungelöst
  • Dritte Iteration (heutige Produktion): Planner (erkundet die Codebasis und erzeugt Aufgaben, kann rekursiv Unter-Planer spawnen), Worker (fokussierte Ausführung, arbeitet unabhängig ohne gegenseitige Koordination), Judge (entscheidet, ob eine Iteration abgeschlossen ist oder neu gestartet werden muss)
• Zentrale Erkenntnis: „Ein überraschend großer Teil des Systemverhaltens wird mehr vom Prompt als vom Harness oder Modell bestimmt“
• Das Matching von Modell und Rolle ist Teil der Designoberfläche: GPT-Modelle sind bei lang andauernder autonomer Arbeit besser als Opus. Opus neigt eher zu frühem Abbruch und Abkürzungen. Gleiche Aufgabe, andere Rolle, anderes Modell
• Composer 2 (eigenes Frontier-Coding-Modell) und Background-Cloud-Agenten: Lang laufende Aufgaben werden nicht lokal, sondern in der Cloud-Infrastruktur von Anysphere ausgeführt. Achtstündige Refactorings und codebasisweite Migrationen laufen weiter, selbst wenn das Notebook geschlossen wird
  • Wenn nach lokalem Start absehbar ist, dass ein Job länger als 30 Minuten dauert, wird er in die Cloud verlagert; danach ist eine Wiederverbindung auch mobil möglich
  • Jeder Agent läuft in einem isolierten git worktree und wird per PR zusammengeführt
• Die finale Struktur ähnelt Anthropic: Rollentrennung, persistente Sitzungen, ein Judge neben dem Worker, und lang laufende Aufgaben mit git-basierter Koordination in Cloud-Sandboxes

Google: Lang laufende Agenten auf der Agent Platform

• Auf der Cloud Next '26 integrierte Google Vertex AI in die Gemini Enterprise Agent Platform und machte lang laufende Agenten zu einem offiziellen Produkt mit definierten SLAs
• Agent Runtime: unterstützt „autonome Ausführung über Tage hinweg“, Cold Starts im Subsekundenbereich und On-Demand-Provisionierung von Sandboxes. Ein Beispiel-Use-Case ist eine einwöchige Vertriebs-Prospecting-Sequenz
• Agent Sessions: persistieren Gesprächs- und Event-Historie. Eigene Session-IDs lassen sich auf CRM- oder Datenbankeinträge abbilden, sodass Agentenzustand zusammen mit Business-Zustand gespeichert werden kann
• Agent Memory Bank: eine auf der Next '26 bereits allgemein verfügbare Schicht für Langzeitgedächtnis. Sie kuratiert Erinnerungen aus Sitzungen, scoped sie auf Nutzer-IDs und bietet eine Search-API. Im Fall von Payhawk verkürzte ein auf Memory Bank basierender Agent die Zeit für Spesenabrechnungen um mehr als 50%
• Agent Sandbox (gehärtete Codeausführung), Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation und weitere Funktionen decken fast alle Anforderungen des Produktionsbetriebs ab. Dazu gehören auch für Unternehmen nötige verschlüsselte Identitäten und Audit-Logs
• Architektonisch ist das dieselbe Struktur wie Anthropics Trennung von brain/hands/session, nur als Plattform in Produktform umgesetzt, gebündelt mit ADK (Code-first-Entwicklungskit) und Agent Studio (visuelle Tools). Was man vor drei Jahren noch selbst bauen musste, ist heute eine Frage davon, „welche Variante der Trennung von brain/hands/session man ausleihen will“

Fünf Muster für lang laufende Produktionsagenten

• Checkpoint-and-resume: Der häufigste Multiday-Fehler ist Kontextverlust. Wenn nach der Verarbeitung von 200 Dokumenten beim 201. ein Fehler auftritt, muss ohne Checkpoint alles von vorn beginnen. Agenten sollten wie lang laufende Serverprozesse behandelt werden: Zwischenzustände auf Disk speichern, nach jeweils N Arbeitseinheiten checkpointen und Fehler wiederherstellen. Entscheidend ist die richtige Granularität der Checkpoints — weder bei jedem Schritt noch nur ganz am Ende
• Delegated approval (human-in-the-loop): Bestehende Umsetzungen serialisieren Zustand in JSON → Webhook → Warten auf Antwort, doch der Zustand veraltet und Benachrichtigungen gehen unter. In einem lang laufenden Runtime-System kann ein Agent pausieren, während komplette Reasoning-Kette, Arbeitsgedächtnis, Tool-Historie und ausstehende Aktionen erhalten bleiben. Während der menschlichen Prüfung liegt der Compute-Verbrauch bei null, die Wiederaufnahme erfolgt mit Subsekunden-Latenz. Googles Mission Control dient dafür als Inbox
• Memory-layered context: Ein Agent, der 7 Tage läuft, braucht mehr als Sitzungszustand. Memory Bank (langfristig kuratierte Erinnerungen) + Memory Profiles (niedrig-latente Abfrage). Der typische Produktionsfehler ist memory drift — der Agent lernt aus unstrukturierten Interaktionen prozedurale Abkürzungen und wendet sie breit an. Speicher muss wie ein Microservice governet werden. Dazu gehören Agent Identity (Lese-/Schreibrechte), Agent Registry (Versionsverfolgung von Agenten) und Agent Gateway (Durchsetzung von Policies)
• Ambient processing: Agenten, die nicht mit Menschen sprechen, sondern auf Ereignisse aus Pub/Sub-Streams oder BigQuery-Tabellen reagieren, etwa für Content-Moderation, Anomalieerkennung oder Inbox-Klassifizierung. Wenn Policies nicht in Agenten hart kodiert, sondern im Gateway definiert werden, können Richtlinienänderungen ohne Redeploy auf Hunderte Agenten ausgerollt werden
• Fleet orchestration: In realen Systemen delegiert nicht ein einzelner Agent, sondern ein Koordinator Teilaufgaben an Spezialisten wie Lead Researcher Agent, Scoring Agent oder Outreach Agent. Jeder Spezialist besitzt eine eigene Identity (der Outreach Agent darf nicht auf Finanzdaten für Scoring zugreifen), eigene Policies und einen eigenen Registry-Eintrag. ADK verarbeitet das deklarativ als graphbasierte Workflows
• Diese Muster lassen sich kombinieren. Ein Beispiel für ein Compliance-System: Checkpointing bei der Dokumentverarbeitung + delegierte Freigabe an Review-Gates + Memory-Layering für Wissen über Sitzungen hinweg + Fleet-Orchestrierung für die Koordination von Spezialisten

Wie man es heute tatsächlich baut

• Entwickler, die in ihrem eigenen Repo lang laufende Coding-Aufgaben wollen: Werkzeuge wie Claude Code, Antigravity, Cursor oder Codex nutzen. AGENTS.md wie eine Checkliste für Piloten pflegen (kurz halten, nur Punkte aus realen Fehlschlägen aufnehmen). Typecheck- und Lint-Hooks ergänzen, vor dem Start eine Plan-Datei schreiben und eine behauptete Fertigstellung per Ralph-Loop erneut prüfen. Multi-Stunden- oder Nachtjobs in einem worktree ausführen, damit sie weiterlaufen, wenn das Notebook geschlossen wird, und nach jeder sinnvollen Arbeitseinheit committen. Das ist für die meisten Menschen der Weg mit dem höchsten Hebel
• Für den Aufbau eines gehosteten Agentenprodukts: die Runtime nicht selbst bauen, sondern Managed-Angebote wählen. Derzeit gibt es praktisch drei Optionen: Google Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents oder Self-Hosting auf Basis von ADK, Claude Agent SDK oder Codex SDK. Managed-Angebote liefern Trennung von brain/hands/session, Observability, Identität und Audit-Trails von Haus aus. Self-Hosting bietet mehr Kontrolle und den Einsatz spezieller Modelle
• Für autonome Betriebsaufgaben (Monitoring, Recherche, Operations): Persistenz im Stil einer Memory Bank ist nötig. ADK + Memory Bank + Cloud Run + Cloud Scheduler ist der sauberste Stack für „Agenten alle N Stunden laufen lassen, Zustand aufbauen und bei Schwellenwerten alarmieren“

Zentrale Praktiken unabhängig vom gewählten Weg

• Fertigstellungskriterien vor dem Start des Agenten explizit festhalten: Das ist bei lang laufenden Systemen der größte Hebel. Explizite, testbare Abschlusskriterien in einer externen Datei verhindern, dass der Agent „fertig“ während der Ausführung neu definiert
• Evaluator und Generator trennen: Selbstbewertung ist ein zentraler Fehlermodus. Eine planner/worker/judge-Pipeline oder ein generator/evaluator-Paar ist kein Stilmittel, sondern ein echtes Architekturmuster. Selbst beim gleichen Modell sollten Rolle und Prompt getrennt sein
• Nicht in Prompts, sondern in Session-Logs investieren: Ein append-only Event-Log macht Agenten wiederherstellbar, debuggbar und auditierbar. Wenn sich die Aktivitäten eines Agenten der letzten 24 Stunden nicht aus persistentem Speicher rekonstruieren lassen, ist es nur ein lang laufendes Shell-Skript, das ein LLM aufruft
• Komprimierung und Kontext-Reset als First-Class-Citizens behandeln: Anthropic stellte fest, dass bei sehr langen Aufgaben reine zusammenfassungsbasierte Komprimierung nicht ausreichte; das Harness musste die Sitzung vollständig zerlegen und aus strukturierten Handoff-Dateien neu aufbauen. Das entspricht im Kern dem Onboarding eines neuen Engineers

Die derzeitigen praktischen Grenzen

• Kosten: Ein 24-Stunden-Lauf auf Frontier-Modellen ist teuer. Ohne Budgetgrenzen, Circuit Breaker und harte Obergrenzen für Tool-Ausgaben kann an einem halben Nachmittag das API-Budget einer Woche aufgebraucht werden
• Sicherheit: Lang laufende Agenten mit API-Keys, Cloud-Zugriff und Berechtigung zur Ausführung von Shell-Befehlen haben eine deutlich größere Angriffsfläche als eine Chat-Sitzung. Deshalb ist das Muster der Trennung von brain/hands wichtig — in der Sandbox, in der modellgenerierter Code läuft, darf kein Zugriff auf Credentials möglich sein
• Alignment drift: Über mehrere Kontextfenster hinweg driftet der Agent. Das ursprüngliche Ziel wird zusammengefasst, erneut zusammengefasst und verliert dabei an Treue. Hooks und ein Judge sollen genau das abwehren; es ist die häufigste Ursache dafür, dass „der Agent etwas getan hat, das nie verlangt wurde“
• Verifikation: Die Prüfung von 24 Stunden autonomer Aktivität ist ein reales menschliches Zeitproblem. Observability und strukturierte Artefakte wie PRs, Commits, Briefings und Testläufe machen das überhaupt erst tractable
• Die Rolle des Menschen: Eine Aufgabe so präzise zu definieren, dass ein Agent einen ganzen Tag daran arbeiten kann, ist schwieriger als sie selbst auszuführen. Die Fähigkeit, deren Wert steigt, ist nicht das Schreiben von Code, sondern das Formulieren von Spezifikationen, die den Kontakt mit autonomen Ausführern überleben

Wohin die Entwicklung geht

• Google, Anthropic und Cursor konvergieren auf dieselbe Struktur: Trennung von Modell-Loop, Ausführungs-Sandbox und Session-Log, Trennung von Planung, Erzeugung und Bewertung, eingebaute Komprimierung, Hooks und Kontext-Resets sowie Speicher als Managed Service
• Die Unterschiede sind oberflächlich: Die Google Agent Platform ist der Enterprise-Stack mit eingebauter Identität und Audit-Trails, Claude Managed Agents sind die „gehostete Version des Anthropic-Harness“, und Cursors Background-Agenten sind „lang laufendes Coding, das aus der IDE in die Cloud ausgelagert wurde“
• Die schwierigeren Probleme des kommenden Jahres liegen nicht in den einzelnen Schichten, sondern in der Koordination darüber: viele lang laufende Agenten in einer gemeinsamen Codebasis betreiben, Agenten ihre eigenen Traces lesen und ihr eigenes Harness patchen lassen, sowie Harnesses, die Tools und Kontext JIT (just-in-time) passend zur Aufgabe zusammensetzen
• Modelle bleiben zwar zentral, aber die Lücke zwischen Chatfenster und Agenten, die über Nacht laufen können, liegt größtenteils in Zustand, Sitzungen und strukturierten Handoffs — und genau dort lohnt sich derzeit die Lerninvestition

[jjpark78]

Ich habe angefangen, zur Lösung dieses Problems hermes zu verwenden, und ich finde, es ist gar nicht schlecht, haha.