Google ADK in Production: A Field Review

The first time I tried to move an ADK prototype from a laptop demo to something I'd leave running unattended, the framework itself was never the problem. The problem was that I had picked up the 1.x mental model just as 2.0 went GA, and half of what the tutorials taught me was now marked deprecated. That tells you something about where ADK is right now: it is moving fast, it is genuinely good, and you need to read the changelog before you trust any blog post, including this one.

Here is what I found building with it, and where I'd pick it over LangGraph or a hand-rolled stack. One caveat up front: I'm describing my own experience and judgment. I'm not going to put invented benchmark numbers on it.

What ADK actually is, and why the version matters

ADK is Google's open-source framework for building agents and multi-agent systems, introduced at Google Cloud NEXT 2025, with a Python 1.0.0 stable release announced at Google I/O 2025. Since then it has grown into a five-language toolkit (Python, Go, TypeScript, Java and Kotlin), each with an MCP client, plus support for the Agent2Agent (A2A) protocol for talking to remote agents.

The part that matters for anyone starting today: ADK Python 2.0 reached general availability on May 19, 2026. In 2.0, agents run as nodes in a Workflow Graph engine, and the 2.0 docs list breaking changes from 1.x. The 1.x line was still receiving patches as of late summer (1.39.1 landed in August), and 2.10.0 was the newest 2.x release I could find on the releases page. Check that page again before you pin a version, because this project ships often.

My practical rule: start new work on 2.x, and treat any tutorial that predates May 2026 as a source of concepts, not copy-paste code. Setup itself is still refreshingly dull:

pip install google-adk

I'm deliberately not stating a minimum Python version. The README and the changelog have disagreed on 3.10 versus 3.11, so read the live README and PyPI metadata for your install.

Tool calling: the docstring is the contract

In ADK, a tool is a plain function, and the model decides when to call it based on the text you write around it. Google's own runtime docs say a tool function needs clear comments describing its parameters, behavior and return value, because the model uses that text to choose which function to call.

I'd go further from experience: this is the single biggest reliability lever in the framework. Most "the agent picked the wrong tool" bugs I've debugged, across ADK and other stacks, were description bugs, not model bugs. A vague docstring is a vague routing rule.

def lookup_invoice(invoice_id: str) -> dict:
    """Fetch one invoice record by its ID.

    Use this only when the user supplies an explicit invoice ID.
    Do NOT use it to search by customer name or date range.

    Args:
        invoice_id: The exact invoice identifier, e.g. "INV-10442".

    Returns:
        A dict with keys "status" ("ok" or "not_found"),
        and on success "amount", "currency", "due_date".
    """
    ...

Three habits that paid off for me:

• State the negative case. "Do NOT use this for X" in the docstring prevents more misroutes than any prompt tweak.
• Return a status field, not exceptions. Let the model see not_found and decide what to do. A raised exception turns into an opaque failure.
• Keep tools narrow. One tool per verb. A tool with a mode parameter is two tools pretending to be one, and the model treats it that way.

MCP support is the other piece worth mentioning. Having an MCP client in every language means I can reuse tool servers I've already built for other agent systems instead of rewriting integrations. For a consultant moving between client stacks, that portability matters more than any single framework feature.

Multi-agent patterns, and the deprecation trap

ADK's multi-agent model has three agent categories: LLM agents, workflow agents (Sequential, Parallel, Loop), and custom agents that inherit from BaseAgent. That taxonomy is clean, and it maps well to how I already think about orchestration: let the LLM decide where judgment is needed, and let deterministic code handle everything else.

Here is the trap. According to the ADK 2.x docs, the legacy SequentialAgent, LoopAgent and ParallelAgent are deprecated in favor of the graph-based Workflow. Worse for anything real-time, LoopAgent and ParallelAgent raise NotImplementedError under run_live(), so they will crash a live session. SequentialAgent still runs in live mode. Meanwhile, the multi-agent docs page and several Google codelabs still teach the three workflow agents as core primitives. The documentation is inconsistent about this, so verify against the current docs page before you design around any of them.

The loop pattern itself is worth understanding even if the class gets replaced. In the Google codelab, a LoopAgent stops when it hits max_iterations or when an agent calls the exit_loop tool. That is exactly the generate, critique, revise shape I use for verification. It maps directly onto the planner, executor, judge flow I've written about before, where a separate judge decides whether work is good enough to stop. Whatever ADK calls the primitive in the version you're on, keep two ideas: a hard iteration cap as a cost ceiling, and an explicit exit signal owned by the critic, not the writer.

