State files, the task board, and memory
Three layers that let a forgetful colleague pick up where they left off
Two agent sessions, started an hour apart, each spent twenty minutes planning the same migration. Neither knew the other existed. The plans were different. Both were reasonable. One of them was wasted.
Continuity does not happen by itself. The agent forgets between sessions, and parallel sessions are strangers. Three layers of written state fix this, and each answers a different question.
Layer 1: the state file. “Where is this thing?”
Every app carries a short file with three headings: where it is, next step, traps. The next step is one concrete action with a file path. The traps are the non-obvious things that have bitten someone. An agent dropped into the app reads it in ten seconds and knows what to do first and what not to touch.
It is deliberately small and deliberately per-app. A single project-wide status document goes stale because nobody owns any one line of it.
Layer 2: the task board. “What is in flight?”
One row per worktree, branch, or todo, with a status and a next step. Checking it is step zero of every session, before reading the constitution, before planning. If the work matches an existing row, continue there; do not start a new worktree. Register new work from the worktree; update the row before stopping.
Layer 3: memory notes. “What did we learn?”
Some facts are neither app state nor a task: a measurement that changed a rule, a decision and why it was made, an incident and the guard it produced. Those go into small, dated notes the agent recalls at the start of a session, each one saying what changed, why, and how to apply it. Cross-links tie related notes together.
The discipline is compression. A note that says “remote health probes on the dictation path doubled latency; the router now runs them in parallel and async; never put a blocking remote call on the transcribe path” replaces a two-hour transcript, and it fits in a sentence the agent can act on.
Handoffs
When a session ends mid-task, the handoff is not the history. It is the objective, the constraints, the verified state, the open questions, and the next action, with paths and timestamps. Evidence, such as screenshots and logs, lives in a runs directory outside the repo and is linked, not pasted. A summary skill can produce the “catch me up” version from the conversation alone when the human comes back from a break.
What does not go into memory
Anything the repo already records. Code structure, past fixes, git history, the constitution itself. Memory is for what is not derivable from the files. If a note would duplicate the codebase, the codebase is the note.
State per app, a board across tasks, notes for what was learned. Three questions, three files, and a colleague who can pick up cold.