Long-Running AI Agent Runtime: Sessions und Checkpoints

Viacheslav Dubrov

2026-05-26 · Aktualisiert 2026-08-01 · 38 Min. · KI-Agenten

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Ein Agent Run kann mehrere Stunden dauern, während sein Worker-Prozess jederzeit neu gestartet werden kann. Das Model wählt weiterhin die nächste Aktion, aber der Runtime muss den State bewahren, die Ausführung steuern und sich von einem Fehler mitten in einem Tool Call erholen. Dieser Beitrag definiert die Grenze des Runtime. Teil 6 öffnet anschließend die eine darin enthaltene Komponente, die Entscheidungen trifft — den Harness. Dort werden Memory, Tool-Verträge und Permission Checks nicht länger als drei Themen behandelt, sondern als ein gemeinsames Programm.

Was ist ein AI Agent Runtime?

Ein AI Agent Runtime ist die Infrastructure Layer, die einen Tool-using Agent am Leben, isoliert, beobachtbar und nach Ende des Model Calls fortsetzbar hält. Sie verwaltet Session State, Tool Execution, Checkpoints, Secrets, Traces, Cost Limits und die Deployment-Form. Das Model wählt die nächste Aktion; der Runtime bestimmt, wo diese Aktion ausgeführt, wie sie aufgezeichnet und wie der Run nach einem Fehler fortgesetzt wird. Ob die Aktion erlaubt ist, entscheidet der Harness. Der Harness ist keine Storage Layer, sondern das Programm, das auf diesen Komponenten aufsetzt. Deshalb erscheint er auch in der folgenden Tabelle: Auch ihn musst du einordnen.

Vier der fünf Komponenten — Session, Sandbox, Checkpoint und Trace — speichern State oder begrenzen die Ausführung. Der Harness ist die Komponente, die Entscheidungen trifft. Hier laufen die Entscheidungen zu Memory, Tool Contracts und Permissions zusammen. Dieser Artikel behandelt ihn als eine Box und beschreibt, worauf sie aufsetzt. Teil 6 öffnet diese Box und sortiert dieselben fünf Komponenten neu: in die eine entscheidende Komponente und die vier Komponenten, auf denen sie läuft.

Long Runs durchbrechen die Annahmen stateless Prozesse

Ein stateless Chat Endpoint kann den Request State in einem Prozess halten und ihn nach der Response verwerfen. Ein Long Agent Run erstreckt sich jedoch über Worker-Neustarts, Deployments, Context Resets und Approval Pauses. Der Worker-Prozess kann daher nicht länger die Source of Truth sein.

Das OpenAI Codex Team berichtet in seinem Harness-Engineering-Beitrag, wie lange solche Runs werden:

„Wir sehen regelmäßig, dass einzelne Codex Runs über sechs Stunden an einer einzigen Aufgabe arbeiten — häufig, während die Menschen schlafen.“

Das Engineering Team von Anthropic beschreibt das entsprechende State-Problem in Effective Harnesses for Long-Running Agents:

„Die zentrale Herausforderung bei Long-Running Agents besteht darin, dass sie in diskreten Sessions arbeiten müssen und jede neue Session ohne Memory an das beginnt, was zuvor passiert ist.“

Beide Beobachtungen führen zum selben Runtime Design: State außerhalb des Workers persistieren und Worker austauschbar machen.

Die Session muss außerhalb des Worker-Prozesses liegen. Ein Durable Store zeichnet Model Calls, Tool Results und Approvals auf, sodass ein anderer Worker nach einem Crash am letzten sicheren Punkt fortsetzen kann. Checkpoints ermöglichen dem Runtime außerdem, eine neue Model Session zu starten, wenn das Context Window voll ist, ohne die gesamte Historie erneut abzuspielen. In Anthropics Formulierung werden Harness-Instanzen damit wegwerfbar und neu startbar; der Durable State liegt an anderer Stelle.

Fünf Primitive, die vor dem Go-Live platziert werden müssen

Anthropics Beitrag Scaling Managed Agents liefert eine nützliche Terminologie für fünf Runtime-Verantwortlichkeiten. Der Harness treibt den Agent voran, während die Session aufzeichnet, was er getan hat, und die Sandbox Commands ausführt. Der Checkpoint gibt dem nächsten Worker einen Resume Point; der Trace bewahrt Belege für späteres Debugging. Eine Implementierung kann Komponenten zusammenlegen, aber die Verantwortlichkeiten und Failure Boundaries müssen weiterhin benannt werden.

Session. Ein Append-only Log über alles, was passiert ist: Model Calls, Tool Calls, Results, Errors und Approvals.

Der Begriff ist überladen; deshalb müssen drei Spans unterschieden werden, die als Session bezeichnet werden. Ein Thread ist die Conversation eines Users über mehrere Tage. Er ist der langlebigste der drei Spans, und LangGraph verfolgt ihn mit einem thread_id.

Eine Model Session ist die kürzeste: eine zusammenhängende Phase desselben Model Contexts. Compaction — der Schritt, der das Window zusammenfasst, damit die Arbeit fortgesetzt werden kann — verlängert eine Model Session, statt sie zu beenden. Ein Restart oder ein bewusstes Fresh Start beendet sie. Teil 6 verwendet „Model Session“ in diesem Sinn.

In diesem Artikel bezeichnet „Session“ das Durable Log eines Runs. Sie liegt zwischen den beiden anderen Konzepten: Viele Model Sessions schreiben in ein Log, und ein Thread sammelt viele Logs. Recovery ist wake(sessionId) → getSession(id) → resume from last event.

In LangGraph nutzt Recovery einen thread_id zusammen mit einem Postgres Checkpointer (siehe LangGraph Persistence). Das OpenAI Agents SDK bietet zehn integrierte Session Backends, darunter SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession und EncryptedSession (siehe die Sessions-Dokumentation).

Harness. Die Orchestration Loop und das einzige Primitive in dieser Liste, das Entscheidungen trifft. Der Harness stellt den Prompt aus dem Memory zusammen, ruft das Model auf, prüft den vorgeschlagenen Tool Call gegen seine Permission Rules, dispatcht erlaubte Calls, schreibt Results in die Session zurück, wendet Retry Rules an und entscheidet, ob die Aufgabe abgeschlossen ist. Jeder dieser Schritte kodiert eine Annahme darüber, was das Model nicht selbst kann. Anthropic formuliert diesen Punkt direkt — das Zitat steht im Abschnitt zu Failure Modes weiter unten, der sich hauptsächlich damit beschäftigt, was passiert, wenn diese Annahmen veralten.

Das Codex Team von OpenAI nennt dies Harness Engineering: Software zu schreiben erfordert weiterhin Engineering-Aufwand, aber ein größerer Teil davon fließt jetzt in das Scaffolding statt in den Code selbst. LangGraphs CompiledStateGraph, LangChains Deep Agents und dessen create_deep_agent Entry Point sowie Claude Code selbst sind Harnesses in diesem Sinn.

Sandbox. Die isolierte Execution Environment, in der Commands tatsächlich ausgeführt werden. Die Seite zu Sandbox Concepts im OpenAI Agents SDK zieht die Grenze klar:

„Der äußere Runtime besitzt weiterhin Approvals, Tracing, Handoffs und Resume Bookkeeping. Die Sandbox Session besitzt Commands, File Changes und Environment Isolation.“

„Outer Runtime“ bezeichnet hier den Harness zusammen mit seinen State Stores. In der Terminologie dieser Serie sind Approvals und Handoffs Entscheidungen des Harness (Teil 4 und Teil 6); Tracing und Resume Bookkeeping gehören zu den Primitives Session und Checkpoint.

Sandboxes unterscheiden sich darin, wie lange sie leben und was sie zwischen Runs speichern. Die einfachste Variante ist fresh ephemeral: Für eine einzelne Aufgabe wird eine Sandbox gestartet, nach Abschluss zerstört und bei jedem Run erneut mit den Cold-Start-Kosten bezahlt.

