Hivemind

Handoffs

How it works

Picking work up in another tool, with the reasoning attached.

Ordinary memory answers what is true. A handoff answers where this work stands and why, which is what breaks when you move between threads or tools.

Nothing to write

There is no handoff to commit. When a tool asks to resume, Hivemind assembles one from what has been saved: your newest memories, from every tool, preferring the project you are asking from.

So a handoff is only as good as what was saved along the way. A decision nobody recorded is not in it.

Five layers

LayerWhat lands in it
FactsStable truths and preferences
NarrativeWhat was said, turn by turn
DecisionsChoices, with the reasoning behind them
PrioritiesWhat was recorded as next, or still to do
WarningsConstraints: what must or must not hold

Each memory lands in a layer by its kind. A layer with nothing in it says so, so the tool reading it knows nothing was left out.

Using it

Any connected tool can load one when it starts. In practice you just ask:

Pick up where I left off.

With the Claude Code hooks installed, finished turns are saved as you work, so there is something to pick up without asking for anything first. In a tool without hooks, ask it to remember decisions as you make them.

Checked or assumed

An agent that says a step is done may have run the test, or may have skipped it. Both read the same in a summary. When a tool saves a memory it can say which: verified means it checked this session, assumed means it took the point on trust. The label travels with the memory, so the next tool reading the handoff sees · verified or · assumed beside the tool and the age.

Nothing is marked unless the writer said. A memory with no label was saved without a claim either way, and Hivemind does not guess one. A label is the writer's word, not a check Hivemind ran, so treat assumed as a prompt to look.

Several agents in one project

Parallel agents in one repository share its memory, which is the point, and also how their notes blur. Give each its own task name when it saves, a ticket, a branch or a worker's job, and pass the same name when it asks. Memories saved under that task come first in the recall or handoff, marked task: name. Memories from other tasks still appear after them, because a task is a ranking hint and never a wall. Say the branch, the worktree and the check that counts as done inside the memory itself: the task name groups notes, it does not describe them.

Finished plans

A plan that is done should stop turning up in the next session. When a tool saves "Done: the webhooks now use the v2 endpoint", it can name the plan it completes, and the plan is retired. It stays in the memory's history and can be brought back from What changed. Nothing is archived on its own: Hivemind cannot tell a finished plan from a stalled one, so the tool or you say so.

Clear instead of compact

A long conversation gets summarised when it fills up, and a summary can lose the one constraint that mattered. Your project's state does not live in the conversation. It lives in Hivemind.

So you can end a session at a natural break, clear it, and start fresh. With the Claude Code hooks installed, your next prompt brings back the memories that bear on it, and a handoff loads where the project stands. Rules you saved are not in the conversation, so clearing does not drop them.

Handoffs versus threads

They answer adjacent questions:

  • A thread is one piece of work and where it stands, written by every tool on it.
  • A handoff draws on everything, across threads and tools, sorted into layers.

Use a thread to see what you did. Use a handoff to carry on somewhere else.