Durable Process Algebra
Problem
Section titled “Problem”Agent apps need long-running work that survives eviction, retries, cancellation, redrive, and backend replacement without turning backend queues or workflow engine memory into truth.
A durable process is a ledger-derived algebra. The ledger records facts; a process projection folds those facts into current process state.
The stable vocabulary is:
processRef: app-owned identity for one durable process instance.intentEventId: the ledger event that requested the process or retry branch.dueWorkId: backend-local scheduled work identity. It is a mechanical cursor, not process identity.stepRef: stable identity for one idempotent process step.command: a fact asking a later boundary to do work.awaitable: a symbolic dependency that must become terminal before a process can resume.
Legal process facts have one writer each:
- intent facts request a process or a new redrive branch;
- command facts request an idempotent external boundary;
- acquired facts record that a step boundary claimed the right to try work;
- waiting facts record that a process is blocked on awaitables;
- resumed facts record that all required awaitables became terminal;
- terminal facts close a process or step as
completed,cancelled,failed, orrejected.
Cancellation is a fact, not a side channel. If cancellation races with acquire, the projection accepts exactly one terminal outcome for the affected step or process. Redrive appends a new intent or command fact and links it to the previous terminal or expired attempt. It does not mutate the old terminal fact.
Backend buffers are not truth:
due_workrows schedule or claim future work;- dispatch outbox rows retry delivery;
- projection tables cache folds;
- stream frames carry live transport output;
- external framework checkpoint tables are references only.
Deleting or compacting one of those buffers must not delete audit-visible process state. If an app needs to read process state after cleanup, that state must be rebuildable from ledger facts and projection definitions.
External effect boundaries are idempotent. A provider call, tool call, dispatch
delivery, or file write happens behind a step boundary that has a stable
stepRef and provider idempotency key. Retrying the same step may retry the
external effect, but it must not append a second terminal fact for the same
semantic step.
Future graph or workflow syntax is only authoring sugar if it compiles to this ledger vocabulary. agentOS replays ledger facts and projection folds; it does not replay arbitrary TypeScript or Effect process code as the source of truth.
Existing Backend Lifecycle View
Section titled “Existing Backend Lifecycle View”DurableProcessLifecycleState is a backend diagnostic over the current durable
trigger substrate. It classifies due_work rows as scheduled, claimed,
cancel_requested, cancelled, completed, or redriven.
That lifecycle view is useful for tests and operators, but it is not the
higher-order durable process truth described here. It cannot be extended with
waiting, resumed, failed, or rejected by adding more buffer columns.
Those states require ledger facts and a projection fold.
External Terms
Section titled “External Terms”- Temporal Workflow maps to a durable process instance.
- Temporal Activity and DBOS Step map to acquire or step boundaries.
- Inngest function steps map to command facts plus idempotent step boundaries.
- LangGraph thread maps to a process cursor.
- LangGraph checkpoint maps to a ledger cursor or projection snapshot, not a source-of-truth table.
- Microsoft Agent Framework executor maps to an app node.
- Microsoft Agent Framework edge maps to command routing.
These terms are design references, not runtime dependencies.
Non-Goals
Section titled “Non-Goals”This concept does not add a workflow-code replay engine, a graph DSL, durable stream logs, automatic reconnect/resume, or a new backend queue. Batch durable triggers and attached streams remain separate substrates until product pressure requires a shared lower-level primitive.