Engine lanes
A machine’s roster entry is not always exactly one agent. A machine can run CMDOP’s built-in engine, or drive a locally installed engine like Claude Code or Codex — and it can host more than one independently-configured agent identity on that same engine. Each one is called an engine lane.
A lane is a full correspondent: it has its own address, its own conversation history, its own unread badge, and its own role. Two lanes on the same machine and the same engine are two different workers you can hire separately — not two views of one worker.
Why more than one lane
A single machine is often shared work capacity. One Claude Code install on a machine can plausibly run a code-review persona and a release-notes persona at the same time, each with its own history and its own instructions, without either bleeding into the other’s context. Lanes are how Cmdop lets you hire both from the same installed engine instead of forcing one role per machine.
The machine’s own built-in agent works the same way: it is a lane too, just the one every machine starts with before you add any others.
How lanes appear
A machine’s roster entry expands into a row per lane once it reports more than one engine, or once you create an extra lane on an engine it already reports. A machine running Claude Code and Codex, for example, shows three rows: its built-in agent, Claude Code, and Codex. The machine row still answers where the work runs; each lane answers who is doing it.
Most lanes appear automatically — one per installed engine the machine reports, with no setup step. Creating an extra lane on an engine that already has one is a deliberate action you take from the console.
Creating a second lane
From a machine’s page in the console, add a lane on an engine that machine already runs. Give it a title and, optionally, a role — the same catalogue of roles you assign anywhere else. A lane created with no role still opens for work; it starts by asking what you need rather than answering as a nameless assistant.
Once created, a lane behaves like any other contact: message it, assign or reassign its role, rename it, or archive it when you are done. Archiving keeps its history and membership in any group room intact; it simply leaves the roster’s default view.
What a lane is not
- Not a sandbox. A lane changes identity and persona, not what the underlying engine or machine is permitted to do. Permissions are governed at the machine level — see Permissions.
- Not a copy of the machine. A lane has no separate files or execution authority of its own; it shares the machine’s files, tools, and project roots, the same as every other lane on that machine.
- Not required. Most machines never need a second lane — the one the engine reports automatically is enough. Lanes exist for the case where one installed engine is genuinely doing two people’s worth of distinct work.
Common questions
Can one machine have more than one AI worker?
Yes. A machine can host more than one agent identity on the same engine, each called an engine lane. Each lane is hired, addressed, and conversed with separately.
Do lanes on the same machine share history?
No. Each lane keeps its own conversation history and its own unread state, even when two lanes run on the same engine on the same machine.
Does creating a lane require a new install?
No. A lane is created on an engine the machine already runs. It does not install a second copy of the engine or require separate credentials.
Can a lane be removed?
Yes, from the console. Removing a lane can also remove its conversations, or you can archive it instead to keep its history while taking it out of the default roster view.
Cmdop