If you give someone a large book containing all the philosophy and information of the world, and then ask them to make tea, that person is going to be confused.
That is the whole idea of sub-agent architecture, in one image. Now the concrete version: a 30-minute training session with fifteen things to do: teach a concept, run a quiz, roleplay an objection, evaluate the performance, plan next steps. One agent carrying all fifteen instructions is mildly confused while doing any one of them. Its quiz instructions bleed into its roleplay. Its evaluation rubric leaks into its teaching voice. Every instruction you add for phase four slightly degrades phases one through three, because (Chapter 5, as always) everything in context competes for attention.
The alternative: several agents, each holding only its own phase’s instructions, handing the baton cleanly between them. This part of the playbook is how.
The signals that it’s time to split
Five signals, in the order you will usually meet them:
1. Duration. Sessions consistently beyond roughly twenty minutes (Chapter 13’s threshold). Summarization is fighting a losing battle, and each phase only needs a fraction of what the summary is straining to preserve.
2. Distinct phases. The flow has stages with genuinely different jobs: greeting and context-setting, teaching, drilling, evaluating, wrapping up. When you look at your Chapter 7 session flow and see phases that share almost no instructions, you are looking at agent boundaries.
3. Incompatible personas. The warm greeter and the ruthless mock-interviewer should not share one prompt. Blend them and you get a lukewarm both: an interviewer who apologizes for pressure, a greeter with an edge. Some persona pairs are simply unmixable in one context.
4. Instruction crowding. Your prompt pushes past the 10,000-token smell (Chapter 5) after you have already moved referential content out per Chapters 9 and 10. What remains is genuinely per-phase instruction, so give each phase its own prompt.
5. Different tool sets per phase. The quiz phase needs MCQ; the roleplay needs image generation and pressure instructions; the evaluator needs the rubric. Tool instructions per phase shrink dramatically when each agent registers only what its phase uses.
One signal is a hint. Three or more is a decision.
Why it works: the token-efficiency argument
Consider what the greeting agent needs, in full: it knows who it’s meeting today, it has to say hello and set the context, and that’s it. Its entire every-turn context is a small persona block, the super memory, and an agenda template. It has sufficient context to greet, and nothing else.
Spell out what that buys:
- Each agent’s every-turn context is its own small prompt plus only-relevant history. Chapter 5’s accuracy curve now works for you instead of against you: every agent operates at the sharp end of the curve.
- The token tax falls for every phase. The greeter doesn’t pay for the evaluation rubric on every turn; the evaluator doesn’t pay for the icebreaker examples.
- Failures are contained. A confused evaluator cannot derail the greeting. And when something goes wrong, you debug one small prompt with one job, not one giant prompt where any of fifteen instructions might be the culprit.
Where the pattern comes from
Credit where due: long-running coding agents pioneered this discipline. They plan, write the plan to a note, and execute against the note. Even if a step fails, the next agent picks up from the note rather than from scratch. Cursor-class agents maintain “here is the plan, here is what I did” artifacts precisely so that no single context ever has to hold everything.
Conversation agents inherit the pattern directly: notes between phases, minimal context per phase. Chapter 16 is entirely about those notes, because the notes are where split architectures succeed or fail.
The cost of splitting
Before you decompose everything you own, the honest counterweight, because splitting adds real costs:
- Handoffs can be felt. If the tone shifts at a seam, the user notices the machinery. Persona consistency across sub-agents takes explicit care (Chapter 15 gives the technique).
- State transfer is a new failure surface. A bad handoff note loses information that a single agent would have remembered for free. You are trading context bloat for seam risk.
- Debugging spans agents. “Why did the evaluator not know about the second roleplay?” is a handoff bug, a species that doesn’t exist in single-agent systems, and one your Chapter 21 loop has to learn to catch.
So the rule: single agent until it visibly strains. Most 10 to 15 minute, single-purpose scenarios never need splitting, and Chapter 4’s simplicity ethos applies to architecture too. But when the signals stack up (and for ambitious sessions they will), split deliberately rather than patching a monolith that has outgrown its context.
Convinced you need to split? Then the next question is where to cut, and phase boundaries, it turns out, are almost always the answer.