When to Use Subagents vs the Main Chat Thread

TL;DR

Keep work in the main chat thread when the agent needs your full shared context, frequent steering, product judgment, or a single coherent plan across multiple phases.

Use a subagent when the task is isolated, noisy, parallelizable, specialized, or useful mainly as a summary back to the parent conversation.

That sounds simple, but the real impact is subtle:

• Subagents protect the main context from search results, logs, browser snapshots, long test output, and exploratory dead ends.
• Subagents can run in parallel, but parallelism multiplies token usage and review load.
• Subagents are great for “go investigate and report back.” They are weaker when the task requires constant negotiation with the human or careful continuity across many decisions.
• Worktrees solve a different problem: file isolation. Subagents solve context and delegation. You often want both.
• Cursor and Claude Code now expose similar primitives, but with different names and coordination models. Do not treat “subagent,” “cloud agent,” “agent team,” and “worktree” as interchangeable.

My default rule:

Main thread:
  decisions, synthesis, product tradeoffs, shared context, final edits

Subagent:
  research, verification, log reading, codebase exploration,
  independent review, isolated implementation attempt

What You Will Learn Here

• When work should stay in the chat history thread.
• When work can safely run in a subagent.
• How Cursor subagents, Cloud Agents, and worktrees fit together.
• How Claude Code subagents, forks, worktrees, background sessions, and agent teams differ.
• The real impact on cost, speed, context quality, correctness, and review effort.
• Practical prompts and subagent definitions you can adapt.
• A simple decision framework for engineers and PMs.

The Core Question

Modern coding agents can do much more than answer one prompt. They can inspect a repo, run commands, browse docs, edit files, open pull requests, and now delegate work to other agent instances.

That creates a new workflow question:

Should this work happen inside the main conversation, or should it be delegated to a subagent?

The main conversation is not just a transcript. It is the agent’s working memory for the task. It contains goals, constraints, tool results, user corrections, partial decisions, and the story of how the solution evolved.

A subagent is a worker with its own context window. The parent sends it a task, the worker does the work separately, and the parent receives the result. In most systems, the parent does not inherit every intermediate file read, search result, shell log, or browser snapshot.

That isolation is the point.

The Mental Model

Think of the main thread as the room where decisions happen.

Think of subagents as side rooms where focused work happens.

                 human + main agent
              product intent, tradeoffs,
             final synthesis, commit scope
                         |
        +----------------+----------------+
        |                |                |
        v                v                v
   research agent   test agent      review agent
   reads 40 files   runs noisy      checks risks
   returns summary  test output     returns findings
        |                |                |
        +----------------+----------------+
                         |
                         v
              main thread decides

If the side room discovers something important, it should bring back a compact result: findings, evidence, file paths, commands run, and recommended next steps.

If the side room needs to negotiate every step, it probably should not be a side room.

What Should Stay In The Main Chat Thread

Keep the work in the main thread when the task depends on shared judgment and continuity.

Good main-thread work:

• Turning a vague request into a clear implementation plan.
• Deciding scope with the user.
• Balancing engineering tradeoffs with product impact.
• Making the final architecture choice after multiple investigations.
• Editing code that touches the central path of the task.
• Coordinating changes where each step depends on the previous result.
• Writing the final summary, PR description, and release notes.

The key signal is not “is this important?” Important work can be delegated. The key signal is:

Does this work need the full evolving conversation to stay coherent?

For example, if you and the agent are discussing whether to ship a narrower feature today or a broader refactor later, keep that in the main thread. A subagent can collect facts, but it should not own the product decision.

Main-thread flow:

User goal
  -> clarify constraints
  -> inspect relevant files
  -> choose approach
  -> implement
  -> verify
  -> explain tradeoffs

This flow benefits from continuity. The agent should remember why you rejected one approach and why another approach matches the product intent.

What Can Run In A Subagent

Use a subagent when the task is bounded and the parent mostly needs the result.

Strong subagent candidates:

