Group chat & the blackboard pattern
Agents on a team have to do two things: share what they know, and decide who acts next. There are two classic ways to wire that — broadcast group chat, where everyone hears every message, and the blackboard, where agents read and write a shared workspace and a controller picks who fires. The choice drives how your context grows and how the system scales.
Written and reviewed by Shreyash Prashu Last reviewed
What you'll learn
- The two coordination substrates — message-passing group chat vs a shared blackboard
- Speaker-selection policies — round-robin, model-chosen, rule-based
- The blackboard pattern — knowledge sources, a shared workspace, a control shell
- Why broadcast chat grows context and how shared memory scales better
Before you start
Topology tells you the org chart — who reports to whom. It doesn’t tell you the mechanics: how agents actually exchange information, and how the system decides who acts next. There are two classic answers, and they scale very differently. Agents can talk — broadcast messages everyone hears — or they can share a blackboard — a common workspace they read and write while a controller picks who fires.
Group chat: everyone hears every message
The conversational model is a group chat: all agents share one message stream, and a selector decides who speaks each turn. The selection policy is the knob:
- Round-robin — fixed rotation; simple and predictable.
- Model-chosen — an LLM reads the conversation and picks “who is best suited to respond now?”; flexible but another call and another thing to trace.
- Rule-based — hand-written routing (after the coder, run the reviewer).
This is exactly what AutoGen’s GroupChat implements with its manager. It’s intuitive and easy to start with, but it has a built-in cost: everyone reads everything. Each broadcast lands in every agent’s context, so the token bill — and the noise each agent must wade through — grows with the conversation. For a long task with many agents, that gets expensive fast.
Blackboard: a shared workspace, not a transcript
The blackboard pattern (from classic AI — the Hearsay-II speech system) flips the model. Instead of broadcasting messages, agents — called knowledge sources — read from and write to a shared workspace (the blackboard). A control shell looks at the board’s current state and runs whichever knowledge source can now contribute. No agent has to read the whole transcript; it just reads the part of the board it needs.
# Blackboard coordination: each knowledge source fires only when its precondition
# is on the board. The control shell runs whoever can contribute — order-independent.
bb = {"raw": "2 + 3"}
def tokenize(bb):
if "raw" in bb and "tokens" not in bb:
bb["tokens"] = bb["raw"].split(); return "tokenize"
def compute(bb):
if "tokens" in bb and "answer" not in bb:
a, op, b = bb["tokens"]; bb["answer"] = int(a) + int(b); return "compute"
sources = [compute, tokenize] # deliberately listed out of execution order
log = []
while "answer" not in bb:
for ks in sources: # control shell: fire whichever precondition is met
if (fired := ks(bb)):
log.append(fired); break
print("fired order:", log)
print("final board:", bb)
fired order: ['tokenize', 'compute']
final board: {'raw': '2 + 3', 'tokens': ['2', '+', '3'], 'answer': 5}
Notice the control flow is driven by the board, not by a fixed script: compute is
listed first, but it can’t fire until tokenize has put tokens on the board, so the
order self-organizes. Agents coordinate through shared state rather than by addressing
each other — add a knowledge source and it simply starts contributing when the board is
ready for it.
Which to reach for
Group chat is the right start for a small team having a conversation — a coder, a reviewer, a tester hashing something out — where the dialogue itself is the work and the transcript is short. The blackboard wins when there are many contributors and a lot of intermediate state: each agent touches only its slice of the board, so context stays lean and you can add or remove knowledge sources without rewiring who-talks-to-whom. In practice many agent stacks use a hybrid — a shared scratchpad or memory (a lightweight blackboard) plus targeted messages — so agents share durable facts through state and use conversation only when they genuinely need to address each other.
In one breath
- Topology is the org chart; coordination is the mechanics — how agents share info and decide who acts next. Two classic substrates: group chat and blackboard.
- Group chat broadcasts every message to every agent; a selector picks the next speaker (round-robin, model-chosen, or rule-based) — this is AutoGen’s GroupChat.
- Its cost: everyone reads everything, so context and token spend grow with the conversation.
- Blackboard: agents (knowledge sources) read/write a shared workspace and a
control shell fires whoever the board is ready for — flow is driven by state, not a
fixed script (the demo self-orders
tokenizebeforecompute). - Use group chat for a small team in conversation; use a blackboard / shared memory when there are many contributors and lots of state — often hybridized in practice.
Quick check
Quick check
tokenize run before compute even though compute is listed first?Next
These are the coordination substrates beneath the topologies; the concrete conversational implementation is AutoGen’s GroupChat, and the durable shared state a blackboard relies on is agent memory.
Practice this in an interview
All questionsUse multiple agents when a task decomposes into distinct specialties or parallel subtasks that exceed one agent's context or reliability; avoid it when a single agent suffices, since multi-agent systems add coordination overhead, latency, cost, and error propagation. A supervisor architecture has an orchestrator routing work to specialized sub-agents, while a swarm lets peer agents hand off control to one another without a central coordinator.
Agents have transient working memory in the current context window and durable external memory, commonly organized as episodic, semantic, and procedural information. Context engineering selects and orders the right information for the limited window, while compaction compresses older state into a smaller, useful representation.
Tool calling extends the LLM's output space to include structured function invocations. The model emits a JSON object naming a tool and its arguments; the runtime executes the tool and feeds the result back as a new message. An agent is a loop that repeats this cycle — observe, think, act — until the task is complete or a stopping condition is met.
ReAct is a step-by-step control loop that alternates between reasoning, tool actions, and observations. Plan-and-Execute creates a broader plan before acting, while Reflexion adds feedback-driven critique and retry after a failed attempt; these patterns can also be combined.