Delegate Only After You Define the Work
A coding agent is not just a chat box with better manners. It can read files, edit them, run terminal commands, call tools, and observe the results before deciding what to do next. That act-observe loop is what makes it an agent. A sub-agent is the same idea used inside a larger task: a separate worker with its own limited assignment, often running in parallel with others.
The central rule is simple: use sub-agents for separate jobs, not vague help. “Improve this repo” is too broad. “Inspect the authentication flow for missing error handling and report file paths, risks, and suggested fixes” is a job. The difference is not wording polish. It is whether the agent has enough boundaries to work without inventing the project for you.
Before launching sub-agents, write the shape of the work: goal, files or folders to inspect, output format, what counts as done, and when to stop. Include edge cases and decision rights. For example: “Do not edit files. If tests cannot run, say exactly why. Rank findings by user impact.” This turns delegation from wishful thinking into process design.
Split by Independence, Not by Size
Once the work is defined, split it where the pieces do not need each other’s intermediate answers. Good sub-agent assignments include research across separate folders, independent code-review passes, test investigation, documentation inventory, or migration work divided by directory. Poor assignments include five agents editing the same function or multiple agents making design decisions without a shared spec.
A practical pattern is to give every sub-agent the same source of truth and a different lane. If you are migrating a markdown knowledge base into a standard structure, every worker should receive the format rules, then one can handle `docs/api`, another `docs/guides`, and another `docs/ops`. If you are reviewing a large codebase, one agent can inspect security risks, another can inspect flaky tests, and another can inspect dependency or build issues.
The tradeoff is cost and coordination. Parallel agents spend more tokens because each worker needs enough context to operate. That is wasteful when the task is tiny or exploratory. It is rational when the work is broad, independent, and checkable. Measure the result by useful completed work per dollar, not by whether the transcript looks short.
Give Each Sub-Agent a Narrow Context Window
Context is the information an agent can see and use while it works: your prompt, selected files, command output, prior messages, and any retrieved documents. More context is not always better. If you stuff every worker with the whole repo and every idea you have, they anchor on the same noise and repeat each other’s assumptions.
Instead, feed each sub-agent only what it needs plus the common rules. A testing agent needs the test commands, relevant failure output, and target files. A reviewer needs the diff or folder scope and severity rubric. A migration agent needs the format spec, the folder it owns, and examples of correct output. This is also where MCP fits: Model Context Protocol is a standard way for agents to connect to external tools and data sources, such as GitHub, docs, browsers, databases, or local services. Treat MCP tools as controlled inputs and actions, not magic authority.
For longer jobs, specify failure behavior. Tell the agent how many times to retry a command, when to skip a file, when to stop and report, and what evidence to include. Unattended agents fail most dangerously when they keep improvising after the plan breaks. A good sub-agent prompt includes a small escape hatch: “If blocked after two attempts, stop and report the blocker with the last command and output.”
Merge Findings Like a Reviewer, Not a Believer
The root agent, or you, becomes the orchestrator. Its job is not to average the answers. It compares reports, removes duplicates, checks evidence, and decides what to do next. Ask sub-agents to return structured findings: title, severity, files, evidence, recommended fix, and confidence. This makes merging possible without rereading five essays.
Expect disagreement. One reviewer may flag a real bug, another may call it harmless, and a third may miss it entirely. That is normal. Use the reports as leads, then verify with files, tests, or commands. For implementation, fix in priority order. Do not let every sub-agent apply patches at once unless their scopes are isolated and the repo can absorb parallel changes cleanly.
Also separate objective work from taste work. “Find failing tests and propose fixes” can be mostly automated because pass or fail is measurable. “Make this UI feel premium” needs human judgment because quality is subjective. Sub-agents can gather references, list inconsistencies, or produce options, but you should keep final taste decisions close to the human owner.
Use a Repeatable Delegation Template
The pattern becomes powerful when you stop inventing it each time. For any repeatable workflow, write a small template: shared context, role, scope, allowed tools, output format, validation checks, retry rules, and stop conditions. Teams often turn these templates into reusable skills so the agent can apply the same review, migration, or testing routine later with fewer instructions.
A simple version looks like this: “You are Sub-Agent A. Scope: `src/auth` only. Task: find places where errors are swallowed or logged without user-visible handling. Allowed actions: read files and run existing tests. Do not edit. Output: up to 10 findings with file path, line reference if available, risk, and suggested next action. Stop if tests require missing services and report the exact blocker.” That is boring in the best way. It gives the worker enough room to act and enough structure to be audited.
Sub-agents help when delegation creates independent evidence faster than one agent can gather it alone. They hurt when they multiply ambiguity. Start small: one research agent, one review agent, one testing agent. Merge their work skeptically. Then promote the parts that worked into repeatable prompts or skills. The goal is not to trust a crowd of agents. The goal is to design small jobs whose outputs you can verify.
Key takeaways
- Use sub-agents for independent, checkable jobs, not broad requests like “improve this repo.”
- Give every sub-agent a clear scope, shared rules, allowed tools, output format, and stop condition.
- Split work by folder, concern, or phase when agents do not need each other’s intermediate answers.
- Treat MCP-connected tools as controlled ways to fetch context or take actions, not as proof that the answer is correct.
- Merge sub-agent reports by deduping, ranking severity, and verifying evidence before implementing fixes.
- Automate measurable work first; keep subjective taste decisions under human review.