Saved, Accepted, Safe to Use: How Work Survives a Restart

This page is the deeper companion to the article Work That Outlives Its Worker and to the interactive explainer, where you can switch the protections in the worked example on and off and watch the consequences. Here the same example is taken apart precisely: the definitions, the theory each mechanism comes from and what that theory assumes, a full trace with its arithmetic, the trade-offs, the failures the example does and does not cover, and the systems that already implement these ideas.

1. The problem, stated narrowly

Long-running agent work regularly outlives the session doing it. Anthropic's November 2025 account of long-running agent harnesses describes the symptom plainly: each new session starts with no memory of the last, and an agent that ran out of context mid-feature left the next session to guess what had happened. Its remedy was a progress file, a feature list and Git commits for the next session to read.²⁵ That is continuity of context. This page is about something narrower and older: continuity of work.

Strip the model away and the question is one that transaction processing, workflow engines and distributed systems have been answering for decades:

When the process doing a unit of work stops — or merely stops answering — and the input it was working from may change while it is gone, what must already have been written down, and checked by whom, for someone else to continue the work correctly?

“Correctly” has four separate meanings, and each fails in its own way:

• Progress is not lost, and a half-done step is not mistaken for a done one. Otherwise work is redone at cost, or an unfinished step is treated as finished.
• An effect on the outside world happens once. Otherwise a customer gets two emails, a card is charged twice, a feed shows two announcements.
• Only the current owner writes. Otherwise a worker presumed dead wakes up and overwrites its successor.
• An output is only relied on for the input it was judged against. Otherwise something accepted against an old input is used as if it were current.

None of these is new. What agent work changes is the economics and the shape of the steps: a model call is slow, costs money and does not reliably return the same text twice, so recovery should restore recorded results rather than recompute them, and a result that does get recomputed is a new result that has to be judged again.

2. Definitions

These are the terms as used on this page and in the worked example. Several of them are ordinary engineering vocabulary given one fixed meaning here; where a term is a policy of this example rather than a general law, that is said.

Work identity

A durable name for the job, independent of who is doing it: here digest/q3-report. It survives any number of attempts.

Attempt

One admitted try at the work, numbered #1, #2, … An attempt is not a session or a process; one attempt could span several of either, and a session could be replaced without the work restarting.

Owner token (epoch)

A number issued with each attempt, strictly larger than any issued before. The attempt carries it on every write; protected stores refuse writes carrying an older one.

Pinned input

The exact input version an attempt is working from, named by content hash and read from an immutable snapshot of that version.

Persisted

A step's result is durably recorded, keyed by what it was computed from. This is progress: it lets a successor restore the step instead of redoing it. It says nothing about whether the result is any good.

Finished (candidate)

The worker has assembled an output it considers complete. Nobody has judged it.

Accepted

A candidate passed an assessment and a transition recorded that fact for a named input version and assessment contract. In this example the assessment is done outside the producing worker; that is a design choice, not part of what durability means. Acceptances are appended, never edited; a later one supersedes an earlier one.

Dependable (for a given consumer)

Another task may rely on it now: it is accepted and it was accepted for the input version that consumer requires. A result can remain accepted, as history, while ceasing to be dependable for a consumer that requires the latest input.

Operation key

An identifier for an intended external effect, derived from what is being done (this announcement, for this accepted digest) rather than who is doing it. The receiver uses it to recognise a repeat.

UNKNOWN

The status of an attempt that has stopped answering. It is neither success nor failure: a silent attempt may have crashed, may be paused, or may have finished its step without recording it.

Written as a predicate, with d a digest, c a consumer and t the moment of admission:

In the worked example the newsletter's policy is required(newsletter, t) = the latest report version at t. A historical consumer could just as legitimately require an older version; the definition is relative to the consumer's declared requirement, not to “latest” in general.

3. Five records, five checkers

Durability is not one save. It is a handful of separate records, each with its own job and, crucially, its own checker — the party that must look at the record for it to protect anything.

The rest of this page takes the mechanisms one at a time, then runs them together.

