Parallel Specialist Lanes Guide

Parallel specialist lanes allow a single Gateway to distribute distinct chats or rooms across multiple agents without sacrificing responsiveness. Think of parallelism as a design challenge around limited resources, not simply a matter of adding more agents.

First principles

A specialist lane boosts throughput only when it eases pressure on the true constraints:

Session locks: at any moment, just one run should modify a given session.
Global model capacity: every visible chat run still competes for the same provider limits.
Tool capacity: shell, browser, network, and repository operations can take longer than the model turn itself.
Context budget: lengthy transcripts slow down each subsequent turn and reduce focus.
Ownership ambiguity: overlapping agents handling identical tasks waste capacity.

OpenClaw already serializes runs per session and restricts overall parallelism via the command queue. Specialist lanes layer policy on top: deciding which agent handles which work, what stays in chat, and what becomes background processing.

Recommended rollout

Phase 1: lane contracts + background heavy work

Each lane needs a written contract placed in its workspace and system prompt:

Purpose: the specific work this lane is responsible for.
Non-goals: tasks it should pass along rather than try to complete.
Chat budget: quick answers remain in chat; long jobs get a short acknowledgment, then execute in a background sub-agent or task.
Handoff rule: when another lane owns the work, indicate its destination and include a concise handoff summary.
Tool-risk rule: choose the minimal tool surface capable of finishing the job.

This phase costs the least and resolves most congestion: a single coding task no longer slows the research lane to a crawl, and each chat preserves its own clean context.

Phase 2: priority and concurrency controls

Adjust queue and model capacity according to the business value of each lane:

{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8, delegationMode: "prefer" },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      cap: 20,
      drop: "summarize",
    },
  },
}

Prioritize direct/personal chats and production-ops agents for high-priority work. When the system is under load, let research, drafting, and batch coding shift to background tasks.

Phase 3: coordinator / traffic controller

Once multiple lanes are running, introduce a small coordinator pattern:

Track active lane tasks and their owners.
Spot duplicate requests across groups.
Move handoff summaries between lanes.
Highlight only blockers, completed results, and decisions requiring human input.

Avoid starting here. A coordinator without lane contracts merely organizes chaos.

Minimal lane contract template

# 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.