Agent Tools & Interoperability

Kanchana Patlolla, Łukasz Olejniczak, Pier Paolo Ippolito · pdf · 2026-06-10 Reader 🖥️

Agent-to-Agent Protocols Agentic Commerce MCP (Model Context Protocol)Multi-Agent Orchestration Cross-Vendor Protocol Standardization

Adopting standardized agent-interoperability protocols — MCP for tools, A2A for agent-to-agent delegation, A2UI for agent-generated interfaces, and AP2/UCP for agentic commerce — replaces the bespoke, fragile wrappers of custom integration with a modular, plug-and-play 'virtual workforce' architecture, converting a developer from a low-leverage integration 'Conductor' into a high-leverage system 'Orchestrator.'

practical · expository — A vendor (Google) practitioner whitepaper aimed at 'vibe coders' — it argues for a course of action (adopt MCP/A2A/A2UI/AP2/UCP as the integration layer for agent systems) and teaches how, rather than building a theory of why these protocols work.

Structure

Part	Role
Introduction / protocol-ecosystem framing (MCP, A2A, A2UI, AP2, UCP as 'Industry Standards')	context and thesis statement
The Vibe Coder's View of MCP: discovery, configuration, connection, NxM problem, debugging, best practices	evidence + how-to for the tool-consumption layer
A2A interoperability: monolith-to-microservices evolution of agent architectures, bounded vs. unbounded domains, the GOTO problem, Agent Card, registries, implementation patterns, monetization (AaaS, x402)	evidence + how-to for the agent-delegation layer
A2UI interoperability: generative UI, the basic catalog, two generation patterns, canvas integration, best practices	evidence + how-to for the agent-to-interface layer
AP2 and UCP: autonomous commerce split into 'what to buy' (UCP) and 'how to pay, bounded' (AP2)	evidence + how-to for the agent-to-commerce layer
Conclusion: protocols eliminate integration debt and elevate developers to architects of a global workforce	restated thesis / call to action

Key terms

Orchestrator Multi-Agent Orchestration
The role a developer or central agent occupies once protocols remove the need for bespoke integration code: directing high-level intent, discovering and delegating to specialist agents/tools, rather than hand-wiring every connection.
bounded vs. unbounded domain
A tool operates in a bounded domain (fire-and-forget: one well-formed request, one response). An agent operates in an unbounded domain (ambiguous inputs, may pause mid-task to negotiate, multi-turn state) — this distinction, not capability level, is why the author argues agents can't simply be wrapped as tools.
the GOTO Problem in Agentic Architecture
Forcing a collaborative, pausable, stateful agent into a standard tool-call wrapper is architecturally analogous to an unstructured jump: control flow leaves the expected structured context and may never return cleanly, so the messy multi-turn state needs its own isolated protocol layer (A2A) rather than living inside the tool layer (MCP).
A2UI (declarative UI intent)
A framework-agnostic format in which an agent describes *what* to render (component types, structure, data bindings) from a trusted catalog, never executable code or pre-rendered pixels — the renderer, not the agent, decides how to paint it natively per platform.
Maintenance Tax
The ongoing cost of keeping bespoke, per-vendor sub-agents (or integration wrappers) working as upstream products, prompts, and API schemas change — the author's argument for preferring officially maintained specialist agents over custom ones.

Propositions

