Paperclip and Lanes both orchestrate multiple agents, but at different altitudes. Paperclip is an open-source control plane for running a whole company of agents across engineering, marketing, sales, and operations, with org charts, budgets, and an audit log. Lanes is a developer workspace for running coding agents in parallel with git worktrees and a coding loop.
This page is about picking the right altitude, not a winner.
At a glance
| Dimension | Lanes | Paperclip |
|---|---|---|
| Scope | Parallel coding agents | A company of agents across all functions |
| Model | Issue board, worktrees, sessions | Org chart, goals, budgets, audit log |
| Agents | Official Claude Code and Codex CLIs | Agent-agnostic (Claude, Codex, Gemini, and more) |
| Focus | Ship code | Coordinate agents to run a business |
| Ordering | Labels and a dependency graph on one board | Goals and budgets across an org |
| Hosting | macOS app, local-first | Open source, self-hosted |
| Docs | Lanes Desktop docs | Paperclip's own docs |
Where Lanes fits
Lanes is for developers who want to ship code with several agents at once. Each task is an issue, each session runs the official CLI in its own worktree, and the whole loop from plan to pull request happens in one place. It goes deep on the coding workflow rather than broad across business functions.
Deep means the mechanics are handled. Work is planned on an issue board and kept findable with labels when dozens of issues are in flight. Dependencies link issues into a graph with cycle detection, so blocked work waits and queued work starts in a valid order without a human sequencing it. A session is the official CLI in a real terminal with live status on its card, and each issue runs in a worktree that Lanes creates off the base branch and cleans up when the issue completes.
Where Paperclip fits
Paperclip is for coordinating many agents across a whole organization, with governance, budgets, and reporting. If your goal is an agent org that spans more than engineering, Paperclip is aimed at that. Governance at that altitude is its own product problem, and Lanes does not try to solve it.
How Lanes does it
- A board with real structure. Columns from Backlog to Done, labels for filtering a busy board, and a dependency graph the queue respects: blocked issues are skipped until their prerequisites land in Done. See dependencies.
- Sessions are real terminals. Each is a PTY running the official CLI, started in Plan or Implement mode with the issue's instructions as the initial prompt, reporting Busy, Awaiting input, Stopped, Exited, or Error, with tokens, cost, and runtime in the Meta tab. See working with sessions.
- Agents can drive it too. Lanes Desktop MCP, a research preview built into the app, exposes 30 tools over SSE on localhost port 5353, so an orchestrating agent can read the board, create issues, and start sessions. See Lanes Desktop MCP.
Choose Lanes if
- Your work is shipping code with parallel coding agents.
- You want git worktrees, a board, and a tight coding loop.
- You want labels, dependencies, and per-issue isolation without running a platform.
Choose Paperclip if
- You want to coordinate agents across many business functions with governance.
- You want engineering to be one department among several that agents run.
The two are not exclusive: Paperclip could run the company while Lanes is where the engineering agents do the coding.
Further reading
- Quick start: install Lanes and run your first session in about two minutes.
- The issue board: columns, bulk actions, and board tabs.
- Dependencies: the graph, cycle detection, and queue behavior.
- Multi-agent coding orchestration: dispatching agents from one board.
See Lanes Desktop or read the quick start.