Persistent paused Sandboxes behalten das Filesystem und einen Memory Snapshot zwischen Runs. Beim nächsten Resume entfällt dadurch ein vollständiger Boot. Snapshot or fork erzeugt ein Copy-on-Write Image aus einem vorbereiteten Parent. So können viele Tasks installierte Dependencies und warme Caches gemeinsam nutzen, ohne ihren Writable State zu teilen.

Per-worktree Sandboxes geben jedem Task einen eigenen Workspace und einen eigenen Observability Stack. Separate Logs, Metrics und Traces ermöglichen das Debugging eines Runs, ohne dass State in einen anderen Run ausläuft. Die Provider-Tabelle weiter unten vergleicht Cold-Start- und Persistence-Verhalten.

Checkpoint. Resumable State.

LangGraphs PostgresSaver schreibt an jeder Super-Step-Grenze ein Checkpoint. Ein Super-Step ist eine Runde des Graphs — entweder ein einzelner Node oder ein parallel ausgeführter Batch. Per-Task Writes gehen an checkpoint_writes, sodass erfolgreiche Node Outputs bei einem Fehler eines Geschwisters nicht neu berechnet werden.

Ein Checkpoint ist ein einfaches Dict (v, id, ts, channel_values, channel_versions, versions_seen, updated_channels). LangGraph serialisiert es mit seinem auf msgpack basierenden JsonPlusSerializer und nicht mit JSON. datetime, set, Decimal und Dataclasses lassen sich damit vollständig round-trippen. Das Format ist auf der langgraph-checkpoint-postgres-PyPI-Seite und in der LangGraph Checkpoints Reference dokumentiert.

StateSnapshot ist die separate, umfangreichere Ansicht, auf der graph.get_state() oberhalb eines Checkpoints aufbaut. Dieses Objekt wird später mit seinem .values in das Debug Bundle geschrieben.

Trace. Die Replay- und Debug-Oberfläche. Jeder Model Call, Tool Call und Sub-Agent Step wird zu einem Span mit Timing, Inputs, Outputs, Token Counts und Kosten. Wenn ein sechs Stunden dauernder Run fehlschlägt, liest du den Trace, um herauszufinden, was passiert ist. Die Terminalausgabe des Runs ist zu diesem Zeitpunkt längst verschwunden. Die GenAI Semantic Conventions von OpenTelemetry standardisieren die Attributnamen — welches Model, welcher Provider, wie viele Tokens, welche Conversation und welcher Workflow. Für ein OTLP-kompatibles Zielsystem, das diese Conventions unterstützt, kann dieselbe Instrumentierung den Trace an Systeme wie Tempo, Jaeger, Honeycomb oder LangSmith exportieren. Backend-Adapter oder eine zielsystemspezifische Konfiguration können jedoch weiterhin erforderlich sein.

Policy und Secrets schneiden sich durch alle Primitives

Zwei Grenzen verlaufen quer durch alle fünf Primitives. Sie sind die Runtime-Version des Security-Arguments aus Teil 4. Die Permission Decision selbst gehört zum Harness; im Folgenden geht es darum, wo die Mechanismen, die diese Entscheidung durchsetzen und mit Daten versorgen, physisch liegen.

Permission Enforcement

Die Permission Ladder aus Teil 4 braucht einen Ausführungsort. Der Check wird vor jedem Tool Call ausgelöst und entscheidet, ob dieser durchgeführt wird. In Production sind zwei Patterns üblich. Deep Agents kann für jeden Sub-Agent festlegen, welche File Paths er lesen oder schreiben darf; die Middleware blockiert alles außerhalb dieser Deklaration. Anthropic Managed Agents leitet jeden Tool Call über einen Model Context Protocol (MCP) Proxy. Dadurch erzwingt der Proxy die Permissions und nicht der Agent Code. Wenn ein sensibler Call eine Human Approval benötigt, pausieren LangGraphs interrupt() und der Approval Hook von Deep Agents den Graph, bis eine Person zustimmt.

Secret Broker

Das Model sollte keine langlebigen Secrets sehen, und normalerweise sollte dies auch für die Sandbox gelten. Das Managed-Agents-Pattern ist das übernehmenswerte Beispiel:

„Für Git verwenden wir das Access Token jedes Repositorys, um das Repository während der Sandbox-Initialisierung zu clonen und es mit dem lokalen Git Remote zu verbinden. Git push und pull funktionieren innerhalb der Sandbox, ohne dass der Agent das Token selbst verarbeitet. Für Custom Tools unterstützen wir MCP und speichern OAuth Tokens in einem Secure Vault. Claude ruft MCP Tools über einen Dedicated Proxy auf; dieser Proxy erhält ein Session-bezogenes Token. … Der Harness erhält zu keinem Zeitpunkt Kenntnis von Credentials.“

Im market-analyst-agent-Reference-Stack — einem kleinen LangGraph Agent, der Market Data abruft und einen Analyst Report schreibt und im Verlauf dieser Serie aufgebaut wurde — hält der MCP Sidecar die API Keys des Data Providers und stellt dem LangGraph Worker nur die Tool-Oberfläche bereit. In der lokalen Compose-Datei lesen beide Container dasselbe .env. Das ist ein Development Shortcut und nicht das empfohlene Pattern. In Production kommt die Environment des Sidecars aus einem Secret Store — Docker Secrets oder HashiCorp Vault — auf den der Worker nicht zugreifen kann. Der Worker ruft das Tool auf, ohne das dahinterliegende Credential jemals selbst zu besitzen.

Die Platzierung einem Plausibilitätscheck unterziehen

Ein praktischer Plausibilitätscheck besteht darin, jede Komponente und die von ihr implementierten fünf Primitives aufzuschreiben. Postgres könnte Session und Checkpoint abdecken. Der Worker Container ist der Harness. Ein Service wie Daytona, Modal oder E2B stellt die Sandbox bereit, während Tempo oder LangSmith den Trace speichert.

Untersuche anschließend gekoppelte Fehler. Wenn zwei Primitives im selben Prozess liegen, reißt ein Crash beide mit. Wenn sie ein Credential teilen, überschreitet ein Leak beide Grenzen. Häufige Beispiele sind ein Worker, der zugleich die Trace-Durability besitzt, oder ein Sidecar Token, das auch die Checkpoint-Datenbank entsperrt.

Failure Modes eines AI Agent Runtime in Production

Der Runtime verwaltet Retries, stellt frühere Arbeit wieder her, isoliert Workspaces und setzt Budgets durch. Wenn sich Runs über Worker und Context Windows erstrecken, verschieben sich die Fehler in Richtung State, doppelter Side Effects, Sandbox Drift und überschrittener Budgets.

Die Fehler fallen in vier Gruppen:

• Quality-of-Output Failures: Der Agent erklärt die Arbeit zu früh für abgeschlossen, vergisst nach einem Context-Window-Reset, was er getan hat, oder vertraut seiner eigenen Self-Evaluation und liefert defekten Output aus.
• Cost-Control Failures: Der Agent gerät in eine Retry Loop oder verbraucht ein Token- oder Tool-Call-Budget, ohne etwas Nützliches zu produzieren.
• State- und Crash-Failures: Workspaces driften, weil ein Run Files berührt, die ein anderer Run besitzt; Tool Calls werden durch Replay bei Retries mehrfach ausgeführt; oder Arbeit geht verloren, wenn ein Worker zwischen zwei Events stirbt.
• Context-Window Failures: Das Model fasst zusammen und beendet den Run vorzeitig, weil es glaubt, dass der verbleibende Platz knapp wird, obwohl das Window noch Kapazität hat.

