Durable agents (long-running, pause/resume)

Agents that persist across time and failures — running for days or weeks, pausing during idle gaps (often human-in-the-loop), surviving crashes, and resuming with full context. The shift from stateless chatbot to production background process, and a distinct maturation axis of the agentic-coding-harness / agent-runtime landscape.

The core architectural move

Separate workflow state from conversation history. Instead of replaying chat to infer progress, durable agents use:

• Explicit state machines / checkpoints — named states the agent can’t skip or hallucinate past; current state injected into the prompt (adk-long-running-agents).
• Persistent session storage — every tool call durably written (e.g. ADK’s DatabaseSessionService, SQLite/Cloud SQL), so a crash resumes from the last checkpoint.
• Event-driven resumption — webhooks/events wake dormant agents and atomically apply a state transition before the next inference (no polling).

The mechanism, concretely (ADK)

ADK’s reference docs (adk-sessions-docs) show the “separate state from history” move as actual classes. A Session holds two things: an events field — “a chronological sequence of all interactions (Event objects)” — and a state field, “a scratchpad for the agent during the interaction.” Replayable history and durable state live side by side. Progress persists by “Appending new interactions (Event objects) to a session’s history,” which is also “the mechanism through which session state gets updated” (sessionService.append_event), so each appended event is the checkpoint a crash resumes from.

Durability is then a choice of SessionService: InMemorySessionService (data “lost if the application restarts”), DatabaseSessionService (Postgres/MySQL/SQLite, with “row-level locking (via SELECT ... FOR UPDATE)” for concurrent safety), or VertexAiSessionService (managed Cloud Agent Runtime). The same agent code becomes ephemeral or multi-week durable by swapping the service — durability as a runtime config, not a model property, which is the thesis below in one design decision.

Where it shows up

• adk (adk-long-running-agents) — the deepest treatment: durable state machines + persistent sessions + webhook resume for multi-week workflows. ADK Go 2.0 makes this a first-class API surface: any graph node pauses into session state for human input and resumes across process restarts by reconstructing the workflow from session history — durable pause/resume promoted from a long-running-agent pattern to the base runtime.
• agentsys, gstack — “state persists across sessions so interrupted work resumes.”
• OpenClaw (claude-code-channels-vs-openclaw) — the self-driven variant: a heartbeat daemon with built-in memory (durability via continuous autonomous operation rather than pause/resume).
• hermes-agent — persistent cross-session memory + hibernation between sessions (and it imports OpenClaw users’ memories); durability paired with self-improving-agents.

Why it matters

Durability is what makes agents usable for real business workflows (onboarding, disputes, multi-touch sequences) rather than single-session demos — and it’s a reliability discipline (checkpoints, atomic transitions) more than a model-capability question, echoing the agentic-coding-harness thesis that structure, not raw model power, unlocks production use.

Related

adk-long-running-agents · adk · agentic-coding-harness · agent-orchestration · claude-code-channels-vs-openclaw · adk-go-2 · graph-based-agent-workflow