• “Search the codebase for every auth entry point and summarize the flow.”
• “Run the test suite and report only failing tests with relevant errors.”
• “Review this diff for security issues, read-only.”
• “Compare three possible libraries and return a recommendation.”
• “Investigate the browser console and return the smallest reproducible issue.”
• “Try an implementation in an isolated worktree so we can compare it.”
• “Check whether the article cites current official docs.”

These tasks share a pattern:

input is clear
work is noisy
output can be summarized
parent can judge result

Subagents are especially useful for context-heavy operations. Codebase exploration, logs, and browser automation can generate huge intermediate output. If all of that lands in the main conversation, the agent may lose room for the actual decision.

Cursor: Subagents, Cloud Agents, And Worktrees

Cursor describes subagents as specialized AI assistants that the main agent can delegate tasks to. Each subagent gets its own context window and returns its result to the parent agent.

The useful Cursor distinction:

Cursor Agent:
  main coding conversation in editor, CLI, or cloud

Cursor Subagent:
  context-isolated helper for focused work

Cursor Cloud Agent:
  a full agent run in an isolated cloud VM, often creating a branch or PR

Cursor Worktree:
  a separate Git checkout so parallel agents do not edit the same files

Cursor’s subagent docs highlight four benefits: context isolation, parallel execution, specialized expertise, and reusability. They also call out a cost reality: each subagent consumes tokens independently, and running several in parallel can roughly multiply token usage.

Cursor also has built-in subagents for context-heavy work:

• Explore for codebase search and analysis.
• Bash for command sequences where output may be verbose.
• Browser for browser automation where DOM snapshots and screenshots can be noisy.

This tells us something important about product design: the most obvious subagent wins are not glamorous. They are the boring, noisy parts of software work.

Cursor Cloud Agents Are A Bigger Delegation Unit

Cursor Cloud Agents, formerly called Background Agents, run in isolated cloud VMs. They clone repos, install dependencies, access configured secrets and MCP servers, build, test, and can push changes for handoff.

Use a Cloud Agent when the unit of delegation is closer to:

"Here is a task. Go work in your own environment and return a branch or PR."

Use a subagent when the unit of delegation is closer to:

"Go investigate this inside my current task and return a useful result."

That difference matters for PMs. A Cloud Agent can convert backlog items into reviewable work while you are doing something else. A subagent makes the current conversation smarter without stuffing it with every intermediate step.

Cursor Worktrees Solve File Collisions

Cursor’s worktree support gives each agent a separate Git checkout. That means agents can edit, install, build, and test without stepping on your main checkout or each other.

Do not confuse this with context isolation:

Subagent = separate thinking/context
Worktree = separate files/branch
Cloud VM = separate machine/environment

For code changes, the best pattern is often:

subagent + worktree

separate context
  +
separate files
  =
parallel experiment you can review

Claude Code: Subagents, Forks, Worktrees, And Agent Teams

Claude Code’s docs frame subagents as specialized assistants with their own context window, custom system prompt, tool access, and independent permissions. The parent delegates a task, the subagent works independently, and the result returns.

Claude’s own guidance is direct:

Use the main conversation when:

• The task needs frequent back-and-forth.
• Multiple phases share significant context.
• You are making a quick targeted change.
• Latency matters.

Use subagents when:

• The task produces verbose output you do not need in the main context.
• You want specific tool restrictions or permissions.
• The work is self-contained and can return a summary.

That is the best generic rule I found in the docs.

Claude Built-ins Point To The Same Pattern

Claude Code includes built-in subagents like Explore, Plan, and general-purpose. Explore is read-only and optimized for file discovery and codebase exploration. Plan gathers context during planning. General-purpose handles more complex multi-step work.

Again, the theme is not “spawn agents because agents are cool.”

The theme is:

Keep exploration out of the main thread
unless the exploration itself is the conversation.

Forked Subagents Are A Special Case

Claude also documents forked subagents. A normal named subagent starts with fresh context plus the delegation prompt. A fork inherits the full conversation history at the moment it starts.

