Pick the work up on the other machine.

Two hours into a debugging session your agent has genuinely learned things. It knows which three files matter, that the obvious fix breaks a test for a non-obvious reason, that you already rejected the refactor, and what the actual next step is.

All of that lives in the conversation. Close the laptop, hit a context limit, or move to the desktop upstairs, and it's gone. What survives is the code — which shows the half-finished state without any of the reasoning that produced it. So you start again, re-explain the constraints from memory, and watch the new session propose the approach you spent an hour ruling out.

A handoff is a document, not a transcript

The instinct is to save the conversation. That's the wrong artifact — it is long, mostly redundant, and the useful parts are buried in tool output. What the next session needs is short and structured:

• The goal. What you're actually trying to achieve, in a paragraph, written for someone with no prior context.
• Where it stands. What works, what doesn't, what's half-done and in which file.
• Decisions already made — including the rejected ones. This is the part that saves the most time, because it's the part a fresh agent will otherwise re-derive and get wrong.
• The next step, specific enough to start on.
• Gotchas. The flaky command, the misleading error, the thing that cost you twenty minutes.

Written that way it's a page of Markdown — and a page of Markdown is exactly what a workspace holds.

The code has to travel with the notes

A handoff that points at a commit the other machine can't fetch is worse than no handoff at all, because the next session resumes against different code and everything looks fine until it doesn't.

So the handoff carries the branch and the commit in its frontmatter, and the work gets pushed before it's written. Making those typed fields rather than prose is the whole trick: the receiving agent can check that the commit exists locally before it acts on anything the document says, and tell you plainly when it doesn't.

Give each handoff a short name you can type

You're going to read this off one screen and type it into another, so a UUID is the wrong identifier. A short dated ID — ctx-20260817-a3f9 — is enough to be unique and short enough to retype without squinting. On the other machine, "resume ctx-20260817-a3f9" is the entire prompt.

Never put secrets in one

A workspace is shared team memory, not a private buffer. Tokens, API keys, .env contents, connection strings and customer data don't belong in a handoff. If the context genuinely depends on a credential, name where it lives — never the value.

What Markbase does and doesn't do here

Markbase stores the handoff and serves it to whatever connects next. It doesn't watch your context window, capture sessions, or decide when to write one — that glue lives in your harness, as a skill or a slash command you write once and reuse. It's a short piece of prompting: gather these facts, push the branch, write the document, print the ID.

We use exactly that pair — one command to export, one to resume — across two machines every week. The interesting half is small. The half that's hard to build yourself is the durable, reachable, versioned place to put it.