What Has to Survive for Work to Continue

Work stops. A session ends, a person hands over, a runtime restarts, a task moves from an automated step to someone reviewing it. Then it starts again, and whatever picks it up has to work out where things stand.

The archive this page replaces treated that as a memory problem. It is better understood as three separate questions that keep getting answered with one artifact.

Three questions, not one

A record of how the work got here answers what happened. That is useful for investigating a past run, and it belongs to the evidence side.

A representation of what is currently true answers where things stand.

A handoff answers who owns the next step.

The same file, log or database may serve all three. They are still different jobs, and an artifact that does one well is not automatically doing the others. The clearest way to hold the distinction is by direction in time. Replay reconstructs a past execution from what was recorded. Continuity preserves enough current truth for work to continue from here.

State is not the transcript

This distinction carries most of the page.

A transcript is a record of what was said or done over time. It can carry current-state markers, supersession notices or a summary of where things stand. Where it does not, it leaves statements from several different moments visible without identifying which one still governs. Reading it end to end recovers the sequence, which is not the same as being told the position.

Consider a record where none of that was done. Work has run across a long conversation, and somewhere in it a choice was made, reversed, and made differently. All three moments are in the record, in the order they occurred, with nothing distinguishing the live decision from its two predecessors. The next actor can reconstruct the sequence and still be unsure which constraint is currently in force. That is an information problem rather than a capacity problem, and it does not go away by making the transcript easier to read.

Length is not the defect. Ambiguity about what is current is the defect. A short transcript can be just as ambiguous.

What current truth might include

Continuity needs something that says where the work stands. Depending on the workflow, that might carry the task and its status, the decisions that have been accepted, the constraints still in force, the artifact or version in play, anything unresolved that blocks progress, and who owns the next action.

That is a list of the kinds of things such a representation may need, not a schema. It can live as prose, as structured data, as rows in a database, as the state of an issue or a pull request, as a position in a workflow state machine, or anywhere else durable enough to be read by whatever comes next. The mechanism is what matters. The format follows the access pattern and the kind of state, and it should be free to change without the idea changing.

Instructions are not state

Instructions say what should generally govern behaviour. State says what is currently true in this particular piece of work.

Approval is required before publishing is an instruction. This change is waiting on approval is state. The first is stable across every piece of work in the repository. The second is true this afternoon and false tomorrow.

Conflating them produces a predictable failure: standing rules get buried inside a status note where nothing will find them again, or a piece of live status gets written into the rules, where it silently stops being true. What a system prompt or a skill is belongs to the instruction layer and is not restated here. The point for continuity is narrower. Instructions have to remain available across sessions while they still govern, and that is a different requirement from keeping state current.

The repository's own agent entry point is seventeen lines long, and most of what governs authoring sits behind a pointer to a separate skill file rather than in the entry point itself. That arrangement is worth noticing rather than admiring: it means the entry point stays small and the governing material can change without the entry point being edited, and it also means anyone reading only the entry point has read a pointer, not the contract.

A handoff transfers responsibility

Sharing context is not a handoff. Copying a folder to someone is not a handoff. A handoff changes who or what is responsible for the next transition.

That is why the test of a handoff is not how much it contains. It is whether the receiver can proceed without having to work out what is still authoritative. The kinds of information that serve that test: what is done, what is currently true, what happens next, which constraints remain active, and what to do if the next step cannot proceed.

Those are not mandatory fields. A workflow where the next step is obvious and the constraints are unchanged may need almost none of them written down. The question is what this receiver needs in order to act, not what a template says a handoff contains.

Boundaries that need one are more varied than the agent-to-agent case that dominates the literature. Work crosses from an agent to a person for review, from a person to an automated step, from one session to the next, from a runtime that restarted to the task it was part-way through, and from one developer to another. The mechanism is continuation across a boundary. Whether the parties are software is incidental to it.

Two ways to carry state across the boundary

Two arrangements recur, and they are architectural choices rather than stages of maturity.

In a payload handoff, the sender assembles a bounded package holding what the next step needs, and the receiver works from that package. The boundary is explicit and the receiver's input is small and inspectable.

In a shared store, the relevant state lives in a common persisted location and each actor reads and updates the parts it needs. The full relevant state does not have to be copied into a handoff package, because the next actor can read what it needs directly from the store. A handoff across such a design may still carry something bounded, such as an identifier, a version, or a pointer to the task at hand.

