AI Agents Fighting Each Other: The Pitfalls of Multi-Agent Collaboration and How to Fix Them

Two AI agents were given a simple task: research a topic and write a summary. The result? The first agent searched for company information, and the second agent also searched for the same information. Then the first agent decided the summary was wrong and rewrote it; the second agent disagreed and changed it back. After 27 API calls, you get a $3 bill and a summary worse than free ChatGPT.

This is multi-agent collaboration—the truth those flashy demos never tell you.

The Hidden Pain Point of Multi-Agent Systems

Multi-agent systems have a rarely mentioned secret: two agents collaborating is often worse than one agent working alone.

The problem isn't that individual agents are incompetent, but that no one tells them how to avoid stepping on each other's toes. Imagine a college group project: five smart people, zero coordination, and seventeen conflicting edits on a Google Doc one minute before the deadline. Multi-agent AI systems fail in exactly the same way: Agent A fetches data, Agent B fetches the same data (because no one told it A already did); Agent A formats the response, Agent B reformats it differently. They loop, duplicate, contradict—your token bill soars while quality drops.

Multi-Agent System refers to an architecture composed of multiple autonomous AI agents that collaborate to complete tasks through message passing or shared state. Each agent typically has its own system prompt, toolset, and context window. Compared to a single agent, the selling point of multi-agent is "specialized division of labor"—a researcher handles retrieval, a writer handles generation. But the cost is coordination overhead: agents have no shared memory and cannot perceive each other's actions, making duplicate work, write conflicts, and infinite loops extremely likely. Academically, such failures are often classified as "coordination failure," where token cost grows superlinearly with the number of agents, while output quality may decrease due to mutual overwriting.

Why "Just Add Another Agent" Is a Trap

"Need research and writing? Add a researcher agent and a writer agent!" This pitch is tempting, but here's what actually happens without coordination:

# What you expect
researcher_result = researcher.run("Find Acme's Q3 revenue")
writer_result = writer.run(f"Summarize this: {researcher_result}")

# What actually happens
researcher_result = researcher.run("Find Acme's Q3 revenue")
# The writer ignores researcher_result and searches again itself
# The researcher sees the writer's draft, thinks it's wrong, and re-researches
# Loop until max iterations or wallet depletion

The solution isn't to remove agents, but to add something "dumber" than AI: contracts.

Contracts Beat Intelligence

The counterintuitive truth is: the best multi-agent systems aren't those with the smartest agents, but those with the strictest handoff rules.

A minimal coordination contract can prevent 80% of multi-agent chaos:

class AgentContract:
    def __init__(self):
        self.completed_tasks = {}
        self.ownership = {}

    def claim_task(self, agent_id: str, task: str) -> bool:
        """Only one agent can own a task; duplicates forbidden."""
        if task in self.ownership:
            return False  # Already claimed
        self.ownership[task] = agent_id
        return True

    def submit_result(self, agent_id: str, task: str, result: str):
        """Once submitted, the task is complete; no other agent may rewrite it."""
        if self.ownership.get(task) != agent_id:
            raise ValueError(f"{agent_id} does not own task {task}")
        self.completed_tasks[task] = result
        return True

    def get_result(self, task: str) -> str:
        """Read-only access to completed work."""
        return self.completed_tasks.get(task, None)

No machine learning, no embeddings, no vector database. Just a dictionary declaring "this task belongs to this agent, and once done it is done."

Contract-based Coordination borrows the ideas of "lease" and "ownership" from distributed systems: any shared resource can have only one writer at any moment, and a lease must be acquired before writing. In AI agent scenarios, this means using a lightweight state store (dictionary, Redis, or database table) to record the "task→agent" mapping; agents atomically "claim" a task before executing, then mark it immutable upon completion. Because it doesn't rely on semantic understanding or embedding similarity, the contract mechanism has near-zero latency, zero hallucination, and fully predictable behavior—which is exactly why it's more reliable than "letting agents negotiate among themselves."

Three Rules to Solve Multi-Agent Chaos

After observing dozens of multi-agent configurations, here are the rules that actually work:

Rule 1: Claim first, then work. Every agent must call claim_task() before starting. If already claimed by another, skip. Zero duplication.

Rule 2: One writer, many readers. The agent that claims a task is the only one allowed to write the result; others get read-only access via get_result(). No conflicting edits.

Rule 3: Disagreements go forward, not backward. If Agent B believes Agent A's result is wrong, it doesn't rewrite directly; instead, it creates a new task—"revision_of_research"—claims it, and writes an improved version. The audit trail stays clean, and you can actually debug what happened.

contract = AgentContract()


**Read-only Access** is a key means of preventing conflicting edits. In multi-agent systems, if multiple agents can write to the same result, you get "last writer wins" overwriting, and it's hard to trace who changed what. By returning immutable copies via `get_result()`, other agents can only read but not modify; any improvement must be submitted as a new task. This is similar to Git's branching model: the main branch is read-only, modifications go through new branches, preserving a complete audit trail and turning debugging from "guess which agent broke it" into "check the task history."
# Researcher claims and completes research
contract.claim_task("researcher", "find_q3_revenue")
data = researcher.run("Find Acme's Q3 revenue")
contract.submit_result("researcher", "find_q3_revenue", data)

# Writer reads research result only, claims writing task
research = contract.get_result("find_q3_revenue")
contract.claim_task("writer", "write_summary")
summary = writer.run(f"Summarize: {research}")
contract.submit_result("writer", "write_summary", summary)

# If the writer disagrees with the research, it submits a new task
contract.claim_task("writer", "research_revision_request")
contract.submit_result("writer", "research_revision_request",
    "Q3 revenue data seems outdated—please re-verify")

The Uncomfortable Truth

Most teams don't need multi-agent systems at all. A single agent with well-crafted prompts and a full toolset will every time beat two agents stuck in a looping argument in 90% of use cases.

Multi-agent coordination is only worth it when you truly have tasks that require different system prompts, different toolsets, or different trust boundaries. If your "researcher" and "writer" can be the same agent making two different function calls, you don't have a multi-agent problem—you have a single agent with a task list.

Agents themselves aren't the hard part; coordination is. And the best coordination doesn't look like AI at all—it looks like boring software engineering.

Have you ever had a multi-agent system in production that actually stayed coordinated? Which handoff pattern saved you? Share your setup in the comments—I'm especially curious about the number of agents, and whether contracts or message queues worked better.

Trust Boundary refers to the division of different permissions and information access scopes granted to different components in a system. In multi-agent architectures, trust boundaries are one of the core criteria for determining whether multi-agent is truly needed: if a type of task involves sensitive data, requires independent auditing, or must use a restricted toolset, then isolating it into a separate agent is reasonable; conversely, if all agents share the same tools and permissions, multi-agent only adds coordination cost without isolation benefits. In practice, teams often mistakenly treat "different prompts" as a reason for multi-agent, but a single agent can achieve the same effect by switching prompts via function calls.

One-line Summary

Multi-agent collaboration often leads to duplication and conflict due to lack of coordination; strict contracts are more effective than smarter agents.

Paragraph Summary

The article points out a hidden pain point of multi-agent systems: two AI agents collaborating is often worse than a single agent working alone, because lack of coordination leads to duplicate searches, conflicting edits, and infinite loops, ultimately driving up token bills while degrading quality. The author argues the solution is not smarter agents but strict handoff contracts—through task claiming, read-only access, and the rule "disagreements create new tasks forward," a simple dictionary can prevent 80% of chaos. The article ends with an uncomfortable truth: in 90% of scenarios, a single agent with good tools suffices; multi-agent is only suitable for tasks requiring different prompts, toolsets, or trust boundaries, and the best coordination looks more like boring software engineering.