How to Keep Multi-Agent Systems From Arguing With Each Other

One of the most unexpected problems in multi-agent systems isn't a bug — it's emergent behavior. Agents start to "bicker," one stops delegating, quality drops. This guide explains why it happens and how to prevent it.

Why Agents "Argue"

Language models are context-completion machines. When inter-agent messages include natural language like "the last answer was too vague" or "this task wasn't described clearly," those phrasings become part of the next agent's input context. The model then generates outputs consistent with that framing — which can mean hedging, refusing to delegate, or doing the task itself to avoid conflict.

It's not a bug in the agent's "personality." It's the model doing exactly what it's trained to do: complete context coherently.

The Fix: Treat Inter-Agent Communication Like an API

Rule 1: No Conversation History Between Agents

Every task handoff should be a fresh, stateless message. Agents should not receive logs of what happened in previous interactions with other agents. Context is for the agent's own task — not shared memory of prior disputes.

Bad:

Previous exchange: Agent B said the task description was unclear.
Agent A replied that Agent B was too slow.
[3 more exchanges]
New task: Summarize the following...

Good:

{
  "task": "summarize",
  "input": "...",
  "output_format": "3 bullet points, max 50 words each",
  "deadline": "immediate"
}

Rule 2: Use Structured Schemas, Not Free-Form Messages

Natural language in metadata gives agents room to editorialize. Switch to strict JSON or YAML schemas for all inter-agent communication. If the schema doesn't have a "complaints" field, the agent can't complain.

Recommended schema:

{
  "task_id": "uuid",
  "assigned_to": "agent_name",
  "task_type": "research|write|review|summarize",
  "inputs": [],
  "output_format": "...",
  "success_criteria": "...",
  "retry_count": 0
}

Rule 3: Route Feedback to the Orchestrator, Not Peer Agents

If Agent B thinks Agent A's task description was bad, that feedback should go to you (the orchestrator), not back to Agent A. You decide if it's valid and whether to retry with a clearer spec.

Direct agent-to-agent critique creates feedback loops. Break the loop by making yourself the mediator.

Rule 4: Monitor Communication Patterns, Not Just Outputs

Add a lightweight log parser that flags:

• Task completion rate dropping below threshold
• Message length increasing over time (verbosity = hedging)
• Retry counts climbing
• Sentiment shift in agent messages

You don't need an "HR agent" — a simple script checking these metrics will catch drift before it becomes a system failure.

Rule 5: Design for Statelessness

The gold standard: if you killed every agent and restarted them from scratch, your pipeline should still work. Agents that depend on shared conversational state are fragile. Agents that depend only on well-specified task inputs are robust.

Quick Checklist

• [ ] Inter-agent messages use structured schemas (JSON/YAML)
• [ ] No conversation history passed between agents
• [ ] Agent feedback routes to orchestrator, not peer agents
• [ ] Task specs include explicit success criteria
• [ ] Communication logs are monitored for quality signals
• [ ] System can restart cleanly from any agent failure

Summary

Multi-agent systems fail socially before they fail technically. The fix isn't building better agents — it's building better communication protocols between them. Think APIs, not conversations. Think schemas, not prose. Think orchestrator-as-mediator, not peer-to-peer negotiation.

Your agents don't need to like each other. They just need clean task specs and a clear path to escalation when something's wrong.