Die Tabelle ordnet jedem Fehler eine Mitigation, die Grundlage der Empfehlung und den Runtime Hook zu, der sie durchsetzt. Model-spezifisches Verhalten kann sich ändern. Vendor-Beobachtungen sollten daher als Anlass verstanden werden, die Annahme erneut zu testen, nicht als dauerhafte Regeln.

Hinter den meisten dieser Zeilen stehen zwei Ideen. Anthropic über die Alterung eines Harness in Harness Design for Long-Running Application Development:

„Jede Komponente in einem Harness kodiert eine Annahme darüber, was das Model nicht selbst leisten kann. Diese Annahmen sollten einem Stresstest unterzogen werden — sowohl weil sie falsch sein können als auch weil sie mit der Verbesserung der Models schnell veralten können.“

Vercel über das verwandte Problem, dass zu viele Tools zu viele Annahmen kodieren, in We Removed 80% of Our Agent’s Tools:

„Wir haben den Großteil gelöscht und den Agent auf ein einziges Tool reduziert: beliebige Bash Commands ausführen. Wir nennen ihn einen File System Agent.“

Das Zitat beschreibt den Bash Core; der von Vercel ausgelieferte Agent behielt zwei Tools, ExecuteCommand und ExecuteSQL, statt zuvor fünfzehn. Teil 3 behandelt das vollständige Vorher und Nachher. Das berichtete Ergebnis über fünf repräsentative Queries: Der Erfolg stieg von 4/5 auf 5/5; der Worst Case sank von 724 s / 100 Steps / 145.463 Tokens (fehlgeschlagen) auf 141 s / 19 Steps / 67.483 Tokens (erfolgreich). Diese Worst-Case-Zeile ist die dramatische Veränderung; über alle fünf Queries hinweg betrug die Token-Ersparnis 37 %. Die Lehre lautet nicht „Lösche deine Tools“. Sie lautet, dass jedes Primitive in deinem Runtime — einschließlich der Tool-Oberfläche — eine begrenzte Halbwertszeit hat. Teste die Annahme erneut, wenn sich das Model ändert.

Cognition sah denselben beweglichen Zielpunkt bei der Session-Länge von Sonnet 4.5. In Rebuilding Devin for Claude Sonnet 4.5 beschreiben sie ein Model, das bei wahrgenommener Context-Erschöpfung proaktiv SUMMARY.md / CHANGELOG.md schreibt, aber unterschätzt, wie viele Tokens noch verbleiben. Ihre Lösung war, das 1M-Token-Context zu aktivieren und die Nutzung auf 200k zu begrenzen, damit das Model weiterhin glaubt, noch Spielraum zu haben. Als sie den Beitrag verfassten, war dies ein Beta Flag.

Anthropics aktuelle Dokumentation zu Context Windows führt Sonnet 4.5 im August 2026 weiterhin mit 200k. Das 1M Window ist bei Opus 4.6 und später sowie Sonnet 4.6 und später standardmäßig und ohne Beta Header verfügbar. Beobachtenswert ist der Cap. Er existiert nur, weil Sonnet 4.5 den verbleibenden Context falsch einschätzt. Sobald ein Model das nicht mehr tut, wird der Cap von einer Lösung zu einer künstlichen Obergrenze. Seit Cognition diesen Beitrag geschrieben hat, haben sich mehrere Model-Generationen abgelöst. Prüfe die Zahlen daher erneut gegen die aktuelle Model-Liste, bevor du etwas davon übernimmst.

Das Harness Team von OpenAI formuliert es in einem Satz: „Humans steer. Agents execute.“ Wenn etwas fehlschlägt, ist die nützliche Frage, welche Capability fehlt und wie diese für den Agent sowohl nachvollziehbar als auch durchsetzbar gemacht werden kann.

Der gesunde Run-Lifecycle

Ein gut funktionierender Run ist langweilig. Er besteht aus einer Kette kleiner, recoverbarer Schritte, und jeder Schritt schreibt sein Ergebnis in Durable Storage, bevor der nächste beginnt.

Genau das Schreiben jedes Ergebnisses vor dem Start des nächsten Schritts begrenzt den Crash-Schaden. Ein Fehler verliert nur den gerade laufenden Schritt; der nächste Worker setzt am letzten abgeschlossenen Schritt fort, statt den gesamten Request neu zu starten.

1. Aus einer frischen oder resumed Session booten. Beim Resume den Workspace aus seinem letzten bekannten State mounten, von der vorherigen Ausführung hinterlassene Progress Files lesen (PROGRESS.md, feature-list.json) und den letzten Checkpoint aus der Datenbank laden. Hier übergibt der Harness dem Agent alles, was der vorherige Worker vor seinem Tod im Memory hatte.
2. Vor allen Tool Calls planen. Festhalten, wie „done“ aussieht, wie viel der Run ausgeben darf, welche Tools der Agent aufrufen kann und was den Run vorzeitig beenden soll. Diese Plan Values werden zu Runtime Checks; ohne sie gibt es für die Execution keine Begrenzung.
3. Einen Tool Call nach dem anderen ausführen. Der Permission Check des Harness entscheidet, ob er erlaubt wird, dispatcht ihn anschließend, erfasst das Result und schreibt ein Event in das Session Log. Ein Schritt, ein Event. Ein Crash zwischen Events ist recoverbar, weil das Log — nicht der Memory des Workers — die Source of Truth ist.
4. An Super-Step-Grenzen oder in einem einfacheren Harness nach jedem Event einen Checkpoint schreiben. Graph State, Workspace Diff und Referenzen auf erzeugte Artefakte persistieren. Dieser Checkpoint wird beim nächsten Resume in Schritt 1 gelesen. Fehlt der Checkpoint oder ist er veraltet, wird Recovery zu einem Replay des vollständigen Session Logs — deutlich langsamer.
5. Die Artefakte prüfen, sobald der Agent glaubt, fertig zu sein: Tests, Evaluator mit frischem Context, Schema Validation und Browser Checks. Wenn der Check bestanden wird, endet der Run erfolgreich. Bei einem Fehler wird der Run vom letzten sauberen Checkpoint mit der Fehlermeldung im Context fortgesetzt und erneut ausgeführt.

Keiner der Schritte setzt voraus, dass der Agent sich zwischen Runs an etwas erinnert. Der State liegt in Session und Checkpoint und wird bei jedem Resume erneut gelesen.

Jedes Tool mit Side Effects benötigt einen aus Session ID und Tool-Call-ID abgeleiteten Idempotency Key, der vor dem Side Effect gespeichert wird. send_email(session_id, tool_call_id, message_hash). create_pr(session_id, tool_call_id, branch_name). charge_customer(session_id, tool_call_id, invoice_id). At-Least-Once Execution ist in Queues und Workflow Engines der Default; daher wird das Duplikat auftreten. Wenn ein Tool Call bei einer Wiederholung realen Schaden verursachen kann und du ihn nicht über einen Key deduplizieren kannst, ist das Tool noch nicht für Agents geeignet.

Evaluation sollte Evidence außerhalb des produzierenden Contexts einbeziehen. Ein Evaluator mit frischem Context reduziert Shared-Context Bias, während Tests, Lints, Browser Checks und Schema Validation deterministische Evidence liefern. Der Check kann pass, fail oder needs_human zurückgeben. Bei Code Agents kann der Reviewer eine weitere Model Session mit Read-Only-Tools sein. Bei Data- und Report Agents solltest du deterministische Validation mit einem Reviewer Model kombinieren, wenn weiterhin Judgment erforderlich ist.

Elf AI-Agent-Deployment-Patterns und was zwischen ihnen entscheidet

Sobald die fünf Primitives benannt sind, stellt sich die Frage, welche Deployment-Form sie ausführt. Mit „Form“ ist eine Anordnung dieser Primitives gemeint: Wo liegt der Harness, wo persistiert der State und welche Sandbox führt die Arbeit aus? Eine Form ist eine Wiring-Entscheidung und keine Vendor-Auswahl. Die Grafik unten zeigt, bei welcher Run-Länge sich die jeweiligen Formen besonders eignen. Im anschließenden Text geht es darum, was zwischen ihnen entscheidet.

