Who does which part
One agent doing everything ends up doing everything worse. Splitting the work across several, each with its own context, is not an advanced optimisation: it is what stops a long task from degrading within the hour.
Context is not shared by default, it is shared by decision. And almost everything that goes wrong in a long session is context that got shared without anyone deciding it.
This is not a seventh discipline. The six are a claim, not a container, and adding one would mean arguing that a real concern goes uncovered. It does not: method already asks “in what order is the work done, and who does each part?”. This page is the second half of that question.
The difference is that method defines the procedure — the phases, the handoffs, the budget — and this defines the topology: where each phase runs and what context it starts from. The same procedure split two different ways gives two different results, which is why the topology earns a page instead of a paragraph.
If you want the procedure before the split, start at method and come back.
The roles
These are not products or settings: they are ways of cutting down what context each agent receives. What defines a role is not what it may do, it is what it is forbidden to do — an agent defined only by its permissions ends up doing everything, and then you are back to one agent wearing five names.
- What lives here
- The main thread: the goal, where the task stands, and the decisions already taken. Very little code, and none it did not need in order to decide something.
- What it returns
- It does not return, it receives. It is the only one that sees the whole task, and that complete view is exactly what is lost once its window fills.
- What it never does
- Start reading the repository to understand something. The moment it does, it stops being an orchestrator and becomes the most expensive executor you have.
- What lives here
- One concrete question and access to the repository. None of the conversation history: tell it what you expect to find and it will find it.
- What it returns
- Three sentences and the coordinates. Never a dump of what it read — handing back the transcript cancels the reason you sent it.
- What it never does
- Edit. Let it write and it will write from what it understood in a single sweep, without having seen the consequences.
- What lives here
- The specification, the repository's standards, and the files it is going to touch. It receives conclusions, not transcripts.
- What it returns
- The change, and what was left out. The second part is the one that rarely comes back and always turns out to be needed.
- What it never does
- Choose the approach. Arriving without one decided, it picks its own — halfway through, and without telling you.
- What lives here
- The diff and the criteria. Nothing about how it was written: whoever knows the argument judges the argument, not what ended up on the page.
- What it returns
- Findings with a file, a line, and a failing scenario. A finding with no scenario is a style opinion.
- What it never does
- Fix what it finds. Whoever reviews and fixes ends up defending their own fix on the next pass.
- What lives here
- The original contract and the finished result. It took part in no earlier phase, and that is its entire usefulness.
- What it returns
- Pass or fail, against the contract. Not against what seems reasonable this late in the day.
- What it never does
- Negotiate the contract. If the contract was wrong, that is a finding — not an excuse to loosen it and wave the work through.
When to delegate and when not to
Both columns matter. A list of what to delegate is advice; the list of what not to delegate is what people learn by paying for it, because over-delegating fails quietly: the work still gets done, you just did it twice.
Delegate
Understanding something means opening four files or more.
The cost of understanding is paid once, in someone else's window, and comes back turned into three sentences.
The command prints hundreds of lines and three of them matter.
This is the most common context leak and the least visible: the whole output goes in even when you only read the end.
Something just written has to be reviewed or verified.
Here it is not about noise, it is about independence. The thread that wrote it already holds every reason it is right.
The task splits into batches that do not overlap.
Each batch fits comfortably in its own window and verifies on its own. It is the only healthy way to run anything in parallel.
Keep it yourself
You already know the answer and it only needs writing down.
Delegation has a fixed cost. Whoever receives the task starts cold and works out again what you had already settled.
The change touches two or more files that have to stay coherent with each other.
One author. Two agents writing in parallel produce two halves, each coherent with itself and with nothing else.
It is a state question: which branch, what changed, which version is installed.
Delegating a one-second question costs more than answering it, and leaves you waiting on top.
Somebody has to sign the decision.
You can delegate the research into each alternative. Not the choice, because whoever delegates it cannot defend it afterwards.
Where the tokens go
None of these levers is a prompting trick. Each one is the economic face of a discipline already on this site, and that is exactly the thing to see: cost is not a seventh thing to engineer, it is what covering the six hands back to you when you look at the bill. With one honest exception: control is the only discipline that also adds spend. Running reviewers and verifiers costs money, and that spend is justified in errors that never reach production, not in tokens saved.
Work that produces a lot of text and little conclusion runs in another window and hands back only the result.
What it saves
In proportion to the noise you avoid — and the large saving is not the files, it is everything you would have thought worse once they were inside.
A code index answers “who calls this function” with the exact fragments, without opening whole files.
What it saves
Ten fragments against thirty complete files, and an answer instead of a search with variable luck.
A rule declared in the repository is sent once and governs the session, instead of being repeated on every message.
What it saves
Whatever you were spending on repeating yourself. And it stops depending on you remembering to repeat it, which is the saving that actually matters.
Decisions are stored as they happen and retrieved on their own at the start, rather than being rebuilt by hand.
What it saves
The context paragraph you write every morning — which you also write worse each time, as the details fade.
Every connected tool takes up window before the work begins, whether you use it or not.
What it saves
A fixed cost per message. Twenty tools connected just in case are paid for on every request, including the one that only asked for a typo.
A strict type or a lint rule tells right from wrong by executing, without consulting any model.
What it saves
Everything the check already settles is surface the review does not have to look at. It is the only item on this list that also improves the result: a mechanical check neither tires nor agrees with you.
When the window fills, the system summarises in order to continue. Splitting the task into phases means that point is never reached.
What it saves
Cutting yourself costs you writing a handoff. Letting it cut costs you the part you do not know you lost, which is the most expensive kind.
And the largest lever is not on the list, because it is not a technique: it is not doing the work twice. An agent that rebuilds context you already had, rediscovers a decision already taken, or rewrites something that already existed costs you far more than any badly divided window.