# What to save before ending an AI coding session > The next session needs enough context to make a good decision. Here is a small, explicit handoff you can use with a document today. By Space · Written 2026-09-15 · Working with agents Web version: https://getspace.sh/articles/ai-agent-session-handoff ![A bundle of notes crosses a paper bridge from finished work to an open notebook, illustrating a session handoff.](https://getspace.sh/design/articles/ai-agent-session-handoff.0a5c1824.jpg) Editorial illustration · AI-generated ## Start with the decision the next session will face You finish a coding session with a working change, two rejected approaches, and a test you still need to run. The code records part of that work. The reasons behind it may be scattered across the conversation. A useful handoff makes the next decision easier. Someone opening it should be able to tell what you were trying to accomplish, what actually changed, which evidence supports it, and what remains uncertain. That someone might be you, the same agent in a new session, or another authorized collaborator. You can write this in a Markdown file or a document. The habit is useful before you adopt any memory tool. Keep the note small enough to read at the start of work, with links to the detail when it matters. ## Save five things Use these fields as a starting point. Leave a field explicitly unknown when you do not have evidence for it. - Goal: the outcome you are working toward, including the constraint that matters most. - Current state: the relevant branch or revision, files changed, and work that is still local. - Decisions: what you chose and why. Include a rejected option only if knowing about it will prevent repeated work. - Evidence: the checks you ran and what they showed. Record failures and checks you have not run as clearly as passes. - Next step: one concrete action, its expected result, and any unresolved question that could change it. ### Carry the decision context across the session boundary 1. **Before stopping: Make the state explicit.** Separate completed work, evidence, and open questions. Confirm that the note was saved. 2. **Saved handoff: Keep five fields.** Goal · Current state · Decisions · Evidence · Next step 3. **When resuming: Read, inspect, continue.** Compare the dated note with the current work before taking the next action. A passing local build is evidence about the build. The public deployment still needs its own check. *A suggested handoff workflow, usable with a plain document. Reading a handoff does not guarantee that its contents are still current.* ## An example: handing off a website launch This is an illustrative handoff, not a test result. Notice how it keeps a successful local build separate from a successful public launch. > Goal: publish the marketing website while the application stays in development. Current state: the public pages build locally; deployment has not been checked. Decision: export the public pages separately because the app contains routes that should not be published. Evidence: the local metadata and link checks passed. Unknown: whether the deployed domain serves the same files. Next step: open the production homepage, sitemap, and one guide while signed out, then record their responses. A note that only says “the website is ready” loses the distinction that matters. The explicit unknown gives the next session something useful to verify before it reports completion. ## Ask your agent to save it explicitly A reusable end-of-session prompt can make the handoff part of your workflow: > Write a handoff for our next session. Include the goal, current state, decisions and reasons, checks actually run, unresolved questions, and one next action. Link the relevant files or sources. Separate observed results from assumptions. Save it in the agreed location and confirm where it was saved. Read the saved note before closing the session. Check the facts that would be expensive to get wrong: the environment, the branch, whether a deployment happened, and whether a test passed. A fluent summary is still something to verify. ## Treat the handoff as dated evidence At the start of the next session, ask the agent to read the handoff and inspect the current work before taking action. A file may have changed, another person may have finished the task, or the assumption behind a decision may no longer hold. Keep the detailed handoff as a document. Track an action you need to complete as a task. Extract a short memory when a decision or constraint is likely to help across future sessions. These records serve different purposes; putting every line into memory makes it harder to tell durable context from temporary status. ## How we are approaching this in Space Space is in development around documents, tasks, and persistent agent memory in one workspace. An authorized agent connects through MCP and explicitly saves work there. Connecting an agent does not automatically import its previous conversations. The development implementation supports direct memory writes and background extraction from submitted text or a saved source revision. Extraction can take time and can be wrong. Saving the original document gives you a place to check what was actually said. Codex CLI has passed a real document-and-task integration test with Space. That test is narrower than proving reliable memory across sessions. Public hosted access is not open yet; the handoff template above can be used independently while we build. ## Further reading - [How memory works in Space](https://getspace.sh/docs/how-memory-works) - [An AI memory should tell you where it came from](https://getspace.sh/articles/ai-memory-with-sources) - [What we verified with Codex and Space](https://getspace.sh/articles/codex-space-first-integration)