Why Checkpointing Is Not Agentic Durable Execution for Production AI Agents

Every agent framework worth using has some form of persistence. LangGraph has checkpointers and thread IDs. CrewAI has @persist and task replay. Google ADK has an event-sourced session service with resumable invocations. Read the feature lists and durability looks solved.

Then the durability claim gets tested. The agent is partway through issuing a customer refund when the server it runs on restarts. The state was saved, so the framework did its part. Everything after that is yours. Nothing noticed the run stopped, and nothing will start it again. When you do, you have to point it at the right run and be sure nothing else picked up the same one, or the customer gets refunded twice.

Yaron Schneider, CTO & Co-Founder, covered the mechanics framework by framework in Why LangGraph, CrewAI, Google ADK, and Others Fall Short for Production Agent Workflows. This one is about what production needs and what Catalyst does about it.

Saving state and resuming from the failing step are different problems

A checkpoint answers one question: where the run had got to. That is useful, and it is where most frameworks stop.

Figure 1. A checkpoint records where the run got to. When step 3 crashes, the run still starts over from step 1, and finishing it is your responsibility.

Resuming from the failing step answers a harder set of questions. Did the run stop, or is it just slow? Which step was in flight when the process died? Have the completed steps already had their side effects, and if so, how do you avoid repeating them? If everything went down, what restarts the run? Every one of those needs an answer, and checkpointing alone answers none of them.

Agentic durable execution is the layer that does. Four properties carry it.

Figure 2. Agentic durable execution detects the failure and resumes from the last checkpoint, carrying the run forward from step 3 rather than step 1.

History

A checkpoint is usually the latest state, overwritten as the run progresses. Production needs an append-only record of every step, its inputs, its outputs, and its position in the run. That record makes recovery deterministic rather than a guess, and it is also the only thing that can answer what an agent did weeks later.

CrewAI's task replay keeps only the most recent kickoff. Run four hundred crews overnight and there is nothing to query for which failed and where.

Replay

With a full history, recovery becomes replay. The workflow function runs again from the top, but every step that already completed returns its recorded result instead of re-executing. Local variables come back. Execution continues at the step that failed, with no conditional skip logic in your own code.

That is the difference between a run that recovers and one that starts over, and it is what finance notices. A ten-step agent that dies on step nine and restarts from the top pays a second time for eight LLM calls that already succeeded. Replay pays for step nine.

Recovery

Something has to notice the failure. In the framework model that something is you, which means building failure detection, locking, and retry infrastructure more reliable than the agents it supervises.

Catalyst sets a durable reminder before each step, a scheduled callback that outlives the process that set it. If the process or the whole cluster goes down, the reminder reactivates the workflow and carries it forward when capacity returns. Workflows and activities are distributed across nodes, so a dead node triggers rebalancing rather than lost work. There is no failure to detect, because detection was never the mechanism.

Observability

Because the engine records every step rather than your process holding it in memory, you can see the state of every run: which are in flight, which are waiting on an external event, which failed and at which step, and what each step cost. That view comes from the same history that drives replay.

Where verification comes in

Everything above still describes a log your own runtime wrote about itself. Good enough to recover from a crash. Good enough to debug. Not good enough when a regulator asks what an agent did and the answer cannot depend on trusting you.

Catalyst signs each step as it completes, propagates lineage so the record is a connected chain, and attests every workflow and activity against a SPIFFE workload identity over mTLS. SPIFFE is an open standard for issuing cryptographic identities to workloads, so a signed step proves which agent produced it. Anyone with the public key can verify the signatures and walk the chain. The history stops being an account and becomes evidence. Those capabilities landed in open-source Dapr 1.18.

What this looks like in your code

None of this asks you to move off your framework. Keep the LangGraph graph, the CrewAI flow, or the ADK agent, and wrap it in a Catalyst runner. Each node becomes a durable workflow activity, state lives in the workflow engine instead of process memory, and the reasoning code stays as written.

Figure 3. Catalyst slots underneath the agent framework, so the reasoning code stays as written while history, replay, recovery, and attestation come from the engine below it.

Over ten frameworks have native integrations today, including LangGraph, Microsoft Agent Framework, Google ADK, AWS Strands, and OpenAI Agents SDK and more. Underneath all of them the same engine handles history, replay, recovery, and observability, with signing and attestation on top.

The bottom line

Checkpointing is fine for a prototype. It stops being fine the first time that refund goes out twice and someone has to explain why.

Every team that reaches production builds some version of this layer, and it has to end up more reliable than the agents running on top of it. That is the part worth not writing yourself.

Break it on purpose

The fastest way to judge this is to try to lose a run. Start a free Catalyst project, wrap an agent you already have in the runner, and kill the process mid-run. Either it comes back on the step that was in flight or it does not, and you find that out in an afternoon instead of during an incident.

Start for free and pick your framework from the quickstarts. If the pressing question is proving what your agents did rather than keeping them alive, talk to someone who has put signed, attested execution into production.