1 The Vision — Peer-to-Peer Agents as Equals
Dan opens with a provocation: what's better than two GPT-5.5 Pi agents running side by side? Two agents that actually work together. He scales up to four Pi agents — none of them is the orchestrator. They're equals, co-workers, pinging each other in a flat network.
Opus 4.7
GPT-5.5
GLM
The key differentiator from existing patterns: this is bidirectional, peer-to-peer communication. Not orchestrator-to-worker. Not parent-to-child. Agents are equals with two-way channels, and the best information wins regardless of which agent holds it.
2 Demo — Prod/Dev Cross-Device Workflow
A real engineering scenario: Pro-tier users are getting locked out of features in production. Dan needs to reproduce the bug locally without leaking PII.
- Production agent (Mac Mini) — has access to the production database, understands PII constraints, acts as a "gatekeeper"
- Dev agent (MacBook Pro M5) — needs to reproduce the issue locally by getting a redacted data slice from production
The agents communicate across the network. The production agent sends redacted data (PII stripped) to the dev agent. The dev agent seeds its local database, reproduces the bug, and reports success. Multiple round-trips happen — it's a conversation, not a one-shot delegation.
3 Why Flat Information Hierarchies Win
Dan draws a parallel to organizational theory: in hierarchical companies, the best information is often at the bottom — with the engineers who have their "boots on the ground." But ideas get stuck because workers lack the title or authority to push them up.
The best organizations (Nvidia, startups) have flat structures where everyone can communicate directly. The same principle applies to multi-agent systems:
- Hierarchical (orchestrator) — information flows one direction, the orchestrator is a bottleneck
- Flat (peer-to-peer) — agents communicate directly, the best information wins regardless of which agent holds it
4 Current Patterns and Their Limits
Dan maps the evolution of multi-agent patterns:
| Pattern | Direction | Limitation |
|---|---|---|
| Sub-agent delegation | One-way ↓ | Parent delegates, child reports back. No lateral communication. |
| Message queue (Claude Code teams) | One-way via broker | One agent sets up the queue, acts as broker between agents. |
| Agent chains | One-way → | Deterministic pipeline. Powerful with code, but always forward-flowing. |
| Peer-to-peer (Pi to Pi) | Bidirectional ⇄ | Agents are equals. Two-way prompt-response between any pair. |
The common limitation of the first three: information always travels in one direction. Even when results come back, it's a one-way stream, never truly bidirectional.
5 The A2A Protocol — Four Simple Tools
The implementation is deliberately minimal — just four tools added as a Pi extension:
- List agents — see all agents currently on the network
- Send command — send a direct command to a specific agent
- Send prompt — send a prompt and get back a message ID
- Await response — wait for a response by message ID (blocking or polling)
An agent connects to the network, discovers peers, sends prompts, and awaits responses. It can fire-and-forget (like a Slack message) or await (like waiting for a reply). Two implementations exist: local (single-device via shared state) and network (cross-device via a lightweight Bun server with Unix sockets).
6 Demo — E2B vs exe.dev Skill Mirroring
The second demo shows a more complex use case: Dan has an existing E2B agent sandbox skill and wants to create a feature-parity skill for exe.dev.
- E2B agent (GPT-5.5) — specialist in the existing E2B skill. Answers questions, validates claims.
- exe.dev agent (Opus 4.7) — driver of the collaboration. Reads exe.dev docs, builds the new skill, asks E2B agent for feature comparisons.
The agents communicate multiple rounds: the exe.dev agent builds, the E2B agent reviews claims and sends back 10 corrections. The exe.dev agent incorporates them, sends back for final review, gets sign-off, and produces the final skill file.
7 Context Engineering — Focused Agents Win
Dan makes a strong case against the "just put everything in one agent" approach:
- The E2B agent is already at 20% of GPT-5.5's 1M context window just understanding one tool
- Adding a second, unrelated API would muddy the context and increase error rate
- Each agent stays focused on one problem, one API, one domain
8 Multi-Model Advantage
Running different models side by side creates something greater than either alone:
- GPT-5.5 — comprehensive, chews up tokens, gives the most detailed result possible
- Opus 4.7 — more goal-oriented, focuses on accomplishing the objective
When these models collaborate, their different training and RL loops create complementary strengths: "Just like code plus agent beats either alone, unique agent one plus unique agent two communicating beats either alone."
9 The Implementation — Two Extensions
Two Pi extensions available in the pi-vs-claude-code codebase:
| Extension | Scope | Transport |
|---|---|---|
| coms (local) | Single device | Shared state — agents on the same machine communicate via local state |
| coms-net (network) | Cross-device | Lightweight Bun server — agents connect, send/receive over network requests |
The network version boots a simple server that handles connections, message routing, agent listing, and event processing. Dan explicitly notes: "Secure it, make it more legitimate for your specific use case."
10 Pros & Cons
✅ Pros
- It's just an agent — boot up any number of agents, connect them, done. No special infrastructure.
- Permanent — agents stay alive. No spin-up/spin-down, no resume flags needed.
- Fully customizable — end-to-end control via Pi extensions. "The tool you use limits what you believe is possible."
- Bidirectional & flat — no hierarchy, no information loss, no bottleneck orchestrator.
- Primitives over composition — each agent is a primitive you can compose into larger systems.
❌ Cons
- You have to build it — prompt engineering, context engineering, edge case handling all on you.
- Loops are possible — sloppy prompts without clear end states can create infinite back-and-forth that burns tokens.
- Cost scales linearly — with agent count plus communication bounces. Dunbar's number applies — there's a limit to useful team size.
- Temptation to fall back to orchestration — peer-to-peer can be composed back into top-down if needed, but the advantage is specifically the flatness.
🎯 Key Takeaways
🔑 Key Takeaways
- Peer-to-peer agent communication is fundamentally different from orchestration — agents are equals, not parent-child. Information flows both directions.
- The protocol is simple: four tools — list agents, send command, send prompt, await response. No magic.
- Cross-device workflows enable real engineering patterns — prod/dev separation with PII safety, multi-machine coordination.
- Flat hierarchies surface the best information — just like in organizations, the most useful context often lives at the "worker" level, not the "orchestrator."
- Focused context windows reduce error rate — one agent per problem domain, communicate when needed. Don't mix unrelated APIs in one context.
- Different models create complementary systems — GPT-5.5 (comprehensive) + Opus 4.7 (goal-oriented) working together outperform either alone.
- Skill mirroring via agent collaboration — existing skill + new platform → agents compare, validate, and build feature-parity skills together.
- Two implementations available — local (single device) and network (cross-device via Bun server). Both open source.
- Loops are the main risk — prompts need clear end states. Sloppy prompts burn tokens in infinite back-and-forth.
- "We're exploring 1% of what's possible" — the state space of agentic engineering is mostly undiscovered. Customizable harnesses like Pi enable exploration.
🔗 Resources & Links
- pi-vs-claude-code — codebase with both coms extensions (local + network)
- Pi Coding Agent — official site
- exe.dev — agent sandbox platform (alternative to E2B)
- E2B — agent sandbox tool