Corpus Agentis
The field book to agent ecosystems
The field book to agent ecosystems
Design · Runtime

Stateful vs stateless

Statefulness is one axis, not two: memory (what an agent knows) at one end, runtime durability (where it is in a task) at the other. The ladder places every mechanism on that spine; the table shows how much state real task types actually need; the catalogue is the durable-execution engines, by mechanism.

The statefulness ladder · 8 mechanisms
MEMORY, WHAT IT KNOWSRUNTIME, WHERE IT IS IN A TASK StatelessnothingSession1one sessionLong-termmemoryknowledgeStatefulactor1co-locatedCheckpoint2snapshotEventreplay2journalStatemachine2FSM positionDurablefunctions6code progress ephemeral durable
memory both runtime dot fill = engines catalogued
Hover any rung for its definition and recovery model; click to jump to its engines. Sources: first-party vendor docs (Temporal, AWS, Azure, Google, Cloudflare, LangChain, OpenAI, Letta), cited on each engine below.
How much state does the task need? · by task type
TaskTypical runState needIf stateless, you lose…What durable buysExamples
Chat Q&A seconds Session the thread across turns, every message starts cold, no follow-ups, no personalisation conversation recall and personalisation within the session ChatGPT Agent, Claude Agent, Gemini Agent
Coding (agentic) minutes to hours Durable dies mid-task, redoes finished work, drops uncommitted edits on any crash resume-after-failure, checkpointed multi-file edits, long test-and-fix loops that survive restarts Devin, Cursor
Design activity minutes, iterative Session to long-term the brand rules and prior decisions between iterations: each pass forgets the last recall of prior decisions, brand constraints and the iteration history v0
Research (deep) minutes to hours Durable + long-term truncates on long runs, cannot accumulate findings across many sources, restarts from zero on failure fan-out across sources, accumulation of findings, resume of long-running jobs OpenAI Deep Research, Perplexity Deep Research, Gemini Deep Research
Ops / automation seconds to days Durable (suspend/resume) cannot wait for a human approval or an external event without holding a process open parks for human sign-off or an external signal, then resumes exactly where it left off Lindy
Durable-execution engines · 14 · by mechanism
Session state · 1
reloaded within a session; lost if the process dies
OpenAI Agents SDK (Sessions) OpenAI
Framework · OSS
Sessions auto-store conversation history in a SQLite/Redis/DB store, reloaded before each agent run. ↗ T1
Stateful actor + hibernate · 1
single-writer object hibernates then wakes
Cloudflare Durable Objects Cloudflare
Co-located actor
Single-writer object co-locates state with compute; Hibernation API evicts then wakes it, preserving state. ↗ T1
Checkpoint / snapshot · 2
resume from the last saved snapshot
LangGraph LangChain
Framework · OSS
Checkpointer snapshots graph state at each super-step, enabling resume, time-travel and human review. ↗ T1
Letta (MemGPT) Letta
DB-native · OSS
Persists memory blocks, message history and archival memory to Postgres so agents stay stateful. ↗ T1
Event-replay · 2
deterministic replay to reconstruct state
Temporal Temporal Technologies
External orchestrator · OSS
Replays a durable, append-only event history to rebuild workflow state and resume after any crash. ↗ T1
Restate Restate
External orchestrator · OSS
Journals each action's result and deterministically replays the journal to resume handlers after a crash. ↗ T1
Managed state machine · 2
durable transition between declared states
AWS Step Functions Amazon Web Services
Managed service
Runs a JSON/ASL state machine; the service durably tracks each state transition and waits on callbacks. ↗ T1
Google Cloud Workflows Google Cloud
Managed service
Managed state machine runs YAML/JSON steps in order, durably persisting state between steps and waits. ↗ T1
Durable functions · 6
replay / memoize completed steps
Azure Durable Functions Microsoft
Managed service · OSS
Orchestrator code is checkpointed via event sourcing; the runtime replays it to resume after failures. ↗ T1
Cloudflare Workflows Cloudflare
Managed service
Automatically persists each step's output on Workers; resumes from the last completed step, sleeps for weeks. ↗ T1
Inngest Inngest
External orchestrator · OSS
Memoizes each step's result in a managed store, then replays and skips completed steps after failures. ↗ T1
DBOS DBOS, Inc.
DB-native · OSS
Checkpoints workflow and step state into Postgres so execution resumes from the last completed step. ↗ T1
Hatchet Hatchet
DB-native · OSS
Postgres-backed engine persists task and step progress, replaying from the last checkpoint after failures. ↗ T1
Trigger.dev Trigger.dev
Managed service · OSS
Checkpoints a running task's full process state (CRIU) while it waits, then restores it where it paused. ↗ T1
Long-term memory engines (Letta, Zep, Mem0) live in Memory · Providers: the same statefulness axis, memory end.
Field notes

One axis: memory at one end, runtime durability at the other

Most agents follow a standard workflow pattern, and they hit the same constraints workflow engines were built for: a long-running process has to survive a crash, retry one step without repeating the whole run, and know where it got to.

Show more

None of this is magic. It is the logic, branching and system architecture that CRM automation and engineering pipelines have used for years, pointed at agents. Expect durable execution to become an assumed part of the stack rather than a choice.

From the corpus, curated by Brandon Chaplin
Common questions
What is durable execution?

A way of running a workflow so it survives crashes, restarts and long waits. The engine records progress as it goes, so if the process dies halfway through, the work resumes from the last recorded point instead of starting again (Temporal).

What is the difference between a stateful and a stateless agent?

A stateless agent starts cold on every call and loses everything in flight if it crashes. A stateful agent persists something between calls: either what it knows, which is memory, or where it is in a task, which is runtime state. Most agents need the first; long-running ones need both.

Why do long-running agents need a workflow engine?

Because a task that runs for hours will hit a crash, a rate limit, or a wait for someone to approve something. Without persisted progress, any of those means starting from the top. Temporal, AWS Step Functions, Azure Durable Functions, Cloudflare Workflows and LangGraph all store that progress for you.

What is a checkpoint in an agent workflow?

A saved snapshot of the agent's state at a point in the run, restored after a failure. The alternative is event replay: keep a log of everything that happened and rebuild the state by replaying it. Checkpoints recover faster; replay is slower but gives a full audit trail.

How much state does an agent actually need?

Less than most teams assume. A question-and-answer bot needs only the current session. A coding agent needs progress it can resume. A multi-hour research run needs a durable journal. Start with the lightest option and move up when a real failure forces it.

Is agent memory the same as runtime state?

No. Memory is what the agent knows: facts, past conversations, preferences. Runtime state is where it is in a task: which step finished, which is still pending. They are usually stored in different places and you can lose one while keeping the other.

Next in the learning path