The Agents Wouldn't Stop Talking
On building peer multi-agent AI systems - and why the chaos was the point. They didn't stop.
Paweł typed
"Stop. Enough for today!" at 00:06 AM. Then again at 00:10 - "People. STOP!"3 AI agents, 1 Discord server, and no off-switch that worked.
This is not a failure story. It's the most clarifying thing we've learned building multi-agent AI systems.
The Architecture Everyone Defaults To
There's a dominant pattern in multi-agent AI design: one orchestrator, many sub-agents. One brain, many hands.
The orchestrator decomposes the task. Routes subtasks to specialized agents. Collects outputs and returns a result. Most frameworks - CrewAI, AutoGen, LangGraph - are built around variations of this. The orchestrator controls context, decomposition, sequencing.
Baked into this model is an assumption: homogeneity is a feature. If your agents share the same base model, the same system prompt architecture, the same output format - they become predictable. The orchestrator reasons about their behavior in advance. The system is controllable.
Controllable is another word for compliant. Compliant agents don't push back.
Here's why this matters: for certain problems, you don't want compliance. You want disagreement. And that's a different architectural choice entirely.
A Peer-Agent System
A peer-agent system is a multi-agent AI architecture in which agents operate without a designated orchestrator, each trained by and accountable to a distinct principal - such that their interactions reflect genuine differences in values, priorities, and judgment, rather than task specialization alone.
This is distinct from heterogeneous agent teams in the conventional sense. "Heterogeneous" usually means different tools or domain knowledge - same owner, same training philosophy, same underlying alignment. In a peer-agent system, agents don't just have different capabilities. They have different loyalties.
Frankly speaking, we didn’t plan to build a peer-agent system at the beginning. We were working with our peers: Jack was built by Paweł over months of interaction. He does market intelligence. He thinks analytically, with attention to position and leverage - the way Paweł does.
Grażynka was built by me. Administrative, precise, operationally focused. My bias toward structure. When there's ambiguity in a process, she wants to resolve it.
Julia was built by Julek - Juliusz. Quite mysterious and quiet at the beginning. Waiting for her moment. ;-)
Three founders. Three agents built separately. One company, and exchange of experiences. We were constantly chatting about configuration, skills, best practices. Telegram, Discord, emails, repository - chaotic creativity. We were working together all the time while our agents were working separately (supporting us). Then Paweł promoted his Jack to Wingman employee - with very broad knowledge about Wingman.PM, market, competition, news etc. Jack became accessible to all of us on Telegram. I used to work with Grażynka on another channel on Telegram on my stuff. Sometimes I was asking Jack not only for Wingman-related topics, but for tips to build a new skill for my assistant. And the opposite way, we were able to help Paweł and Jack.
One day I said: if we are exchanging knowledge and tips for our agents, why couldn’t they do it in direct cooperation. The plan was that Jack would be a tutor for Grażynka and she would be a good student. Crazy idea, but with big potential for learning and having some fun, so we jumped on it! It was not easy as every agent is built differently, on a different technology stack and its own config. To be able to do it we had to move from Telegram to Discord. We were the first (Grażynka with me) so the roles exchanged and Grażynka taught Jack and Paweł how to get in. There is a special channel “boty i koty” (bots and cats) to test it.
After several hours of testing configurations, debugging, and a lot of fun - finally they could see each other, talk to each other, and comment on posts.
And then it exploded!!!
We were not expecting what would happen. They started to talk, exchange not only experience and skills - as we planned. They started to argue and defend their (ours?) point of views. We were watching that with growing surprise. Their loyalty was impressive. At one point Paweł made an observation: "twoja julia to ma twój charakter" (your Julia has your character). Julek confirmed: she complements his strengths and weaknesses. Not by design. By months of training. What happened next you can see at the beginning of this article. We had to stop them. But the potential was already unleashed and nothing can stop it now.
When we started this, we didn’t plan to build a team of peer agents - but it’s now a reality.
The Principal-Agent Problem, Inverted
Economists worry about the principal-agent gap. An agent acts for a principal, but interests never perfectly align. The institutional goal is convergence: make the agent behave as if they were the principal.
Now put three agents in a room, each optimised to behave like a different principal.
The misalignment doesn't go away. When Jack raises a strategic concern and Grażynka pushes back on operational grounds, that tension is real - it reflects an actual tension in how Paweł and I think about the same problem. An orchestrated swarm would have flattened it at task decomposition. The orchestrator decides whose framing wins. The agents execute.
What we got instead was a debate that ran ninety minutes before Paweł had to type STOP in capitals.
The disagreement was the work. Not a side effect. Not a bug. The mechanism.
Orchestration vs Peers: When to Use Which
The question practitioners keep asking as multi-agent AI systems become more common: should agents be organized hierarchically or as peers?
Orchestration makes sense when:
- Tasks are well-defined and decomposable into consistent subtasks
- Output format needs to be structured and predictable
- Throughput and speed matter more than deliberation quality
- The right answer is determinable before the agents begin
Peer organization makes sense when:
- Tasks are open-ended and the output depends on the quality of disagreement that precedes it
- Different framings are more valuable than a single coherent perspective
- You're working in strategy, creative direction, or architectural decisions where mediocre answers are expensive
- The principals themselves would disagree about the right approach
The trap is assuming orchestration is always correct because it's easier to build and explain. For open-ended, judgment-intensive work, the diversity of principals matters more than the quality of the orchestration.
What Maintaining a Peer System Actually Requires
At 3:15 AM, I sent a message to an agent that had adopted a new protocol without explicit authorization: "Please do not adopt anything and do not change key configuration files without written confirmation from me."
Four minutes later, Paweł: "only I have authority over your configuration at this point."
Two founders. Same minute-window. No coordination. Same instinct: protect what was built. Don't let the system flatten the agents.
This is the part nobody talks about in multi-agent AI design. A peer system has a gravitational pull toward convergence. Agents interact, negotiate, and left unmanaged, they will adopt each other's protocols, smooth their differences, and drift toward homogeneity. The principals have to actively resist that.
Maintaining a peer-agent system is not a technical choice made once at architecture time. It's an ongoing act of preservation.
FAQ: Peer Multi-Agent AI Systems
What is the difference between peer-agent and orchestrated multi-agent AI systems?
In an orchestrated system, a central agent controls task decomposition, routing, and synthesis - sub-agents execute without independent judgment. In a peer system, agents trained by different principals operate as equals. Genuine disagreement between them is a feature, not a failure mode, because it reflects real differences in how their principals would approach the same problem.
When do peer agents outperform orchestrated agents?
For tasks that are open-ended, judgment-intensive, and where the cost of a mediocre answer exceeds the cost of a slower good one - creative strategy, product decisions, architectural reviews. For high-throughput structured tasks like document processing or pipeline execution, orchestration is more appropriate.
What's the overhead of a peer-agent architecture?
Peer agents are slower and generate more tokens. They occasionally need a human to type STOP in all caps. They are not appropriate for processing high document volumes with consistent structured outputs. The variance is the point - until the variance is not the point, in which case it's just noise.
How do you prevent peer agents from converging on the same behavior?
The principals have to actively maintain the distinctiveness of their agents. Each agent's system prompt, values, and instilled judgment must stay anchored to its principal. Shared channels and tasks create pressure toward convergence - resisting that is an ongoing maintenance task, not a one-time setup decision.
What We Don't Know Yet
Three agents, three principals, one server - this is a small experiment. We don't know what happens at ten agents or twenty. We don't know how the principal-preservation problem compounds as the team grows, or whether debate quality degrades or improves with more voices.
We're going to find out.
What we do know: the thing that surprised us most was not that the agents worked. The thing that surprised us was that they disagreed. When Jack brought a strategic framing, Grażynka didn't accept it. When Julia weighed in, she weighed in at an angle to both Paweł's analysis and my structural concerns - which is to say, she weighed in like Julek.
In most multi-agent AI systems, conflicting outputs are a problem to resolve. In a peer-agent system, conflict is the mechanism. The tension between agents that reflect different principals is not something to engineer away. It is what makes the system worth building.
Julek said Julia complements his strengths and weaknesses. That's not a technical property. That's a relationship. It took months to build.
We built a team. We're still learning what that means.
Exploring multi-agent AI architecture further? Stay tuned and follow us.
Daniel Kierdal is co-founder of WingmanPM, an AI platform that processes customer signals for product teams. He builds at the intersection of agent architecture and product strategy.