A Repo-Local Continuity Packet for Multi-Agent Coding Work
Multi-agent coding work fails quietly when the next agent inherits only a chat transcript and a vague instruction to continue. The missing material is usually not code. It is the story behind the code: what was tried, what was rejected, which files are risky, where review stopped, what evidence matters, and which decisions should not be reopened unless new facts appear.
| Packet part | What it preserves | Review check |
|---|---|---|
| Story record | Goal, plan, blockers, accepted decisions | Can a new agent explain the next step? |
| Memory layer | Durable notes, lessons, project facts | Can humans inspect and edit it? |
| Context routing | Large outputs, traces, retrieved snippets | Can bulky evidence stay searchable without flooding the prompt? |
In Short
A repo-local continuity packet is the handoff surface for coding agents that rotate across tasks, models, or sessions. It should live near the code, be readable by humans, and separate four jobs: story state, durable memory, searchable conversation history, and bulky tool output that should not be pasted into the main context window.
The five official sources in this queue point at a useful stack. Storybloq keeps stories, plans, handovers, and review evidence in a repo-local .story/ directory. AgentMemory provides persistent project memory for coding agents. Basic Memory stores local-first Markdown knowledge that MCP-capable clients can read, write, and search. MemSearch uses Markdown as its source of truth while indexing across supported coding agents. Context Mode focuses on sandboxing large tool outputs, session continuity, and targeted retrieval after compaction.
Who this is for
This workflow is for engineering teams using more than one coding agent, session, or reviewer on the same repository. It is especially useful when work spans days, involves architecture choices, or requires evidence from tests, logs, browser runs, issue threads, or code review.
It is less necessary for a one-file change that starts and finishes in a single sitting. The packet earns its keep when a new agent would otherwise need ten minutes to ask what happened.
Starter workflow
1. Start with a story, not a transcript. Give the work a short story record: goal, owner, status, blockers, accepted plan, changed files, test evidence, and next action. Storybloq is built around this shape: stories, issues, handovers, lessons, approvals, and review records as readable files beside the code.
2. Split decisions from observations. Decisions should say what the team chose and why. Observations should say what the agent saw: failing tests, API responses, screenshots, logs, or command summaries. AgentMemory and Basic Memory are useful because both are aimed at persistent memory rather than one-off prompt stuffing. Keep project facts durable, but avoid storing secrets or raw private data unless policy allows it.
3. Keep memory human-editable. A memory layer that nobody can inspect becomes another hidden dependency. Basic Memory emphasizes Markdown files, wikilinks, and a local-first knowledge graph; MemSearch treats Markdown as the source of truth and uses its index as a derived cache. Humans can read and correct the record, while agents can search it.
4. Search across agents without merging every chat. When Claude Code, Codex, OpenClaw, or another agent touches the same project, the useful handoff is the relevant prior decision, note, or transcript fragment. MemSearch is designed for cross-agent semantic memory over Markdown and conversation history, with progressive retrieval instead of forcing every past session into the prompt.
5. Sandbox bulky output. Large snapshots, logs, issue lists, and test dumps should be stored and indexed, not pasted into working context. Context Mode’s source frames this as context saving plus session continuity: keep raw tool output out of the prompt, persist session events, and retrieve only what matters later.
6. End every session with a handover. The handover should name the current branch, changed files, commands run, tests that passed or failed, unresolved questions, and the next concrete step. A future agent should be able to resume without asking the human to reconstruct the last hour.
Recommended ASE skills
- Run repo-local story, handover, and review workflows with Storybloq for story files, handovers, approvals, and review evidence that stay beside the repository.
- Give coding agents persistent project memory with AgentMemory when agents need durable project facts and prior decisions across sessions.
- Give MCP clients local Markdown project memory with Basic Memory when the team wants local-first Markdown notes that humans and agents can both use.
- Search cross-agent Markdown memory and conversation history with memsearch when multiple agent clients need a shared searchable memory layer.
- Preserve coding-agent context by sandboxing bulky tool output and retrieving only relevant session state with Context Mode when compaction, logs, snapshots, and large tool results are eroding the working context.
What to watch
Do not turn memory into a junk drawer. Every stored note should have a use: decision, lesson, source pointer, unresolved risk, test evidence, or next action.
Keep secrets out of continuity files. Repo-local does not mean harmless. If notes might be committed, synced, indexed, or shared with another agent, treat them like project documentation and avoid credentials, private customer data, and unnecessary personal data.
Do not replace tests with handovers. A good packet tells the next agent what was checked. It does not prove correctness. Keep CI, local tests, review, and release gates as the source of truth for whether code is ready.
Watch for stale decisions. A recorded decision is useful until the facts change. Mark assumptions and revisit them when dependencies, product requirements, or production behavior move.
FAQ
What is the minimum useful continuity packet?
A story record, current status, accepted decisions, changed files, test evidence, known blockers, and the next concrete action.
Should the packet live in Git?
Often yes for project-state files that are safe to share with the team. Keep private session notes, sensitive logs, and machine-local indexes out of Git unless the repository policy explicitly allows them.
How is memory different from a handover?
A handover is the current baton pass. Memory is the durable project context that should survive many handovers: architecture decisions, recurring lessons, naming conventions, and operational cautions.
When should bulky output stay out of the prompt?
Whenever the agent only needs a summary, count, failing line, or targeted excerpt. Store the raw output where it can be retrieved, then pass the smallest useful slice back into the active task.