4. Intent before work: what WAL does and does not give

Write-ahead logging is the oldest idea here. ARIES, the reference recovery method for write-ahead-logged databases, states the rule exactly: log records describing changes to some data must already be on stable storage before the changed data is allowed to replace its previous version on non-volatile storage.¹ On restart ARIES analyses the log from the last checkpoint, then repeats history by redoing logged updates, and only then undoes the work of transactions that did not commit. The redo is conditional on a test that tells it whether an update's effect is already present on the page:

Two ideas carry over to durable work; the algorithm itself does not.

1. Record before acting, so the record bounds what may have happened. In the example the controller writes attempt #1's admission — identity, pinned input, owner token 41 — before dispatching any work. This is WAL-inspired ordering, not ARIES's rule: ARIES orders a log write before a page write; here an attempt record is ordered before dispatch. After a failure the record does not say whether the work ran. It says what has to be reconciled.
2. Make redo conditional on a test. ARIES's test compares sequence numbers. The example's test is “is there a journal record for this step whose input key matches mine?” (section 6). For an external effect, the test has to live where the effect lives: at the receiver (section 8).

What does not carry over: ARIES redoes deterministic page updates. A model call is not a deterministic update, so a journal for agent work stores the step's result and restores it, rather than storing an operation and executing it again.

The rollback-recovery literature adds the companion rule for effects that leave the system. Elnozahy and colleagues call it the output commit problem: the outside world cannot be relied on to roll back — a printer cannot unprint, an ATM cannot recover dispensed cash — so before output is sent, the state from which it is sent must be recoverable despite any future failure. They also note that inputs from the outside world may not be reproducible during recovery, and that a common approach is to save each input to stable storage before processing it.⁵ The example applies both: the report version is recorded and pinned before work, and the announcement is sent only from a durably recorded state. It additionally requires that state to be an accepted digest; that is this example's policy, not part of the output-commit rule.

5. Restore, redo and the determinism boundary

It is tempting to say that durable execution needs deterministic work and agent work is not deterministic, so durable execution does not apply. That is wrong in a precise way. Replay-based engines require determinism of the orchestration code — the part that decides what to do next — and record the results of everything else.

• Temporal's documentation states that workflow code must be deterministic to support replay, and that non-deterministic operations such as API calls, LLM/AI invocations and database queries belong in Activities, which execute outside the replay path.⁹
• Azure Durable Functions replays an orchestrator from the start against its execution history; when the history shows an activity already ran, the framework replays that activity's recorded result rather than running it again. Orchestrators must therefore be deterministic, and must take time and GUIDs from the orchestration context.¹⁴¹⁵
• LangGraph's Functional API restores completed task results from the checkpointer instead of recomputing them, “including for long-running or non-deterministic task outputs”, and notes that different runs of a workflow can produce different results while resuming a specific thread replays the same persisted results.¹⁶
• Restate's ctx.run wraps a non-deterministic operation and stores its result in the execution log.¹⁸

Schneider's state-machine tutorial states the property underneath: a state machine's outputs are completely determined by the sequence of requests it processes, independent of time and other activity.⁶ Replay works for the part that has that property, provided every non-deterministic input to it has been logged — the piecewise-deterministic assumption of the rollback-recovery survey.⁵

For agent work, then: a model call belongs on the recorded-result side of the boundary. Restoring it reuses exactly what was recorded. Redoing it is a new execution which may produce different output — not must — and whatever it produces has to be assessed in its own right. The worked example makes this visible by stipulation: it gives every computed step a schematic result identifier derived from the attempt that computed it, so a restored step keeps its old identifier and a redone step gets a new one. The model does not generate summary text and does not claim real reruns differ.

6. Keying progress by its inputs

A journal that records “step 2 is done” is not enough once inputs can change. The record has to say what step 2 was computed from. Content addressing is the standard way to do that. Git is, in its own documentation's words, a content-addressable filesystem whose core is a key-value store keyed by a hash of the content.²² Bazel's remote cache keys each action by a hash of its declared inputs, command line and environment, and stores outputs in a content-addressable store.²³ The example applies the same idea to each step:

In the example each section summary declares one input — its own section text — and the assessment contract is held constant, so the key reduces to the section's content hash. When the report changes in section 2 only, a successor restores sections 1, 3 and 4 and redoes section 2.

Reuse by key is sound under two conditions, and Bazel's own documentation lists a known issue for each:

1. The key covers everything the output depends on. Bazel does not track tools outside the workspace, so two users with different compilers can wrongly share cache hits: the outputs differ but the action hash is the same.²³ In the example, if a section summary quietly read another section, section-level reuse would be unsound.
2. The bytes the step read are the bytes the key names. Bazel warns that when an input file is modified during a build, it might upload invalid results to the remote cache.²³ Hashing a mutable file at admission and later reading it does not guarantee that. The example assumes each attempt reads an immutable snapshot of its pinned version; a real system needs that snapshot, or equivalent isolation. Rechecking a version label the worker reports about itself is not enough.

The example exercises version selection and stale reuse across two versions. It does not model a file changing during a read.

7. Leases, suspicion and fencing

A controller cannot see inside a worker. It sees heartbeats, or their absence. Gray and Cheriton defined a lease as a contract giving its holder specified rights over property for a limited time. Because the term is bounded, a grantor that loses contact with a holder only has to wait for the lease to run out, not for the holder to be found.³ Their paper is explicit that leases depend on well-behaved clocks: a server clock that runs fast can allow a write before a previous holder's lease has expired at that holder, and a client clock that runs slow can keep using a lease the server considers expired. The minimum requirement is a known bound on clock drift.

Even with good clocks, expiry is only suspicion. Kleppmann's essay on distributed locking gives the failure that matters: a lease holder pauses (a garbage-collection pause, a page fault, a stopped process), its lease expires, another client takes over, and the first resumes and writes, believing it still holds the lock. Checking the lease just before writing does not fix this, because the pause can fall between the check and the write. The fix is a fencing token, a number that increases every time the lock is granted, sent with every write; the storage remembers the highest token it has processed and rejects a write with a lower one. In his words, this requires the storage to take an active role in checking tokens.¹⁹

The example uses a stronger arrangement that is worth stating exactly, because the difference matters:

In the model every protected store — the journal, the candidate store, the effect records and the acceptance transition — compares against one authoritative owner epoch, and the controller publishes the new epoch before the successor is admitted. A store that only remembers tokens it has seen on writes may still accept token 41 after 42 has been issued but before any write carrying 42 has reached it. A real system with separate stores needs the corresponding synchronisation: conditional writes against a shared epoch, or the successor's first write reaching each store before the old owner can, and monotonic epochs that survive the controller's own restarts.

Three limits follow, and they are the ones worth remembering:

• Fencing does not prove the old worker stopped. In the example the woken attempt #1 is still alive after its write is rejected. Fencing removes its write authority; it says nothing about its health.
• Only stores that check tokens are protected. The external feed in the example checks idempotency keys, not owner tokens.
• A false suspicion wastes work. If the worker was merely slow, its in-flight step is lost and redone. Fencing keeps that from corrupting anything; it cannot make it free.

8. Effects: at least once, applied once

Here is the hardest window in the example. The worker records that it intends to post the announcement, sends it, the feed applies it, and the worker dies before it records the acknowledgement. Its successor finds an intent with no confirmation. That local record is compatible with two different histories: the post never arrived, or it arrived and the acknowledgement was lost. Nothing on the worker's side can tell them apart.

Saltzer, Reed and Clark made this point in 1984: reliably detecting a crash is problematic, because the problem may be a lost or delayed acknowledgement, in which case the retried request is a duplicate that only the application can discover. Duplicate suppression must be done by the application with knowledge of its own requests.⁴ Distributed commit has a related result — Bernstein, Hadzilacos and Goodman show that a participant that fails during its uncertainty period cannot reach a decision alone and that no atomic commitment protocol guarantees independent recovery² — but that theorem is about voting protocols, which the example does not have. It is an analogy for why someone outside the worker must be asked, not the reason in this case. The reason here is simpler: only the receiver saw whether the effect happened.

