Multi-Agent Coordination Patterns

Goal

Choose a coordination pattern based on task dependencies, authority, and evidence instead of adding agents without a clear reason.

Which tasks can run together?

Suppose a security investigation has four pieces of work:

analyze web log ─┐
                 ├→ check policy → write final report
analyze auth log ┘

The two log analyses do not depend on each other, so making one wait for the other only adds delay. The policy check, however, needs their findings, and the final report should wait for the policy result.

Now the coordination question is concrete: which work can happen independently, which work must wait, and who owns the final decision?

A multi-agent system can express that shape in several ways. The goal is not to add as many agents as possible. More agents create more messages, more state, higher cost, and more ways to fail. Choose a coordination pattern because it matches the task dependencies or keeps authority clear.

Supervisor and pipeline patterns

In a supervisor pattern, one parent breaks down the task, delegates work, checks results, and combines the final answer. This fits systems where authority should stay in one place. The supervisor can also enforce child budgets.

In a pipeline pattern, work moves through specialists in order. For example: extract facts → check policy → draft answer. This works when each step depends on the one before it. Later stages should still validate their inputs so one early error does not spread silently.

Parallel and peer patterns

A parallel specialist pattern sends independent subtasks to several agents at once and then joins the results. This can reduce wait time or gather different evidence. The join rule must say what happens when results disagree. A majority vote can still be wrong if every agent used the same bad source.

A peer-to-peer pattern lets agents coordinate more directly. It can fit truly distributed ownership, but it is harder to audit because authority is spread across more links. Start with a simpler pattern unless decentralization solves a real need.

supervisor: parent → child A
                  → child B
pipeline:   agent A → agent B → agent C
parallel:   parent → {A, B, C} → join

Keep IDs, ownership, and budgets explicit

Every pattern still needs IDs, ownership, and limits. The coordinator should know which child task belongs to which subgoal, who owns it, and when its result is too old to use.

Messages consume budget too. Several agents can keep asking one another for confirmation even when each agent has its own step limit. System-level limits should therefore count child tasks and inter-agent messages.

Multi-agent evaluation looks beyond each agent's local choices. It also checks routing, delegation, handoffs, conflict handling, and the final outcome.

Prefer the smallest structure that works

Choose the smallest coordination structure that matches the task dependencies. Coordination should make responsibility clearer, not create activity for its own sake.

Predict

Three agents can independently analyze separate logs before one parent integrates the findings. Which pattern fits best?

Parallel specialists with an explicit join and evidence-validation ruleA strict pipeline where each log analysis must wait for the previous unrelated oneUnbounded peer-to-peer discussion until all agents agree

Run the Docker-environment Lab preflight

This activity is registered for the Docker-oriented environment used by multi-agent operational work. Start with the deterministic Python preflight so protocol/controller failures remain distinguishable from container or network setup problems.

Run:

python3 labs/notebooks/level-13/l13-09-coordination.py

The Lab turns a small dependency graph into execution waves.

1. Run it unchanged. log_a and log_b should appear in the same first wave, showing that they can run in parallel.
2. In deps, find "log_b": set(). Before editing, predict what the wave structure will become if log_b must wait for log_a.
3. Change only that value to "log_b": {"log_a"}, then rerun.
4. Confirm the first two tasks now occupy separate waves and the schedule becomes a one-step-at-a-time pipeline before policy and report.

Loading lab…

Quick Check

1. When is a supervisor pattern especially useful?

When every child should inherit all parent permissionsWhen one controller retains decomposition and final authorityWhen no component should know which subtask belongs to which goal

2. What is a coordination-specific risk of parallel specialists?

They cannot return artifacts to the coordinatorOne specialist may take longer than anotherTheir results may conflict at the join

3. Why count inter-agent communication in budgets?

Because cross-agent loops can grow despite per-agent limitsBecause every message is a side effectBecause the protocol limits each agent to one child task

0 of 3 questions answered.

Explain it back

Choose a coordination pattern for a security investigation with independent log analysis, one policy check, and one final report. Explain ownership, dependencies, and the join rule.

Key Takeaways

• Choose coordination patterns from dependencies and authority needs.
• Supervisors centralize integration and control.
• Parallel specialists need an explicit join policy.
• System budgets must include child tasks and communication.
• Evaluate routing and handoffs, not only individual agents.

Next Lesson

Next, L13.10 — Shared State and Conflict Resolution addresses races and disagreement when several agents update related work.

References

• Agent2Agent Protocol, v1.0.0 Specification.
• Liu et al., AgentBench.