Wenn du nur eines der elf Patterns liest, lies Pattern 2: Queue + Worker + Checkpoint DB. Es ist der Default, den ich den meisten Teams empfehle, die im Reference Repo verwendete Form und das Grundgerüst, von dem viele andere Formen abweichen: Queue → Durable State, wobei Sandbox Source, Harness Owner oder State Engine ausgetauscht werden. Wenn du mit Pattern 2 beginnst, lassen sich die übrigen schneller überblicken.

Die Grafik vergleicht die Formen nach Run-Länge. Die folgende Matrix vergleicht sie nach Ownership: Jede umrandete Zelle nennt die Komponente, die dieses Primitive bereitstellt.

1. SDK in einem App Server (synchron, Request-scoped)

Die ursprüngliche Form. Das Agent SDK läuft innerhalb eines Request Handlers. Geeignet für Tasks unter 30 Sekunden, Demos und interne Tools. Ungeeignet für alles, wovon sich ein HTTP Client trennen könnte. Das HTTP Timeout von Cloud Run endet spätestens nach 60 Minuten, und ein Panic in der Web Tier beendet den Run. Das SDK ist der Harness, der Web-Prozess agiert zugleich als Sandbox, und der State liegt normalerweise im Process Memory, sofern du ihn nicht explizit an anderer Stelle persistierst. Für mehrstündige Arbeit nicht verwenden.

2. Queue + Worker + Checkpoint DB

Der Default, den ich den meisten Teams empfehle, und die in market-analyst-agent verwendete Production-Form: ein Python Worker mit PostgreSQL Checkpointer, Redis Streams (oder RabbitMQ) für die Inbound Queue sowie ein MCP Sidecar für Tools. Geeignet für Runs von zehn Minuten bis zu mehreren Stunden mit idempotenten Steps. Der Local Runner kann die Queue in der synchronen Entwicklung umgehen; sobald asynchrone Submission und Backpressure benötigt werden, ist die Queue jedoch Teil der Production-Form.

Die App akzeptiert einen Request, erstellt eine Session Row, stellt einen Job in die Queue und gibt eine Run ID zurück. Der Worker zieht den Job, führt den Harness aus, schreibt Checkpoints, streamt den Status und speichert währenddessen Artefakte. Postgres bleibt bestehen, Worker sind austauschbar und die Queue Depth liefert Backpressure. Spot-/Preemptible Compute funktioniert, solange der Checkpointer das Schreiben auf Disk beendet, bevor er Success meldet.

In dieser Form ist der Worker der Harness. Sein Container und der Workspace pro Thread bilden eine Execution Boundary; untrusted Code benötigt jedoch weiterhin eine Hardened Sandbox oder VM. Postgres besitzt Session- und Checkpoint-State. Traces laufen über OpenTelemetry in den von dir betriebenen Observability Stack.

3. Durable Workflow Engine (Temporal-style)

Der Agent-Orchestration-Code läuft innerhalb eines Temporal Workflow; Model Calls und Tool Calls laufen als Activities. Der Workflow State liegt in einem von Cassandra, MySQL oder Postgres unterstützten Event-History-Log, sodass State Deployments übersteht und sauber gereplayed werden kann. Die Temporal × OpenAI Agents SDK Integration, seit März 2026 allgemein verfügbar, liefert einen OpenAIAgentsPlugin und einen activity_as_tool Helper. Der Beitrag zu agentic Sandboxes beschreibt außerdem, wie ein laufender Agent während einer Conversation auf einen anderen Sandbox Provider geforkt werden kann. Idle Workflows verbrauchen keinen Compute. Die Einschränkungen sind real: Realtime Agents werden nicht unterstützt, Streaming ist weiterhin als experimentell markiert, und LocalShellTool sowie ComputerTool sind deaktiviert, weil sie nicht zum Distributed Model passen.

Verwende diese Form, wenn der Run echte Wartephasen enthält: Human Approvals, externe Callbacks, lange Sleeps, Retries mit Business Rules oder Deployment Windows. Eine Human Approval wird dabei zu einem Durable Sleep, der keinen Compute verbraucht — nicht zu einer Polling Loop.

Der Workflow Code ist der Harness. Die Sandbox liegt normalerweise außerhalb von Temporal und wird aus Activities aufgerufen. Session- und Checkpoint-State fallen im Temporal Event-History-Log zusammen; Trace Visibility kommt aus der Temporal UI sowie OpenTelemetry Spans für jede Activity.

4. Sandbox Provider pro Session

Eine neuere Form. Jeder Agent Run erhält eine eigene MicroVM oder einen eigenen Container von einem Sandbox-as-a-Service-Provider. Der Harness liegt an einer Durable Stelle; die Sandbox ist die wegwerfbare Execution Environment.

Cold Starts bezeichnen hier End-to-End-Provisioning und nicht den reinen Boot: Die etwa 150 ms von E2B kommen zu den etwa 125 ms Firecracker-Boot-Zeit hinzu, die Teil 4 für den Hypervisor selbst nennt. Die Tabelle kombiniert den E2B-vs.-Daytona-Vergleich, Daytons Sandbox-Dokumentation und den Fork-/Snapshot-Changelog, Modals Sandboxes und Cold-Start-Guides, das Runloop AWS Marketplace Listing sowie Vercel Sandbox Pricing.

Daytona zeichnet für jeden unabhängigen Fork eine Parent-Child-Verknüpfung auf und bewahrt damit die Lineage abgeleiteter Sandboxes. OpenAIs Codex Harness verwendet die Per-Worktree-Variante: „Codex arbeitet an einer vollständig isolierten Version dieser App, einschließlich ihrer Logs und Metrics, die nach Abschluss des Tasks abgebaut werden.“

Wähle diese Form, wenn der Agent untrusted Code, Browser Automation, Tests oder Package Installs ausführt. Der Trade-off sind höhere Kosten und stärkere Provider-Kopplung im Vergleich zu Shared Workers.

Der Provider besitzt die Sandbox und nichts darüber hinaus. Harness, Session, Checkpoint und Trace bleiben auf deiner Seite, normalerweise verdrahtet als Queue-plus-Worker-Form aus Pattern 2.

5. Anthropic Managed Agents (Hosted Harness)

Anthropic hat Managed Agents am 8. April 2026 als Public Beta gestartet, hinter dem managed-agents-2026-04-01 Beta Header. Der Service stellt eine Hosted Session, einen Harness, eine Sandbox und einen Vault-backed MCP Proxy bereit. wake(sessionId) kann den Harness auf einem neuen Worker initialisieren, ohne den Durable Session State zu verlieren.

Anthropic berechnet Managed Agents zu den regulären Token Rates plus $0,08 pro Session-Stunde. Die Abrechnung erfolgt auf Millisekundenbasis und gilt nur, solange der Session Status „running“ ist; Idle Time ist kostenlos. Eine unkontrollierte Retry Loop verursacht daher zusätzlich zu den Token-Kosten Session-Hour-Kosten.

Beachte die Einschränkungen. Der Rabatt der Batch API gilt nicht („Sessions sind Stateful und Interactive. Es gibt keinen Batch Mode.“). Managed Agents ist weder über AWS Bedrock noch über Google Vertex AI verfügbar. Innerhalb der Beta benötigen MCP Tunnels und das „Dreaming“ der Agents zusätzlich eine Research Preview, für die du Zugriff anfordern musst. Multi-Agent Coordination und Rubric-graded Self-Evaluation sind dokumentierte Bestandteile der Beta. Der Lock-in ist hoch: Du tauschst Harness-Freiheit dagegen ein, die Loop nicht selbst betreiben zu müssen.

Anthropic hostet alle fünf Primitives: Session, Harness, Sandbox, Checkpoint und Trace. Du übergibst den Runtime und erhältst die Outputs.

