A2A Protocols Beyond MCP: What Should RDCO Adopt for Inter-Skill Handoff?

The question

MCP solved tool access. Inter-agent comms is still ad-hoc in RDCO: subagent dispatch via the Agent/Task tool, one-way artifact handoff, no shared state, no async message-passing. As the pipeline-* fan-out scales, this gap becomes load-bearing. Which protocol — Google A2A, Pi-to-Pi, or an Anthropic-native pattern — should pipeline-* and check-board adopt? And does RDCO actually need a protocol at all right now?

What we already know (from the vault)

• Pi-to-Pi (IndyDevDan, 2026-05-18). Dan's peer-to-peer pattern: two-plus Pi agents communicating over a lightweight BUN/Unix-socket server with a deliberately minimal four-tool A2A protocol (list agents, send command, send prompt, await response). Bidirectional, flat-hierarchy, cross-device. Thesis: "the best ideas die in agent hierarchies the same way they die in corporate hierarchies," so flat peer topologies beat orchestrator/worker for some tasks. Two big caveats already flagged in the vault note: (1) you build it yourself, and (2) it's an "impossible on a rented harness" pattern — i.e. it presupposes you own the harness (Pi), which RDCO does not (we're on Claude Code). The note's own verdict: file as a watch-item, not actionable now, because L5 roadmap says unhobble the COO agent on Claude Code first.

• Dynamic Workflows + agent teams (AlphaSignal, 2026-05-29). Already in the vault: Opus 4.8 shipped Dynamic Workflows (research preview) — plan, fan out hundreds of subagents in one session, verify before returning. The vault note's own read: this is "the managed, plan-then-spawn-hundreds-then-verify version of exactly what RDCO already does by hand" with /process-newsletter, the pipeline seats, and the implementation-notes pattern. It explicitly reinforces RDCO's verification-as-independent-worker discipline (the "verify before returning" step is the native encoding of the /verify-* gates).

• Current RDCO handoff mechanics (read directly from the skills). The pipeline-* seats already pass work via filesystem handoff in a per-run scratch dir (~/rdco-vault/01-projects/skill-pipelines/runs/<domain>-<timestamp>/): spec-author writes spec.md → test-author reads it, writes tests.md → code-author reads both, writes code/ → critic reads code/ + reference exemplars, returns PASS/FAIL. The parent (build-haiku-generator) orchestrates by dispatching one general-purpose Agent subagent per seat, waiting on each return line, with seat isolation enforced precisely by what file each seat is allowed to read. check-board similarly dispatches background Agent subagents per complex task, passing the Notion page ID so the subagent can self-close — no shared state, no peer messaging.

• Agent architecture cluster (cross-check, 2026-04-12). Anthropic's own trajectory: TodoWrite "became a cage," replaced with a simpler Task tool; the design principle is remove harness complexity, not add it. Relevant because it argues against bolting a heavyweight protocol onto RDCO.

What the web says

• Google A2A is real, governed, and adopted — but it's an enterprise cross-vendor protocol. Released April 2025, donated to the Linux Foundation June 2025 (Apache 2.0). At its one-year mark (April 2026): 150+ organizations, deep integration in Google/Microsoft/AWS, production deployments in supply chain, finance, insurance, IT ops. Spec is on a public RFC process; v1.2 (March 2026) is current stable. Native support in Google ADK, LangGraph, CrewAI, LlamaIndex, Semantic Kernel, AutoGen. The mechanism: agents publish "agent cards," discover each other, authenticate, and delegate tasks across organizational and framework boundaries. It is designed for the case where Agent A (your company) hands a task to Agent B (a vendor) running a different stack.

• Anthropic now ships TWO native inter-agent primitives — this is the "Anthropic-blessed pattern."

  • Dynamic Workflows (GA-ish research preview, June 2 2026, Claude Code v2.1.154+). A dynamic workflow is a JavaScript script Claude writes that orchestrates subagents; a runtime executes it in the background. Intermediate results live in script variables, not context windows. Up to 16 concurrent agents, 1,000 total per run. It can have independent agents adversarially review each other's findings before reporting. Critically: /deep-research is a bundled workflow — the exact deep-research engine RDCO already runs is now a native Claude Code workflow primitive. You can have Claude write a workflow, then s to save it as a /command in ~/.claude/workflows/.
  • Agent teams (experimental, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). This is the literal A2A primitive: a lead + teammates (each a full independent Claude Code session) coordinating through a shared task list (~/.claude/tasks/{team}/, file-locked claiming) and a mailbox with direct teammate-to-teammate messaging (auto-delivered, no polling). Teammates can challenge each other ("scientific debate" pattern), self-claim unblocked tasks, and depend on each other's tasks. Teammate roles can reuse subagent definitions. This is Pi-to-Pi's bidirectional flat topology, but native, on the harness RDCO already owns.

• MCP vs A2A framing (consensus across sources). They are complementary, not competing: MCP = agent-to-tool (vertical), A2A = agent-to-agent (horizontal). Google's own positioning puts A2A on top of an MCP foundation. A2A's reason to exist is cross-vendor, cross-framework agent interop — which is not RDCO's problem.

Convergences and contradictions

• Convergence — everyone landed on the same shape. Dan's four-tool Pi-to-Pi protocol (list / send command / send prompt / await response) is structurally identical to Anthropic agent teams' mailbox + shared task list. Google A2A's discover/delegate/await is the same primitive at enterprise scale. The frontier converged on "agents need a roster, a way to send, and a way to await." RDCO doesn't need to pick a philosophy — the philosophy is settled.

• Convergence — flat peer topology earns its keep only for adversarial/exploratory work. Pi-to-Pi, agent teams' "competing hypotheses" example, and Dynamic Workflows' "draft a plan from several angles" all cite the same use case: independent agents challenging each other to beat anchoring bias. That is exactly the RDCO pipeline-critic fan-out and the /verify-* fresh-eyes pattern. For sequential work (spec → test → code), every source agrees a single orchestrator with one-way handoff is correct — which is what the pipeline already does.

• Contradiction — "you must own the harness" (Dan) vs "it's native now" (Anthropic). The Pi-to-Pi vault note's load-bearing claim was that bidirectional peer comms is impossible on a rented harness. As of June 2026 that claim is stale: Anthropic shipped exactly this (agent teams + workflows) natively in Claude Code. The harness-ownership argument for adopting Pi specifically just lost its strongest leg for this use case. (Log to the harness-ownership watch-item.)

• No contradiction, but a scope mismatch — Google A2A solves a problem RDCO doesn't have. A2A's value is cross-org, cross-framework interop with auth and agent-card discovery. RDCO is a single-founder, single-harness, single-vendor (Anthropic) shop. Adopting A2A would be importing enterprise federation machinery to coordinate four skills that all live in ~/.claude/skills/ on one Mac Mini. Pure overhead.

Synthesis for RDCO

Recommendation: do NOT adopt any third-party A2A protocol. The current Agent-tool dispatch + filesystem-scratch-dir handoff is correct for pipeline-* and check-board today. When (and only when) a future skill genuinely needs adversarial peer cross-talk, reach for Anthropic-native Dynamic Workflows first, agent teams second — both are on the harness RDCO already owns.

Reasoning against each option:

• Google A2A — reject. Cross-vendor federation protocol for a single-vendor shop. Lock-in risk is low (Linux Foundation), but the fit is wrong: it solves interop RDCO doesn't have, and it sits below the abstraction RDCO works at (Claude Code skills, not raw agent servers). Cost to adopt: high (stand up A2A servers, agent cards, auth). Benefit: ~zero. Skip.

• Pi-to-Pi — reject for adoption, keep as a watch-item. Its one decisive advantage (bidirectional peer comms impossible on a rented harness) was neutralized by Anthropic shipping agent teams. Adopting Pi would mean migrating off Claude Code, which contradicts the L5 "unhobble the COO agent on Claude Code first" roadmap. The idea (flat adversarial peers) is validated and now available natively.

• Anthropic Dynamic Workflows — adopt opportunistically, NOT a rip-and-replace. This is the most important finding: the dynamic-workflows release changes the build-vs-adopt calculus. RDCO's pipeline-* is a hand-rolled orchestrator-worker with a convergence loop — exactly what a Dynamic Workflow is for. And /deep-research is now a bundled workflow, meaning RDCO's deep-research skill has a native competitor/replacement. But two reasons not to rip-and-replace now: (1) it's research-preview, and (2) RDCO's pipeline encodes deliberate filesystem isolation between seats (rubber-stamp prevention — code-author must not see reference exemplars) that the founder explicitly designed; a workflow script can replicate this but it's a re-derivation, not a free port. Right move: when the pipeline graduates from build-haiku-generator smoke-test to a real domain, prototype that domain as a saved Dynamic Workflow in parallel and compare against the hand-rolled seats. Don't migrate the seats pre-emptively.

• Agent teams — hold for the adversarial-critic use case specifically. The one place RDCO would benefit from true A2A (teammates messaging each other) is the pipeline-critic / /verify-* family, where the "competing hypotheses, challenge each other" pattern is native. Even there, it's experimental and token-heavy. Park until it leaves experimental.

Does RDCO need a protocol now? No. The gap described in the question (no shared state, no message-passing) is real but not yet load-bearing — the pipeline is still at smoke-test stage (build-haiku-generator, not yet shipped to a real domain), and the scratch-dir handoff is sufficient and auditable for one-way sequential flow. Premature protocol adoption would add exactly the harness complexity Anthropic's own trajectory (TodoWrite → simpler Task tool) warns against.

Rip-and-replace cost estimate:

• If we adopt the recommendation (do nothing structural now): $0 / zero engineering. Add a one-line note to each pipeline-* SKILL.md and check-board pointing at Dynamic Workflows as the graduation target. ~30 min.
• If we later port pipeline-* to a Dynamic Workflow: low-moderate. The 4 seat SKILL.md files (~284 lines total) + build-haiku-generator orchestrator (~135 lines) collapse into one workflow script Claude writes; the load-bearing work is re-encoding the filesystem-isolation rules (which seat reads what) as script-variable scoping. Estimate: one focused session to prototype + critic-gate, plus a head-to-head eval run on the haiku smoke-test before trusting it. Reversible — keep the seats until the workflow beats them.
• If we ever needed Google A2A: high and unwarranted — new infra (servers, agent cards, auth), no current payoff. Not estimated further.

Open follow-ups

• Should /deep-research (RDCO's skill) be retired in favor of the bundled Claude Code /deep-research workflow, or do RDCO's vault-write + /verify-* gates justify keeping the custom one?
• Prototype: port build-haiku-generator to a saved Dynamic Workflow and run a head-to-head against the hand-rolled 4-seat pipeline — does the workflow preserve seat isolation (rubber-stamp prevention)?
• At what scale does check-board's per-task background-subagent dispatch hit a coordination ceiling that a shared task list (agent teams) would solve — and is the Notion board already serving as that shared task list?
• Harness-ownership watch-item refresh: now that Anthropic ships native peer comms, what's left in Dan's "impossible on a rented harness" list that RDCO actually wants?
• Does Dynamic Workflows' 16-concurrent / 1,000-total agent cap change the economics of the pipeline-critic per-axis fan-out enough to widen the critic axes?

Related

• [[2026-05-18-indy-dev-dan-pi-to-pi-two-way-agent-orchestration]]
• [[2026-05-29-alphasignal-opus-4-8-dynamic-workflows-effort-control]]
• [[2026-04-12-cross-check-agent-architecture]]
• [[2026-04-06-claude-agent-sdk-guide]]
• [[2026-04-15-thariq-claude-code-session-management-1m-context]]

Sources

• Vault: ~/rdco-vault/06-reference/2026-05-18-indy-dev-dan-pi-to-pi-two-way-agent-orchestration.md
• Vault: ~/rdco-vault/06-reference/2026-05-29-alphasignal-opus-4-8-dynamic-workflows-effort-control.md
• Vault: ~/rdco-vault/06-reference/cross-checks/2026-04-12-cross-check-agent-architecture.md
• Skills (read directly): ~/.claude/skills/pipeline-{spec,test,code}-author/SKILL.md, ~/.claude/skills/pipeline-critic/SKILL.md, ~/.claude/skills/build-haiku-generator/SKILL.md, ~/.claude/skills/check-board/SKILL.md
• Web: Claude Code Docs — Dynamic Workflows — https://code.claude.com/docs/en/workflows
• Web: Claude Code Docs — Agent Teams — https://code.claude.com/docs/en/agent-teams
• Web: Anthropic blog — Introducing dynamic workflows in Claude Code — https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
• Web: Linux Foundation press — A2A Protocol Surpasses 150 Organizations (one-year milestone) — https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
• Web: Google Developers Blog — Google Cloud donates A2A to Linux Foundation — https://developers.googleblog.com/en/google-cloud-donates-a2a-to-linux-foundation/