What each task in a plan is handed, and what it is not

A plan assigns multiple coding-agent sessions, each one starting with an empty context window. The only knowledge carried forward is what the orchestrator decides to hand over from one session to the next. This decision is crucial, as it determines whether a task continues the previous work or must rediscover it.

Each task operates independently, unaware of the session before it. It is tempting to view the plan as a conversation, but it is not. Task two begins with a fresh prompt, forgetting everything about its predecessor, unless it is explicitly passed along. Copying the entire transcript or planning conversation would fail, as the transcript contains the prompt that marks the task complete.

Three blocks are handed to each task, in a fixed order: the plan map, the outputs of directly dependent tasks, and the task itself. These blocks are composed from the plan state, not from any text the model wrote about itself. The plan map lists the tasks in order, their current status, the runner assigned to the current task, and a marker indicating the session's progress.

The outputs of direct dependencies follow the map. Each block contains a review note and the tail of the captured output, capped at 500 characters. Only direct dependencies contribute, as the planner's dependency graph defines the context boundary. Tasks running side by side in the same wave see no interaction with each other.

When a task resumes, it receives the files and a warning, reminding it that earlier edits may not have been saved. The protocol ensures that no transcript, summary, or memory file drifts out of date, and that each task only knows about its predecessors through the captured output and review notes. This design protects against misinterpretation and maintains the integrity of the plan.