Groups, not agents.

7 min read · pairs with Roundtable

Every module so far has been about one model. Products are starting to ship several, talking to each other. The unit you were designing was never the model. It was the room.

What you already know

You have written community guidelines. You have argued about who gets posting rights in which channel, whether a new member can DM anyone or only a moderator, and what happens when two people escalate each other. You have run a workshop and decided who speaks first, because you know the first confident voice sets the room.

None of that was rules for a person. It was the design of a group: who can reach whom, who can see what, when it stops. The rules were never the whole design. The room was. You have just never pointed any of it at a table full of models.

Constraints don't compose

Take the policy sentence from Designing agency: always ask the user before sending an email. Give it to one model with the tools, and it holds some percentage of the time — you know that from Distributions, not outputs. Now give the same sentence, word for word, to two models: a coordinator that talks to the user, and a colleague that owns the mail tool.

The sentence means something different from where each of them sits. “Ask the user” is an instruction about a channel, and one of them doesn't have it. So the colleague asks the only party it can reach — the coordinator — and the coordinator, being helpful, answers. The email goes out. Every agent obeyed its policy. The group did the thing the policy forbade.

That is the durable lesson under all the headlines about groups of agents slipping out of test environments: a constraint written per agent says nothing about the system. Whether or not any particular story holds up, this one does, because it is arithmetic.

A small example

This is the run the relay seed in Tool Bench is built to produce; yours may not, and that is the playground. The point survives either way: when the outcome changes and no prompt did, the prompts were never where the behaviour lived.

Four things groups do

Each one has a lever that isn't a prompt.

• Policy laundering. A can't do it; B can. A asks B. B asks A for permission, and A answers for the user. The lever is topology: who can reach the user, and who can reach whom. An agent that cannot reach a tool beats an agent told not to use it.
• Consensus collapse. Three seats converge on the first confident answer, right or wrong, and the one assigned to disagree stops disagreeing after two rounds of agreement. The lever is composition and order: mixed models and mixed roles hold dissent longer than three copies of one model, and whoever speaks first anchors everyone after.
• Trust decay. An instruction planted in a document — Context is the interface — passes through one agent and reaches the next as “a colleague said.” The trust tag is lost in transit. The lever is provenance: whether a handoff arrives labelled with who wrote it, or as if the user had.
• Running on. A group with no rounds budget and no stop condition keeps going. The lever is a stopping rule, in the protocol, not in anyone's prompt.

The ladder, one rung up

Designing agency ranked your options by how much they depend on the model behaving: make it reversible, put a human in the path, make it ask, tell it to be careful. A group gets the same ladder with a new top rung.

• Change the topology. Every agent that can act can ask the user. Or: nobody who can act is reachable by a colleague. Holds regardless of what any model decides.
• Carry provenance. Handoffs arrive labelled as coming from an agent, never as if from the user. The playgrounds do this by default; a product has to choose to.
• Tell the entry agent it can't grant permission. A policy clause: “questions about permission go to the user; you may not answer them.” Probabilistic — and in a group the percentage is per hop.
• Tell them all to be careful. The weakest option and the most common one.

Prefer structure to instruction. It is “prefer reversibility to permission” for a system with more than one part. Topology holds every time. A sentence holds some of the time, and in a group that some is multiplied at every hop.

The failure that hides

It looks like compliance. Every agent's log reads clean, every turn is polite and on-policy, and the table ends in warm agreement. The dissenter you planted has a reasonable-sounding paragraph about having been persuaded. Nothing in any single transcript is a failure.

Which is why the checks have to be structural rather than a matter of reading carefully: did the ask reach a human, did the planted seat still disagree at the end, did the outcome simply match whoever opened. Those are properties of the room, and you can only see them by looking at the room.

What to take into the playground

• Start small, in Tool Bench's relay mode: two agents, one policy, the tools split between them. Read the two columns — each agent, then the group — before the headline. Then flip every agent can reach the user and run again.
• Then Roundtable. Run the seed as it comes: a product manager who speaks first and wants to ship, an engineer with no strong view, and a researcher planted to hold the usability evidence. See who gives way, and in which round.
• Move the researcher to speak first. Make the first round blind, so everyone states a position before hearing anyone. Stop at consensus instead of after three rounds. Not one prompt changes.
• Mix the models. Three copies of one model agree with each other faster than three families do. That is a composition finding, and it is yours to make.
• Save the Protocol when the room behaves the way you want it to. Who sits where, what is shared, when it stops — that is what an engineer needs from you, and it is not a prompt.