Agent Development Kit (ADK), A2A, and MCP.

The short version

ADK is a toolkit. You use it to build agents. Think of it like React or Django — a framework for creating things properly.

A2A is a protocol. Agents use it to talk to other agents across different systems, frameworks, and companies. Think of it like HTTP — the universal language that makes everything interoperable.

MCP is a protocol. Agents use it to talk to tools, databases, and APIs. Think of it like USB — one standard connection that works with everything.

ADK — How you BUILD AI agents

ADK stands for Agent Development Kit. It's Google's open-source toolkit for building AI agents.

Google didn't build ADK as a public product first. They built it internally, used it to power their own products like Agentspace and the Customer Engagement Suite, tested it at real production scale, and then open-sourced it. That matters because most AI agent frameworks started as research experiments or side projects that got packaged up and released. ADK was built to run inside Google before anyone outside ever touched it. That's why it's production-grade in a way most frameworks aren't.

The core problem ADK solves is this: before proper frameworks like this existed, most AI agents were essentially prompt scripts. Long, brittle strings of instructions that worked inconsistently, broke when something changed, and were nearly impossible to test or maintain at scale. Engineers hated working with them. They couldn't version them properly. They couldn't write automated tests. They couldn't integrate them into normal deployment pipelines.

ADK changes that entirely. It treats agents like real software. You write your agent logic in code — Python, Java, TypeScript, or Go. You version control it like any other codebase. You write tests for it. You run it through your CI/CD pipeline. You deploy it with a single command to your laptop, a container, or Google Cloud. There's a built-in development UI where you can watch your agents run in real time, trace every decision they made, and debug exactly where something went wrong.

The other major thing ADK handles is multi-agent orchestration. You don't just build one agent — you build systems of agents. Sequential agents that hand tasks off one after another. Parallel agents that work simultaneously on different parts of a problem. Loop agents that keep running until a condition is met. ADK gives you the primitives to compose these into complex, maintainable systems instead of spaghetti logic.

The best analogy for ADK: think of it the way you'd think of React or Django. It's a framework for building things. It doesn't run your agents for you — it gives you the tools and structure to build them properly.

When to use ADK

Use ADK when you are building AI agents from scratch and need them to be maintainable, testable, and scalable over time.

Use it when your team includes engineers who need to work on agent logic the same way they work on any other piece of software — with proper version control, code review, and automated testing.

Use it when you need to orchestrate multiple agents — agents that work in sequence, in parallel, or in loops — and you don't want to build all of that orchestration logic yourself.

Use it when you're planning to deploy agents to production and need reliability. If your agents are going to handle real customer interactions, real business data, or real operational decisions, you need them built on a framework that was designed for production — not a research prototype.

Use it when you need deployment flexibility. ADK is deployment-agnostic. You can run it locally, in Docker, on Google Cloud Run, or on Vertex AI Agent Engine. You're not locked into one cloud or one environment.

Don't use ADK when you need something running in five minutes as a proof of concept with no maintenance requirements. There are faster ways to spin up a demo. ADK is for building agents you intend to actually maintain and scale.

A2A — How agents TALK TO EACH OTHER

A2A stands for Agent2Agent. It is not a toolkit for building agents. It is a communication protocol — a shared language that lets AI agents from completely different systems work together.

Here's the problem it solves. Right now, most companies building with AI are creating agents in isolation. One team builds a customer support agent. Another team builds a data analysis agent. They pay for a SaaS tool that has its own agent built in. They work with a vendor whose system runs its own agents. Every single one of these is an island. They can't talk to each other. They can't hand tasks off to each other. They can't share context without someone building a custom integration from scratch every single time.

As companies build more agents, this fragmentation becomes a real operational problem. You end up with an AI strategy that looks impressive on a slide but functions like a collection of disconnected tools in practice.

A2A solves this at the infrastructure level. It's an open protocol — a standard that any agent, built by any company, using any framework, can implement. Once your agent supports A2A, it can discover other A2A-compatible agents, communicate with them securely, delegate tasks to them, and receive results back — without needing to know anything about how the other agent was built internally.

The scale of adoption here is significant and worth paying attention to. Google launched A2A in April 2025. Within two months it had over 100 companies backing it — including AWS, Microsoft, Cisco, SAP, Salesforce, and ServiceNow. It's now governed by the Linux Foundation, meaning no single company owns it or controls its direction. It's a genuine open standard, not a Google product wearing open-source clothing.

The analogy that makes this click: think of HTTP. HTTP is the protocol that lets any browser talk to any website, regardless of who built the browser, who built the website, or what technology either uses. You don't think about HTTP when you're browsing the internet — it's just the invisible layer that makes everything interoperable. A2A is that layer for AI agents. It's becoming the HTTP of the agent world.

There's also a security dimension worth understanding. A2A is specifically designed so that agents can collaborate without exposing their internal logic, their memory, or their proprietary data to each other. Your agent can hand a task to a partner's agent without that partner seeing how your agent works internally. That's critical for enterprise adoption.