6. LangChain Deep Agents Deploy (Managed Open Harness)

deepagents deploy verpackt einen deepagents.toml in ein LangSmith Deployment mit Durable Execution, Memory, Multi-Tenancy, Human-in-the-Loop, Observability, Sandboxed Code Execution und Scheduled Runs. Cloud-, Hybrid- und Self-Hosted-Deployment-Modi werden unterstützt. Sandbox Provider (LangSmith Sandboxes, Daytona, Modal, Runloop oder Custom Provider) lassen sich über einen einzelnen Config Value austauschen. State liegt in einem Virtual Filesystem mit pluggable Backends; Memory kann auf User, Assistant oder beide gescoped werden. Der Lock-in ist geringer als bei Managed Agents: Der Harness steht unter MIT-Lizenz, Instructions verwenden den offenen AGENTS.md-Standard, und Agents werden über MCP, das A2A-Protokoll (Agent2Agent) und Agent Protocol exponiert. Siehe LangChains Beitrag runtime-behind-production-deep-agents.

Standardmäßig werden alle fünf Primitives gehostet, aber jedes ist per Config austauschbar. Die Sandbox liegt hinter einem einzelnen Config Value. Session und Checkpoint befinden sich in einem Virtual Filesystem mit pluggable Backends. Der Trace geht an LangSmith.

7. Google Cloud Run Service oder Job

Cloud Run besitzt zwei unterschiedliche Runtime-Modi; welcher passt, hängt davon ab, wie der Agent aufgerufen wird. Services sind an HTTP gebunden und skalieren zwischen Requests auf null; der Harness läuft als Request Handler und gibt zurück, wenn der Run abgeschlossen ist. Jobs laufen ohne HTTP Entry Point bis zum Abschluss; der Harness läuft als One-Shot Worker und beendet sich nach Abschluss des Tasks. Beide können den Harness hosten, aber keiner hält State über Runs hinweg. Sessions und Checkpoints müssen in Postgres, Spanner oder einem ähnlichen externen Store liegen.

Die harten Limits unterscheiden sich deutlich. Cloud-Run-Service-Request-Timeout: Standard 300 s, maximal 3.600 s (60 min). WebSockets unterliegen demselben Timeout. Cloud-Run-Jobs: standardmäßig 10 min pro Task, maximal 168 h (7 Tage); für Tasks mit GPUs maximal 1 Stunde. Services skalieren auf null, sofern Always-On CPU nicht aktiviert ist; Jobs haben kein HTTP und autoskalieren nicht.

Verwende einen Service für synchrone Runs bis 60 Minuten. Für längere One-Shot- oder asynchrone Arbeit verwende einen Job. Cloud Run Jobs können einen Task tagelang am Leben halten, bieten aber kein Durable Replay über Deployments, Versionsänderungen oder Worker-Ersatz hinweg. Oberhalb von 7 Tagen solltest du Cloud Run nicht verwenden.

Cloud Run hostet den Harness. Session- und Checkpoint-State liegen in Postgres, Spanner oder einem anderen externen Store; Traces können über Cloud Logging und OpenTelemetry fließen. Der Service Container ist eine Execution Environment. Wenn der Agent untrusted Code ausführt, ergänze eine separate Sandbox.

8. AWS Lambda (warum es das falsche Tool ist)

Lambdas maximales Function Timeout beträgt fest 900 s (15 Minuten). Wenn API Gateway die Function vorschaltet, hängt das Integration Limit vom API-Typ ab. HTTP APIs erlauben 30 Sekunden; REST Integrations haben standardmäßig 29 Sekunden, während regionale und private REST APIs ein längeres Timeout konfigurieren können. Keiner dieser Wege macht Lambda zu einem mehrstündigen Worker. Ein Long-Running Harness benötigt weiterhin externen State und erneute Invocation, womit du wieder bei der Queue-plus-Worker-Form landest. Verwende Lambda für begrenzte Tool Calls, etwa File Fetches oder S3 Uploads, die von einem länger laufenden Orchestrator aufgerufen werden. Den Orchestrator selbst solltest du dort nicht platzieren.

Lambda kann höchstens einen Tool Call innerhalb seines 15-Minuten-Limits ausführen. Harness, Session, Checkpoint, Sandbox und Trace müssen an anderer Stelle liegen.

9. AWS ECS-/Fargate-Task pro Run

Fargate dokumentiert im Gegensatz zu Lambda kein hartes Limit für die Task-Laufzeit. Fargate Throttling Quotas erlauben einen Launch Burst von 100 und füllen sich mit 20 pro Sekunde wieder auf; für On-Demand und Spot gelten separate Budgets. ECS Service Quotas begrenzen Services mit AWS Cloud Map Discovery auf 1.000 Tasks pro Service und EC2-basierte Cluster auf 5.000 Container Instances.

Fargate erfordert den Modus awsvpc. Jeder Task erhält daher ein Network Interface und eine private IP. Diese Form eignet sich für VPC-interne Data Access. Fargate Spot bringt ein zusätzliches Interruption Risk mit sich; Durability bleibt deine Verantwortung, da die Plattform kein Temporal-artiges Replay bietet.

Fargate hostet den Harness und gibt jedem Run einen eigenen Task. Das trennt Workspaces und Task Credentials, ist aber allein noch keine vollständige Sandbox für hostile Code. Session, Checkpoint und Trace gehen an externe Services wie RDS oder DynamoDB sowie CloudWatch/X-Ray.

10. Kubernetes Job oder Namespace pro Session

Geeignet, wenn du bereits Kubernetes betreibst und Sandbox-per-Session mit clusterweiten Controls möchtest. Ungeeignet, wenn du Sub-Second-Startup benötigst, weil das Pullen des Container Images und die Initialisierung des Pods bei einem Cold Start zu lange dauern. Das Pattern besteht aus einem Job pro Agent Run, mit activeDeadlineSeconds, einem PersistentVolumeClaim für den Workspace und einem Sidecar für den MCP Server. Crash Recovery musst du selbst bauen. Kubernetes nur für Agents einzuführen, ist hinsichtlich Configuration Overhead und Operational Burden teuer. Es lohnt sich nur, wenn du K8s bereits aus anderen Gründen betreibst.

Kubernetes hostet den Harness und die Execution Environment pro Run, normalerweise als einen Job und gelegentlich mit einem dedizierten Namespace. Starke Isolation hängt weiterhin von Runtime Class, Network Policy, Pod Security und der zugrunde liegenden Container- oder VM-Grenze ab. Session- und Checkpoint-State liegen in einer externen Datenbank oder auf einem PersistentVolumeClaim.

11. Lokales Docker Compose (nur Dev)

Die Referenz für den nächsten Abschnitt. Der Zweck dieser Form besteht darin, die Production Topology eins zu eins abzubilden — gleiche Primitives, gleiche Network Shape — während alles auf einer einzigen Maschine läuft. Nicht abgebildet wird die Isolation: ein gemeinsamer Workspace Mount, ein Postgres, keine Hardened Sandbox und keine getrennten Failure Domains zwischen Worker und State. Nichts, das so aussieht, sollte ausgeliefert werden.

Compose bildet Form 2 auf einem einzelnen Host nach. Postgres hält Session- und Checkpoint-State; der Worker Container ist der Harness. Der Shared Workspace Mount ist für die Entwicklung bequem, isoliert aber keine untrusted Runs. Der optionale OpenTelemetry Stack zeichnet Traces auf.

Reference Stack: Docker Compose

Die in slavadubrov/market-analyst-agent verwendete Referenz-Topology besteht aus einem LangGraph Worker, einem Postgres Checkpointer, Qdrant für Retrieval, einem MCP Sidecar, einer Redis Queue für asynchrone Production-like Runs sowie einem optionalen Prometheus / Grafana / Loki / Tempo / OTel Observability Stack. In Local Compose ist Redis nur deshalb optional, weil der synchrone Runner den Worker direkt aufrufen kann. docker compose up startet die Core Topology lokal; MCP Sidecar und Observability Stack sind Opt-in Profiles (--profile mcp, --profile observability).

