Cover image showing AI agents communicating across cloud platforms via the A2A protocol, with interconnected nodes representing Google ADK, LangGraph, and Claude frameworks

This is Part 3 of a 3-part series on Google ADK.

In Part 1, we build a single agent with tools locally. In Part 2, we orchestrate multi-agent workflows. In Part 3 (this article), we ship to production and connect agents across frameworks via A2A.

Series links:

• Part 1: Google ADK Deep Dive: Building Your First Agent
• Part 2: Google ADK Deep Dive: Multi-Agent Orchestration with ADK
• Part 3 (this): Google ADK Deep Dive: A2A, MCP, and Production Deployment
• Skillzwave: skillzwave.com

<aside> 💡

TL;DR: Deploy Google ADK agents to production using Vertex AI Agent Engine or Cloud Run. Use the A2A protocol (now at v1.0.0) for agent-to-agent interoperability across frameworks. MCP and A2A are complementary, not competing: MCP gives agents tools, A2A gives agents colleagues. Cross-framework communication between ADK, LangGraph, and Claude agents works today with some rough edges.

</aside>

Your agent is stuck on your laptop.

This article turns it into a production service and makes it interoperable: MCP gives it tools, and A2A gives it peers — so it can collaborate with agents built in other frameworks.

In Part 1, we built an ADK agent locally. In Part 2, we orchestrated multiple agents. Now we ship: deploy to Cloud Run or Agent Engine, then connect ADK ↔ LangGraph ↔ Claude-powered agents over A2A.

The A2A Protocol: Turning Agents into Services

Every web service needs a way for clients to find it, understand what it does, and call it. Why should agents be any different?

The Agent-to-Agent (A2A) protocol, launched by Google in April 2025 and now governed by the Linux Foundation at v1.0.0, answers that question. Over 50 partners have signed on: Salesforce, SAP, ServiceNow, Atlassian, LangChain, and a who's who of enterprise tech. Even the big system integrators (Accenture, Deloitte, McKinsey, PwC) are on board, which tells you something about where enterprise agent architecture is heading.

Think of A2A as HTTP for agents. It gives agents a standard way to advertise their capabilities, discover other agents, and delegate tasks across network boundaries. No custom integration required.

Agent Cards: The Business Card for Your Agent

Here’s a minimal agent-card.json-style example you can use as a starting point (trimmed to the essentials):

{
  "name": "research-agent",
  "description": "Performs deep technical research",
  "url": "https://REPLACE_ME.run.app",
  "version": "1.0.0",
  "skills": [
    {
      "id": "technical-research",
      "name": "Technical Research",
      "description": "Research a topic and return findings",
      "inputModes": ["text"],
      "outputModes": ["text"]
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

An Agent Card is a JSON document that tells the world what your agent can do. It lives at a well-known endpoint, just like robots.txt for web crawlers or openapi.json for REST APIs.