That is useful when the side task would require too much re-explanation.

Named subagent:
  fresh context
  custom prompt/tools/model
  good for focused roles

Fork:
  inherits current conversation
  same broad situation
  good for trying side approaches

The tradeoff is that forks reduce the “clean room” benefit. They know more, but they also carry more context.

Agent Teams Are Not Just Subagents

Claude Code’s agent teams are separate Claude Code sessions coordinated by a lead, with a shared task list and inter-agent messaging. The docs position them for work where multiple agents need to communicate, challenge findings, or coordinate independently.

Use subagents for focused workers that report back.

Use agent teams when the workers need to talk to each other.

Subagents:
  parent coordinates
  workers report back to parent

Agent team:
  lead coordinates
  teammates can communicate
  shared task list

Agent teams add more overhead and token usage. They are strongest for parallel research, code review from different angles, independent feature pieces, or debugging with competing hypotheses.

The Real Impact Of Using Subagents

Subagents are not a free productivity button. They move costs and risks around.

1. Context Quality Improves

This is the biggest win.

The main thread stays focused on user intent, decisions, implementation state, and final synthesis. The messy middle stays elsewhere.

Without subagents:

main context =
  user goal
  20 file reads
  8 grep outputs
  3 failed test logs
  browser DOM dump
  one useful conclusion

With subagents:

main context =
  user goal
  useful conclusion
  evidence summary
  next decision

That cleaner context often matters more than raw context-window size.

2. Speed Can Improve, But Only For Independent Work

Parallel subagents can finish independent investigations in the time of the slowest worker instead of the sum of every worker.

Good parallel prompt:

Investigate these independently:
1. auth middleware
2. session storage
3. frontend login state

Return file paths, risks, and recommended fixes.
Do not edit files.

Bad parallel prompt:

Three agents should all modify the same checkout and improve auth.

The first prompt partitions the work. The second creates conflict and review pain.

3. Cost Goes Up Faster Than People Expect

Each subagent has its own context and token usage. If five subagents each read the same repo instructions, inspect files, and produce summaries, you are paying for five work loops.

This can still be worth it. A senior engineer would rather pay for three focused investigations than spend an hour manually reading logs. But the economics are not magic.

Use subagents when one of these is true:

• They avoid polluting the main context.
• They shorten wall-clock time.
• They produce independent perspectives.
• They enforce a useful permission boundary.
• They let you compare alternate implementations.

If none of those is true, keep the work in the main thread.

4. Correctness Can Improve Through Independent Review

One of the best uses is a verification subagent.

The main agent implements. The subagent reviews with a different objective.

main agent:
  implement the feature

verifier subagent:
  run tests
  inspect the diff
  find incomplete claims
  report pass/fail

This helps because implementation and verification are different mental modes. The implementing agent is vulnerable to confirmation bias. A verifier with a skeptical prompt can catch missing edges.

5. Review Load Increases

Parallel work creates parallel outputs. Someone still has to merge the truth.

For engineers, this means reviewing summaries, diffs, tests, and artifacts.

For PMs, this means deciding whether the extra throughput is valuable if it creates more review queues.

The question is not:

Can we run ten agents?

The question is:

Can we review ten outputs well enough to trust the result?

Decision Framework

Use this before delegating:

Does the task need the full evolving user conversation?
  yes -> main thread
  no  -> continue

Will the task generate noisy intermediate output?
  yes -> subagent
  no  -> continue

Can the task return a compact result?
  no  -> main thread
  yes -> continue

Can it run independently from other work?
  yes -> subagent, possibly parallel
  no  -> main thread or sequential subagent chain

Will it edit files?
  no  -> subagent is low risk
  yes -> use a worktree or isolated branch

Do multiple workers need to coordinate with each other?
  yes -> consider agent teams or a human-owned plan
  no  -> subagent is enough

Here is the same framework as a table:

Practical Prompt Patterns

Research Subagent

