mirror of
https://github.com/openclaw/openclaw.git
synced 2026-07-18 15:11:40 +00:00
f7d7148cf0
Source-grounded rewrite of 529 published docs pages with per-unit information-loss verification: 1,713 factual corrections cited to src/**, generated surfaces regenerated, frontmatter titles preserved for i18n, release notes pages untouched. All docs gates green. Closes #100141
129 lines
3.7 KiB
Markdown
129 lines
3.7 KiB
Markdown
---
|
|
summary: "Run parallel specialist agents without clogging shared model and tool capacity"
|
|
title: "Parallel specialist lanes"
|
|
sidebarTitle: "Specialist lanes"
|
|
read_when:
|
|
- You route group chats to dedicated agents
|
|
- You want parallel work without one long task blocking every chat
|
|
- You are designing a multi-agent operations setup
|
|
status: active
|
|
---
|
|
|
|
Parallel specialist lanes let one Gateway route different chats or rooms to
|
|
different agents while keeping the user experience fast. Treat parallelism as
|
|
a scarce-resource design problem, not just "more agents".
|
|
|
|
## First principles
|
|
|
|
A specialist lane only improves throughput when it reduces contention for the
|
|
real bottlenecks:
|
|
|
|
- **Session locks**: only one run should mutate a given session at a time.
|
|
- **Global model capacity**: all visible chat runs still share provider limits.
|
|
- **Tool capacity**: shell, browser, network, and repository work can be slower
|
|
than the model turn itself.
|
|
- **Context budget**: long transcripts make every future turn slower and less
|
|
focused.
|
|
- **Ownership ambiguity**: duplicate agents doing the same job waste capacity.
|
|
|
|
OpenClaw already serializes runs per session and caps global parallelism
|
|
through the [command queue](/concepts/queue). Specialist lanes add policy on
|
|
top: which agent owns which work, what stays in chat, and what becomes
|
|
background work.
|
|
|
|
## Recommended rollout
|
|
|
|
### Phase 1: lane contracts + background heavy work
|
|
|
|
Give every lane a written contract in its workspace and system prompt:
|
|
|
|
- **Purpose**: the work this lane owns.
|
|
- **Non-goals**: work it should hand off instead of attempting.
|
|
- **Chat budget**: quick answers stay in chat; long tasks acknowledge briefly,
|
|
then run in a background sub-agent or task.
|
|
- **Handoff rule**: when another lane owns the work, say where it should go and
|
|
provide a compact handoff summary.
|
|
- **Tool-risk rule**: prefer the smallest tool surface that can do the job.
|
|
|
|
This is the cheapest phase and fixes most clogging: one coding job no longer
|
|
turns the research lane into molasses, and each chat keeps its own context
|
|
clean.
|
|
|
|
### Phase 2: priority and concurrency controls
|
|
|
|
Tune queue and model capacity around the business value of each lane:
|
|
|
|
```json5
|
|
{
|
|
agents: {
|
|
defaults: {
|
|
maxConcurrent: 4,
|
|
subagents: { maxConcurrent: 8, delegationMode: "prefer" },
|
|
},
|
|
},
|
|
messages: {
|
|
queue: {
|
|
mode: "collect",
|
|
debounceMs: 1000,
|
|
cap: 20,
|
|
drop: "summarize",
|
|
},
|
|
},
|
|
}
|
|
```
|
|
|
|
Use direct/personal chats and production-ops agents for high-priority work. Let
|
|
research, drafting, and batch coding move to background tasks when the system is
|
|
busy.
|
|
|
|
### Phase 3: coordinator / traffic controller
|
|
|
|
Add a small coordinator pattern once multiple lanes are active:
|
|
|
|
- Track active lane tasks and owners.
|
|
- Detect duplicate requests across groups.
|
|
- Route handoff summaries between lanes.
|
|
- Surface only blockers, completed results, and decisions the human must make.
|
|
|
|
Do not start here. A coordinator without lane contracts just coordinates chaos.
|
|
|
|
## Minimal lane contract template
|
|
|
|
```md
|
|
# Lane contract
|
|
|
|
## Owns
|
|
|
|
- <job this lane is responsible for>
|
|
|
|
## Does not own
|
|
|
|
- <work to hand off>
|
|
|
|
## Chat budget
|
|
|
|
- Answer quick questions directly.
|
|
- For multi-step, slow, or tool-heavy work: acknowledge briefly, spawn/background
|
|
the work, then return the result when complete.
|
|
|
|
## Handoff
|
|
|
|
If another lane owns the request, reply with:
|
|
|
|
- target lane
|
|
- objective
|
|
- relevant context
|
|
- exact next action
|
|
|
|
## Tool posture
|
|
|
|
Use the smallest tool surface that can complete the task. Avoid broad shell or
|
|
network work unless this lane explicitly owns it.
|
|
```
|
|
|
|
## Related
|
|
|
|
- [Multi-agent routing](/concepts/multi-agent)
|
|
- [Command queue](/concepts/queue)
|
|
- [Sub-agents](/tools/subagents)
|