Paths Subjects Questions Quizzes Pricing Search
Advanced Open Pro

Deciding When a Subagent Is Worth It for a Single Task

You're debugging a failing integration test. The failure could stem from any of ~15 files across three modules, and you don't yet know which one. You're already 40 turns into a long working session on this same codebase.

  1. Explain why delegating "find what's causing this test failure" to a single subagent is likely to help here, even though only one agent is involved and there's no parallelism.
  2. What exactly does the subagent not have access to that the main session does, and why does that matter for how you write its task description?
  3. Once the subagent reports back, you now want it (or a new subagent) to write the fix. Would you dispatch a second fresh subagent, or resume/fork the one that already found the root cause? Justify your choice against the fresh-vs-fork tradeoff.

Share this question

← Back to MCP Servers and Subagent Orchestration practice

We use cookies for product analytics to improve OmniAtlas. See our Privacy Policy.