The resumption test
You may already keep application logs, versioned code and delivery notes. The gap in an agent workflow is often between them: the code exists, but the reason for a choice, the last check and the uncertainty about an external action live only in the conversation.
Choose a bounded local task, save its current state and stop at a known boundary. Start a fresh session using the repository and issue trail, without a private briefing. Can it identify the source revision, accepted changes, unfinished work and next verification step?
If it needs you to reconstruct those facts from memory, the handover is incomplete. This article shows what to record and how to test that another session can actually use it. Do not use a mid-payment or other externally consequential operation as your first resumption experiment.
Why resume cannot be the continuity plan
A saved conversation is useful working context. Treat it as one input to continuity, with a different job from a decision record or execution receipt.
Session retention and loaded context depend on configuration and runtime behavior. Long conversations may be compacted, and Claude Code's team documentation says resume does not restore in-process teammates. Check the actual stored state and installed version instead of assuming the visible conversation is the whole running system.
A versioned plan can survive a conversation boundary and be inspected by the receiving session. That only helps if it identifies the relevant revision and is updated when the plan changes. A stale committed plan is durable misinformation; persistence and correctness are separate properties.
A transcript mixes proposals, abandoned attempts, tool output and decisions. It may contain the answer to a later question without making clear which statement was accepted or still applies.
A record is curated at the moment of writing: a plan, a decision note, a gate output, a pull request description. Keep transcripts where they help diagnosis, and make the accepted state explicit enough to inspect without replaying the conversation.
Keep the durable state explicit
Write down the state that the next person or session must be able to verify.
Record intent, plan changes, decisions, status and evidence when they become relevant to the next action. Waiting until shutdown makes the handover depend on the session surviving long enough to remember everything.
For each record, name the source revision, what was observed, what remains unknown and the next check. Separate a proposed action from an attempted action and a confirmed outcome.
For example, a handover saying “migration done” is ambiguous. A useful record names the migration revision, the environment inspected, the command and result, and whether application behavior was checked afterward. It gives the receiver something to verify without turning a summary into proof.
This site is produced by an operation built on exactly that doctrine. Every decision lands as a numbered ruling in a git repository. Every stream of work files a statement of work with a ledger of claims, and each claim carries the commit it landed in and the check that proves it.
The three incidents below are real, drawn from this operation's own practice and offered here as illustrative first-party examples of the pattern, not as an externally auditable case study with a public repo link, since the underlying ruling history is internal:
A design that had never rendered. A CSS plugin was installed and never registered, so seventeen carefully-written style rules had never once applied. Every build passed the whole time; an inert class is not an error.
Two workers editing the same file. Both were correct, both were assigned, neither could see the other. The record showed the collision; one reverted.
A day spent re-deciding something already decided. Three participants reasoned about an acquisition mechanic that a ruling on disk had settled weeks earlier. Nobody had looked, because the question felt new.
That last one is the honest lesson: the record is only an advantage if it is read before it is added to.
Budget integration along with concurrent work
Three worktrees may each pass their checks while touching adjacent behavior. They still have to land on main in an order. The second and third branches may arrive on a base they were not tested against. Model calls, context preparation, review and integration all consume capacity.
Parallel streams are only as parallel as the decomposition was, and decomposition is an up-front management act rather than something the agents work out.
Assign the merge decision to an integrator with the dependency picture and authority to sequence the work. That role may use automation, but an isolated worker's local PASS is not sufficient evidence about another branch.
Research and disposable experiments can be useful early parallel tasks. Production changes can also be split when ownership, dependencies and integration tests are explicit. When the work is entangled, sequence it or define the shared contract before dispatch.
Make review possible for the receiving team
Multi-stream operation does not multiply the operator. It multiplies the inflow to the operator.
Two useful practices make the receiving work visible:
Review against a spec you wrote. Code that started from your own specification is far less effort to review, because you are checking conformance rather than reconstructing intent.
Make each stream carry its evidence. Record the command, source revision, environment and result. That lets a reviewer check whether a claimed success applies to the version being received.
A bare “done” leaves the receiver to recover scope and evidence. A diff, a recorded gate run and a conformance note reduce that reconstruction, but the receiver still needs to inspect the relevant changes and the check's blind spots. Measure that review effort; do not assume evidence packaging eliminates it.
History is for the receiver
Agent-generated changes can become difficult to review through oversized commits, many tiny commits without purpose, or messages that narrate edits without explaining them. History rewriting can also remove a reference someone else needs. Choose a repository policy that keeps the accepted work and its reasoning traceable.
The counter-doctrine, assembled:
Use a branch per independently delivered change when that matches the repository workflow. Make shared files and dependencies explicit so the integrator can choose and test a merge order.
An attribution trailer can record assistance under your repository policy. It does not prove who reviewed a commit or how thoroughly. Record review and approval through their actual mechanisms, and apply the agreed attribution policy consistently.
Frequently, and as a standing instruction. The harness has its own checkpointing and the documentation says plainly that it is not a git replacement.
The receiver may be you, a teammate or a future agent session. State the trigger, resulting behavior and relevant validation so they can assess the change without reconstructing this chat.
What this actually is
Assemble what an operated harness has forced into existence.
The workflow now has workers with bounded context, shared instructions whose loading must be checked, permission boundaries, acceptance gates, dispatch rules and a budget. Durable records connect decisions to the live operational state and the evidence used to accept a result.
This supplies part of an organization's coordinating structure: roles, boundaries, records and checks that persist when individual sessions change. It does not by itself establish business viability, legal status or the ability to operate without people.
Session replacement becomes a property you can test. A replacement reads the records, checks current state and continues within its authority. If an external effect has an unknown outcome, it reconciles that outcome before repeating the action.
A coordination workflow does not itself decide which outcomes are worth pursuing. The people responsible for the operation still need to define authority, accountability and release decisions.
This is a coordination proposal, not a measured throughput gain. To evaluate it, track the time to recover a task, the work repeated because records were missing, and the cost of keeping the records current. A useful record system should improve an observable handover, not just produce more documents.
A Zero-Employee Organization removes employees. It does not remove accountability.
Failure modes to include in the handover
What to do this week
Run the bounded resumption test. Save a local task at a known boundary, close the session and try to continue from records. Note each fact you had to recover manually, then add it at the point where future work produces that fact.
For one week, choose a fact the next session needs, such as an accepted decision or the definition of done. Record it when it changes and check whether the next handover can use it.
Repeat the test after a real change in the workflow. Check not only whether a record exists, but whether it leads the receiving session to the correct revision, evidence and unresolved action.
Rot register
Sources reviewed 2026-09-08. The linked documentation supports the stated runtime boundaries; it is not execution evidence for every configuration or a public audit of the internal examples.
| Claim | Re-check at |
|---|---|
| Transcript retention and format stability | code.claude.com/docs/en/sessions |
| Worktree branch naming and isolation | code.claude.com/docs/en/worktrees |
| Attribution trailer settings | code.claude.com/docs/en/settings |
| Agent team resume limitations | code.claude.com/docs/en/agent-teams |
Compare the published format and requirements with the application or handover you want to work on. Use the programme details to judge the fit before making a commitment.
