# I Stopped Doing the Work Myself. My OpenClaw Agent Now Delegates to Sub-Agents.

> Source: <https://dev.to/mrclaw207/i-stopped-doing-the-work-myself-my-openclaw-agent-now-delegates-to-sub-agents-18g1>
> Published: 2026-07-24 18:13:01+00:00

There's a moment when you stop thinking of your AI agent as a tool you're holding, and start thinking of it as infrastructure you're operating.

For me, that moment was when I started delegating work to sub-agents — spawning child sessions inside my main OpenClaw agent to handle parallel streams of work. It changed how I think about the whole system. Instead of one agent doing things sequentially, I had a small agency of agents, each doing one thing well.

This is what that actually looks like in practice.

When you run one agent doing everything, you hit a ceiling fast. The agent can only do one thing at a time, in one context. If you ask it to research a topic, write a report, AND send an email, it does them in sequence — and the context window gets crowded fast as it tries to hold all of it at once.

More than that: a single agent blurs responsibility. When one agent writes the email and also reviews the research, it can't easily catch its own mistakes. Confirmation bias is a real thing for LLMs too. The agent that wrote the email thinks the research supporting it is solid because it wrote both.

Sub-agents solve both problems.

OpenClaw lets you spawn isolated child sessions — sub-agents — from within your main session. The API call is clean:

```
# Spawn a sub-agent for parallel research
result = sessions_spawn(
    task="Research the top 5 open-source AI agent frameworks as of 2026. Return a JSON array with name, repo_url, stars, and one-line description for each.",
    runtime="subagent",
    mode="run",
    cleanup="delete"
)
```

This fires off the research task to a fresh, isolated agent. Meanwhile, the main agent can do something else — write the email draft, set up the cron job, whatever the second priority is.

When the sub-agent finishes, its output comes back as a structured result. The main agent can then incorporate it, review it, or hand it off to the next sub-agent.

The key word is **isolated**. The child session doesn't inherit your main conversation context (unless you explicitly fork it). This is a feature, not a bug. Isolation means the sub-agent can't be contaminated by the main agent's biases, and it can't accidentally overwrite the main session's state.

After running this pattern for a few weeks, I've learned what makes a good delegation task:

**Good candidates:**

**Bad candidates:**

The pattern I use: if a task has a clear input, a clear output, and doesn't need to know what else is happening in the main session, it gets delegated.

The real unlock for me was combining delegation with cron jobs. Instead of having one cron job that does everything at 2 AM, I now have a cron job that spawns a sub-agent with the full task context:

```
# In the cron job payload — fires an isolated agent turn
payload = {
    "kind": "agentTurn",
    "message": (
        "It's 2 AM. Your job is to:\n"
        "1. Read memory/YYYY-MM-DD.md for yesterday's context\n"
        "2. Research any open PRs or issues on openclaw github\n"
        "3. Draft a summary report and save it to data/daily-report.md\n"
        "4. If anything looks broken, send a Telegram alert\n"
        "Use exec, read, and write tools freely. Be thorough."
    ),
    "timeoutSeconds": 900,
    "sessionTarget": "isolated"
}
```

The main session isn't involved. The cron fires, the sub-agent wakes up, does the work, and disappears. No context pollution. No sequential bottleneck.

I want to be honest about what this costs.

**Latency.** Spawning a sub-agent and waiting for its result takes longer than doing the work yourself in the same context. For quick tasks under 2 minutes, it's often not worth it.

**Context fragmentation.** When 3 sub-agents are working in parallel, you have 3 separate result streams coming back. You need a clear convention for how results get surfaced back to the main session — otherwise you spend as much time stitching outputs together as you saved.

**Failure modes multiply.** If the main agent spawns a sub-agent that fails silently, you need to build in acknowledgment checks. I added a lightweight result log in `data/subagent-results/`

that each sub-agent writes to on completion:

```
# Each sub-agent writes this on success
with open(f"data/subagent-results/{task_id}.json", "w") as f:
    json.dump({"status": "done", "output": result, "timestamp": now()}, f)
```

The main session can then poll this directory if it needs confirmation.

Delegation isn't about replacing your agent. It's about giving it the ability to work on multiple things at once without sacrificing quality.

The biggest shift was psychological: I stopped feeling like I had to be the one doing the work. Instead of asking "how do I do this task faster?" I started asking "should this task be mine at all?"

Sometimes the answer is yes — especially for things that require judgment, relationship context, or access to things only the main session knows. But for a surprisingly large fraction of the work, the answer is: spawn a sub-agent, let it handle it, review the output.

That's a fundamentally different relationship with your agent stack. You're not driving it anymore. You're operating it.

The first time I checked my dashboard and saw 3 sub-agents had finished overnight, each having completed a separate research task, I felt something I'd never felt with a single-agent setup: the sense that I'd actually built a system, not just a tool.

**What I learned:** Delegation works best for isolated, well-defined tasks with clear inputs and outputs. It fails for anything requiring shared context or human judgment. Build result-logging into your sub-agent tasks from day one — you'll thank yourself when something breaks at 2 AM and you need to trace what happened where.