Deep Research with Claude: Parallel Market Research Agents in One Session

Before building anything, get clear on which Claude product you are talking about — they work differently.

| Surface | What it does | Parallel agents? |

|---------|-------------|-----------------|

| claude.ai → Research button | Extended thinking: one Claude instance reasons longer before answering. Adds web search. Sequential, not parallel. | No |

| Claude Code subagents | Specialized worker agents spawned inside your terminal session. Each gets its own context window. Can run in background simultaneously. | Yes |

| Claude Code agent teams | Multiple fully independent Claude Code instances coordinated by a lead. Experimental feature. Teammates can message each other. | Yes (higher overhead) |

This guide focuses on Claude Code subagents, with a section on agent teams for more complex scenarios. If you are using the claude.ai website and clicking a Research button, that is extended thinking — a different mechanism entirely.

A Claude Code subagent is a specialized AI assistant that runs in its own isolated context window inside your session. The official definition from code.claude.com/docs/en/sub-agents:

"Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions. When Claude encounters a task that matches a subagent's description, it delegates to that subagent, which works independently and returns results."

Key properties verified from the official docs:

• Isolated context: the subagent does not see your main conversation history. It starts fresh with only the task prompt you pass it.
• Returns a summary: verbose output (search results, logs, scraped content) stays in the subagent's window. Only the result comes back to your main session. This is why subagents help with context management.
• Subagents cannot spawn subagents: nesting is blocked. Delegation goes one level deep.
• Can run in background: Claude decides foreground vs. background based on task. You can also explicitly ask for background execution, or press Ctrl+B to background a running task.
• Model is configurable: you can route subagents to haiku (fast, cheap) or sonnet (more capable) depending on task complexity.

For parallel research specifically, the pattern the docs describe is:

Research the authentication, database, and API modules in parallel using separate subagents

Each subagent explores its area independently, then Claude synthesizes the findings. The docs note clearly: "This works best when the research paths don't depend on each other."

For a deeper grounding in how to write effective subagent definitions, see the guide on 5-agent-skill-design-patterns.

The official comparison from the docs:

| Property | Subagents | Agent teams |

|----------|-----------|-------------|

| Context | Own window; results return to caller | Own window; fully independent |

| Communication | Report back to main agent only | Teammates message each other directly |

| Coordination | Main agent manages all work | Shared task list, self-coordination |

| Token cost | Lower — results summarized back | Higher — each teammate is a full Claude instance |

| Status | Stable | Experimental (requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) |

Parallelization costs more, not less. Each subagent consumes its own token budget for both input and output. Running four subagents in parallel costs roughly four times as many tokens as running one sequentially — you save wall-clock time, not money.

From practitioner benchmarks (paddo.dev synthesis, verified against Anthropic pricing):

• A deep recursive multi-agent research query can run $1–5+ per session with April 2026 pricing
• The Anthropic engineering team's 16-agent C compiler project consumed approximately 2 billion input tokens and cost roughly $20,000 over two weeks — an extreme case, but instructive about how token costs scale

Token costs are not a reason to avoid subagents. They are a reason to size the task appropriately and use cheaper models (Haiku) for subagents that do straightforward retrieval.

This is the most important constraint to understand. Subagents do not share memory, context, or findings with each other while they are running. There is no bulletin board they all write to. The only mechanism for sharing is: a subagent finishes, returns its result to your main session, and you (or Claude) synthesize and optionally pass findings forward to a chained subagent.

Implications for research design:

• Each subagent must be given enough context in its task prompt to do its job independently
• If subagent B needs subagent A's findings, you must run A first, receive the result, then start B — which is sequential, not parallel
• True parallelism only works for tasks that are genuinely independent

Parallel information gathering is tractable. Parallel synthesis is not — it is your job, and it is harder than it looks.

Each subagent returns a summary to your main context window. If four subagents each return 800 tokens of findings, that is 3,200 tokens of research landing in your main context simultaneously. Claude then attempts to synthesize these into coherent conclusions. Problems that arise:

