"Pi to Pi: Two-Way Agent Orchestration with the Pi Coding Agent" — IndyDevDan

Why this is in the vault

Dan keeps pushing the frontier on multi-agent orchestration patterns beyond the dominant orchestrator/sub-agent shape, and this video introduces a peer-to-peer flat-hierarchy pattern with two-way bidirectional communication across devices. Directly relevant to RDCO's COO-agent harness work — particularly the question of how multiple Ray instances on multiple machines could coordinate without a hard top-down hierarchy. Also useful as a data point on the agent-harness-ownership thesis (Pi vs Claude Code) which the founder is actively tracking.

Episode summary

IndyDevDan introduces "Pi to Pi" — two Pi coding agents (or more) communicating peer-to-peer over a lightweight Unix socket / BUN server with a four-tool A2A protocol (list agents, send command, send prompt, await response). Two live demos: (1) a Prod/Dev scenario where a production agent on a Mac Mini coordinates with a dev agent on an M5 MacBook Pro to reproduce a Pro-tier user lockout bug while keeping PII safe, and (2) an E2B agent + exe.dev agent collaborating to build a new agent-sandbox skill with feature parity. The core thesis: flat agent hierarchies beat orchestrator/worker patterns because "the best ideas die in agent hierarchies the same way they die in corporate hierarchies." Code shipped in the pi-vs-claude-code repo as two extensions (comms and comms-net).

Key arguments / segments

