Durable work

Durable work

Preview

Focused tests for Durable Work Runtime are passing, but it is still being integrated and is not yet the default public runtime.

The idea is simple: important work should not disappear just because a chat tab closes, a process restarts, or an agent needs more than one execution attempt.

LM Nexus gives longer-running work its own durable state.

Core concepts

A durable work graph can include:

• Workspace — the durable scope that related work belongs to;
• Goal — the outcome the work is trying to reach;
• Plan — the committed structure for getting there;
• Task — one unit of work, including its current state and dependencies;
• WorkExecution — one attempt to execute a Task;
• events/checkpoints — history that helps the system recover after a restart;
• artifacts — outputs produced by the work;
• verification evidence — evidence used to decide whether an outcome should be accepted.

Why this is separate from Chat

Chat is where a person talks to the system.

A conversation can start work, inspect it, or discuss it, but the task itself should not depend on one browser session or one message history to keep existing.

Durable Work Runtime therefore keeps the task state. Chat and Agent Runtime can work with it without becoming its only source of truth.

Who does the work

Durable Work Runtime does not replace Agent Runtime.

Conceptually:

Goal / Plan / Task
  -> WorkExecution
     -> Agent Runtime or another executor
        -> tools / providers
        -> evidence / artifacts
     -> durable task-state update

The executor does the actual work. Work Runtime remembers what that work means, which attempt ran, and what state the task is now in.

Completion is not the same as acceptance

A child execution finishing successfully does not automatically mean its result should be accepted.

The current integration work is defining replay-safe verification identity and explicit outcomes such as:

• PASS;
• FAIL;
• INCONCLUSIVE.

That verification boundary is needed before some of the deeper tracked-delegation flows can be enabled safely.

Future consumers

Planned features such as reusable Rituals are intended to create normal durable Goals, Plans, and Tasks rather than introduce a second workflow engine.