• Conflicting data: two subagents find contradictory information. Which do you trust?
• Uneven depth: one subagent found rich primary sources; another hit paywalls and returned thin coverage. The synthesis may not reflect this asymmetry.
• Context bloat: enough parallel subagent results can consume significant main-session context, pushing out other useful context through compaction.

The official docs include this warning explicitly: "Running many subagents that each return detailed results can consume significant context."

Do not use parallel subagents when:

• The task requires sequential logic (each step depends on the previous result)
• The question has a single authoritative answer (just ask Claude directly)
• You are on a token budget and the task is not time-sensitive
• The research paths overlap heavily (you will get redundant work)
• You need the subagents to challenge each other's findings in real time (use agent teams instead, or just do it yourself in synthesis)

The official guidance from code.claude.com/docs/en/agent-teams: "Agent teams add coordination overhead and use significantly more tokens than a single session. They work best when teammates can operate independently. For sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective."

Subagents are defined in Markdown files with YAML frontmatter. Store project-specific subagents in .claude/agents/ — they get checked into version control and shared with your team.

A minimal market-research subagent definition:

---
name: competitor-researcher
description: Researches a single company or product. Use when asked to investigate a specific competitor. Pass the company name and what to investigate.
tools: Read, Glob, Grep, Bash
model: sonnet
---

You are a competitive intelligence researcher. When given a company name and research scope, you:
1. Search for publicly available information about the company's product, pricing, and positioning
2. Identify specific claims with source URLs where possible
3. Note what you could NOT find (gaps are as important as findings)
4. Return a structured summary: Overview | Pricing | Strengths | Weaknesses | Gaps

Do not speculate beyond what sources support. Label inferences as inferences.

Save this as .claude/agents/competitor-researcher.md.

A few notes on the configuration choices:

• model: sonnet — use Sonnet for substantive research. Haiku is faster/cheaper but weaker on synthesis tasks.
• tools: Read, Glob, Grep, Bash — this gives the subagent read access to local files plus shell (for web fetching via curl or similar). Add WebSearch if your MCP config includes a search tool.
• The system prompt instructs the subagent to flag gaps — this is important because a subagent that sounds confident regardless of source quality is worse than one that admits uncertainty.

For guidance on writing effective system prompts for specialized agents, the CLAUDE.md mastery guide covers the same principles applied to project-level instructions.

Once the subagent definition exists, you invoke it by describing what you want. The simplest way to launch multiple workers in parallel is to ask Claude to use the subagent for several tasks at once in a single prompt:

Use the competitor-researcher subagent to investigate all four of the following companies in parallel. Run them as background tasks simultaneously, then report all findings once they complete.

1. Linear — project management, pricing tiers, target market
2. Height — pricing, differentiators vs Linear, recent product changes
3. Notion — task management features specifically (not docs/wiki), pricing
4. Asana — task management pricing and positioning in 2026

For each: return Overview, Pricing, Strengths, Weaknesses, Gaps.

Claude will spawn four background subagent instances, each receiving one company as its task. They run concurrently. When all complete, findings return to your main session.

You can also @-mention a subagent to guarantee it runs for a specific task:

@"competitor-researcher (agent)" research Linear's pricing and target market

The @-mention syntax ensures that specific subagent runs rather than leaving the choice to Claude's automatic delegation.

You are evaluating whether to build a B2B project management tool aimed at small engineering teams (5–30 people). You want competitive intelligence on four products before writing your PRD. This is a genuine parallelization use case: each competitor is independent research, the paths do not overlap, and you want results quickly.

This is what you type to Claude Code in your main session:

I'm evaluating the small-team engineering project management market (5-30 person teams).
Research these four products in parallel using the competitor-researcher subagent.
Run all four as background tasks simultaneously.

Products to investigate:
1. Linear — focus on pricing tiers, "cycles" feature, and how they position against Jira
2. Height — focus on what differentiates it from Linear, current pricing, user sentiment
3. Shortcut (formerly Clubhouse) — pricing, target team size, current feature state
4. Plane — focus on open-source angle, self-hosted option, enterprise pricing

