OpenClaw subagents are one of the most powerful features in the platform. Spawn a child agent, hand it a task, and let it run while the main agent keeps moving. In theory, it is clean and efficient. In practice, there are a handful of mistakes that come up repeatedly that waste tokens, break workflows, or produce unreliable results.
This post covers the seven most common ones. If you have tried openclaw subagents and hit a wall, one of these is probably why.
1. Polling in a Loop Instead of Using sessions_yield
This is the biggest one, and it is more destructive than it looks. When a main agent spawns a subagent and then immediately starts calling subagents list or sessions_list in a loop to check if it is done, you are burning tokens on every single poll. Dozens of API calls. Hundreds, if the subagent takes time. That is real money and wasted context window.
The right approach is to call sessions_yield after spawning. This suspends the current turn cleanly and lets the runtime push the result back when the subagent finishes. Completion is push-based, not pull-based. The subagent announces when it is done. You do not need to ask repeatedly.
If you find yourself writing a loop that checks status every few seconds, stop. That pattern belongs to a different era of task management. In OpenClaw, yield and wait for the push event.
2. Using context:”fork” When You Do Not Need It
When you spawn a subagent with context:"fork", the child receives the entire parent session transcript. Every message, every tool call, every result. That can easily add up to thousands of tokens before the child has done a single thing.
For most tasks, the subagent does not need that history. It needs a clear task description. That is it. Use isolated context (the default, or context:"isolated") and pass only what is relevant as structured input in the task prompt.
Fork context is appropriate when the child genuinely needs to understand the conversation that led to the task, for example when handling a nuanced follow-up that depends on earlier decisions. For focused subtasks like research, writing, or API calls, isolated is almost always the right choice.
3. Not Setting runTimeoutSeconds
A subagent with no timeout set can run indefinitely. If something goes wrong inside the child, if it hits a loop, a stuck tool call, or a model that is taking forever, you will not know until the session costs spiral or the platform cuts it off on its own terms.
Set runTimeoutSeconds on every subagent spawn. Be deliberate about it. A research task might need 60-120 seconds. A simple data fetch should complete in 15-20. If you do not know how long it should take, that is a signal to break the task into smaller pieces.
Timeouts are not pessimistic. They are a contract. You are saying: if this is not done in X seconds, something is wrong and I want to know about it.
4. Treating Subagent Results as Trusted
Subagent output is generated content. It can contain errors, hallucinations, or in adversarial scenarios, injected instructions. If a subagent is scraping web content, summarizing external documents, or processing user-supplied text, the result is untrusted by default.
Do not pipe subagent results directly into consequential actions without review. If the child says “delete these files” or “post this to the API,” the parent should verify that the instruction makes sense before acting on it.
This is especially relevant when you are building agentic pipelines that touch external systems. One poisoned input can propagate through the whole chain if you are not checking at each step. Treat subagent output the way you would treat user input: validate before acting.
5. Spawning Too Many Subagents at Once Without Coordination
Parallel subagents are great. Spawning ten at once without a plan for handling their results is not. You end up with a pile of completion events, no clear ordering, and a main agent that has to reconcile potentially conflicting outputs with no structure to work from.
When you use openclaw spawn subagents in parallel, keep the count manageable. Three to five parallel agents with distinct, non-overlapping tasks is reasonable. More than that and you are creating coordination overhead that often outweighs the parallelism benefit.
If you need fan-out at scale, structure it in waves. Spawn a first batch, wait for results, then spawn the next batch based on what came back. That gives you control without losing the speed advantage.
6. Using an Expensive Model for Simple Subtasks
Not every subagent needs Claude Sonnet or GPT-4. If you are spawning a child to do a web search and summarize three sentences, that task does not require your most capable model. Using it anyway is a cost blowout that compounds fast when you are running multiple subagents per workflow.
Match the model to the task. Research, simple writes, data extraction, and format conversion work fine on lighter models like GPT-4o Mini or Haiku. Reserve the heavy models for reasoning-intensive tasks: complex decision trees, nuanced analysis, multi-step planning.
OpenClaw lets you specify the model per subagent. Use that. A hybrid approach where the orchestrator runs on a capable model and the workers run on cheaper ones is how you keep costs sane at scale.
7. Ignoring the Child Result or Reading It Wrong
Subagent results come back as completion events. If your main agent is not reading them properly, you lose the output entirely. This happens more than you’d expect, especially when agents are built by iterating quickly without testing the full round-trip.
Common failure modes: the parent checks the wrong field in the result object, assumes the result is always a string when it might be structured JSON, or skips error handling so a failed subagent silently passes through as success.
Always read the completion event explicitly. Check for error states. If the subagent failed, handle it – retry, fall back, or surface the error to the user. Do not assume that because the subagent finished, the result is valid. Finish and success are not the same thing.
Ampere.sh is built for running AI agents around the clock. Fast ARM servers, low cost, and no config headaches. It is how most serious OpenClaw users keep their agents always on.
FAQ
What is the difference between isolated and fork context in OpenClaw subagents?
Isolated context (the default) gives the subagent only what you explicitly pass in the task prompt. Fork context copies the entire parent session transcript into the child. Use isolated for focused tasks and fork only when the child genuinely needs full conversation history to do its job.
How do I stop a subagent from running forever?
Set runTimeoutSeconds when you spawn the subagent. This caps how long the child can run before the platform terminates it. Pick a value based on what the task actually requires and treat any timeout as a signal to investigate.
Is polling subagent status really that costly?
Yes. Each poll is an API call that costs tokens and counts against your rate limits. If a subagent takes 60 seconds and you are polling every 5 seconds, that is 12 unnecessary calls. Across multiple subagents and multiple workflows, this adds up quickly. Use sessions_yield instead.
Can subagents in OpenClaw spawn their own subagents?
Yes, but there are depth limits. OpenClaw enforces a maximum subagent nesting depth to prevent runaway recursion. Check the platform docs for current limits. In practice, most workflows only need one or two levels of nesting before coordination costs outweigh the benefits.
How many OpenClaw subagents can I run in parallel safely?
There is no hard rule, but three to five parallel subagents is a practical ceiling for most workflows. Beyond that, managing results, handling failures, and reconciling outputs becomes complex enough to cause more problems than the parallelism solves. Start small and scale up as you understand the pattern.
For more on this, check out our guide on step-by-step guide to spawning subagents.
Final Thoughts
OpenClaw subagents are genuinely useful when used correctly. The mistakes above are not obscure edge cases – they are patterns that show up in real workflows built by people who are trying to move fast. Fixing them is mostly about slowing down slightly at the design stage and being explicit about context, timeouts, model selection, and result handling.
If you are still getting up to speed with the basics, start with the OpenClaw subagents guide before building multi-agent pipelines. Getting the fundamentals right makes the mistakes above much easier to avoid. And if you run into issues with OpenClaw losing context between sessions, that is a different but related problem worth understanding before you start delegating work to child agents.
Not Ready to Self-Host? Try ClawTrust
Building agents locally is powerful, but managing infrastructure, security, and scaling takes effort. ClawTrust provides managed OpenClaw hosting — your agents run securely in the cloud with automatic scaling, no DevOps overhead, and 24/7 monitoring.
This post contains affiliate links. If you buy through them, I may earn a small commission at no extra cost to you.
About The Author
The polling loop mistake is real. I spent an embarrassing amount of time wondering why my session was burning tokens before I figured out what was happening. sessions_yield is not obvious when you first start out.
Glad it clicked. That one trips up almost everyone at first. The mental model shift from polling to push-based completion takes a bit, but once it lands you start seeing how much cleaner the whole workflow becomes.
The polling loop mistake is something I ran into on day one. I had a subagent doing a long web scrape and I was checking status every 3 seconds. My token count at the end of the session was embarrassing. Switching to sessions_yield fixed it immediately. Wish this was in the docs more prominently.
That is one of the most common first-week mistakes. The polling habit comes from how most people have written async code before, but the push model in OpenClaw is genuinely different. Once it clicks, you do not go back. Glad sessions_yield sorted it for you.
Number 6 about using expensive models for simple subtasks is something I needed to read. I was running Sonnet on every single subagent and wondering why costs were climbing. Switched research tasks to a smaller model and it made a big difference.
Thanks for reading, Rania Aziz. On 7 Common OpenClaw Subagent Mistakes, I would start with the basics and then tighten things up once you see how it behaves in practice. If you are already testing it, the main thing is to keep the setup simple enough to debug quickly.
Good breakdown. One thing I would add to the list is not labeling subagents. When you have several running and something goes wrong, tracking down which one failed without a label is painful.
That is a great addition, Kieran. The label parameter in sessions_spawn is easy to overlook but it makes a huge difference when you are managing more than two or three subagents at once. Might add that as mistake number 8.
Quick question on mistake 4, treating subagent results as trusted. If I am spawning subagents to process data I control (not user input or external content), is validation still necessary? Or is the risk mainly when external content is involved?
Great question. The risk is definitely higher with external or user-supplied content, but even with data you control, subagent output can include model errors or misformatted results. At minimum, check that the result structure matches what you expected before acting on it. A quick schema check goes a long way.
The model cost point hit home. I was running a pipeline with 6 parallel subagents, all on Sonnet, doing tasks that were basically just fetch-and-summarize. Switched 4 of them to Haiku and the cost dropped by about 60 percent with no noticeable quality difference. Should have caught this sooner.
60 percent is a solid saving. Fetch-and-summarize is exactly the kind of task where lighter models perform just as well. The key is identifying which steps in the pipeline actually need heavy reasoning and which are just pattern-following work. Sounds like you have that figured out now.