explicitcontestedMCP, A2A, A2UI, AP2, and UCP function as industry-standard interoperability layers that let an agent's 'Harness' plug into tools, other agents, interfaces, and payment rails without bespoke wrapper code — replacing a low-leverage 'Conductor' role with a high-leverage 'Orchestrator' role.conf: high
contradictsPresentation: APIs for Agents: Rethinking API Programs in the MCP Era · p10 — Morgan Stanley argues individual agent protocols (MCP today, A2A tomorrow) are each uncertain to persist and recommends keeping APIs as the stable integration point; this whitepaper instead frames the protocols themselves as the durable 'Industry Standards' worth architecting around — opposite emphases on where durability lives.
supportsThe Interfaces Are Arriving · p1 — Both treat the donation of MCP and A2A to neutral, Linux-Foundation-based governance as the consequential standardization event that justifies building production architecture on top of these protocols.
explicitMCP reduces the integration cost of connecting N models to M tools from O(N×M) bespoke integration points to O(N+M) by standardizing discovery, configuration, and connection into one socket.conf: high
explicitA specialist AI agent cannot be safely wrapped as a plain callable tool because it operates in an unbounded problem space (ambiguous inputs, multi-turn negotiation, mid-task pauses), unlike a tool's bounded, fire-and-forget request/response contract — forcing the wrapper introduces 'the GOTO Problem' into the orchestrator's control flow.conf: high
explicitA2A resolves agent-ecosystem fragmentation by giving a central Orchestrator a standard way to discover (via Agent Card + registries), onboard, and delegate to any specialist agent regardless of its underlying framework, language, or organization.conf: high
extendsPresentation: APIs for Agents: Rethinking API Programs in the MCP Era · p9 — Morgan Stanley observes MCP and A2A are different interaction paradigms (tool calls vs. agent collaboration); this whitepaper extends that into a load-bearing architectural principle — the bounded/unbounded distinction and 'GOTO problem' — for why collaborative agent work structurally cannot live in the tool-call layer.
explicitAgentic architectures are recapitulating the monolith-to-microservices evolution of web software: a single 'Swiss Army knife' agent prompt hits a 'Monolithic Ceiling' (scaling friction from an oversized action space, contextual overload, single point of failure) that specialization resolves first internally (shared-runtime sub-agents) and then externally (A2A-separated specialist agents across network boundaries).conf: high
explicitA2UI makes generative UI safe by having agents request components from a trusted, renderer-owned catalog rather than emit executable code or raw pixels — the agent decides composition, the client decides rendering, so code-injection/XSS risk is structurally excluded rather than filtered.conf: high
explicitAP2 and UCP divide agentic commerce into two separable concerns: UCP standardizes how an agent discovers a merchant's offerings and composes an order (the 'what'), while AP2 provides a cryptographically signed, pre-authorized spending mandate that blocks unauthorized or inflated charges (the 'how to pay, bounded').conf: high
explicitFor domain-specialist agents (e.g., for Salesforce, Workday, ServiceNow), adopting an officially maintained specialist agent is preferable to building a bespoke sub-agent, because bespoke integration imposes an open-ended 'Maintenance Tax' of tracking the vendor's own prompt-logic and API-schema changes.conf: medium
explicitVibe coders should treat public MCP registries as fine for prototyping but unsafe for production: audit server code before connecting, never pass credentials to unverified community servers, scope servers to read-only/non-production data, and log tool usage for audit.conf: high
supportsMCP Is Making API Sprawl Worse · p4 — The empirical finding that 43% of MCP servers carry authentication flaws backs up this whitepaper's best-practice warning to audit public MCP servers and avoid trusting unverified community endpoints in production.
implicitThe paper treats governance, accountability, and failure-handling for an adopted 'official' specialist agent (version drift, outages, behavior changes) as largely out of scope, focusing almost entirely on the integration-cost side of the build-vs-buy decision.conf: medium
implicitThe paper assumes the 'vibe coder' persona — prioritizing velocity and consumption over protocol creation — can safely evaluate and bound the production risk of each adopted protocol surface through a short best-practices checklist, without dedicated platform or security-team involvement.conf: medium

Arguments

Teams building agentic systems should adopt MCP, A2A, A2UI, and AP2/UCP as their integration backbone rather than writing custom integration code, because doing so converts developers from low-leverage integration mechanics into high-leverage orchestrators of a virtual, interoperable workforce. strength: medium

Explicit premises:

The NxM integration math shows standardized protocols reduce connection effort from multiplicative to additive.
Treating a specialist agent as a tool breaks down architecturally (the bounded/unbounded distinction, the GOTO problem), so a dedicated delegation protocol (A2A) is structurally necessary, not a convenience.
Agent Cards and registries let specialists be discovered and hired without custom integration code, mirroring how microservices replaced monoliths.
Build-vs-buy favors adopting officially maintained specialist agents over bespoke ones because of the ongoing Maintenance Tax.

Implicit premises:

Standardizing the integration layer reduces total engineering effort faster than it adds new governance, negotiation, and monitoring overhead across many independently-maintained specialist agents.
The ecosystem of official specialist agents (Google, Salesforce, Workday, etc.) will mature into genuinely interoperable, reliable services rather than fragmenting into another generation of vendor-specific lock-in one layer up the stack.
An individual 'vibe coder' can adequately vet, scope, and monitor each adopted protocol surface (public MCP server, remote A2A agent, commerce mandate) using the paper's checklist-style best practices, without needing a dedicated platform/security function.

Inferences:

If every vendor ships and controls its own 'official' specialist agent, the 'virtual workforce' model reproduces SaaS-style vendor dependency risk at the agent layer — the same lock-in concern the paper doesn't raise when it recommends buying over building.
Because protocol churn (new MCP/A2A revisions) is real elsewhere in the corpus, teams following this paper's advice should expect to re-validate their adopted protocol surfaces on a recurring cadence, not treat the initial integration as done.

Narratives

The paper compares hiring a kitchen-renovation specialist versus buying tools and doing it yourself: a specialist is a collaborative partner who pauses to consult on trade-offs when they hit an edge case, unlike a tool that simply executes a request.
→ Supports the proposition that agents are categorically different from tools (collaborative partner vs. passive instrument) and justifies why A2A needs to exist as a separate protocol layer from MCP.
A 2 a.m. scenario where roommates deploy an AI assistant to order a burrito: UCP lets the agent query the restaurant's menu and compose an order ('one chicken burrito, no onions'), while AP2 enforces a pre-approved $25 spending mandate so the agent can pay without exposing a real card number or being overcharged.
→ Makes concrete and supports the proposition that UCP and AP2 split agentic commerce into discovery/composition ('what to buy') versus authorized, bounded payment ('how to pay').

Questions addressed

✅ How can a developer avoid the NxM integration crisis when connecting multiple models to multiple external tools?
Adopt MCP as a standardized socket (discovery, configuration, connection) so integration effort scales additively instead of multiplicatively.
✅ Why can't a specialist AI agent simply be exposed and consumed as a standard tool?
Because agents operate in an unbounded domain and can pause/negotiate mid-task, which breaks a tool's bounded request/response contract; A2A isolates this collaborative, multi-turn state instead.
✅ How can an agent generate a user interface at runtime without the security risk of agent-generated executable code?
A2UI has the agent declare UI intent against a trusted component catalog; the client-side renderer, not the agent, performs the actual rendering.
✅ How should an autonomous agent's spending be constrained so it can't overspend, get scammed, or make unauthorized purchases?
AP2's cryptographically signed mandate pre-authorizes bounded spending and blocks charges that violate it.
⭕ Who is accountable, and what happens operationally, when a depended-on 'official' specialist agent from another vendor changes behavior, degrades, or goes down?

Gaps

incompleteThe build-vs-buy argument for specialist agents is framed purely as a maintenance-tax tradeoff, with no discussion of vendor lock-in, SLA/accountability questions, or what happens when an officially maintained specialist agent's behavior silently drifts between versions — concerns that other corpus documents on production agent platforms (e.g., API governance under MCP sprawl, enterprise architecture-as-data platforms) treat as central, not peripheral.
Read next: Read alongside enterprise platform-governance accounts (e.g. the Morgan Stanley CALM/MCP piece) for how organizations actually assign ownership and SLAs across protocol boundaries.
incompleteThe 'virtual workforce' framing never addresses runtime failure modes for a remote A2A specialist (unavailable, slow, or behaving maliciously/incorrectly), despite the paper's own MCP best-practices section explicitly warning against trusting unverified public servers — the same caution is absent from the A2A discovery/registry sections.
Read next: Look for A2A-specific resilience patterns (circuit breakers, fallback orchestration, registry trust scoring) in follow-on protocol documentation.
uninformedThe paper treats MCP and A2A as settled 'Industry Standards' worth building an architecture around, without engaging the countervailing view — present elsewhere in the corpus — that individual agent protocols are still young and revised rapidly, and that APIs (not agent protocols) should remain the stable integration point precisely because of that churn risk.
Read next: Compare directly against documents arguing for an API-stable, protocol-agnostic integration layer underneath MCP/A2A.