Start With One Manager Thread
The central rule is simple: parallel agents need a single place where decisions come back together. A coding agent is an AI session that can use tools, meaning it can read files, edit files, run commands, open a browser, or call connected services. A sub-agent is another agent session you send off to do a smaller job. If every session makes its own plan and changes files independently, you get conflicting edits, duplicated research, and no shared judgment.
Use one main thread as the manager. That thread holds the goal, the constraints, the current state, and the final decision. Sub-agents should report back to it, not wander into implementation unless you explicitly gave them that right. For a first coding-agent workflow, this is the safest mental model: the manager owns context and judgment; sub-agents produce evidence, options, drafts, or isolated fixes.
This matters because context is limited. Context is the working memory the agent can see: your prompt, selected files, command output, prior messages, and project rules such as `agents.md` or `CLAUDE.md`. More context is not always better. Old rules, stale notes, and unrelated files can distract the model. The manager should decide what each sub-agent needs to see, then keep the returned findings short enough to merge.
Split Only Independent Work
Once you have a manager thread, split work only where the pieces can be checked separately. Good sub-agent jobs have a narrow question, a clear boundary, and an expected output. Examples: inspect authentication code for security issues, compare three UI libraries for this project, find flaky tests related to checkout, migrate one documentation folder to a known format, or review a pull request for performance risks.
Bad sub-agent jobs are vague or overlapping: “improve the app,” “clean up the codebase,” or “fix the backend and frontend.” Those tasks force multiple agents to reason about the same files and make incompatible assumptions. If the work touches shared architecture, APIs, database schema, or user-facing behavior, use sub-agents for research and review first. Let the manager decide the implementation path after seeing the tradeoffs.
A useful test is this: could two humans do these tasks at the same time without talking? If yes, sub-agents may help. If no, write an implementation spec first. The spec should say what problem is being solved, what files or modules are in scope, what must not change, how success will be verified, and where human judgment is required. That extra planning feels slower, but it prevents the expensive failure mode where agents spend hours producing work you cannot safely merge.
Give Each Agent a Job Description
A sub-agent prompt should read less like a wish and more like a work order. Include the role, scope, inputs, output format, permission level, and stopping condition. For example: “Review only `src/billing` for race conditions. Do not edit files. Return the top five risks with file references, reproduction steps if possible, and a confidence rating.” That tells the agent what success looks like and keeps it from turning a review into a rewrite.
Also specify tool limits. Tools are powerful because they connect the model to the real environment, but they are also where damage happens. Running tests is low risk. Deleting directories, rewriting config, changing DNS, or pushing code is high risk. New users should keep approval prompts on for important actions and add safety rules that block catastrophic commands against sensitive paths. Parallelism multiplies mistakes, so tool boundaries matter more when sub-agents are involved.
For longer jobs, add exception rules. Tell the agent what to do if tests fail, dependencies are missing, a file is unclear, or the task seems larger than expected. Set retry limits and escalation conditions. “Try the test command once, inspect the failure, retry once after a fix, then stop and report” is much better than “keep going.” A stuck sub-agent should return a useful status, not burn time in a loop.
Use MCP and Skills as Shared Rails
After your sub-agent prompts are narrow, shared tooling becomes the next stabilizer. MCP, or Model Context Protocol, is a way to connect agents to external systems through controlled interfaces: files, browsers, issue trackers, docs, calendars, databases, and other services. Skills or project rules are reusable instructions for recurring work, such as how to run tests, format commits, inspect logs, or deploy a service.
The point is not to connect every tool you can find. The point is to reduce guesswork. If every agent uses the same test command, review checklist, documentation format, and project conventions, their outputs become easier to compare. For large knowledge bases, use predictable indexes and metadata so agents can load only the section they need instead of dragging the whole archive into context.
Review these shared rules periodically. Instructions written for an older model or a previous project phase can become clutter. If agents keep over-explaining, editing the wrong files, or following rituals that no longer help, prune the rules. A clean harness, meaning the codebase, tools, rules, and validation path around the model, often matters more than choosing the most expensive model for every task.
Merge Through Review, Not Hope
The final step is where most chaos is either prevented or created. Do not accept sub-agent output just because it is detailed. Have the manager dedupe findings, rank them by severity or value, identify conflicts, and decide what gets implemented. For code changes, prefer isolated branches, worktrees, or sandboxed environments so parallel agents do not overwrite each other locally.
Move human attention to the highest-leverage checkpoint: final review. That does not mean ignoring the agents. It means you design the pipeline so most work can happen without interruption, then you inspect the parts that require taste, architecture judgment, security judgment, or product judgment. Quantifiable tasks like formatting, test repair, documentation sweeps, and mechanical migrations can be automated more aggressively. Subjective tasks like UX polish, pricing copy, or architectural tradeoffs need a human validation zone.
Sub-agents work when they create sharper evidence for one decision maker. They fail when they become a crowd of unsupervised editors. Keep one manager thread, split only independent work, give each agent a narrow contract, constrain tools, and merge through a deliberate review step. That is how parallel agents become leverage instead of noise.
Key takeaways
- Use one manager thread to hold the goal, constraints, and final judgment.
- Split work only when tasks are independent enough to verify separately.
- Give each sub-agent a narrow prompt with scope, tool limits, output format, and stopping rules.
- Use MCP, skills, and project rules to make repeated workflows consistent across agents.
- Keep high-risk actions behind approvals and safety rules, especially when agents run in parallel.
- Merge sub-agent work through deduplication, ranking, and final review instead of accepting outputs piecemeal.