The Team: Role-Based Coordination

From primitives to an organization

We have the primitives — start, write, read — and we've seen that every coordination pattern is a policy over them. Now the archetype that most organizations of humans converged on, and that multi-conversation systems keep rediscovering: the team of roles. A multi-conversation archetype, like the Actor–Critic — but where the Actor–Critic couples two attentions through one artifact, the Team couples many responsibilities through delegated work.

A fixed set of ROLES, modeled the way human teams are:

  EXPERTISE        what this role is good at — its casting:
                   system message, tools, knowledge
  RESPONSIBILITY   what this role OWNS — the questions that
                   are always, and only, its to answer
  BOUNDARIES       who it may coordinate with, and how —
                   encoded as its coordination tools

Work moves between roles only along the allowed edges.

The deep move is the second line. Expertise says what a role can do; responsibility says what it owns — and ownership is a statement about the whole system: every kind of question the task can raise should have exactly one role it belongs to. Gaps mean dropped work; overlaps mean duplicated, disagreeing work. This is org design, and the design questions are the ones organizations have always asked.

The classic: a coordinator and specialists

The most common team shape — and the right default — puts one role in charge of the movement of work:

The coordinator's expertise is nothing domain-specific. Its responsibility is the project: reading the task, splitting the work, writing each specialist's brief, moving deliverables to whoever needs them next — and one duty that must live somewhere, so it lives here: deciding when the task is complete. Watch the shape on a real task:

⟨tool_use⟩
delegate(role = "statistics", brief = "Reviewer 1 argues our
repeated-measures ANOVA ignores per-site clustering and demands
mixed models. Attached: their comment, our methods section, the
data dictionary. Deliver: (1) is the criticism valid — yes/no
with reasoning; (2) if yes, the corrected analysis and updated
results table; (3) a response-to-reviewer paragraph.")

⟨tool_use⟩
delegate(role = "literature", brief = "Reviewer 2 names three
missed papers [refs]. Deliver: for each, one paragraph — what it
claims, how it relates to our contribution, whether it changes
our novelty argument. Flag if any actually threatens the paper.")

⟨tool_result⟩
[statistics, d-12]: Criticism valid — site clustering inflates
our F-statistics. Mixed model rerun: main effect holds (p=.003,
was p=.001); interaction NO LONGER significant. Updated table +
response paragraph attached.

⟨tool_result⟩
[literature, d-13]: Two papers adjacent, easily cited. One
(Vik 2025) overlaps our second contribution — novelty argument
needs narrowing, not abandoning. Paragraphs attached.

⟨tool_use⟩
delegate(role = "writing", brief = "Revise the manuscript using
d-12 (new stats — NOTE: interaction result is gone; §5.2's claims
must be cut or softened) and d-13 (related work + narrowed
novelty claim in the intro). Deliver: revised manuscript +
change log + response letter.")

⟨tool_result⟩
[writing, d-14]: Revised manuscript, change log, response letter
attached.

⟨tool_use⟩
read_deliverable(id = "d-14")

Boundaries are tools

Where do the team's rules live? Not in anyone's memory — in the coordination tools each role holds. The permissions-table idea from the architecture, now read as org design:

Why forbid specialist-to-specialist talk at all? The same reason human orgs route through a lead when stakes are high: every direct edge is a place where work can move unobserved by the role that owns completion. Fewer edges: cleaner accountability, simpler walls, easier debugging — at the price of the coordinator becoming a bottleneck. Adding an edge back (writer may read statistics' conversation, say) is a deliberate act: you are trading oversight for speed, and the permissions table shows exactly where.

Designing a team

1. ROLES from responsibilities, not from enthusiasm:
   list the kinds of questions the task raises;
   every kind gets exactly one owner. No gaps, no overlaps.
2. CAST each role: system message, tools, knowledge —
   the casting principle, per seat.
3. BRIEFS AND DELIVERABLES as contracts: what crosses each
   edge, in what form (the touch points are the design).
4. ONE role owns completion — and holds the original task
   to judge it against.
5. Draw the permissions table LAST, and read it as an org
   chart: if you can't explain an edge, remove it.