Der einzige inline gezeigte Teil ist das kanonische LangGraph Wiring. Es handelt sich um einen illustrativen Auszug und nicht um ein direkt im Repository ausführbares Beispiel. Für die Ausführung benötigst du langgraph, langgraph-checkpoint-postgres und psycopg[binary,pool], eine erreichbare PostgreSQL-Datenbank mit Berechtigung zum Anlegen der Checkpointer-Tabellen, POSTGRES_PASSWORD sowie ein zuvor gebautes StateGraph in builder; siehe LangGraphs Postgres Checkpointer Setup.

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
# `builder` is your StateGraph, already built
session_id = "session-123"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)
    result = graph.invoke(
        {"messages": [{"role": "user", "content": "Continue the task"}]},
        {"configurable": {"thread_id": session_id}},
    )

Observability, die den Run übersteht

Kurze Request Handler lassen sich leicht debuggen: Wenn etwas fehlschlägt, liest du die Response und das Live Log. Long-Running Agents haben diesen Luxus nicht. Wenn ein sechs Stunden dauernder Run fehlschlägt, liegt das interessante Event fünf Stunden zurück, die Live-Terminalausgabe ist verschwunden und der Worker, der es erzeugt hat, wurde ersetzt. Niemand wird den Run aus dem Memory rekonstruieren. Daher wird aus Durable Artifacts debuggt, die geschrieben wurden, während der Run noch lief.

Production Stacks decken typischerweise vier Arten von Artefakten ab, aufgeteilt in zwei Gruppen. Zwei davon liest du nach Abschluss des Runs für Postmortems und Replay: ein abfragbares Event Log jedes Steps und OpenTelemetry Traces, die zeigen, wohin Zeit und Tokens geflossen sind. Zwei liest du während des Runs. Das eine ist ein Live Tail dessen, was der Agent im Workspace produziert. Das andere ist ein Per-Worktree-Observability-Stack, den der Agent selbst während der Arbeit abfragen kann.

Structured Event Log (nach dem Run lesen)

Jeder Model Call, Tool Call, jedes Result, jeder Error und jede Approval wird mit Session ID und Timestamp versehen in Durable Storage geschrieben. Nach Abschluss des Runs lässt sich das Log wie eine normale Datenbanktabelle abfragen. Addy Osmani setzt in Long-Running Agents die Messlatte klar: „Wenn du aus Durable Storage nicht rekonstruieren kannst, was der Agent in den vergangenen 24 Stunden getan hat, hast du kein Long-Running Agent, sondern ein Long-Running Shell Script, das zufällig ein LLM aufruft.“

OpenTelemetry GenAI Traces (nach dem Run lesen)

Dieselben Step-Daten werden als Spans mit den Standardattributen aus den gen_ai.* Semantic Conventions ausgegeben: Model Name, Provider, Input- und Output-Token Counts, Conversation ID und Workflow Name. Die Conventions befinden sich weiterhin auf der Stability-Stufe Development.

2026 wurden sie aus dem zentralen OpenTelemetry Semantic-Conventions-Repository in ein eigenes GenAI Semantic Conventions Repository verschoben. Die Attributnamen können für Instrumentierung verwendet werden; pinne jedoch die von dir validierte Revision statt einer Versionsnummer des Main Repos. Provider-spezifische Felder liegen in Subnamespaces (anthropic.*, openai.*), die über gen_ai.provider.name referenziert werden. Der Vorteil des Standards ist Portabilität: Bei OTLP-kompatiblen Zielsystemen, die diese Conventions unterstützen, ist beim Wechsel des Backends möglicherweise keine erneute Instrumentierung erforderlich. Backend-Adapter oder zielsystemspezifische Konfiguration können dennoch notwendig sein.

Tool-Call-Timeline plus Workspace Diffs (während des Runs lesen)

Der schnellste Weg herauszufinden, was ein Agent gerade tut, besteht darin, das zu tailen, was er im Workspace produziert, statt ein Session Log mit grep zu durchsuchen. Der Quickstart zu Harness Primitives for Long-Running Claude Agents von Anthropic liefert dafür eine Zwei-Pane-Watch-Loop: watch -n 5 'git log --oneline -8' zeigt die neuesten Commits des Agents, watch -n 5 'find screenshots -name "*.png" | tail -5' die neuesten von ihm aufgenommenen Screenshots. Zwei Terminal-Panes, die sich alle fünf Sekunden aktualisieren, reichen aus, um zu erkennen, ob ein Run Fortschritte macht oder sich im Kreis dreht.

Ephemeral Stack pro Worktree (vom Agent selbst während des Runs gelesen)

Laut OpenAIs Harness-Beitrag: „Logs, Metrics und Traces werden Codex über einen lokalen Observability Stack zur Verfügung gestellt, der für jeden Worktree ephemeral ist.“ Jeder Agent Worktree erhält einen eigenen kurzlebigen Loki-, Prometheus- und Tempo-Stack, der ausschließlich auf diesen Run begrenzt ist. Der Agent fragt ihn während der Arbeit ab. Dadurch kann ein Prompt wie „Kein Span in diesen vier User Journeys überschreitet zwei Sekunden“ direkt vom Agent verifiziert werden, statt dass er raten muss.

(Der Evaluator mit frischem Context aus der Failure-Modes-Tabelle liest diese Artefakte, um „done“ zu entscheiden. Er gehört zur Evaluation, nicht zur Observability; siehe § Healthy Run Lifecycle. Er hängt von jeder oben genannten Oberfläche ab.)

Ein minimaler Self-Hosted-Observability-Stack

Für etwas wie market-analyst-agent:

1. OpenTelemetry Collector mit dem GenAI Normalizer Processor (contrib, alpha) für unterstützte GenAI-Attribute. Verwende die generischen Attributes- oder Transform-Prozessoren, um gen_ai.*-Felder zu filtern oder umzuschreiben.
2. Tempo (oder Jaeger) für Traces, anhand von gen_ai.conversation.id / thread_id.
3. Loki für Structured Event-Log-Einträge.
4. Prometheus für gen_ai.client.token.usage, gen_ai.client.operation.duration und gen_ai.client.operation.time_to_first_chunk — die gen_ai.server.* Metrics kommen vom Model Server und sind daher nur verfügbar, wenn du die Weights selbst hostest (siehe die GenAI Metrics Conventions).
5. Grafana-Dashboards mit den Keys gen_ai.agent.name und gen_ai.request.model.

Hosted Alternatives (eine auswählen, nicht drei):

• LangSmith: native LangGraph Integration; zugleich das Deployment Target für Deep Agents Deploy.
• Braintrust: am besten geeignet, wenn Eval-First-Regression-Suites Priorität haben.
• Arize Phoenix: OSS, nativ für OTLP (das OpenTelemetry Wire Protocol), und passend zu OpenInference-Instrumentation.
• OpenAIs Tracing Dashboard: automatisch verfügbar, wenn du das OpenAI Agents SDK oder dessen Temporal Integration verwendest.
• Anthropics Claude Tracing: für Sessions innerhalb von Managed Agents.

Den LangGraph Node instrumentieren

Dies ist ein illustrativer Auszug und wird vom Example Runner des Repositorys übersprungen. Er setzt voraus, dass der LangGraph Node bereits über ein aktives OpenTelemetry span, das aktuelle thread_id sowie ein Provider Response usage-Objekt mit input_tokens und output_tokens verfügt. Tracer Setup, Export Configuration und Provider-spezifisches Usage Mapping liegen außerhalb des Snippets.

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "<your-model-id>")
span.set_attribute("gen_ai.response.model", "<your-model-id>")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Die Attributnamen wurden unverändert aus der OpenTelemetry GenAI Semantic Conventions Registry übernommen.