So the practical pattern is: send at least once, and make the effect idempotent at the receiver. Temporal's documentation defines it: performing an operation multiple times has the same result as performing it once. For an operation k acting on receiver state S:

A receiver achieves that for an effect that is not naturally idempotent by remembering, for each key, the request it was given and the answer it gave. In the example the receiver is the feed, and the post lives in the feed's own store. From the worker's side the feed is external and nothing the worker does can roll a post back; from the feed's side, the post and the feed's record of it can be written in one transaction:

receive(key, req):
  transaction, serialized per key:
    # nothing else on this key interleaves
    saved = remembered.get(key)
    if saved is not None:
      if saved.params != req.params:
        return reject("different request")
      return saved.result     # same answer
    outcome = apply(req)      # the post
    remembered[key] = (req.params, outcome)
  return outcome

Everything inside transaction runs as one unit that no other request for the same key can interleave with. A per-key lock, a serializable transaction, or a unique constraint on the key that aborts the losing commit before its post persists would each do. The lookup has to be inside that unit. If it sits outside, two copies of the same request arriving together can both find nothing remembered and both post, and the second answer overwrites the first. Each part of the recipe answers a requirement in the sources:

• The receiver enforces it. Temporal states that idempotency keys are enforced by the service the activity calls, not by the activity itself, and recommends a key built from the Workflow Run ID and Activity ID because that is consistent across retry attempts but unique among executions.⁸
• The lookup, the effect and the record are atomic and isolated. The AWS Builders' Library article on idempotent APIs requires “the process that combines recording the idempotent token and all mutating operations related to servicing the request” to meet the properties of an atomic, consistent, isolated and durable (ACID) operation, and its example flow begins with the service checking whether it has seen the identifier before.²⁰ Atomicity stops the token being recorded without the resource, or the resource created without the token. Isolation is what stops two concurrent copies from both missing the lookup. AWS does not spell out that concurrent case. Stripe does: a request that conflicts with another request executing concurrently is not saved, and can be retried.²¹
• The key names the operation, not the attempt, and is checked against the stored request. If each attempt generates its own key, a successor's resend looks new. AWS stores the parameters of the first request with its client request identifier and returns a validation error for a parameter mismatch, on the reasoning that the customer may have intended a different outcome. Stripe compares incoming parameters with the original request's and errors if they differ, “to prevent accidental misuse”.²⁰²¹ The recipe stores req.params beside the result and rejects a mismatch.
• A repeat gets the stored answer. AWS returns a semantically equivalent response to a request it has already seen. Stripe saves the status code and body of the first request for a key “regardless of whether it succeeds or fails” and returns them for later requests with that key, including errors.²⁰²¹ In this recipe a failed post rolls the whole transaction back and nothing is remembered, so a retry tries again. Remembering the failure, as Stripe does, is the other defensible choice.
• Keys expire. Stripe allows keys to be removed once they are at least 24 hours old, after which a reused key creates a new request.²¹ A retry that arrives after the receiver forgot the key is a new effect.

With the lookup, the parameter check, the post and its record serialized in one transaction, and the key kept for as long as a retry can arrive, the guarantee is one application as far as the receiver can tell, not exactly-once execution. Temporal is careful about the same distinction: with retries, an activity is observed as completed exactly once, yet may be executed multiple times and may even partially complete more than once.⁸ Where a receiver offers neither keys nor a way to ask whether the effect happened, the remaining tool is compensation — a saga in Garcia-Molina and Salem's sense, a sequence of transactions each with a compensating transaction to amend a partial execution. Compensation amends rather than prevents: a sent email can be followed by a correction, not unsent. Their paper also notes the case where compensation itself cannot complete and the system is stuck.⁷

9. Three lifecycles, not one

