GSD and H·AI·K·U

"AI coding agents produce worse output as their context window fills up." Work is broken into atomic plans, each executes in a fresh context window. Main session stays at 30–40% usage while subagents do the heavy lifting.

Same diagnosis from a year of running AI-DLC — the agent forgets the skill it loaded six steps ago. Every hat fires as a fresh subagent invocation with a structured mandate. The main agent's context never balloons because the main agent never holds the work.

The framework extracts a spec from the user's description and uses it as the source of truth for atomic plan dispatch. Subagents read the artifact they need; nothing material lives in chat.

intent.md plus units/*.md plus stage outputs are the source of truth. The agent reads what it needs per tick. Drift detection runs against the files; verifiers grade against the files.

GSD-2 detects stuck loops, recovers from crashes, auto-advances through milestones without human intervention. State is structured enough to resume.

Every state we track lives on disk. Crash, /clear, switch machines mid-intent — the next haiku_run_next reads disk and tells you what's next. Nothing was in the agent's head to lose.

A smart partner — itself an agent, with a curated mandate and tighter tools, but an agent. It decomposes specs into atomic plans, chooses which subagent runs next, decides when to clear context, declares milestones complete.

A deterministic engine. haiku_run_next reads disk, walks a state machine, returns exactly one structured action. The action is a data structure, not a prompt. No language model in the orchestrator's decision path. Same state always produces the same action.

Can hallucinate like any agent — pick a wrong atomic plan, dispatch the wrong subagent, declare a milestone done when it isn't. Mitigation is craft: tighter mandates, better tools, careful guardrails.

Can't hallucinate because there's no model in the orchestrator. Can be buggy — but the bug is in TypeScript, reproducible, and gets fixed in code rather than re-prompted.

Dispersed across runs. The orchestrator agent burns tokens every cycle deciding what to dispatch and whether the milestone is done.

Concentrated upfront. The engine is harder to build than a prompt and has to be updated in code when the workflow shifts. It doesn't burn tokens — same state, same action, no inference cost on the orchestrator side.

GSD's atomic-plan model is excellent for "spec → tasks → build artifacts → reap." Most coding work fits that shape. H·AI·K·U carries more workflow shape because we're addressing problems past the build: "build this feature, then have it security-reviewed, then opened as a PR that waits for human merge, then drift-checked against the rendered output." That's a multi-stage lifecycle with hard gates, named reviewers, and structured handoffs to humans at specific seams. Studios, stages, hats, gates, the forward-only lifecycle, and the same engine treating feedback as a first-class unit of work — those carry the lifecycle, not the task. (The Scavenger Hunt for the long shape.)

Twenty-plus studios — software, security-assessment, legal, finance, incident-response, hwdev, marketing, sales — each carrying its own stage sequence, hat library, review-agent lineup, and operation templates. GSD scales by tightening its orchestrator's mandate per project; we scale by shipping more studios. Different leverage point. The studio is reusable; the orchestrator-mandate is per-project.