Return findings in a consistent structure:
- Overview (2-3 sentences)
- Pricing (current tiers and prices if findable)
- Key differentiator claim
- Weaknesses or gaps in their offering
- What I could NOT verify

After all four return, synthesize: which two are most directly competitive with a new entrant targeting 5-30 person eng teams, and why?

The following is a representative example of what parallel subagent output looks like. It is clearly labelled as illustrative — actual output depends on what sources the subagents find.

[Background subagents running: linear-research, height-research, shortcut-research, plane-research]

--- Linear findings returned ---
Overview: Linear is a fast, opinionated project management tool built for software teams.
Known for speed and keyboard-first UX. Launched Cycles (sprint-like feature) in 2022.
Pricing: Free (10 members), Standard $8/user/month, Plus $14/user/month (2026 pricing
  — verify before using, pricing pages change frequently).
Key differentiator: "Built for speed" — sub-50ms UI, Git integration, automatic issue
  tracking from commit messages.
Weaknesses: Limited customization for non-engineering workflows. Roadmap views are
  basic compared to dedicated roadmap tools.
Could not verify: Current enterprise tier pricing — only found "contact sales."

--- Height findings returned ---
Overview: Height is a project management tool positioning as a more flexible Linear
  alternative. Has recently added AI task routing features.
Pricing: Could not confirm current pricing — website showed "Get started" CTA only.
  Blog post from Q4 2025 referenced a free tier and a $6.99/user/month paid tier.
Key differentiator: Flexible views (spreadsheet, board, timeline, chat threads per task).
Weaknesses: Smaller team and community than Linear; unclear funding status.
Could not verify: Whether AI features are available on all tiers.

[Shortcut and Plane findings returned similarly...]

--- Synthesis ---
Most directly competitive with a new entrant targeting 5-30 person eng teams:

1. Linear — highest brand recognition in this exact segment. Any new tool will be
   compared to Linear by default. Its weakness (low flexibility, eng-centric) is
   where a new entrant could differentiate.

2. Plane — the open-source angle is a genuine differentiator and attracts the same
   cost-conscious small team buyer. Self-hosted option removes the "another SaaS
   subscription" objection. Watch this space.

This output flow shows the key structural properties: each subagent returns its own findings independently, gaps are explicitly named, and the synthesis step is a separate, explicit request rather than something that happens automatically.

After receiving initial results, you can chain a follow-up investigation on the most interesting finding:

The Plane open-source angle is interesting. Use the competitor-researcher subagent
to do a deeper dive on Plane specifically: GitHub star count and trajectory,
community size, enterprise customer names if any, and what the self-hosted
setup process actually looks like.

This is sequential by design — you needed the first round of results before you knew which competitor warranted deeper attention. Do not force parallelism here; the dependency structure makes sequential the right call.

For a fuller look at multi-agent data pipeline patterns — including how to chain agents for ETL-style research workflows — see the autodata multi-agent data pipeline guide.

Agent teams are experimental (enable with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). Use them when you need teammates to actively challenge each other's conclusions — not just report findings in parallel.

From the official Anthropic engineering blog example: they spawned five teammates to investigate different hypotheses about a bug, with the explicit instruction to try to disprove each other's theories, not just report individually. The debate structure forces hypotheses to survive scrutiny rather than accumulating unchallenged.

For competitive research, this is the agent-teams use case:

Create an agent team with 3 teammates to analyze whether we should enter the
project management market.

- Bear: find all evidence AGAINST entering (market saturation, strong incumbents,
  commoditization risk, capital requirements)
- Bull: find all evidence FOR entering (gaps in incumbent offerings, pricing
  opportunities, recent customer complaints about Linear/Asana)
- Skeptic: challenge both Bear and Bull's findings — look for weak sourcing,
  survivorship bias, and confirmation bias in their arguments

Have them debate, then synthesize a final assessment.

The key difference from subagents: the Skeptic can message Bear and Bull directly during the session, not just receive their final reports.

The official docs are explicit: "Agent teams use significantly more tokens than a single session. Each teammate has its own context window, and token usage scales with the number of active teammates."

