Multi-Agent Systems
A single agent working alone is bounded by one context window and one line of reasoning. Splitting a problem across several buys two different things: independent pieces run at once, and a conclusion can be checked by something with no stake in having produced it. The second is worth more than the first.
How I use it
Decomposing work across sub-agents
Fanning a task out over independent pieces — separate areas of a codebase, separate research questions — so each runs in its own context instead of competing for room in one. The decomposition is the design decision; the parallelism is a side effect.
Adversarial review
A second agent whose job is to refute the first one rather than agree with it. Plausible-but-wrong output survives a single pass and rarely survives a reviewer instructed to break it, which is the cheapest quality gain available in this whole area.
Task-matched model routing
Routing each step to the cheapest model that clears the bar for it. Most pipelines have a long tail of mechanical calls that never needed a frontier model and a short head that genuinely does — running everything at the top tier is the default and it is wasteful.
Knowing when not to orchestrate
Coordination has a cost. A task that fits in one context, done once, is slower and worse as a fan-out. Multi-agent is for breadth, for independent verification, or for work too large to hold at once — not as a default.
What I use
- Claude Code
- Claude API
- Model Context Protocol
Related skills
Want the detail behind any of this?
I can walk through any of it in as much depth as you want.