Peer Collaboration
Agents communicate directly with each other as equals — without a central orchestrator — exchanging messages, debating perspectives, and building consensus to solve problems collaboratively.
function PeerCollaboration(task, agents, max_rounds):
shared_context = [task]
for round in 1..max_rounds:
responses = []
for agent in agents:
// Each agent sees the full shared context
response = agent.respond(shared_context)
responses.append(response)
shared_context.append(response)
// Check for consensus
if detect_consensus(responses):
break
// Synthesize final output from all contributions
return synthesize(shared_context, agents)
function detect_consensus(responses):
// Compare positions across agents
// Return true if positions have converged
similarity = pairwise_similarity(responses)
return similarity > CONSENSUS_THRESHOLDWhen to Use
- Tasks that benefit from diverse perspectives — code review, analysis, brainstorming
- When adversarial dynamics improve quality — debate, red-teaming, security review
- Creative tasks where emergent, unexpected solutions are valued
- When no single agent has sufficient expertise to solve the problem alone
- Scenarios where resilience matters — no single point of failure
When NOT to Use
- Well-structured workflows with clear sequential steps — use supervisor instead
- Latency-sensitive applications — peer rounds multiply response time
- Budget-constrained scenarios — token usage scales quadratically with agent count
- Tasks requiring deterministic, reproducible outputs
- When a clear authority or decision hierarchy is needed
Decentralized Agent Communication
The Peer Collaboration pattern removes the centralized supervisor and instead lets agents communicate directly with each other in a flat, egalitarian topology. Each agent has its own perspective, expertise, and goals, and they interact through structured message passing to collectively arrive at a solution.
This pattern is inspired by real-world collaboration models: peer code review, academic peer review, parliamentary debate, and brainstorming sessions. In each case, no single participant has authority over the others — quality emerges from the interaction itself.
The architecture consists of:
- Peer Agents: Each agent has a defined role, expertise area, and communication interface. Agents can read messages from other agents and produce their own responses.
- Message Bus / Shared Context: A mechanism for agents to exchange messages. This can be a shared conversation history, a publish-subscribe channel, or a structured message queue.
- Termination Protocol: A mechanism for determining when the conversation should end — consensus detection, vote counting, or a maximum round limit.
Unlike the supervisor pattern, no single agent controls the workflow. This makes the system more resilient (no single point of failure) but harder to predict and debug.
Message Passing Protocols
The design of the message passing protocol critically affects the quality of peer collaboration. Several patterns exist:
Round-robin: Agents take turns in a fixed order. Agent A speaks, then Agent B, then Agent C, then back to A. This is the simplest protocol and prevents any agent from dominating the conversation. It works well for structured debates and review processes. The downside is rigidity — an agent that has nothing to add still takes a turn.
Reactive messaging: Agents respond when they have something relevant to contribute. An agent monitors the shared context and speaks up when it detects content relevant to its expertise. This is more natural but requires a mechanism to prevent simultaneous responses and ensure all agents get heard.
Structured protocols: Define explicit phases for the conversation: proposal, critique, revision, vote. Each agent participates in each phase according to its role. This combines the predictability of round-robin with the focus of reactive messaging.
Broadcast with filtering: All messages go to all agents, but each agent has a filter that determines which messages are relevant to its role. This allows parallel processing — agents can work on different aspects simultaneously and only engage when cross-cutting concerns arise.
The choice of protocol depends on the use case. Code review benefits from structured protocols (propose, review, revise). Brainstorming benefits from reactive messaging. Debate benefits from round-robin with rebuttals.
Consensus and Conflict Resolution
When multiple agents collaborate as peers, they will inevitably disagree. A robust peer collaboration system needs explicit mechanisms for resolving conflicts and reaching consensus:
Majority voting: After a discussion round, each agent votes on the preferred outcome. The majority wins. This is simple but can produce mediocre compromises. It works best for binary decisions (approve/reject, include/exclude).
Weighted voting: Agents' votes are weighted by their expertise relevance to the topic at hand. A security expert's vote carries more weight on security decisions than a UI designer's. Weights can be assigned statically or computed dynamically based on the discussion content.
Convergence detection: The system monitors successive rounds of discussion and detects when agents' positions have converged — when new rounds produce only minor variations rather than substantive changes. This is more sophisticated than voting and works well for iterative refinement tasks.
Escalation: If agents cannot reach consensus after a maximum number of rounds, the disagreement is escalated to a human reviewer or a more capable model that acts as an arbiter. This is a pragmatic fallback that prevents infinite debates.
Synthesis: Rather than choosing one agent's position, an aggregation step synthesizes the best elements from all perspectives. A designated synthesis agent (or a final LLM call) reads all contributions and produces a unified output that incorporates the strongest arguments from each participant.
Use Cases and Applications
Peer collaboration excels in scenarios where diverse perspectives improve outcomes:
Code review: An author agent writes code, a reviewer agent critiques it for bugs and style issues, a security agent checks for vulnerabilities, and a testing agent suggests test cases. The agents exchange feedback in rounds until the code meets all quality criteria. This mirrors real engineering workflows and can catch issues that a single agent would miss.
Creative writing and brainstorming: Multiple agents with different creative styles or domain knowledge contribute ideas to a shared canvas. A "divergent thinking" agent generates wild ideas, a "convergent thinking" agent evaluates feasibility, and a "synthesis" agent combines the best elements. The lack of a supervisor allows unexpected connections to emerge.
Debate and analysis: Agents argue different sides of a question — bull vs. bear for investment analysis, prosecution vs. defense for legal reasoning, or different theoretical frameworks for research. The adversarial dynamic forces each agent to strengthen its arguments and address counterpoints, producing more rigorous analysis.
Multi-perspective research: When analyzing a complex topic, agents with different expertise (economics, sociology, technology, policy) each contribute their perspective. The peer structure ensures no single viewpoint dominates and cross-disciplinary insights emerge naturally.
Challenges and Design Considerations
Peer collaboration is the most powerful but also the most challenging multi-agent pattern to implement well:
- Conversation drift: Without a supervisor to keep agents on track, peer conversations can wander off topic. Mitigation: Include a focused objective in each agent's prompt and implement topic-relevance scoring to detect drift.
- Echo chambers: Agents with similar training may reinforce each other's biases rather than providing genuinely diverse perspectives. Mitigation: Explicitly configure agents with contrarian or adversarial roles, and use different model providers or temperatures for different agents.
- Token explosion: Every message is consumed by every agent, leading to quadratic growth in token usage. With N agents and R rounds, total tokens scale as O(N x R x context_size). Mitigation: Summarize earlier rounds, limit per-message length, and use selective attention (agents only read messages relevant to their role).
- Non-determinism: Outcomes vary significantly between runs because the conversation dynamics are emergent. Mitigation: Use lower temperatures, structured protocols, and convergence detection to stabilize outputs. Accept that some variability is inherent and desirable in creative tasks.
- Deadlocks: Agents may reach a stalemate where no one changes their position. Mitigation: Set maximum round limits and implement escalation protocols.