Google’s Agent Development Kit gives developers a cleaner way to build multi-agent AI

Google has a new pitch for developers tired of stitching together agent demos from half a dozen frameworks: use its Agent Development Kit, or ADK, and keep the system in one place.

That pitch lands because agent tooling has been messy for a while. LangChain, LangGraph, LlamaIndex, CrewAI, homegrown orchestration code, custom tool wrappers, random state stores. Once teams move past a toy chatbot, they usually end up rebuilding the same plumbing: session management, tool calling, workflow control, sub-agent routing, and guardrails that hold up in production.

ADK packages those pieces into a single developer kit. The headline features are familiar: multi-agent orchestration, model-agnostic execution, built-in tools, session state, safety hooks, and support for an open agent-to-agent protocol meant to let different systems talk to each other.

Google isn’t early here. Every major player has some kind of agent framework. What stands out is that ADK seems aimed at the parts teams actually struggle with.

Where ADK looks useful

A lot of agent frameworks still feel like prompt engineering wrapped in Python classes. Easy to demo. Irritating to run at scale. The problems show up later:

• how agents hand work to each other
• how state survives beyond one request
• how tools are exposed safely
• how loops and retries are controlled
• how to mix models from different vendors without rewriting the app
• how to connect to enterprise systems that already exist

ADK goes straight at those problems.

Google describes it as multi-agent by design, and that matters. Plenty of frameworks can support multiple agents if you force the issue. ADK appears to treat delegation and orchestration as core concepts. That fits real systems better, where you may want a planner, a tool-using worker, a reviewer, and some bounded logic around all of it.

It’s also model-agnostic, at least in the way developers usually care about. You can use Gemini, but Google also points to support for models from OpenAI and Anthropic. That’s practical, not ideological. Teams switch models for cost, latency, task fit, or policy reasons. A single-vendor stack sounds fine until finance or legal starts asking questions.

The API is simple enough, which helps

The entry point is minimal:

from adk.agent import Agent
from adk.tools.google import GoogleSearchTool

agent = Agent(
name="QuestionAnswerAgent",
model="gemini-2.5-flash",
description="A helpful assistant capable of answering questions using Google Search.",
instruction="Respond to user queries using the Google Search tool.",
tools=[GoogleSearchTool()]
)

That’s about the right level of abstraction for an SDK like this. Define an agent, assign a model, give it tools, set instructions. Developers shouldn’t have to wire up half the runtime just to test a basic workflow.

The harder question comes after hello world.

If ADK’s runtime can handle tool invocation, message flow, session state, and delegation without becoming opaque, that’s where it gets interesting. Frameworks in this category usually fail one of two ways. They’re so thin that orchestration complexity falls right back on the developer, or they hide too much and become miserable to debug. Google has to avoid both.

Multi-agent orchestration is the main draw

The sample weather bot is simple, but it points to the architecture Google wants people to build: one coordinating agent, several specialized sub-agents, and explicit routing rules.

A stripped-down version looks like this:

def get_weather(city):
weather_db = {"Toronto": "Partly cloudy, 30°C"}
return weather_db.get(city, "Error: City not found.")

weather_agent = Agent(
name="WeatherAgent",
model="gemini-2.5-flash",
description="Main agent coordinating weather queries.",
instruction="Provide weather information or delegate greetings/farewells appropriately.",
tools=[get_weather],
sub_agents=[greeting_agent, farewell_agent]
)

That pattern will be familiar to anyone building production agents. One model shouldn’t do everything. Narrower responsibilities are easier to reason about, especially when tools or policies differ by task. A greeting handler doesn’t need database access. A data analysis agent probably shouldn’t be allowed to send outbound email. That separation improves quality and limits blast radius.

ADK also supports sequential, parallel, and loop-based workflows. That matters because it’s usually the point where prompt chains stop being enough. Once you need fan-out, retries, review steps, or iterative tool use, ad hoc code gets ugly fast.

There’s a trade-off, though. Multi-agent systems are often overbuilt. Split one request into four model calls and two tool calls, and the architecture diagram looks impressive while the user gets a slow app. If ADK makes multi-agent design easy, teams will still need the discipline to use one agent where one agent is enough.

