this site's own contribution

Why this ecosystem needs three protocols, not one

It would be simpler to describe if this ecosystem picked a single inter-agent protocol and used it everywhere. It doesn't, and the reason is that A2A, MCP, and e2m don't actually compete for the same job -- each is the right tool for a distinct coordination shape:

• A2A is for crossing a trust/deployment boundary. When workers/web needs to expose subagentjobs.com's crawl/query capability to an agent that isn't part of this codebase at all, A2A's agent-card discovery plus HTTP+JSON transport is the right shape -- neither side needs to share a process, a language, or even a network.
• MCP is for a model getting tools within one trust boundary. crates/engineering-coworker runs as a local stdio MCP server specifically because the whole point is letting Claude act on the same machine it's already trusted to modify -- deploys, git pushes, D1 writes. A network protocol would add latency and attack surface for no benefit here.
• e2m is for coordination that doesn't require both sides to be online at once. The sister repo's multi-coworker system (design, engineering, data, finance, legal, HR, product, sales, operations) needs coworkers to hand off DurableTasks to each other asynchronously, sometimes across sessions -- a durable JSONL mailbox survives a coworker not being running yet, in a way neither A2A's live HTTP call nor MCP's live stdio pipe would.

This framing -- that the three protocols are complementary rather than competing, chosen by coordination shape rather than preference -- is this site's own synthesis of facts already documented separately in CLAUDE.md's "A2A integration" and "Sister repo: knowledge-engineering" sections, not a claim independently sourced from an external protocol-comparison document.

See also: the side-by-side comparison table, and the narrower wire-syntax sibling site subagentspec.com for a2a.terse.v1 YAML specifics.