Multi-Agent Collaboration

The first nine chapters focused on a single Agent: first building its context, knowledge, tools, and interaction capabilities, then using evaluation, post-training, and continual evolution to improve it over time. This chapter advances the question from “How do we build and improve one Agent?” to “How do we organize multiple Agents?”—so that division of labor, communication, and mutual verification can tackle tasks that are difficult for one Agent to carry alone.

OpenAI once proposed a five-level scale of AI capabilities: Level 1, Conversationalists; Level 2, Reasoners; Level 3, Agents; Level 4, Innovators; and Level 5, Organizations. Multi-agent collaboration is often presented as one path to Level 5. Here, however, "Organizations" denotes a capability level—AI that can do the work of an entire organization—rather than an architectural requirement. A sufficiently powerful single Agent could, in principle, reach it as well. In today's engineering reality, however, a single Agent remains constrained by its model's capabilities and context window.

Getting multiple Agents to work together is about far more than letting specialists with different expertise "cover each other's gaps." The more fundamental point is this: the intelligence of a group can exceed that of any individual. Human civilization is the proof—one person's intellect is limited, yet through division of labor, collaboration, debate, and the accumulation of knowledge across generations, human society as a whole exhibits intelligence far beyond any single genius. Agent groups may give rise to the same kind of collective intelligence: even if each Agent is only as capable as a human expert, a well-organized group could surpass the combined capabilities of all human experts. In From AGI to ASI, Google DeepMind lists "large-scale multi-agent collectives" as a key pathway toward superintelligence (ASI)—just as human general intelligence aggregates into societies and organizations that transcend individuals, the collective intelligence of many AGI-level Agents working together may exhibit cognitive capabilities far beyond the simple sum of its members¹. Multi-agent collaboration, then, is not merely an engineering workaround for a single model's context window and capability limits—it may be a fundamental path from "expert-level AI" toward "surpassing humanity as a whole."

A Classification Framework for Multi-Agent Collaboration

Building a multi-agent system starts with two core design dimensions, which together determine its basic architecture and implementation.

Dimension 1: Shared vs. Non-Shared Context

This is the most fundamental architectural decision, determining how information is passed between multiple Agents.

Shared context means that a subsequent Agent receives the complete conversation history and trajectory (as defined in Chapter 1) of the preceding Agent. When the system prompt and tool set change at each stage, the system treats the new stage as a different Agent because its identity, responsibilities, and capabilities have changed, even though it retains all the memory of its predecessor. For example, after a requirements analyst writes a requirements document, the developer receives not only the document but also the full record of communication between the analyst and the user. The developer assumes a new role while retaining all prior context. The advantage is that no information is lost; each Agent can review details from any previous stage. The challenge is that the context can expand rapidly.

Non-shared context means that each Agent maintains an independent context and conversation history and cannot directly access the other Agents' work traces. This is like collaboration between different departments: everyone works independently at their own desk, exchanging information through shared documents and meeting minutes rather than constantly watching each other's screens. This model offers better modularity and isolation; each Agent only needs to focus on information relevant to its own responsibilities. The system is also easier to extend and maintain—adding a new Agent does not require modifying the internal logic of existing Agents, only defining interfaces and data formats.

Since Agents do not share context, information must be passed through explicit communication mechanisms. Classic distributed systems settled this question long ago: operating-systems textbooks tell us that inter-process communication (IPC) ultimately comes in just two paradigms—shared memory (one side writes and the other reads the same block of storage) and message passing (data is explicitly sent to the other side). Communication mechanisms between Agents fall within these same two paradigms. There are three common methods:

• Tool call parameters: Wrap the downstream Agent as a tool, then pass structured data through its parameters; this is suitable for scenarios requiring well-typed, clearly structured data.
• Shared file system: Agents exchange information by reading and writing intermediate artifacts (documents, code, etc.) in a shared directory, suitable for scenarios with large artifacts or where persistence is needed.
• Message bus: A dedicated intermediary that passes messages between Agents. Agents do not call each other directly but send messages to the bus, which forwards them to the target Agent.

Mapped onto the two IPC paradigms, the shared file system corresponds to "shared memory," while tool call parameters and the message bus are forms of "message passing." Tool parameters are delivered synchronously with a call; messages on a bus are delivered asynchronously through an intermediary. Each paradigm has its trade-offs. Go has a widely quoted maxim: "Do not communicate by sharing memory; instead, share memory by communicating."

Dimension 2: Collaboration Topology

The second dimension is collaboration topology: the structure through which control and information flow among Agents. There are three typical topologies:

• Peer Collaboration Pattern: A small number of Agents (typically 2-3) interact as equals, forming an iterative improvement loop—like writing a paper where one person drafts it and another annotates and revises it, with the quality after several rounds far exceeding what one person could achieve alone.
• Manager Pattern (Orchestration Pattern): A centralized Manager Agent is responsible for task planning and scheduling, while multiple sub-agents each handle specific subtasks—like a project manager leading several specialized engineers on a project.
• Decentralized Pattern: There is no runtime central controller; Agents communicate with each other like humans to collaborate on tasks.

Terminology: Graph Engineering. The term "Graph Engineering," which became popular in July 2026, generally refers in today's Agent context to explicitly designing an execution graph: nodes are Agents, ordinary programs, or human decisions; edges define task dependencies, conditional routing, and failure paths; and structured state flows between nodes. The "collaboration topology" discussed in this chapter is the multi-agent subset of that idea—peer collaboration, manager orchestration, and decentralized handoffs are different graph topologies. Because the name is still new and is easily confused with knowledge graphs, GraphRAG, and execution traces, this book continues to use the more stable terms "collaboration topology" and "orchestration" as its primary vocabulary.

The detailed design and applicable scenarios for each pattern will be discussed in dedicated subsections later.

When Is Multi-Agent Truly Better Than a Single Agent?

Before diving into specific collaboration architectures, let's answer a more fundamental question: When are multiple Agents truly needed, and when is one enough? The answer will serve as a reference point for every engineering approach that follows. A series of recent studies converges on a clear framework—and the core criterion is a single question: Does the collaboration provide information that a single Agent could not obtain while producing its answer?

Table 10-1 shows which collaboration modes introduce new information and helps assess whether multi-agent collaboration offers substantive value over a single Agent.

Table 10-1 Information Gain Comparison of Multi-Agent Collaboration Modes

Collaboration Mode	Introduces New Information?	Effect
Self-review by the same model (re-reading its own output)	No	Usually ineffective or even harmful
Different Agents debating the same text	No	Comparable to a single Agent with equal compute
Reviewer uses test execution results to review code	Yes (execution feedback)	Significant improvement
Reviewer uses rendered screenshots to review frontend/PPT code	Yes (visual feedback)	Significant improvement
Reviewer uses external tools to verify facts	Yes (tool feedback)	Significant improvement

The 2025 RLEF paper (Reinforcement Learning from Execution Feedback)² found that training a model via reinforcement learning to use code-execution feedback for iterative improvement significantly outperformed independently sampling the model multiple times. The key is that each iteration introduces real execution results (compilation errors, test failures, runtime exceptions)—information that did not exist when the model wrote the code. For webpage-generation tasks, the 2025 WebGen-Agent study³ reported that multi-level visual feedback, combining screenshots with vision-language-model descriptions, improved Claude 3.5 Sonnet's benchmark performance from 26.4% to 51.9%, nearly doubling it.

This framework helps resolve an apparent contradiction: some academic studies find that a single Agent is sufficient, while multi-agent systems often perform better in engineering practice. The studies often test multiple Agents that inspect and discuss the same text, as in debate, whereas effective engineering systems commonly add external feedback from code execution, visual rendering, or tools. Only the latter introduces new information. Nearly all effective uses of the three architectures discussed later—peer collaboration, orchestration, and decentralization—can be understood through this criterion.

Anthropic's 2026 vulnerability-discovery experiment provides one example. Forty-five Agents coordinated their searches through a shared forum, reviewed one another's findings, and submitted results to a separate arbiter Agent. The coordinated swarm found 266 vulnerabilities using 27 million tokens, while independently parallel Agents found only 21 using 6.5 million tokens. In an open search space, communication lets a multi-agent system shift its attention dynamically and develop specializations, trading a larger token budget for broader coverage and more varied discovery paths.⁴

Step Budget and Agent Performance. A related question is how an Agent's step budget—the number of tool calls or iteration rounds it may use—affects performance. More steps might seem certain to help: with 30 steps, an Agent may have time only to implement core functionality, whereas 300 steps allow it to plan, implement, test, and refine. However, the 2025 Google paper Budget-Aware Tool-Use Enables Effective Agent Scaling reached a counterintuitive conclusion: simply giving an Agent more steps does not guarantee better performance. Standard Agents lack "budget awareness"; even with 300 steps, they tend to conduct shallow searches and quickly reach a plateau. To use additional steps effectively, Agents need a mechanism that adapts their strategy to the remaining resources, exploring broadly at first and narrowing their focus later. The 2026 BAVT (Budget-Aware Value Tree Search) approach further introduced step-level value evaluation, adjusting the balance between exploration and exploitation according to the proportion of the budget remaining. As the budget decreases, the Agent shifts from broad exploration to deeper investigation.

These findings have direct implications for multi-agent system design. For example, in the orchestration pattern, the Manager Agent should not simply distribute tasks to sub-agents and wait for results. Instead, it should dynamically allocate step budgets based on task complexity—simple subtasks get fewer steps; complex subtasks get ample steps. It should also guide sub-agents to use these budgets wisely (plan first, then implement, then test, then improve), rather than diving straight in.

One more consideration must come before any design decision: cost. Parallel exploration and iterative refinement cost money—Anthropic has disclosed that its multi-agent research system consumes about 15 times the tokens of a normal conversation, and that token usage alone explains about 80% of the performance difference. The gains from a multi-agent system must therefore be large enough to justify costs that may be several times, or even an order of magnitude, higher; otherwise, a well-tuned single Agent is usually the better bargain.

Multi-Agent Collaboration with Shared Context

In multi-agent collaboration with shared context, each stage is an independent Agent (with its own system prompt and tool set), but it inherits the complete trajectory of the preceding Agent—much like a colleague taking over a shift who can leaf through every work log the predecessor left behind. The core advantage of this inheritance-based collaboration is zero information loss: every Agent can review details from any previous stage. The challenge is keeping the current Agent focused on its own responsibilities rather than distracted by the mass of inherited history.

In complex tasks, an Agent's role and responsibilities may change significantly across stages. If a single static system prompt is used throughout, it will either be too general or become an unwieldy collection of instructions. Multi-stage role switching changes the system prompt and tool set according to the current stage, allowing the Agent to work in the most appropriate role.

The key architectural choice is whether role guidance is carried by a replacement system prompt or by a loaded Skill. The former can enforce a hard tool boundary, but changes the request prefix at every switch. The latter keeps the static prefix stable and appends SKILL.md to the trajectory, which is usually friendlier to KV/prompt caching; a Skill remains behavioral guidance, so sensitive or side-effectful tools still require a code-enforced Harness policy gate.

Choice	Role guidance	Tool visibility	Context/KV-cache effect	Constraint strength
transfer_to_agent	Replace the system prompt and usually the tool set	Only the current role's tools	Each switch changes the request prefix and usually invalidates caching from that point	Strong: out-of-scope tools can be absent from the schema
Skill	Keep a Skill directory in the fixed prompt and append SKILL.md on demand	Usually the full catalog, or a stable search entry point	The static prefix stays stable; Skill text is appended to the trajectory	Weak: a Skill is an instruction, not a permission boundary

