Durable State for Coding Agents: LangGraph vs Google ADK vs OpenAI Agents SDK

#python #agents #ai #programming

Long-running coding agents fail in ways a chat demo hides: the worker restarts, a human approval arrives hours later, or a tool call is interrupted after changing the repository. “Memory” alone is not enough. You need to know what state is saved, what resumes, and what may run twice.

This is a documentation-based comparison of LangGraph, Google ADK, and the OpenAI Agents SDK. It is not a benchmark, and I did not run a common workload across the three. I reviewed the official documentation on July 21, 2026.

Evaluation criteria

I compared each option on:

State model: conversation history, workflow state, and cross-session data.
Durability boundary: what is persisted and when.
Resume primitive: how a paused or interrupted run continues.
Replay and side effects: whether tools or nodes can execute again.
Production path: storage backends and operational control.
Coding-agent fit: repository edits, tests, approvals, and long waits.

At a glance

Framework	Primary durable abstraction	Resume handle	Cross-session memory	Main sharp edge
LangGraph	Checkpointer for thread state; Store for shared data	thread_id plus graph input or Command	Store, separate from checkpoints	Resumed nodes can replay; side effects must be idempotent or isolated in tasks
Google ADK	Session events and state via a SessionService	session_id plus prior invocation_id when resumability is enabled	user: and app: state scopes with a persistent service	Tools are at-least-once on resume and may run more than once
OpenAI Agents SDK	Session history, RunState, or server-managed conversation	Same session plus resumed RunState	Pluggable sessions or OpenAI-hosted Conversations	Sessions preserve history, but durable workflow execution is an integration concern

These are not interchangeable terms. A conversation session can preserve messages while still leaving your workflow step, approval status, or file-write outcome undefined.

1. LangGraph: explicit checkpoints plus a separate Store

LangGraph splits persistence into two deliberate layers. A checkpointer saves graph state for one thread. A Store holds application-defined key-value data across threads. That maps cleanly to a coding agent:

checkpoint: the current repository task, plan, tool results, and approval pause;
store: reusable user preferences, team conventions, or a verified project index.

The thread ID is the durable cursor. For a human approval, interrupt() pauses execution, saves state, and later resumes with a Command using the same thread. This is a strong fit when you want the workflow graph and its control flow to be inspectable.

The important limitation is replay. LangGraph documents that execution resumes from a checkpoint boundary, not from the exact Python line. A node can run again. Wrap nondeterministic work and side effects in tasks or nodes, make writes idempotent, and use an idempotency key for operations such as opening a pull request or applying a migration.

Best fit: a coding workflow with explicit stages such as inspect → plan → approve → edit → test → review, especially when you need time travel, human-in-the-loop pauses, or recovery after failure.

2. Google ADK: event-backed sessions and resumable workflows

Google ADK’s Session is more than a message list. Its state is a serializable key-value scratchpad, and the SessionService determines whether it survives a restart. InMemorySessionService is not durable; DatabaseSessionService and VertexAiSessionService are the production-oriented persistent choices documented for state.

ADK also makes scope visible through prefixes:

no prefix: current session;
user: shared across that user’s sessions;
app: shared across the application;
temp: current invocation only and not persistent.

With resumability enabled, ADK records completed workflow tasks in Events. A stopped workflow can be resumed with the saved session and invocation IDs. Sequential and parallel workflows use recorded completion state to avoid re-running completed branches where possible.

But the safety warning matters for coding agents: the official resume documentation says tools are guaranteed to run at least once and may run more than once during resume. A tool that edits a file, pushes a branch, or creates an issue therefore needs duplicate protection and a post-run reality check.

Best fit: teams already using Google’s agent runtime and wanting session-scoped, user-scoped, or app-scoped state plus resumable sequential or parallel workflows.

3. OpenAI Agents SDK: flexible sessions, explicit run continuation

The OpenAI Agents SDK provides a pluggable Session interface. The runner loads session items before a run and persists new items afterward. The official Python docs list file-backed SQLite, Redis, SQLAlchemy, MongoDB, Dapr, encrypted wrappers, and OpenAI-hosted Conversations as options.

For a paused human approval, the SDK serializes a RunState. You approve or reject the interruption, then run again with that state and the same session. That is a useful distinction: the session stores the conversation history, while RunState represents the interrupted execution that must continue.

The SDK also lets you limit retrieved history or customize how history is merged before a model call. That helps control context growth, but it is not the same as checkpointing every arbitrary workflow step. For long waits, retries, or process restarts, the official running-agents guide points to durable-execution integrations such as Temporal, Dapr, Restate, and DBOS.

Best fit: an agent application that primarily needs durable conversation and approval continuation, or a team comfortable adding a workflow runtime when execution must survive long outages and waits.

The coding-agent decision rule

Choose based on the failure you must recover from:

“Resume this graph at a known stage and inspect prior state.” Start with LangGraph.
“Persist session, user, and app state inside Google’s agent runtime.” Start with Google ADK.
“Persist conversation history and resume an approval, then add a workflow engine when needed.” Start with OpenAI Agents SDK.

Do not select based only on the word “memory.” Ask where these facts live after a crash:

Which commit or worktree was active?
Which tools completed successfully?
Was the approval granted for this exact command and arguments?
Is the next step safe to replay?
Can an operator inspect and delete stale state?

A practical state contract

Regardless of framework, persist a small, explicit contract rather than dumping the entire prompt into memory:

{
  "task_id": "issue-1842",
  "repo_sha": "abc123",
  "worktree": "/worktrees/issue-1842",
  "phase": "tests",
  "approved_action_hash": "sha256:...",
  "completed_tools": ["read_diff", "run_unit_tests"],
  "next_action": "run_integration_tests",
  "idempotency_keys": ["issue-1842:patch:1"]
}

Keep secrets and untrusted tool output out of durable memory unless you have a retention, encryption, and retrieval policy. Persist identifiers and verified results, not credentials.

What to do now

Pick one failure scenario: worker restart during tests, approval wait, or duplicate patch application.
Draw the state boundary: conversation, workflow cursor, tool result, and cross-session memory are separate things.
Add a stable task ID and idempotency key to every side-effecting tool.
Run the same scenario twice: once normally and once after killing the worker at each tool boundary.
Verify the repository, branch, issue tracker, and CI system after resume. “The framework resumed” is not proof that the side effect happened exactly once.

Candid limitations

This comparison is based on official documentation, not a common benchmark. APIs and integrations change quickly, and “persistent” does not by itself specify transactionality, encryption, retention, multi-writer behavior, or exactly-once effects. Storage latency, deployment topology, and tool design can dominate the framework choice. Treat the documented resume semantics as design constraints, then test your own failure modes.

If you are working on observability, see how to turn agent traces into regression tests. For a related control-flow choice, see handoffs vs subagents across agent frameworks.