Session roles and missions
3 min read
Once you have more than a handful of agents on the board, the hard question stops being "what is each one doing" and becomes "who is in charge of what." Session roles answer that at a glance. Every session on the Director board now carries a role - Standalone, Architect, Manager, or Worker - and related sessions can be gathered into a named mission. You can read a busy fleet in one sweep: which sessions are solo, which one plans, which supervise, and which are heads-down doing the work.
The four roles
A role describes a session's place in a piece of work, not a different kind of agent. The same coding agent can be a Worker on one task and a Manager on another.
- Standalone. The default. A solo session that is not wired to any other - it is just working on its own. Every session starts here, and most of a casual board stays this way.
- Architect. A session that plans and oversees the work. This is the one role you set yourself, for the session you want out in front - thinking about the shape of the change and directing the rest.
- Manager. A session that is supervising another session. When one session hands work to another, the one keeping watch shows as the Manager.
- Worker. A session that is running work on behalf of another session. If a session is doing a job that a different session set up, it shows as a Worker.
Roles are worked out for you
You do not tag every session by hand. A session starts as Standalone, and its role changes as the work connects up: a session that is running work for another one shows as a Worker, and the one supervising it shows as a Manager. The only role you set deliberately is Architect - the planner you put in charge. Everything else follows from the way the work is wired together.
Missions: a name for related work
When several sessions belong to the same effort, group them into a mission and give it a name. The mission is the container that holds an Architect and the Managers and Workers under it, so a whole line of work reads as one thing on the board instead of a scatter of unrelated cards.
Why this matters
The point of DevThrottle is to run many agents without losing the thread. Roles and missions make the fleet legible: instead of a wall of identical sessions, you see a structure - the Architect that is steering, the Managers watching their Workers, and the missions those groups belong to. That is what lets you scale from one agent to a whole fleet and still know, at a glance, who needs you.
Where to go next
Roles sit on top of the session basics. If you have not yet, read session cards and states for how to read a single card, and starting and steering agents for how work gets going in the first place.