Mature engines name every lifecycle state rather than inferring it; Airflow's task instances, for example, move through explicit states such as queued, running, success, failed, up_for_retry and deferred, and tasks whose heartbeats time out are detected and failed or retried.²⁴ The example keeps three small machines and keeps them separate, because they answer different questions:

ATTEMPT — is this worker allowed to act?
  admitted ─dispatch─▶ running
  running ─missed heartbeats─▶ UNKNOWN
      (never success, never failure)
  running | UNKNOWN ─write rejected─▶ fenced
      (stale token; may still be alive)
  running ─candidate refused─▶ refused
  running ─post confirmed─▶ done

ARTIFACT — what is the status of this output?
  candidate ─assessed, recorded─▶ accepted
      (for a named version and contract)
  candidate ─assessed, refused─▶ refused
  accepted ─input superseded─▶ accepted
      (history; not dependable for “latest”)

EFFECT — did the outside world change?
  intent recorded ─sent─▶ unconfirmed
  unconfirmed ─receiver answers─▶ confirmed

Keeping them apart is what lets the example say true things at the same moment that a single status field would contradict. At t13 in the main trace, attempt #2 is UNKNOWN; its digest's acceptance at t10 still stands; the announcement is unconfirmed; and the newsletter has already started on the accepted digest. Silence also gets its own state. A system that maps “process gone” to failed throws away work that may have finished; one that maps it to success invents completion.

10. Accepted versus dependable

Acceptance is a judgement recorded for an input version and a contract. Two policy choices in the example deserve to be read as policies:

• Acceptances are append-only. The example never edits or withdraws one; a later acceptance supersedes an earlier one. This keeps history honest. It is not a law of durable systems: a flawed result can be replaced by a new assessment of the same input, recorded as a new disposition, without pretending the first judgement was never made. (Atomic commitment protocols do make individual commit decisions irrevocable,² but that is about protocol decisions, not about whether a semantic assessment can later be revised.)
• At most one accepted digest per report version, under one fixed contract. The example holds the assessment contract constant and never changes it.

The dependant's admission rule is where accepted and dependable separate. The example offers the newsletter three rules: take the latest finished candidate, take the latest accepted digest, or take an accepted digest for the current report (equation 1). Only the third prevents the superseded-input failure.

One case needs care. If the records carry no version at all, the third rule cannot be checked. The reader-facing model deliberately makes that rule fail open in that case — it behaves as “take the latest accepted” — to show what an unchecked freshness requirement does. A rule that fails closed would wait instead. Across the 144 input combinations where versions are off and the strict rule is selected, failing open lets the newsletter use a wrong digest in 72; failing closed prevents every one of those, but the newsletter is then never admitted in any of the 144 (it can never prove freshness), and the wrong digest is still accepted upstream in 78 of them either way. Refusing to proceed protects the consumer; it does not repair the producer.

A conservative alternative avoids mixing versions altogether: pin a run to its original input and start a new execution for a new input. AWS Step Functions' redrive continues a failed Standard execution from the unsuccessful step using the same input and the same state-machine definition version, preserving the results of successful steps, and requires a new execution for an updated definition.¹² Two qualifications from the same documentation: preserved successful work has documented exceptions — after a States.DataLimitExceeded failure, a Parallel state, an Inline Map state or a Distributed Map state is rerun including its successful branches, iterations or child workflows — and redrive is only available for 14 days after the execution ends. Redrive does not itself provide the example's cross-version reuse of unchanged sections; whether a new execution reuses earlier results is an application-level choice, not a consequence of pinning.

11. The worked example

Setup

Task digest/q3-report summarises a four-section report into a digest, one model call per section, then assembles a candidate digest, has it assessed and accepted by the controller's transition, and posts one announcement to an external feed. A newsletter, ready at t12, depends on the digest and quotes its revenue figure.

Fixed timings, in ticks: the first owner token is 41; an attempt is presumed lost after 2 missed heartbeats; attempt #1 goes silent as it starts s3 at t3; if it was only paused it wakes at t8; the report is corrected at t4 (“during the outage”) or at t12 (“after acceptance”). The protections are on: per-step checkpoints, fencing, version pins, an operation key on the post and the strict newsletter rule. Result and digest identifiers such as 3af8da4e are schematic labels, as explained in section 5.

