Orchestration is more than starting sessions. It is deciding what runs, in what order, and wiring the results back. Lanes gives you a board to orchestrate by hand and Lanes Desktop MCP to orchestrate from inside an agent.
How Lanes does it
- A board, not a queue. Plan work as issues, start a session per issue, and drag cards through plan, implement, review, and done. The issue board is the shared state every agent and every human can see.
- Agents that dispatch agents. The Lanes MCP server lets an agent manage the board and spawn sessions itself. Tell one agent to dispatch three more. The Lanes Desktop MCP server is built into the app, runs as SSE on
localhost:5353under the namelanes-desktop, and exposes 30 tools: 18 for the workspace plus 6 each for GitHub and Linear once those are connected. - Quick commands. Inject preset prompts into any session in one click. Quick commands are per-repo, typed as either Claude prompts or raw terminal commands, bound to Cmd+Alt+1 through 9, and they run inside the issue's worktree.
- Safe at scale. Every session is isolated in its own worktree, so orchestrating many at once never corrupts your repo.
Through MCP, an agent can list and search issues, create and move them, start a session in plan mode or with a custom prompt, tie it to a freshly created worktree, then read its terminal scrollback and session stats to answer "how is this issue going" on its own. Ordering comes from dependencies: the graph is a DAG with cycle detection, and the queue manager skips blocked issues, so a chain of issues in the backlog executes in the right order without a human sequencing it.
Sessions support an orchestration pattern of their own. Since v0.41 one issue can host several named sessions sharing the same worktree: one plans, one implements, one reviews, each with its own transcript and metrics.
Why it matters
What used to take a workflow now takes a sentence. You keep oversight of the whole fleet while the agents handle the wiring.
The chains are the interesting part: an agent that reads the backlog, picks the next ticket by label, starts a session in a worktree, and reports back when it gets blocked. Every step of that is an MCP tool call against the board you are already looking at.
Set it up
- Enable the server. In Lanes, open Settings, then Local MCP, and toggle it on. The server ships as a research preview.
- Connect your agent. One-click buttons write the
lanes-desktopentry for Claude Code or Codex; any other MCP client can point at the SSE endpoint on port 5353 manually. - Restart the agent and ask it something like "what is on my plate in Lanes" to confirm the tools are live.
- Give it work. "Create issues for these three refactors, add dependencies, and start the first one in plan mode" is a valid instruction.
The local server is one of three Lanes MCP servers. The MCP overview explains how lanes-desktop, the hosted lanes server, and the self-hosted lanes-link endpoint differ and why they never collide.
Where this breaks without Lanes
Multi-agent setups without a shared workspace tend to become scripts: one process spawns others, state lives in log files, and nothing shows you what is running or why. When a step fails you reconstruct the plan from stdout. With the board as shared state, dispatch stays inspectable: every agent-created issue, session, and status change is a card you can click.
Further reading
- Lanes Desktop MCP: the tool surface, connect flow, and example prompts.
- MCP overview: the local and remote servers and when to use each.
- Dependencies: DAG ordering and the queue manager.
- Working with sessions: several named sessions on one issue.
- An issue board for AI agents: the board that orchestration runs on.