What durable execution means for open-source agent work

The definition both vendors give

Temporal and Restate are the two vendors people quote for this term, and their definitions agree almost word for word. Temporal's blog reduces it to four words: "Durable Execution is crash-proof execution." Restate is more precise: "Durable Execution is a programming paradigm that makes ordinary code resilient to crashes, restarts, and infrastructure failures. A durable execution engine records each step of a function as it runs."

Read them together and the machine is plain. Code is cut into steps. Each completed step's result is written to a journal before the next one starts. If the process dies mid-run, a fresh process reads the journal, replays the finished steps from their recorded results instead of executing them again, and picks up at the first step that never completed. Determinism is the price of admission: replay follows the same path only if the code branches on journaled values and not on a fresh clock reading.

Three things a journal buys

Retries stop being custom code, because the engine retries a failed step under the policy you declared. State survives a process death, because it lives in the journal and not in memory. Resumption starts at the last completed step, so a twenty-step job does not repeat its first nineteen.

What the definition leaves out

All of that answers one question: what happens when the machine stops. It says nothing about three others.

Where the resume point lives

A replay engine keeps the journal in its own service or database, so recovery depends on that store staying reachable. A library that checkpoints into Postgres keeps it in your database instead.

Who accepts the result

The engine knows that a function returned. It holds no view on whether the return value was any good. A step that wrote the wrong number into the wrong row is a completed step: journaled, retried never, correct by definition of completed.

What a step is when the work is an agent

A step in a billing workflow is a function call with a known return type. A step in agent work is a read of a repo, a plan, an edit across a dozen files, a command that fails for a reason the agent has to interpret. The Kortix blog walks through the failure modes that show up once an agent is doing real work.

What is durable execution in AI?

In AI work, the state worth keeping is the working tree and the change that comes out of it, not the call stack that produced them. That is a different decision from replay, and the one Kortix makes.

Kortix keeps agent work in a git repo. A session runs one agent in its own sandbox: the sandbox clones the project repo and works on a new branch whose name is the session id. The starter agent's own prompt states the consequence without softening it: "Only what you commit + push survives." The reasoning, the shell history and the half-finished edits stay behind in a sandbox that is thrown away.

The bar is lower than crash-proof execution. The agent commits, pushes its session branch and opens a change request against the project's default branch. A person with the merge permission merges it. Merge is default-deny for agents. What survives is a diff somebody can read, comment on and reject. It outlives the model, the run and the machine that produced it. Six weeks later the change request still holds the change, the discussion and the decision.

Kortix does not claim more than that. It is not a durable-execution engine, and a session does not resume where a crash interrupted it. What it makes durable is the output: a branch, a change request and a record of who merged it.

What is a durable execution pattern?

A pattern here means where the engine keeps its history. Two shapes recur.

Replay-based engines, the school Temporal and Restate belong to, keep a journal or an event history outside your process and run your workflow code against a deterministic runtime. The side-effecting steps go out to workers. Temporal calls them activities; Restate calls them durable steps. The pattern suits a process that spans hours or days, takes timers and external signals, and can be written so a replay produces the same branch every time.

Database-backed libraries put the checkpoint in the database you already run. DBOS states the idea most cleanly: durable workflows are "entirely contained in this open-source library, there's no additional infrastructure for you to configure or manage", with Postgres transactions doing the work a separate engine would do. It suits short workflows that touch rows you own, where a step and its write commit together.

Agent work has a third shape, and the difference is in the artifact rather than the store. The unit of recovery is a branch and a change request, the acceptance step is a review by a person, and none of that needs replay to be correct. Durable execution for AI agents works through that case in detail.

Starting durable work with nobody present

Durability on its own does not make work start. Something has to fire while everyone is asleep. A trigger does that: it starts a session with nobody present. Kortix's docs list four kinds: cron, a schedule slot or run_at; webhook, a signed POST; event, something happens in a connected app; and monitor, a command in your repo that prints a line on stdout.

A trigger is not a queue consumer

A consumer is a long-lived process that pulls work and has to be running to keep pulling; if it dies quietly, work stops moving. A trigger is configuration: when its condition fires it starts a session on its own machine, so Saturday morning's digest does not depend on a laptop being open or a worker being healthy.

When an engine fits, and when the session is enough

• Reach for a replay engine when the sequence itself must survive: steps you own and can keep deterministic, timers, external signals, and a recovery point somewhere in the middle of a long run.
• Reach for a database-backed library when the workflow is short, the data lives in your Postgres, and a checkpoint in the same transaction as the write is the whole requirement.
• Reach for a session and a change request when the unit of work is a change to a repo that a person reviews. The review is the acceptance step, and no journal supplies it.
• Combine them. An engine can own the pipeline that decides what work exists while each piece runs as a session behind a trigger: durable entry point, reviewable artifact.
• If the only state you need back is what ran and what it changed, the branch and the change request already are that record.

Durable workflows and durable execution engines each take one of those branches further. What stays constant is the question worth asking before you pick a tool: after this dies, what exactly do I want back?