An engine keeps the process alive; open source keeps the change reviewable

Two questions a failure asks

Temporal defines its own category in five words: "Durable Execution is crash-proof execution." Restate sells the same category and explains the mechanism instead. A durable execution engine "records each step of a function as it runs", so ordinary code survives crashes, restarts and infrastructure failures. Temporal and Restate describe the same guarantee from two angles.

Both definitions answer one question. Did the process finish? A worker dies mid-call. A task queue loses a message. A network call times out. The engine replays recorded state and carries on, so the answer becomes yes even though something broke.

Agent work asks a second question. Was the result right, and who accepted it? A process can be crash-proof and still write a wrong file. It can produce a patch that compiles and breaks the build. Replay has nothing to say about that, because replay knows what the code did, not what a person wanted.

Where a durable execution engine wins

Plenty of work is a better fit for the engine, and pretending otherwise would waste a quarter. Take a payment flow across four services, an order pipeline, or a nightly reconciliation of two ledgers. Or a batch job whose steps are deterministic code you can replay with confidence. Temporal or Restate will do a better job than an agent runtime at all of those, because the work never needed judgment. It needed ordering, retries and a record.

Temporal's model is documented plainly. Applications are workflows and activities, dispatched to polling workers, with timers, signals, queries, updates and schedules as the durable primitives. Restate keeps the code inline instead: a function runs its durable steps in place, each step journaling as it commits. Restate claims "up to 10× more cost efficient" than Temporal Cloud, with "a few milliseconds" of overhead per durable step, and runs inside your own cloud account. Both products are comfortable with a timer set for ninety days, which is a normal thing to write in either.

The price sets the bar for every alternative. Temporal Cloud is pay as you go: free with $150 in credits for 90 days, no base fee. After that, $0.042 per GB-hour of active storage and $0.00105 per GB-hour retained. Business starts at $500 a month for 2.5 million actions and 100 GB of retained storage (Temporal pricing). Restate self-hosts as a single binary, run with Docker, Homebrew or npx (Restate on GitHub).

What you are buying in either case is a durable log, a dispatcher and a replay engine. For orchestration, those are the right things to buy.

Where the platform wins

Agent work ends in a file, and a file needs an owner. In Kortix, the unit is the session. The sandbox clones the project repo and works on a new branch whose name is the session id. The prompt the agent reads on that branch is explicit about what survives (Kortix on GitHub):

"The session you're in is an isolated sandbox — an ephemeral branch of this repo … Only what you commit + push survives."

That line is the design. Kortix makes no promise that a session resumes after a crash, because the thing worth resuming is already in git. The agent's last instruction is to commit and push its session branch. Then it opens a change request against the project's default branch, where a person with the merge permission merges it. Merge is default-deny for agents (Read the docs).

So the reviewer opens a diff: the branch and the changed lines. The question "was the result right?" gets answered by the person who owns the repo, inside the tool they already use to review code. That is a weaker durability guarantee than replay. It is a stronger acceptance guarantee, and for work that changes a company's files, acceptance is the harder half. A team with nobody to operate a cluster can still start a session and review a diff.

Auditability takes the same shape. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan. A manager who has to answer "what did it do last Tuesday" gets a list of actions and a branch to inspect, rather than a reconstruction from logs.

Kortix is an AI Operating System, and its session, branch, change request and triggers are what make an agent's work survive long enough to be judged.

Your scheduler starts the session, the change request ends it

The two halves compose with very little glue. A trigger starts a session with nobody present. There are four kinds. A cron trigger fires on a schedule slot, or once at a time you choose. A webhook fires on a signed POST. An event trigger fires when something happens in a connected app, and a monitor fires when a command in your repo prints a line on stdout. Each one is a way for a system you already run to hand work to an agent (triggers docs).

Your existing scheduler keeps its job list. Its last step becomes a signed POST, and the session does the part a scheduler was never good at: read the repo, write the change, run the checks. A cron entry covers the cases where the scheduler is missing entirely.

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

The return path is the change request. Your pipeline reads it, runs its own gates against the branch, then merges or closes it. The engine never has to know how a file was edited. It only has to know that a step finished, and the change request is that step's result. If the work continues after the merge, the engine's next step starts from the commit that landed.

For a longer treatment of each side, see durable execution engines and durable execution for AI agents. The pattern appears in Kortix's blog.

Three situations, three tools

• A ninety-day timer, or a payment flow across four services, with no agent involved: Temporal or Restate.
• An agent that edits a repo, and a person who approves the edit: Kortix.
• A pipeline that must hand work to an agent and get a reviewable change back: your engine starts the session; Kortix returns the change request.

Which tool gets the file matters more than which tool is better. When the file is the deliverable and a person signs it off, the platform that produces a reviewable change does the work that matters. The engine is the thing that starts it on time.