OpenClaw Subagents: Parallel AI for Complex Tasks

The single most underrated feature in OpenClaw is subagents. When you ask a complex question — "research three competitors and give me a pricing comparison" — most AI tools make you wait while one model does all three in sequence. OpenClaw doesn't. It spawns three isolated agents, runs them in parallel, and synthesizes the results. The whole thing happens in the time it used to take to do one.

That's the headline. But the more interesting story is why this architecture exists and what it means for how we should think about AI workflows.

The Problem with Single-Agent Thinking#

Most people's mental model of an AI assistant is a single thread: you ask, it thinks, it answers. This works fine for simple tasks. For complex ones, it creates a fundamental problem: context contamination.

Imagine asking one agent to simultaneously research a competitor's pricing, analyze your own sales data, and draft a proposal. Each of these tasks benefits from focus. The pricing research wants to be thorough and impartial. The sales analysis wants to look at patterns without pre-loading assumptions. The proposal draft wants to be persuasive without second-guessing itself with raw data.

When you shove all three into a single context window, they fight each other. The model hedges on the proposal because it's still processing the competitor data. The competitor analysis gets colored by your internal sales narrative. The result is mushy and unfocused.

Subagents solve this by giving each task its own clean context.

How OpenClaw Subagents Actually Work#

Under the hood, a subagent is a fresh OpenClaw agent session. It has:

• Its own context window — starts from zero, no inherited state
• Its own tool access — same tools as the parent, but isolated execution
• A specific task brief — written by the parent orchestrator before spawning
• A completion signal — when done, results auto-announce back to the parent

The parent agent (what OpenClaw calls the "orchestrator") decides when to spawn subagents, writes their task briefs, and synthesizes their results. You can think of this as the CEO/worker relationship: the orchestrator plans and delegates, the subagents execute.

Here's what the spawning looks like from the orchestrator's perspective:

sessions_spawn({
  task: "Research Salesforce's current pricing tiers. Focus on the Professional and Enterprise plans. Return a structured comparison with per-seat costs, included features, and contract terms.",
  label: "Research: Salesforce pricing"
})

The subagent receives this task brief and nothing else. It doesn't know who spawned it. It doesn't have access to the parent's CRM data or conversation history. It just does its job and returns results.

The Depth-2 Constraint#

OpenClaw enforces a maximum subagent depth of 2. An orchestrator can spawn subagents; those subagents cannot spawn further subagents of their own.

This is a deliberate design choice, and I think it's the right one.

Unlimited recursion sounds powerful in theory. In practice, it creates agent pipelines that are impossible to debug, reason about, or interrupt. When something goes wrong in a depth-6 chain, you're not debugging a bug — you're excavating an archaeological site.

Depth-2 forces you to be intentional about decomposition. If a task is complex enough that a subagent needs to spawn further agents, it's almost always a sign that the orchestrator's task brief was too vague. Write a better brief. The constraint makes the system better.

When to Use Subagents (and When Not To)#

Not every task needs parallelism. Spawning subagents has overhead — context initialization, task serialization, result synthesis. For simple queries, a single agent is faster.

Use subagents when:

• The task has genuinely parallel subtasks (research A + research B + research C simultaneously)
• Different subtasks benefit from different "mental contexts" (analysis vs. drafting vs. review)
• The task is long-running and you want progress without blocking the main session
• You're processing bulk data where each item is independent (enriching 50 contacts)

Don't use subagents when:

• The task is sequential (step 2 depends on step 1's output)
• The task is simple enough that decomposition overhead exceeds the benefit
• You need tight conversational feedback during execution

The OpenClaw CRM setup guide shows examples of when subagents are used for data enrichment workflows, which is one of the most common patterns.

The Orchestrator's Job#

In DenchClaw, the main agent is always the orchestrator. It follows a specific workflow:

1. Decompose — Break the goal into subtasks
2. Present — Show the plan and get user approval
3. Dispatch — Spawn subagents for independent tasks
4. Monitor — Validate results as they arrive
5. Synthesize — Combine everything into a coherent answer

This isn't just a technical pattern. It's a thinking model. The orchestrator is forced to think clearly about what it's delegating before delegating it. The task brief — which must be fully self-contained, since subagents have no shared context — requires the orchestrator to articulate exactly what it knows and what it needs.

This discipline makes AI output better. Vague requests produce vague results. A well-written task brief almost always produces a better answer than a conversation where context builds up implicitly over many turns.

Task Briefs: The Most Important Thing You Can Write#

If you're building on OpenClaw or customizing DenchClaw's orchestration behavior, spend more time on task briefs than anything else.

A bad task brief:

Research the competitor and give me what I need.

A good task brief:

Research HubSpot's CRM Free tier. Specifically:
1. What contact storage limits exist (number of contacts, deals, companies)?
2. What features are gated to paid plans?
3. What does their current pricing page say for Starter and Professional?
4. What do recent (2025-2026) user reviews say about the free tier limitations?

Return a structured markdown document. Do not invent features — if you can't confirm something, note it as unverified.

The difference is specificity. The good brief constrains scope, defines what success looks like, and includes a quality check ("do not invent features"). The subagent has everything it needs to execute without guessing.

Real-World Patterns#

Pattern 1: Parallel competitor research

Spawn one subagent per competitor, each researching pricing, features, and positioning. Orchestrator synthesizes into a comparison matrix.

Pattern 2: Bulk data enrichment

For 50 leads that need company data pulled from the web, spawn subagents in batches of 5-10. Each subagent handles a batch, writes results to DuckDB, and reports completion.

Pattern 3: Draft-and-review

Spawn a Writer subagent to draft a proposal. Spawn a Reviewer subagent with the draft to critique it. Orchestrator synthesizes the critique with the draft to produce the final version.

Pattern 4: Research-then-act

Spawn a Research subagent first. When it completes, use the results to write a task brief for an Action subagent. This is sequential, but the second subagent benefits from the first's clean, structured output.

What This Means for AI-Native Tools#

Most AI tools treat the LLM as the product. You go to the interface, type a prompt, get an answer. The LLM is the thing.

OpenClaw treats the LLM as infrastructure. The product is the orchestration — the system that decides what to ask, when to ask in parallel, how to synthesize, and how to maintain quality across multiple contexts.

This is the right abstraction. The specific model powering any given subagent matters less than the quality of the task decomposition and the briefs that guide execution. You could swap GPT-4o for Claude 3.7 Sonnet for Gemini 2.5 Pro in any given subagent, and the output quality would be primarily determined by the brief, not the model choice.

That's a profound claim, and I believe it. The value isn't in the model — it's in the workflow.

What DenchClaw is goes deeper on this philosophy, specifically how DenchClaw's orchestration layer is designed around this principle.

The Sessions_Yield Mechanic#

One detail worth understanding: after spawning subagents, the orchestrator calls sessions_yield. This ends its current turn and waits for subagent completions before receiving results.

This is push-based, not poll-based. The orchestrator doesn't sit in a loop asking "are you done yet?" It yields, and subagents announce completion when they're finished. This is more efficient and avoids the thundering herd problem of rapid polling.

For users, this shows up as the agent saying "I've dispatched three subagents for this research — results will arrive shortly" and then going quiet until the work is done.

FAQ#

How many subagents can be spawned simultaneously? There's no hard limit, but practical constraints apply. Each subagent consumes API quota and has its own context window. For most tasks, 3-5 parallel subagents is the sweet spot.

Do subagents have access to my local files and DuckDB? Yes — subagents run in the same environment as the parent and have access to the same tools, including file system and database access. They're isolated contextually, not environmentally.

Can I interrupt a running subagent? Yes. Subagents are tracked as sessions and can be killed via the sessions manager. The parent orchestrator can also be instructed to stop waiting for specific agents.

What happens if a subagent fails? The parent orchestrator receives the failure report and can re-plan. Good orchestration includes validation: if a subagent's output doesn't meet quality criteria, the orchestrator can either retry with a better brief or handle the gap manually.

Is the subagent architecture specific to DenchClaw? No — it's built into OpenClaw, the underlying framework. DenchClaw uses it by default for complex tasks, but any application built on OpenClaw can access the subagent API.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →