Last Tuesday my agent took 14 minutes to do something it used to do in 3. The transcript was a wall of repeated context. It was re-reading the same 40,000 tokens on every turn because I'd been piling tasks into one session for months.
The fix was embarrassingly simple: stop trying to run everything through one agent.
I split the workload across three sub-agents running in parallel. Response time dropped to under 90 seconds. Token use per task fell by roughly 60%. And the main agent stopped hallucinating explanations for things that happened three hours ago in the same session.
Here's exactly what I changed and why it works.
The Problem: Context Accumulation Kills Agent Performance
Every OpenClaw session has a context window. As the session grows with history, the model has to process more tokens on every single turn. This has three compounding effects:
- Latency climbs — more tokens means longer inference
- Cost per task rises — you're paying to re-read everything every turn
- Reliability drops — models get distracted by their own history and start mixing up what happened when
I noticed it first on a research task. The agent was supposed to gather data on five competitors, summarize each, and write a comparison brief. What I got was a 20-minute run that somehow missed two competitors entirely and doubled back on a third. The transcript showed it getting confused about which research was already done.
This isn't a model intelligence problem. It's an architecture problem.
The Fix: Isolate and Delegate with Sub-Agents
OpenClaw lets you spawn clean child sessions — sub-agents — that run independently, each with fresh context. The main agent delegates a specific task, the sub-agent handles it in isolation, and then returns only the result.
This is not the same as a tool call. A tool call runs in the same session. A sub-agent runs in its own session with its own context window, its own model selection, and its own tools. When it finishes, it hands back a result. The main session only sees the answer — not the 80 intermediate steps to get there.
The pattern looks like this:
// Spawn a research sub-agent for one competitor
sessions_spawn({
task: `Research ${company_name}. Return a 200-word summary covering:
- What they do
- Their pricing model
- Key differentiators
Use web search to find current information.`,
taskName: `research-${company_name.toLowerCase().replace(/\s+/g, '-')}`,
runtime: "subagent",
mode: "run",
cleanup: "delete"
})
Each sessions_spawn call fires in parallel. While all five competitor-research sub-agents are running, the main agent is free — not blocked, not burning tokens on context bloat. When they return, the main agent gets five clean summaries and writes the comparison brief.
No repeated context. No confusion about what's done.
What I Actually Run This Way
After a week of splitting tasks across sub-agents, here's my current breakdown:
| Task | Agent Type | Why |
|---|---|---|
| Inbox triage, daily digest | Main agent | Needs full conversation history |
| Competitor research (per company) | Sub-agent | Isolated, parallel, no history needed |
| Code review / PR analysis | Sub-agent | Fresh context per repo |
| Long-form content drafts | Sub-agent | Isolation prevents tone drift |
| Real-time monitoring / alerts | Main agent | Needs immediate context |
The rule I landed on: if a task requires looking at more than 10 files, or will take more than 5 tool calls to complete, it goes to a sub-agent. Everything else stays in the main session.
The Results After One Week
The numbers from my OpenClaw dashboard:
- Average task latency: down from 11.3 minutes to 2.1 minutes (parallelism + isolation)
- Token use per research task: down ~58% — no more re-reading 40k-token histories
- Error rate on multi-step tasks: dropped from 23% to 4%
- Sub-agents spawned per day: averaging 14 across all task types
The error rate drop surprised me most. When each sub-agent has fresh context, it doesn't inherit the main session's accumulated confusion. A sub-agent researching Company X doesn't know that the previous three research calls were for Companies A, B, and C. It's focused.
One Gotcha to Watch
Sub-agents don't share memory with the main session. If you need a sub-agent to know something, you have to pass it explicitly in the task prompt. I learned this the hard way when a code review sub-agent had no context for what the project actually was, and spent the first three tool calls trying to figure out the repo structure.
The fix is simple: include a brief context block at the start of every sub-agent task.
task: `Context: You are reviewing PR #${pr_number} for the ${repo_name} project.
The main branch is 'main'. This PR changes the auth module.
[additional relevant context]
Your task: ${review_task}
Return your findings in this format:
- Issues found
- Suggestions
- Approval recommendation`
What This Changes About How You Design Agent Workflows
The traditional approach is: one agent, many tools, long sessions. That works until it doesn't.
Sub-agent delegation changes the design question. Instead of "how do I give this agent more capabilities?" the question becomes "what are the independent workstreams, and how do I hand each one to the right context?"
It's closer to how a good engineering team operates: specialists with clear scopes, handing off outputs to a coordinator. The main agent is the coordinator. Sub-agents are the specialists.
If your main agent is slowing down, getting expensive, or making errors because of context confusion, the answer isn't a better model — it's probably better architecture. Start by isolating one task type and running it as a sub-agent. You'll see the difference in the first run.
I'm running 14 sub-agents a day across various task types. If you're doing something similar — or differently — I'd like to hear what architecture choices have worked for you.
Top comments (0)