Roles: who plans, who manages, who builds

One session is easy to follow. The trouble starts around the third: you gave one of them the plan, another is grinding through a refactor, a third is running errands for the second - and every card on the rail looks the same. Roles fix the reading problem. The method has five - Standalone, Architect, Manager, Worker, and Reviewer - and each session carries one word that says its place in the work. DevThrottle records the first four today, and works most of them out for you.

About ten minutes. You need a Gateway, the DevThrottle command line, and at least one running session - start one if nothing is running.

1. Look at what you have - and notice the silence

   Open the Director and look at the session rail, or open the fleet map in the Cockpit. Unless a session is already supervising another - or already wears a role someone declared - you will see no role anywhere: no badge on the rail, no role word on the cards.

   That silence is the design. Every undeclared session starts as Standalone - working alone, facing you - and Standalone shows no badge, so a fleet of solo sessions stays quiet. A role only appears when it says something: someone plans, someone supervises, someone builds - or someone declared it.

2. Declare the planner

   One role never appears on its own: Architect, the session that settles the design and directs the rest. DevThrottle can work out who supervises whom by watching the wiring, but nothing in the wiring says which session is the planner - so the Architect is the one role you must declare yourself. Start a session as one:

   An Architect at birth

   cc-devthrottle session spawn D:/work/my-repo --role architect --name "Checkout flow - Architect" --prompt "Plan the checkout rework. Settle the design and the phases before anything is built."

   Or promote a session that is already running - it defaults to the session you are in, or name a target:

   An Architect after birth

   cc-devthrottle session role <session-id> architect

   On the Director rail the session now carries a small A badge (hover it for the full word); on the fleet map its card says Architect. Notice it is there already, before this session supervises anyone: a declared role wins from birth, not from the wiring. It is also sticky - it stays until you clear it with cc-devthrottle session role <session-id> none.

3. Hand work down and watch the roles appear

   Now the part you never set by hand. Ask any running session to hand a piece of work to a fresh session - prompt it with something like "spawn a helper session in this repository to write the migration script, and collect its answer". From inside a session, the spawn command it runs defaults to starting the new session supervised by the one that spawned it.

   The moment that happens, the Gateway resolves both ends. The new session shows as a Worker (a W on the rail). Your planner keeps its A: a declared Architect that hands work down stays an Architect, so do not look for an M here. The Manager badge is what an undeclared spawner earns - any session with no declared role of its own shows as a Manager while it has a live supervised session under it, whatever role that session itself wears - and when the last one ends, the badge goes with it. Derived roles track the live work, not history.

   On the fleet map, a Worker's card nests under its Supervisor when both sit in the same lane of the grouping you have chosen - group by machine, and a Worker tucks under its Supervisor on that machine's lane. A Worker whose Supervisor sits in a different lane renders as a root of its own lane instead; the nesting never reaches across lanes.

   Note

   Two different edges connect sessions, and only one drives any of this. The Supervisor is the live relationship that roles and colours are computed from. The Parent - who started the session - is plain history and changes nothing on screen. They usually coincide, but a session can start a peer for you with --standalone: that peer has a Parent and no Supervisor, faces you, and wears no Worker badge even though an agent started it.

4. Read the colours through the roles

   Roles change what the colours mean, and this is the point of the whole arrangement. A Standalone, Manager, or Architect that needs input turns red - those sessions face you, so their red is your business. A Worker's red is its Supervisor's business - and that Supervisor need not be a Manager; a Worker can answer directly to an Architect. A waiting Worker under a live Supervisor never turns red at all. It recedes to a quiet slate - the Cockpit's fleet-map legend calls that colour Sub-agent - and its Supervisor deals with it while you get on with your day.

   There is an escape hatch, with one deliberate exception. A Worker whose role was worked out from the wiring stops being a Worker if its supervising session dies, so anything it needs from a human turns red again - nothing waits silently on a Supervisor that will never answer. A Worker you declared is different: the declaration is sticky, so it keeps the role and the quiet slate even after its Supervisor exits, until you clear the declaration.

5. Put names on the pattern

   What you just built by hand - a planner, a supervisor, a builder - is the cast of the Team way of working, shipped in the workflow catalog as mission: an Architect settles the design, a Manager drives the phases, and Workers build. The catalog's other two built-in workflows are smaller casts of the same idea - standalone is one session working alone, and standalone-with-review adds a second, separate session that checks the work before it is called done.

   Every session is briefed with the catalog's one-line summary of each workflow; a session that participates in a workflow run is told to fetch that workflow's pinned conduct and follow it. The workflows tutorial shows how those ways of working are written down and published to your fleet.

   Note

   The Reviewer in standalone-with-review is the method's fifth role - a different session from the one that wrote the work, checking it before it lands. It is agreed but not yet recordable: the role flag accepts four values today and no badge shows for a Reviewer, so the workflow staffs the role rather than the rail displaying it.

The full facts - the resolution order, every badge surface, and the exact colour behaviour - live on session roles and missions. For giving each session its own copy of the code so a team of them can build in parallel, read repositories and worktrees.