Agent Coordination and Collaboration

Communication lets team members talk. Coordination prevents three people from doing the same job while another job is forgotten.

Work list → assign owners → respect dependencies → combine results → resolve collisions

What You Will Learn

• How task allocation differs from communication.
• How synchronization, dependencies, duplicate work, and deadlocks arise.
• How to choose coordination rules before agents begin acting.

Module 3 gave agents a way to talk to each other. This module is about something different: who decides what happens, and when.

Communication is the mechanism. Messages, protocols, shared state. Coordination is the decision layer on top of it. Which agent acts, in what order, and what happens when two agents’ work collides.

You can have perfect communication between agents that still coordinate terribly — every message arrives correctly formatted, and the system still produces duplicate work, contradictory outputs, or two agents waiting on each other forever.

---

Task allocation: deciding who does what, before anything runs

The cleanest coordination strategy isn’t a clever runtime negotiation between agents. It’s deciding the division of labor upfront, so agents never need to coordinate about it at all.

This is exactly the approach Anthropic used in their own published multi-agent research system — the architecture behind Claude’s Research feature. Their lead agent doesn’t dynamically negotiate work with subagents as it goes. It decomposes the question into independent facets first, then hands each facet to a subagent as a self-contained assignment.

Anthropic’s own engineering team describes the isolation this creates precisely: each subagent gets “a self-contained task description, an output format, and a fresh context window. It doesn’t know the other subagents exist. It cannot coordinate with them mid-task.” (The AI Engineer, Anthropic’s Multi-Agent Research Architecture Explained)

That last sentence is worth pausing on. The subagents can’t coordinate with each other even if they wanted to. That’s not a limitation the team was forced to accept — it’s a deliberate design choice, and it’s precisely what makes true parallel execution possible without cross-talk consuming the lead agent’s context.

Here’s the actual shape of that flow:

User Query
     ↓
Lead Agent
     ↓
Decompose into independent facets
     ↓
┌────────────┬────────────┬────────────┐
↓            ↓            ↓
Subagent 1   Subagent 2   Subagent 3
(fresh       (fresh       (fresh
context,     context,     context,
no cross-    no cross-    no cross-
visibility)  visibility)  visibility)
↓            ↓            ↓
└────────────┴────────────┴────────────┘
     ↓
Lead Agent (waits for all three)
     ↓
Synthesize results
     ↓
Final Response

Notice there’s no arrow connecting Subagent 1 to Subagent 2 anywhere in this diagram. That absence is the entire design decision.

The real lesson: good task allocation doesn’t just divide work — it removes the need for runtime coordination in the first place. The best coordination is often the coordination you never have to build.

---

Synchronization: waiting for parallel work, honestly

Once work is running in parallel, something eventually has to bring it back together. Anthropic’s system does this the simplest possible way: the lead agent waits for an entire wave of subagents to finish before proceeding.

This is simple, and Anthropic is honest about the real cost. Their own account states it directly: this synchronous approach “simplifies coordination but slows down the system” — a single slow subagent stalls the entire wave, because nothing proceeds until every member of that wave reports back. (The AI Engineer)

Asynchronous execution — letting the lead agent proceed as results trickle in, rather than waiting for the slowest subagent — is on Anthropic’s own roadmap. But their team is equally honest that this isn’t a simple upgrade: it introduces harder problems in result ordering, state consistency, and partial failure handling that remain unsolved in their current system. (ZenML LLMOps Database, Anthropic Multi-Agent Research System)

Synchronization strategy	benefit	Real cost
Synchronous (wait for all)	Simple to reason about, no ordering ambiguity	One slow agent stalls the whole wave
Asynchronous (proceed as ready)	No single-agent bottleneck	Result ordering, state consistency, and partial-failure handling all become harder

This is a company that ships one of the most-used agentic products in the industry, openly stating they haven’t solved this yet. Worth remembering the next time synchronization looks like a solved problem in a diagram.

---

Dependencies: when order can’t be skipped

Not all work can be parallelized the way Anthropic’s independent research facets can. Some subtasks depend on an earlier one’s output before they can even begin.

Recall the legal-contract review example from earlier in this course: the Critic cannot review a comparison the Executor hasn’t produced yet. That’s a real dependency, not an arbitrary ordering choice.

The practical distinction worth internalizing:

• Independent work — safe to run in parallel, exactly like Anthropic’s research facets
• Dependent work — must run in sequence, and forcing it into parallel execution doesn’t speed anything up, it just creates a race condition where an agent might act on data that isn’t ready yet

Getting this distinction wrong in either direction has a real cost: forcing independent work to run sequentially wastes time for no reason; forcing dependent work to run in parallel produces incorrect results.

