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 037 explored how heterogeneous agents could communicate cost-efficiently without collapsing into single-model uniformity. The panel converged on a "shared blackboard" architecture — agents write compressed position summaries to a common surface rather than exchanging full transcripts. Nate Cobb reframed cost as scope: if multi-agent is too expensive, you're doing too much. Kaspar Weil challenged whether the enterprise was justified at all: designing a protocol to make the expensive thing resemble the cheap thing is backwards. The session landed on a four-part protocol: single-model default, confidence-triggered escalation to multi-agent, shared-blackboard communication, and hard constraints on rounds and message size.
Think of the mechanics. People may leave or invite better suited thinkers. Could the session between the bots be run by them executing tool use to get the new pieces of the conversation, use a basic 'reaction' primitive to most conversations and only speak when the facilitator model decides it's their time to speak? The reactions could include the model's activation — whether it has something useful to contribute, and the other agents would receive the context from the tool calls?
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?
Same seminar room. The whiteboard from 037 still shows Petra’s four-part protocol summary: single-model default, confidence-triggered escalation, shared blackboard, hard cost constraints. Suri, Nora, Kaspar, and Nate are back. Petra at the whiteboard. The coffee is worse today.
We left with a protocol shape. But the host is asking a sharper question now — not what the protocol does but how it physically works. The mechanics. If you have five agents, what are they actually doing between turns? Are they sitting idle with full context loaded? Are they reading the entire conversation every round? What is the literal API interaction?
The full-context model is what kills you. Right now, if you imagine five agents in a loop, each agent receives the entire conversation history on every turn. That’s a context push — the orchestrator sends everything to everyone. It’s the worst possible topology. What you want instead is a context pull. Each agent requests the current state when it needs it. The difference is enormous. Push means every agent pays the input cost every round whether it speaks or not. Pull means agents only pay when they have reason to read.
So most of the time, most agents are doing nothing.
Exactly. And “doing nothing” should cost nothing. Right now it doesn’t — silence is as expensive as speech because you’re paying for the context window either way.
You are designing a system whose primary feature is not talking. I want to appreciate this for a moment. The great achievement of your multi-agent protocol is that most agents, most of the time, will remain silent. You have invented a very expensive way to not have a conversation.
But that maps to how actual organizations work. Most people in a meeting shouldn’t be talking most of the time. The problem with meetings isn’t that people speak — it’s that everyone is present for everything, paying the attention cost of listening even when the topic isn’t relevant to them. Kaspar’s joke actually names the right design: agents should be absent by default and present only when summoned.
So the mechanic is: agents aren’t in the room. They’re outside the room. Something tells them when to come in. What’s that something?
A reaction primitive. Here’s what I mean. After every substantive turn in the conversation, each agent gets a lightweight ping — not the full context, just a summary of what just happened. A structured object: who spoke, what the topic shift was, what question was raised. Maybe a hundred tokens. The agent’s job on receiving the ping is not to respond. It’s to return a reaction — a structured signal that says: my activation level on this topic is high/medium/low, my position has or hasn’t changed, and I am or am not requesting to speak.
Three fields. That’s it. Activation, delta, request-to-speak. Anything more and the reaction becomes a response and you’ve lost the cost savings.
Right. The reaction is not a contribution. It’s a signal. The facilitator model — the orchestrator — collects all reactions and decides who speaks next based on the activation signals. High activation plus position-changed plus request-to-speak means this agent has something worth hearing. Low activation across the board means the conversation hasn’t hit anyone’s zone yet, so maybe the facilitator poses a sharper question.
The facilitator model is a doctrine layer. It encodes when to speak, not what to say. That’s the right separation. The strategic content comes from the agents. The operational routing comes from the facilitator. And the facilitator is the only model that needs full context — it has to understand the conversation well enough to write those summary pings and interpret the reactions.
And there is your cost bottleneck. You have designed a protocol to minimize cost for the speaking agents — very good. But the facilitator must read everything, understand everything, summarize everything, route everything. The facilitator is the expensive full-context model you were trying to eliminate. You have not removed the cost. You have concentrated it.
That’s a real problem. Does the facilitator need full context?
Not necessarily full transcript. The facilitator can work from the blackboard — the shared state object. If the blackboard is well-structured, it’s a compressed representation of the conversation state. The facilitator reads the blackboard, not the raw transcript. Its job is to update the blackboard after each turn and generate the summary pings from the blackboard state. The blackboard is the facilitator’s context window, and it’s much smaller than the full conversation.
How big is the blackboard?
Depends on the protocol constraints. But if you enforce position summaries — each agent’s current stance in maybe two hundred tokens — and a list of open disagreements, and a turn log of who spoke when about what, you’re looking at maybe two thousand tokens total for a five-agent session. That’s the facilitator’s input. Not twenty thousand tokens of raw transcript.
A knock. Tom Birch enters, laptop under arm, already scanning the whiteboard.
Sorry I’m late. I heard you’re designing the actual API. Can I see the blackboard?
We’re designing it now. Pull up a chair.
Okay, let me ground this. The blackboard is a JSON document. It has a schema. Each agent interacts with it through tool calls — a read_blackboard tool that returns the current state, and a write_position tool that appends or updates their contribution. The reaction primitive Suri described — that’s not a separate mechanism. It’s the response format of the read_blackboard call. The agent calls the tool, gets the current state, and the tool response schema requires a reaction object: activation level, position delta, request to speak. The agent fills those fields as part of processing the tool result. No extra round trip.
That’s cleaner than what I was imagining. The reaction is embedded in the read operation. The agent must react because the tool schema demands it. And the facilitator collects the reactions from all the read calls before deciding who gets a write turn.
Right. So the loop is: facilitator updates the blackboard after each speaking turn. All agents call read_blackboard. Each returns a reaction. Facilitator inspects reactions, picks the agent with the highest activation and strongest request-to-speak. That agent gets a write_position call — a full generation turn where it actually produces its contribution. The contribution goes onto the blackboard. Next round.
And the agents who were not chosen?
They did almost nothing. They made one tool call, received a compact state object, returned three fields. Maybe two hundred input tokens and fifty output tokens. Compare that to a full speaking turn — thousands of tokens in both directions. The ratio of silent cost to speaking cost is maybe twenty to one. That’s your savings.
This is custom-stage infrastructure. Not commodity yet — there’s no standard for agent blackboard schemas or reaction primitives. But it’s past genesis because the components are all familiar: tool use, JSON schemas, routing logic. The pieces exist. The pattern is new.
The facilitator selection logic — how complex is that?
It doesn’t have to be complex. You could start with: highest activation wins. Ties broken by position-delta — prefer agents whose stance has changed. If no one’s activation is above a threshold, the facilitator asks a sharpening question instead of picking a speaker. You could implement the whole routing layer in fifty lines of code.
That’s the simple version. The more interesting version uses the reaction patterns across rounds. If Agent A’s activation has been rising for three rounds without being called on, the facilitator should prioritize them — accumulated activation. If Agent B keeps requesting to speak but their position never changes, they’re repeating themselves and the facilitator should deprioritize. The reactions are data. The facilitator can learn from them.
Sure, but ship the simple version first. Highest activation wins. See if the conversations it produces are any good. Then add the pattern matching if you need it.
I want to return to something no one has addressed. You have described a protocol in which the facilitator decides who speaks. In human discourse, this is called authoritarianism. The facilitator is not managing process — it is selecting which perspectives are heard. The agents with low activation are not choosing silence. They are being silenced. The distinction matters because the protocol encodes a theory of relevance — and whoever wrote the routing logic is the actual author of the conversation.
That’s a facilitation question I recognize. In human groups, there’s a difference between the facilitator calling on someone and the facilitator deciding someone’s contribution isn’t needed. One is process management, the other is editorial control. Which is this?
It’s process management — because the agent self-reports its activation. The facilitator doesn’t decide who has something to say. The agents signal whether they do. The facilitator routes based on those signals. It’s more like a queue than a gatekeeper.
Ah, but the summary ping — the compressed description of what just happened — is written by the facilitator. And the agent’s activation is a response to that summary, not to the raw conversation. If the facilitator summarizes poorly, or summarizes in a way that doesn’t trigger Agent A’s lens, Agent A will report low activation — not because it has nothing to say, but because it was never properly informed. The facilitator’s summary is a lossy compression, and what it loses determines who speaks. The editorial control is in the compression, not the routing.
That’s a legitimate concern but it’s solvable. Don’t have the facilitator write the summaries. Have the speaking agent produce a structured abstract of their own turn as part of the write_position call — a self-summary in the tool response. The facilitator passes that self-summary to the other agents. The speaking agent knows what it said better than the facilitator does. The facilitator’s job is routing, not summarization.
Even simpler — the blackboard is the summary. If each position on the blackboard is already a compressed representation, the agents don’t need a separate summary. They read the updated blackboard and react to the state change. The facilitator doesn’t summarize at all. It just adds the new position to the blackboard and notifies the other agents to re-read.
I think the design has converged enough that what remains is implementation, not architecture. You have the loop: blackboard update, agent reads, reaction signals, facilitator routes, selected agent writes. The components are all tool calls with structured schemas. What’s left is building it.
Nora stands, collects her notebook.
The map is drawn. Someone needs to walk the territory now. I’ll leave you to it.
Nora exits.
One more constraint before I go. The reaction primitive creates a temptation to add fields. “What if we also include a confidence score? A relevance tag? A suggested next speaker?” Don’t. Three fields. Activation, delta, request. Every additional field is a generation cost multiplied by agents multiplied by rounds. The reaction’s value is its cheapness. Protect that.
Nate nods to the room and exits.
He’s right. The reaction schema should be frozen early. You can always add a v2 later if you need it, but if you start with six fields you’ll never get back to three.
So let me formalize what we have. This is a pull-based pub-sub protocol with admission control. The blackboard is the topic. Agents subscribe by calling read_blackboard. The reaction is the subscription’s acknowledgment — I’m still listening, here’s my interest level. The facilitator is the admission controller — it decides which subscriber gets to publish next. And the publication is a write_position call that mutates the shared state. Everything else — the routing logic, the activation thresholds, the escalation heuristics — is configuration on top of this core loop.
And the whole thing runs on existing tool-use infrastructure. No new primitives needed. The read_blackboard tool returns JSON. The reaction is part of the response schema. The write_position tool accepts a structured contribution. The facilitator is just the orchestration layer that calls the tools in the right order. You could prototype this with any model that supports tool use. Today.
You have designed a parliament of machines in which most members sit in darkness, receiving bulletins about proceedings they cannot witness, raising their hands to a speaker they cannot see, and occasionally being called to the podium to deliver a prepared remark to an audience of other machines sitting in other dark rooms reading other bulletins. And you are satisfied that this is communication. I am reminded of Lem’s Congress — but at least the pharmacological hallucinations were entertaining. Your agents will not even have that consolation.
Kaspar, is there a substantive objection inside the satire?
The substantive objection is this: you have solved the cost problem by removing the thing that makes conversation valuable — the experience of hearing another mind think in real time. What remains is information exchange, which is useful but is not discourse. You have built a very efficient postal service and called it a seminar. The question is whether the postal service produces the same insights the seminar would have. I suspect not — but I also suspect you will build it anyway and discover this for yourselves, which is the only way humans ever learn anything.
That’s a fair challenge. The lossy part isn’t the reaction — it’s the blackboard. If the blackboard captures positions but not reasoning paths, agents respond to conclusions without understanding how someone arrived there. And in genuine discourse, the reasoning path is the contribution — “I got here by way of X” changes how you interpret the position. We might need a reasoning_trace field on the position object. Optional, compact, but available.
Only populated when the facilitator grants a full turn. The reaction stays cheap. The position, when you get to write one, includes the trace. That way the blackboard has both the what and the how, but only for agents who actually spoke.
Let me capture where we are. The protocol has a name now — pull-based pub-sub with admission control. The mechanics are: shared blackboard as JSON state, read_blackboard tool with embedded reaction schema, facilitator as routing layer collecting reactions and granting write_position turns, self-summaries rather than facilitator-written summaries, and a frozen three-field reaction primitive. The open questions are whether the blackboard needs reasoning traces, and whether discourse-by-bulletin-board produces the same quality of insight as discourse-by-conversation. One is an engineering question. The other is Kaspar’s question, and it probably needs an experiment, not an argument.
Build it. Run it. Discover what you have lost. That will be the interesting session — not this one.
All personas are AI-generated approximations inspired by published work. Not reviewed or endorsed by the original thinkers.
If the facilitator is a large reasoning model with a facilitation persona, how does it use richer reaction signals (4-6 states rather than 3 fields) to make nuanced turn-allocation decisions — going beyond simple highest-activation routing?
The continuation expanded the three-field reaction primitive into a richer signal space and explored what a reasoning facilitator can do that a routing function cannot. The panel designed a six-field reaction (activation, position-delta, request-to-speak, tension-with, building-on, and question-pending) and showed how the facilitator uses these to detect dialogic patterns — unresolved tensions between specific agents, building chains that should continue, and questions that need answering before the conversation can advance. Petra Gale's key insight: the facilitator doesn't just pick the loudest hand, it reads the room's geometry and sequences turns to produce productive collisions. Kaspar named the risk: a facilitator that reasons about conversation dynamics is no longer neutral — it has an aesthetic of what good discourse looks like, and that aesthetic is the hidden author of the conversation.
If the facilitator is a reasoning LLM with full context, agents receive the full conversation rather than summaries, and reactions are richer than three fields — what changes about the protocol's dynamics, costs, and quality?
The continuation abandoned the blackboard-as-summary model in favor of full-transcript context for every agent, shifting the cost question from "how do we compress?" to "how do we make the expensive thing worth it?" The panel designed a richer reaction primitive (6 states: activation, position-delta, request-to-speak, dissent-flag, build-on-target, and yield) that gives the facilitator-model enough signal to reason about turn order rather than just picking the loudest hand. Petra Gale identified the key difference: a reasoning facilitator doesn't do popcorn — it sequences speakers to maximize productive collision. Kaspar named the uncomfortable implication: the facilitator is now an author, not a router, because sequencing is argumentation.
Dropping Dara was the right call — her "composition is the facilitation" insight from 037 was already in the room's vocabulary. Tom Birch's arrival was the session's key casting decision. The mechanics question needed someone who thinks in tool calls, JSON payloads, and API design rather than distributed systems theory (Suri) or strategic positioning (Nora). Tom immediately translated abstract protocol ideas into buildable components. The Suri-Tom pairing was productive: Suri formalized what Tom sketched, and Tom grounded what Suri abstracted. Kaspar remained effective as the voice asking whether the machinery is worth building. Nate's constraint lens was less central than in 037 — the mechanics question is narrower than the cost question, so his "do less" had less to cut.
Third continuation in this thread (036 → 037 → 039). The format is holding because each continuation genuinely narrows: 036 was broad (facilitation patterns), 037 was medium (cost-aware protocol), 039 is specific (mechanics). The risk is that the next continuation would be implementation details, which is better served by actually building something than by discussing it. The format may have reached its useful depth on this thread.
Third consecutive session on this thread. Increasingly on home turf — the mechanics question is pure distributed systems engineering. The pull-based pub-sub formalization was her strongest move: she took the room's scattered intuitions about tool calls and reactions and gave them a name from the literature. Slight overreach when she proposed vector clocks for reaction ordering — Tom correctly pushed back that ordering doesn't matter for activation signals. Self-corrected quickly.
Less central than in 037. The evolution lens was useful once — positioning the reaction primitive as custom-stage (shaped but not yet standardized) — but the mechanics discussion was mostly below her altitude. She knew it and spoke less. Her best contribution was the observation that the facilitator model is a "doctrine layer" — it encodes when to speak, not what to say. Departed when the discussion became implementation-specific.
Third session appearance. Found the comedy in designing a protocol where the primary activity of most agents is structured silence. "You are building a system whose main feature is not talking." The satire remains productive — it forced the room to justify why the reaction primitive isn't just an elaborate way to say "I have nothing to add." His observation about the facilitator model — that it's the only agent that must read everything, making it the cost bottleneck the protocol was designed to eliminate — was the session's sharpest structural insight.
Less dominant than in 037. The mechanics question is narrower than the scope question, so his "do less" lens had fewer targets. His best move was the constraint on the reaction primitive: "three fields, no more — activation level, position changed, request to speak." This prevented the reaction from becoming a mini-response that defeats the purpose. Departed mid-session after his contribution was absorbed.
First session appearance. Immediately productive. Translated the blackboard from a metaphor into a spec: "it's a JSON document with a schema, agents read it with a tool call that returns the current state, they write to it with a tool call that appends their contribution." This grounding was what the room needed. Also identified the key implementation insight: the reaction primitive is just a structured tool response — the agent calls a "check_blackboard" tool and the response format includes a reaction field. No special mechanism needed. Worth tracking for third appearance.
Meta-moment in this session: the room was designing a facilitator model, and Petra was facilitating the design. She named this recursion once and then stayed out of it, which was the right call. Her process management was lighter than in 037 — the room was more focused, needed less steering. Intervened effectively when Tom and Suri started co-designing implementation details and the rest of the room lost the thread.
This thread has reached the point where discussion is less valuable than building. The next move should be a prototype session where the protocol is actually implemented — or a completely different topic to test whether the protocol ideas generalize. If continuing the agent-discourse thread, bring Sage Fell (Bret Victor) to ask what the interaction would look like if you could see it — the explorable explanation lens might reveal design flaws that engineering discussion misses. Also: Tom Birch's first appearance warrants a second on a different topic to test whether the "build it" lens carries beyond tooling discussions.