Skip to content
Durable Execution Guide
menu

durable execution for a workload that edits a repo

Open-source durable execution for agents: the change is the record

The open-source AI Operating System

Durable execution keeps a run alive after a crash by recording each step. When the run is an agent, the state worth keeping is the edit. Kortix is the open-source AI Operating System: your agents, their skills, your company memory and every connector in one git repo you own.

Self-host is free · Read it, fork it, audit it · Every action is recorded. Reading, exporting and streaming the audit log depend on the plan

A merged Kortix change request, showing six changed files and a code diff

sourcegithub.com/kortix-ai/suna/pull/11059

Session work reaches main through a change request. Merge is default-deny for agents.

agents/kortix.md
You are hands-on: you read, edit, run, search, fetch, and ship. Thesession you're in is an isolated sandbox — an ephemeral branch ofthis repo, your own `/workspace` — so you can install, experiment,and recover freely. Only what you commit + push survives.

github.com/kortix-ai/suna/blob/dev/packages/starter/templates/base/agents/kortix.md

triggers
kortix triggers add daily-digest --type cron \  --cron "0 0 9 * * 1-5" --timezone Europe/Berlin \  --prompt "Summarize yesterday's commits and open change requests." --apply

kortix.com/docs/connect/triggers

Three runs that outlive the machine that started them

One agent job per card, the interruption it has to survive, and what it hands back.

Approval wait

The reviewer looks nine hours after the run ends

The agent opens a change request at 18:40. Its sandbox is gone by 19:00. The branch and the diff wait for a person at 09:15, and no process has to stay awake for that wait.

change request #1842What comes back
commitchange
a41c9raise the retry budget in client.ts
7d20eadd the retry note to runbook.md
f3b81cover retries in the client test

Opened 18:40, merged 09:15 the next morning

Nightly run

02:00, with nobody at the keyboard

A cron trigger starts a session that reads yesterday's commits and opens a change request with the digest before anyone signs in. The trigger is configuration, so the job runs whether or not a worker is healthy.

digest.mdWhat comes back
+## 2026-10-28+- api: retry budget raised to 5 in client.ts+- web: pricing copy moved to content/pricing.ts+- open: 2 change requests awaiting review

Change request #1851, opened 04:12 by the 02:00 run

After the fact

Explain the change three weeks later

Every action is recorded. Reading, exporting and streaming the audit log depend on the plan, so check before you need the trail. The change request carries the rest: the diff, the review and who merged it.

run-1028.jsonWhat comes back
run
02:00 cron trigger
session
9f3c
opened
change request #1851
merged
09:40
log
by plan

The change request keeps the diff and the merge

The engines, and the unit each one keeps

Kortix first. The six engines record steps so a process survives a restart. Kortix makes the finished change the thing that survives.

Recommended

Kortix

Open source
Yes
The durable unit
A session, on its own branch
Self-host
Cloud, your VPC, or on-prem; free

Temporal

Open source
Yes, MIT
The durable unit
A workflow and its activities
Self-host
One binary, brew or Docker

Restate

Open source
No, Business Source License 1.1
The durable unit
A function, step by step
Self-host
One self-contained binary

Inngest

Open source
Server SSPL, SDKs Apache 2.0
The durable unit
A function: triggers, flow control, steps
Self-host
Your own infrastructure, or its server

Trigger.dev

Open source
Yes, Apache-2.0
The durable unit
A TypeScript task
Self-host
Docker guides

DBOS

Open source
Yes, MIT
The durable unit
A workflow on Postgres
Self-host
A library, no extra infrastructure

Hatchet

Open source
Yes, MIT
The durable unit
Background tasks, agents, workflows
Self-host
Hatchet Cloud or self-hosted

Open source, so the record is yours to read

Open source. Read it, fork it, audit it.

  • Run it on Kortix Cloud, in your VPC, or on your own on-prem network; self-host is free.
  • The agent, its skills and the schedule that starts it are files you can diff.
  • Every action is recorded. Reading, exporting and streaming the audit log depend on the plan.

Kortix on GitHub · Read the docs · Kortix blog

Questions people ask about durable execution

What is a durable execution?
A durable execution keeps the record of a run outside the process. The work continues after a crash, a restart or a deploy. In agent work, the record worth keeping is the edit it made to your repo. The engine takes over the retry, so the process can be replaced.
What are some examples of durable execution frameworks?
Temporal, Restate, Inngest, Trigger.dev, DBOS and Hatchet are the engines usually named. Each records steps in its own store. Restate says its BYOC model is up to 10× more cost efficient than Temporal Cloud. Kortix takes another route, where the record is a branch.
How to trigger a durable function?
From outside the process. A schedule, a signed webhook, an event in a connected app, or a command that prints a line. Temporal dispatches a workflow to polling workers and lists Schedules. Kortix starts a session from a cron, webhook, event or monitor trigger.
What is a durable task?
A unit of work whose progress is written down as it runs. A failure resumes it instead of restarting it. Microsoft's Durable Task framework builds fault-tolerant workflows as ordinary code on that idea.
What does durable execution mean?
It means the engine holds the state of a run, not your process. A crash resumes at the last recorded step. When the run is an agent, that leaves open the other half: who accepts the change it made.
Does a Kortix session resume after a crash?
No. The sandbox is gone and nothing replays the run. What survives is what the agent committed and pushed: a branch and a change request you can still review, merge or close.
Is Kortix a durable execution engine?
No. A session is not a replayed workflow. Kortix keeps the work in branches and change requests, so what survives is the change a person reviews, not a journal of steps.

Put an agent behind a trigger and read the change it opens

Open source, self-hosted or on Kortix Cloud, so the branch stays in a repo you own.

Self-host is free · Read it, fork it, audit it · Every action is recorded. Reading, exporting and streaming the audit log depend on the plan