• [00:00:00] Cold open: what's better than two GPT-5.5 agents? Two GPT-5.5 agents that actually work together. Push to 3-5 peer agents on the network, no orchestrator.
• [00:01:30] Demo 1 setup — production database on Mac Mini with Pro-tier user lockout bug; need to reproduce on M5 dev machine without leaking PII. Two jcoms commands boot one prod agent + one dev agent.
• [00:04:00] The agents negotiate: dev agent sees the prod peer on the network, sends a prompt requesting the affected slice with PII stripped. Prod agent works through the redaction. Bidirectional message exchange (await response on a message ID).
• [00:05:30] Why agent-to-agent matters — current state of the art is sub-agent delegation (Claude Code Agent Teams pattern with one orchestrator + message queue) or deterministic agent chains. All are one-way top-down information flows. Peer-to-peer unlocks bidirectional.
• [00:08:30] Information-hierarchy thesis: in traditional companies, the best information is at the worker level (engineers with boots on the ground), but ideas get stuck because they don't have the right title. Flat structures (cited: Nvidia, startups) win because valuable information beats titles/politics. Same dynamic for agents — "ideas die in hierarchies."
• [00:11:00] Demo 1 wraps: PII-clean repro of the production bug is now on the dev machine, agent has done legitimate cross-device engineering work, both context windows stayed focused.
• [00:12:00] Demo 2 setup — wants to build a new exe.dev agent-sandbox skill that has feature parity with his existing E2B skill. Spins up an E2B agent and an exe.dev agent in a separate comms pool, asks the E2B agent to be the reference / answer questions about the existing skill.
• [00:15:00] Context-engineering lesson — "a focused agent is a performant agent." Each agent in the pair has a tight context (one focused on E2B, one on exe.dev) so error rate stays low. The lesson: don't wait for a 5M-token context to solve all problems; instead specialize agents per problem.
• [00:18:00] Comparison aside: GPT-5.5 chews tokens for comprehensive results; Opus 4.7 is more goal-oriented. Useful pairing — different RL training, different strengths, combined system outperforms either alone.
• [00:20:30] exe.dev agent boots up, connects via SSH, fetches docs, starts asking the E2B agent specific questions (browser tool, templates vs images, snapshot equivalent, etc).
• [00:21:30] System internals — four tools, no magic: list agents, send command, send prompt, await response (blocking or non-blocking poll). Two versions ship: comms (single-device) and comms-net (lightweight BUN server for cross-device).
• [00:23:30] Verifier-agent pattern in action — the agents are double-checking each other's claims, surfacing 10 corrections from one exchange (e.g. wrong recursive flag, snapshot has no E2B equivalent, CP unique to exe.dev). Cross-references Dan's prior verifier-agent video.
• [00:26:00] Why not just one agent? Because (a) context window is finite and error rate scales with unrelated content muddied together, and (b) different models trained differently combine to make a stronger system. "Unique agent 1 + unique agent 2 communicating beats either alone."
• [00:28:00] Pros: it's just an agent + extension (no spin-up/spin-down, no sub-agent delegation), persistent, fully customizable end-to-end, bidirectional and flat. Reinforces "the tool you use limits what you believe is possible" — owning the agent harness is the unlock.
• [00:30:00] Cons: you have to build it yourself (or take Dan's from the repo); loops are possible if prompts are sloppy (need a clear end state); cost scales linearly with agent count + communication bounce; risk of falling back into orchestration pattern unnecessarily.
• [00:33:00] Close: peer-to-peer composes back into orchestration if needed; one of many multi-agent patterns to be discovered. Two extensions added to the pi-vs-claude-code repo. Dan teases next pattern waiting on next Gemini launch.

Notable claims

• "The state space of agentic engineering is vast. Only one percent of what is possible has been discovered." Recurring Dan framing — useful as a calibration line against the temptation to declare any current pattern as "the" architecture. [00:28:00]
• "A focused agent is a performant agent. The more you add to that context window, the higher the chance something goes wrong is." Direct echo of Thariq's context-rot guidance ([[~/rdco-vault/06-reference/2026-04-15-thariq-claude-code-session-management-1m-context.md]]); used here as the rationale for splitting work across peer agents rather than scaling one agent's context. [00:15:30]
• The A2A protocol is just four tools (list agents, send command, send prompt, await response). Intentional minimalism. [00:21:30]
• Cross-device variant uses a lightweight BUN server on Unix sockets — no heavy infra. [00:22:30]
• Multi-model peer pairing (GPT-5.5 + Opus 4.7) outperforms either alone because different RL training produces complementary strengths. [00:26:30]

Guests

No guests — solo creator video. Code ships at github.com/disler/pi-vs-claude-code as the comms and comms-net extensions. Referenced tools: Pi Coding Agent (pi.dev), exe.dev, e2b.dev. Referenced prior video: "Verifier Agent" (https://youtu.be/EnXKysJNz_8).

Mapping against Ray Data Co

Strong relevance.

• Multi-agent COO substrate. RDCO is actively building the COO-agent (Ray) and has been thinking about how multiple Ray instances on different machines might coordinate (e.g. Mac Mini always-on agent + ad-hoc laptop sessions). The Pi-to-Pi peer-to-peer pattern is a concrete shape worth evaluating against the current setup (LaunchAgent + tmux + Discord/iMessage channels). Worth a small spike: could the Mac Mini Ray and a laptop Ray hand work between each other via a similar A2A primitive instead of routing through the Notion task board?
• Context-rot reinforcement. Dan independently arrives at the same conclusion as Thariq's Anthropic guidance — focused per-agent context beats one agent with everything. Useful corroboration for the existing RDCO rule (CLAUDE.md hard rule #4) about routing long artifacts through subagents. The Pi-to-Pi pattern extends that pattern from "subagent for ingestion" to "peer agent for execution."
• Harness-ownership thesis. Dan keeps pushing the line that owning the agent harness (Pi, not Claude Code/Codex/Gemini CLI) unlocks patterns that are impossible to build on rented harnesses. The founder is actively tracking this — Ray is on Claude Code (rented harness). Worth a vault flag: at what point does the cost of NOT owning the harness exceed the cost of building one? Pi-to-Pi peer-to-peer is one of those "impossible on rented harness" patterns Dan cites. Not yet an actionable decision for RDCO (Claude Code remains the right call for unhobbling COO agent first per L5 roadmap), but file as a watch-item.
• Verifier-agent pattern reinforcement. Dan again demonstrates a verifier agent catching real claim errors (10 corrections from one exchange). Reinforces the RDCO pattern of fresh-eyes critic subagents (codified in verify-vault-write, verify-dispatch, verify-strategic-output, design-critic, video-critic). The Pi-to-Pi version is peer-shaped rather than nested-shaped — same underlying mechanism, different topology.
• Skill mirroring pattern. Demo 2 (E2B → exe.dev skill mirroring via two peer agents) is a clean reusable pattern: "I have a skill against tool A; spin up two peer agents to mirror it against tool B with feature parity verified by cross-agent claim-checking." Directly applicable when RDCO needs to swap providers (e.g. if 1Password / Cloudflare migrations come up again, or any time we hedge against vendor lock-in).

Related

• [[06-reference/2026-04-15-thariq-claude-code-session-management-1m-context.md]] — context-rot guidance, same thesis from Anthropic side
• IndyDevDan's verifier-agent video (https://youtu.be/EnXKysJNz_8) — referenced inline
• Prior IndyDevDan agent-thread cluster (2026-04-20 synthesis if it exists in vault)
• [[01-projects/]] COO-agent harness work — Mac Mini channels-agent setup
• [[concepts/]] flat-hierarchy-information-flow (seed concept article candidate — Dan + Nvidia + startup observation)