Interoperability Capstone: A2A + ADK on the Platform

Before you start: this is a billed cloud service

• Cost and account. A Google Cloud project with billing enabled, a deployed Agent Engine instance (Lab 2), and the relevant APIs on. This capstone touches several billed services at once — clean up afterward.
• Authored against the docs, not executed live. The Python is written against the official ADK/A2A docs and syntax-checked, not run during authoring. A2A integration helpers and import paths evolve — pin your SDK version and verify.
• SDK-first.

About this series

This is Part 11 — the capstone — of the Gemini Enterprise Agent Platform series. You've built an agent up through grounding, tools, memory, evaluation, safety, governance, and observability, all on Google's managed platform. This final lab connects that managed agent to the open ecosystem: it consumes an MCP server for tools, delegates to a peer over A2A, and exposes itself over A2A so others can call it — the full managed-but-open picture, and the point where this series meets the open-protocol labs.

What you'll build

You'll assemble an Acme Concierge — an orchestrator agent that:

1. Consumes an MCP server for order tools (the server you built in the MCP lab).
2. Delegates to a peer agent over A2A — a returns specialist running elsewhere — using RemoteA2aAgent.
3. Is exposed over A2A itself, so other agents (or partners) can call it, publishing an Agent Card.
4. Runs on Agent Engine — managed hosting underneath, open protocols on the edges.
5. Is discoverable through the registry (from Lab 9).

The result is a managed agent that's a first-class citizen of the open agentic web — it can use, be used by, and be discovered by agents and tools built on entirely different stacks.

Why this matters (the 5-minute business case)

Read this before handing the lab to your team.

The strategic question with any managed platform is: am I building leverage, or building a cage? Managed services are a huge productivity win — that's the whole series — but a managed platform you can't get out of, or that can't talk to anything outside itself, is a liability. The answer isn't to avoid managed platforms; it's to use ones that speak open protocols. This lab is the proof that you can have both.

Three reasons this is a leadership-level concern:

1. Managed *and* open beats choosing one. You get the operational leverage of Agent Engine (no infra, autoscaling, memory, safety, governance, observability — Labs 2–10) and the optionality of open protocols (MCP for tools, A2A for agents, ARD for discovery). You're not betting the company on a single vendor's walled garden.
2. Interoperability is how agents compound. The real value shows up when agents and tools from different teams, vendors, and even organizations can work together. A2A lets your concierge delegate to a specialist built on a different framework; MCP lets it use any compliant tool server. That composability is where multi-agent systems get genuinely powerful.
3. It's your anti-lock-in insurance. Because the agent speaks open protocols at its edges, you can move pieces — swap the host, replace a peer, change a tool provider — without a rewrite. That optionality is worth real money the day a price, a model, or a strategy changes. (This is the control-plane argument made concrete: standardize on the platform, keep the model and the peers replaceable.)

The honest caveats:

• Open protocols don't erase trust boundaries. An agent calling other agents and tools across orgs multiplies the surface area. The identity, egress, and safety work from Labs 8–9 is what makes interop safe — do not skip it because the capstone is exciting.
• More moving parts, more failure modes. A delegated A2A call can be slow or down; a remote MCP tool can change. Build for partial failure (timeouts, fallbacks) the way you would for any distributed system.
• Young, fast-moving glue. A2A integration helpers and import paths shift between SDK versions. Pin and verify.

A framing for a non-technical stakeholder: "We're using Google's managed platform for the heavy lifting, but our agent talks to the outside world in open standards — so it can work with tools and agents from anywhere, and we're never locked in. Maximum leverage, minimum cage."

Concepts you'll use (2-minute primer)

• A2A (Agent-to-Agent) — an open protocol for agents to discover and call each other. An agent publishes an Agent Card (its capabilities and endpoint); callers use it to talk to the agent.
• `RemoteA2aAgent` — the ADK client for a remote A2A agent. Point it at a peer's Agent Card and it handles the handshake, serialization, and JSON-RPC — the peer looks like a local sub-agent.
• `to_a2a` — wraps your ADK agent as an A2A server so others can call it (it serves the Agent Card and endpoint).
• MCP toolset — tools served by an MCP server, consumed by the agent (from Lab 4).
• Agent Engine — the managed host underneath it all (Lab 2); the registry (Lab 9) makes the agent discoverable.

One sentence: MCP brings in tools, `RemoteA2aAgent` brings in peer agents, `to_a2a` exposes you to others, and Agent Engine hosts the whole thing — managed core, open edges.

Prerequisites

Step 1 — Build the orchestrator (MCP tools + an A2A peer)

The concierge uses an MCP server for order tools and delegates returns to a remote specialist agent over A2A:

from google.adk.agents import Agent
from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset
from google.adk.agents.remote_a2a_agent import RemoteA2aAgent
from mcp import StdioServerParameters

