hawkes.aiKey ideas
- The one idea — A subagent is a fresh agent spawned to do one bounded job with a clean context, returning only a short summary — so the parent's window stays lean and the subtask's clutter never pollutes it.
- How it is shown — A parent agent spawning a subagent to "read these 40 files and find the bug"; the subagent burns its own context on all 40 and hands back a two-line answer.
- The trap to avoid — Doing every subtask in the main agent's context — the window fills with intermediate clutter and rots; delegate context-heavy jobs to a subagent and keep only the result.
- What it sets up — Subagents and swarms are powerful — but more agents isn't always better. when does it break?
Every research detour your agent takes dumps clutter into its window — and that clutter stays. The fix: hand the messy job to a disposable agent with a clean context.
The one idea
A subagent is a fresh agent spawned to do one bounded job with a clean context, returning only a short summary — so the parent's window stays lean and the subtask's clutter never pollutes it.
Inside orchestration lives one especially useful move, and it's really about context, not teamwork. Spawn a fresh agent for a single job, let it work, keep only its answer. That's a subagent — the cleanest trick for keeping a long task's window from rotting. A subagent is a new agent the main agent spawns to handle one bounded task. It starts with a clean context — none of the parent's history — does its single job, and returns just a short summary. Then it's gone. Delegation, with a fresh slate each time. The real point is context isolation. Say a subtask needs reading forty files to find one bug. Do it in the main agent, and all forty pile into its window and rot it.
How it works — the demo
A parent agent spawning a subagent to "read these 40 files and find the bug"; the subagent burns its own context on all 40 and hands back a two-line answer.
Hand it to a subagent instead: it burns its own context on the forty files and returns two lines. The parent stays lean. This works because of everything we've said about context. A window is finite and degrades as it fills. A subagent quarantines the messy, token-heavy part in a throwaway context, so the clutter never touches the main thread. You keep the conclusion, not the search that produced it. And it composes with the loop. The parent, mid-task, spawns a subagent as if calling a tool, waits for the summary, and continues. Subagents can even spawn subagents. It's the same agent idea, nested — fresh context on demand, whenever a job would otherwise bloat the window.
The trap to avoid
Doing every subtask in the main agent's context — the window fills with intermediate clutter and rots; delegate context-heavy jobs to a subagent and keep only the result.
Why it matters — and what’s next
Subagents and swarms are powerful — but more agents isn't always better. when does it break?
The trap: doing every subtask in the main agent's context to keep things simple. It feels simpler, but the window fills with clutter — search results, file dumps, dead ends — and quietly rots. Delegate the context-heavy jobs, and keep only what you need: the result. So a subagent is a fresh agent spawned for one job, with a clean context, returning just a summary — the cleanest way to keep a long task's window from rotting. Skills, hooks, rules, sandboxes, swarms, subagents: the harness has grown powerful. But more agents isn't always better. When does it break down? Next group: the honest limits.
This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.
Full transcript 2:30 of narration
Inside orchestration lives one especially useful move, and it's really about context, not teamwork. Spawn a fresh agent for a single job, let it work, keep only its answer. That's a subagent — the cleanest trick for keeping a long task's window from rotting.
A subagent is a new agent the main agent spawns to handle one bounded task. It starts with a clean context — none of the parent's history — does its single job, and returns just a short summary. Then it's gone. Delegation, with a fresh slate each time.
The real point is context isolation. Say a subtask needs reading forty files to find one bug. Do it in the main agent, and all forty pile into its window and rot it. Hand it to a subagent instead: it burns its own context on the forty files and returns two lines. The parent stays lean.
This works because of everything we've said about context. A window is finite and degrades as it fills. A subagent quarantines the messy, token-heavy part in a throwaway context, so the clutter never touches the main thread. You keep the conclusion, not the search that produced it.
And it composes with the loop. The parent, mid-task, spawns a subagent as if calling a tool, waits for the summary, and continues. Subagents can even spawn subagents. It's the same agent idea, nested — fresh context on demand, whenever a job would otherwise bloat the window.
The trap: doing every subtask in the main agent's context to keep things simple. It feels simpler, but the window fills with clutter — search results, file dumps, dead ends — and quietly rots. Delegate the context-heavy jobs, and keep only what you need: the result.
So a subagent is a fresh agent spawned for one job, with a clean context, returning just a summary — the cleanest way to keep a long task's window from rotting. Skills, hooks, rules, sandboxes, swarms, subagents: the harness has grown powerful. But more agents isn't always better. When does it break down? Next group: the honest limits.