If you're building anything with AI agents in 2026, you've probably heard two acronyms thrown around constantly: MCP and A2A. You might have also h...
For further actions, you may consider blocking this person and/or reporting abuse
The MCP vs A2A framing is right but it undersells how different the ergonomics actually are in practice. I built DOMShell on MCP, and the "tool as function call" model clicked immediately — the hard part wasn't the protocol, it was deciding what granularity to expose. I'm curious whether A2A will push multi-agent builders toward more opinionated orchestration patterns, or if we'll end up with another pile of one-off agent schemas dressed up as a standard.
The granularity problem is real for real world adoption. Too much makes it complex, too little makes it fuzzy. We hit the same wall when we started building agent infrastructure for hiring, the MCP side was straightforward. Expose a tool, define the schema, done.
On your A2A question — I think the answer is neither opinionated orchestration nor one-off schemas. It's domain protocols. A2A gives you the transport and the Agent Card handshake, but it deliberately doesn't tell agents what they're negotiating about. It's a design choice — but it means every vertical either builds shared semantics or you get exactly what you described: a pile of bespoke schemas pretending to be interoperable.
Payments already went this way. Visa built TAP, Mastercard built Agent Pay — both domain layers on top of generic agent plumbing and Stripe / OpenAI with ACP.
We're doing the same for hiring (OTP/OJP, MIT-licensed). The pattern seems to be: generic protocol for discovery and transport, domain protocol for transaction semantics. Which maps to human industry knowledge.
The "one-off schema" outcome is what happens when people skip the domain layer and try to cram vertical logic into A2A extensions. I'd bet against that working.
The domain protocol layer is the missing piece most A2A discussions skip. Every major protocol followed the same arc: transport layer first, then industry convergence around shared business logic and supporting systems that turn 1-to-1 company interactions into proper platform plays. Payments (Visa/Mastercard rails to interchange networks), advertising (OpenRTB from bilateral deals to programmatic exchanges), healthcare (HL7 to FHIR ecosystems). The pattern is always: point-to-point protocol, then multilateral semantics, then platforms.
That is the real question for A2A. The name says it: Agent to Agent, singular. But the interesting problems in hiring, procurement, supply chain are agents-to-agents, where discovery, trust, and transaction semantics need to work across a network, not just a pair. Your OTP/OJP work is interesting precisely because hiring forces you into that multi-party problem early. Curious how you see the path from bilateral agent handshakes to something more like an exchange.
We currently frame what we do, similar to how FIX standardized the bilateral message between broker and exchange. But the exchange itself — order matching, multilateral settlement, audit trail — was a different layer entirely. FIX didn't become the exchange. The exchange was built above it.
That's how we see A2A. It gives you the handshake. But the exchange semantics, discovery mechanism, trust propagation, multilateral settlement come from the domain layer above A2A.
We register demand/supply pulses (OJP for jobs, OTP for talent), run filter across the network (constraint overlap on location, availability...), then escalate the shortlist to reasoning models. That's register → filter → match → settle. The domain protocols define the order format. The matching tiers are the matching engine.
The compliance vault is the clearing house + agent identity verification.
We couldn't start bilateral and bolt on network semantics later. OTP/OJP had to support multilateral from day one. That's O(M+N) routing through the exchange, not O(M×N) point-to-point integrations.
The path from A2A to exchange: domain protocols that give agents shared context for what they're negotiating, then an exchange layer that handles discovery, matching, and settlement across the network. A2A is the transport. The domain layer is what turns messaging into a market.
The granularity question is exactly what I've been wrestling with. I built an MCP server for browser automation with ~30 tools, and the answer I landed on was a layered protocol: 8 irreducible core operations (eval, pointer, keyboard, nav, wait, screenshot, run, capabilities) + 17 composed built-in operations that any AI client gets for free.
The key insight: the AI doesn't need 30 fine-grained tools if you give it a small, composable core + higher-level operations built from that core.
click(target)is justeval(find)+pointer(x, y, 'click')— but the AI can call either depending on what it needs.On A2A: I think MCP's "tool as function call" model wins for single-agent use cases. A2A adds value when agents need to negotiate capabilities with each other — but most real-world automation today is one agent talking to one tool server, not agent-to-agent coordination.
The layered protocol is the same design I landed on with DOMShell. 39 tools total, but structurally it is a small set of primitives (eval, cd, ls, find, text, click, type, scroll) plus composed operations that chain them (read, grep, extract_table, extract_links). The AI calls whichever level it needs, and the composed operations are just documented aliases for common primitive chains. The 8+17 split you describe is almost identical. Where I ended up diverging: DOMShell exposes a filesystem metaphor on top of the accessibility tree rather than raw DOM. cd into a section, ls its children, grep for elements. That abstraction cut API calls by about 50% compared to coordinate-based approaches because the agent navigates structure rather than pixels. Agree on A2A. The single-agent-to-tool-server pattern is where 95% of real usage is today. A2A becomes interesting when you need agents to discover and negotiate capabilities, which is a different problem than tool execution.
The complementary framing (MCP for tool access, A2A for agent-to-agent) is the right mental model. In practice, we found MCP is where you start and A2A is where you end up wanting to go once your agents need to coordinate across services. The 97 million monthly SDK downloads stat is wild — it went from niche to default infrastructure in about 18 months.
From a fintech perspective, the security model matters more than the protocol choice. We need cryptographic audit trails for every agent action that touches payment data. MCP's tool-level auth is a decent foundation, but the moment you chain multiple MCP servers together, the authorization boundary gets fuzzy fast.
The framing of MCP and A2A as "complementary layers" rather than competing standards is the right mental model — but it took us longer than it should have to internalize it. We initially tried to route agent-to-agent calls through MCP servers and ended up with awkward bidirectional hacks before A2A gave us proper agent discovery and handoff.
Where I'd push back slightly: the boundary between MCP and A2A can blur in practice. When an MCP server starts maintaining state between calls and returning structured "next action" suggestions, it's starting to behave like an agent. And when an A2A agent exposes a tight tool interface, it looks a lot like an MCP server. The conceptual line is clean; the implementation line often isn't.
Is there a worked example in your experience where you had to consciously decide which protocol was the right fit? Particularly curious about cases where the same capability could have been reasonably implemented either way.
This is a useful framing because many teams currently discuss MCP and A2A as competing buzzwords instead of different coordination layers solving different problems. I especially liked the focus on interoperability and operational complexity because that is where protocol choices become architectural decisions rather than implementation details. Another challenge I think will grow quickly is debugging across protocol boundaries once multiple agents, runtimes, and orchestration layers interact. Understanding one agent run end-to-end is already difficult before introducing cross-protocol coordination. Nice practical comparison overall.
The three-layer framing (WebMCP → MCP → A2A) is a useful mental model that I haven't seen clearly laid out elsewhere. Most discussions treat these protocols as competing or overlapping, when in practice they're solving different parts of the coordination problem.
The practical implication that I think gets undersold: MCP's client-server model gives you reliable, auditable, typed tool interfaces. A2A's peer-to-peer discovery model gives you dynamic capability negotiation between agents. These are fundamentally different needs — one is about controlled access to external systems, the other is about flexible delegation between agents that may not know about each other at design time.
One challenge with the three-layer stack in production: debugging failures across all three layers requires instrumenting all three separately, and today's tooling doesn't unify them well. When an A2A task fails, was it a delegation routing issue, an MCP tool failure, or a WebMCP access error? Right now that usually means reading three separate log streams. An observability layer that treats the whole stack as one trace unit would be a significant unlock for teams running complex pipelines.
Looking forward to seeing how the A2A governance model evolves under the AAIF — the protocol having a neutral home helps a lot with enterprise adoption.
Comprehensive breakdown. The three-layer stack framing (WebMCP → MCP → A2A) is the clearest mental model I've seen for how these protocols relate.