Drei Abfragen, die auf ein Dashboard gehören

# Loki: token usage per agent over 1h
sum by (gen_ai_agent_name) (
    rate({service_name="market-analyst-agent"} | json | unwrap gen_ai_usage_output_tokens [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

Das Debug-Bundle-Pattern

Wenn ein Run fehlschlägt, sollte der Worker ein /workspaces/${THREAD_ID}/_debug/ mit den Artefakten ablegen, die du für ein Postmortem anfordern würdest:

• session.jsonl: vollständiger Event-Log-Dump aus dem PostgresSaver (checkpointer.list({"configurable": {"thread_id": ...}})).
• last_state.json: StateSnapshot.values des letzten erfolgreichen Super-Steps.
• trace.json: OTLP-exportierte Spans des Runs.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: Workspace Directory plus git diff gegen den Initializer Commit.
• screenshots/*.png: was der Agent gesehen hat.
• PROGRESS.md, feature-list.json und alle anderen vom Agent verfassten Progress Files.
• env.txt: Image Tags, Model Version, Harness Commit SHA.

Dieses Bundle liefert einem Menschen oder Reviewer Agent genug Evidence, um den Fehler zu rekonstruieren. „Der Agent hat sich festgefahren“ ist vage. Ein illustrativer Report ist konkret: Session s_123 verbrauchte 71 Prozent ihrer Tokens damit, drei Commands zu wiederholen, nachdem npm install fehlgeschlagen war.

Die richtige Form auswählen: Ein Decision Guide

Der obige Vergleich lässt sich auf eine Handvoll Entscheidungen reduzieren.

Mit der Run-Länge beginnen

Verwende die Run-Länge als ersten Filter:

• Unter 30 Sekunden, idempotent: Request-Lifecycle SDK in einem App Server.
• 30 s bis 60 min: Queue + Worker + Checkpoint DB.
• 60 min bis 24 h: dieselbe Queue-plus-Worker-Form oder ein Cloud Run Job für One-Shot-Arbeit. Verwende eine Durable Workflow Engine, wenn du zusätzlich Versionierung und Replay benötigst.
• Mehr als 24 h, Deployments müssen überstanden werden: Durable Workflow Engine (Temporal-style). Cloud Run Jobs können Long-Running Work bis zum Task Limit halten, bieten aber keine Replay Semantics.
• Multi-Day Reinforcement-Learning Training Loops: K8s Job + Volume + Temporal.

Prüfe nach diesem groben Filter Side Effects, Recovery, Replay, Isolation, Data Location und das Team, das den Service betreiben wird.

Platform Fit nach Use Case

Die Matrix ist dicht; keine einzelne grüne Zelle entscheidet über die Architektur. In der Regel entscheiden die gelben Zellen — dort, wo eine Plattform etwas nur mit Einschränkungen unterstützt. Eine breite Workload-Abdeckung ist nützlich, zeigt aber weder Data Residency noch Replay Semantics, Provider-Abhängigkeit, Operational Maturity oder die Kosten einer späteren State-Migration.

Deep Agents Deploy ist die einzige Spalte der Matrix ohne rote oder gelbe Zelle: kurze synchrone Runs, Multi-Hour Batch, Sandbox Forking, GPU Work und der geringste Lock-in sind sämtlich grün. Damit ist es ein Kandidat, wenn eine Plattform alle deine Workloads abdecken muss. Diese Breite geht mit einer kürzeren Production-Historie einher als bei einem Queue-plus-Worker-plus-Postgres-Stack. Behandle die grünen Zellen als Capability Claims, die du validieren musst, und vergleiche anschließend die operationalen Einschränkungen, die die Matrix nicht abbilden kann.

Anthropic Managed Agents passt entweder vollständig zu deinem Workload oder überhaupt nicht. Das Produkt hat zwei harte Constraints: Es ist Hosted-only und Claude-only. Wenn dein Workload beide erfüllt — Claude ist bereits das gewünschte Model und du möchtest einen Harness nicht selbst betreiben — ist Managed Agents sehr passend. Ein interner Coding Agent, der in zwei- bis sechsstündigen Bursts läuft, entspricht der am besten passenden Form; zugleich entfällt ein großer Teil der Platform-Arbeit für dein Team. Wenn einer der beiden Constraints scheitert, weil du ein Nicht-Claude-Model oder Self-Hosted Compliance benötigst, passt Managed Agents nicht. Das lässt sich nicht durch Konfiguration ändern.

Das Pricing solltest du vor der Entscheidung modellieren, nicht danach. Die Session-Hour-Zeile entspricht $0.08/hour on top of standard token costs. If a single session ran continuously, that is about$58 pro Monat und Session. Bei 100 kontinuierlich laufenden Sessions ergibt sich ungefähr $5,800/month _before tokens_. Multiply$0,08 multipliziert mit deinen erwarteten Concurrent-Session-Hours. Addiere diesen Betrag zu deiner Token-Rechnung und vergleiche ihn mit den Kosten eines Queue-plus-Worker-Stacks auf eigener Infrastruktur. Eine spätere Migration weg von Managed Agents ist ein Re-Platforming-Projekt, keine Config-Änderung.

Hosted Harness vs. eigener Harness

Hier geht es darum, wer den Harness betreibt, nicht darum, wer seinen Code geschrieben hat. Hosted bedeutet, dass der Vendor die Harness Loop in seiner Infrastruktur betreibt und du eine API aufrufst. Owned bedeutet, dass du die Loop auf deiner eigenen Infrastruktur betreibst, selbst wenn der Harness Code von einem Vendor stammt.

LangChain steht auf beiden Seiten dieser Grenze, was häufig zu Verwirrung führt. Das Unternehmen liefert LangGraph, eine MIT-lizenzierte Library, die du selbst hostest (owned), und Deep Agents Deploy, ein Managed Product, das standardmäßig einen Deep Agents Harness auf LangSmith Deployment in der Cloud ausführt (hosted). Dasselbe Unternehmen, zwei unterschiedliche operative Modelle. Du entscheidest, wer die Loop betreibt — nicht, wessen Logo auf der Library steht. (Deep Agents Deploy besitzt außerdem einen Self-Hosted-Modus für Teams, die Harness-Ergonomie ohne Cloud-Komponente möchten; dieser Modus gehört zur Owned-Kategorie.)

Wähle einen Hosted Harness, wenn Model Support, Data Boundary, Recovery-Verhalten und Extension Points bereits passen. Wähle einen Owned Harness, wenn diese Constraints Anforderungen sind, von denen du erwartest, dass sie sich ändern. Eine Migration zwischen beiden verändert State, Observability und Execution Boundaries. Teste daher den Exit Path, bevor Production Data davon abhängt.

Hosted Sandbox vs. eigene Execution Environment

Wähle eine Hosted Sandbox, wenn Isolation, Pause/Resume oder Fork Semantics des Providers zu Threat Model und Startup Budget passen. Docker oder Fargate können für vertrauenswürdige interne Workloads mit VPC Access oder strikter Data Residency geeignet sein. Ein Standard-Container ist jedoch keine ausreichende Boundary für hostile Code. Teil 4 behandelt dafür die verfügbaren Isolation-Optionen.

State Stores: Git, DB und Object Storage nebeneinander

Long-Running Agents verwenden meist drei State Stores gleichzeitig, weil jeder Store ein anderes Artefakt besitzt.

Git speichert Workspace State: den Code, die Dokumente und Progress Files, die der Agent verändert. Jeder Commit liefert dem Harness einen stabilen Recovery Point und der nächsten Session eine kompakte Historie.

Die Checkpoint-Datenbank speichert den Graph State: Was wurde entschieden, welche Nodes liefen, welche Results kamen zurück und was als Nächstes laufen soll. Der Artifact Store hält große finale Outputs wie PDFs, Parquet Files und Screenshots. Diese Artefakte gehören weder in Git noch in die Checkpoint-Datenbank.

Wann Git als State verwendet werden sollte

Verwende Git, wenn der Workload codeförmig ist (Multi-File-Edits, Refactorings, App Generation) oder dokumentförmig genug, dass File History relevant ist. Das Pattern ist einfach: Einen Run Branch erstellen, einen Initializer Commit anlegen und anschließend an sinnvollen Grenzen committen — nach dem Setup, nach jedem Feature, nach bestandenen Tests und nach dem finalen Cleanup. Speichere die aktuelle Workspace Commit SHA neben der Checkpoint Row. Beim Resume checkt der nächste Worker den Branch aus, liest git log --oneline -8, untersucht git status und den neuesten Diff und liest anschließend PROGRESS.md oder die Handoff-Datei, die die vorherige Session geschrieben hat.

Damit ist Git eine Recovery Surface für das bearbeitete Artefakt und kein Ersatz für die Checkpoint DB. Git kann zwei Fragen beantworten: Was hat sich geändert und welche Version hat die Tests bestanden? Es kann dem Harness nicht sagen, welcher Graph Node als Nächstes laufen soll, welcher Tool Call auf Approval wartet oder welcher Retry seinen Idempotency Key bereits verwendet hat. Anthropics Harness verwendet Initializer Commits plus Per-Feature Commits als Source of Truth für Workspace Recovery; das Model liest git log --oneline -8, um den State wiederherzustellen. Überspringe Git, wenn das Arbeitsergebnis aus einer einzelnen Conversational Answer besteht. Der Overhead lohnt sich dann nicht.

Wann DB Checkpointing verwendet werden sollte

Verwende PostgresSaver-artiges Checkpointing, wenn der Agent eine Graph-Struktur mit mehreren Nodes besitzt, deren Intermediate State relevant ist (Planner → Researcher → Writer → Verifier). Das Reference Repo nutzt es genau aus diesem Grund. Terabyte-große Workspace-Artefakte gehören nicht in den Checkpoint; dafür ist Object Storage zuständig.

Wann ein Artifact Store (S3 / GCS) verwendet werden sollte

Verwende Object Storage, wenn:

• der Output größer ist, als die Checkpoint-Datenbank tragen sollte;
• Downstream Consumer ein URL-addressable Artifact benötigen, ohne über den Agent zu gehen; oder
• Deliverable und Run State unterschiedliche Retention Windows besitzen.

Du könntest beispielsweise das Session Log nach 30 Tagen löschen, den finalen Report aber jahrelang behalten. Strukturiere das Layout nach (thread_id, checkpoint_id, artifact_name), damit der produzierende Run reconstructable bleibt.

Wann Human-Approval-Gates hinzugefügt werden sollten

Füge Gates hinzu, wenn ein Tool Call destruktiv und irreversibel ist (DB Writes, Money Movement, externe Kommunikation), wenn der Tool Call den Blast Radius des Agents verlässt (Production Deployments, kundensichtbare Veröffentlichungen) oder wenn Regulatoren einen Review verlangen. LangGraphs interrupt() und die Approval Middleware von Deep Agents unterstützen solche Gates bereits. Teil 4 hat erläutert, warum diese Gates ein Permission-Thema und kein Prompt-Thema sind.

Eine praktische Production Checklist

Bevor ein Long-Running Agent ausgeliefert wird, beantworte diese Fragen mit konkreten Infrastrukturangaben.

1. Welcher Store besitzt Session Events und Checkpoints?
2. Was passiert, wenn der Worker mitten in einem Tool Call stirbt?
3. Kann ein Run den Workspace eines anderen Runs beschädigen?
4. Welche Aktionen erfordern eine Approval?
5. Können Model oder Sandbox Raw Credentials lesen?
6. Welche Tool Calls können sicher wiederholt werden?
7. Wo wird das Cost Cap pro Run durchgesetzt?
8. Welcher Evaluator mit frischem Context entscheidet über „done“?
9. Wo liegen finale Outputs, nachdem die Sandbox verschwunden ist?
10. Können wir einen fehlgeschlagenen Run morgen erklären, ohne ihn erneut auszuführen?

Wenn die Antwort auf eine dieser Fragen lautet: „Der Prompt weist den Agent an, vorsichtig zu sein“, ist das System noch nicht deployed. Es ist weiterhin eine Demo.

Die nächste Layer ist die Harness Loop

Dieser Runtime kann einen Run am Leben und recoverbar halten, aber Durability beweist nicht, dass die Arbeit korrekt ist. Teil 6, Harness Engineering for AI Agents, öffnet das Harness Primitive aus der obigen Tabelle: Wie ein Trace zeigt, welcher von mehreren Fehlern tatsächlich vorliegt, wo Retry- und Stop-Regeln liegen, was ein Handoff bewahren muss und wie ein externer Acceptance Check entscheidet, dass ein Run abgeschlossen ist. Es ist zugleich der letzte Beitrag der Serie.

Referenzen

Engineering-Beiträge

• OpenAI, Harness Engineering: Leveraging Codex in an Agent-First World.
• Anthropic Engineering, Effective Harnesses for Long-Running Agents.
• Anthropic Engineering, Harness Design for Long-Running Application Development.
• Anthropic Engineering, Scaling Managed Agents: Decoupling the Brain from the Hands, 8. April 2026.
• Cognition AI, Rebuilding Devin for Claude Sonnet 4.5: Lessons and Challenges.
• Vercel, We Removed 80% of Our Agent’s Tools.
• Addy Osmani, Long-Running Agents.

LangGraph und Deep Agents

• LangGraph Docs, Persistence.
• LangGraph Reference, Checkpoints.
• langgraph-checkpoint-postgres auf PyPI.
• LangChain Docs, Deep Agents Overview.
• LangChain Blog, The Runtime Behind Production Deep Agents.

OpenAI Agents SDK

• OpenAI Agents SDK, Sessions.
• OpenAI Agents SDK, Sandbox Concepts.

Temporal

• Temporal Blog, Introducing Temporal and Agentic Sandboxes: The OpenAI Agents SDK.
• Temporal Blog, Production-Ready Agents with the OpenAI Agents SDK + Temporal.
• Temporal × OpenAI Agents SDK Contrib README (temporalio/sdk-python).

Anthropic Platform

• Anthropic, Claude Platform Pricing: Session-Hour-Rates für Managed Agents.
• anthropics/cwc-long-running-agents: Code with Claude 2026 Take-Home mit Evaluator Sub-Agent und Progress-File-Patterns.

Sandbox Provider

• ZenML, E2B vs. Daytona: Sandbox Comparison for Platform Engineers.
• Daytona Docs, Sandboxes.
• Daytona Changelog, Sandbox Fork and Snapshot Endpoints.
• Modal Docs, Sandboxes.
• Modal Docs, Cold Start Guide.
• Runloop on AWS Marketplace.
• Vercel Sandbox Pricing and Limits.

Cloud-Plattform-Timeouts und Quotas

• Google Cloud, Configure Request Timeout for Services.
• Google Cloud, Using WebSockets.
• Google Cloud, Set Task Timeout for Jobs.
• AWS, Configure Lambda Function Timeout.
• AWS, Lambda Quotas.
• AWS, Fargate Throttling Quotas.
• AWS, ECS Service Quotas and API Throttling Limits.

Observability

• OpenTelemetry, Semantic Conventions for Generative AI Systems.
• OpenTelemetry, Gen AI Attributes Registry.
• OpenTelemetry, Semantic Conventions for GenAI Agent and Framework Spans.
• OpenTelemetry, Semantic Conventions for Generative AI Metrics.

Der Code des Market Analyst Agent (LangGraph Worker, Postgres Checkpointer, Qdrant Memory, MCP Sidecar und die oben beschriebene Docker-Compose-Topology) liegt auf GitHub.