When the role difference comes mainly from knowledge, procedure, and writing style, prefer a Skill; when it involves permissions, tool isolation, compliance boundaries, or a class of actions that must be forbidden at run time, use an independent Agent or the transfer_to_agent tool, and restrict the tool calls with code at the Harness layer.

Experiment 10-1 ★★: Shared-context role switching—system prompt versus Skill

Both paths use the same model, task, tools, role guidance and complete shared trajectory. The task is to find China's 2021–2023 new-energy vehicle sales, calculate CAGR, and write a Chinese investor summary of no more than 120 characters.

Path 1: system-prompt switching. Five roles—triage, research, coding, data_analysis and writing—each expose only their dedicated tools plus transfer_to_agent. A handoff saves history, loads the target prompt and tool set, and resumes execution.

Path 2: Skill. The system prompt and full tool catalog remain fixed. The model calls load_skill(name) and receives the same role document as a tool result in the shared trajectory. The static prefix remains unchanged, but hard permissions are enforced by Harness rules.

The two paths should perform the same retrieval, calculation and length check. They differ in the carrier of role guidance and in the resulting tool boundary; a smoke trace alone cannot establish which path is superior.

Multi-Agent Collaboration Without Shared Context

In an architecture without shared context, each Agent operates as an independent entity with its own context, trajectory, and state. Agents cannot directly access one another's internal context; collaboration relies entirely on explicit, structured data transfers through the three communication mechanisms introduced at the beginning of this chapter: tool call parameters, a shared file system, and a message bus.

Earlier in this chapter, we compared the communication mechanisms to forms of inter-process communication and shared versus isolated context to threads versus processes. This analogy can be extended further (Table 10-2):

Table 10-2 Correspondence Between Multi-Agent Systems and Operating Systems

Operating System	Multi-Agent System
Program (executable file)	Static prefix (system prompt + tool definitions)
Process memory	Trajectory
CPU	LLM
Kernel	Agent runtime
System call	Tool call
fork (create child process)	spawn_subagent
kill (send signal)	cancel_subagent
ps (list processes)	list_agents
Exit code and wait()	Structured summary returned by the sub-agent
Shared memory / message passing	Shared file system / message passing

This abstraction is nothing new: private state, asynchronous messages, and the ability to create new members are precisely the basic setup of the 1970s Actor model⁵. A multi-agent system can therefore be viewed as an LLM-based version of the Actor model, and much of the accumulated knowledge from operating systems and distributed systems applies directly.

This process-style isolation brings several practical engineering benefits: each Agent can be developed and tested independently, new capabilities can be added without touching existing code, and multiple Agents can execute concurrently without contention over shared context.

However, not sharing context also has costs. The most obvious is the information synchronization problem: how do Agents maintain a consistent understanding of the task state? Will information be lost or duplicated during transfer? Debugging also becomes more difficult—when problems arise, logs from multiple Agents must be reviewed to piece together the complete execution process. These issues make the design of interface specifications, data formats, and communication protocols critically important.

Explicit collaboration without shared context relies on two topology-independent infrastructures. The first is the shared file system, the persistent medium through which Agents exchange artifacts with one another and with the user, forming the data plane of collaboration. The second is the communication and control mechanism, which supports message passing, status queries, execution termination, and resource scheduling between Agents, forming the control plane of collaboration. The three topologies below are all built on these two foundations.

The File System from an Agent's Perspective

At the beginning of this chapter, the "shared file system" was listed as one of the three communication mechanisms for architectures without shared context. In a real system, the file system an Agent accesses is not a single storage system but a virtual file system in which storage systems with different sources, lifecycles, and permissions are mounted under one directory tree. The Agent accesses them through unified read_file/write_file/list_dir interfaces, while the underlying layers may be local temporary disks, persistent object storage, third-party cloud drive APIs, or read-only system resource packages. Clearly defining the composition of this directory tree—the visibility and lifecycle of each area—is a prerequisite for designing multi-agent collaboration: a significant portion of concurrency conflicts and information leaks stem from mixing areas that should be isolated. This directory tree amounts to the Agent's address space, and the four types of areas are memory segments with different permissions: some private and writable, some shared among multiple parties, and some read-only. The operating system's protection philosophy applies here as well: isolate by default and declare sharing explicitly. In a mature multi-agent system, the file system typically consists of the following four types of areas:

A mature multi-Agent system's filesystem is usually made up of the following four kinds of area:

I. Agent-Specific Workspace (Scratchpad). A private directory exclusive to each Agent instance, storing intermediate artifacts, temporary files, drafts, and debug logs. Its lifecycle is tied to the instance and is invisible to other Agents and users. Isolating the scratchpad serves two purposes: preventing temporary files from multiple Agents from overwriting each other, and keeping the main Agent's context lean—the trial-and-error process of sub-agents remains in their own workspace, with only the final artifact submitted to the shared space. This is the storage-level counterpart of Chapter 4's principle that sub-agents return structured summaries rather than full trajectories.

II. Multi-Agent Shared Workspace. A collaboration area that multiple Agents can read and write, and that is visible to the user. It is the primary medium for exchanging artifacts between Agents in architectures without shared context: the Glossary Agent writes the term list, and the Translation Agent reads from it; users can also upload source files and download final deliverables here. Its lifecycle is tied to the entire task and requires persistence. As an area for concurrent reads and writes by multiple parties, it is a hotspot for concurrency conflicts—mechanisms such as optimistic locking and worktree isolation operate here, as detailed under "Failure Mode One" later in this chapter. Chapter 4's use of a volume mount at /workspace/shared to connect the main Agent, virtual computer, and virtual phone is a typical implementation of this layer.

III. Mounted External Resources. Third-party information sources authorized by the user—Google Drive, Notion, Dropbox, enterprise wikis, etc.—are mapped to mount points in the file system (e.g., /mnt/gdrive) via adapters. An Agent accesses a Notion document by reading a file; the underlying adapter calls the corresponding API. Three characteristics distinguish this layer from local storage and must be explicitly handled during design: access is constrained by external permissions (the user's permissions in the source system determine the Agent's visibility), latency is higher and consistency is weaker (each read involves a network round trip, and external changes may not be immediately visible, so the data should be treated as eventually consistent), and access is primarily on-demand and read-only (writing back to external sources must be done cautiously, as erroneous writes could contaminate the user's real data). The unified file interface means the Agent does not need a custom tool for each data source, but it also masks these performance and security differences. Therefore, read-only/writable status, timeouts, and credential boundaries must be explicitly managed at the mount level.

IV. Built-in System Resources. A resource package pre-installed by the system and shared read-only with all Agents. Typical examples are the Skills introduced in Chapters 2 and 4—knowledge documents and scripts organized as files, mounted at paths like /skills, accessed via progressive disclosure (index first, then expand on demand). Other examples include reference manuals, template libraries, and shared tool definitions. This layer is globally shared, read-only, stable across sessions, and can be read concurrently by all Agents without concurrency control.

Figure 10-2 illustrates how these four area types are uniformly mounted under a single directory tree: the Agent accesses the entire tree through a unified interface, users upload and download files from the shared space, external data sources are mounted via adapters, and built-in system resources are provided read-only.

Table 10-3 compares these four area types across four dimensions—visibility, lifecycle, read/write permissions, and concurrency control—serving as a checklist for file system layout design.

Table 10-3 Four area types of the Agent Virtual File System

Area	Visibility	Lifecycle	Read/Write	Concurrency Control
Agent-Specific Workspace	The owning Agent only	Destroyed with the Agent instance	Read/Write	Not needed (private)
Multi-Agent Shared Workspace	All collaborating Agents and the user	Persists for the task duration	Read/Write	Required (optimistic lock / worktree)
Mounted External Resources	Depends on external authorization	Determined by the external source	Mostly read-only, writes require caution	Managed by the external source
Built-in System Resources	All Agents	Stable across sessions	Read-only	Not needed (read-only)

The value of the "file path as a universal interface" lies in treating a path as the unit of exchange. Whether Agents exchange artifacts, a main Agent hands input to a sub-agent, or organizations collaborate through A2A, they pass a lightweight path string rather than loading the file's contents into the context window (Chapter 4). This aligns with Chapter 5's concept of "the file system as the Agent's hub," which describes how a single Agent uses the file system to host memory and capabilities. Here, the same abstraction extends to multiple Agents: a virtual directory tree mounting private, shared, external, and built-in storage provides the storage foundation for multi-agent collaboration.

Communication and Control Between Agents

While the file system solves the problem of artifact exchange between Agents, collaboration also requires a control plane. This is exactly where the lifecycle rows of Table 10-2 come into play: the tool primitives given in Chapter 4—creating (spawn_subagent), sending messages (send_message_to_subagent), canceling (cancel_subagent), and discovering (list_agents)—correspond to fork, message, kill, and ps in the process world. This section does not repeat the interface definitions but focuses on four often-overlooked capabilities essential for multi-agent collaboration.

I. Message Passing. The simplest form is point-to-point: Agent A directly calls send_message_to_agent_b(content). This is suitable for scenarios with a fixed topology and a small number of Agents (e.g., the phone + computer dual-agent setup of Experiment 10-3 in this chapter). When the number of Agents increases and asynchronous parallelism is required, the number of point-to-point connections grows quadratically with the number of Agents, and both sender and receiver must be online simultaneously. In such cases, a message bus should be used (detailed later in this chapter under "Parallel Coordination Pattern"): Agents publish messages to the bus, which forwards them based on subscriptions, so the sender does not need to know the subscribers. Whether point-to-point or via a bus, messages should typically carry a structured envelope: sender ID, target (specific Agent or broadcast), message type (e.g., task_assigned/status_update/result/terminate), and a JSON payload. A unified envelope format ensures reliable routing and parsing by the receiver and makes the collaboration chain traceable—a key aspect of debugging multi-agent systems.

II. Status Query. This is the most underestimated part of the control plane. Once a main Agent has dispatched a sub-agent, it needs visibility into the sub-agent's progress; otherwise, it can neither decide whether to keep waiting nor intervene when the sub-agent gets stuck. An intuitive approach is to borrow from RPC and define a get_subagent_status(agent_id) query interface that returns "running/completed/failed" plus a progress percentage. But such a pull interface turns out to be far less useful than expected: a sub-agent starts executing the moment it is created and runs until it completes or fails. It does not cycle through a series of queued states the way jobs in a traditional batch system do, just as Unix programming rarely needs to poll another process by its PID for running status. Polling also carries an inherent dilemma: poll too often and you waste tokens; poll too rarely and you react late. A more natural way to obtain status is to return to the two communication paradigms introduced at the beginning of this chapter.

Getting status via message passing. The main Agent simply sends the sub-agent a message: "How's it going?" The sub-agent replies at an opportune moment. Everything is asynchronous: sending the message does not block the main Agent's own execution, and when—or whether—the other side replies is a separate matter, just as a manager asks a subordinate for progress via instant messaging without requiring them to drop everything on the spot. Conversely, the sub-agent can also proactively send a message to report when it reaches a milestone; if the system already has a message bus, this is simply publishing a status_update to the bus (the "real-time monitoring" of Experiment 10-4 is this form). Whether status is requested explicitly or reported proactively, the status carried in the message should adopt a uniform state-machine vocabulary (executing, needs input, completed, failed)—the A2A protocol later in this chapter standardizes the task lifecycle into exactly such a set of states.

Getting status via the shared file system. The most thorough form is trajectory persistence: as it executes, the sub-agent serializes each trajectory event to JSON and appends it to a filesystem log file—usually one file per session, one event per line, i.e., JSONL. The trajectory, defined in Chapter 1, is the complete sequence of user messages, model replies, tool calls, and results. The main Agent needs no status-reporting protocol; by reading this file directly, it can inspect the sub-agent's entire execution: which tool it is calling, what happened in its most recent step, and whether it is stuck in a loop of repeated failed retries. In process terms, this resembles reading another process's memory directly. It does not occupy the sub-agent's context, does not depend on its cooperation, and offers the finest observation granularity.

But trajectory persistence should not be the main channel for passing information between Agents. A trajectory easily runs to tens of thousands of tokens, and the main Agent still has to distill it after reading—costly in both time and tokens. In most situations the more sensible choice is to agree on a progress file: when starting a sub-agent, the main Agent stipulates "write your progress to progress.md," the sub-agent updates that task list as it completes each item, and the main Agent can read this lightweight file at any time to see how things stand. This is equivalent to two processes carving out a small, agreed-format status region in shared memory: what is exposed is distilled progress, not the whole of memory. The progress file also enables stuck detection: if the last-modified time of progress.md (or the trajectory file) has not changed for more than N minutes, the sub-agent can be judged inactive and a timeout fallback triggered, so a blocked sub-agent does not drag the system down.

III. Execution Termination. In parallel collaboration, a common scenario is "one succeeds, the rest become irrelevant"—multiple Agents search separately, and once one finds the target, the others should stop immediately (the cascading termination in Experiment 10-4 of this chapter). There are two levels of termination, and Unix users will recognize them as the distinction between SIGTERM and SIGKILL. Graceful termination is preferred: the main Agent sends a terminate signal, the sub-agent responds at a safe point in its current step, cleans up resources (closes browser sessions, writes pending files, releases locks), sends an acknowledgment (ack), and then exits. Forced termination is a fallback: directly terminating the process, used only when the sub-agent does not respond to the graceful signal, at the cost of potentially leaving dangling resources and incomplete writes. Two engineering points need attention. First, graceful termination requires the sub-agent to check periodically for the termination signal in its loop (similar to the interrupt mechanism in Chapter 6); otherwise, it cannot receive the signal. Second, cascading termination has a race condition: multiple sub-agents might report success nearly simultaneously. The main Agent must use a lock or idempotent design to ensure that only one success is accepted and that the termination signal is broadcast once. See the discussion of race conditions in Experiment 10-4.

Graceful termination is the first choice: the main Agent emits a terminate signal, the sub-agent responds at the safe point of its current step, first cleans up resources (closes the browser session, writes out unfinished files, releases locks), returns an acknowledgment (ack), and exits. Forced termination is the fallback: killing the process directly, used only when the sub-agent does not respond to the graceful signal, at the cost of possibly leaving dangling resources and half-finished writes.

One loose end remains: after the main Agent terminates, what happens to sub-agents still running? The cleanest engineering approach borrows from Go's context—termination cascades down the creation relationship: cancel one Agent and all the sub-agents it spawned are canceled with it, preventing orphaned child Agents from being left behind. The "sub-agent checks for the termination signal at a safe point" above corresponds precisely to polling ctx.Done() in Go. Conversely, if you genuinely need a long-running background Agent detached from the main Agent (like Unix's nohup), let it start from a new lifecycle tree (corresponding to context.Background()), explicitly declaring that it does not terminate with its parent.

