Why Your Agents Run One-by-One (And How to Enable Parallel Processing)

If you've set up multiple agents in OpenClaw and noticed they process requests sequentially instead of in parallel, you're not alone. This is one of the most common questions from users running multi-agent setups.

The Problem

You have multiple agents (maybe in separate Telegram chats or Discord channels), and when you send messages to several at once, they seem to queue up and respond one after another instead of simultaneously.

Why This Happens

This "one-by-one" behavior is Gateway-side, not a limitation of the underlying model. OpenClaw intentionally runs inbound agent turns through an in-process command queue with two important rules:

1. Per session: Always serialized — only one active run can touch a given session at a time
2. Across sessions: Can be parallel, but capped by agents.defaults.maxConcurrent

The key insight: if maxConcurrent is set to 1 (the default in some configurations), everything will look strictly sequential — even if your agents are in completely separate sessions.

The Fix

Check your current concurrency setting:

openclaw config get agents.defaults.maxConcurrent

If it's low (or 1), bump it up:

openclaw config set agents.defaults.maxConcurrent 8
openclaw gateway restart

Start with 4-8 for most setups. You can go higher if your hardware and API rate limits allow.

Telegram-Specific Note

Telegram's long polling uses the grammY runner with per-chat sequencing — this is intentional to prevent message ordering issues within a single chat. The overall runner "sink concurrency" is controlled by agents.defaults.maxConcurrent. Different chats (different session keys) can run in parallel once you increase this setting.

Still Sequential After Increasing?

If maxConcurrent is already >1 and you're still seeing sequential behavior, check for:

• Provider rate limits — You might be hitting 429 errors and triggering backoff
• CPU saturation — Your machine might be bottlenecked
• Same session — If agents share a session, they must run sequentially

Check your gateway logs around a burst of requests:

openclaw logs --follow

Look for "queued for …ms" or retry/backoff lines — these are dead giveaways.

For True Parallel Work Within One Conversation

If you want parallel execution within a single conversation (not just across separate chats), look into sub-agents. They can spawn parallel tasks and return results to the main conversation.

Docs:

• Queue/concurrency behavior
• Sub-agents

Sourced from the OpenClaw Discord #help channel. Thanks to JungleWorm for the question!