Three Coordination Patterns for Multi-Agent Collaboration and Three Rules to Prevent Infinite Loops

Multi-agent systems are moving from experimentation to production, but how to make multiple AI agents collaborate efficiently and avoid falling into infinite loops remains a core challenge for developers. Recently, a practitioner in the Reddit community shared three coordination patterns their team developed for multi-agent collaboration, along with three rules to stop agents from looping, sparking widespread discussion. Based on that sharing and combined with common practices in the multi-agent field, this article takes a deep dive into the logic behind these patterns and rules.

Why Does Multi-Agent Collaboration Need Coordination Patterns?

A single agent can complete tasks independently, but when task complexity rises and multiple agents need to divide the work, coordination becomes the bottleneck. Without clear coordination patterns, agents easily duplicate work, fall out of sync, or even get stuck in infinite loops—one agent waits for another's feedback while the latter waits for the former's output, ultimately exhausting resources or stalling the task. The author of the original Reddit post noted that these pain points prompted them to systematically design coordination patterns and establish hard rules to prevent loops.

A multi-agent system (MAS) is a system composed of multiple autonomous agents (usually based on large language models) that complete complex tasks difficult for a single agent through communication and collaboration. Compared with single-agent systems, the core advantage of MAS lies in division of labor and specialization: different agents can play roles such as researcher, writer, and reviewer, each leveraging its strengths. However, this also introduces coordination overhead—agents need to exchange information, align goals, and resolve conflicts, and these interactions themselves consume computational resources (such as tokens). When coordination mechanisms are poorly designed, the system may fall into livelock or deadlock, manifesting as agents repeatedly exchanging information without substantive progress. Therefore, coordination patterns are essentially about defining control flow and communication protocols for multi-agent interactions to balance flexibility and efficiency.

Three Coordination Patterns

Pattern 1: Orchestrator Pattern

A primary agent (orchestrator) is responsible for decomposing tasks, assigning subtasks to worker agents, and aggregating results. This pattern has a clear structure and suits scenarios with well-defined task boundaries and simple dependencies. Its advantage is centralized control flow, which makes monitoring and debugging easier; its disadvantage is that the central node can easily become a bottleneck, and the orchestrator's decision quality directly affects overall performance. The original post mentioned that their early version adopted this pattern, but when tasks changed dynamically, the orchestrator's frequent replanning led to decreased efficiency.

Pattern 2: Peer-to-Peer Negotiation

Agents communicate directly, allocating tasks and resolving conflicts through negotiation. This pattern is more flexible and suits open-ended, exploratory tasks such as multi-agent debate or collaborative writing. But the negotiation process itself may consume a large number of tokens, and without a global perspective it easily falls into local optima. The original author emphasized that peer-to-peer negotiation requires explicit termination conditions; otherwise agents may repeatedly exchange opinions without converging.

Peer-to-peer negotiation draws on the idea of point-to-point communication in distributed systems: there is no central scheduler among agents, and they interact directly through message passing. This pattern is common in multi-agent debate scenarios: multiple agents each propose viewpoints and critique one another, ultimately converging through voting or consensus mechanisms. Its advantage lies in the robustness and diversity of viewpoints brought by decentralization, but its disadvantages are also obvious—communication costs grow quadratically with the number of agents, and without a global perspective it easily falls into local optima or repetitive discussion. In practical implementations, peer-to-peer negotiation usually requires consensus protocols (such as majority voting or confidence weighting) and termination conditions (such as maximum rounds or viewpoint similarity thresholds); otherwise the system may fail to converge.

Pattern 3: Pipeline Relay

Tasks are split by stage, and agents process them in sequence, each passing its output to the next. This pattern suits linear processes such as a "research–write–review" pipeline. It is simple to implement but has poor fault tolerance—an error in one stage affects all subsequent stages. The original post mentioned that they added checkpoints to the pipeline, triggering rollback when an agent's output does not meet expectations rather than blindly continuing.