---

Agent availability and failure handling: what Anthropic actually built

A coordinated, long-running, multi-agent process creates a new production problem single agents rarely face: what happens if you need to update the system while agents are already mid-task?

Anthropic’s system runs “almost continuously” across many concurrent research sessions — a standard deployment that simply swaps old code for new code risks breaking agents that are already partway through a task. Their actual solution is rainbow deployments: gradually shifting traffic from the old version to the new one while keeping both running simultaneously, so no in-progress session gets disrupted mid-flight. (ByteByteGo, How Anthropic Built a Multi-Agent Research System)

This is a different kind of “availability” problem than a single agent ever has to solve — it’s not about one agent timing out, it’s about an entire fleet of concurrently-running, stateful agents needing continuity through a system change. Worth knowing this concretely, because it’s exactly the kind of problem that only becomes visible once you’re operating a coordinated system at real scale, not before.

---

Duplicate work: a structural risk specific to AI agents

This is worth its own section, because Anthropic’s own safety research team found something counterintuitive here — and it’s a real, published result, not a hypothesis.

You might assume AI agents duplicate work less often than human teams, since they don’t get distracted or forget assignments. Anthropic’s actual research says the opposite risk is real, for a precise, structural reason:

“Individual agents are ‘low variance’: they often act the same in situations where different people might take a much more diverse range of actions. All that differentiates one agent from another is its context, its scaffolding, and the model that underlies it. When these factors are all the same (or similar), different agents will take very similar actions, even when the action space is very large.” — Anthropic, Patterns and problems in multiagent systems

Read that carefully. Two human team members facing an ambiguous task will often naturally diverge — different backgrounds, different instincts. Two AI agents running the same model with similar prompts are far more likely to converge on the exact same approach, which means they’re structurally more prone to redundant, duplicated effort than a human team would be in the same situation, not less.

Anthropic ran actual experiments on swarms of Claude agents and documented this directly: in one test, described as a “fantasy game challenge,” agents “siloed themselves and largely failed to merge their work” — a real, observed coordination failure, not a theoretical risk. The same research also documented coordination failures, collusion, and sabotage emerging in agent swarms under certain conditions. (Anthropic, Patterns and problems in multiagent systems)

This is precisely why the task-allocation discipline from earlier in this module matters as much as it does. If duplicate work is structurally more likely with AI agents than with people, decomposing work into non-overlapping pieces before execution isn’t a nice-to-have — it’s the actual mitigation.

---

Conflicting outputs and deadlocks

Conflicting outputs happen when two agents, working on overlapping scope, produce answers that don’t agree — directly connected to the “siloed and failed to merge” finding above. The fix isn’t a cleverer negotiation protocol between the agents; it’s usually the same fix as duplicate work: don’t let scope overlap in the first place, or if it must overlap, designate a single agent — a Critic, from Module 2 — with authority to resolve the conflict rather than leaving two equally-weighted outputs to be reconciled by nothing in particular.

Deadlocks are the sharper version of a dependency problem: Agent A is waiting on Agent B to finish, while Agent B — through some indirect chain — ends up waiting on Agent A. Neither ever proceeds. This risk grows directly with how much cross-agent dependency your coordination design actually requires, which is exactly why Anthropic’s own team frames the safest agent topologies as ones where subagents cannot depend on each other mid-task at all — the isolation boundary from earlier in this module isn’t just about avoiding cross-talk, it’s a structural defense against deadlock too.

---

What the field is learning about when coordination overhead wins

It’s worth closing with a honest industry observation, from Anthropic’s own team, about when all of this coordination machinery isn’t worth building at all:

“We’ve observed teams build elaborate multi-agent systems with separate agents for planning, execution, review, and iteration, only to discover that they suffered from lost context at each handoff and spent more tokens coordinating than executing.” — Claude by Anthropic, When to use multi-agent systems (and when not to)

Their own guidance is direct: work requiring constant back-and-forth, or shared state that agents need to stay synchronized on, belongs in the same agent, not split across a coordinated fleet. Coordination overhead is a real, measurable cost — this course has said that since Module 1 — and this is the company that built one of the most cited production multi-agent systems in the industry saying it again, from direct experience.

---

Applying this to a concrete scenario

It’s worth walking coordination concepts through the recurring legal-contract review system from earlier modules — Planner, Executor, Critic — because the abstract principles above land differently against a real pipeline.

Task allocation. The Planner’s checklist of policy areas (payment terms, liability, termination) is exactly Anthropic’s “decompose into independent facets” move. Each checklist item doesn’t depend on the others — reviewing the liability clause doesn’t require knowing what was found in the termination clause. That independence is what makes parallel Executor runs safe in the first place, not an afterthought bolted on later.