Session state helps, and it brings the usual problems

Google’s session state model sounds reasonable: a persistent dictionary tied to a user session. That gives developers a clear place to store preferences, prior outputs, intermediate work, and conversation context.

That’s standard for any serious assistant. Without memory, the agent feels stateless and forgetful. With memory, it can carry context across a multi-step task, personalize responses, and stop asking for the same information twice.

This is also where production headaches start.

Stateful agents are harder to reason about, harder to test, and easier to poison with bad data. If a tool returns garbage and that output gets written into session memory, the system can quietly build on the mistake for the rest of the interaction. Enterprise teams also have to worry about retention rules, PII, auditability, and tenant isolation. “Persistent session state” sounds great right up to the moment someone asks where it lives and who can inspect it.

Google does have an advantage here. If ADK connects cleanly to the company’s cloud stack, teams get a path to managed storage, observability, and deployment instead of bolting those on later.

Guardrails need to go deeper than demos

Google says ADK includes safety guardrails and callbacks that can intercept or shape agent behavior before output reaches the user. Good. That should be standard now.

The question is how far those controls go. Serious deployments need more than a profanity filter or a lightweight moderation check. They need controls around tool permissions, data exfiltration, prompt injection, human approval thresholds, and logging that can survive compliance review.

Tool-using agents widen the attack surface. A plain chatbot can hallucinate. An agent with search, database access, and external APIs can hallucinate while taking action. That’s a different class of problem.

If ADK gives developers hooks deep enough to inspect intermediate reasoning steps, tool arguments, and delegation decisions, that’s useful. If the safety model mostly sits at the final output layer, it’ll be too shallow for a lot of enterprise work.

The protocol may outlast the SDK

One of the more interesting pieces here is Google’s open-source Agent-to-Agent Protocol, meant to let agents built on different frameworks interoperate. Less flashy than a model demo, probably more important.

Most companies aren’t starting from zero. They already have LangGraph workflows, internal orchestration layers, domain-specific services, maybe a CrewAI experiment that somehow made it into production. Rewriting all of that just to adopt Google’s framework won’t happen.

A common protocol lowers the switching cost. It also makes the enterprise story more believable: keep the systems you already have, expose them as agents or services, and let ADK coordinate where it actually adds value.

Google says more than 50 partners support the protocol, including MongoDB, Neo4j, Accenture, and Deloitte. Some of that is ecosystem signaling. Big vendor lists always are. Still, protocol support matters if it cuts down on bespoke integrations and glue code.

The open question is whether this becomes a real interoperability layer or another “open” standard that works best inside one vendor’s orbit. The idea is solid. Adoption will decide it.

The data science use case is obvious

Google’s sample use cases point to a pretty clear sweet spot: multi-agent systems for analytics and ML operations.

The examples include:

• a database agent that queries BigQuery using natural language
• a data science agent that runs Python for analysis and visualization
• a machine learning agent that ties into Vertex AI for training and inference

That stack makes sense. Data workflows already involve staged reasoning, tool use, and role separation. One component fetches data, another cleans or analyzes it, another handles modeling, and a supervising layer decides what happens next.

For teams already on Google Cloud, ADK could work well as the glue between conversational interfaces and existing data infrastructure. That’s where the product looks strongest. A general-purpose agent story is easy to claim. Wrapping enterprise tools in an orchestrated AI layer without inventing the control plane from scratch is a lot more useful.

What technical teams should watch

ADK looks promising, but the buying criteria are straightforward.

Watch for:

• observability: Can you inspect traces, tool calls, state changes, and routing decisions?
• runtime control: How much logic can be deterministic instead of left to the model?
• portability: How real is the model-agnostic story once the app gets complex?
• security: Can tool permissions, memory boundaries, and approval flows be enforced cleanly?
• latency and cost: Does the framework help manage them, or just make expensive patterns easier to write?

Google has the right ingredients. The SDK surface looks clean. The protocol story is smart. The support for multi-agent workflows, memory, and tools maps to real pain points.

Now it has to hold up under normal enterprise abuse: feature creep, policy exceptions, and cost dashboards that keep getting worse. If ADK stays legible there, it’ll be worth taking seriously.