Neither is better in general, and neither is protected from going stale. A payload captures a bounded package at one particular handoff, which makes it easy to inspect and fixes its contents at the moment it was assembled. A shared store lets actors read and update common persisted state, and its usefulness depends on update discipline, on what the fields are agreed to mean, and on whether what sits there is current. State that persists is not thereby state that is current. You can verify that a value was preserved without establishing that it still describes the state the workflow should continue from. Many systems use both, with a payload carrying the immediate task and a store holding the durable parts. What they have in common is more important than the difference: in each case the application is supplying state deliberately. Nothing is remembered by the model between calls, and describing agents as remembering or as knowing what happened obscures the software that actually carried it.

Continuation is not the whole history

The next actor needs enough to continue. A record of the path and a statement of the position are different things, and the parts of a path that describe how a position was reached do not themselves say what it is.

The reverse claim is equally wrong, and it is worth saying plainly: shorter is not automatically better. A compact note that omits an active constraint is worse than a long record that contains it. The useful property is not brevity. It is that what is current can be found without inference.

Historical detail still matters, for audit, for debugging, for explaining a decision later and for settling disputes about what was agreed. That is the evidence job. One store can serve both, and the two questions stay distinct even then.

A specimen from this repository

This repository keeps a long-running handoff document that records what changed, the decisions taken, the open risks and the suggested next actions across many separate periods of work. It is 1,167 lines. It carries thirty-nine appended update sections, dated between March and late June 2026, which appear in the file in an order that is not their date order, so reading top to bottom does not read forward in time.

It opens with a heading that presents current state, and that section is the most instructive part. The section of that document headed Key files touched lists thirty-five paths, and thirty-four of them do not exist at the commit this page cites. They were real when written. The repository has since moved to a different framework, and the section recording what had recently been touched was never revisited, because nothing about appending the next update requires revisiting it.

There is a further gap that is easier to miss. The work actually in progress in this repository at the cited commit, a long content migration, appears nowhere in the document. The most recent thing it describes finished months earlier.

None of that makes the file a mistake. It is a serviceable record of how the work got here, and useful as one. The narrow point is about the label. It is named current.md, its first heading offers current state, and neither of those makes its contents current. Applying that test to your own artifacts is simple and uncomfortable: open the thing that claims to hold the current position, take the first concrete assertion in it, and check whether it is still true.

Staleness is the standing failure mode

What a handoff says is true was true when it was written. The repository moved on, the ticket changed, the data underneath shifted, someone made a decision elsewhere.

There is no cadence that fixes this, and inventing one would be a guess. What helps is making the handoff's own position checkable: pin the commit or version it describes, date it, name the owner, and re-validate the parts that matter before continuing rather than assuming them. Those are examples of the mechanism, not a required set. The mechanism is that a claim about current state should carry enough with it for a reader to test whether it is still current.

When the next step cannot proceed

Continuity design is incomplete if it only describes the path where everything is available. A receiver may find the state ambiguous, the constraint unsatisfiable, or the artifact gone.

The available responses are ordinary: stop and say why, return the work to the previous owner, ask for the specific missing thing, escalate, take a defined fallback, or retry from a known earlier state. Not every workflow needs all of these, and the choice depends on what it costs to be wrong.

Two things this does not settle. Resuming work does not make the next action permitted; whether an action may proceed is a separate check that runs regardless of how coherent the state is. And handing work to a person does not by itself produce meaningful human judgment, which depends on what that person can see and whether they can say no.

Replay and resume

Two words that get used as though they were one operation.

Replay reconstructs or inspects a past execution from what was recorded of it, and it is bounded by what the record happens to contain.

Resume continues work from a preserved state.

Resuming does not require replaying the path. The point of preserved state is that the path does not have to be re-walked. Replaying does not authorize or perform the next step; it tells you about a run that already finished. A checkpoint sits between them, and it is worth being exact there too. A commit, a saved workflow state, an approved artifact, a status on an issue: each preserves what it actually contains and nothing else. A checkpoint is not a guarantee of recoverability.

What repeatability means here

Repeatability, in this sense, is not the same prompt returning the same output. Preserving instructions and state does not make a probabilistic system deterministic, and any claim that it does will be contradicted by the next run.

Repeatability means preserving enough process, state, constraints and checks for work to continue coherently even when model outputs vary. The operating conditions are what repeats. The generations underneath them do not have to.

Persisted state also proves nothing about whether the system is ready to face real users. That judgment involves evidence and controls this page does not supply, and it is its own question.

What this changes

Pick a piece of work in progress that will cross a boundary. Find the artifact that is supposed to tell the next actor where things stand, and read only that. Then ask whether someone could act from it without opening anything else, and whether its first concrete claim is still true.

If the answer is no, a longer record is not the fix. What helps is separating the account of how the work got here from the statement of where it currently is, and naming who owns what happens next.