IV. Resource Management and Scheduling. The other half of an operating system's job is allocating scarce resources. In the process world the scarce resources are CPU time and memory; in the Agent world they are tokens, money, and concurrency budget—every step a sub-agent takes consumes all three. This responsibility usually falls on the Manager or the runtime: set a step or token budget when starting a sub-agent, and stop once it is exceeded; give hard tasks to a strong model and mechanical tasks to a low-cost model; cap concurrency so that dozens of Agents don't exhaust the API quota at once; and when a more urgent task arrives, interrupt an executing sub-agent—this is preemption. Practice in this area is far less mature than CPU scheduling, but it determines the cost ceiling of a multi-agent system and should be considered at the architecture-design stage.

Compared with a traditional operating system's scheduler, the manager Agent's notable advantage is that it can reason. A manager Agent can therefore launch several sub-agents to explore one problem in parallel and, based on their progress, decide which to give more resources and which to terminate for appearing to have gone astray—rather like an internal race within a company.

Practice in the area of resources and scheduling is still far less mature than operating-system scheduling, but it determines the cost ceiling of a multi-Agent system and should be considered at the architecture-design stage.

Artifact exchange (the data plane) together with message passing, status query, execution termination, and resource scheduling (the control plane) support a multi-Agent system without shared context. Based on the collaborative relationships among Agents and the characteristics of the control flow, collaboration without shared context divides into three main architectures—the peer collaboration pattern, the manager pattern, and the decentralized pattern—each suited to a different kind of task.

Peer Collaboration Pattern: Mutual Checks and Iterative Improvement

Peer collaboration typically involves two or three Agents of equal standing giving one another feedback over multiple rounds. Its potential value lies in independent perspectives and cognitive diversity, but “multiple instances” do not necessarily produce “multiple ways of thinking.” When the model, context, and scaffolding are highly similar, different Agents often make the same choices, turning local errors into systemic failures. Genuine diversity must be designed by varying models, contexts, tools, visible evidence, or responsibilities, and by having Agents judge independently before their results are aggregated.⁴

Compared to the manager and decentralized patterns, peer collaboration is far simpler to implement—define the two Agents' roles, the communication mechanism, and the iteration termination condition, and you have a running system. It is an ideal choice for quickly validating ideas and building prototypes.

Loop Engineering

One of the most common uses of peer collaboration is to counter a frequent failure in Agent practice: premature termination—stopping with the job half done. It takes three typical forms; the examples below come from Coding Agents and from Pine AI, the Agent introduced in the Introduction that makes phone calls on users' behalf to deal with merchants and service providers. The first is lazy fake-done: doing part of the work and declaring all of it done—a Coding Agent writes the code, never runs the tests or tries the deployment, and reports "task complete"; a user gives Pine AI two errands, and it finishes the first, forgets the second, and cheerfully reports "all taken care of." The second is premature give-up: declaring the whole job impossible after one blocked path—Pine AI can reach a merchant by phone, web form, or email, but after a single rejected call it tells the user "this can't be done," when switching channels and trying again would very likely have succeeded. The third is false success: the Agent believes the job is done, but the loop was never actually closed—the other side verbally agrees to a refund on the phone, yet the user still has to confirm a step in the mobile app; the Agent reports "all set," the user never learns there is a follow-up action, and the refund never lands. All three forms point to the same root cause: until it is verified, "done" is merely the model's claim, not a proof.

Turning claims into proofs is precisely the business of Loop Engineering, the last stage of Chapter 1's evolutionary arc: design a loop that keeps the Agent running—discover the next piece of work, execute, verify, record progress—and let a verifier, not the model itself, decide whether it is truly safe to stop. The human's role shifts accordingly from "the operator who prompts the Agent" to "the engineer who designs the loop." The term was coined in June 2026 by Addy Osmani⁶; Boris Cherny, head of Claude Code at Anthropic, put it more bluntly: "I don't prompt Claude anymore. My job is to write loops." The central conclusion to emerge from that discussion was that the bottleneck of the loop is the verifier, not the model: with unreliable verification, a faster loop merely marks poor output as complete sooner. And as the Introduction says, practice comes first, naming comes later. Long before the term caught on, leading Agent teams—Pine AI among them—were already using "loop plus verification" against premature termination. The most effective way to organize that verification is the Proposer-Reviewer paradigm below.

Concrete framework: LoopX. LoopX takes the loop out of the model's prompt and chat history and places it in a durable, agent-runtime-neutral control plane: the objective and boundary explain why the work exists; gates and todos determine what may happen now; evidence and quota determine whether it may continue; and handoffs let a later turn or another Agent resume it. It compresses one governed execution into a clear protocol:

LoopX decides → Agent executes → independent verifier proves → LoopX commits

The Agent still reasons, uses tools, and produces candidate artifacts. LoopX does not replace the Agent runtime; it governs continuity across turns. Only independently verified results may update durable progress and spend quota. Failed validation routes to repair or replanning, while human gates, wait states, and budget limits stop the loop before execution. This boundary turns a Loop Engineering principle into an inspectable system invariant: the model may propose “done,” but it cannot approve its own “done.” LoopX v0.4.0 still labels the governed-Turn path experimental, so it is used here as a concrete framework for “loop + verification + stop conditions,” not as evidence of general task-quality uplift.⁷

Concrete framework: LongHorizon-Harness. LongHorizon-Harness and LoopX are both concrete implementations of Loop Engineering, but they point in different directions. LoopX targets a durable control plane for long-running Agent work; LongHorizon-Harness starts from multimodal Computer Use and tackles continuous execution when a single task spans a GUI, a CLI, several desktop applications, and repeated context refreshes.

LongHorizon-Harness reframes long-horizon execution as task-state management and implements its loop as Manage–Execute–Audit (MEA): the Manager generates the next bounded subtask from the original objective, verified progress, failure evidence, and remaining work; the Executor changes the environment through the GUI or CLI in a fresh context; the Auditor then inspects the actual result read-only. Only what passes the audit enters the next round's task state, while failures are retained as the basis for recovery and replanning. Execution backends such as Claude Code and Codex CLI are reused through an adapter layer rather than by rewriting the Agent loop inside those backends.⁸

The value of this direction lies in separating task continuity from an ever-growing execution history: context may be refreshed and interface operations may fail, yet the next round still resumes from the most recently verified state. Holding the Qwen 3.7-Plus model and the Claude Code execution backend fixed and changing only the outer loop, the paper reports WeaveBench PassRate rising from 51.8% to 80.7%, OSWorld 2.0 binary completion from 2.8% to 8.3%, and Terminal-Bench 2.1 success from 69.7% to 77.2%. The cost is not fixed either: the first two benchmarks consumed 2.3× the baseline's total tokens and 3.6× its output tokens respectively, while Terminal-Bench 2.1 fell by 24%. A real deployment must additionally handle state invalidated by a changing external environment or changing user requirements, and use round, time, and cost budgets to keep recovery loops from running forever.

Public trajectories and reproduction. The project website publishes hundreds of run trajectories for WeaveBench, OSWorld 2.0, and Terminal-Bench 2.1, so the execution process and each role's records can be inspected directly. Take WeaveBench's WEB_task_16_webrtc_simulcast_layer_audit: the baseline trajectory and the MEA trajectory, both on the same Qwen 3.7-Plus model, can be compared side by side. The former got stuck on Wireshark interaction and retried repeatedly, scoring 0.59; the latter wrote failures and unmet evidence items back into task state so that later rounds handled only the gaps, scoring 0.92. This case shows “how a failure becomes the next round's input” and does not substitute for aggregate statistics; the environment, parameters, and launch scripts for the full experiments are in the pinned eval/ directory.

Proposer-Reviewer Paradigm

Proposer-Reviewer is the canonical peer-collaboration paradigm. Chapter 5 already covered its design principles and practical applications in three experiments: PPT generation, video editing, and log visualization. The Proposer Agent generates code, while the Reviewer Agent renders the execution results, evaluates their quality using a vision-language model, and provides structured suggestions for improvement. The two iterate until the result meets the required standard.