The docs recommend starting with 3–5 teammates and give a practical heuristic: "5-6 tasks per teammate keeps everyone productive without excessive context switching."

Anthropic's own engineering experiment (16 parallel Claude instances building a C compiler) consumed approximately 2 billion input tokens. The lesson from that experiment was that parallelization only works when tasks are genuinely independent — their initial approach failed because all agents hit the same blockers. Success required restructuring work into truly independent subtasks first.

The most common failure mode is subagents that return confident-sounding output with poor sourcing. Prevent this with explicit instructions in the subagent system prompt:

For every factual claim, note the source URL or document you drew it from.
If you cannot find a primary source, say "unverified" rather than stating
the claim as fact.
List what you searched for but could not find — gaps matter.
Do not synthesize beyond your sources. Label inferences explicitly.

This matches the Anthropic engineering guidance on prompt design: give Claude an explicit out rather than creating pressure to fill gaps with plausible-sounding confabulation.

When multiple subagents return detailed findings simultaneously, your main session context fills quickly. A few practices help:

• Ask for structured summaries, not raw dumps: instruct the subagent to return a fixed-length structured summary (e.g., 5 bullet points per section) rather than everything it found. The full detail stays in the subagent's context; only the summary returns.
• Process subagents in batches: if you have eight competitors to investigate, run four in parallel, synthesize, then run the next four. This prevents a single context-flood.
• Ask Claude to compact after synthesis: once you have synthesized findings from a batch, explicitly ask Claude to summarize the synthesized conclusions into a compact form before starting the next batch.

Background subagents auto-deny tool calls that would otherwise require a permission prompt. If a research subagent needs to make a web request and your session has not pre-approved that tool, the subagent will fail silently on that call and continue with what it has.

Before running a parallel research session, run one foreground subagent task first and approve the relevant permissions interactively. Subsequent background agents then inherit those approvals.

Running multiple subagents in parallel does not automatically improve accuracy. As the paddo.dev synthesis of this pattern notes: "Hallucination persists. Multi-source verification reduces but doesn't eliminate false synthesis. Verification confirms only what sources claim; bad data produces bad conclusions with citations."

The same model class makes similar error patterns regardless of parallelization. Three Sonnet subagents can each independently arrive at the same confident but wrong conclusion because they share the same underlying biases and knowledge gaps.

Specific risks in market research:

• Stale pricing data: pricing pages change frequently. A subagent finding a price from a cached page or a blog post may return outdated data confidently.
• Missing recent changes: acquisitions, pivots, shutdowns, and major feature releases from the last few months may not be well-indexed in whatever search tools your subagents can reach.
• Competitor self-description: subagents often draw from company marketing pages — which represent how a company wants to be seen, not necessarily how customers experience the product.

Build in explicit verification: for any pricing or capability claim you intend to act on, check it manually against the current primary source before using it.

Claude can draft a synthesis of subagent findings, but you should treat that draft as a starting point rather than a conclusion. The synthesis step is where:

• Gaps from different subagents may not be visible to each other (one found pricing, another found complaints, Claude's synthesis may not connect them)
• Conflicting findings need a judgment call that Claude cannot always make correctly without domain context you hold
• The "so what" for your specific use case requires business judgment, not just information aggregation

Write the synthesis yourself, or give Claude the synthesis with explicit instructions about which findings to weight more heavily and why.

Next Steps

• Set up your first research subagent: create .claude/agents/competitor-researcher.md using the template in Module 3
• Run a single foreground subagent session first before launching parallel background agents — confirm it returns useful output before multiplying the cost
• Read the full 5 agent skill design patterns guide for more on how to design focused, reliable subagent definitions
• For multi-stage data pipelines where research feeds into transformation and storage, see autodata multi-agent data pipeline

Sources

• Official Claude Code subagents documentation: (fetched May 2026)
• Official Claude Code agent teams documentation: (fetched May 2026)
• Anthropic engineering: Building a C compiler with parallel Claude agents: (fetched May 2026)
• Three ways to build deep research with Claude (practitioner synthesis): (fetched May 2026)
• Claude Code advanced patterns — subagents and scaling (Anthropic resource):