Pi to Pi: Two-Way Agent Orchestration

The Shift from Hierarchy to Peer-to-Peer

Most multi-agent systems rely on a top-down, hierarchical structure where a primary orchestrator delegates tasks to sub-agents. This mirrors corporate bureaucracy, where information often gets lost or filtered as it moves up and down the chain. IndyDevDan argues that this is a local maximum; the most effective agentic systems should instead be flat, allowing agents to act as equal coworkers that communicate bidirectionally. By using a simple Unix socket and BUN server, agents can ping each other, share context, and coordinate on complex tasks without a central bottleneck.

Context Engineering and Specialization

Rather than stuffing massive context windows with every possible detail, the Pi-to-Pi pattern encourages "context engineering." By splitting tasks across specialized agents—each with a focused, clean context window—the system reduces the likelihood of hallucinations or errors. This approach allows for cross-device workflows, such as a production-side agent on a Mac Mini coordinating with a developer-side agent on a MacBook Pro. The production agent can perform tasks like data redaction and PII-safe database slicing, passing only the necessary, sanitized information to the developer agent to reproduce bugs locally.

Implementation and Workflow

The Pi-to-Pi protocol is built on four fundamental operations: listing agents, sending commands, sending prompts, and awaiting responses. This allows for dynamic scaling where new agents (e.g., specialized models like GLM or GPT-5.5) can be added to the communication pool on the fly. In the provided demo, the system is used to build feature parity between two different sandbox tools (E2B and exe.dev). One agent acts as the subject matter expert for E2B, while the other acts as the builder for exe.dev, communicating back and forth to ensure the new skill is implemented correctly based on the feature inventory generated by the first agent.

Trade-offs and Limitations

While powerful, this pattern is not a silver bullet. The speaker emphasizes that "great engineering is all about managing trade-offs." As the number of agents in a pool increases, the overhead of communication and the potential for context noise grow. There is a point of diminishing returns where adding more agents provides no additional value. The goal is to maintain a balance where the agents are specialized enough to be performant but connected enough to solve complex, multi-step engineering problems that a single agent could not handle alone.