Google ADK: The Agent Development Kit with A2A

// In plain English

An AI agent is a language model wrapped in a loop: it reads a goal, decides on an action, calls a tool, looks at the result, and repeats until the job is done. Writing that loop from scratch — wiring up tool calls, conversation state, retries, logging — is fiddly and easy to get wrong. Google ADK (Agent Development Kit) is an open-source framework that hands you the loop and the plumbing so you can focus on what your agent should actually do.

Think of it like a kitchen that comes fully fitted out. You could buy a bare room and install your own stove, sink, and wiring (that is building an agent by hand). Or you could move into a kitchen where the appliances are already plumbed in and you just decide what to cook. ADK is the fitted kitchen: agents, tools, a runner that drives the conversation, sessions that remember state, and built-in evaluation are all there from day one.

The piece that makes ADK stand out is the front door it builds for every agent. It ships first-class support for A2A — the Agent2Agent protocol — a shared language that lets one agent talk to another, even an agent written by a different team in a different framework. So ADK is not only a kit for building one agent; it is built from the start for agents that work together.

// Why it matters

Most agent tutorials stop at a single agent calling a couple of tools. Real systems rarely stay that small. You end up wanting a research agent, a coding agent, and a planning agent — and you want them to cooperate without you re-inventing the wiring each time. ADK plus A2A targets exactly that messy middle.

• Less boilerplate, more agent. The runner, session memory, tool calling, streaming, and tracing come built in. You describe the agent's job and tools; ADK runs the loop and keeps the conversation state for you.
• Model- and deployment-agnostic. ADK is designed not to lock you to one model or one host. It integrates cleanly with Google's stack (Gemini, Vertex AI) but is built to run other models and deploy to other places too, so it is a framework choice, not a vendor cage.
• Multi-agent is a first-class idea, not a hack. Instead of bolting coordination on later, ADK lets you compose agents — one agent can delegate to a sub-agent — and expose any agent over A2A so other systems can call it.
• Cross-vendor interoperability. Because A2A is an open protocol, an ADK agent can call (or be called by) an agent built in a different framework entirely. That matters when no single team owns every agent in a workflow.
• Multi-language. ADK began in Python and has grown beyond it, so teams that do not live in Python can still use the same agent model and the same A2A wire format.

Who should care? Anyone moving past a demo toward a system of cooperating agents — especially if those agents are owned by different teams or vendors. If you only ever need one self-contained agent, a lighter provider agent SDK may be plenty. The moment you need agents to talk to each other across boundaries, the A2A part of ADK starts paying for itself.

// How it works

ADK is built from a few core pieces that fit together the same way every time. Once you know the four nouns — agent, tool, runner, session — most of the framework makes sense.

Agents, tools, and the runner

An agent is mainly an LLM plus an instruction (what its job is) plus a list of tools it is allowed to use. A tool is just a function with a clear name and description; ADK shows those descriptions to the model, and the model decides when to call one. The runner is the engine that actually executes the loop: it sends the prompt to the model, sees that the model asked to call a tool, runs the tool, feeds the result back, and keeps going until the agent produces a final answer. The session holds the running conversation and any shared state across those turns.

Multi-agent: agents as tools

Here is the move that unlocks multi-agent systems: in ADK, an agent can be a tool of another agent. A top-level coordinator agent can hold specialist sub-agents (say a researcher and a writer) and delegate to them the way it would call any other tool. The coordinator decides which specialist to hand the sub-task to, collects the result, and continues. This is composition, not a separate framework — the same agent/tool/runner model nests inside itself.

Where A2A comes in

Sub-agents living in the same program is the easy case. The hard case is an agent on another machine, owned by another team, maybe written in another framework. That is the problem A2A solves. A2A is an open protocol that defines how agents discover and call each other over the network. Each A2A-capable agent publishes an agent card — a small machine-readable document advertising its name, what it can do, and its endpoint. A client agent reads the card, sends a task, and receives results (including streaming updates) over a standard HTTP-based interface.

The key idea: ADK lets you expose any agent over A2A and consume remote A2A agents, both with little extra code. Because the protocol is shared and open, the agent on the other end does not have to be an ADK agent at all — it just has to speak A2A.

// A coordinator with a remote specialist

