Every session with an LLM agent starts from zero. The model has no memory of previous work, no record of decisions made, no awareness of where the last session ended. Without intervention, each session is isolated — competent within itself, but disconnected from everything before it.
The handover document is the intervention.
The Problem It Solves
Session continuity is a structural problem, not a behavioral one. It cannot be solved by prompting the model to "remember" things, because the model has no mechanism for retention between sessions. The information must be written down and injected into the next session's context.
I cross-referenced how human organizations handle the equivalent problem — shift handovers in medical settings, project handoffs in consulting, incident reports in engineering — and found a consistent pattern: the most effective handovers are structured, specific, and written for a reader with no prior context. The same principles apply to agent handovers.
A handover document is not a log. It is not a transcript. It is a compressed, structured summary of state designed to make the next session effective from turn one.
Document Structure
Effective handover documents contain four categories of information:
1. Current State
What exists right now. Not what was attempted — what succeeded and is present. This includes file paths, database states, deployed configurations, and any artifacts the agent produced. The reader of this document should be able to verify current state independently based on what is written here.
2. Decisions and Rationale
What choices were made and why. This is the section most often omitted and most often missed. When a future session encounters a technical constraint or an architectural choice, it needs to know whether that choice was deliberate or incidental. Decisions documented without rationale get relitigated. Decisions documented with rationale get respected or explicitly overridden.
3. Open Items
What is incomplete, blocked, or unresolved. This section prevents the next session from re-discovering problems already identified. It should include the specific state of each open item — not just "authentication is broken" but "authentication fails on token refresh with a 401; the issue is in refreshToken.ts line 47; the likely fix is X but it requires verifying Y first."
4. Next Actions
The first 2–3 things the next session should do, in priority order. This is not a wishlist — it is a concrete starting point that bypasses the re-orientation overhead at the beginning of every session.
Principles for Writing Effective Handovers
Write for someone who was not there. The next session has no access to the conversation history, no memory of what was discussed, and no awareness of context that was implicit during the session. Every piece of information that matters must be stated explicitly.
Prefer specificity over completeness. A handover document that attempts to capture everything becomes unreadable. The goal is the minimum information required to resume effectively, not a full record. If a decision is unlikely to matter next session, it does not need to be in the document.
Update the document during the session, not after. Handover documents written at the end of a session from memory are less accurate than documents updated incrementally. The most reliable approach is to treat the handover document as a live artifact that gets updated whenever a significant decision is made or state changes.
Use consistent structure. Agents reading handover documents benefit from predictable organization. A document where the current state is always in the same section, formatted the same way, is faster to process than a document where structure varies by session.
Include failure information. What was tried and did not work is as valuable as what succeeded. Without this, the next session may repeat failed approaches. Failed attempts should be documented with enough specificity to understand why they failed, not just that they did.
How They Enable Continuity
The handover document is injected into the next session's context as part of the knowledge base. From the model's perspective, it reads a structured document describing the current project state and picks up from there.
The practical effect: sessions that begin with a handover document reach productive work within the first 2–3 turns. Sessions without one spend 5–10 turns re-establishing context, often incompletely.
There is a compounding benefit over time. A project managed with consistent handover documents accumulates a structured record of decisions, state changes, and rationale. That record is useful not just for agent continuity but for human review — it provides an auditable history of what an agent did and why.
What a Handover Document Is Not
It is not a conversation transcript. Transcripts are long, unstructured, and expensive to process. The handover document is a synthesis, not a record.
It is not a task list. Task lists track what needs to be done. Handover documents communicate current state, including the state of tasks, but they are not project management tools.
It is not permanent. A handover document is accurate as of the session that produced it. Its validity decays as the project evolves. Systems that treat outdated handover documents as authoritative will make decisions based on stale state.
Implementation
The mechanics are straightforward:
- Maintain a
handover.md(or equivalent) file in the project knowledge base - At the end of each session, update the document with the four sections described above
- Ensure the document is injected into the next session's context via the system prompt or knowledge base configuration
- At the start of each session, confirm the document's current state is accurate before beginning work
The update step is the one that fails most often in practice. The solution is to make it a required final action — an explicit instruction in the agent's operating procedure that the session does not end without updating the handover document.
Sessions are ephemeral. The work is not. Handover documents are the bridge between them.
Comments 0