Subagents are useful when independent investigations can run with focused context. They are not a reason to parallelize tightly coupled edits that all touch the same files.
1. Choose separable work
Good subagent jobs include tracing an error path, mapping test coverage, checking one subsystem or reviewing a dependency. Avoid vague “fix the whole app” delegation.
2. Give one deliverable
Ask each subagent for a compact artifact: relevant files, evidence, risks and a recommendation. Do not ask it to both investigate and rewrite half the repository unless necessary.
3. Restrict tools and context
Give only the tools, folders or commands needed for that specialist role. Smaller context reduces distraction and makes the result easier to audit.
4. Let the main session synthesize
Bring findings back to the parent session. Resolve contradictions there, decide the actual change plan and keep one source of truth for the implementation.
5. Verify before acting
Open the files and commands cited by the subagent. Treat its output as an investigation report, not as automatically trusted ground truth.
Delegate this investigation to one specialist subagent. Scope: [subsystem]. Do not edit files. Return only: likely root cause, evidence with file paths/lines, tests that cover it, and the smallest recommended next step.
Creating subagents for every tiny task; letting several agents edit the same files independently; accepting a subagent conclusion without evidence; delegating security-sensitive access too broadly.
Finish check
The parent session receives focused, evidence-backed findings that reduce uncertainty without introducing uncontrolled edits.