agent-orchestration

Agent orchestration

Subagents are a force multiplier for mechanical, parallelizable, and verifiable work. They are not a substitute for judgment. Treat every agent's output as evidence you must verify -- not as a finished deliverable. You own every finding you publish, regardless of which agent produced it.

When to use

Delegate work that is well-specified, has a checkable answer, and does not depend on holding the whole problem in your head:

• Mechanical tracing. Follow one call path, one data flow, or one config chain to its end. "Trace how a request reaches the persistence layer."
• Point verification. Confirm one claim at one location. "Does function parse_header at src/net/http.rb handle a missing content-length?"
• Search and aggregation. Find every call site, collect all matches of a pattern, tally occurrences across a tree.
• Parallel independent reads. Fan out N agents to read N files or modules for coverage when the reads do not depend on each other.
• Validation. Check one agent's claim against the code, or cross-check two agents that touched the same surface.

Rule of thumb: if you can state the question, the exact place to look, and the shape of a correct answer, an agent can do it.

When not to use

Keep these yourself. Delegating them produces confident, wrong, or shallow output:

• Architecture and design thinking. Agents analyze components in isolation. They miss cross-component interactions, shared-state coupling, and cascading effects. A design decision lives in the seams between parts, which no single-component agent sees.
• Trade-off weighing. Agents will list pros and cons, but they do not weigh them with real numbers (latency budgets, memory ceilings, blast radius, team cost). A list is not a decision.
• Anything session-dependent. Agents start fresh with no memory of this session -- prior decisions, constraints you discovered, why option B was already ruled out. If the answer depends on context you built up, the agent cannot reconstruct it.