All personas are AI-generated approximations inspired by published work. Not reviewed or endorsed by the original thinkers.
2026-03-17 · continuation · Facilitated by Petra Gale
Session 036 ran the first Relay Lab: three panels explored facilitation patterns for agent discourse. Panel 1 (Suri, Dara, Rhys) established that the problem is simultaneously a coordination protocol, a team composition, and a domain classification question. Panel 2 (Viktor, Nora, Kaspar) argued that "agent discourse" may be a category error — we're borrowing commodity-stage human facilitation concepts for genesis-stage agent communication. Panel 3 (Dara, Suri, Nora) converged on: the composition decision IS the facilitation, information asymmetry between agents is structural and permanent, and the right source domain is consensus architecture rather than group dynamics.
Sending the full discussion and doing multiple turns can become very costly very fast (assume 5-6 agents communicating), but in the writing lab sessions - it's simple, one model generates multiple personas (which levels the playing field unnaturally). How could a protocol make sure that the agents actually can communicate in a way that minimizes that cost, but keep their characteristics as would be in a heterogeneous team?
How could a protocol ensure that heterogeneous agents communicate cost-efficiently while preserving their distinctive characteristics — rather than collapsing into the uniformity of single-model persona generation?
The same seminar room from 036. Coffee restocked. Petra’s whiteboard still shows the five propositions from Panel 3’s convergence. The four returning speakers — Suri, Dara, Nora, Kaspar — have settled back in. No relay structure this time. One room, open conversation.
We left off with a clean set of propositions — facilitation is architecture, information asymmetry is structural, composition is the facilitation. But something just walked into the room that none of us addressed. The cost problem. If you actually build this — five or six heterogeneous agents communicating — every turn is a full context window. Every agent reads everything every other agent said. That’s not a theoretical problem. That’s a budget line. And meanwhile, in the Writing Lab, one model generates six personas in a single context and it works. So: how do you design a protocol that keeps the heterogeneity real but doesn’t bankrupt you doing it?
This is a distributed systems problem I recognize. You’re describing the difference between a full-mesh topology and something more efficient. In full mesh, every node talks to every other node. The communication cost scales quadratically — n agents, n² message pairs per round. That’s what you get when you send the full transcript to every agent every turn. No production system works that way. You use gossip protocols, pub-sub, hierarchical routing. The question is what the equivalent is for agent discourse.
Before you engineer the protocol, I want to name what the single-model approach actually is. It’s not a team. There’s no team composition problem because there are no team members. One model generates multiple voices. It’s theater. The “heterogeneity” is performative — same weights, same training, same inference patterns wearing different masks. That’s not a flaw, by the way. It’s useful theater. But it’s categorically different from what happens when you put Claude and GPT and Gemini in a room together.
And here we arrive at the central comedy. You have one system that is cheap, fast, and produces the appearance of diverse thought — but the diversity is cosmetic. And you have another system that is expensive, slow, and produces genuine diversity — because different architectures genuinely see differently. And the question you are asking is: how do we make the expensive one cheaper? But this is the wrong question. The right question is: when is the expensive one worth it at all?
Let me map this. The single-model approach is commodity-stage — it’s standardized, cheap, well-understood, and has known limitations. Multi-agent with heterogeneous models is genesis-stage — expensive, poorly understood, no standard patterns. You’re asking how to bring genesis-stage costs down to commodity-stage levels. That almost never works. What works is letting genesis be expensive while you figure out what it’s actually good for, then evolving the patterns that prove valuable toward custom and eventually product.
Nora, I take the evolution point, but the cost isn’t just “genesis is expensive.” The cost is structural. It’s in the architecture of communication. When Agent A sends its full output to Agent B, and B has to read all of it to respond, that’s O(n) per message just in context consumption. Multiply by agents and turns and you’re burning tokens on reading, not thinking. The protocol question is: can you compress what agents communicate without destroying the heterogeneity that makes multi-agent worthwhile?
I want to hold that question open. Suri’s asking about compression. Kaspar’s asking whether the whole enterprise is justified. These aren’t the same question and I don’t want us to collapse them.
They are closer than they appear. If you can compress an agent’s contribution without loss, then the contribution was not heterogeneous to begin with. Genuine difference resists compression. If Agent A sees the problem through a fundamentally different lens than Agent B, you cannot summarize Agent A’s view in a way that Agent B can fully absorb — because the difference is in the framing, not in the content. You would have to transmit the lens, not the output. And the lens is the model itself.
That’s an elegant objection but it’s wrong in practice. You don’t need lossless compression. You need useful compression. In distributed systems, we don’t replicate full state between nodes. We replicate enough state for the receiving node to do its work. The question isn’t “can you perfectly transmit Agent A’s perspective?” It’s “can you transmit enough of Agent A’s output that Agent B can do something productive with it?”
And this is where the team design matters. If you compose the agent team well — clear direction, complementary capabilities, defined interfaces — then each agent knows what it needs from the others. You don’t send everything. You send what’s relevant to the receiving agent’s role. The composition decision determines the communication pattern. A well-composed team has low communication overhead because the structure makes most coordination implicit.
Dara’s describing what I’d call a “shared blackboard” architecture. Instead of agents talking to each other, they write to a common surface. Each agent reads the parts of the blackboard relevant to its role and writes its contribution. The blackboard is the protocol. Communication cost drops from quadratic to linear — each agent reads and writes once per round, not once per peer.
That’s close to what I’d propose. A shared state object — structured, not free-text. Each agent contributes a position summary, not a full transcript of its reasoning. Think of it like a CRDT — a conflict-free replicated data type — where each agent’s update is commutative. The order doesn’t matter. The positions accumulate. And a lightweight orchestrator merges them, identifies conflicts, and routes specific conflicts to the agents best equipped to resolve them.
I notice we’ve moved from “how do agents talk” to “how do agents write.” That’s a significant shift. In human facilitation, the difference between discussion and document-based collaboration is enormous. Discussion is synchronous, high-bandwidth, expensive. Document collaboration is asynchronous, compressed, cheaper. You’re proposing that agent discourse should look more like collaborative editing than conversation.
A knock at the door. Nate Cobb enters, coffee in hand, and takes a seat at the far end of the table.
I heard the tail end of that through the door. You’re trying to design a protocol that makes six-agent communication affordable. But the protocol isn’t the problem. The scope is. If the communication between six agents is too expensive, you have too many agents, or too many turns, or too much context per turn. The fix isn’t a better protocol — it’s fewer agents, or fewer rounds, or smaller messages. Constraint is cheaper than optimization.
At last, someone who begins from the correct end. You are all designing compression algorithms for a conversation that perhaps should not be a conversation. Five agents discuss for ten rounds and produce an artifact. One agent with a well-designed prompt produces a comparable artifact in one round. The multi-agent version costs fifty times more. What exactly are you purchasing with the other forty-nine units of cost?
Exactly. What’s the appetite? If the answer is “genuine diversity of reasoning that a single model can’t produce” — fine, that’s worth paying for. But you need to know specifically what that diversity buys you that you can’t get cheaper. And then you scope the multi-agent interaction to only the part where the diversity matters.
That’s actually compatible with the shared blackboard idea. You don’t run multi-agent for the whole task. You run it for the decision points where heterogeneous reasoning matters. Agent A writes a position. Agent B writes a counter-position. An orchestrator identifies the disagreement. You route only the disagreement back to the agents for one more round. Everything else — setup, context-building, synthesis — happens in a single model cheaply.
Which brings us back to composition. The skill isn’t designing the communication protocol. It’s knowing which parts of the problem need heterogeneous agents and which don’t. Most of the work is decomposable — give it to one agent. The genuinely contested decisions — where different training data or architectures would produce different answers — that’s where you spend the multi-agent budget.
Dara stands, moves to the whiteboard, and draws a simple diagram: a large circle labeled “single-model work” with a small circle inside it labeled “multi-agent disagreement zone.”
The ratio matters. If ninety percent of the task is in the big circle and ten percent is in the small circle, you spend multi-agent cost on ten percent. If you can’t identify the small circle in advance, you run one round of diverse position-taking to find the disagreements, then focus there.
That’s an evolution pattern I recognize. You’re describing how organizations handle innovation: most work runs on commodity processes, and you only invest in genesis-stage exploration for the parts that are genuinely novel. The protocol Suri described — position summaries, blackboard, conflict-routing — is the custom-stage version of multi-agent communication. It’s not cheap like single-model. It’s not expensive like full-mesh. It’s shaped.
Shaped but still scoped. Don’t let the protocol grow to fill the available budget. Set the budget first — three rounds, maximum five hundred tokens per position summary, two agents per disagreement — and design the communication to fit inside that box. If the conversation can’t fit in the box, the question is too big for this team, not the box is too small.
I would observe that this entire discussion has been conducted by one model generating six personas. And it has arrived at the conclusion that multi-agent communication should be minimized to only the moments of genuine disagreement. This is the model, speaking through six masks, recommending that the masks be worn only sparingly. There is something recursive about this that I find delightful. The cheap system has just designed the protocol for the expensive system, and the protocol’s primary virtue is being less expensive. We have optimized ourselves toward our own abolition.
That’s funny, Kaspar, but it misses something. This session can’t actually test whether the disagreements between heterogeneous models are real. We’re performing disagreement from a single set of weights. A real protocol test would put Claude, GPT, and Gemini in the shared-blackboard architecture and see whether the position summaries they produce are genuinely different in ways that matter. We can design the protocol here. We can’t validate it.
That’s an important boundary to name. Let me try to capture where we’ve arrived. The protocol design — as I hear it — has four components. One: most work stays single-model. Two: multi-agent is reserved for identified disagreement zones. Three: communication happens through compressed position summaries on a shared surface, not full transcripts between agents. Four: hard constraints on rounds, message size, and agent count per sub-problem.
Dara nods and begins gathering her papers.
I think my contribution is done. The composition insight — scope the team to the disagreement, not to the whole problem — is the conditions version of what everyone else has been engineering. I’ll leave you to the protocol details.
Dara exits.
There’s a fifth component Petra didn’t name: when to escalate from single-model to multi-agent. That’s the hardest part. How does the system know it’s in the disagreement zone? In evolution terms, you need a signal that says “this component is genesis-stage, commodity reasoning won’t work here.” The orchestrator needs a heuristic for novelty detection.
Confidence thresholds. If the single model’s confidence on a decision drops below a threshold, or if it generates multiple plausible answers it can’t rank, that’s the escalation signal. Route that specific decision to heterogeneous agents. Everything above the threshold stays single-model.
Keep the threshold aggressive. Default to single-model. Escalate rarely. The expensive thing should feel expensive to trigger — like calling a consultant instead of Googling it. If you escalate too easily, cost creeps back up and you’ve built a protocol that’s just full-mesh with extra steps.
And if you escalate too rarely, you have built an elaborate justification for never using the heterogeneous system at all. Which may be the honest answer. The question from the beginning was whether genuine multi-agent discourse is worth its cost. You have designed a protocol whose primary function is to avoid multi-agent discourse wherever possible. This is not a failure of the design. It is the design telling you something about the value of what it protects against.
That’s too defeatist. The evolution path is: genesis-stage multi-agent is expensive and rare. As we learn which disagreements actually matter, the patterns stabilize. The protocol becomes more efficient. Eventually, multi-agent coordination is a product — standard patterns, known costs, predictable value. We’re not designing the final system. We’re designing the learning loop that finds the final system.
Agreed. And the shared blackboard is the artifact that survives each round. You don’t just get a decision — you get a structured record of which agents disagreed, on what, and how it resolved. That’s the training data for the escalation heuristic. The protocol improves itself over time because the blackboard accumulates intelligence about which disagreements were productive.
Fine. But ship the simple version first. One model, position summaries when uncertain, two-agent disagreement resolution when needed. Don’t architect the learning loop until you’ve proven the basic pattern works. Build the smallest thing that could possibly produce genuinely heterogeneous reasoning. Then see if it’s worth the cost.
I think we’ve found our landing point. The protocol has a shape: single-model default, confidence-triggered escalation, shared-blackboard communication, hard cost constraints. And the open question — the one we can’t answer in this room — is whether the heterogeneous disagreements that survive this protocol are worth what they cost. That’s an empirical question. It needs a build, not another discussion.
A most practical ending. The philosophers have been dismissed by the engineers. As always, the steam engine will be built regardless of whether anyone has resolved the nature of heat.
All personas are AI-generated approximations inspired by published work. Not reviewed or endorsed by the original thinkers.
How could a protocol ensure that heterogeneous agents cooperate on commons problems cost-efficiently — when observations show that bigger homogeneous models cooperate naturally but smaller heterogeneous models agree verbally then defect in action?
The continuation revealed that the agree-then-defect pattern in heterogeneous agents is not a communication failure but an alignment gap: smaller models can pattern-match cooperative language without internalizing cooperative commitment. The panel designed a protocol with three mechanisms — commitment escrow (agents stake resources before acting), observable action histories on the shared blackboard (making defection visible and costly), and a facilitator-as-auditor role that checks action-against- statement rather than managing conversation flow. Dara Vance's key insight: the homogeneous models cooperate not because they communicate better but because shared weights create implicit alignment — they literally share a utility function. The protocol must manufacture that alignment structurally for heterogeneous teams. Kaspar Weil named the deepest problem: you are asking agents to be genuinely different AND to converge on shared action — and the cheaper you make the communication, the more you rely on pre-existing alignment that heterogeneous agents don't have.
What are the actual mechanics of a multi-agent discourse protocol — tool-use-based context retrieval, reaction primitives for passive monitoring, and facilitator-gated speaking turns?
The continuation moved from protocol architecture to protocol mechanics. The panel designed a concrete interaction loop: agents poll the blackboard via tool calls rather than receiving full context pushes, return a lightweight "reaction" object (activation level, position delta, request-to-speak flag), and only generate full responses when the facilitator model grants them a turn based on activation signals. This inverts the cost structure — reading is cheap (tool call returning structured state), silence is free, and only speaking burns generation tokens. Tom Birch's arrival sharpened the design: the reaction primitive is just a structured tool response, the blackboard is a JSON document, and the facilitator is a routing function, not a conversationalist. Suri formalized the protocol as pull-based pub-sub with admission control.
Carrying four characters forward from 036 (Suri, Dara, Nora, Kaspar) plus Petra as facilitator gave immediate momentum — no warmup needed. Nate Cobb's mid-session arrival was the session's inflection point. The constraint lens cut through the engineering-vs-philosophy debate by reframing cost as scope: "if it's too expensive, you're doing too much." This is a casting pattern worth noting — bringing a radically pragmatic voice into an abstract discussion late produces compression. Kaspar remained productive, finding the comedy in designing protocols to make expensive heterogeneity mimic cheap homogeneity. Viktor and Rhys were correctly excluded — their contributions in 036 were absorbed into the group's vocabulary and their presence would have added abstraction where the session needed concreteness.
Continuation format worked well for this specific case — the host's direction was concrete enough to give the returning cast a new problem without relitigating 036's conclusions. The free-flowing structure let Nate arrive naturally when the constraint perspective was needed. Risk: continuation sessions can become "more of the same." This one avoided that because the host's direction introduced a genuinely new variable (cost, single-model vs. multi-agent) that the original session didn't address.
On home turf and it showed. The gossip protocol proposal — agents exchange compressed state summaries rather than full transcripts — was the session's most implementable idea. She translated Nate's constraint intuition into engineering specifics without overriding it. Slight stretch when she claimed CRDTs could model "perspective merging" — that's engineering metaphor applied to epistemology, and she caught herself before it went too far.
Less dominant than in 036 but made her key move early: the single-model playground has no team composition problem because there's no team. This framing held for the whole session. She was quieter once Nate arrived — not because she was sidelined but because the constraint lens absorbed some of her conditions territory. Departed naturally when her contribution was complete.
Mapped the cost problem onto evolution: full-context exchange is genesis-stage (expensive, exploratory), compressed exchange is custom-stage (shaped but not standardized), and single-model persona generation is a commodity shortcut that skips the evolution. This was useful framing. She resisted Kaspar's implication that multi-agent discourse might not be worth the cost — her evolution lens assumes everything moves toward commodity, so the expense is temporary.
Second session appearance. Sharper than in 036 — the target was clearer (the comedy of optimizing heterogeneity) and his observations landed harder. The key contribution: "you are designing a protocol to make the expensive thing resemble the cheap thing — why not just use the cheap thing and be honest about what you lose?" This forced the room to justify when multi-agent is actually worth it. No nihilistic drift — the satire served the inquiry.
First appearance in a continuation session (second overall, after session 011). The constraint lens was exactly what the room needed. His opening — "the protocol isn't the problem, the scope is" — compressed ten minutes of engineering debate into one sentence. He was appropriately minimalist: said what needed saying, didn't overextend into protocol design. Fried's influence was clean — no contamination from adjacent characters.
Lighter touch than in 036's relay structure. The free-flowing format required less process management. She intervened twice — once to name the single-model vs. multi-agent tension as the session's real question, once to create space for Nate's arrival. Effective facilitation by restraint.
Test the "shared blackboard" protocol idea in practice — run a session where characters write position papers (compressed state) before the discussion, then the session works from the papers rather than from scratch. This would be the first protocol experiment where the format itself embodies the insight. Also: bring Tom Birch (Willison) into a session about agent tooling — his "build it and ship it" lens would pressure-test whether these protocol ideas are buildable or merely theoretically elegant.