What are roles and lanes, and why does a task need both?

Roles and lanes

A role is who does the work. A lane is where that role is allowed to touch. A task needs both before it can run beside another task, and the reason is not bookkeeping: without a lane, nothing stops two agents from editing the same file at the same time.

A role is a standing brief, not a label

A role carries four things, and they apply to every session that role opens:

Which CLI. This is a capability choice, not a preference. Codex ships imagegen and produces raster images; claude --help does not mention images once. An art-direction role on Codex does things the same role on Claude would not.
Which account and model. Blank inherits the project’s default.
A mandate. What this role is and how it decides. It goes into every one of its sessions, before the task. Without it, “art director” is a word on a screen.
A lane. The paths it owns.

The mandate is what makes roles worth having. “You own the HTTP layer. Prefer explicit errors over defaults. Never change a public signature without adding a test for the old shape” is a standing instruction you would otherwise retype in every session, and forget in half of them.

A lane is a set of paths

A lane is a list of path prefixes relative to the project root — src/api/, web/src/, docs/probe/. It is what the runner consults to decide whether two tasks can run at the same time, and it is the set a task inherits when it does not declare files of its own.

Only the lane protects. Two roles that write the same file collide exactly as two engineers would.

The same repository, three roles

For a small service, the split that works is usually the one your folders already suggest:


backend    src/api/
frontend   web/src/
tests      test/

Three roles, three lanes, no overlap. A task about the HTTP client is admitted in the backend lane; a task about the queue screen runs at the same time in the frontend lane; a task adding tests runs in the third.

Three fronts running at once, each pane headed by its role and its task

For something that isn’t a web service

The split follows the work, not the language. A game project splits by discipline, because the disciplines already own different folders:


gameplay     scripts/, scenes/player/
level        scenes/levels/
art          assets/sprites/, assets/tilesets/
audio        assets/audio/

Give the art role Codex, because it can generate raster assets; give gameplay whichever CLI you trust with logic. That is the whole point of the CLI being a property of the role.

What a role is not

It is not a permission system. A role with no lane is not restricted; it is unrestricted and serialised — it never runs beside anything.
It is not a personality. The mandate should say how the role decides, not how it talks.
It is not per-machine. Roles live with the project, so a role you declare once keeps working every time you open that project.

Declaring a lane is the practical half: how to pick the paths, and what a wrong lane costs you.