My advice on sub-agents: resist the urge to create five of them on day one. Every extra agent is another prompt to maintain, another place for context to leak, and another hop of latency. I add a sub-agent only when a single agent's tool list gets long enough that routing degrades.

A2A: where ADK has a real edge

ADK supports the Agent2Agent protocol natively: it can use a remote A2A agent as a sub-agent and can expose an ADK agent as an A2A agent. Google announced this alongside A2A protocol version 0.3, which added gRPC support and signed security cards.

This is the feature that makes ADK interesting for larger organizations rather than solo builders. A2A was originally developed by Google and donated to the Linux Foundation, and a Technical Steering Committee maintains it with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow. That governance story is what a cautious enterprise buyer wants to hear: the wire protocol is not owned by one vendor's framework.

In practice, the value is boundary clarity. When one team owns the billing agent and another owns the support agent, you do not want them importing each other's Python. You want a network contract. A2A gives you that, and ADK treats it as a first-class citizen instead of an afterthought. I'd still keep A2A for real organizational boundaries. Inside a single service, a function call beats a network hop every time.

Deployment and cost

The ADK README documents two deployment paths straight from the CLI: adk deploy cloud_run and adk deploy docker. For managed hosting, Google Cloud's current docs call the layer Agent Platform Runtime (Agent Runtime) under the Gemini Enterprise Agent Platform name, the product formerly known as Vertex AI Agent Engine. The naming has churned, so search for both names when you read docs.

I run most things on serverless infrastructure that scales to zero, so Cloud Run is the natural fit for me, and the docker path means you are never locked into Google's runtime. I'm not quoting Agent Runtime pricing because I couldn't confirm it from an official Google page, and aggregator numbers disagree. Price it from the source before you commit.

On model cost, the official pricing page lists Gemini 3.8 Flash, 3.7 Flash and 3.6 Flash at introductory pricing of $0.75 input and $3.75 output per 1M tokens through December 31, 2026, rising to $1.50 input and $7.50 output per 1M tokens from January 1, 2027 (source: https://cloud.google.com/vertex-ai/generative-ai/pricing). That doubling is the thing to put in your budget model now. An agent loop that looks cheap in Q4 will cost twice as much in Q1 at the same traffic, and loops multiply token usage because each iteration re-sends context. This is also why that iteration cap matters.

ADK vs LangGraph vs a custom stack

I'll be direct that I'm comparing from experience, not from a benchmark. I did not retrieve LangGraph's current docs for this post, so I'm deliberately not making version, license or feature-parity claims about it. Verify those yourself.

Where ADK wins for me: a Google Cloud shop, a team that spans languages, or an architecture with genuine agent-to-agent boundaries. Where I'd hesitate: highly custom control flow where I want to own every state transition, and any project that cannot absorb a framework that rewrote its orchestration core in 2026. For a handful of simple, long-running workers, a thin custom loop around the model API is still the most boring and most debuggable option, and boring is a feature when nobody is watching the system at 3 a.m.

I'd avoid any claim that one framework simply "cuts build time in half." Those numbers circulate in agency write-ups, and none of them are reproducible. Your build time depends on how well your tool descriptions are written and how clean your boundaries are, not on the logo on the framework.

What I'd do

• Pin the version and read the release notes. ADK 2.x moves quickly. Treat upgrades as a small migration, not a pip install -U.
• Don't build on the legacy workflow agents. Per the 2.x docs they are deprecated, and two of them crash under run_live(). Use the graph-based Workflow for new work.
• Spend your effort on tool docstrings. It is the highest-return hour in the whole project.
• Cap every loop. Set max_iterations, give the critic the exit tool, and put a dollar budget on the whole run, especially with Gemini Flash pricing doubling on January 1, 2027.
• Use A2A only at real ownership boundaries. Inside one service, call functions.
• Run an eval set before you ship. Whatever framework you choose, the thing that makes an agent trustworthy is a repeatable test suite, not the SDK.

If you are weighing ADK against LangGraph or a custom build for a real project, I'm happy to compare notes. You can reach me at lazar-milicevic.com/#contact, or keep reading on the blog for more production agent write-ups.