“Multi-agent” sounds like digital colleagues chatting at a whiteboard. In practice, it is multiple ReAct loops sharing a message bus — and the hard part is not the chat, it is the contracts: who owns what memory, who routes to whom, how conflicts resolve, and what the shared state looks like. Huang et al. (2025) demonstrate this cleanly with Intrinsic Memory Agents: each agent maintains its own structured memory template (role, goals, facts, procedures), updated per turn, while a shared conversation space carries cross-agent coordination. They beat global-memory baselines on ALFWorld because separation of concerns works for agents too.

The Coordination Stack

Layer	Question	Pattern That Works
Identity & Role	Who am I? What do I own?	Structured memory template per agent (role, goals, facts, skills) — updated per turn
Routing	Who handles this?	Explicit router (LLM or rule-based) → delegate to specialist; or broadcast + self-selection
Shared State	What do we all see?	Whiteboard / blackboard: append-only log of decisions, artifacts, open questions
Memory Isolation	What is private vs shared?	Private: episodic (my attempts), procedural (my skills). Shared: facts, decisions, user preferences
Conflict Resolution	We disagree — now what?	Hierarchical (lead agent decides), voting, or “escalate to human” tool
Termination	When are we done?	Explicit Finish action with structured output; or timeout / budget exhausted

Memory: Private by Default, Shared by Contract

Huang et al. (2025) show that agent-specific memory preserves role consistency. A planner remembers plans; a coder remembers code patterns; a reviewer remembers checklist items. If they all share one undifferentiated memory, the planner’s “try X” pollutes the coder’s context with irrelevant intent.

Rule: Each agent gets its own memory namespace. Cross-agent reads require explicit projection (e.g., “summarize my last 3 attempts for the reviewer”). The shared whiteboard holds only decisions, artifacts, and open questions — not raw history.

Routing: Explicit > Emergent

Two patterns that work in production:

1. Lead Agent + Specialists (Hierarchical)

User → Lead (plans, delegates, aggregates) → Specialist A / B / C
                    ↑                         ↓
              aggregates ←────────────────────┘

Lead owns the task decomposition, budget, and final answer. Specialists are stateless workers with focused toolsets. Used by: HuggingGPT, MetaGPT, ChatDev.

2. Blackboard / Pub-Sub (Peer-to-Peer)

Agents subscribe to topics (e.g., "code-review", "design-decision")
Publish: structured messages (type, payload, provenance, TTL)
Consume: filter by relevance to own role

No central lead. Agents self-organize around the blackboard. Used by: AutoGen (group chat), LangGraph (state graph).

Hybrid (recommended): Lead for task-level orchestration; blackboard for domain-level collaboration (e.g., frontend + backend + devops agents discussing API contract).

Toolsets: Disjoint by Design

Give each agent a minimal, disjoint toolset. Overlap causes confusion (who calls write_file?). If two agents need the same tool, wrap it in a service with an API — the tool becomes a shared resource, not a personal capability.

Agent	Tools
Planner	think, delegate, read_plan, update_plan
Researcher	web_search, web_extract, save_finding
Coder	read_file, write_file, patch, run_test
Reviewer	read_file, run_lint, run_test, post_review
DevOps	deploy, logs, rollback, metrics

The Contract Artifacts You Must Define

Before spawning a multi-agent system, write these down (machine-readable, versioned):

1. Agent Spec — role, goals, toolset, memory schema, input/output formats
2. Message Schema — type, payload, provenance, TTL, required ack
3. Routing Policy — lead vs broadcast, escalation rules, timeout handling
4. Memory Contract — private namespaces, shared whiteboard schema, projection APIs
5. Termination Criteria — Finish payload schema, budget limits, human escalation trigger

Failure Modes (All Preventable)

Failure	Cause	Fix
Infinite delegation loop	No termination check in lead	Max delegation depth; budget counter
Memory bleed	Agents read each other’s raw history	Enforce projection APIs; private by default
Tool conflict	Two agents write same file	Disjoint toolsets; file-lock service
Context explosion	Full history broadcast to all	Summarize + project; each agent sees only relevant slice
Silent disagreement	No explicit conflict resolution	Mandatory “disagree” message type → escalate

What the Research Says

• Intrinsic Memory Agents Huang et al. (2025): role-aligned memory + shared conversation space → SOTA on ALFWorld, higher consistency than global memory.
• G-Memory Xu et al. (2025): hierarchical memory for multi-agent — global + per-agent, with consolidation.
• MIRIX Xu et al. (2026): granular taxonomy (Core, Episodic, Semantic, Procedural, Resource, Knowledge Vault) — per-agent instances + shared Knowledge Vault.
• Tool-to-Agent Retrieval Xu et al. (2026): bipartite graph (tools ↔ parent agents) for reuse across agent fleet.

The Honest Takeaway

Multi-agent is not free intelligence. It is explicit coordination overhead that pays off when:

• Task decomposes cleanly into specialized subtasks (plan → research → code → review → deploy)
• Subtasks need different toolsets, memory schemas, or evaluation criteria
• You need auditability (who decided what, based on what)
• You want to swap/replace specialists without rewriting the whole system

If your task is “answer this question” → single agent. If your task is “build this feature” → multi-agent with lead + specialists + blackboard.

The host builds the protocol. The agents follow it. The intelligence is in the contract design.