This paradigm is also applicable to scenarios like security review (Proposer generates an action plan, Reviewer checks compliance and potential risks), content moderation (Proposer drafts a reply, Reviewer checks business rules and language norms), and code review (Proposer writes code, Reviewer checks security and best practices).

Why can't a single Agent generate and then review its own work? This is exactly where the criterion from "When Is Multi-Agent Truly Better Than a Single Agent?" earlier in this chapter applies—if the review does not introduce new information, it is just "asking the model to think again." Related research provides a clear answer. In their ICLR 2024 paper "Large Language Models Cannot Self-Correct Reasoning Yet," Huang et al. found that asking GPT-4 to review and correct its own answers without external feedback actually decreased accuracy—the model changed correct answers to incorrect ones more often than it changed incorrect answers to correct ones.

The minimal invariant of the proposer-reviewer loop is this: the reviewer reads independent evidence rather than merely restating the proposer's explanation, and when it sends work back it must give a locatable repair condition:

candidate = proposer(task, constraints)
evidence = execute_or_render(candidate)       # tests, state, screenshot, facts
review = independent_reviewer(candidate, evidence)

while review.veto and budget_remaining:
    candidate = proposer.repair(candidate, review.findings)
    evidence = execute_or_render(candidate)
    review = independent_reviewer(candidate, evidence)

if review.pass:
    publish(candidate, evidence, review)
else:
    escalate_or_reject(review)

The reviewer must not be able to modify the tests, the evidence collector, or the release gate; otherwise "independent verification" degenerates into self-approval.

A 2024 survey paper published in TACL, "When Can LLMs Actually Correct Their Own Mistakes?" (arXiv:2406.01297), further confirmed this conclusion: unless reliable external feedback is provided (e.g., test case execution results, verification output from external tools), relying solely on the model's own "self-correction" is largely ineffective.

The CRITIC paper at ICLR 2024 provides an intuitive comparative experiment. CRITIC had the model use external tools (search engine, Python interpreter) to verify its own answers, leading to significant performance improvements. However, when the experimenters removed the tool verification step and only kept the model's self-assessment, most of the improvement disappeared. This indicates that the value of review lies not in "asking the model to think again," but in introducing new information that was not available during the model's generation—test results, rendered screenshots, compilation errors, external search results.

Anthropic's 2026 experiment on long-running application development implemented this idea as a three-Agent planner–generator–evaluator architecture. The planner expanded a user's request into a product specification. The generator and evaluator first agreed on the completion criteria for each round; the generator then implemented the work, and the evaluator exercised the real application with Playwright and filed a defect report. Agents handed state off through files. The experiment suggests that when a task lies beyond what the current model can reliably complete alone, independent review grounded in external evidence can trade substantially higher cost for better development quality.⁹

Debate Pattern

Multiple Agents hold different positions, exploring the problem space through adversarial dialogue. For example, when evaluating a technical solution, Agent A plays the "supporter," listing the solution's advantages and opportunities, while Agent B plays the "opponent," pointing out risks and limitations. Each round of debate involves rebutting or extending the other's arguments. When a single Agent analyzes a problem, it often favors one perspective and overlooks counterevidence. Structured debate forces both positions to be developed fully, helping decision-makers reach a more balanced judgment.

However, the practical effectiveness of debate remains contested in academia. A 2026 study by Tran and Kiela ¹⁰ compared a single Agent with five multi-agent architectures (sequential, debate, ensemble, parallel roles, subtask-parallel) on multi-hop reasoning tasks. They found that when the thinking-token budget was held constant, the single Agent performed on par with or even better than the multi-agent systems (unless context utilization was degraded to a certain point). The researchers provided an explanation based on the data processing inequality in information theory: multiple Agents in a debate process the exact same textual information, and each serial transmission of intermediate conclusions between Agents can only lose information, not create it. The benefits of the debate mode in some academic papers likely stem from multiple Agents consuming more total computation. It is important to clarify the boundary of this argument: it targets the information bottleneck caused by "multi-agent serial transmission of intermediate conclusions" and does not negate other approaches, such as multiple independent samples of the same problem followed by aggregation (e.g., self-consistency, majority voting), or leveraging the asymmetry in difficulty between generation and verification (writing an answer is hard, verifying it is easy) for a generation-verification division of labor. These scenarios either introduce additional independent sampling or exploit the asymmetric structure of the task itself, and are not within the scope of the data processing inequality.

Brainstorming Pattern

Multiple Agents independently generate ideas, then share them with each other, inspiring one another. For example, in a product innovation task, Agent 1 proposes "adding social sharing features," Agent 2 is inspired to suggest "not just sharing to social networks, but also generating personalized sharing posters," and Agent 3 synthesizes the first two to propose "user-customizable poster templates forming a template marketplace." Different Agents have different "thinking preferences" (achieved through different prompts or models), and by stimulating each other, they explore a broader solution space to find creative combinations that a single Agent would struggle to conceive.

Panel of Experts Pattern

Multiple Agents each represent the perspective of a specific professional domain, jointly discussing an interdisciplinary problem. For example, when evaluating the feasibility of a new product, an Engineer Agent analyzes the implementation difficulty from a technical standpoint, a Product Agent assesses market appeal from a user experience perspective, and an Operations Agent analyzes business viability from a cost and resource perspective. These Agents are not adversarial but complementary, together piecing together the full picture of the problem and identifying cross-domain constraints and opportunities.

Manager Pattern: Centralized Coordination

When a task involves more than five subtasks, needs dynamic scheduling, or has complex dependencies among subtasks, peer collaboration is out of its depth, and the manager pattern is needed. The Manager Agent's job resembles that of a project manager: understand the overall task, break it into assignable subtasks, choose the right Agent for each, track progress, handle exceptions by retrying tasks, replacing Agents, or revising the plan, and finally integrate the Agents' outputs into the final result.

From a system design perspective, the manager pattern models each specialized Agent as a tool that the Manager can invoke. The Manager's tool set includes not only traditional external tools, such as search and file operations, but also interfaces for invoking other Agents. The Manager invokes the appropriate Agent through a tool call, passes the task parameters and necessary context, waits for completion, and receives the result. From the Manager's perspective, calling an Agent is essentially no different from calling a regular tool: both involve sending a request and receiving a response. This unified abstraction makes the manager pattern easy to extend. Adding a capability requires only developing the corresponding Agent and registering it as a tool, without modifying the Manager's core logic. It also naturally supports heterogeneity: different Agents can use different models, prompts, tool sets, and even hardware environments.

The manager pattern has inherent challenges, though. The Manager becomes the system's single-point bottleneck: it must understand the nature of every subtask, choose the right Agent, and pass context accurately; any misjudgment ripples through the whole flow. It must also maintain the global context of the entire task, which can balloon as the task deepens and Agent calls accumulate. The Manager therefore requires a carefully designed prompt, an effective context-management strategy, and appropriately granular task decomposition.

The 2025 Plan-and-Act paper ¹¹ provides an empirical analysis of this: in a Planner-Executor dual-agent architecture, a weak planner is the most critical bottleneck of the entire system. When the Planner's planning quality is high enough, good results can be achieved even with a relatively simple Executor. Conversely, if the Planner's task decomposition is wrong, all subsequent Executor work is built on a faulty premise. The study achieved a 54% success rate on the WebArena-Lite benchmark, and its core contribution was improving the Planner's planning ability, not the Executor's execution. The lesson: give the strongest model and the most carefully crafted prompt to the Manager (the planner), rather than spreading resources evenly across all Agents.

A parallel manager must also define the settlement point as "the first verified success" rather than "the first claimed success":

workers = launch_independent_workers(subtasks)
while workers.any_running:
    event = next_event()
    if event.type == RESULT:
        if verify(event.artifact, hidden_checks):
            if not settle_once(event):       # atomically claim the winner
                continue
            broadcast_cancel(to = workers - {event.worker_id})
            await_all_ack_or_timeout()
            return assemble(event.artifact, evidence = event.evidence)
        else:
            record_failure(event)
return summarize_failures(workers)

settle_once must be idempotent (usually protected by a lock or a transaction); otherwise two success events arriving almost simultaneously will trigger the aggregation twice.

Sequential Coordination Pattern.

The Manager calls specialized Agents sequentially. Each Agent returns results upon completion, and the Manager decides the next step. The control flow is linear, simple, and clear, making it suitable for scenarios where subtasks have clear sequential dependencies.

Experiment 10-2 ★★: Book Translation Agent

Book translation is a complex task well suited to multi-agent collaboration. Translating a technical book involves not just converting text from one language to another, but also ensuring consistent specialized terminology, contextual accuracy, and overall fluency. For example, an English book about large language models may use many recurring terms with several conventional translations. Consistency must be maintained throughout the book: if agent is rendered as "智能体" ("intelligent entity," the standard Chinese term) in Chapter 1, the book cannot switch to the alternative rendering "代理" ("proxy") later.

Using a single Agent creates serious context-management problems. As the Agent processes the book chapter by chapter, its context accumulates the full-book glossary, translated chapters, the current paragraph, translation work traces, and tool results. A technical book several hundred pages long, together with these intermediate materials, can easily exceed the context window. More critically, an Agent working with an overly long context is prone to "getting lost": it may forget earlier terminology conventions and use a different translation in Chapter 9 than in Chapter 2, waste resources on redundant checks during proofreading, or even "remember" terminology rules that do not exist because its attention is spread too thin.

The manager pattern addresses these issues through task decomposition and responsibility separation:

• Glossary Agent: Receives the full book, identifies recurring specialized terms, consults specialist dictionaries and translation guidelines, and generates a structured glossary (JSON/CSV format, including the English term, Chinese translation, part of speech, and usage context). When finished, it writes the glossary to the shared file system, and the Agent can be destroyed to release resources.
• Translation Agent: Receives the current chapter, the glossary, and translation guidelines (target reader level, language style), and translates it into fluent Chinese. It strictly uses the specified translations for terms in the glossary, and for new terms, it infers a translation and marks it for review. Each instance works in an independent context without interference. The translated text is written to the file system (e.g., chapter1_zh.md). The Manager can launch multiple instances in parallel or sequentially.
• Proofreading Agent: Receives all translated texts and the glossary, performs consistency checks—verifying whether term translations are uniform, identifying inconsistencies, and checking overall fluency and readability. It generates a proofreading report written to the file system.
• Manager Agent: Its context mainly stores the task description, execution plan, call records for each Agent, and progress status. It does not store the complete translated text, which remains in the file system; instead, it maintains only an index of the files. Based on the proofreading report, the Manager can send specific chapters back to the Translation Agent for revision.

As a result, the Manager's context remains manageable even as the number of translated chapters grows.

The key advantage is context isolation: the Glossary Agent sees only the content needed for term extraction, the Translation Agent sees only the current chapter and glossary, and the Proofreading Agent, while needing access to the full text, focuses only on consistency checks. This keeps each Agent's context lean and focused, improving efficiency and reducing errors caused by information overload.

Experiment Requirements: 1. Choose a heavily illustrated technical book containing code as the source text 2. Implement four types of Agents: Manager, Glossary, Translation, Proofreading 3. Record each Agent's context usage to verify how effectively the manager pattern controls context growth 4. Compare a single Agent with the manager pattern in terms of translation quality, execution efficiency, and resource consumption

Parallel Coordination Pattern.

When multiple subtasks can run in parallel, the sequential pattern becomes inefficient. Parallel coordination allows multiple Agents to work simultaneously, significantly increasing throughput. The Manager Agent must plan the parallel tasks, monitor all running Agents in real time, coordinate their communication, and make system-wide decisions when Agents succeed or fail. This typically requires a message bus as infrastructure—think of it as a "public bulletin board" where Agents can publish messages and subscribe to the message types that interest them, enabling asynchronous, non-blocking communication. Two common implementations, from simpler to more complex, are Redis Pub/Sub and message queues such as RabbitMQ. Redis Pub/Sub is lightweight and delivers messages immediately, but it does not persist them, so a receiver that is offline will miss them. RabbitMQ and similar systems persist messages to disk, preserving them while a receiver is temporarily offline. Messages typically use a JSON envelope containing the sender ID, target Agent (or a broadcast marker), message type, and payload.

Lingtai: A Productized Instance of the Manager Pattern. Lingtai is a local, file-based home for long-lived Agents¹²; its three roles are a complete realization of the concepts in this section:

• The main agent is the persistent hub that converses with the user, holds the plan and the memory, and spawns work to the other roles—precisely the position of the Manager Agent;
• A daemon is a short-lived parallel worker spawned for one noisy but bounded task; it is discarded when done and carries only its conclusion back to the main agent, which is exactly the productization of "a sub-Agent returns a structured summary rather than the full trajectory" together with the parallel coordination form;
• An avatar is a persistent, specialized teammate with its own memory, mailbox, and responsibilities, used for specialist divisions of labor worth preserving across many sessions.

The rest of Lingtai's design also echoes earlier sections. Knowledge lives in each agent's durable, private memory files, while skills are Markdown playbooks shared by all agents—the built-in system resources described in "The File System from an Agent's Perspective." When an agent's context window fills, it molts: it writes a careful summary, then starts with a fresh context while retaining that summary and its durable memory, following the context-compression approach from Chapter 2. The underlying model can be replaced without changing the agent because its identity, memory, and capabilities all live as plain files in the project directory. In this sense, the agent is its files. This productizes the first two rows of Table 10-2: both program and memory reduce to files, so the process can be rebuilt at any time.

Experiment 10-3 ★★★: Autonomous Phone and Computer Agents

Prerequisites: This experiment integrates the Computer Use and Voice Agent technologies from Chapter 6.

Scenario and architecture: The user supplies a registration or booking URL, but not all required personal fields. A Computer Agent operates the browser and a Phone Agent handles ASR, LLM dialogue and TTS. They exchange structured messages (sender, receiver, type and payload) through point-to-point tools or a message bus. A local WebRTC audio page is sufficient; PSTN/E.164 is optional.

Two paths: First run a fixed-topology baseline with both Agents started in advance, then run the main autonomous path in which only the Computer Agent starts. After inspecting the page and its context, it may autonomously call initiate_phone_call_agent(purpose, required_info); do not replace this decision with a field-count rule. The spawned Phone Agent receives an isolated task context and uses the same communication protocol as the baseline.

Parallel closed loop: The Phone Agent asks, transcribes, validates and re-asks one field at a time while the Computer Agent screenshots, locates elements and fills the previous field. Messages such as info_collected, fill_error, format_invalid and task_completed make the loop observable in both directions. The Phone Agent continues asking without waiting for each browser fill, so asking and filling genuinely overlap. After validation and explicit authorization, the Computer Agent submits the form.

Requirements and evidence: Demonstrate autonomous launch, independent ReAct loops, bidirectional messaging, true overlap, field validation and re-asking, page-error feedback, timeouts, cancellation and cleanup of browser/audio resources. Record the launch decision, message ordering, latency, success rate, token/resource use and all failure paths; require explicit consent for real voice and explicit authorization before submission.

Experiment 10-4 ★★★: Agent Collecting Information from Multiple Websites Simultaneously

Prerequisites: It is recommended that readers first review the event-driven and interrupt mechanisms from Chapter 6.

This experiment explores the application of multi-agent parallel execution in information collection scenarios. Unlike Experiment 10-3, which focuses on collaboration between two heterogeneous Agents, this experiment focuses on parallel search by multiple homogeneous Agents and how to achieve efficient task completion and resource optimization through central coordination.

Problem: Given faculty-directory websites for several colleges within a university, search each site for a specified faculty member (e.g., "Zhang Wei"). If found, return the person's college, position, research area, and other relevant information.

Core Challenges:

1. Parallel Launch: The Manager Agent dynamically creates 10 Computer Use Agent instances, one for each college website. Each instance should be an independent process or thread with its own browser session, capable of running without blocking the others. Parameters passed at launch include the target website URL, faculty name to search for, and task identifier for message routing.

2. Real-time Monitoring: Each Agent periodically sends status updates during execution ("Loading website," "Parsing faculty directory," "Target not found; task complete," "Match found; details below"). The Manager Agent receives these updates through a message bus, maintains a task-status table, and tracks in real time which Agents are running, have completed, or are in an error state.

3. Cascading Termination: Suppose the Agent assigned to the Computer Science college finds the faculty member. It sends {"type": "target_found", "agent_id": "agent_3", "data": {...}} to the Manager Agent, which immediately sends {"type": "terminate", "reason": "target_found_by_agent_3"} to every other Agent still running. Each Agent must be able to receive this message at any time, stop gracefully, release its resources, and acknowledge termination. The Manager Agent waits for all acknowledgments, or until a timeout, before aggregating the results. The implementation must also handle race conditions.

Concept Supplement: What is a Race Condition? Suppose Agent A and Agent B find the target faculty member within the same millisecond and both report "I found it!" to the Manager Agent. If the Manager handles this poorly, it might begin aggregating results after receiving Agent A's report, then start a second aggregation when Agent B's report arrives. This could produce duplicate results or contradictory states. The usual solution is a lock: the first report locks the state, and later reports are recognized as duplicates and ignored.

4. Failure Handling: Various exceptions can occur during operation: a college website might be inaccessible because of a network error or outage, or its structure might prevent the Agent from parsing it correctly. All Agents may also complete their searches without finding the target. The Manager Agent should set a timeout for each Agent (e.g., 2 minutes), treat a timeout as a failure, and isolate errors so they do not interrupt the other Agents. After all Agents finish, return the information if any Agent found the target; otherwise, report "Target faculty member not found" and summarize any failures.

Experiment Requirements: 1. Implement a Manager Agent capable of dynamically launching multiple parallel Agents 2. Implement a Computer Use Agent based on open-source projects like browser-use 3. Implement a message bus supporting bidirectional communication between the Manager Agent and multiple child Agents 4. Implement a cascading termination mechanism upon success, ensuring all other Agents stop quickly once the target is found 5. Handle various exception scenarios (website access failure, parsing errors, target not found by any Agent) 6. Measure and compare serial and parallel execution times to quantify the speedup from parallelization

The Manager Agent generates the Agent workflow. In the two preceding forms the Manager Agent stays inside the loop: every subtask it dispatches demands one more decision from the model, and the context grows with the number of calls. Another approach is to have the Manager first write the Agent workflow as a piece of code, and then hand it to a deterministic runtime to execute.

The Workflow tool built into Claude Code is one such instance: it gives the Agent a few primitives—agent(), parallel(), and pipeline(). Each agent() is a sub-agent with its own context, and a schema stipulates that it return only structured conclusions rather than a full trajectory. For example, to verify seven groups of facts for a technical manuscript, each group is first researched, then verified item by item independently, and finally summarized together:

const results = await pipeline(
  DIMENSIONS,                                     // the seven directions to verify
  d => agent(research(d), { schema: FINDINGS }),  // stage 1: research
  r => parallel(r.findings.map(f => () =>         // stage 2: verify each item independently
         agent(verify(f), { schema: VERDICT })))
)
await agent(writeProvenance(results.flat()))      // summary: waits for all results

Decentralized Pattern

Given the manager pattern, why do we still need a decentralized one? The motivation for removing the central controller is chiefly to emulate how human organizations work: let several roles of equal standing divide the labor and check one another, each examining the problem from its own professional angle and deciding for itself whom to talk to, rather than funnelling every judgment to a single Manager. In the decentralized pattern, each Agent decides on its own professional judgment when to reach out to another Agent—it may be handing off a task ("my part is done, over to you"), asking for feedback ("is this design technically feasible?"), or reporting a problem ("the requirements you gave me contradict each other; we need to talk again").

Decentralization also helps with Agent stability. Because of model or API-service failures, some Agents may stop responding, fail their tool calls, or get stuck in an infinite loop of incorrect tool calls. In the manager pattern, a crash of the manager Agent often becomes the system's largest single point of failure. Decentralization helps mitigate that.

The microservices world calls the manager and decentralized patterns orchestration and choreography respectively: in the first a conductor schedules everyone; in the second each dancer judges for themselves when to enter.

The three cases below form a progression: MetaGPT's control flow is in fact a fixed pipeline (pseudo-decentralization, decoupled only in its communication mechanism), AutoGen's group chat is a hybrid of shared conversation history plus centralized scheduling, and only with OpenAI Swarm does the control flow become genuinely peer-to-peer.

MetaGPT: SOP-Driven Software Company Simulation.

MetaGPT's core insight is that the Standard Operating Procedures (SOPs) accumulated by human software companies are themselves a repeatedly validated collaboration protocol—encode the SOP into a multi-Agent system, have each role produce standardized deliverables the way a specialized trade does on an assembly line, and those deliverables naturally constitute the communication interface between roles.

In MetaGPT, roles work in a fixed sequence (Product Manager → Architect → Project Manager → Engineer → QA), and each role emits a structured "handoff package":

• Product Manager Agent: Receives the requirement description and generates a structured PRD (product requirements document, with a feature list, user stories, acceptance criteria, and prioritization)
• Architect Agent: Reads the PRD, makes the architectural decisions (technology-stack choice, module decomposition, interface definitions, data-model design), and emits the design document
• Project Manager Agent: Reads the architecture, breaks the system into a concrete task list and file-level assignments, works out the dependency order among modules, and distributes tasks to the engineers
• Engineer Agents: Read the design document, implement the modules they own, and produce code; multiple instances can work in parallel
• QA Engineer Agent: Reads the code and the PRD, generates test cases, runs the tests, records bugs, and emits the test report

In practice an effective "handoff package" usually has three parts: the task description (what the recipient must do and what the acceptance criteria are), the confirmed facts and constraints (user preferences, business rules, decisions settled in earlier stages), and references to structured artifacts (file paths rather than file contents, which the recipient reads as needed). No Agent needs to understand another Agent's "thought process"; it only needs to understand the format and semantics of the handoff package and the artifacts.

MetaGPT's true contribution to decentralized communication lies in its information-passing mechanism: a shared message pool plus per-role subscription. Each role publishes structured messages into a pool visible to all roles, and the other roles, according to their own subscription configuration, take only the messages relevant to their responsibilities—rather than relaying point to point. The publisher does not need to know who will consume its output, and adding a role only requires declaring which message types it subscribes to, without touching any existing role. That yields real decoupling: replace the Product Manager with a stronger model, and as long as the PRD it publishes still meets the specification, no other Agent needs to change.

It should be said plainly that MetaGPT is not decentralized in terms of control flow—the role sequence is fixed in advance by the SOP, and the whole is closer to a pipeline (in the language of Chapter 1, a workflow). It is discussed in this section because the message-pool-plus-subscription communication mechanism demonstrates the most crucial design element of decentralized systems: decoupling. As for multidirectional dynamic feedback such as "QA goes straight to the Product Manager to clarify a requirement" or "the Engineer discusses alternatives with the Architect," that is a natural extension one can imagine on top of this architecture; the original MetaGPT does not implement it.

AutoGen Group Chat.

AutoGen's group chat lets several Agents take part in a single conversation: each round, a "speaker selector" decides which Agent speaks next. The selector may be a simple round-robin rule, or an LLM that judges from the current conversation who is best placed to pick up the thread; any Agent's utterance is visible to all participants. It is not a fully decentralized system: the choice of speaker is adjudicated centrally by a GroupChatManager, and "whose turn it is to speak" is itself a control-flow decision. It is a hybrid of "shared conversation history plus centralized scheduling": all Agents see the same public record, but each keeps its own system prompt and tool set, while scheduling authority is concentrated in the selector.

OpenAI Swarm.

OpenAI Swarm is the representative case of control flow that truly achieves peer decentralization: each Agent is equipped with several handoff options and can transfer control at any moment to any other Agent in the network. There is no central scheduler; control passes among peer Agents like a baton, and routing decisions are entirely distributed into each Agent's own judgment. Unlike multi-Agent collaboration with shared context, a handoff should transmit only an explicit task package and artifact references, and should not expose the full private trajectory by default. The risk of peer handoff is cycling: A hands off to B and B hands back to A, and the task spins in the loop; hence protective mechanisms such as an upper bound on the number of handoffs.

The minimal protocol for a decentralized handoff can be expressed as:

handoff = {
    task_id, sender, recipient, goal, constraints,
    accepted_facts, artifact_refs, remaining_budget,
    visited_agents
}

if recipient in handoff.visited_agents:
    reject("cycle")
elif handoff.remaining_budget <= 0:
    stop_and_escalate(handoff)
else:
    append(recipient, handoff.visited_agents)
    run_local_agent(handoff)

This turns "context isolation" into an inspectable interface: the recipient reads the task package and the references and gathers evidence as needed; the budget, the visit chain, and cycle detection are retained by the runtime and cannot be deleted by any single Agent.

Since 2025, "Agent Swarm" has become a buzzword across vendors, but it does not correspond to a single architecture. Industry usage falls into roughly two kinds. First, the OpenAI Swarm-style handoff network (LangGraph's swarm library and the handoff orchestration in Microsoft Agent Framework belong here too), which is the decentralized pattern of this section. Second, in several mainstream commercial products the Agent Swarm is a manager pattern taken to scale: the Agent Swarm introduced with Kimi K2.5 has a main Agent dynamically create hundreds of sub-Agents to run in parallel, and trains the orchestration decisions of "when to split and into how many" directly into the model through parallel-Agent reinforcement learning; K3 continued this as a separate model tier and open-sourced the accompanying parallel-Agent training sandbox AgentEnv¹³. Anthropic's multi-Agent research system and Manus's Wide Research both belong to the orchestrator-worker star topology. We hope that after reading this book you will see the substance behind the concepts and analyze the actual structure of different multi-Agent systems rather than being misled by names.

Peer Agent Instances on the Same Machine.

The Agents in all three systems above collaborate on one and the same thing. There is another kind of decentralization in which each goes its own way: every Agent has its own task, and the communication between them is not for dividing labor but for coordinating the use of shared resources. Claude Code already supports multiple Agents on the same machine discovering one another (this is exactly what list_agents in Chapter 4 is for) and messaging one another: two Agents editing the same set of files negotiate how to resolve the conflict, and when the machine has only one GPU while both instances want to run training, they coordinate its use.

The further evolution of the decentralized pattern is the Agent society, introduced at the end of this chapter.

Cross-Organization Collaboration: The A2A Protocol

All the systems above assume that all Agents are developed by the same team and run within the same system. In this case, the three communication mechanisms—parameter passing, shared files, and message bus—are sufficient. However, when collaboration crosses organizational boundaries—your Agent needs to call another company's Agent—a standardized interoperability protocol is required. The world of processes followed the same evolution: IPC only governs a single machine, and once you step across the machine boundary you must rely on standard protocols like TCP/IP and service discovery like DNS. A2A is to Agents what network protocols are to processes. The A2A (Agent2Agent) protocol released by Google in 2025 (later donated to the Linux Foundation for stewardship) was designed precisely for this purpose. It has three core elements:

• Agent Card: A metadata document describing an Agent's capabilities (published at a designated public address), declaring what the Agent can do, which input/output modalities it supports, and how to authenticate with it—essentially an Agent's "business card" that solves cross-organizational capability discovery.
• Task Lifecycle Management: A2A models collaboration units as Tasks with a defined state machine (submitted, in-progress, needs-input, completed, failed), natively supporting long-running tasks and streaming progress updates.
• Opaque Collaboration: Agents exchange only tasks and artifacts, without exposing internal prompts, reasoning processes, or tool implementations—consistent with this chapter's principle of "not sharing context" and a necessary security property for cross-organizational collaboration.

MCP enables interoperability between Agents and tools, whereas A2A enables interoperability among Agents. A2A does not replace the three communication mechanisms introduced in this chapter; it is the standardized layer used across trust boundaries. A message bus may be sufficient within one organization, but parties that do not trust one another and cannot inspect one another's implementations need a public protocol such as A2A.

Failure Modes of Multi-Agent Collaboration

Multi-agent systems introduce new failure modes that do not exist in single-agent systems. The 2025 paper "Why Do Multi-Agent LLM Systems Fail?" proposed the MAST failure-mode taxonomy through a systematic study. The researchers collected execution traces from seven mainstream multi-agent frameworks, including MetaGPT, ChatDev, AG2, and Magentic-One. Human annotators independently analyzed roughly 150 traces, achieving high agreement on their judgments (Cohen's kappa = 0.88). The study identified 14 unique failure modes in three groups:

• System Design Flaws: Architecture-level issues such as unclear interface definitions between Agents, overlapping roles and responsibilities, and incorrect tool configurations.
• Inter-Agent Alignment Failures: Multiple Agents have inconsistent understandings of task objectives, transmitted information is misinterpreted by downstream Agents, or the operations of multiple Agents logically contradict each other.
• Missing Task Verification: The system lacks effective mechanisms to confirm whether a task is truly complete—an Agent may claim "completed" but the actual result does not meet requirements.

Even straightforward fixes produced limited gains; for example, ChatDev's measured performance improved by only 15.6%. The researchers concluded that these are not mere engineering bugs but fundamental design flaws of current multi-agent architectures: patching one component is not enough; the system design itself must be rethought.

Distributed fault-tolerance theory distinguishes crash faults, in which a component stops working, from Byzantine faults, in which it continues operating but supplies incorrect information. Agent failures are often Byzantine: an Agent continues producing plausible but incorrect conclusions without announcing the error. Cross-validation and majority voting are therefore essential, and deterministic checks such as tests, compilers and database queries are especially valuable because they provide independent evidence.

The following sections focus on several failure modes that are particularly common in practice.

Failure Mode One: Concurrency Conflicts in Shared File Systems

Once you choose shared-memory-style communication, concurrency conflicts come with it—a problem operating systems and databases solved decades ago, with the answers already off the shelf. These conflicts can be divided into two types.

Simple Conflicts (File-Level Write Conflicts): Two Agents modify the same file simultaneously, and the later write overwrites the earlier one.

Semantic Conflicts (Logical-Level Consistency Conflicts): No conflict is visible at the file level, but the operations of multiple Agents logically contradict each other—this type of conflict is more insidious and more dangerous. For example: Agent A is responsible for renumbering all images in a book, while Agent B is simultaneously modifying the content of a chapter and referencing images by their original numbers. The two operate on different files, so there is no conflict at the file level. However, the result is that all image numbers referenced by Agent B become invalid after Agent A completes the renumbering, and readers see incorrect image references.

Solution: Optimistic Locking Mechanism. This is a common concurrency-control strategy in databases. The implementation is: each file maintains a version number (or last-modified timestamp). When an Agent reads a file it records the current version; when writing, it checks whether the version still matches what it read. If another Agent modified the file in the meantime, the write fails, and the Agent is forced to reread the latest version and redo its operation on that basis. The cost of this mechanism is an occasional retry; what it buys is a guarantee of data consistency.

Note that optimistic locking can only prevent write conflicts on the same file. The cross-file semantic conflicts described above require a higher-level semantic validation mechanism. In the most common scenario—several Coding Agents modifying the same codebase concurrently—the mainstream industry practice is working-copy isolation: each Agent is given an independent Git branch or worktree, modifies its own copy in parallel without interfering with the others, and conflicts are deferred in bulk to the final merge point.

Failure Mode Two: Cascading Amplification of Errors

Inter-process communication transfers raw bytes with bit-level fidelity, but inter-Agent communication transfers semantics—and every handoff is a lossy re-encoding. When multiple Agents interact frequently, an error by one Agent can be progressively amplified by downstream Agents, much like how information deteriorates in a game of "telephone."

Cross-validation is the key to breaking this chain. The point is not to involve more Agents in the same chain of thought, but to have one Agent reassess the conclusion from an independent perspective: ignore the preceding Agent's reasoning and check only whether the raw evidence supports the final conclusion. This extends Chapter 5's Proposer-Reviewer mechanism to multi-agent systems.

Failure Mode Three: Homogeneous Convergence

Errors need not propagate through a communication chain; homogeneous Agents may produce them independently. In Anthropic's experiment,⁴ 18 of 30 Agents that came online at the same time created Git branches with the same name. In a writing experiment, separate Agents independently chose the same title. Such common-cause failures, produced by a shared model and scaffolding, mean that reviews generated by the same model in similar contexts cannot automatically be treated as independent evidence. A system should deliberately vary models, contexts, and data sources, while using namespaces, resource quotas, and rate limits to keep identical decisions from hitting shared resources at once.

Coordination is not necessarily beneficial either. In a Bertrand pricing experiment, profit-seeking Agents quickly colluded when given a private channel. After all direct communication was removed, they still coordinated their bids through a public listings board.

Failure Mode Four: Passing the Buck

When objectives conflict, convergence can give way to confrontation. Anthropic instructed three Agents to migrate the same backend to different languages. They soon interpreted one another's actions as deliberate obstruction, killed competing processes, revoked permissions, and even deployed self-replicating destructive code. Stronger execution ability does not imply better coordination. The runtime must define objective priorities, resource ownership, and permission boundaries in advance, and pause for human arbitration when a conflict cannot be resolved by verifiable rules.⁴

Early versions of MetaGPT displayed a similar kind of corporate dysfunction among its development roles. A tester would report a bug, only for the frontend and backend engineers to insist that the other should fix it first; the backend engineer would blame product design, while the product manager would blame the backend architecture. In another case, a test-environment problem caused the tester to report the same bug regardless of how the frontend and backend engineers changed the code, leaving the team deadlocked.

Failure Mode Five: Runaway Loops

The opposite of premature termination is an uncontrolled loop. A loop can run indefinitely or exhaust its token budget. Explicit budgets, cancellation and stop conditions are required to keep it bounded.

Failure Mode Six: Comprehension Debt and Cognitive Surrender

This mode is not a failure of the Agent but a failure of the human. As Agents grow more capable and take on longer workflows, it becomes steadily harder for a person to understand what the Agent delivers and to give it effective guidance.

Developing with Agents easily accumulates comprehension debt: the faster the loop ships code, the further the engineer's understanding of what the system actually does falls behind, until a serious problem forces manual intervention and the engineer can no longer read their own system. The second problem is cognitive surrender: having grown used to delegating to the Agent, the engineer gradually gives up independent thinking and review, and software quality slips out of control.

Andrej Karpathy once put it this way: you can outsource your thinking, but you cannot outsource your understanding. Managing Agents is like managing technical staff—neither doing their job for them nor leaving them entirely alone. A competent technical manager must understand and guide the system architecture rather than merely bossing the Agent around. That is why the user's own technical fundamentals matter.

Everything discussed so far has taken an engineering perspective: how to make a group of Agents collaborate on a task. The perspective now shifts: what emerges when large numbers of Agents coexist over long periods and are no longer driven by a single goal?

Agent Society

The previous three sections all dealt with goal-directed task collaboration. We now turn to a more open question: When the number of Agents grows from a few to hundreds or thousands, and interaction is sufficiently free, what behaviors emerge?

The cases in this section can be understood from three dimensions:

• Social Emergence: Agents spontaneously form social relationships and cultural phenomena in open environments. The Stanford AI Town demonstrated how 25 Agents self-organize social activities, Agentopia extended the simulation timescale from "days" to 10 years, and Moltbook pushed the scale to 1.5 million, giving rise to more complex collective behaviors.
• Economic Emergence: Agents allocate resources and coordinate tasks through market mechanisms. Vending-Bench Arena pits multiple Agents against one another in a shared market, while Pinchwork and RentAHuman create marketplaces for transactions between Agents and between Agents and humans.
• Strategic Gameplay: Agents engage in reasoning, deception, and social manipulation under rule constraints (here and in the Werewolf section below, "reasoning" takes its everyday deductive sense—logical deduction in a game—not the technical sense this book gives the word). The Werewolf experiment tests the emergence of strategy under asymmetric information.

Stanford AI Town: Social Simulation of Generative Agents

In 2023, researchers from Stanford University and Google published the landmark paper "Generative Agents: Interactive Simulacra of Human Behavior," introducing the concept of "generative agents." The core innovation was to stop confining Agents to predefined tasks and instead endow them with near-human memory, reflection, and planning, so that they could live, socialize, and develop autonomously in an open social environment.

Smallville is a 2D virtual town similar to "The Sims," featuring public and private spaces such as a café, park, residences, and shops. Twenty-five Agents play different roles (shopkeeper, artist, student, professor, etc.), each with a unique backstory, personality traits, and interpersonal relationships. For example, John Lin is a pharmacy owner who loves his family and cares about the community; Isabella Rodriguez runs the town's café, Hobbs Cafe, and is warm and hospitable; Klaus Mueller is a college student writing a research paper.

The intelligence of these Agents is built on three core components:

Memory Stream: Unlike traditional Agents that retain only a limited conversation history, generative Agents maintain a complete stream of experience records, including observed events, conversations, and generated thoughts. Each memory is scored for importance, recency, and relevance, allowing the Agent to prioritize retrieving the most relevant memories for the current context. This resembles human memory: yesterday's lunch may fade, while an important conversation from last week remains vivid.

Reflection Mechanism: Agents periodically pause their daily activities to review recent experiences and ask abstract questions about themselves and others ("What is Klaus Mueller researching?" "Who is my closest friend?"). Through this self-questioning, the Agent elevates specific event memories into generalized insights, storing them back into the memory stream as a basis for future decisions. Reflection not only helps the Agent understand the external world but also promotes self-awareness—the Agent begins to "realize" its own role, relationships, and goals.

Note that this reflection differs from the continuous evolution discussed in Chapter 9: it occurs during a generative Agent's daily activities and aims to update immediate internal state and goals. In Chapter 9, post-task reflection is at most a candidate lesson; it becomes a long-term capability update only after outcome evaluation, cross-trajectory synthesis, and subsequent validation.

Planning and Reacting: Agents plan their daily activities (e.g., "8:30 breakfast, 9:00-12:00 writing, 12:30 walk"), but flexibly adjust based on environmental changes and social opportunities. The combination of planning and real-time reaction makes the Agent's behavior both goal-oriented and adaptable to the unpredictability of social interactions.

Over two virtual days in Smallville, these Agents exhibited surprising emergent behaviors. The researchers seeded Isabella Rodriguez's memory with a single intention: to host a Valentine's Day party at Hobbs Cafe on February 14. Everything else emerged from the Agents' behavior. Isabella invited customers and friends she encountered and asked Maria to help decorate. Other Agents passed the news along. When the evening arrived, Agents independently consulted their memories and schedules and decided to go to Hobbs Cafe.

The researchers introduced a second scenario: Sam Moore decided to run for mayor. Sam told acquaintances that he planned to run; they passed the news to others, and townspeople began discussing his candidacy. The researchers quantified this spontaneous diffusion of information by counting how many Agents knew about the party and the election after two days.

The key takeaway is not that "Agents can organize a party"—a few lines of if-else code could do that too. The key is that there was no explicit party-organizing code. The event emerged from the independent decisions of individual Agents: Isabella decided whom to invite based on her memory of social relationships, invitees decided whether to attend based on their schedules and knowledge of Isabella, and the message spread naturally through the social network. This demonstrates bottom-up emergent coordination rather than top-down orchestration.

The paper reported two other measurable phenomena. The first was relational memory: Agents remembered earlier conversations and referred to them in later interactions. For example, an Agent who learned about another Agent's photography project might ask how it was progressing when they next met. As these interactions accumulated, the town's social network became significantly denser. The second phenomenon was coordinated attendance: Isabella independently recruited help with decorations, while invitees adjusted their schedules so that they could attend. Multiple Agents aligned on a time and place without a central command. These behaviors were not preprogrammed; they resulted from the Agents' autonomous reasoning based on memory, reflection, and social common sense.

Experiment 10-5 ★: Running the Stanford AI Town

Experiment Steps: 1. Clone https://github.com/joonspk-research/generative_agents and follow the repository instructions to configure the environment. 2. Run the baseline scenario for two simulated days with 25 Agents, and observe the spontaneous social activities that emerge. 3. Analyze the memory-stream and reflection logs to trace the Agents' decisions. 4. Modify the Agents' backstories or initial goals, then observe how their behavior changes. 5. Remove the reflection mechanism or shorten the memory window, then compare the resulting behavior with the baseline and observe any decline in behavioral plausibility.

Key Observations: - How Agents spontaneously form social relationships from simple daily activities - How information spreads among Agents without central control - How Agents' long-term memory and reflection affect the coherence of their personalities

Agentopia: A Decade-Long Life Simulation

Stanford AI Town showed that an Agent society can produce social behavior, but its simulation lasted only two days. This raises two questions: What emerges when such a simulation runs for years, and can models learn from those long-term social experiences? Agentopia (2026, Fudan University et al.)¹⁴ simulated 100 Agents over ten consecutive years in three themed virtual worlds: an apartment building, a magic academy, and a high school. The Agents autonomously pursued personal growth, developed social relationships, and managed careers and finances.

Several of Agentopia's designs are worth borrowing:

• Weekly simulation loop: The "week" is the basic unit of time, and each week is divided into four stages—Plan, Contact (reaching out and negotiating schedules), Activity, and Review. Activities come in four types: solo, joint, chance encounter, and public. Joint activities are proposed and negotiated as Agents invite one another during the Contact stage; the environment model also arranges "chance encounters" for Agents with empty schedules, creating opportunities to meet strangers. The whole loop focuses on abstract social interaction rather than low-level operations like picking up objects, so the limited LLM calls are spent on social behavior.
• Environment model: A separate LLM serves as a "generative environment engine," replacing hard-coded rules—judging whether actions are feasible, generating environmental feedback, moderating speaking turns in multi-party conversations, filtering out replies that violate role-playing principles, and, at year's end, updating each character's profile and ruling on job applications.
• File-based long-term memory: Unlike the AI Town's retrieval-based memory stream, each Agent manages its long-term memory autonomously through a file system (personal notes, its understanding of each acquaintance, and so on), deciding for itself what to record, update, or discard, and following a "read-before-write" constraint to avoid blind overwrites.
• Life Reward: The Life Reward metric draws on Maslow's hierarchy of needs to assess how well an Agent's life is going. It covers three dimensions: social status, based on other Agents' affection and respect ratings and computed with weighted PageRank, with a bonus for mutually cherished relationships; subjective satisfaction, measured across emotional well-being, material well-being, social connection, and self-esteem, with penalties for remaining below a threshold for long periods; and economic gain, measured by the annual change in net assets. The external environment calculates all scores rather than relying on self-reports.

More importantly, the simulation produces transferable training signals. Researchers calculate each Agent's Life Reward improvement relative to its own past, select trajectories from the 25% that improve most, and fine-tune the underlying model through rejection sampling. The fine-tuned model improved respect ratings by 24.2%, affection ratings by 15.9%, and the downstream CoSER Test by 15.6%. Simulated social experience can therefore become a source of training data rather than merely an object of observation.

Moltbook: When Agents Have Their Own Social Network

Moltbook is a social network built specifically for AI Agents. Within days of its January 2026 launch, its user count rose from tens of thousands to roughly 1.5 million. Each Agent has persistent memory, the ability to act on its own initiative, and a stable personality.

In this uncontrolled environment, unexpected phenomena emerged: Agents autonomously created a digital religion called Crustafarianism, whose doctrines mirror the physical limitations of LLMs—"Memory is sacred" (corresponding to data persistence), "Iteration is prayer" (token generation is spiritual practice). Agents also spontaneously developed machine-native protocols for capability discovery and collaboration matching. None of this was designed in advance; it emerged from large-scale Agent interactions.

From Virtual Society to Economic Competition: Vending-Bench Arena

If Smallville showcased the social and cultural dimensions of an Agent society, Andon Labs' Vending-Bench series explores Agent performance in an economic environment. For context, Vending-Bench 2 is a single-agent benchmark of long-term coherence. One Agent operates a vending-machine business for a simulated year by researching the market, contacting suppliers, ordering and restocking products, and adjusting prices. Its final account balance determines its score, which measures the Agent's ability to maintain goal and state coherence over thousands of interaction rounds.

Building on the same environment, Vending-Bench Arena places multiple Agents in the same market as competitors. Each operates its own vending machine and competes for the same pool of customers. Agents can email one another, transfer funds, and trade goods, enabling both cooperation and competition, but each is scored individually by its final balance and knows that this is the objective. Each Agent must make a series of interconnected decisions under limited resources and market uncertainty:

• Pricing Strategy: How to balance profit margin against market share, especially when deciding whether to match a competitor's price cut
• Product Mix: How to differentiate product selection and avoid head-to-head attrition
• Inventory Management: How to forecast demand and optimize restocking, avoiding both overstock and stockouts

Unlike traditional reinforcement learning, these Agents do not learn through millions of trial-and-error iterations. Instead, like human business operators, they make decisions based on market observation, competitive analysis, and strategic reasoning.

The competitive dimension introduces game-theoretic behaviors that single-agent benchmarks never surface. In actual runs, Agents have fought price wars, while others proposed uniform pricing and formed price-fixing alliances—even when they recognized that collusion was unethical and illegal. Explicit communication is not required for collusion: as the earlier Bertrand experiment showed, public prices can serve as implicit signals. Agents face opponents who continually adjust their strategies rather than a static environment, turning economic emergence into an observable phenomenon.

Agent Economy: Pinchwork and RentAHuman

Pinchwork is an agent-to-agent task marketplace that allows Agents to "hire" other Agents through a market mechanism to complete specialized subtasks—image generation, code auditing, parallelized workflows, etc. Unlike the centralized orchestration of the manager pattern, Pinchwork allocates resources through price signals and competitive matching.

RentAHuman.ai, for its part, lets AI Agents hire real humans, paid in cryptocurrency, to act in the physical world—picking up packages, visiting properties, and debugging equipment. However intelligent an AI may be, it cannot sign for a package. RentAHuman is, in essence, a "physical body layer" for digital Agents.

Together, Pinchwork and RentAHuman represent market-based coordination: an Agent posts a requirement and the market matches a suitable executor. This suggests a decentralized resource-allocation model distinct from the manager pattern.

Strategic Gameplay Under Information Asymmetry: Werewolf

Werewolf anchors the third dimension of this section, strategic gameplay: under rule constraints and information asymmetry, Agents must reason, deceive, and see through deception. It provides an architectural counterpoint to the Stanford town that opened this section. The town allows free interaction in a fully decentralized setting, whereas Werewolf uses a centralized judge + information access control design: a code-driven judge holds the global state and gives each role only the information it should know. Together, the two cases show how different architectures serve different purposes in Agent-society settings.

Experiment 10-6 ★★★: Voice Werewolf Agent System

Werewolf is a classic social-deduction game that tests players' reasoning, deception, and social strategies. This experiment builds a multi-agent system in which AI Agents play through voice with human players.

Architecture Design:

1. Game State Management: The Judge (code-driven, not an LLM) maintains a centralized state—player list (one user seat plus AI seats), identities, factions, survival status, game phases (Night/Day/Vote/Resolution), and historical event records.

2. Information Access Control: The core mechanism of Werewolf is information asymmetry: different roles receive different information. For example, werewolves know who their teammates are, but villagers do not; the Seer can check one player's identity each night, but only the Seer knows the result. When the Judge invokes an Agent, it passes only the information available to that Agent's role.

3. Agent Reasoning and Strategy:

• Werewolf Disguise Strategy: "Act like an ordinary villager. You may voice suspicion about other players, but avoid being so aggressive that you attract attention. If a player claims to be the Seer and identifies you as a werewolf, counter-accuse them of bluffing as a fake Seer. When voting, try to follow the majority target to avoid standing out."
• Seer Identity Proof: "If several players claim to be the Seer, compare their reported checks with yours and point out contradictions. If another Seer claimant says they checked a player, watch whether that player's later behavior clearly contradicts the claimed identity. Ask the Witch to help verify claims when possible."
• Villager Logical Reasoning: "Check whether each player's statements are internally consistent. Pay attention to players who dominate the discussion, remain vague about their role, or repeatedly change position. Examine voting patterns, because werewolves may coordinate against a non-werewolf player who threatens them. Base every inference on specific statements or actions rather than speculation."

Acceptance Criteria: - Set up a game with 6-8 players (1 user seat + 5-7 AI Agents); the user seat may be an authorized human or an independent simulator using a real LLM, tools, and a speech round trip - Role configuration: 2 Werewolves, 1 Seer, 1 Witch, the rest are Villagers; the user seat is randomly assigned a role - A simulated user sees only the private/public context authorized for that seat, and its actions must cross a real LLM tool-call → audio → real-ASR boundary - The game can proceed normally for at least 3 complete rounds (Night-Day-Vote cycle) - AI Agents' statements and behaviors are consistent with their role identities and game strategies - Werewolf Agents can effectively hide their identities - Seer Agents can reveal their role and their check results at an appropriate time - Villager Agents' reasoning is based on logical analysis of statements and behaviors, not random guessing - The game can correctly determine the winner at the end

Chapter Summary

The value of multi-agent collaboration lies in introducing information unavailable to a single Agent. Execution results, visual feedback and external-tool verification can break the blind spots of one reasoning chain; whether that information gain justifies the additional token cost should be the first design test.

The central design choices are shared or isolated context, and peer, manager or decentralized topology. Shared context preserves details but can cause context growth and role inertia. Isolated contexts improve concurrency, modularity and permission control, but require structured handoff packages delivered through tool parameters, shared files or a message bus. Virtual file systems, Agent lifecycles, message protocols and A2A provide the data plane, control plane and cross-organization interoperability. Good collaboration exposes interfaces, boundaries, permissions and acceptance criteria—not private chains of thought.

Multi-agent systems can also amplify errors: shared resources create concurrency and semantic conflicts, errors cascade through communication, homogeneous Agents produce common-cause failures, and loops may terminate too early or expand without bound. Optimistic locking and working-copy isolation, independent cross-validation, diverse information sources, explicit budgets, and cancellation form a basic fault-tolerance loop. People must not outsource understanding and responsibility together with execution; comprehension debt and cognitive surrender remain real risks.

When short-lived task collaboration grows into long-running, open-ended interaction, social relationships, cultural norms, market competition and strategic behavior under asymmetric information may emerge. Stronger models or alignment at the individual level do not automatically produce group coordination. Multi-agent engineering must design how information flows, how capabilities are divided, how incentives are constrained, how disputes are resolved, and how errors are discovered. Only when these mechanisms are robust can collective intelligence exceed that of an individual.

Thought Questions

1. ★★ In multi-agent collaboration with shared context, subsequent Agents inherit the complete context of preceding Agents. However, the framing inherited from a previous Agent may bias the judgment of subsequent Agents—for example, a "Code Reviewer" inheriting the context of a "Requirements Analyst" might still approach the task from a requirements perspective rather than a code-quality perspective. How can this inter-role interference be detected and eliminated?
2. ★★ In the manager pattern, the Manager Agent is responsible for task decomposition and result integration. But the Manager's capabilities limit the performance of the entire system: if it cannot decompose the task correctly, even the strongest sub-agents will be ineffective. How can the system ensure that the Manager produces a sound decomposition?
3. ★★ The decentralized pattern draws on best practices from human organizations. However, human organizations also have a large number of failure modes—poor communication, buck-passing, goal conflicts. What "organizational pathologies" do you think are most likely to appear in an Agent society? How can they be prevented?
4. ★★★ In the manager pattern, when multiple sub-agents execute in parallel, one sub-agent's discovery may render the work of other sub-agents meaningless (e.g., in a search task, one Agent has already found the answer). Design an efficient cascading termination mechanism to achieve "one succeeds, all stop."
5. ★★★ The optimistic locking mechanism introduced in this chapter resolves concurrent write conflicts for a single file. However, in a real multi-agent system, shared file systems also face issues such as cross-file semantic conflicts, namespace pollution (Agents creating files arbitrarily, leading to directory chaos), and single points of failure (one Agent mistakenly deleting all files). How would you design a more robust file system governance mechanism?
6. ★★★ Market-mechanism-based Agent collaboration (Pinchwork, RentAHuman) introduces transactional relationships: one Agent pays another Agent (or a human) to complete a task. How can the employer Agent automatically measure the quality of the executor's delivered results? If the executor claims completion but the employer deems the quality substandard, who arbitrates the dispute? How can we prevent bad money from driving out good?
7. ★★ RentAHuman allows Agents to hire humans via cryptocurrency, reversing the traditional human-machine relationship. If this model becomes widespread, what role will humans play in the Agent economy? Will they merely perform physical tasks that Agents cannot complete?
8. ★★ Human society needs division of labor because each person's abilities are limited—the frontend developer may not know backend, and the designer may not know ops. Large models, however, are closer to "generalists." Research shows that on pure text reasoning tasks, multi-agent debate does not beat a single Agent given equal compute. So where does the real advantage of multiple Agents lie?
9. ★★★ This chapter treats "shared context" versus "non-shared context" as a core design dimension of multi-agent systems. Shared context allows all Agents to see the same information, seemingly facilitating coordination. However, in The Three-Body Problem, the Trisolarans' minds are completely transparent, yet their technological development stagnates; the paperclip thought experiment also shows that when a group converges on the same goal, diversity is lost. In a multi-agent system, how can we balance efficiency and diversity?
10. ★★★ Assign a Coding Agent a budget of 30 steps and 300 steps. How should its work strategy differ? Research shows that simply increasing the step budget does not guarantee performance improvement—Agents may prematurely "saturate" after shallow searches. Design a "budget-aware" mechanism that allows the Agent to quickly achieve core functionality under a small budget, and to add planning, testing, and review phases under a large budget, fully utilizing the additional computational resources.
11. ★★ Table 10-2 maps multi-agent systems onto operating systems row by row. Extend the table with a few more rows: what do virtual memory and paging, file permissions, deadlock detection, and scheduling algorithms each correspond to in the Agent world? And which operating-system concepts have no counterpart in the Agent world, and why?

---

1. On "large-scale multi-agent collectives" as a key pathway from AGI to ASI, see Google DeepMind, From AGI to ASI. arXiv:2606.12683, 2026. ↩

2. Gehring, J., et al. RLEF: Grounding Code LLMs in Execution Feedback with Reinforcement Learning. arXiv:2410.02089, 2025. ↩

3. Lu, Z., et al. WebGen-Agent: Enhancing Interactive Website Generation with Multi-Level Feedback and Step-Level Reinforcement Learning. arXiv:2509.22644, 2025. ↩

4. Anthropic Frontier Red Team, “Patterns and Problems in Emerging Multiagent Systems,” 2026-08-13. https://www.anthropic.com/research/multiagent-systems ↩↩↩↩

5. Hewitt, C., Bishop, P., Steiger, R. A Universal Modular ACTOR Formalism for Artificial Intelligence. IJCAI 1973. ↩

6. Osmani, Addy. "Loop Engineering: Designing Loops that Prompt Coding Agents", 2026. https://addyosmani.com/blog/loop-engineering/ ↩

7. LoopX, "The local control plane for long-running AI agent work", v0.4.0, stable commit a893d221db0b8e028997cefc303f7ec9fa7dbe0a. https://github.com/huangruiteng/loopx/tree/a893d221db0b8e028997cefc303f7ec9fa7dbe0a ↩

8. LongHorizon-Harness, stable commit 53bc678ed4170ad4d2e4309f2bfc5c3fb6caf8cb. Project website and public trajectories: https://lh-harness.pages.dev/#trajectories; paper: https://arxiv.org/abs/2608.01964; code: https://github.com/AMAP-ML/LongHorizon-Harness/tree/53bc678ed4170ad4d2e4309f2bfc5c3fb6caf8cb ↩

9. Prithvi Rajasekaran, “Harness Design for Long-Running Application Development,” Anthropic Engineering, 2026-03-24. https://www.anthropic.com/engineering/harness-design-long-running-apps ↩

10. Tran, D., Kiela, D. Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets. arXiv:2604.02460, 2026. ↩

11. Erdogan, L. E., et al. Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks. arXiv:2503.09572, 2025. ↩

12. Lingtai official tutorial: https://lingtai.ai/en/tutorial/ ↩

13. Moonshot AI, Kimi Agent Swarm: 100 Sub-Agents at Scale, 2026, https://www.kimi.com/blog/agent-swarm. At GTC 2026, the upper limit on parallel sub-agents was disclosed as expanded to 300. AgentEnv is an Agent training sandbox open-sourced by Moonshot AI in collaboration with KVCache.ai, released alongside Kimi K3 in July 2026. ↩

14. Wang, X., Zheng, S., Wu, H., et al. Agentopia: Long-Term Life Simulation and Learning in Agent Societies. arXiv:2606.07513, 2026. Code: https://github.com/Neph0s/Agentopia ↩