Three Rules to Prevent Loops

Patterns alone cannot eliminate loops. The original author summarized three hard rules that effectively stopped agents from falling into infinite loops.

Rule 1: Explicit Maximum Round Limit

Set a maximum number of interaction rounds for each collaboration session (for example, 10 rounds). Once the limit is reached, forcibly terminate and output the current best result. This rule seems simple but prevents the vast majority of infinite loops. The original author said that they did not set limits early on, and as a result a single task consumed several hours and a large number of API calls while still producing no output.

Rule 2: State Convergence Detection

Monitor the dialogue state among agents. If two consecutive rounds produce no new valid information (for example, repeating the same viewpoints or output with no change), judge it as convergence stagnation and trigger termination or human intervention. This requires designing state hashing or summarization mechanisms for agents so they can be compared quickly. The original post mentioned that they detected stagnation by comparing the similarity of message embeddings, with notable results.

The core idea of state convergence detection is to determine whether a multi-agent dialogue has entered a "stagnant" state. Common implementations include: comparing text similarity of messages across consecutive rounds (such as using edit distance or Jaccard similarity), computing cosine similarity of message embedding vectors, or maintaining a hash digest of the dialogue state. When similarity exceeds a preset threshold, the system judges it as convergence stagnation and triggers termination or handover to a human. This mechanism draws on the concept of convergence detection in distributed systems, but the challenge in multi-agent scenarios is semantic equivalence rather than literal repetition—agents may express the same viewpoint in different wording. Therefore, embedding-based semantic similarity is more reliable than literal comparison. The original author adopted message embedding similarity precisely to capture this kind of semantic-level stagnation.

Rule 3: Strict Boundaries of Roles and Responsibilities

Each agent must have a clear role definition and scope of responsibility to avoid meaningless buck-passing caused by overlapping functions. For example, a review agent is only responsible for assessing quality and does not participate in content generation; a generation agent should not overstep to make final decisions. The original author pointed out that ambiguous responsibilities are a common cause of loops—agents wait for each other to decide while no one actually acts.

Practical Recommendations and Reflections

These three patterns and three rules are not mutually exclusive; in practice, systems often use them in combination. For example, under orchestrator-based scheduling, worker agents may use pipeline relay among themselves; peer-to-peer negotiation requires stricter state convergence detection. Several developers in the Reddit community also added other anti-loop strategies in the discussion, such as introducing external monitors, setting timeout mechanisms, and using finite state machines.

You may not have noticed that the complexity of multi-agent collaboration comes not only from technology but also from task design. The original author admitted that many loop problems stem from vague task descriptions, which lead agents to understand goals inconsistently. Therefore, before applying coordination patterns and rules, clearly defining task goals and success criteria is equally important.

As multi-agent frameworks (such as AutoGen and CrewAI) mature, coordination patterns are gradually being abstracted into built-in framework features. But understanding the principles behind these patterns still helps developers make reasonable choices based on their scenarios and avoid blind application.

One-line Summary

Three coordination patterns and three anti-loop rules for multi-agent collaboration, plus the importance of task design.

Paragraph Summary

Based on a practitioner's sharing in the Reddit community, this article systematically analyzes three coordination patterns in multi-agent collaboration—orchestrator-based scheduling, peer-to-peer negotiation, and pipeline relay—along with three anti-loop rules: explicit maximum round limits, state convergence detection, and strict boundaries of roles and responsibilities. The article points out that each pattern has its applicable scenarios and limitations, and real systems often combine them. Anti-loop rules can effectively stop agents from falling into infinite loops, but the root cause often lies in vague task descriptions and unclear responsibilities. Therefore, clearly defining task goals and success criteria is as important as coordination patterns. As frameworks such as AutoGen and CrewAI mature, coordination patterns are being abstracted into built-in features, but understanding their principles still helps developers make sound choices.