Flat Beats Hierarchy: Peer-to-Peer Agents and the Information Lost in Orchestrator Setups

Most multi-agent systems shipping today share a topology so familiar that nobody questions it. A parent agent decomposes the task. Sub-agents execute the pieces. Results bubble up. The parent assembles the answer. This is the orchestrator-worker pattern, and it has been the default since the first published harness designs.

The pattern is borrowed wholesale from corporate hierarchies. It inherits the same failure mode. In any hierarchy, the most accurate information about what is actually happening lives at the worker level. Hierarchies then bury that information under summarization, translation, and the parent’s preexisting model of the problem. By the time a finding reaches the decision point, it has been compressed into whatever shape fits the parent’s expectations.

IndyDevDan’s Pi to Pi demo, released this week, shows the alternative. It runs on a Unix socket and a Bun server. It exposes four tools: list agents, send command, send prompt, await response. There is no orchestrator role. Every agent can ping every other agent. The repo is public. It is short. You can read it.

What the demo proves is not that peer-to-peer is more elegant. It is that peer-to-peer changes which information reaches the decision.

Demo 1: The Production Agent Sees Things the Dev Agent Cannot

The first demo runs two agents on different machines. A production agent on a Mac Mini has access to live data. A dev agent on a MacBook Pro has access to the codebase and the staging environment. They are reproducing a Pro-tier user lockout bug.

In an orchestrator-worker setup, the dev agent would ask the parent for the production state. The parent would ask the production agent. The production agent would return whatever the parent asked for, in whatever shape the parent expected. PII would either flow through unredacted, or the parent would need to know enough about the production schema to ask the right redacted questions.

In Pi-to-Pi, the dev agent pings the production agent directly. The production agent enforces PII redaction at its own boundary. The dev agent never sees raw production data, but it sees the production agent’s own description of the bug state, in the production agent’s own terms. The bug surfaced in minutes.

The architectural property here is worth naming. The boundary of trust is the agent itself, not a control plane between agents. The production agent is the redactor because the production agent is the one that knows what redaction means in its context. A central orchestrator that tries to enforce redaction across heterogeneous data domains has to know all those domains. The peer model lets each agent enforce its own boundary.

Demo 2: Ten Corrections That Would Have Shipped Silently

The second demo is the one that should change how engineering teams think about agent context windows.

Two agents work in parallel. One holds the full E2B documentation in context. The other holds the full exe.dev documentation in context. Their job is to build a feature-parity skill for a new sandbox provider, using the existing E2B skill as the template.

The peer-to-peer exchange runs ten messages. In those ten messages, the exe.dev agent corrects the E2B agent ten times. Ten factual errors that the originating agent would have baked into the new skill silently. The correction loop only fired because there was a second agent with the authority and the context to push back. Not a worker reporting findings up a chain. A peer disagreeing with a peer.

The information that mattered most lived in the second context window. A hierarchical setup with a single planner agent at the top would not have surfaced any of those ten corrections. The planner would have written the skill from a summary of the docs, not from the docs themselves. The factual errors would have lived in the summary, not in the planner’s awareness.

Two Million Tokens, Two Windows, One Better Result

The other quietly important finding from the second demo: total context budget across two agents was roughly two million tokens. The same budget in a single agent would have produced a worse result. Not because of the model’s raw capacity, but because attention degrades as context grows. Two focused windows of one million tokens each outperform one diluted window of two million.

This is the operational case for peer-to-peer. Specialization of context is the actual asset. The four-tool A2A protocol is the mechanism. The topology is what lets specialized contexts negotiate directly instead of forcing their findings through a translation layer.

Anthropic’s own multi-agent research system, published in 2025, leaned hierarchical. Their March 2026 publication of the long-running app harness used a strict planner-generator-evaluator chain. By May 2026, their AI Engineer Conference talk reported simplifying that hierarchy. Fewer roles. More peer behavior emerging at the model level. The vendor that arguably invented the modern orchestrator pattern is, on stage, recommending less of it.

The Governance Implications Are Not What You Expect

Flat topology is not a free win. It has consequences your platform team has to plan for.

Boundary enforcement moves to the agent. In hierarchical setups, the orchestrator is a natural choke point for policy. Want to enforce data residency? Put the rule in the orchestrator. Want to redact PII? Same place. In peer-to-peer, every agent that owns a sensitive domain has to enforce its own boundary. This is harder to design and easier to scale. The production agent in Demo 1 is the right place to redact production data. The orchestrator never was.

Audit shifts from a single trace to a graph. A hierarchical run produces a linear audit log: parent called child, child returned, parent called next child. A peer-to-peer run produces a directed graph. Your observability stack has to handle that. If you cannot reconstruct who told whom what, and in what order, you cannot debug, and you cannot satisfy a compliance review.

Loop detection becomes the platform’s problem. Two peers can ping each other indefinitely. Hierarchies have a natural termination signal: the root agent returns. Peer-to-peer needs explicit budgets, deadlines, and cycle detection. Pi-to-Pi’s await_response is synchronous; it forces serialization but does not bound the conversation length. A production deployment has to add those bounds.

The skill of writing for peers replaces the skill of writing for orchestrators. Worker agents are designed to satisfy a parent. Peer agents have to challenge each other and accept being challenged. Prompt engineering for peer behavior is a different discipline from prompt engineering for hierarchical execution. The ten corrections in Demo 2 happened because both agents had been instructed to push back on factual claims, not just answer questions.

The Topology Decision Should Be Explicit

The teams that are still treating orchestrator-worker as the only option are mostly doing so by inertia, not by analysis. The question is no longer whether peer-to-peer works. The Pi-to-Pi demo proved that with four tools and a Unix socket. The question is which parts of your agent system benefit from flat topology, which parts need hierarchical control, and how those two regimes hand off to each other.

We have written elsewhere about multi-agent kernels, about orchestration in production, and about team-shaped operating models. What this week’s demo adds is a clean, runnable proof that the topology choice is a real choice, with measurable effects on information flow, governance boundaries, and context utilization. The harness layer is where you make this choice. It matters which one you pick.

Do This Now

Block 45 minutes with your engineering lead and one senior agent designer. Pull a diagram of your most complex multi-agent flow. Ask three questions.

First: where in this flow does information die because a summary replaces a finding? If you cannot identify any such point, you have not looked hard enough. Every hierarchical flow has one. Mark it.

Second: of the boundaries you enforce centrally today (PII, data residency, rate limits, schema validation), which ones are enforced by an agent that does not own the domain being protected? Move those boundaries to the agents that do own the domain. That is the peer-to-peer pattern even inside a still-hierarchical flow.

Third: pick one node in the diagram where two agents could productively disagree, and currently cannot. Give them the tools to ping each other. Watch what comes out. The Pi-to-Pi repo gives you a four-tool protocol you can copy. The shift you are looking for is not in the tooling. It is in what reaches the decision once the agents can talk.

The orchestrator-worker pattern is not wrong. It is, however, not the only choice. Treating it as the default is how teams quietly lose access to the information their agents already have.

This analysis synthesizes Pi to Pi: Two-Way Agent Orchestration (IndyDevDan, May 2026), the pi-vs-claude-code repo (disler, May 2026), and Build Agents That Run for Hours (Anthropic, AI Engineer Conference 2026).

Victorino Group helps engineering teams choose between hierarchical and flat agent topologies and instrument both for production. Let’s talk.