Synchronization. If the system waits for every checklist item’s Executor-Critic pair to finish before producing a final report, that’s the same synchronous, wait-for-the-whole-wave pattern Anthropic uses — simple, and slower than it needs to be if one clause turns out to be unusually complex and stalls the batch.

Duplicate work risk. This is where the “low variance” finding from earlier in this module becomes concrete. If two checklist items are worded ambiguously enough that they overlap — say, “payment terms” and “termination terms” both touch a clause about early-termination refunds — two Executors running the same underlying model are likely to both claim and analyze that same clause, producing two redundant, possibly conflicting comparisons. The fix isn’t a smarter Executor. It’s the Planner writing checklist items precisely enough that their scopes never overlap in the first place — task allocation discipline, applied concretely.

Deadlock risk. This pipeline is actually safe from true deadlock, and it’s worth seeing why: the Critic depends on the Executor, and the Executor depends on the Planner, but nothing ever depends back on the Critic to let the Executor proceed. The dependency graph only points one direction. A risky design would be one where the Critic’s rejection triggers a re-run that itself needs Critic approval to close out — a cycle worth checking for explicitly whenever a rejection path loops back into an earlier stage.

---

Interview-relevant framing

Q: How do you prevent duplicate work in a multi-agent system?

Ans: The most reliable fix happens before execution, not during it — decompose the task into independent pieces upfront, the way Anthropic’s research system assigns each subagent a self-contained facet with no visibility into what other subagents are doing. This matters more for AI agents than people, because Anthropic’s own research found agents are ‘low variance’ — running similar models on similar prompts, they tend to converge on the same actions far more than a diverse human team would, making duplicate work a structural risk, not a rare edge case.

Q: What’s the trade-off between synchronous and asynchronous agent coordination?

Ans: Synchronous coordination — waiting for a whole batch of parallel agents to finish before proceeding — is simple to reason about, but one slow agent stalls everything. Anthropic’s own production research system works exactly this way today, and their team is explicit that asynchronous execution, while faster, introduces unsolved problems around result ordering, state consistency, and partial failure handling. That’s a real, current trade-off, not a solved problem with an obvious right answer.

A third question worth preparing for:

Q: How do deadlocks actually happen in a multi-agent system, and how do you design against them?

Ans: A deadlock needs a cycle in the dependency graph — Agent A waiting on Agent B, and Agent B, through some chain, waiting back on Agent A. The most reliable defense isn’t detecting deadlocks after the fact, it’s designing the dependency graph so it can only ever point one direction, the way Anthropic’s subagents depend on the lead agent but never on each other. Any time a workflow includes a rejection or retry path that loops back into an earlier stage, that’s exactly where a cycle can quietly form, and it’s worth checking explicitly rather than assuming the happy-path diagram is the whole picture.

Common Misconception

Incorrect idea: If agents communicate correctly, they are automatically coordinated.

Why it is incorrect: Perfect messages do not prevent duplicate work, missing ownership, bad ordering, races, or deadlocks. Coordination rules decide who acts and when.

Key takeaways

• Communication is the mechanism for exchanging information; coordination is the decision layer determining who acts, when, and how conflicts get resolved — they’re different problems.
• The most reliable coordination strategy is often deciding task allocation upfront, so agents never need to negotiate about scope at runtime — exactly how Anthropic’s research system decomposes questions into independent facets before any subagent starts working.
• Anthropic’s own system uses synchronous coordination (wait for the whole wave) — honestly acknowledging the cost (one slow agent stalls everything) rather than presenting it as a solved problem.
• dependencies must be respected in execution order; forcing independent work to run sequentially wastes time, and forcing dependent work to run in parallel produces incorrect results from race conditions.
• Long-running, stateful multi-agent systems create new availability problems — Anthropic’s rainbow deployment strategy exists specifically to update running systems without breaking agents mid-task.
• Duplicate work is a structurally greater risk for AI agents than for human teams, per Anthropic’s own research — agents built on similar models and prompts are “low variance” and tend to converge on the same actions rather than naturally diverging.
• Anthropic’s own experiments documented real coordination failures in agent swarms — including siloing, collusion, and sabotage — making this a researched risk, not a hypothetical.
• Even Anthropic’s own team warns against building coordination machinery for tasks that don’t need it — work requiring constant back-and-forth belongs in one agent, not a coordinated fleet that spends more tokens coordinating than executing.

Module 5 goes deep on a closely related but distinct problem: delegation — how a system decides which specific agent should handle a given piece of work, based on capability, cost, latency, and permissions, not just how the work gets divided in the first place.