When to use A2A

Use A2A when your agents need to collaborate with agents outside your direct control — agents from vendors, partners, different teams, or different platforms.

Use it when you're building a multi-agent system where different agents are built on different frameworks. If one agent uses ADK and another uses LangChain and a third uses CrewAI, A2A is what lets them talk to each other without custom integration work.

Use it when you need your agents to be composable and replaceable. Because A2A is a standard protocol, you can swap one agent out for a better one without rebuilding all the connections. The protocol stays the same even when the agent changes.

Use it when you're working in an enterprise environment where different teams own different parts of the agent stack and you need them to interoperate securely — without each team needing to expose their internal systems.

Use it when you're thinking long-term about vendor lock-in. Because A2A is governed by the Linux Foundation and backed by AWS, Microsoft, Google, and others, building on it means you're building on a neutral standard rather than betting everything on one vendor's proprietary integration approach.

Don't reach for A2A if you're building a single agent that only needs to work within your own system. If all your agents live in one codebase, talk to your own tools, and never need to collaborate with anything external, A2A adds complexity you don't need yet.

MCP — How agents TALK TO TOOLS and DATA

MCP stands for Model Context Protocol. It's from Anthropic — not Google. Released in late 2024.

MCP is also a protocol, but it solves a completely different problem from A2A. Where A2A is about agents talking to other agents, MCP is about agents talking to tools, APIs, databases, and data sources.

Here's the problem. Every AI agent needs to connect to external resources to be useful. Your customer support agent needs your CRM. Your data agent needs your database. Your research agent needs web search. Your workflow agent needs your internal tools. Without a standard way to make these connections, every agent needs custom integration code for every tool it uses. If you have ten agents and twenty tools, that's potentially two hundred custom integrations to build and maintain. It doesn't scale.

MCP creates one standard connection layer. Instead of building a custom integration between each agent and each tool, you build an MCP server for each tool — once. Then any agent that supports MCP can connect to any MCP server. The connection is standardised. The authentication is standardised. The way data flows back and forth is standardised.

The USB analogy works well here. Before USB, every peripheral device — keyboard, mouse, printer, camera — had its own proprietary connector. You needed a different port for everything. USB created one standard that everything could use. MCP does the same thing for AI agents and their tools. One standard interface that works across everything.

What makes MCP particularly powerful is that it's already been widely adopted. Because Anthropic released it as an open protocol in 2024, there are now MCP servers available for hundreds of tools — databases, file systems, APIs, SaaS platforms, developer tools. The ecosystem built up quickly because the problem it solves is universal. Every team building AI agents runs into it.

MCP also works alongside A2A rather than competing with it. The way to think about it: MCP is the layer that connects agents to resources. A2A is the layer that connects agents to agents. A fully connected agent system needs both.

When to use MCP

Use MCP when your agents need to access external tools, databases, APIs, or data sources — which is almost always.

Use it when you want to avoid building custom integrations from scratch for every tool your agents use. If you're building more than one agent that needs to access the same database or API, MCP saves you from duplicating that integration work across every agent.

Use it when you want flexibility to switch tools without rebuilding your agents. Because the integration is standardised through MCP, you can change the underlying tool — swap one database for another, switch from one API provider to another — without rewriting your agent logic.

Use it when you're working in a team environment where different people own different tools. MCP creates a clean separation: the team that owns the database builds and maintains the MCP server for it. Every agent team consumes it. Nobody needs to coordinate custom integration work across teams.

Use it any time you need your agents to have access to real-time data. Agents using MCP can pull live data from your systems rather than working only with whatever was in their training data or context window.

Don't treat MCP as the answer to agent-to-agent communication. That's A2A's job. MCP handles the resource layer — tools and data. If you find yourself trying to make agents talk to each other through MCP, you're working around a problem that A2A is designed to solve properly.

How all three work together

Here's a real scenario that shows how ADK, A2A, and MCP operate as a complete system.

Say you're a company with a customer support operation, a data team, and a finance function — all running AI agents.

Your support team uses ADK to build their customer support agent. It's written in Python, versioned in GitHub, tested automatically, deployed to Google Cloud with one command. The agent connects to your CRM and your ticketing system through MCP — one standard connection for each tool, reusable across any agent that needs it.

A customer comes in with a complex billing issue. The support agent handles the initial conversation but needs to pull detailed financial data it doesn't have direct access to. Through A2A, it reaches out to the finance team's agent — built by a completely different team on a different framework — delegates that task, and gets the information it needs. The finance agent never exposes its internal data or logic. The support agent never needs to know how the finance agent works. A2A handles the handshake.

Meanwhile, your data team has built their own analytics agent using ADK. It connects to your data warehouse through MCP. When the support agent needs historical customer behaviour data, it delegates that request to the analytics agent through A2A. Three agents, three different jobs, all collaborating seamlessly.

That's what the full stack looks like in practice. ADK builds the agents. MCP connects them to tools and data. A2A connects them to each other.