A scheduler change might leave this record at handover:
Objective: stop accepting new tasks and let the running data import finish.
Artifact: the core patch is saved; the command-line entry point is not connected yet.
Conflict: the current patch cancels running tasks, and the tests verify that old behavior.
Next step: correct the pause semantics, then continue integration.
Executor: none assigned.
No agent is running, yet the work has a definite state. Before reading the previous conversation, the next executor can identify the most consequential defect: the core code conflicts with the current objective. Connecting it directly would expose the wrong behavior to users.
This record is a teaching example of the Work design proposed in Flowness’s public commit c9d6abe. That version still classifies the complete cross-agent continuation path as a design. The example is not presented as a completed run. Design and evidence status
Behind the address, a route back to evidence
Work provides a stable place to query an ongoing task. An identifier helps us find it; it does not guarantee that what opens is current fact.
Flowness designs Work as a projection of underlying records. Code stays in the repository, test results identify the version they checked, and judgments and changes remain in event records. The work view assembles those facts. When the core patch changes, the view should identify which version the test examined instead of displaying only a green “passed.”
The view also has a position in time. For example, as_of_seq identifies the event through which it has been assembled. If the view stops at event 147 and the owner changes the pause requirement at event 148, the system has a basis for recognizing that the view has not yet incorporated the new decision. WorkView design
Such an entry point can support subsequent action more reliably than a handover summary alone. A summary explains what people thought then. A current view must also know which explanations have since changed.
After an executor is interrupted, the first job is to inspect what remains: has the original execution actually stopped, is the patch committed, which files are still in a temporary workspace, and which results have been checked? Recovery should follow actual state, not the last agent’s estimate that it was “nearly done.”
Next, prepare context for the next action. Flowness calls this material a Context Capsule: current objectives, relevant versions, effective constraints, artifacts, and unresolved issues selected from a definite cutoff in the record. In the scheduler example, the next executor must first resolve the pause-semantics conflict. Supplying the entire chat history could bury the few materials that determine the next move. Runtime reconciliation and context compilation
The new agent starts its own execution on the same Work. Once checked, its results become evidence for the next query.
Changed premises change the meaning of completion
The pause request may initially have been understood as “stop all tasks.” The owner later confirms that the running import must finish. That change affects more than the task description.
The old tests passed, but they verified cancellation. Core code, assertions, and command-line help may all depend on that same old premise. A logging format unrelated to pause may need no revision.
To make that judgment, the system needs two kinds of dependency: how tasks connect in execution order, and which version of an interpretation an artifact depends on. The first says integration follows testing. The second can reveal that the requirement tested has become obsolete.
Flowness calls an observation that changes subsequent work a Finding. Reflow then locates affected premises and dependencies and organizes the work that follows. Here the observation can be written plainly: “The core implementation cancels the running import, contrary to the current requirement.” The plan then returns to core behavior, checks that in-flight tasks really finish, and finally connects the command entry point. The relationship between Finding and Reflow
Existing artifacts remain. What changes is which conclusions they can support. Old test results can explain history; they cannot keep supporting a claim that the new requirement is met.
Whether selective rework saves effort depends on accurate dependencies. Missing relationships need investigation. When impact is unclear, broader verification may cost less than fine-grained classification. The design therefore needs testing on real change tasks: how many wrong turns does it save a successor, and how much recording work does it add?
Durable execution already has mature tools. Temporal can reconstruct workflow state from event history and accept new inputs through Signals and Updates. LangGraph uses checkpoints and persistent stores for graph state and cross-thread data. Temporal workflows, message passing, LangGraph persistence
The Work model concerns how stored state should be interpreted: objective versions, superseded judgments, affected artifacts, and the material a successor needs now. These rules can sit on existing execution engines. If tickets, repositories, and workflows already preserve the relationships completely, another parallel database would add synchronization work.
The address is still useful after “done”
Repairing the core logic does not make the remaining work disappear. Flowness distinguishes four states, each with a different continuation:
| State | Meaning in the scheduler example |
|---|---|
| Built | An inspectable artifact implements the pause capability. |
| Integrated | The command entry point and actual call path are connected. |
| Activated | Natural use in the target environment has actually invoked the capability. |
| Accepted | The person responsible for acceptance confirms that the result meets the need. |
Activation excludes tests, demonstrations, rehearsals, and deployment alone. Acceptance also needs a definite object: which version of the result was accepted? Definitions of activation and acceptance
This makes waiting specific. The capability may be integrated without a real pause request having occurred. Or it may have seen real use while awaiting the owner’s acceptance. An agent need not run continuously. The system needs to retain the event being awaited, the responsible person, and the conditions for checking again.
When those conditions arrive, reopen the same Work, check the current version, and start the next action. The public handover-demo specification is designed to test this path too: after an executor is interrupted, can a new one continue from persistent state without relying on the previous agent’s temporary memory? Handover-demo specification
For a maintainer, the address should ultimately answer a practical question: where should I begin if I return to this scheduler today? Continuing to answer it gives work a chance to survive the end of a conversation, a change of executor, and a change of requirements.