In what order does the work happen, and who does each part?
Splitting work into phases with something handed over between them, instead of asking for one large task in one go and seeing what comes out.
The idea that outlives the tools
Split the work until each part fits comfortably in one window, and hand over conclusions, not transcripts.
A large task in a single conversation fails for a mechanical reason: as the window fills, the instruction from the start competes with two hundred lines of test output. The signal dilutes. Bigger windows move the problem rather than remove it.
Method fixes that by splitting the work into stages with a deliverable in between. Exploring, choosing an approach, writing, verifying: these are activities with different standards and different context needs. Merging them into one request is like asking the same person to design, build and inspect at the same time — they will approve their own work.
The other half is delegation. When part of the work produces a lot of noise and one small conclusion — reading twenty files to answer one question — it belongs to a separate agent with its own context, returning only the conclusion. The noise is not paid for in your window.
There is a symmetrical mistake that costs just as much: over-delegating. If the delegator already knows the answer, the receiver starts cold and re-derives it from scratch. Delegation has a fixed cost; it only pays when the noise avoided is larger.
Budget belongs here too. A process with no declared limit does not end: there is always one more phase to run, one more detail to check. Deciding in advance how much correction is allowed is what makes the cycle close.
How it works, stage by stage
That was the why. This is the machine: what happens at each stage and, above all, which decision is yours at each one. If there is a stage where you decide nothing, that stage is being decided for you by the tool.
01
The cut
What happens
The work is split into phases with different criteria: explore, choose the approach, write, verify. Mixing them into one request is asking the same person to design, build and inspect at once — they will approve their own work.
What you decide
Where to cut. The useful cut is where the question changes, not every few minutes.
02
The handoff
What happens
Something written passes between phases: a conclusion, a list, a specification. What passes is not the previous phase's transcript, it is its result.
What you decide
What gets handed over. Passing the whole transcript cancels the cut: the next phase inherits all the noise you were trying to leave behind.
03
Topology
What happens
Every phase runs somewhere. The ones that produce a lot of noise and little conclusion belong in a separate agent with its own window, handing back only the conclusion.
What you decide
What gets delegated. And the symmetric mistake costs just as much: if the delegator already knew the answer, the agent receiving the task starts cold and works it out again from scratch.
04
Independence
What happens
Some phases lose all their value if they share context with the previous one. The reviewer must not have seen how the code was written: having seen the reasoning, it reviews the reasoning instead of the result.
What you decide
Which ones start clean. This is not about saving tokens, it is about judgement: a reviewer who saw the argument already agrees with it.
05
Budget
What happens
The cycle carries a limit declared up front: how many corrections, how many rounds. Without that number it never ends, because there is always one more phase to run and one more detail to look at.
What you decide
The number. Choosing it before you start, while you are neither tired nor invested in the result.
Signs you are missing it
Long sessions end worse than they started.
You ask for a whole feature in a single message.
You cannot tell where in a long task something broke.
The cost of a task surprises you when you look at it afterwards.
Common mistakes covering it
Copying another team's process without understanding what problem it solved.
Delegating work you had already figured out: the subagent rediscovers it from scratch.
Adding so many phases that the ceremony costs more than the work.
None of them is mandatory. Covering the discipline is mandatory; these are known ways of doing it.
OpenSpec
Fission AIWorkflow
File-backed spec-driven development: what is already agreed, kept apart from what is being proposed.
Problem, mechanism & fit
The actual pain
You agree in the chat on what to build, the agent builds something else, and there is nowhere to point at what was agreed. The conversation the decision lived in is closed.
How it works
Keeps the current specifications in the repository, separate from proposed changes. Each change opens a folder with the proposal, the delta specs, the design and the tasks; once applied and verified, the deltas merge into the current specs and the change is archived. All of it is markdown in your repo: the commands are regenerated for whichever assistant you use, the files are not.
When it fits
When the gap between what you asked for and what came out is your recurring problem, and you want the argument to happen before the code. On a two-line change it is pure cost.
Gentle AI
Gentleman ProgrammingWorkflow
Reproducible configuration installer, spec-driven phased development, and review with a budget.
Problem, mechanism & fit
The actual pain
A hand-configured environment does not reproduce on another machine. And an AI review with no limit does not converge on its own: ask again and another observation arrives.
How it works
Installs and syncs agents, procedures and profiles by preset and scope. Adds a phased cycle — explore, propose, specify, design, tasks, apply, verify, archive — and a bounded review that picks the kind of analysis from the risk of the change, with a correction budget fixed in advance.
When it fits
When the problem is no longer making the agent work, but making it work identically on every machine and making review terminate.
gstack
Garry TanWorkflow
Twenty-plus procedures assigning product roles — product, design, QA, release — across a sprint cycle.
Problem, mechanism & fit
The actual pain
One agent doing everything does everything halfway. Planning, designing, reviewing and shipping apply different standards.
How it works
Installs commands chaining a think, plan, build, review, test, ship and reflect cycle, with deliverables handed from one phase to the next. Works across several different agents.
When it fits
When you work alone and need the standards a team would supply. It is a strong opinion about how software gets built: if it does not match yours, you will fight the tool.
Subagents
Ecosystem patternPattern
Secondary agents with their own context, for work that should not inflate the main thread.
Problem, mechanism & fit
The actual pain
Reading twenty files to answer one question leaves twenty files in the window, and everything after that thinks worse.
How it works
The main agent delegates a scoped task to a secondary one, which works in its own context and returns only the conclusion. The cost of the dirty work is not paid in your window.
When it fits
When a task produces a lot of noise and one small conclusion. The opposite mistake costs just as much: delegating something you already knew forces the other one to rediscover it cold.
Also helps with
Agent Skills
Anthropic, open standardPackage
Standards
Procedures packaged as a folder — instructions, scripts, resources — that the agent loads on its own when the task that needs them appears.
Skills for Real Engineers
Matt PocockPackage
Control
A procedure collection built around the specific failures of AI-assisted development.
Claude Code
AnthropicHarness
Capability
Terminal agent with declared permissions, hooks, subagents and skills; also on desktop, web and IDEs.
OpenCode
Open source communityHarness
Capability
An open source, provider-agnostic terminal agent.
Pi
EarendilHarness
Capability
A minimal harness: it runs agents in the terminal and brings nothing else. Whatever you need, you add.