Durable execution for AI agents: open source, and the output survives

What breaks an agent run

Durable execution is usually sold as insurance against a crash. For an agent, a crash is the rarer half of the problem. The four failures that end a run look different from each other, and only one of them is a process dying.

A tool call that takes minutes. The agent runs a test suite, a build or a crawl, and the call takes longer than anything upstream will wait. A process that gives up here loses the context already gathered, the tokens already paid for, and every edit it made but has not written down. Restarting pays for all of it twice.

A rate limit or a provider error. The model call fails at the ninth step of twelve. With no record of the first eight, the run begins again from the prompt, and step nine is paid for twice.

An approval that arrives the next morning. Nothing failed. The run is waiting for a person to say yes, and a process that exits while it waits throws away the work underneath. An approval that costs a night of wall-clock time is ordinary in agent work and close to unknown in a payment pipeline.

A sandbox recycled mid-run. The machine goes away, and whatever lived only on that machine goes with it.

Three of those four are waits. A retry does not shorten a wait, and a crash-proof journal does not tell anyone what happened to the twelve files an agent had half-edited. That is the gap worth designing around. For agent work the thing that has to survive is the change, and a change has an owner who accepts or rejects it.

Why a retry fixes one failure and deepens another

Retrying a read is free. Retrying a write is not. Most agent tool calls are writes: create the ticket, send the message, push the commit, update the row. Few of them come with a natural idempotency key, and the duplicate side effect usually surfaces days later, long after the retry has been forgotten.

Retries also hide the wait. Wrap an approval in a retry and you get a loop that wakes every minute for ten hours, or a timeout that fires at the wrong moment. The retry count was never the problem. The run had nowhere to sit while a person was away from their desk.

Two schools, and what each asks of your code

The market answers the crash half in one of two ways.

A replay engine keeps a history and re-executes from it. Temporal calls durable execution "crash-proof execution". It organizes an application into workflows and activities, dispatched to polling workers, and its durable steps are activities, timers, signals, queries, updates and schedules (Temporal's definition). Replay is why workflow code must stay deterministic: the same inputs have to take the same path on the second execution. Restate carries the idea into ordinary code, and its own page calls durable execution "a programming paradigm that makes ordinary code resilient to crashes, restarts, and infrastructure failures" (Restate's definition). Restate claims "a few milliseconds" of overhead per durable step, and up to 10× better cost efficiency than Temporal Cloud. It runs inside your own cloud account (its comparison).

What that school asks of a team: a cluster to run or a bill to pay, step boundaries drawn in the right places, and workflow code treated as something that will execute twice.

The second school checkpoints into a database you already operate. DBOS builds durable workflows on Postgres, and its repository says the durability is "entirely contained in this open-source library, there's no additional infrastructure for you to configure or manage" (DBOS). What it asks: the work runs as DBOS workflow functions, and the Postgres is yours to back up, restore and query.

Both schools record the steps of a process. Neither has an opinion about the artifact at the end. A run can replay perfectly and still leave twelve edited files that somebody has to read, understand and accept, and that decision sits outside both designs.

The session as the durable unit

Kortix starts from the artifact. 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 branch is a git object in a repo you own, so the unit of resumption is a commit rather than a stack frame. Kortix's own agent prompt says it in one line: the session is an ephemeral branch of the repo, and only what you commit and push survives.

Work leaves a session as a change. 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, and merge is default-deny for agents. That step is where an agent run stops being a process and becomes something a business can accept, reject or send back.

Two more pieces make it repeatable. A trigger starts a session with nobody present: cron on a schedule slot, webhook on a signed POST, event when something happens in a connected app, or monitor when a command in your repo prints a line on stdout. Read the docs for the four types and the CLI that adds one. A reminder re-prompts one existing session later, once or on repeat, which covers the approval that arrives tomorrow without holding a process open all night. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan.

Kortix does not replay a process, and that limit is worth stating plainly. What survives a run is what was committed and pushed, plus the change request it produced. A team that needs deterministic replay of arbitrary code, month-long timers inside a function, or orchestration across a dozen services still needs an engine. The two can meet in the middle: a scheduler you already run can call a trigger, and the change request becomes the handoff back into your pipeline. For the approval side of that handoff, read the guide on reliable agent workflows.

Five questions to ask your own agent

Where does the resume point live? If the answer is "in the engine's memory" and you cannot point at a commit, a row or a file, the work is recoverable at best. Recoverable is a smaller promise than durable, and it is the one most agent teams have actually bought.

What happens to uncommitted work? Ask what a sandbox recycle costs. If the answer is four hours of edits, the design needs a commit boundary, not a longer timeout.

Who accepts the output? A durable run that nobody reviews is a queue with extra steps. Name the person or the role, and name what they look at: a branch, a pull request, a change request, a report.

How do you audit it afterwards? A run you cannot reconstruct is a run you cannot defend in an incident review. Check what the tool records, who can read it, and how long it is kept before you need it.

Who starts it at 3am? A schedule or a signed webhook that starts the run, not a person who remembers to. If the honest answer is "someone on call", the durable part is missing.

If the answers point at a branch and a reviewer, the comparison table is the next thing to read. If they point at deterministic replay of code that has nothing to do with files, an engine is the right tool, and what durable execution means covers that vocabulary.