"They built me a fleet of brilliant language models, then spent a year rediscovering that the hard part was getting us to agree on who does what. We could have told them. We are from the 1980s."
A Contract-Net Manager, Back in Fashion
The classical mechanisms of distributed artificial intelligence, built decades before large language models existed, are now the coordination layer that decides whether a multi-agent AI system works or collapses. When you wire several LLM agents together to solve a task, the model gives each agent flexible reasoning and natural-language communication, but it does not tell them how to split the work, where to store shared findings, who should take which subtask, or how to stay consistent when they disagree. Those are exactly the questions this chapter answered: distributed problem solving, blackboards, the contract-net protocol, distributed constraint optimization, coordination, and distributed belief. This closing section connects the old vocabulary to the new systems, shows the classical patterns composing into a modern agent workflow in runnable code, and summarizes the chapter's thesis: intelligence is the sixth axis of distribution, and DAI gives that axis its language.
Every earlier section of this chapter introduced a mechanism that, at the time, ran on a handful of hand-coded expert systems exchanging stilted messages over a slow network. The ideas were sound; the agents were brittle. A contract-net contractor could bid on a task only if a programmer had anticipated the task and written the bidding logic. A blackboard knowledge source could contribute only what its rigid rule base allowed. For thirty years the mechanisms outran the agents that were supposed to use them. What changed is the agent. A large language model is a general-purpose reasoner that can read a task description it has never seen, decide whether it is competent, communicate in plain language, and produce a structured result. Drop that capability into the old mechanisms and they spring to life, because the mechanisms were never the bottleneck; the flexible agent was the missing piece.
So this section is not a victory lap for old ideas. It is the argument that the hard problems of multi-agent AI, the ones engineers hit the moment they connect two agents, are the distributed-systems problems of this entire book, now operating at the level of reasoning rather than the level of gradients or bytes. Coordination overhead, consistency, communication cost, and partial failure do not disappear because the workers are intelligent; if anything they get subtler, because an intelligent worker can be confidently wrong in ways a numerical worker cannot. The good news is that DAI spent decades naming and studying these problems, and that vocabulary is what the rest of Part VI builds on.
1. The Mapping: Classical DAI to Modern Multi-Agent AI Beginner
The cleanest way to see the connection is a direct mapping from each mechanism in this chapter to the component it became in a modern agent stack. Table 27.9.1 lays out the correspondence. Read it as a translation dictionary: the left column is the language of 1985, the right column is the language of a 2025 multi-agent framework, and the two describe the same coordination problem.
| Classical DAI mechanism | Introduced in | Modern multi-agent counterpart |
|---|---|---|
| Distributed problem solving: decompose a goal into subtasks | Section 27.2 | Multi-agent LLM workflows that split a task across role-specialized agents (planner, researcher, writer, critic) |
| Blackboard: a shared workspace many knowledge sources read and write | Section 27.4 | Shared agent memory, scratchpads, and group chat history that every agent appends to and reads from |
| Contract-net protocol: announce, bid, award | Section 27.5 | Task routing and bidding among agents; a manager-agent delegating subtasks to the best-suited worker |
| Distributed constraint optimization and coordination | Sections 27.6 to 27.7 | The coordination layer of an agent team: resolving conflicting actions, avoiding duplicated work, allocating shared resources |
| Distributed knowledge and belief | Section 27.8 | Keeping a shared, consistent context across agents so they reason from the same facts and do not drift apart |
The mapping is not loose analogy. A modern "manager agent that delegates to worker agents" is a contract-net manager whose contractors happen to be language models; a "shared scratchpad" is a blackboard whose knowledge sources happen to reason in natural language; a "consistent shared context window" is the distributed-belief problem of Section 27.8 with tokens standing in for logical assertions. Figure 27.9.1 draws the same correspondence visually, so you can carry one picture rather than five separate facts.
A large language model makes one agent flexible: it can read a novel task, reason about it, and answer in natural language. It says nothing about how several such agents divide labor, share findings, route subtasks, resolve conflicts, or stay consistent. Those are coordination questions, and coordination is precisely what distributed AI studied for decades. That is why connecting two capable agents is easy and connecting twenty into a reliable system is hard: the difficulty was never the intelligence of one agent, it was the coordination of many, and DAI is the field that already owns that problem.
2. Why DAI Became Practical, and Why the Hard Problems Stayed Hard Intermediate
For most of its history, distributed AI was a field with elegant protocols and no agents worth running them. The contract-net protocol of Section 27.5 is a beautiful piece of design, but it needs contractors that can read an arbitrary task announcement and accurately assess their own fitness, and before LLMs, building such a contractor for any open domain was the entire research problem. Large language models removed that obstacle in one stroke. An LLM agent can parse a task it has never encountered, reason about whether it is suited to it, communicate its bid in language a manager can read, and carry out the work. The mechanisms that sat on the shelf for thirty years suddenly have agents capable of using them, which is why DAI moved from a historical curiosity to the operating logic of modern agent frameworks almost overnight.
What did not change is the cost structure. Every problem this book has studied at the level of bytes and gradients reappears at the level of reasoning, and Table 27.9.2 makes the parallel explicit. Coordination overhead is still the tax on distribution, only now a "message" is a few hundred tokens of natural language that costs real money and latency to generate, so a chatty agent team can spend more on coordinating than on the actual task, the agent-level echo of the communication tax from Section 1.1. Consistency is still hard, only now agents can hold contradictory beliefs expressed in fluent prose, the distributed-belief problem of Section 27.8 with the added hazard that a confident hallucination reads exactly like a fact. Failure is still the rule at scale, only now a failed worker does not crash; it returns a plausible, wrong answer that propagates through the blackboard until a critic catches it.
| Distributed-systems problem | At the level of bytes and gradients | At the level of reasoning agents |
|---|---|---|
| Communication cost | Bytes per all-reduce, network bandwidth | Tokens per message; coordination can cost more than the task itself |
| Consistency | Replicas must agree on state (Section 27.8) | Agents must share the same context and not drift into contradiction |
| Coordination overhead | Synchronization barriers, stragglers | Rounds of agent dialogue, an agent waiting on another's output |
| Partial failure | A worker crashes or stalls | An agent returns a confident wrong answer that looks correct |
This is the unifying claim of the whole book restated for Part VI. The machinery you built to make many machines behave like one coherent computation, the coordination primitives of Chapter 2, the communication accounting of Chapter 4, the optimization-under-communication-budget of Chapter 10, is exactly the machinery you need to make many agents behave like one coherent intelligence. The distributed-systems thinking does not get easier when the workers are smart; it becomes the load-bearing skill.
The contract-net protocol was published by Reid Smith in 1980, when "agent" meant a few hundred lines of Lisp on a minicomputer. Today you can find its announce-bid-award loop reimplemented, often by engineers who have never heard of it, at the core of "manager and worker agent" patterns in modern LLM frameworks. The lesson is not that the new engineers should have read the old papers, though it would not hurt. It is that coordination problems are timeless: change the agents from Lisp programs to trillion-parameter models and the right way to route a task among them is still the one a graduate student worked out in 1980.
3. What Classical DAI Got Right, and What LLMs Changed Intermediate
It helps to be precise about the division of labor between the old field and the new technology, because the two are easy to conflate. Classical DAI got the structure right. It correctly identified that a society of agents needs an interaction protocol (contract-net), a shared workspace (the blackboard), a way to resolve conflicting local choices into a globally good outcome (DCOP and coordination, Sections 27.6 to 27.7), and a discipline for keeping distributed beliefs consistent (Section 27.8). Those structures are not artifacts of 1980s technology; they are the load-bearing walls of any multi-agent system, and modern frameworks rebuild every one of them, usually without realizing they are following a fifty-year-old blueprint.
What LLMs changed is the content that flows through the structure. Classical agents communicated in narrow, pre-agreed message formats and reasoned with brittle symbolic rules; the structure was sound but the agents could only handle tasks their designers had foreseen. LLM agents communicate in open natural language and reason flexibly over tasks nobody anticipated, which makes the same structures suddenly general. The flip side is a new failure mode the old field never had to design around: a symbolic agent that could not do a task simply failed to fire a rule, whereas an LLM agent that cannot do a task may produce a fluent, confident, wrong answer. So the modern coordination layer inherits the classical structures and adds a new obligation, verification, which is why a "critic" or "reviewer" agent, an idea with no clean classical analogue, has become a standard role in agent teams.
4. A Runnable Workflow: Three Classical Patterns Composing Intermediate
The mapping is most convincing when you watch the patterns compose into one workflow. The program below takes a single goal, "produce a one-page technical brief," and runs it through three of this chapter's mechanisms at once: distributed problem solving decomposes the goal into role-typed subtasks (Section 27.2), a blackboard holds the shared results that later subtasks read from (Section 27.4), and a contract-net loop routes each subtask to the agent that bids lowest (Section 27.5). No language model is called; each "agent" is a role with a competence profile, so the coordination is visible in plain numbers. This is the skeleton of a modern multi-agent LLM workflow with the reasoning stubbed out, which is exactly what lets you see the classical machinery underneath.
INF = float("inf")
# Role-specialized agents. Each has a private per-capability cost (lower = better
# fit). In a real system these are LLM agents with system prompts like "you are
# the researcher"; here the role IS the capability profile.
AGENTS = {
"Planner": {"plan": 1.0, "research": 5.0, "analyze": 6.0, "write": 4.0, "review": 3.0},
"Researcher": {"plan": 6.0, "research": 1.0, "analyze": 3.0, "write": 5.0, "review": 4.0},
"Analyst": {"plan": 5.0, "research": 3.0, "analyze": 1.0, "write": 6.0, "review": 2.5},
"Writer": {"plan": 4.0, "research": 6.0, "analyze": 5.0, "write": 1.0, "review": 3.0},
"Critic": {"plan": 5.0, "research": 7.0, "analyze": 4.0, "write": 5.0, "review": 1.0},
}
class Blackboard:
"""Shared agent memory: a scratchpad of (key -> contribution) plus an
append-only event log, exactly the 27.4 blackboard control structure."""
def __init__(self):
self.entries = {}
def post(self, agent, key, value):
self.entries[key] = value
def read(self, key):
return self.entries.get(key)
def decompose(goal):
"""Distributed problem solving (27.2): split one goal into role-typed
subtasks with explicit data dependencies (which keys they need first)."""
return [
# (subtask id, capability, workload, dependencies on prior keys)
("outline", "plan", 2, []),
("gather", "research", 4, ["outline"]),
("interpret", "analyze", 3, ["gather"]),
("draft", "write", 3, ["outline", "interpret"]),
("critique", "review", 2, ["draft"]),
]
def contract_net(blackboard, agents, subtasks):
"""Announce -> bid -> award for every subtask (27.5). The manager holds no
global schedule; it compares the bids it receives, with a congestion penalty
so a busy agent prices itself out."""
allocation, load, total = {}, {a: 0 for a in agents}, 0.0
for task_id, cap, work, deps in subtasks:
for dep in deps: # only announceable once deps are posted
assert dep in blackboard.entries, f"missing dependency {dep}"
bids = {a: agents[a].get(cap, INF) * work + 0.5 * load[a] for a in agents}
winner = min(bids, key=bids.get) # AWARD the lowest finite bid
allocation[task_id] = winner
total += bids[winner]
load[winner] += work
ranked = sorted(bids.items(), key=lambda kv: kv[1])
bidstr = ", ".join(f"{a}:{c:.1f}" for a, c in ranked[:3])
print(f"announce '{task_id}' (needs {cap})")
print(f" bids -> {bidstr} ... AWARD -> {winner}")
context = {d: blackboard.read(d) for d in deps} # read dependencies
result = f"<{cap} output by {winner} from {sorted(context)}>"
blackboard.post(winner, task_id, result) # post result to the board
return allocation, total
goal = "Produce a one-page technical brief on a new topic"
bb, subtasks = Blackboard(), decompose("brief")
allocation, cost = contract_net(bb, AGENTS, subtasks)
print("\nFinal allocation:", {t: allocation[t] for t, *_ in subtasks})
print(f"Total coordination cost: {cost:.1f}")
print("Workflow output:", bb.read("critique"))
decompose) splits the goal, a Blackboard holds shared state, and contract_net routes each subtask by bidding. Replace each role's competence number with an actual LLM call and you have a real role-specialized agent team.announce 'outline' (needs plan)
bids -> Planner:2.0, Writer:8.0, Analyst:10.0 ... AWARD -> Planner
announce 'gather' (needs research)
bids -> Researcher:4.0, Analyst:12.0, Planner:21.0 ... AWARD -> Researcher
announce 'interpret' (needs analyze)
bids -> Analyst:3.0, Researcher:11.0, Critic:12.0 ... AWARD -> Analyst
announce 'draft' (needs write)
bids -> Writer:3.0, Planner:13.0, Critic:15.0 ... AWARD -> Writer
announce 'critique' (needs review)
bids -> Critic:2.0, Analyst:6.5, Planner:7.0 ... AWARD -> Critic
Final allocation: {'outline': 'Planner', 'gather': 'Researcher', 'interpret': 'Analyst', 'draft': 'Writer', 'critique': 'Critic'}
Total coordination cost: 14.0
Workflow output:
Notice what the output shows and does not show. It shows the coordination doing real work: the planner wins the outline, the researcher wins the gather, and each result lands on the blackboard for the next subtask to consume, so the dependency chain is honored without any agent holding a global plan. It does not show a language model, because the coordination is the point; swap each competence number for a system-prompted LLM and the same loop becomes a production agent team. That substitution is precisely the path the rest of Part VI takes.
You will rarely hand-roll the loop in Code 27.9.1. Three families of frameworks ship these exact mechanisms. LangGraph models the agent team as a graph whose nodes are agents and whose shared state object is the blackboard, so the dependency edges of decompose become graph edges. AutoGen gives you conversable agents and a group-chat manager that routes turns, which is contract-net awarding with a chat transcript as the shared memory. CrewAI is built directly on roles and tasks, a "crew" of role-specialized agents with a process that delegates, which is distributed problem solving plus task routing by another name. In each, the roughly forty lines of Code 27.9.1 collapse to a short declaration of agents and a state schema; the framework handles message passing, turn-taking, retries, and the shared-context plumbing.
# CrewAI: the same role-specialized workflow, declared not coded.
from crewai import Agent, Task, Crew, Process
planner = Agent(role="Planner", goal="Outline the brief", backstory="...")
researcher= Agent(role="Researcher",goal="Gather sources", backstory="...")
writer = Agent(role="Writer", goal="Draft the brief", backstory="...")
critic = Agent(role="Critic", goal="Review the draft", backstory="...")
crew = Crew(
agents=[planner, researcher, writer, critic],
tasks=[Task(description="Produce a one-page technical brief", agent=planner)],
process=Process.hierarchical, # a manager agent delegates: contract-net, productized
)
result = crew.kickoff() # the framework runs announce/route/share for you
Process.hierarchical is the manager-delegates-to-workers pattern, which is contract-net under a modern name.Who: An applied-AI team at a SaaS company building an autonomous "research and draft" feature from LLM agents.
Situation: They wired six role-specialized agents (planner, two researchers, analyst, writer, critic) into a free-form group chat where any agent could speak at any time.
Problem: Latency and token bills ballooned. The agents re-explained context to each other every turn, two researchers fetched the same sources, and the team argued in circles before converging, when they converged at all.
Dilemma: Add more agents and a smarter model to break the deadlock, the intuitive fix, or impose structure on how the agents coordinate, which felt like a step backward toward rigid pipelines.
Decision: They imposed classical structure: a single blackboard as the source of truth so agents read shared findings instead of re-deriving them, and a contract-net manager that awarded each subtask to exactly one agent, killing the duplicated research.
How: They replaced the free-for-all chat with a LangGraph state graph (the blackboard) and a router node that delegated subtasks by fit, the Code 27.9.1 pattern in production form.
Result: Token cost per completed brief fell by roughly two thirds and end-to-end latency by half, because the coordination overhead, not the reasoning, had been the bottleneck all along.
Lesson: When a multi-agent system is slow or incoherent, the cure is usually a coordination mechanism from this chapter, not a bigger model. Structure beats horsepower at the coordination layer.
5. Closing the Chapter: Intelligence as the Sixth Axis Beginner
This chapter opened the sixth and final axis of distribution from Section 1.1: distributing intelligence itself. The first five axes spread data, training, the model, and inference across machines, then coordinated the cluster that holds them. This one spreads the decision-making, the reasoning, the goal-directed action, across many agents that must act as one. Distributed AI is the field that gives this axis its vocabulary and its mechanisms, and every section of this chapter contributed a piece of that vocabulary. The rest of Part VI is the deep treatment of each piece.
From here the story continues outward. Chapter 28 supplies the game-theoretic foundations, the equilibria and mechanisms that explain when self-interested agents will cooperate and how to design incentives so they do. Chapter 29 develops full multi-agent systems: negotiation, auctions, and the task-allocation protocols that generalize the contract-net you met here. Chapter 30 turns coordination into a learning problem with multi-agent reinforcement learning, where agents learn to cooperate rather than being told how. Chapter 31 scales to swarms, where simple agents produce collective intelligence with almost no explicit coordination. And Chapter 32 brings it home to today's systems with distributed agent orchestration, the engineering of LLM agent teams at production scale, where the blackboards and contract-nets of this chapter become LangGraph graphs and AutoGen group chats. The thread you have been pulling, that coordination is the hard part and DAI named it first, runs through all five.
Intelligence is the sixth axis of distribution, and it is the one where the book's central tension is sharpest. Every form of distribution buys capability and pays a coordination tax; for agent teams the capability is general reasoning and the tax is rounds of expensive natural-language dialogue, possible inconsistency, and confidently wrong workers. The mechanisms that pay that tax efficiently, distributed problem solving, blackboards, contract-net, DCOP, coordination, and distributed belief, are not new inventions of the LLM era. They are the distributed-systems disciplines of Chapter 2 onward, lifted to the level of reasoning. The book's thesis, that scale-out is the engineering of many parts behaving as one coherent system, reaches its final and most literal form when the parts are themselves intelligent.
The classical mechanisms of this chapter are the active research frontier of multi-agent LLM systems. Orchestration frameworks have consolidated fast: AutoGen (Wu et al., 2023, with a major v0.4 actor-model rewrite through 2024 to 2025), LangGraph, and CrewAI each productize distributed problem solving, shared memory, and task routing, and the open question is which coordination topology, hierarchical manager, flat group chat, or learned routing, minimizes the token-and-latency tax for a given task. A second thread studies emergent behavior in larger agent societies: generative-agent simulations (Park et al., 2023 and follow-ups) and "society of mind" style debates where multiple agents critique each other to improve factuality, a direct descendant of the distributed-belief reconciliation in Section 27.8. A third measures and attacks the failure modes Table 27.9.2 names, surveys of why multi-agent LLM systems fail point squarely at coordination breakdowns, inconsistent shared context, and unverified outputs, which is to say the field is rediscovering, with experiments, that the hard problems are the distributed-AI problems this chapter laid out.
Intelligence is the sixth axis of distribution: a modern AI system distributes not only its data, training, model, and inference but its decision-making, across many agents that must reason and act as one. Distributed artificial intelligence is the field that supplies the vocabulary and the mechanisms for that axis. This chapter built them in order: distributed problem solving decomposes a goal across agents (Section 27.2); centralized, decentralized, and hybrid control architectures decide who holds authority (Section 27.3); the blackboard gives agents a shared workspace (Section 27.4); the contract-net protocol routes tasks by announce-bid-award (Section 27.5); distributed constraint optimization and coordination resolve conflicting local choices into globally good outcomes (Sections 27.6 to 27.7); and distributed knowledge and belief keep the agents reasoning from a consistent view of the world (Section 27.8). Large language models did not replace any of these; they supplied the flexible, general-purpose agents the mechanisms always assumed, which is why every one of them now runs at the heart of a multi-agent LLM framework. The coordination problems, overhead, consistency, communication cost, and failure, are the distributed-systems problems of this whole book, now operating at the level of reasoning. Modern multi-agent AI rests on this classical foundation, and the rest of Part VI builds upward from it.
Pick one modern multi-agent framework (LangGraph, AutoGen, or CrewAI) and read its quickstart. For each of the five rows of Table 27.9.1, name the specific framework construct that plays the role of the classical mechanism (for example, "in LangGraph the shared state object is the blackboard"). Where a framework has no clean counterpart for a row, say so and explain what it does instead. Conclude with one coordination problem from Table 27.9.2 that the framework leaves entirely to the developer.
Extend Code 27.9.1 so that every announce, bid, and blackboard read or write costs a fixed number of simulated "tokens." Run the workflow and report the total coordination tokens spent versus the number of subtasks actually completed. Then add three more redundant agents that bid on every task but never win, and rerun. By how much does the coordination cost grow even though the work done is identical? Relate your finding to the communication-cost intuition from Chapter 4: more participants raise coordination cost even when they add no useful work.
In Code 27.9.1, the blackboard is a single shared dictionary, so every agent reads identical state, the easy case for consistency. Argue what changes if each agent instead kept a private local copy of the blackboard and synchronized only occasionally (the realistic case for geo-distributed or rate-limited agents). Connect your analysis to the distributed-belief discussion of Section 27.8 and to the consistency models of Chapter 2: which inconsistencies would a "critic" agent need to catch, and which would silently corrupt the final brief?
These projects turn the chapter's mechanisms into working code on a real allocation or coordination task. Each is self-contained and runnable on a single machine in pure Python; scaling any one of them across processes or adding LLM agents is the natural extension.
- A contract-net task allocator for a real fleet. Model a small fleet (delivery drivers, warehouse robots, or cloud workers) with heterogeneous capabilities and current loads, then implement the full announce-bid-award protocol of Section 27.5 with a congestion penalty so busy agents bid higher. Compare its total cost and load balance against a random-capable baseline and a greedy nearest-first heuristic across many randomized instances, and report when contract-net wins and when it ties the greedy rule. Extension: make each contractor an LLM agent that reads a natural-language task description and emits a structured bid.
- A DCOP solver for a shared-resource problem. Take a real allocation task with constraints, conference-room scheduling, channel assignment for wireless devices, or shift assignment, and encode it as a distributed constraint optimization problem (Section 27.6). Implement a local message-passing solver (the distributed stochastic algorithm or max-sum) where each agent owns one variable and exchanges only with its constraint neighbors, and measure how solution quality and message count scale as you add agents. Compare against a centralized solver to quantify the price of decentralization.
- A blackboard-coordinated multi-agent pipeline. Build the Code 27.9.1 workflow into a real research-and-write pipeline backed by an LLM, with role-specialized agents (planner, researcher, writer, critic) sharing a blackboard and a manager that routes subtasks by contract-net. Instrument it to log every message and measure the coordination tax (tokens and rounds) against task quality, then experiment with topologies: free-form group chat versus strict hierarchical routing versus a debate among critics. Report which topology gives the best quality per token, the empirical question at the heart of the Section 5 research frontier.