STATE.md is the spine here. Every workflow reads it on start to work out where the project stands, and writes back after any meaningful step. Agents do not rely on memory - they rely on the file.
There is a consequence the documentation states plainly: a subagent cannot see anything that is not written to disk. Isolation is required for independence, but it also means everything needed must be in files before the spawn. The planning directory is precisely the shared substrate that makes the scheme hold together.
Isolation raised to architecture rather than left as a trick
The difference between "spawn subagents" and what GSD does lies in what the subagent is for.
The number of agents by itself buys nothing. Five agents sharing one murky context will simply repeat a single mistake at greater expense. Here a subagent is first of all a context boundary: a new process, a bounded set of inputs, one job, then termination.
One case that is usually forgotten is closed separately: the orchestrator fills up too. The project registers the runtime's lifecycle hooks to get a signal about how much window is left, and to warn before the runtime silently triggers compaction and discards the state the orchestrator was counting on.
Verification is a phase, not a closing sentence
A separate verification step closes the most common substitution: execution finished without errors, therefore it is done.
The verifier reads the phase goal, the recorded decisions, the plans and the execution summaries - and checks what was built against what was intended. It checks requirement coverage, decision coverage (was what you agreed in the discussion actually implemented) and alignment with the phase goal overall.
The phrasing in the documentation is worth quoting: a phase is done not because execution finished without errors, but because what was built is what was planned, and what was planned is what was decided. Discrepancies become fix plans rather than remarks.
Roles are spread across models
The practical part that lighter packs usually lack.
Roles are configured by model tier, at three levels of granularity: the whole profile (quality, balanced, budget), the phase type (planning, discussion, research, execution, verification, completion), and a per-agent override by name. Plus a mapping from tiers to concrete model identifiers for each runtime.
The point is direct: a strong model for planning and debugging, a cheap one for execution and mapping the codebase. With thirty-four agents and work spread over days, that stops being cosmetic and becomes a line item.
The documentation does not hide the awkward parts
That is a rare quality, and it is present here.
The chapter on context engineering ends with a section on trade-offs stating outright that the loop adds real friction, that spawning fresh-context subagents is slower than one in-context edit, and that for renaming a variable or fixing a typo the whole loop is overkill.
It also admits that tracking the remaining window is a heuristic rather than a guarantee: a single model call can consume unpredictably much. And it describes a decision that had to be reversed: three heavy workflows used to run in a forked context, but a fork has no agent-spawning tool, and those workflows exist precisely to spawn - so the fork was removed, with a link to the tracker issue.
The cost: debugging the process instead of the code
Orchestration makes failures harder to unpick.
When a result has passed through a researcher, a planner, a plan-checker and an executor, "which line of code is bad" is often the wrong question. The real one is at which stage the wrong premise appeared and why it was let through.
The upside is that every intermediate artefact is on disk and can be read. The downside is that you are the one reading it, and that is a different skill from reading a stack trace.
The cost: external memory grows too
Files solve the vanishing-context problem and introduce one of their own.
A bad decisions file merely converts old chat noise into new file noise. And a good one still grows: this repository's own context file is three hundred and forty-two kilobytes, and the project had to invent a format for it in which every fact occupies a single machine-greppable line, with the chronology exiled to a log at the bottom. Between two checks a day apart it grew by sixteen kilobytes - a better illustration of the point than any argument.
That is an honest signal about the scale of the problem. External memory demands the same discipline as code, and at some point demands a format of its own.
The cost: the system has to be learned
There are thirty-four agents here, seventy-one commands, seventy-one skills and nearly four hundred pages of documentation. This is no longer a set of instructions layered onto an agent but a full tool with its own lifecycle, configuration and vocabulary.
It is installed by an installer that adapts the files to your particular runtime - sixteen of them are documented individually:
