Agent delegation gets better when agents can branch, score options, and hand execution to deterministic tools instead of forcing everything through one linear prompt. The best clue came from an r/openclaw post where divergent thinking improved results, but raised cost by ~5x and latency by ~10x—great for planning, bad as a default for coding.
I clicked the “I gave OpenClaw ADHD” post expecting a meme.
Instead I found one of the clearest explanations of what’s broken in current agent design.
While researching agent delegation patterns, I came across a thread on r/openclaw where someone built what they called “ADHD - Parallel Divergent Ideation for Coding Agents.” The idea was simple and weirdly useful: don’t make OpenClaw think in one straight line. Make it explore multiple candidate thoughts, run a critic over them, and then keep the promising branches.
That sounds like a stunt until you notice it maps almost perfectly to Tree of Thoughts, the older research result that argued language models do better when they can explore, self-evaluate, and backtrack instead of marching left-to-right and hoping for the best.
And that’s the real lesson.
Not “write longer prompts.”
Not “add more agent personas.”
Not “make GPT-5 think harder.”
The useful next step is controlled divergence.
The funny post was accidentally making a serious point
The line that stuck with me from that thread was brutally honest:
“Limitation : It shoots cost by ~5x and time to output by ~10x but enables instant novel thinking. Good for brainstorming and planning, not for coding.”
That is such a better production insight than most polished agent demos.
Because now we have a real tradeoff instead of hand-wavy magic. Branching helps when the task is fuzzy, ambiguous, or strategic. Branching hurts when the task is obvious and execution-heavy.
That means the right design is not “always branch.” It’s branch selectively.
A commenter in the same thread said they’d installed the approach “on two different agents,” which tells you this idea is already escaping the original experiment. People can feel the limitation of the standard loop: prompt, think, act, repeat. It’s too linear for research and too expensive to brute-force forever.
And that raises the next question.
What problem are we actually solving?
Most agent failures do not come from lack of raw intelligence. They come from premature commitment.
The agent grabs the first plausible plan and starts digging.
If you’ve watched OpenClaw, AutoGen, LangGraph, or a homegrown n8n agent go sideways, you’ve seen this exact movie. The model picks one interpretation of the task, one search query, one file to edit, one API path to call. Then 20 steps later you realize it was confidently wrong on step 2.
A longer prompt does not fix that.
A bigger context window does not fix that.
A stern paragraph saying “consider alternatives carefully” definitely does not fix that.
What fixes it is giving the runtime permission to do something that good human operators do naturally:
- Generate a few plausible approaches
- Score them
- Kill the weak ones early
- Commit only when one path clearly wins
That’s basically Tree of Thoughts translated into agent engineering.
Linear loop vs branching runtime
| Approach | What it’s good at |
|---|---|
| Linear chain-of-thought agent loop | Single-path reasoning, lower cost and latency, straightforward execution |
| Controlled branching / Tree-of-Thought-style agent | Exploring alternatives, scoring and pruning, better for research and planning |
| Deterministic tool + delegated runtime architecture | Reliable production execution, permissions, batching, retries, and long-running workflows |
That table is the whole argument, honestly. The mistake is treating these as rivals when they should be stacked.
Use branching for thinking.
Use deterministic infrastructure for doing.
But the second half matters even more than people think.
Why “more agent” is often the wrong answer
While I was reading the ADHD thread, I found another r/openclaw discussion from a team using OpenClaw for compliance, DevOps, and finance. Their post was the perfect counterweight to the branching hype.
They wrote:
“Generic MCP servers that wrap vendor APIs don't scale in production. The model ends up doing the integration work: call this endpoint, paginate, retry, handle errors, loop 1000 times.”
That sentence should be taped to the monitor of anyone building agents for real workflows.
Because once you see it, you can’t unsee it. A lot of “AI agent framework comparison” debates are really arguments about where logic should live. Should Claude or GPT-5 be deciding every retry, every pagination cursor, every batch boundary, every permission check?
No. Absolutely not.
That team’s answer was much saner. OpenClaw handled teams, webhooks, routing, and sessions. Credentials stayed out of model context. Each agent got a tight tool list. And for runtime, they wired in cursor-agent through ACPX because, in their words, it holds up better for “long tasks, subagent spawning, and staying on track than a generic agent loop.”
That’s not multi-agent theater. That’s architecture.
A production shape that actually makes sense
OpenClaw -> ACPX -> cursor-agent
models:
providers:
local-qwen:
timeoutSeconds: 120
That models.providers.<id>.timeoutSeconds setting showed up in another OpenClaw troubleshooting thread for slow local and self-hosted providers. Tiny detail, but revealing. Real teams are not just prompting models. They are managing runtimes, timeouts, sessions, permissions, and failure modes.
Which is exactly why branching alone is not enough.
So where should branching actually happen?
Here’s my opinionated version: branch on uncertainty, not on everything.
If the task is open-ended, branch.
If the task is operational, constrain.
If the task is repetitive, deterministic, and permission-sensitive, get the model out of the weeds and let purpose-built code do the work.
Good places to branch
- Research questions with multiple plausible answers
- Planning a migration or architecture change
- Investigations where the first hypothesis is usually wrong
- Safety analysis, red-teaming, and policy review
- Early-stage coding design before implementation starts
Bad places to branch
- Sending 1000 BoldSign documents
- Paginating through a vendor API
- Retrying failed webhook deliveries
- Audio transcription pipelines
- Applying a known code change across a repo
That last one matters. In an OpenClaw audio transcription discussion, one commenter argued against routing transcription through a general coding or reasoning agent at all. They recommended a dedicated audio step that OpenClaw orchestrates.
Exactly right.
Use the agent to choose and coordinate. Don’t force it to brute-force every subproblem through one giant reasoning loop.
And now we get to the part nobody likes talking about.
Who can afford all this branching?
Branching is intellectually attractive and economically annoying.
The viral OpenClaw post had a score of 119, which makes sense because people instantly recognized the behavior. But they also recognized the bill. The author said the divergent approach increased cost by approximately 5x and time to output by approximately 10x.
That is not a rounding error. That is an architectural decision.
OpenClaw users have been pretty open about this pressure. I kept finding threads asking things like “How much do you spend on API fees per month?” or how to track Claude Opus token spend across customers. Once you add branching, every uncertain step can fan out into a small invoice.
That changes agent routing decisions.
A lot of teams say they want smarter agents. What they really mean is they want smarter agents without paying for five versions of every thought. That’s why selective branching matters so much. You need a gate:
- branch only on high-uncertainty tasks
- cap branch width
- prune aggressively
- switch to deterministic tools as soon as the plan is chosen
If you don’t do that, your “clever” agent becomes a very expensive brainstorming partner that still can’t reliably ship work.
Is this just multi-agent hype with better branding?
I don’t think so.
Most multi-agent demos are basically one model wearing fake mustaches. Researcher agent. Critic agent. Planner agent. Reviewer agent. Same loop, same context, same mush.
What’s more interesting in these OpenClaw threads is separation of concerns.
The enterprise recipe post describes a stack where OpenClaw handles channels and sessions, custom MCP services expose locked-down business actions, and Cursor CLI acts as the runtime because it deals better with long tasks and subagent spawning. That is real agent delegation.
Not “pretend there are five experts in the room.”
Actual delegation means:
- one component explores options
- another scores or selects
- another executes with narrow permissions
- another handles retries, batching, and error recovery
That’s a much better direction than stuffing more personas into a prompt and calling it orchestration.
The design rule I wish more agent builders used
If I had to compress all of this into one rule, it would be this:
Branch for thinking. Constrain for execution. Delegate by boundary, not by vibe.
That rule explains why Tree of Thoughts still matters.
It explains why the “I gave OpenClaw ADHD” post was more insightful than it looked.
It explains why Cursor CLI can outperform a generic loop on long tasks.
And it explains why so many agent systems feel smart in a demo and flaky in production. They are trying to solve planning, execution, retries, permissions, and recovery inside one undifferentiated prompt-shaped blob.
That blob has reached its limit.
The next useful jump in agent design probably won’t come from a dramatically better paragraph in your system prompt. It’ll come from runtimes that know when to split into branches, when to spawn a subagent, when to call a deterministic service, and when to stop thinking and just do the work.
That’s the weirdly useful lesson hiding inside a joke Reddit title.
And honestly, it’s a good one.