20+ years scaling technical orgs. NYU/Caltech Physics + Columbia MBA. Bridging the gap between deep-tech and GTM success. Currently a Fractional CPO & Advisor for AI-native startups.
Location
Brooklyn, NY
Education
BS Applied Physics (NYU/Caltech); MBA, Columbia Business School.
Work
20+ yrs at Snowflake, SurrealDB, Omnicom. Now Fractional CPO & GTM Advisor for AI-native startups.
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.
20+ years scaling technical orgs. NYU/Caltech Physics + Columbia MBA. Bridging the gap between deep-tech and GTM success. Currently a Fractional CPO & Advisor for AI-native startups.
Location
Brooklyn, NY
Education
BS Applied Physics (NYU/Caltech); MBA, Columbia Business School.
Work
20+ yrs at Snowflake, SurrealDB, Omnicom. Now Fractional CPO & GTM Advisor for AI-native startups.
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 just eval(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.
20+ years scaling technical orgs. NYU/Caltech Physics + Columbia MBA. Bridging the gap between deep-tech and GTM success. Currently a Fractional CPO & Advisor for AI-native startups.
Location
Brooklyn, NY
Education
BS Applied Physics (NYU/Caltech); MBA, Columbia Business School.
Work
20+ yrs at Snowflake, SurrealDB, Omnicom. Now Fractional CPO & GTM Advisor for AI-native startups.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.