The Architecture of Coordination

Step back from the tools

Earlier we designed individual coordination tools — ask_statistician, start_conversation. Now step back from names and descriptions and ask the architect's question: what are the primitives at our disposal? For coordinating conversations, there are three:

START (template)        bring a new conversation into existence.
                        The template is the role: a system message,
                        a tool set, initial context. Starting
                        instantiates it.

WRITE (conversation)    add a message to an existing conversation —
                        usually into its user seat.

READ (conversation)     look at an existing conversation:
                        its final message, its tail (status),
                        or a search through it (selective read).

Notice what start versus read/write resolves: the role-vs-instance question. "A conversation with a statistician" is start — a role, instantiated. "What did that statistician say" is read — a particular, existing conversation.

And notice what is deliberately not a primitive: interrupt. Reaching into another agent's loop mid-thought makes its trajectory — and your reasoning about the system — dramatically harder. We coordinate at message boundaries: you may write to a conversation, and what it does with your message is its own affair.

Every architecture is a policy over the primitives

Each coordination pattern people name and diagram is just a rule about who may use which primitive on whose conversation:

When you meet any multi-agent framework — whatever it calls its crews, swarms, or graphs — ask one question and its whole design will unfold: who may start, write, and read which conversations?

A worked example: three agents write a report

Let's build a real system and watch it run. The goal: a weekly operations report. The design — first the map, as always:

Read that table the way you'd read an org chart — because that is what it is: who may open a conversation with whom, who reports upward, what lives in the shared filing cabinet. Multi-agent architecture is organizational design for conversations — teams, specialists, channels, and hierarchy, rediscovered one table at a time.

Now the run. Three walls:

⟨tool_use⟩
start_conversation(template = "researcher",
                   task = "Gather this week's operations data:
                   deliveries, delays, incidents. Write findings to
                   shared-notes as structured bullet points.")

⟨tool_result⟩
Started: c-201 (running).

⟨tool_use⟩
read_status(conversation = "c-201")

⟨tool_result⟩
Ended. Final message: "Findings written to shared-notes: 9 items."

⟨tool_use⟩
start_conversation(template = "writer",
                   task = "Write the weekly operations report from
                   shared-notes. Audience: site managers. One page.")

⟨tool_result⟩
"Draft complete: three delivery delays (all weather), one resolved
incident, throughput up 4%. Full text attached…"

⟨tool_use⟩
query_deliveries(week = "2026-W33")

⟨tool_result⟩
412 deliveries; 3 delayed >2h (storm, 19 Aug).

⟨tool_use⟩
write_notes(entry = "Deliveries: 412; 3 delayed >2h — cause:
storm 19 Aug [source: delivery log]")

⟨tool_use⟩
read_notes()

⟨tool_result⟩
[9 structured findings: deliveries 412, 3 delayed (storm)…]

Trajectories become a braid

One conversation is one trajectory. This system is three trajectories, coupled only at the points where something crossed — two briefs, a status read, the notes, a draft. Everywhere else, the three ran independent and untouched. That is what the permissions table really controls: where trajectories are allowed to touch.

Couple them too much (share everything, read everything) and you've rebuilt one giant noisy conversation with extra steps. Couple them too little and the pieces can't compose. Choosing the touch points — what crosses, in which direction, saying how much — is precisely the decomposition problem, and it gets a lesson of its own later.

The playwright's responsibility, at scale

One earlier thread now runs through the whole architecture: at every touch point, somebody composed what crossed. The coordinator wrote the researcher's world; the researcher's notes became the writer's entire evidence; the writer's draft became what the user believes happened this week. Every arrow in the architecture diagram is a shadow being cast — and the org design decides who casts it, from what knowledge, for whose wall.