# Tools from an MCP server (the one you built in the MCP lab):
order_tools = MCPToolset(
    connection_params=StdioServerParameters(
        command="python", args=["acme_mcp_server.py"]
    )
)

# A peer agent running elsewhere, consumed over A2A via its Agent Card:
returns_specialist = RemoteA2aAgent(
    name="returns_specialist",
    agent_card="https://agents.acme.example.com/returns/.well-known/agent-card.json",
)

concierge = Agent(
    name="acme_concierge",
    model="gemini-3.5-flash",
    instruction=(
        "You are the Acme Concierge. Use your order tools to look up orders. "
        "For anything about returns or refunds, delegate to the "
        "returns_specialist. Be concise and never guess."
    ),
    tools=[order_tools],
    sub_agents=[returns_specialist],
)

In one agent you've now combined two open standards: MCP for tools and A2A for a peer. The specialist could be built on a completely different framework — A2A doesn't care.

Step 2 — Expose the concierge over A2A

So other agents can call your concierge, wrap it as an A2A server. It publishes an Agent Card describing what it can do:

from google.adk.a2a.utils.agent_to_a2a import to_a2a

a2a_app = to_a2a(concierge, port=8001)
# Serve it, e.g.:  uvicorn serve_a2a:a2a_app --host 0.0.0.0 --port 8001
# The Agent Card is then available at /.well-known/agent-card.json

Now the concierge is both a consumer (of MCP tools and the returns peer) and a provider (callable by others over A2A). That bidirectional openness is what lets agents compose into networks rather than silos.

The exact to_a2a import path and signature vary across ADK versions. The shape here follows the docs as of authoring; if it differs, check the ADK A2A docs for your pinned version.

Step 3 — Host it on Agent Engine (managed core)

Deploy the orchestrator to the managed runtime, exactly as in Lab 2 — so the open-protocol agent gets managed hosting, autoscaling, memory, safety, and observability underneath:

import vertexai

client = vertexai.Client(project="your-project-id", location="us-central1")
remote_app = client.agent_engines.create(
    agent=concierge,
    config={"requirements": ["google-cloud-aiplatform[agent_engines,adk]"]},
)
print(remote_app.api_resource.name)

This is the whole thesis in one move: managed underneath, open at the edges. You didn't trade the platform's leverage for openness, or openness for leverage — you have both.

Step 4 — Make it discoverable

Register the concierge in the Agent Registry (Lab 9) so it gets a namespaced URN and shows up in your ai-catalog.json. Now peers don't need a hardcoded Agent Card URL — they can discover the concierge through the registry (the ARD spec), resolve it by URN, and verify it's really yours. Discovery + identity + A2A is what turns a handful of agents into a trustworthy network.

Step 5 — Run the full picture

End to end, a single customer request can now:

1. Hit the concierge (hosted on Agent Engine, callable over A2A).
2. Use MCP tools to look up the order.
3. Delegate the refund to the returns specialist over A2A.
4. Return a grounded, safety-screened, traced answer — with every step observable (Lab 10) and governed (Labs 8–9).

That's a production-shaped, multi-agent, multi-protocol system that's managed where it helps and open where it matters.

Cost & cleanup

This capstone lights up several services. Tear them all down:

• Delete the deployed concierge (Agent Engine, delete(force=True)).
• Stop any local MCP server and A2A server processes.
• Remove the registry entry, egress policy, and test catalog from Lab 9.
• Delete any data stores, corpora, example stores, or Model Armor templates still around from earlier labs.
• Confirm in Billing → Reports that nothing is still accruing.

If a lab created it and you're done, delete it today.

Verified against

• ADK A2A integration (to_a2a, RemoteA2aAgent, Agent Cards), MCP toolset, and the `google-cloud-aiplatform[agent_engines,adk]` SDK, June 2026.
• A2A helper import paths and signatures vary by SDK version; code is syntax-checked against the docs but not executed during authoring. Pin your version.

Series wrap-up

That's the full Gemini Enterprise Agent Platform series — eleven labs from a no-code agent to a managed, open, governed, multi-agent system:

1. Platform tour & Agent Studio · 2. Agent Engine · 3. Grounding · 4. Tools & connectors · 5. Sessions & memory · 6. Example Store · 7. Evaluation · 8. Model Armor · 9. Identity & registry · 10. Observability & cost · 11. this capstone.

Where to go next:

• Coming from the ADK series? You've now seen the managed counterpart of everything you built in code. The two together — open framework, managed platform — are the whole toolkit.
• The protocol series (MCP, A2A, ARD) is the open foundation this platform implements. This capstone is where they meet.
• The strategy behind all of it lives in the articles — start with "Stop Picking a Model. Pick a Control Plane." The labs show you how; that piece argues why.

Build something, measure it honestly, govern it, and keep the edges open. That's the whole game.