A handoff is more than a summary

A note saying “Implemented the filter and fixed the tests” leaves the next engineer with several questions before they can resume the work. They need to find the branch and understand what the tests covered, along with any deployment or decision that is still outstanding. The same information is needed when a new agent session takes over.

A useful handoff gives the next person or session enough information to continue without having to reconstruct what happened. Describe the current state and link to the evidence they can inspect. When something remains uncertain, explain what still needs to be established before it affects the next decision.

Separate four kinds of statement

Keep observations distinct from decisions and proposed work. A successful command is something you observed; a choice about the next release should identify who made it and why. Work that has not happened and questions that remain open need to be described clearly enough that the next session will not treat them as completed.

For a synthetic support case, “refund drafted” and “refund issued” describe different system states. For a code change, “build passed locally” and “production serves the merged commit” are different evidence. Make those distinctions visible wherever the next action depends on them.

Prefer evidence references over pasted logs. Name the command and outcome, the artifact location, and the version it belongs to. A transcript may remain available elsewhere, but the handoff should not require the next engineer to rediscover the task by reading it from the beginning.

Make resumption a small rehearsal

Before ending a session, read the handoff as if you had just joined the task. Check whether it gives you enough information to locate the work and understand what it is meant to accomplish. The unresolved decision and the next permitted step should be clear without having to invent an answer.

The workbench’s handoff field is a place to specify those requirements. Export the brief, then ask a colleague to attempt the resumption using synthetic or approved material. Watch where they have to guess. Those gaps tell you more than a longer summary would.

Decide which notes need to remain available after the task ends. A temporary observation may expire quickly, while the reason for a design decision may be useful to the next engineer. Record who owns information that needs review and when they should reconsider it.

Use a clean stopping point

Before handing work over, describe anything unfinished and explain whether it can safely be used in its current state. Include known failing checks and the reason a partial change must be kept out of a release. The next person should be able to continue without mistaking an incomplete implementation for an approved one.

Anthropic’s long-running-agent harness article describes initialization, incremental work, progress artifacts, and testing across sessions. It also treats the approach as an implementation account with open questions. It is not proof that a progress file makes an arbitrary system reliable.

My extension is to treat resumption itself as something to rehearse. A handoff that another person can use is stronger evidence of continuity than one that its author finds reassuring. Keep the rehearsal scoped: a reader should not need production access just to understand what remains to be done.

Leave the next owner a decision they can make

State the next decision precisely enough that someone can act on it. If a release is waiting for review, identify the evidence that needs checking and who can approve it. An instruction to “continue improving” leaves the next person to work out both the priority and when to stop.

The broader AI SDLC method explains how these decisions fit into delivery. If you are learning the work, include a handoff in a small project through LockedIn Labs Training and have someone else try to resume it. That attempt can become part of the portfolio you discuss through FDE Benchmark.