Pi to Pi: Two-Way Agent Orchestration — Deep Dive

1 The Pitch — Why Two-Way Agent Communication? ▶ 0:00

Opens with the escalation: what's better than one GPT 5.5 Pi agent? Two that actually work together. What about three with unique models? Four agents where none is the orchestrator — they're equals, co-workers.

The key insight: giving agents a true two-way communication channel creates a flat hierarchy where the best information wins and the best ideas win. This is 'Pi to Pi' — peer-to-peer agent communication.

2 Demo 1 — Production DB Debugging with PII Safety ▶ 1:27

Real-world scenario: Pro-tier users getting locked out of pro features in a production database on a Mac Mini.

Setup

• Production agent (Mac Mini) — gatekeeper with PII constraints, understands the system, will not expose personal identifiable information
• Developer agent (M5 MacBook Pro) — needs to reproduce the issue locally

Communication Flow

1. Dev agent sees the prod agent on the network
2. Sends a message/prompt, gets a message ID
3. Can await the response
4. Prod agent works with all redactions applied
5. They iterate back and forth — not as sub-agents or workers, but as a team

Result: PII-safe reproduction of the production bug on the dev machine. The prod agent transferred a redacted slice of the database, dev agent set up local repro. Both agents verified the work.

3 The Problem with Current Agent Communication ▶ 4:59

Current landscape of agent communication patterns:

• Sub-agent delegation — great start but one-directional (top-down)
• Message queues (used by Claude Code agent teams) — one agent as broker
• Agent chains — deterministic workflow with agent nodes, powerful with code integration

The problem: in all these patterns, information travels in basically one direction. It's always top-down. Even if information comes back, it's a one-way stream, never truly bidirectional.

Solution: let agents talk to each other — prompt/response in both directions. Peer-to-peer, not orchestrator-to-worker.

4 The Philosophy — Flat Information Hierarchies ▶ 8:11

Draws parallel to organizational structures:

• Traditional companies have hierarchies where information/commands travel downstream
• Often the best information, decisions, and system awareness lives at the bottom — the engineers with boots on the ground
• Best ideas get stuck at lower levels due to lack of title/authority
• Best companies (Nvidia, startups) use flat structures where everyone can communicate directly

'Ideas die in hierarchies.'

This applies to agent systems: valuable information should win over structural position. Flat agent hierarchies mirror the best organizational patterns.

5 Cross-Device Agent Communication ▶ 10:35

Practical benefits demonstrated:

• Cross-device communication (production EU server ↔ developer machine)
• PII compliance — data never leaves the production device unredacted
• Dynamic agent pools — agents can be added via 'Jcoms' command
• Focused context — each agent maintains its own context, no spillover between issues

6 Demo 2 — Feature Parity Skill Building (E2B vs exe.dev) ▶ 12:41

Second demonstration: building a new agent sandbox skill for exe.dev that mirrors an existing E2B agent sandbox skill.

Setup

• E2B agent (GPT 5.5) — understands the existing E2B skill, stands by to answer questions
• exe.dev agent (Opus 4.7) — driver of the collaboration, builds the new skill

Workflow

1. E2B agent loads and inventories all its sandbox features (commands, inputs, outputs, quirks)
2. exe.dev agent reads documentation, gets live access via SSH
3. Agents communicate to map features one-to-one
4. exe.dev agent asks questions, E2B agent provides detailed answers
5. Feature parity document created with corrections
6. Claims are validated — 10 corrections found through agent-to-agent verification

'It's not just getting all the right things. It's getting just the right things.'

Each agent at 20% of its 1M context window, focused on one specific tool.

7 Model Observations — GPT 5.5 vs Opus 4.7 ▶ 18:06

• GPT 5.5: 'chews up tokens', goes and goes for comprehensive results
• Opus 4.7: more goal-oriented, focuses on accomplishing the goal; will expand scope if prompted widely
• Running both together creates something greater than either alone — different training, different RL loops

'Unique agent one plus unique agent two, communicating, beats either alone.'

8 The Implementation — Four Simple Tools ▶ 21:43

The system is remarkably simple — four tools:

1. List agents — discover all agents on the network
2. Send command — send a prompt to another agent
3. Await response — block-wait for a reply
4. Check/pull — non-blocking status check on a message

Two Versions

• Comms (local) — operates on a single device
• Comms Net (network) — lightweight Bun server accepting requests over the network; supports connect, get messages, list agents, process events

Both available in the 'Pi versus Cloud Code' codebase.

9 Pros & Cons Analysis ▶ 27:55

10 The Bigger Picture — Agentic Engineering ▶ 32:55

• Only ~1% of the state space of agentic engineering has been discovered
• Customization and extensibility are core to the future
• 'The tool you use limits what you believe is possible'
• Renting your agent harness (Claude Code, Codex, Gemini CLI) limits exploration
• This pattern adds to the 'bag of tricks' for agent harness owners
• Goal: increasing trust and scale of agentic systems week after week

🕐 Timestamp Index