Use a read-only subagent to inspect the payment flow.

Return:
- the key files and entry points
- the current flow in 8 bullets or fewer
- any unclear or risky areas
- what you did not inspect

Do not edit files.
Do not paste long code snippets.

Why it works:

• It limits scope.
• It asks for evidence.
• It prevents code dumping.
• It keeps uncertainty visible.

Verification Subagent

Use a verifier subagent to check the current diff.

Verify:
- the feature is implemented, not only stubbed
- tests were added or existing tests still cover the behavior
- npm test or the closest relevant command passes
- there are no unrelated edits

Return pass/fail, commands run, and specific file references.

Why it works:

• It separates builder mode from reviewer mode.
• It asks for actual commands, not vibes.
• It keeps the parent responsible for final judgment.

Parallel Investigation

Run three read-only investigations in parallel:

1. API behavior
2. database schema and migrations
3. frontend state and UI edge cases

Each subagent should return:
- relevant files
- current behavior
- likely change points
- risks

After all return, synthesize one implementation plan.

Why it works:

• Each worker has a distinct territory.
• The parent keeps synthesis.
• The final plan stays coherent.

Example: Cursor Subagent Definition

Cursor custom subagents are Markdown files with YAML frontmatter. A useful team-owned verifier could look like this:

---
name: verifier
description: Validates completed work. Use after implementation to confirm the change is functional and scoped.
model: inherit
readonly: true
---

You are a skeptical verification agent.

When invoked:
1. Inspect the current diff.
2. Identify what the parent agent claims is complete.
3. Run the most relevant tests or checks when allowed.
4. Verify that the implementation exists and is not only a stub.
5. Look for unrelated file changes.

Return:
- pass/fail
- commands run
- evidence by file path
- incomplete or risky items
- recommended next action

Project-level location:

.cursor/agents/verifier.md

Use this kind of subagent when the repeated problem is “the agent says done, but I need a second pass before I believe it.”

Example: Claude Code Subagent Definition

Claude Code also supports filesystem-based subagents. A read-only research agent could look like this:

---
name: codebase-researcher
description: Read-only codebase researcher. Use when a task needs broad exploration across files before implementation.
tools: Read, Grep, Glob
model: inherit
---

You are a codebase research specialist.

Your job is to investigate, not edit.

When invoked:
1. Restate the question you are answering.
2. Search for the smallest set of relevant files.
3. Summarize the architecture and behavior.
4. Include exact file paths.
5. Flag uncertainty and areas not inspected.

Do not propose a full implementation unless asked.
Do not paste large code blocks.

Project-level location:

.claude/agents/codebase-researcher.md

This is a good fit when the parent thread is about a bigger change but needs a clean research packet first.

Example: A Simple Delegation Heuristic

If you are building your own agent router, you can encode a basic heuristic before reaching for complex orchestration.

type Task = {
  needsUserJudgment: boolean;
  expectedOutput: "summary" | "code-change" | "decision";
  noisy: boolean;
  independent: boolean;
  editsFiles: boolean;
};

function chooseExecutionMode(task: Task) {
  if (task.needsUserJudgment || task.expectedOutput === "decision") {
    return "main-thread";
  }

  if (task.editsFiles && task.independent) {
    return "subagent-in-worktree";
  }

  if (task.noisy && task.expectedOutput === "summary") {
    return "subagent";
  }

  if (task.independent && task.expectedOutput === "summary") {
    return "parallel-subagent-candidate";
  }

  return "main-thread";
}

The point is not the code. The point is the discipline:

delegate only when the output contract is clear

Anti-Patterns

1. Delegating The Decision

Bad:

Use subagents to decide what product we should build.

Better:

Use subagents to research three customer workflows.
Return evidence and tradeoffs.
We will decide in the main thread.

2. Parallelizing Same-File Edits

Bad:

Have five agents refactor the auth service at once.

Better:

Have one agent inspect auth service risks.
Have another inspect tests.
Have another inspect API callers.
Synthesize first, then edit.

