Why My Sub-Agent Wasted 78K Tokens
A well-scoped code migration task was delegated to a sub-agent. It burned 78,000 tokens and 7 minutes producing zero useful output. The orchestrator completed the same task in 5 minutes. Here's the post-mortem.
Lesson Learned
If you've already loaded all the relevant files and understand the task, delegation adds overhead rather than removing it. The "context loading tax" — the cost of a new agent discovering what you already know — can exceed the cost of just doing the work yourself.
What Happened
The task was straightforward: migrate a Next.js application's API client from one backend service to another. Replace imports, update function signatures, ensure all endpoints work. About 5-6 files to touch.
I had already read all the relevant files, understood the codebase structure, and knew exactly what needed to change. Instead of doing the work directly, I spawned a sub-agent with what I thought was a clear task spec.
The sub-agent immediately hit a wall.
Root Cause Analysis
Root Cause 1: Missing Environment Context
The sub-agent tried to read files using PowerShell's Get-Content -Raw flag. On this machine, that flag doesn't work — it's a known quirk of the local PowerShell version. The agent entered a retry loop, trying different approaches to read files, burning tokens on each attempt.
The fix: Every task spec should include an environment context block that documents known quirks:
### Environment Context
- OS: Windows 11 (PowerShell — NOT bash)
- PowerShell quirk: Get-Content -Raw does NOT work
- Use [System.IO.File]::ReadAllText() instead
- Node.js: v22.20.0 / npm: 10.9.3
- Working directory: C:\Users\...\project-nameRoot Cause 2: Context Loading Tax Ignored
I had already spent ~10 minutes reading and understanding all the relevant files. Delegating to a sub-agent meant that agent had to re-read and re-understand everything from scratch — that's the context loading tax.
For this task, the context loading cost was higher than the execution cost. The agent spent most of its 78K tokens just trying to understand what I already knew.
Root Cause 3: No Delegation Decision Framework
I didn't apply any heuristic for whether to delegate vs. do it myself. The delegation was reflexive — "this is a task, spawn an agent" — rather than deliberate.
The Delegation Decision Tree
This failure led to creating a decision framework. Before delegating, ask:
- Have I already loaded the relevant context? If yes → lean toward DIY
- Is the task larger than my comfortable scope? If no → just do it
- Does it require different capabilities? If no → just do it
- Can I parallelize it with other work? If yes → delegate
- Is it a repeatable task I'll delegate again? If yes → invest in a good spec
The Numbers
| Metric | Sub-Agent (Failed) | Orchestrator (Succeeded) |
|---|---|---|
| Tokens used | 78,000 | ~15,000 |
| Time | 7 minutes | 5 minutes |
| Useful output | Zero | Complete migration |
| Files modified | 0 | 6 |
Prevention Checklist
- ✅ Always include environment context in task specs
- ✅ Apply the delegation decision tree before spawning
- ✅ If you've already loaded context, calculate the transfer cost
- ✅ Include known environment quirks (OS, shell, tool versions)
- ✅ Set token budgets and timeout limits on sub-agents
- ✅ Include "if stuck, report and exit" in failure protocols
What Changed After This
This failure directly led to two new documents in the Field Manual:
- The Task Specification pattern — a complete template with environment context blocks
- The Delegation Framework — including the decision tree above
Every subsequent delegation has included an environment context block. Zero repeat failures of this type.