Here is the shape of a small ADK setup in Python: one agent with a local tool, plus a coordinator that delegates to a remote agent reached over A2A. The exact API surface evolves, so treat this as the mental model, not copy-paste-final code.

from google.adk.agents import Agent

def get_weather(city: str) -> dict:
    """Return the current weather for a city."""
    # In real life this calls a weather API.
    return {"city": city, "temp_c": 21, "sky": "clear"}

weather_agent = Agent(
    name="weather_agent",
    model="gemini-2.5-flash",
    instruction="Answer weather questions. Use the get_weather tool.",
    tools=[get_weather],
)

The function's name, type hints, and docstring are what the model reads to decide when to call it — so write that docstring as if it were documentation for the model, because it is. Now a coordinator that treats a remote agent as one of its options:

from google.adk.agents import Agent
from google.adk.agents.remote_a2a_agent import RemoteA2aAgent

# A specialist running somewhere else, exposed via its A2A agent card.
research_agent = RemoteA2aAgent(
    name="research_agent",
    agent_card="https://research.example.com/.well-known/agent-card.json",
)

coordinator = Agent(
    name="coordinator",
    model="gemini-2.5-flash",
    instruction=(
        "Plan the task. Use weather_agent for weather, "
        "and research_agent for anything needing web research."
    ),
    sub_agents=[weather_agent, research_agent],
)

From the coordinator's point of view, research_agent is just another sub-agent — it does not care that the work happens on a different server in a different framework. That sameness is the whole payoff: local composition and remote delegation use the same model.

// ADK vs other ways to build agents

ADK is one of several provider-backed kits. The honest summary: pick based on which model and ecosystem you are anchored to, and whether you need cross-agent interoperability out of the box.

These are not strict rivals. A2A is the thing that lets them coexist: an ADK coordinator can call a LangGraph agent or an OpenAI-SDK agent as long as that agent is exposed over A2A. The protocol is the bridge between framework islands. For a fuller side-by-side, see the provider agent SDK comparison.

// Common pitfalls

• Reaching for A2A too early. If all your agents live in one process, plain sub-agents are simpler than a network protocol. Use A2A when agents genuinely live in separate services or are owned by different teams — not for in-process calls.
• Vague tool descriptions. The model picks tools from their names and docstrings. A tool called do_stuff with no description will be called at the wrong times. Treat each tool description as a prompt the model must understand.
• Confusing ADK with A2A. ADK is the kit; A2A is the protocol. You can use ADK without exposing anything over A2A, and you can speak A2A from a non-ADK agent. Mixing them up leads to wrong design decisions.
• Assuming remote agents are trusted. An A2A agent is a network service. A remote response is untrusted input that can carry instructions aimed at your model. Validate and fence what comes back, the same way you would treat a web page pulled into a prompt.
• Forgetting state lives in the session. Tool functions are usually stateless. If two turns need to share data, it belongs in the session state, not in a global variable you hope survives.

// Going deeper

Once the agent/tool/runner model and A2A click, a few deeper themes are worth knowing.

Evaluation is part of the kit. Agents are hard to test because their behavior is non-deterministic — the same prompt can take different paths. ADK includes evaluation tooling so you can score not just the final answer but the trajectory (which tools were called, in what order). Building this evaluation habit early is what separates a demo from a system you can change without fear.

Streaming and long-running tasks. Agents can take a while, and A2A is designed for that: tasks can stream partial updates back to the caller rather than blocking on one final response. This matters for user-facing agents where you want to show progress, and for agent-to-agent calls where one agent waits on another's slow work.

The agent card as a contract. An agent card is more than an address — it is a published description of capabilities. As fleets of agents grow, discovery (finding the right agent for a task) becomes its own problem, and machine-readable cards are how an ecosystem of cross-vendor agents stays navigable instead of becoming a tangle of hard-coded URLs.

Deployment-agnostic by design. ADK integrates tightly with Google's hosting (Vertex AI Agent Engine, Cloud Run) but does not require it. The same agent definition can run locally for development and be deployed elsewhere, which keeps the framework decision separate from the hosting decision.

Where to go next. If you have not yet, read the foundational what is an AI agent to ground the loop concept, then MCP for the tools-and-data half that pairs with A2A. The durable lesson: ADK gives you a clean way to build one agent, but its real bet is that the future is many agents cooperating — and A2A is how it makes that bet concrete.