Main trace: interrupted, corrected, retried

Outcome: 6 model calls against a minimum of 4 (#1 made 3, #2 made 3, #3 made none); 1 step restored; 1 stale write rejected and none applied; 1 post delivered and no duplicates; the digest first accepted for the current report at t10; the newsletter started at t12 quoting 4.7 million; no invariant broken. Note that the newsletter starts at t12 although the announcement is not confirmed until t14: dependability rests on acceptance, not on the announcement.

The cost decomposes cleanly. With a checkpoint after every step,

With checkpoints only at the end, attempt #1's two finished steps were never written, so #2 redoes all four; and because the woken #1's first write is now postponed until it assembles, it spends one more call before it is fenced. The digest is accepted at t11 instead of t10. Persisting more often is a cost lever in this model, never a correctness one — which matches LangGraph's description of its exit, async and sync durability modes as a performance-versus-durability trade.¹⁷

Second trace: accepted, then superseded

Same protections, but the report is corrected only at t12, after a digest was accepted for v1.

Outcome: 6 model calls (#1 3, #2 2, #3 0, #4 1); two distinct announcements and no duplicates; the newsletter waits from t12 to t17; no invariant broken. Because only section 2 changed, the rebuild after the correction costs 1 model call. Rebuilding everything for v2 would have cost 4. That comparison is between two stipulated policies in this model, not a measured property of any engine. With the newsletter rule relaxed to “latest accepted” or “latest finished”, the newsletter instead starts at t12 on the v1 digest and quotes 4.1 million while the report says 4.7 million.

The failure path: version checks off

Repeat the main trace with version pins off: records keep no input hashes, so reuse is by step name alone and acceptance cannot compare versions.

Cheaper, faster and wrong. Two invariants break: a digest built from a superseded input was accepted, and the dependant consumed it. With a fail-closed rule the newsletter would wait instead; the wrong digest would still be accepted.

One change at a time

All 864 combinations

The interactive exposes eight inputs: what the silent worker really did (paused or crashed), fencing, checkpoint frequency, when the input changes (during the outage, never, after acceptance), version pins, the newsletter rule (current accepted, any accepted, latest finished), whether the posting worker dies, and the post key (per operation, per attempt, none). That is 2 × 2 × 2 × 3 × 2 × 3 × 2 × 3 = 864 combinations, and the model was run on every one.

• With all four protections on — fencing, pins, a per-operation key, the strict newsletter rule — all 24 runs (12 event combinations × 2 checkpoint modes) break no invariant and finish: an accepted digest for the final input, its announcement confirmed. They cost 5–6 model calls (mean 5.67) with per-step checkpoints and 7–9 (mean 7.83) with end-only checkpoints.
• Weakening exactly one protection, with per-step checkpoints, over the 12 event combinations:

“Necessary” here means necessary within this model and these exact switch definitions. It is exhaustive over the configured combinations, not over arbitrary interleavings, crash points, clock behaviour or storage failures. It also shows that fencing and version pins guard different things: with fencing off and pins on, stale writes pollute the record but no wrong digest is accepted; with pins off and fencing on, no stale write lands but a wrong digest is.

12. Trade-offs

13. Failure cases outside the model

The model demonstrates five failures: a duplicate effect without a stable key; a stale owner writing after it was replaced; acceptance of output built from a superseded input; a dependant using a superseded or never-accepted output; and two outputs accepted for one input. These it does not cover:

1. A worker paused inside the effect. If an owner had already passed acceptance and was paused mid-post, its late send reaches the feed, which checks keys but not tokens. A per-operation key deduplicates it; anything else duplicates. Fencing cannot protect a resource that does not check tokens.
2. A receiver with no idempotency. If the receiver offers no key and no way to ask whether an effect happened, at-least-once means possible duplicates. Compensation or a human check remain.
3. Key expiry and late arrivals. A retry arriving after the receiver has pruned the key is a new request.
4. Clocks outside their assumed bound. Lease timing is wrong; fencing prevents corruption but not wasted work.
5. Undeclared or mutable inputs. Reuse by hash is unsound if a step read something outside its key, or bytes other than the ones hashed.
6. A fallible assessor. An acceptance records what was judged, not that the judgement is right. In the example the assessor checks completeness and form, not every figure.
7. Journal and effect are never one transaction. The window between recording intent and the receiver applying the effect always exists; the design has to assume it.
8. Orchestration code that changes under running work. In replay engines, changing workflow code under running executions causes non-determinism errors⁹ — a code-version cousin of the changed-input problem.
9. The controller itself restarting. The example assumes the controller survives and its records are on reliable storage. A restarted controller would need, at least, durable attempt records, the owner epoch, unconfirmed effect intents and acceptances; it would have to rebuild its suspicion timers rather than trust them, and keep the epoch monotonic across its own restart. That is a requirement, not a trace this model runs.
10. Losing the journal. All of this assumes stable storage. Durable work is only as durable as its records.

14. Prior art and current engines

Nothing in the example is new. It is assembled from mechanisms the following systems document, and it is not offered as an alternative to them or as better or worse than any of them. The table states what each page said when it was read in October 2026; vendor documentation changes, and each statement is about that system's own semantics.

Two other families are worth naming. Whole-process checkpoint and restore is simpler, but the rollback-recovery survey judges checkpoint-based recovery ill suited to applications that interact frequently with the outside world.⁵ And agent harnesses that hand over through progress files and Git commits, with a separate evaluator judging when work is done, address continuity of context and quality of judgement.²⁵²⁶ Anthropic's March 2026 follow-up reports that a separate evaluator was a strong lever but needed tuning against leniency, and that its full harness cost over twenty times as much as a solo run in that comparison. These complement the records described here; they do not replace them.

The honest summary of “why not just use an engine?” is: for many systems, do. The engines above implement most of these records. What none of them can do on your behalf is make a third party's effect idempotent, know which inputs your agent actually read, or decide what “accepted” means for your output.

15. A dated design example: Era 3

Loki's Era 3 is a proposed design for running agent work from durable factory records rather than from any one session. As of its draft architecture documents of September 2026, it is a design, not a running system: no Era 3 core, factory engine or session-capture runtime has been implemented. Its two state-walkthrough teaching applications are real, but they deliberately keep every input fixed and leave controller recovery and changed inputs out.

The draft requires most of the properties on this page and, for most of them, has not yet chosen a mechanism:

The worked example on this page is a small paper rendering of the kind of proof that design asks for — interrupt a worker, replace it, continue from records without losing accepted decisions, inventing completion or repeating recorded effects — built from textbook mechanisms. It is not evidence that Era 3 does any of this. Fencing tokens, section-hash keys and per-operation keys are choices a builder might make, not choices the design has made.

16. Where the model stops

The model's assumptions, all of which the interactive shares:

1. One model call per section summary. Result and digest identifiers are schematic: restored steps keep theirs; redone steps get new ones by stipulation. No summary text is generated or compared.
2. A section summary depends only on its own section and the fixed contract, and each attempt reads an immutable snapshot of the version it is pinned to.
3. The assessor checks completeness and form; version consistency is checked mechanically by comparing part hashes with the pin.
4. One assessment contract, held constant. The newsletter requires the latest report. At most one digest is accepted per report version. These are policies of this example.
5. Protected stores share one owner epoch and compare it atomically with each write; the new epoch is published before the successor is admitted.
6. The feed cannot be rolled back, deduplicates only by key, keeps keys for the whole run and does not check owner tokens.
7. A fenced worker stops when a write is rejected. It may still be alive.
8. Discrete ticks, one step per tick, no clock skew. Missed heartbeats are suspicion, never proof.
9. The controller never fails, and its records are on reliable storage.

Within those assumptions the model shows what each record protects and what removing it costs. It does not show that these mechanisms are sufficient for a real system, measure anything about any engine, or replace the engines that already implement them.