Part 2 · Taming the Tail

Context Engineering · ~6 min

Breaking the Stack

A sub-agent starts from nothing. It inherits none of your project rules, skills, or history — unless you hand them over at the door.

Why this, for you: the moment you delegate to a sub-agent, the careful instruction stack you built (Lesson 06) silently resets to empty. This is the harness pattern behind every orchestrator-worker setup (#2) — and the trick that keeps a long coordinator's context clean instead of drowning in raw exploration (#1).

Lesson 06 stacked your instructions in layers: system prompt → project file → skill → user message, each more specific, each overriding the one above. Sub-agents don't read that stack. They get a fresh one.

1 A worker boots with an empty stack

A sub-agent invoked by a parent does not inherit the parent's context. It starts fresh with its own system prompt, typically injected at invocation time. The parent's project instructions, loaded skills, and conversation history are not present unless explicitly passed.

A sub-agent can violate the exact project conventions the parent was carefully following — not because it disagrees, but because it never received them. Debugging means knowing what the sub-agent got at invocation, not what the parent had.
# parent has CLAUDE.md loaded: "always write tests" # it spawns a worker to add a helper — and forgets to pass the rule Worker prompt: "Add a date-parsing helper to utils.ts" → worker ships the helper, no tests — it never saw the convention # the bug isn't the worker. it's the empty stack you handed it.

This is why layering and delegation pull against each other: the layer stack lives in the parent; the worker is a brand-new room.

2 The isolation is the feature

That empty stack isn't only a hazard — it's the whole point of the orchestrator-worker pattern. Each worker gets a bounded subtask and its own context window; its exploration never enters the main thread. The coordinator dispatches tasks and receives only distilled summaries, not raw file reads and dead ends.

A worker reads 5000, returns 200

A sub-agent that consumes a 5000-token page should hand back a ~200-token summary of the relevant facts. The other 4800 tokens vanish when it finishes — they never crowd the coordinator's window. Isolation is a context management strategy, not just a parallelism one.

# coordinator stays clean; workers absorb the mess Worker A → src/auth/login.ts → 200-token summary Worker B → src/auth/session.ts → 200-token summary Worker C → src/auth/middleware.ts → 200-token summary # main thread synthesizes the architecture from summaries alone

It pays off when each worker's exploration would otherwise pollute the main context. Spawning three workers to read three 100-token files just buys latency and cost — isolation only earns its keep on substantial, independent work.

Workers win — when the task actually splits

Opus orchestrating Sonnet workers beat single-agent Opus by 90.2% on complex research. But that's conditional: in a controlled evaluation most multi-agent setups underperformed a single-agent baseline, and multi-agent burns ~15x the tokens of chat. Fan out only when subtasks are genuinely independent.

↪ Your win: delegate the mess, pass the constraints

Retrieval practice — recall, don't peek

Question 1A freshly invoked sub-agent inherits the parent's project rules…

Question 2The main benefit of running workers in isolated windows is that…

Question 3Layering instructions without an injection protocol leaves sub-agents with…

Question 4A worker reading a 5000-token page should return to the coordinator…

Question 5 · spaced recall from Lesson 12When an approach fails, you should usually…

Ask me anything. Want a handoff-contract template for passing constraints into a worker, or how to decide between fire-and-forget sub-agents and a coordinated agent team? Next: Maps & Breadcrumbs — giving the agent structure, not raw files.
✎ Feedback