Parallel specialist lanes

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.

Apus already serializes runs per session and caps global parallelism through the command queue. Specialist lanes add policy on top: which agent owns which work, what stays in chat, and what becomes background work.

Recommended rollout

For a ready-made starting point, apus agents team create ships these lane contracts as coordinator, researcher, writer, and reviewer roles. Each role puts its scope, artifact handoff, approval gates, and escalation rules in AGENTS.md. The preset wires the coordinator to the specialists and instructs specialists to return results without further delegation. See Team preset.

Phase 1: lane contracts + background heavy work

Give every lane a written contract in its agent workspace AGENTS.md, which is loaded into the system prompt at the start of every session:

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:

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

maxConcurrent caps the shared main lane; subagents.maxConcurrent gives each spawning session its own child execution budget.

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. subagents.delegationMode is prompt guidance only; see sub-agent delegation for what each value does, and command queue for mode, cap, and drop.

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

Save this in the lane agent's workspace AGENTS.md: