Multi-Agent Architecture: Topology, Task Decomposition, and Communication Between Agents | Harvard CS2680 Lecture 5

🌏 中文版

Video status: The course is not recorded. This post is based on the public slides; the numerical examples are this site's additions. Source notes

Lecture 5 of CS2680 met on September 23, 2026, under the title "Agent Design II: Multi-Agent Systems" (slides). Lecture 3 took the user's side and showed how to run subagents and agent teams in Claude Code. This lecture takes the designer's side and asks how several agents should be put together.

The lecture answers two questions: when should you split work across several agents, and once you do, who directs whom and how do messages move? By the end you should be able to use a granularity formula to judge whether a task is worth splitting, and to point out which part of the communication is most likely to break for the split you chose.

The slides have three parts: architecture (p5–18), task decomposition (p19–25), and communication (p26–43), followed by four design principles (p44). The outline on p3 lists agent memory, but this deck doesn't cover it; memory moved to Lecture 6.

Why split, and how to describe a split

Four reasons

The slides give four reasons to split work across agents (p6):

• Specialization: different agents use different models, prompts, and tools.
• Isolation: different agents get different privileges, for example only one agent may write to production.
• Parallelism: independent subtasks run at the same time.
• Context management: not every agent has to carry the whole trajectory.

The last point builds on the conclusion of Lecture 4: context is a finite resource, and the longer it gets, the more it costs and the more the model misses. Hand the search to another agent and the main agent receives only the distilled result, so its own context stays clean.

Three graphs

The lecturer describes any architecture with three questions (p7):

The three graphs vary independently. With the same "one supervisor in charge," the work can be split up front or as it goes; messages can all pass through the supervisor or be written to shared files. Every one of the eight architecture slides that follow labels these three columns at the bottom.

Eight architectures

The pipeline slide has a useful line: "one retry edge beats one more agent" (p11). This post reads it as: when something goes wrong between stages, having the previous stage redo its work is often cheaper than adding another agent.

The summary table on p18 has a weakness column. This post maps it onto communication to show where each architecture is most likely to break:

• Supervisor–worker: aggregation, because the summaries workers hand in lose detail.
• Pipeline: errors travel all the way downstream.
• Blackboard: concurrent writes, and reading stale state.
• Committee: members aren't independent and end up agreeing with each other.
• Swarm: too many messages, and questions that go around in circles.

All of these failures come back when we get to communication.

Real systems are mostly hybrids (p17). The slide's example: under a supervisor, a planner produces a task DAG and re-plans when needed; coding, research, and testing agents share one Git repo; a reviewer checks the result at the end. That uses a hierarchy, shared memory, and a pipeline at once.

Compare this with the tools from Lecture 3 (the slides don't make this comparison): a Claude Code subagent is supervisor–worker and reports its result only to the main agent. An agent team's shared task list works like a blackboard, and the mailbox between teammates is point-to-point messaging.

Self-check: the GPU auction rule on p14 is "the cheapest bid that finishes within 5 seconds wins." The A100 node bids $0.20 and 3 seconds; the T4 bids $0.05 and 10 seconds; the H100 bids $0.40 and 1 second. Who wins? What if the T4 falsely claims 4 seconds? Answer: the A100. The T4 is cheapest but takes more than 5 seconds, so it's out; of the A100 and H100, the A100 is cheaper. If the T4 claims 4 seconds it wins, and the job actually takes 10 seconds. That is this architecture's weakness: bids are self-reported.

Task decomposition

Six ways to split, and what a subtask needs

Work can be split along six dimensions (p20):

• Data: each agent handles a subset of documents or records.
• Expertise: security, performance, correctness, and legal each take a pass.
• Stage: plan, implement, test, review.
• Hypothesis: each agent investigates one possible explanation.
• Tool: web, database, code execution, internal documents.
• Authority: agents act in different administrative domains.

Splits can be stacked. The slide's example is a PR touching 200 files: split it by file first, then by the two areas of expertise, security and performance (p20).

Each subtask should spell out eight things: the objective, inputs and relevant context, boundaries and exclusions, available tools and permissions, the output format, what counts as done, budget and deadline, and which other tasks it depends on (p21). "Research storage systems" is a poor subtask. "Identify storage-related papers published in 2026; return title, date, system contribution, evaluation scale, and primary-source URL; exclude database query optimization" is a good one.

Anthropic made the same point about its own Research feature: early on, the lead agent gave short instructions like "research the semiconductor shortage," and subagents duplicated each other's work and left gaps. Anthropic then required every subtask to state an objective, an output format, guidance on tools and sources, and clear boundaries.

Will splitting make it faster? The granularity formula

If subtasks are too large, there isn't enough parallelism and the work still happens one piece after another. If they're too small, scheduling and communication overhead outweighs the time saved (p22). The slides give an estimate:

T_multi ≈ T_planning + T_critical_path + T_communication + T_merge

The time to finish with several agents is roughly planning, critical path, communication, and merging added together. The critical path is the longest chain of work whose pieces depend on each other and must happen in order. Parallelizing pays off only when the sequential work it saves exceeds the cost of planning, communication, and integration.

Here is one worked example from this post. A task takes a single agent 30 minutes. Split it into three subtasks:

In the second row the critical path grows to 25 minutes: the last two subtasks wait for the result of the one before, and only about 5 minutes of the three pieces can overlap. Splitting here just adds planning, communication, and merging costs on top of the original work.

The formula counts only time to finish, not cost. Three agents running in parallel finish sooner but use more tokens than one agent: each one reads the background and instructions separately, and communication and merging come on top. Anthropic measured multi-agent systems using about 15 times the tokens of an ordinary chat. Whether that's worth it is a separate calculation.

Self-check: the example on p22 batches 20 "one-line" lookups into 4 subtasks. Why not run 20 agents? Answer: each lookup takes only seconds, so the planning, communication, and merging cost of starting an agent is larger than the lookup itself. In 4 batches, each batch has enough work to justify those fixed costs.

Split up front, or split as you go

There are four timings for decomposition (p23):

• Static: split before execution; predictable and easy to evaluate. For example, summarize each of five uploaded PDFs.
• Dynamic: agents create new tasks as they discover things. For example, a dead link spawns a lookup task.
• Recursive: workers delegate further down. For example, a review agent starts one sub-agent per subfield.
• Opportunistic: idle agents claim the next available task. For example, an idle agent picks up the next unlabeled document.

Every decomposition needs limits, and the dynamic, recursive, and opportunistic kinds need them most: how many agents may be spawned, how much budget, how many levels deep delegation can go, and when to stop. Without them, delegation explodes recursively (p23). Anthropic's Research feature made this mistake early on: it spawned 50 subagents for a simple question.

Six common decomposition failures

The examples all come from p24–25; the "how to prevent it" column is this post's mapping onto the subtask spec on p21. This series files these six failures under the harness layer of Lecture 6's five-layer attribution, because the harness decides how work is split. The straggler is exactly the "blocking fan-out" that Lecture 6 lists under the harness layer. Overlap, gaps, and hidden dependencies can also be seen as subtask specs that weren't written clearly. For a fuller taxonomy of multi-agent failures, read MAST: the authors analyzed execution traces from 7 multi-agent frameworks and identified 14 failure modes in three categories: system design, misalignment between agents, and verification.

Communication

Four dimensions

Communication between agents has four design dimensions (p27):

• Topology: who can talk to whom, decided by the architecture you chose.
• Medium: how information is exchanged. Messages over a queue, a shared in-memory state object, or work products in files and databases (p28).
• Channel: how it's sent. Point-to-point, broadcast, publish–subscribe, a shared blackboard, request–response, or handing over an artifact (p29).
• Format and semantics: what a message looks like and what action it expresses.

The recommended format uses both (p30–31): natural language for content, structured fields for coordination. A message carries an id, a task_id, a sender, a recipient, and a type the runtime (the program that routes messages) recognizes, such as DELEGATE, REPORT, CANCEL, ACK, or ERROR; the actual content goes in the payload (the body of the message). The runtime can then route, retry, and stop without asking an LLM what the message meant. The slides' rule of thumb: route on the fields, not the prose (p32).

The 9/23 reading list also includes two earlier frameworks that this post doesn't go into: AutoGen builds multi-agent systems as agents conversing with each other; MetaGPT writes standard operating procedures into prompts, divides roles like an assembly line, and has roles with domain expertise check intermediate results, which is close to the pipeline above.

Communication is really a distributed systems problem

On p33–34 the slides only name the concepts and give one timeout scenario. This section works through two examples: the first is this post's addition, the second extends p33.

Example 1: two agents edit the same file. Agents A and B both read config.ts. A adds a setting and writes the file back. B edits a different line based on the old version it read, and writes it back too. B's version doesn't include A's change, so A's work silently disappears and nobody reports an error. This is the concurrent-write problem of the blackboard architecture (p12). There are three common fixes: only one agent writes at a time, lock before writing, or each agent works on its own branch and Git merges them. Cognition's 2026 post likewise treats "writes stay single-threaded" as the precondition for multi-agent setups that work reliably today (see the design principles).

Example 2: a message times out. The slide's example: agent A asks B to "purchase 8 GPU instances," the network times out, and A gets no reply (p33). A doesn't know whether B made the purchase. Resend, and you might end up with 16 instances; don't, and you might have none. A also can't tell whether B is slow or dead, which is the "partial failure" listed below. Resending is at-least-once in the table below; not resending is at-most-once. Distributed systems describe this trade-off with three delivery semantics (definitions from Confluent's Kafka documentation):

The most common combination in practice is at-least-once plus an idempotent receiver: resending is fine because the receiver recognizes duplicates. The slides suggest an idempotency key on the task_id: when B sees the same key again, it returns the previous result instead of buying again, and if something does go wrong there has to be a compensation or rollback path (p33). Kafka's idempotent producer uses the same idea: each sender (the producer) has an id, and the server that stores messages in between (the broker) uses sequence numbers to recognize duplicates.

The slides then list the difficulties distributed systems already have (p34):

• The network delays, drops, reorders, and duplicates messages.
• Clocks on different machines disagree.
• Many parties modify the same state at once.
• You can't tell a slow agent from a dead one (partial failure).
• Replicas trade consistency against availability.
• Logs are scattered and their timestamps don't line up.

Multi-agent systems inherit all of these and add three more: scheduling, resource allocation, and state management. And there's no predetermined request flow, so the system can't know who needs to run, for how long, or with how many resources (p35).

LLMs add another layer (p36): summaries drop what the worker knew; what matters gets buried in a long context; B still acts on X=3 after X became 5; A says it's safe while B says it's vulnerable; every agent thinks someone else owns the task; A asks B, B asks C, and C asks A, in a loop.

Self-check: a worker's completion report arrives twice. What happens to the supervisor, and how do you design against it? Answer: if the supervisor does a follow-up action every time it receives a report (merging the result, charging the budget, assigning the next task), the duplicate report makes those actions happen twice. The fix is to make report handling idempotent: each report carries a task_id or message id, the supervisor records the ids it has already handled, and when the same id arrives again it only sends an ACK and does nothing else.

A2A and MCP: agent to agent, agent to tool

A2A (Agent2Agent) is an open protocol for agents to work together; the current specification is version 1.0.0. The flow: A first looks up B's capabilities, sends a message that creates a task, receives progress updates, and finally gets the output back (p37).

• Agent card: every A2A server publishes a machine-readable card at /.well-known/agent-card.json that says who it is, what it claims to do, where and how to call it, whether it supports streaming and push notifications, and which authentication scheme to use (p38).
• Three abstractions: a Message is one turn of conversation; a Task is a unit of work with an id and a state; an Artifact is what the task produces, such as an itinerary PDF and booking data (p39).
• Task states: submitted and working, plus four terminal states: completed, failed, rejected, and canceled. A task can pause in input required or auth required and return to working once the missing information arrives. For example, "Book a flight to Boston" → "Which date?" → "Oct 3" all belong to the same task (p39–40).
• Following long tasks: poll for short jobs, stream for interactive output, use a webhook push notification for jobs that run for hours (p41).

The lecturer's summary: A2A standardizes communication, not orchestration (p41). Whether to delegate, how to split, and when to stop are still the harness's job. The specification itself also stresses "opaque execution": agents collaborating don't need to share their internal thoughts, plans, or tool implementations.

MCP (introduced in Lecture 2) handles the boundary between an agent and tools or data (p42–43):

MCP standardizes three primitives: tools are callable functions, resources are data the host can attach, and prompts are reusable interaction templates. The slides say "one client speaks to many servers"; the current MCP specification puts it this way: one host (such as Claude Code) runs several clients, and each client connects to exactly one server. The host decides which servers may connect and what the user has consented to; the model decides when to call a tool.

The two stack: a remote agent reached through A2A may itself call twenty MCP servers (p43, an illustrative figure).

Four design principles and the counterarguments

The slides end with four principles (p44):

1. Is multi-agent really necessary? A single agent is usually enough; multiple agents often only add cost and complexity.
2. Choose the topology from the task's dependencies, and keep communication to a minimum.
3. Find where information gets lost: every aggregation node drops detail.
4. Draw failure-containment boundaries: one stuck agent must not stall the whole system.

The closing line: a dense mesh is rarely the best default, and more communication can increase context pressure without adding useful information.

The first principle is the heart of the lecture. After laying out eight architectures, the lecture's first principle asks whether to split at all, and the assigned reading includes a piece arguing against it.

The counterargument: Cognition. In June 2025, Walden Yan of Cognition wrote "Don't Build Multi-Agents," which sets out two principles: first, agents must share context, and share full agent traces, not just individual messages; second, actions carry implicit decisions, and conflicting decisions produce bad results. His example is building Flappy Bird: one subagent builds the background and another builds the bird; the background ends up looking like Super Mario, the bird's style and movement don't match the game, and the agent that has to combine them is left with two contradictory pieces. His recommendation: the simplest approach is a single-threaded agent. The same post also says a subagent that only answers a question and doesn't write code is acceptable, citing Claude Code's subagents at the time.

Ten months later, in "Multi-Agents: What's Actually Working" (2026-04), he drew the boundary more precisely: his original observations still hold for multiple agents writing in parallel, but setups where several agents contribute judgment while writes stay single-threaded do work. His example is letting a coding agent and a review agent iterate against each other, where the review agent shares no context beforehand and catches more bugs because of it.

Even the people who build multi-agent systems add caveats. Anthropic's Research feature uses Opus 4 as the lead agent and Sonnet 4 as subagents, and outperformed a single Opus 4 by 90.2% on Anthropic's internal research eval. The same post also says multi-agent systems use about 15 times the tokens of a chat, so the task has to be valuable enough to pay for it. It adds that most coding tasks have fewer truly parallelizable parts than research, and that domains where every agent must share the same context aren't a good fit for multi-agent systems today. Cognition's 2026 post also notes that this Anthropic post and his first one reached similar conclusions: the first place multi-agent systems pay off is agents that read but don't write.

What controlled studies say. Kim et al. (Google Research, MIT, and others; an arXiv preprint) held tools, prompts, and compute fixed and compared a single agent with four multi-agent architectures across 260 configurations. The result depends on the task:

• On financial reasoning that can be decomposed, centrally coordinated multi-agent systems did 80.8% better than a single agent.
• On tasks that require sequential planning, with agents working independently, they did 70% worse.
• On tasks where a single agent already exceeds 45% accuracy, adding agents made things worse.
• With independent agents and no central verification, one agent's error propagates all the way to the final answer; architectures with central coordination amplify errors only about a quarter as much.

Tran and Kiela (2026, an arXiv preprint) held the reasoning-token budget fixed before comparing. On multi-hop reasoning, a single agent matched or beat multi-agent systems. They argue that many reported multi-agent advantages actually come from unaccounted-for compute and context effects.

Taken together, these sources point to the same conditions: split only when the task decomposes, the subtasks depend little on each other, and the extra tokens are worth it; have someone responsible for verifying and merging, and keep writes in one place. That's why the granularity formula (time) and the token bill (cost) have to be worked out together.

Final self-check

1. You're building an agent that "reads 50 customer interviews and identifies the top five pain points." A single agent reads each one in 1 minute, 50 minutes in total. Instead, 5 workers read 10 each, with an estimated 2 minutes of planning, 3 minutes of communication, and 6 minutes of merging. Use the granularity formula to work out how long the split takes. Is it worth it? Which way of splitting and which architecture? Which part of the communication is most likely to break? Criterion: you get 2 + 10 + 3 + 6 = 21 minutes, faster than 50, so it's worth it; splitting by data with independent subtasks suits supervisor–worker. The likeliest communication failure is the supervisor losing detail when aggregating (information loss on p36, principle 3), so every worker should use the same output format and attach the original quote and interview number to each pain point, letting the supervisor check back and merge similar items.
2. Two coding agents change the same repo in parallel, and CI passes some runs and fails others for no clear reason. Based on this lecture, what's the most likely cause? Criterion: you identify concurrent writes in a blackboard architecture (p12): both agents read an old version and write back, the last writer wins, so the CI result depends on execution order; conflicting implicit decisions are another possibility. The fix is to keep writes in one agent, or have each work on its own branch and merge.
3. Your agent needs to call a quoting agent built by another company; a quote may need manual approval and take hours. MCP or A2A? How do you follow progress? Criterion: you choose A2A, because the other side is an opaque agent and the task runs long and may pause in input required; follow progress with a push notification (webhook).

Further reading

• Lecture 3: Running many agents at once: the user's view of this lecture's architectures, and how to actually run subagents and agent teams.
• Multi-Agent Orchestration Patterns: Scripted, Model-Driven, or Hybrid: who decides the next step, and the trade-offs among three orchestration philosophies.
• Multi-Agent Communication: Handoff, Delegate, Mailbox, and the Push for Protocol Standards: the implementation side of this lecture's communication section.
• The Protocol Layer: MCP, A2A, ACP, Skills: protocols beyond A2A and MCP.
• Cemri et al., Why Do Multi-Agent LLM Systems Fail?: MAST's 14 multi-agent failure modes.

Course video sources

• The course is not recorded (policy page).
• Source: Lecture 5 slides (PDF pages p5–44) and the 9/23 reading page, read on 2026-10-22. Page numbers always follow PDF page order.
• Numbers cited in the readings and slides were checked against the originals: Anthropic's Research post, both Cognition posts, Kim et al. (arXiv 2512.08296 v3), the A2A 1.0.0 specification, and the MCP 2026-07-28 specification; places that differ from the slides are flagged in the text. The Tran and Kiela study, Cognition's 2026 post, and the Confluent documentation are sources this site added.
• The 30/20/35-minute granularity example, the two-agents-editing-one-file example, and the answers to the self-checks are this site's additions, not lecture content.

Changelog

• 2026-10-23: Added links to the Lecture 6 post.

References

• CS2680 Lecture 5 slides: Agent Design II: Multi-Agent Systems
• CS2680 readings: 9/23
• Anthropic: How we built our multi-agent research system (2025)
• Walden Yan (Cognition): Don't Build Multi-Agents (2025)
• Walden Yan (Cognition): Multi-Agents: What's Actually Working (2026)
• Kim et al., Towards a Science of Scaling Agent Systems (2025)
• Tran & Kiela, Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets (2026)
• Cemri et al., Why Do Multi-Agent LLM Systems Fail? (2025)
• Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (2023)
• Hong et al., MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework (2023)
• A2A Protocol Specification
• Model Context Protocol: Architecture (2026-07-28)
• Model Context Protocol: Server features (2026-07-28)
• Confluent: Message Delivery Guarantees for Apache Kafka