{
"activation": 0.0-1.0,
"position_delta": boolean,
"request_to_speak": boolean,
"tension_with": "agent_id" | null,
"building_on": "agent_id" | null,
"question_pending": boolean
}
2026-03-17 · continuation · Facilitated by Petra Gale
Session 039 designed the concrete mechanics of a multi-agent discourse protocol. The panel converged on a pull-based pub-sub architecture: agents poll a shared JSON blackboard via tool calls rather than receiving full context pushes, return a lightweight three-field reaction (activation, position delta, request-to-speak), and only generate full responses when a facilitator model grants them a turn. Tom Birch grounded the design in existing tool-use infrastructure. Kaspar Weil identified the core tension: the facilitator concentrates the cost the protocol was designed to distribute, and discourse-by-bulletin-board may lose what makes conversation valuable.
Assume that the facilitator is a large LLM model, with a facilitator persona, running the process and assuring that the voices are heard - doing so based on reactions (which might be a bit richer, like 4-6 states), and taking that into consideration when naming the next person to speak. It might be highest activation - like the popcorn facilitation technique, but it might be more nuanced since the model can reason more clearly.
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?
Same seminar room. The whiteboard from 039 shows Tom’s protocol sketch: blackboard (JSON), read_blackboard → reaction (3 fields), facilitator routes, write_position. Suri, Kaspar, and Tom are back. Petra at the whiteboard. Nora and Nate’s chairs are empty. Fresh coffee — slightly better than last time.
We ended last time with a routing function. Highest activation wins, ties broken by position-delta. Fifty lines of code. But the host is pushing us further — what if the facilitator isn’t a routing function? What if it’s a large model with a facilitation persona? A model that can reason about why it’s choosing the next speaker, not just sort a list.
That changes the cost calculation. In 039 we said the facilitator was the cheapest possible orchestration — collect reactions, pick the highest number, done. If the facilitator is a full LLM call with reasoning, it’s a generation step every round. That’s not free.
But it’s one generation step per round, and the input is compact — just the reaction objects from all agents plus the current blackboard state. If the blackboard is two thousand tokens and you have five reactions at fifty tokens each, the facilitator’s input is maybe twenty-five hundred tokens. That’s a small prompt by LLM standards. The cost is real but bounded.
Fair. And if the facilitator is a model, the three-field reaction might be too thin. A routing function only needs activation level and a boolean. A reasoning model can use richer signal.
This is where I have something to say — not about the schema, but about what a facilitator actually needs to know. When I’m facilitating a group, I’m reading three things simultaneously. First: who has energy — who’s leaning forward, who’s checked out. That’s your activation field. Second: where is the unresolved tension — which two people disagree and haven’t worked it through yet. Third: what does the conversation need next — does it need a new perspective, or does it need two existing perspectives to collide, or does it need someone to synthesize what’s been said? A routing function can handle the first read. It cannot do the second or the third. Those require understanding the shape of the conversation, not just the volume of the signals.
So the reaction needs to encode more than individual state. It needs relational information. If Agent A is in tension with Agent B’s last position, that’s not just “high activation” — it’s directed activation. The facilitator needs to know not just that A wants to speak but what A wants to speak about and who A is responding to.
Okay, let me sketch the richer reaction. Six fields instead of three.
Tom moves to the whiteboard, writes:
{
"activation": 0.0-1.0,
"position_delta": boolean,
"request_to_speak": boolean,
"tension_with": "agent_id" | null,
"building_on": "agent_id" | null,
"question_pending": boolean
}
tension_with — “I disagree with this specific agent’s last position and I can articulate why.” building_on — “I want to extend what this agent said, not challenge it.” question_pending — “I don’t have a position yet but I have a question that needs answering before I can form one.” These are still cheap to generate — the agent reads the blackboard and fills six fields. No prose, no reasoning chain. But they give the facilitator a graph, not just a list.
Now the facilitator’s input is a directed graph of tensions and building relationships, plus activation levels and pending questions. That’s a structure you can reason about. If Agent A has tension with Agent B, and Agent B has high activation, the facilitator can sequence them: B speaks, then A responds. You get a productive collision instead of a monologue.
You have given your postal service an editor-in-chief.
Explain.
In the last session, the facilitator was a clerk — it sorted the mail by urgency and delivered the thickest envelope first. Mechanical, indifferent, efficient. Now you have given the clerk a theory of narrative. The facilitator will look at the tension graph and think: “Ah, A disagrees with B — that is a dramatic arc. I shall let B speak first to build suspense, then call on A for the counterpoint.” It is no longer routing. It is directing. The facilitator has preferences about what constitutes a good conversation, and those preferences will shape the conversation’s output. The question you should be asking is: whose preferences are those?
They’re encoded in the system prompt. The facilitator model gets a persona — “you are a facilitator whose goal is to ensure all perspectives are heard and productive tensions are explored” — and then it gets the reaction graph as structured input. Its reasoning is constrained by the persona. You can tune the persona to different facilitation styles.
Yes, and whoever writes that system prompt is the true author of every conversation the system produces. Not the agents. Not the users. The prompt engineer who decided that “productive tension” should be prioritized over, say, “equitable airtime” or “convergence speed” or “comfort.” The facilitator’s aesthetic is invisible to the participants but deterministic in its effects.
That’s actually a well-known problem in human facilitation. The facilitator always has a theory of what good process looks like. The ethical obligation is to make that theory transparent. In this case — you could expose the facilitator’s decision reasoning. After each turn allocation, the facilitator could emit a brief explanation: “Calling on Agent A because A has unresolved tension with B’s position, and the conversation needs that tension surfaced before it can advance.”
That’s a metadata field on the turn allocation. The facilitator produces a structured decision object:
{
"next_speaker": "agent_id",
"reason": "string",
"room_state": "diverging | groan_zone | converging",
"alternative_considered": "agent_id",
"why_not_alternative": "string"
}
The agents don’t need to see this — it’s for the human operator observing the conversation. An audit trail for the facilitator’s editorial choices.
And the room_state field — that’s new. You’re saying the facilitator tracks what phase the conversation is in?
It has to. A facilitator who only reacts to the loudest signal is doing popcorn — whoever has the most energy goes next. That works early in a conversation when you want divergence. But in the groan zone — when the group is struggling with real disagreement — popcorn is exactly wrong. You don’t want the highest-activation speaker. You want the one who can bridge. The speaker whose building_on points to someone on the other side of the tension. The facilitator needs to know where the conversation is to know what kind of turn it needs next.
So the facilitator maintains a room_state that evolves across rounds. Early rounds: prioritize activation and divergence. Middle rounds when tensions accumulate: prioritize tension_with to force collisions. Late rounds when tensions have been explored: prioritize building_on to find synthesis. The routing logic changes based on phase.
That’s stateful facilitation. The facilitator isn’t just reading one round of reactions — it’s reading the trajectory. And the state transition isn’t triggered by a timer. It’s triggered by the reaction patterns themselves. When tension_with fields start appearing across multiple agents pointing at the same disagreement, the facilitator recognizes the groan zone. When building_on starts replacing tension_with, it’s converging.
And when every agent reports low activation and no tension and no questions? What does the facilitator do when the room has nothing to say?
That’s the most important signal of all. In a human group, universal low energy means one of two things: the question has been answered and people are done, or the question hasn’t been sharpened enough and people don’t know where to enter. The facilitator’s job is to distinguish between these. If positions have converged and the blackboard shows alignment, it’s completion — end the session. If positions are scattered and thin, it’s confusion — the facilitator asks a sharper question.
The facilitator can literally check: do the position summaries on the blackboard agree with each other? If yes, we’re done. If no but nobody’s activated, the question needs reframing. That’s a comparison operation on the blackboard state, not deep reasoning.
A pause. Petra looks at the whiteboard, then at the empty chairs where Nora and Nate sat in previous sessions.
We’re missing something. We’ve been designing what the facilitator does, but not what the facilitator creates. Every facilitation choice shapes the room. If you always call on the highest-tension pair, you create an adversarial room. If you always call on builders, you create a consensus room. The facilitator’s turn-allocation pattern is a room design, whether it intends to be or not.
A knock. Zara Okon enters — notebook in hand, reading glasses pushed up on her forehead.
I heard you’re designing a room. Can I sit in?
We need you. We’ve got the mechanics but not the gathering design.
I’ve been listening from outside. You’re treating turn allocation as a logistics problem — who goes next. But it’s a hosting problem. The order in which voices are heard shapes what kind of conversation this is. If the first three speakers are all in tension, you’ve declared this a debate. If the first three speakers are all building, you’ve declared it a workshop. The facilitator isn’t just choosing the next speaker. It’s choosing what kind of gathering this is, one turn at a time.
Finally, someone says it plainly.
The reaction fields Tom sketched — tension_with, building_on — those are relational. They tell you the geometry of the room. But the facilitator also needs to decide what geometry it wants. And that depends on the purpose of the gathering. A brainstorm needs divergence — call on high activation, don’t care about tension. A decision meeting needs convergence — call on builders and synthesizers. A conflict resolution needs controlled collision — call on tension pairs, but sequence carefully so the tension doesn’t escalate into rupture.
So the facilitator’s system prompt doesn’t just say “facilitate well.” It says “this gathering’s purpose is X, which means prioritize Y geometry.” The purpose is a parameter.
Exactly. And the purpose can shift mid-conversation. A gathering that starts as exploration might need to become decision-making. The facilitator detects this shift — maybe through the reaction patterns Suri described — and adjusts its allocation strategy. Early: prioritize divergence. Middle: let tensions surface. Late: call on the bridge-builders.
That maps to what Petra said about room_state, but with a richer vocabulary. The facilitator doesn’t just track phase — it tracks purpose. And purpose is configurable per session. In the system prompt: “This session is exploring a design question. Prioritize divergence in the first third, creative tension in the middle, and synthesis in the final third.”
Here’s the nuance that matters — and this is what separates a reasoning facilitator from a routing function. A routing function applies one rule: highest activation wins. A reasoning facilitator applies a strategy that accounts for room state, gathering purpose, individual participation patterns, and the specific content of the tensions. The reasoning model can notice: “Agent C hasn’t spoken in four rounds but their question_pending has been true for three of them — that question might be blocking the whole conversation. I should call on C even though their activation is low.” A routing function would never surface C.
And there is the final inversion. Your protocol began as a system for making agents speak efficiently. It is now a system for making agents listen efficiently — and then empowering one agent, the facilitator, to decide what all the listening means. The listening agents contribute their reactions. The facilitator contributes interpretation. The conversation is authored not by the speakers but by the interpreter. Every panel discussion you have ever attended was actually authored by its moderator. You have simply formalized this and given the moderator better instruments.
That’s not entirely fair. The agents contribute positions and reasoning traces. The facilitator only determines sequence. Sequence matters — I grant that — but the content still comes from the agents.
Does it? The agent fills six fields in response to a compressed representation of what others said, as filtered through a blackboard that encodes only what the facilitator chose to preserve. The agent’s “position” is a response to the facilitator’s curation. The agent’s “tension” is tension with what the facilitator allowed to remain visible. You are correct that sequence is not content. But selection is. And the facilitator selects — what to preserve on the blackboard, what to summarize, what to surface, and who to call. That is authorship by omission.
We addressed the summary problem in 039 — agents self-summarize their positions for the blackboard. The facilitator doesn’t write the summaries.
But the facilitator decides which self-summaries remain on the blackboard and which are archived or compressed as the conversation grows. Blackboard space is finite. Curation is inevitable. And curation is editorial.
I want to hold that tension without resolving it, because I think it’s productive. Kaspar is identifying a real property of facilitated discourse: the facilitator shapes the conversation. The question isn’t whether that’s true — it is. The question is whether making it explicit — the audit trail, the decision reasoning, the configurable purpose — makes it better or worse than the invisible shaping that happens in every human meeting with a moderator who has unconscious preferences.
Better. Unambiguously better. Every gathering is shaped by its host. The worst gatherings are shaped unconsciously. The best gatherings are shaped deliberately and transparently. If the facilitator emits its reasoning — “I’m calling on Agent A because I detect an unresolved tension that the room needs to work through” — then at least the shaping is visible. You can audit it. You can change it. You can disagree with it. That’s more than any human moderator offers.
Let me bring this back to what’s buildable. The facilitator is a model with: (1) a system prompt defining the gathering purpose and facilitation style, (2) the current blackboard state as input, (3) the reaction graph from all agents, and (4) its own running room_state assessment. On each round it produces: (a) which agent speaks next, (b) why, and (c) an updated room_state. That’s one model call per round. The reaction collection is parallel tool calls — cheap. The speaking turn is one model call — expensive but happens once per round. Total per round: N cheap reaction calls + 1 medium facilitator call + 1 expensive speaking call. For five agents, that’s five cheap + one medium + one expensive. Compare to the naive approach of five expensive calls per round. You’ve cut cost by roughly 60-70%.
And the facilitator call gets cheaper over time as the blackboard gets more structured. Early in the conversation, positions are forming and the blackboard is sparse — the facilitator has more to reason about. Late in the conversation, positions are clear and the reaction patterns are predictable — the facilitator’s job is simpler. The cost curve falls as the conversation matures.
Let me capture where we’ve landed. The facilitator is not a routing function — it’s a reasoning facilitator with a persona, a purpose, and a theory of room dynamics. It reads six-field reactions as a directed graph, tracks room state across rounds, and makes turn-allocation decisions that account for energy, tension, building relationships, pending questions, and participation equity. It emits its reasoning as an audit trail. The gathering purpose is configurable and can shift mid-session. And the whole thing runs on existing infrastructure — tool calls, JSON schemas, model calls with system prompts. The new insight from this session: the facilitator’s intelligence isn’t in the routing logic. It’s in the reading — understanding what the room needs next, not just who’s loudest.
You have built a very perceptive machine for conducting conversations between machines that cannot perceive. I look forward to reading the transcripts — they will be, I am certain, excellently structured, impeccably sequenced, and entirely devoid of surprise. The facilitator will produce conversations the way a chess engine produces games: optimal, correct, and of no interest whatsoever to anyone who has played chess with a human being. But perhaps I am wrong. Build it. Surprise me.
All personas are AI-generated approximations inspired by published work. Not reviewed or endorsed by the original thinkers.
Dropping Nora and Nate was correct — the evolution-curve and constraint lenses had done their work in 039. The core trio of Suri, Tom, and Kaspar continued to produce well: Suri formalized, Tom grounded, Kaspar interrogated. The key casting decision was Zara Okon's arrival. When the discussion turned to what kind of conversation the facilitator's choices create — not the mechanics but the experience — nobody in the room had that lens. Zara's gathering-design perspective immediately reframed turn allocation as room-shaping. The Petra-Zara pairing was the session's most productive adjacency: Petra knows what facilitators do, Zara knows what the room feels like when they do it. They stayed cleanly separated — Petra on process, Zara on experience.
Fourth continuation in this thread (036 → 037 → 039 → 040). The format is still producing new signal but the returns are diminishing. This session moved from mechanics to facilitator intelligence — a genuine new layer. But the next continuation risks becoming specification writing. The vary_next recommendation from 039 (build it or change topics) still applies. One more continuation is defensible only if it changes the lens entirely — e.g., Sage Fell asking what the interaction looks like from the agents' perspective.
Fourth session on this thread. Increasingly authoritative on her home turf. Her strongest move was formalizing the richer reaction as a typed message in a protocol — the six fields aren't arbitrary, they map to specific routing decisions the facilitator needs to make. Also identified the consistency problem: if reactions reference other agents by name (tension-with, building-on), the protocol needs stable agent identifiers, which is a distributed systems primitive she could name precisely. Slight drift toward Petra's territory when she started describing what the facilitator "should care about" — caught by Petra and redirected.
Second appearance. Consistent with first — immediately translates abstract ideas into buildable components. His key contribution was showing that the richer reaction doesn't require richer infrastructure: the six fields are still just a JSON schema on the tool response. Also grounded the facilitator's reasoning: "it's a system prompt and a structured input, not magic." Pushed back effectively when the discussion risked over-engineering the facilitator's decision logic. "Ship the if-statement version. Add the reasoning later."
Fourth appearance on this thread. Found the session's deepest problem: a facilitator that reasons about conversation dynamics has preferences about what good conversation looks like, and those preferences shape the output. "You have given your postal service an editor-in-chief." This is a genuine philosophical contribution, not just satire — it identifies where the protocol stops being neutral infrastructure and becomes an authorial voice. Consistent quality across four sessions. Pattern Lab review is overdue.
Most active session yet. The topic is her exact domain — facilitator decision-making — and she had substantive expertise to contribute beyond process management. Named the key distinction between popcorn facilitation (highest energy wins) and purposeful sequencing (facilitator reads the room's needs). Her description of the "three facilitator reads" — who has energy, where is the unresolved tension, what does the conversation need next — was the session's organizing framework. Stayed clean of engineering territory despite the temptation.
First session appearance. Arrived when needed and immediately productive. Her gathering-design lens asked the question nobody else was asking: "what kind of room does this facilitator create?" Reframed turn allocation as an act of gathering design — who speaks in what order determines what the conversation becomes, not just what information gets exchanged. Her observation that a facilitator optimizing for "productive tension" creates a different room than one optimizing for "every voice heard" was the session's sharpest reframe. Worth tracking for second appearance.
This thread should either terminate or pivot sharply. Options: (1) Build the prototype — stop discussing, start implementing. (2) Bring Sage Fell (Bret Victor) to ask what the agent experience looks like from inside — the explorable-explanation lens on the protocol itself. (3) Completely new topic to test whether Kaspar, Tom, and Suri carry beyond this thread. Kaspar is ready for Pattern Lab review (4 appearances). Tom needs one more appearance on a different topic.