Module 3 · Planning, Context & Multi-agent Systems · scripted

The Team: Role-Based Coordination

30 minoutcomes: multi-agent, agent-architectures

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.

The Team, defined

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 pattern

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:

Example 1 · The revise-and-resubmit

user

You have the following tools available for use:

delegate( role, brief )
read_deliverable( id )
send_result( text )

Task: The journal returned our paper: major revisions. Reviewer 1 challenges the statistics (says we need mixed models); Reviewer 2 wants the related-work section rebuilt around three papers we missed. Handle the revision.

assistant

⟨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.")

assistant

⟨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.")

user

⟨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.

user

⟨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.

assistant

⟨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.")

NoteRead the coordinator's real work: it never touched statistics or literature — but it routed the consequence of d-12 into the writing brief ("§5.2's claims must be cut"). Moving work between roles is not forwarding; it is reading each deliverable well enough to know who needs what from it. The playwright's responsibility, one brief at a time.

Example 2 · Deciding done

user

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

assistant

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

assistant

Completion check against the reviewers' demands: R1 statistics — addressed with mixed models, honestly reporting the lost interaction (§5.2 softened, change log line 9). R2 papers — integrated, novelty narrowed. Every reviewer point has a response-letter entry. One issue: the letter claims "all analyses unchanged in conclusion" — but the interaction result changed. I will not send that sentence; returning to writing for one correction before I declare this complete.

NoteCompletion is a JUDGMENT, and it is owned. The coordinator held the deliverable against the original demands — and caught the one overclaim that would have embarrassed the team. If completion belonged to everyone, it would belong to no one; the writer thinks "done" when the text is polished, the statistician when the model runs. Someone must own the question "done for the TASK?" — and exactly one role does.

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:

The team, as each role's tool set

coordinator:delegate(role, brief) · read_deliverable(id) · send_result(text)

statistics:query_data(…) · run_model(…) · deliver(artifact) — no delegate tool

literature:search_corpus(…) · read_paper(…) · deliver(artifact) — no delegate tool

writing:read_deliverable(id) · edit_manuscript(…) · deliver(artifact)

The statistics role CANNOT task the writer — not because a rule forbids it, but because no tool in its hands says it. The org chart is not documentation. It is unspeakability, applied to coordination.

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

The org designer's checklist

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.

The organization on the page

In Example 1, which deliverable would have been mishandled if the specialists talked directly and the coordinator just collected outputs at the end? Trace the specific failure.
Your research group is a team of roles. Write its permissions table honestly — including the edges that exist but shouldn't. Which role owns "done"? Is that ever actually ambiguous — and what does it cost when it is?

Your turn

Design a team for a recurring multi-part task in your domain. Deliver: the role list with expertise + responsibility for each (one owner per question type — prove it), each role's tool set including its coordination tools, the brief/deliverable contract for every edge, and the completion judgment written as the coordinator would run it. Then break it on paper: give it a task where two roles both believe they own one question — and fix the design, not the moment.