5.7 Communication Patterns for Multi-Agent Systems

📄← Module index↗ · 📄↑ Master index↗

After this section, you should be able to:

• Explain what communication patterns for multi-agent systems contributes to an agentic system.
• Decide when to use it and when a simpler design is sufficient.
• Implement the pattern as observable, testable components.
• Identify its principal cost, safety, and reliability risks.

Choose linear, hierarchical, deep-hierarchical, or peer communication based on dependency structure and control needs.

Topology determines coordination cost, visibility, fault isolation, and predictability.

The arrows show control and data movement, not necessarily separate models. A deterministic function, one model called multiple times, or several models may implement the boxes. Preserve trace identifiers across the flow.

1. Map information dependencies. Write the input, expected output, owner, and failure condition before implementation.
2. Prefer linear flow for stable sequences. Keep the decision observable in logs or structured state so it can be evaluated.
3. Use a manager hierarchy for coordinated specialists. Apply least privilege and validate assumptions at this boundary.
4. Use deeper hierarchies sparingly. Capture the result and enough metadata to reproduce or diagnose it.
5. Avoid all-to-all unless unpredictability is acceptable. Compare the result with explicit acceptance criteria before continuing.
6. Define message schemas and stop conditions. Route failures to retry, fallback, or human review according to policy.
7. Test deadlocks, loops, and conflicting outputs. Add the observed behavior to the regression suite and operating notes.

• State: Keep messages, tool calls, observations, artifacts, decision reasons, attempt count, token use, latency, and final status in a structured run record.
• Contracts: Define each component with typed inputs, typed outputs, allowed side effects, timeouts, and error categories.
• Controls: Use least-privilege credentials, allowlisted tools, bounded loops, input validation, output validation, and approval gates for consequential actions.
• Observability: Record prompts or prompt versions, model and parameters, tool arguments, tool results, exceptions, timestamps, and cost—subject to privacy rules.
• Evaluation: Test representative, edge, adversarial, and failure-recovery cases. Compare against the simplest viable baseline.

A manager-worker pattern centralizes decisions; peer-to-peer exchange offers flexibility but is harder to control.

INPUT: user goal + constraints
STATE: {run_id, step, observations, budget, status}
DECIDE: next bounded action
VALIDATE: permissions, arguments, and policy
EXECUTE: model call, deterministic code, or tool
OBSERVE: structured result or categorized error
STOP: acceptance criteria pass, budget reached, or human escalation

• The use case justifies this pattern over a simpler one-shot call.
• Inputs, outputs, and success criteria are explicit.
• Tool calls and side effects are validated and permissioned.
• Loops have hard budgets and meaningful stop conditions.
• Failures produce safe retries, fallbacks, or escalation.
• Quality, latency, and cost are measured together.
• Regression tests include at least one failure case.

1. What observable failure would show that this pattern is misapplied?
2. Which part should be deterministic rather than delegated to an LLM?
3. What is the minimum context required at each step?
4. Where should a human approval or escalation gate sit?
5. Which metric would prove that the added complexity is worthwhile?

Implement a minimal version for one narrow task. Save three traces: a successful run, a recoverable failure, and a case that must stop or escalate. Write one regression test for each trace and compare the result with a direct-generation baseline.