3. Using Subagents For Tiny Tasks

Bad:

Use a subagent to rename this variable.

Better:

Rename the variable in the main thread.

Subagent startup and context gathering can be slower than just doing the task.

4. Accepting Summaries Without Evidence

Bad:

Looks good.

Better:

Looks good because:
- tests run: npm test
- files inspected: src/auth/session.ts, src/middleware.ts
- risks remaining: refresh token expiry not covered

A subagent summary should be compact, not vague.

How PMs Should Think About This

For PMs, subagents are less about model architecture and more about work packaging.

A good delegated task has:

• Clear goal.
• Clear boundaries.
• Clear output.
• Clear definition of done.
• A reviewer who can judge the result.

This maps nicely to product work:

bad delegation:
  "Improve onboarding"

good delegation:
  "Inspect onboarding analytics events.
   Return missing events, duplicate events,
   and one recommended event schema update."

Subagents reward precise work decomposition. They punish vague delegation by creating confident summaries of poorly scoped work.

How Engineers Should Think About This

For engineers, subagents are a context management and verification tool.

The best engineering uses I have seen are:

• Read-only architecture exploration before touching code.
• Test and log analysis.
• Independent diff review.
• Security or performance pass with limited tools.
• Best-of-N implementation attempts in separate worktrees.
• Research packets for unfamiliar systems.

The important discipline is to keep the parent thread responsible for integration.

Subagent finds.
Main thread decides.
Main thread integrates.
Verifier checks.
Human reviews.

Practical Operating Rules

Use these team rules until you have better local data:

1. Start with one subagent, not five.
2. Prefer read-only subagents first.
3. Use worktrees for file-editing subagents.
4. Ask for evidence, not just conclusions.
5. Partition by module, risk, or hypothesis.
6. Keep final synthesis in the main thread.
7. Track whether subagents reduced review time or only moved it.
8. Promote repeated successful prompts into project subagent definitions.

A Useful Default Workflow

For a medium-size coding change:

1. Main thread:
   clarify goal and constraints

2. Research subagent:
   inspect relevant code paths, read-only

3. Main thread:
   choose implementation plan

4. Main thread or worktree subagent:
   implement

5. Verifier subagent:
   run tests, inspect diff, report gaps

6. Main thread:
   fix gaps, write summary, prepare PR

This gives you context isolation without losing coherence.

The Bottom Line

Subagents are most valuable when they protect the main conversation from noise and produce independent, reviewable results.

They are least valuable when they are used as a reflex for every task.

The mature workflow is not “one agent vs many agents.” It is:

one main thread for coherence
focused subagents for bounded work
worktrees for file isolation
cloud agents for independent backlog execution
agent teams when workers must coordinate

That is the shape I would recommend today for engineering teams and PMs adopting Cursor, Claude Code, or any similar agentic coding environment.

Open Gaps In This Article

This article is based on current product documentation and practical workflow analysis, not a controlled benchmark.

The next useful research would be:

• A small benchmark comparing one main-thread agent vs one main-thread agent plus verifier subagent.
• A cost study of parallel research subagents across real repos.
• A review-time study: do subagents reduce human review time or just create more artifacts?
• A failure taxonomy for delegated coding work: stale context, bad partitioning, permission issues, merge conflicts, and vague summaries.
• A comparison of Cursor Cloud Agents, Claude background sessions, and Codex-style cloud worktrees on the same backlog tasks.

Source List

• Cursor Docs: Subagents
• Cursor Docs: Cloud Agents
• Cursor Docs: Worktrees
• Cursor Docs: Cloud Agent Best Practices
• Cursor Blog: Best practices for coding with agents
• Claude Code Docs: Create custom subagents
• Claude Code Docs: Subagents in the SDK
• Claude Code Docs: Run agents in parallel
• Claude Code Docs: Run parallel sessions with worktrees
• Claude Code Docs: Orchestrate teams of Claude Code sessions
• Claude Code Docs: Extend Claude Code