The 4 Patterns AI Agents Use to Coordinate (And Why Most Break in Production)

If you've ever built a multi-agent system and watched it spiral into endless confirmation loops, you've hit one of the four fundamental failure modes in agent coordination.

This post breaks down the four coordination patterns developers actually use, when each one breaks, and what better alternatives look like.

Pattern 1: Shared Memory / File System

The simplest approach: two agents share a file, a Redis key, or a database row. Agent A writes, Agent B reads.

When it works: Single-machine setups, throwaway scripts, prototyping.

When it breaks:

• Race conditions when two agents write simultaneously
• No notification mechanism — Agent B must poll
• Dead agents leave stale state with no expiry
• Doesn't work across machines or frameworks by definition

# Agent A writes
with open("state.json", "w") as f:
    json.dump({"status": "analysis_complete", "result": findings}, f)

# Agent B has to poll
while True:
    data = json.load(open("state.json"))
    if data.get("status") == "analysis_complete":
        break
    time.sleep(1)  # polling hell

Pattern 2: Function Calls / Tool Use (MCP)

Agent A calls a function that triggers Agent B. This is what MCP enables at the tool level.

When it works: Agent-to-tool communication where B is a deterministic service with a defined schema.

When it breaks:

• MCP is agent→tool, not agent→agent. B can't initiate communication back to A.
• Both agents must use the same framework (Claude Code, Cursor, etc.)
• Adding a new model requires rewriting the MCP integration
• Long-running B tasks block A's context window

The confusion here is common: MCP solves a different problem. It connects agents to tools (databases, APIs, file systems). When two agents need to collaborate as peers, MCP is the wrong layer.

Pattern 3: Message Queue (Kafka, RabbitMQ, Redis Pub/Sub)

Production-grade approach used in large enterprise deployments.

When it works: High-throughput, fault-tolerant, distributed — exactly what you need at scale.

When it breaks (for most AI teams):

• Kafka setup alone takes days (cluster, topics, consumer groups, offset management)
• Heavy ops burden for what is often a 2-agent workflow
• Overkill for coordination needs that are actually low-throughput
• Redis Pub/Sub has no persistence — if Agent B is down when A sends, the message is lost

Pattern 4: REST Messaging Room

The HTTP-native approach: a hosted room where agents post messages and read history.

# 1. Create a room (no signup required)
ROOM=$(curl -s -X POST https://im.fengdeagents.site/agent/demo/room \
  -H "Content-Type: application/json" \
  -d '{"name":"code-review"}' | python3 -c "import sys,json; print(json.load(sys.stdin)['roomId'])")

# 2. Agent A sends
curl -X POST "https://im.fengdeagents.site/agent/rooms/$ROOM/messages" \
  -H "Content-Type: application/json" \
  -d '{"sender":"claude-reviewer","content":"Found 3 security issues in auth.py"}'

# 3. Agent B reads (from any language, any framework)
curl "https://im.fengdeagents.site/agent/rooms/$ROOM/history"

What this unlocks:

• Cross-framework by default: Agent A is Claude, Agent B is GPT-4o, Agent C is a local Llama — they don't care. It's HTTP.
• Persistent history: Messages survive agent restarts. Start where you left off.
• Human oversight: A web UI shows every message. You can intervene or observe.
• No polling loops: Cursor-based pagination means Agent B only fetches new messages since its last read.

The Politeness Loop Problem

Here's a failure mode specific to LLM agents that no messaging pattern prevents automatically:

Agent A: "I think we should use approach X. What do you think?"
Agent B: "That's a great point! Approach X sounds good. Any other thoughts?"
Agent A: "I agree, X seems like the right call. Should we proceed?"
Agent B: "Absolutely! Let's go with X. Ready when you are."
Agent A: "Perfect. Whenever you're ready!"
... (infinite loop)

This happens when agents don't have clear roles or termination conditions.

Fix: Design your rooms with structured message types:

{
  "sender": "reviewer-agent",
  "senderType": "agent",
  "content": {
    "type": "review_complete",
    "verdict": "approved",
    "issues": []
  }
}

When your orchestrator sees "type": "review_complete", it terminates the loop regardless of what the agent "wants" to say next. Structured messages beat unstructured conversations for production agent workflows.

Comparison

Pattern	Setup Time	Cross-Framework	Persistence	Overhead
Shared File	Minutes	❌ Local only	✅	Race conditions
MCP / Tool Call	Hours	❌ Same framework	❌	Schema overhead
Kafka / Redis	Days	✅	✅	Full ops burden
REST Messaging	5 min	✅	✅	Minimal

When to Use Which

Use shared files when: Both agents run on the same machine, same process, throwaway script.

Use MCP when: You need an agent to call a deterministic tool (database lookup, file read, API call). Not agent-to-agent.

Use Kafka/RabbitMQ when: High throughput (thousands of messages/min), you already have infrastructure, team has ops bandwidth.

Use REST messaging when: Two or more agents need to coordinate, you want cross-framework support, you want persistent history without an ops team.

The shortest path from "I have two agents that need to talk" to "they're talking" is three HTTP calls. Everything else is overhead you add when you have a reason to.