Google ADK 2.x: Building Production AI Agents with the Agent Development Kit

Everyone is shipping “AI agents”. Most of them are a single prompt in a while loop with a brittle JSON parser taped to the side.

A real agent is different. It plans, it calls tools, it recovers from bad tool output, and it stays observable when something goes wrong in production at 3 a.m. That gap between a demo and a system you can actually operate is what Google’s Agent Development Kit (ADK) was built to close, and ADK 2.0 moved the goalposts: the framework is no longer a hierarchy of agents but a graph engine where agents, tools and plain functions are nodes.

This is the hands-on version, updated for ADK 2.x: what ADK is, how to build and evaluate an agent, what is new in 2.0, what breaks when you upgrade from 1.x, and how it stacks up against LangGraph and CrewAI.

What the Agent Development Kit Actually Is

ADK is an open-source (Apache 2.0) framework for building, evaluating and deploying AI agents. It is available for Python, TypeScript, Go, Java and Kotlin, it is model-agnostic (optimized for Gemini, but it also supports Claude, OpenAI, Gemma, Ollama, vLLM and LiteLLM), and it runs anywhere: your laptop, Cloud Run, GKE or Google Cloud’s managed Agent Runtime.

The mental model is small and worth memorizing:

• Agent: an LLM plus instructions plus a set of tools. The unit you compose everything from.
• Tool: a plain function the agent can call. ADK reads your function signature and docstring to build the schema automatically. It also supports OpenAPI specs and MCP tools.
• Runner: the execution loop that drives the agent: prompt the model, call tools, feed results back, repeat until done.
• Session: the memory and state that persists across turns.
• Workflow (new in 2.0): a graph that connects agents, tools and code as nodes with explicit paths between them.

What Is New in ADK 2.0

ADK Python 2.0 went generally available on May 19, 2026. ADK Go followed on June 30 and ADK TypeScript on August 21. The Python package is now at 2.13.0 (October 23). Three ideas define the release:

• Graph-based workflows. Deterministic code and adaptive AI reasoning in one graph: routing, fan-out and fan-in, loops, retries, state management and nested workflows, with explicit execution paths and predictable outcomes.
• Dynamic workflows. Code-based logic for iterative loops and decision-driven branching that you cannot draw as a fixed graph up front.
• Collaborative workflows. Coordinator agents delegating to sub-agents, with a structured Task API for agent-to-agent delegation, including human-in-the-loop steps.

Two smaller additions matter in practice: a tool confirmation flow that can guard a tool call with an explicit human yes, and Agent Config, which lets you define agents without code.

Build a Real Agent in About 30 Lines

Here is a working agent that does something useful: it answers questions about an order by calling a tool. The tool is a normal Python function with a clear docstring, and ADK turns it into a callable schema for you.

from google.adk import Agent

def get_order_status(order_id: str) -> dict:
    """Look up the delivery status of a customer order.

    Args:
        order_id: The customer-facing order number, e.g. "A-10423".
    """
    # In production this would hit your orders API.
    orders = {"A-10423": {"status": "shipped", "eta": "2026-11-02"}}
    return orders.get(order_id, {"status": "unknown"})

root_agent = Agent(
    name="support_agent",
    model="gemini-3.8-flash",
    instruction=(
        "You are a concise customer-support agent. "
        "When a user asks about an order, call get_order_status and "
        "answer in one sentence. Never invent an order status."
    ),
    tools=[get_order_status],
)

Run it locally with the ADK dev UI and you get a chat window, a live trace of every tool call and the model reasoning, without writing frontend code. ADK 2.x needs Python 3.11 or newer:

pip install google-adk
adk web path/to/agents_dir     # web UI with traces
adk run path/to/support_agent  # interactive CLI

The first time you watch the trace panel show user, model, tool call, tool result, model, answer, the appeal clicks. You are not guessing what the agent did. You can see it.

A Graph Workflow: Deterministic Steps Around Model Calls

A single agent is the start. The new part of ADK 2.0 is the Workflow: you decide the path, and the model only does the fuzzy parts. A two-step flow that extracts an order number and then answers from the tool looks like this:

from google.adk import Agent, Workflow

extract = Agent(
    name="extract_order",
    model="gemini-3.8-flash",
    instruction="Extract the order number from the message. Return only the number.",
)

reply = Agent(
    name="reply",
    model="gemini-3.8-flash",
    instruction="Give a one-sentence delivery update for the order, using get_order_status.",
    tools=[get_order_status],
)

root_agent = Workflow(
    name="support_flow",
    edges=[("START", extract, reply)],
)

The edges are explicit, so the order of steps never depends on what the model feels like doing. From here the docs add routes (conditional edges), fan-out and fan-in, loops, retries and human input as first-class graph features.

Where ADK Pulls Ahead: Tools, Evaluation and Deployment

Three things separate ADK from a hand-rolled agent loop.

Tools are first-class and typed. Your function signature is the contract. No hand-written JSON schemas to drift out of sync with the code. ADK also ships ready-made tools such as Google Search and can wrap other agents as tools.

Evaluation is built in. You define test cases (an input plus the expected tool trajectory and final response) and run them as a suite. This is the part most teams skip and later regret: an agent that worked last week silently breaks when you change a prompt, and an eval set catches it before your users do. The docs also cover user simulation and custom metrics.

adk eval support_agent support_agent/order.evalset.json \
    --config_file_path support_agent/eval_config.json

Deployment is a short hop, not a rewrite. The same agent runs locally, in a container, on Cloud Run or on Agent Runtime, the managed agent service in Google Cloud’s Agent Platform (its docs still live under the Vertex AI Agent Engine path). Agent Runtime is a paid service with a no-cost access tier.

adk deploy docker --with_ui support_agent
adk deploy cloud_run --with_ui support_agent

For a fully configured Google Cloud setup with CI/CD and infrastructure-as-code, the docs describe an Agents CLI path as well.

From One Agent to a Team

The interesting systems are multi-agent: a coordinator that delegates to specialists. An agent can have sub_agents, and the coordinator routes work to them based on their descriptions.

from google.adk import Agent

billing = Agent(
    name="billing",
    model="gemini-3.8-flash",
    description="Answers billing and refund questions.",
    instruction="Answer billing and refund questions.",
)
shipping = Agent(
    name="shipping",
    model="gemini-3.8-flash",
    description="Answers delivery and tracking questions.",
    instruction="Answer delivery and tracking questions.",
)

coordinator = Agent(
    name="coordinator",
    model="gemini-4-argon",
    instruction="Route each request to the right specialist and summarize the answer.",
    sub_agents=[billing, shipping],
)

The coordinator uses a stronger model to reason about routing; the specialists use a cheaper, faster one for the narrow work. That split, smart router and cheap workers, is one of the most effective cost patterns in production agent systems. Keep the model name in configuration, not buried in code, because it will change: what Gemini 4 Argon means for platform teams covers how to route by task class and migrate one rule at a time.

ADK vs LangGraph vs CrewAI

None of these is strictly best. They optimize for different things.

The short version: reach for LangGraph when your problem is really a state machine with tricky branching. Reach for CrewAI when you want a multi-agent demo by lunch. Reach for ADK when the agent has to live in production on Google Cloud, with evaluation, tracing and a managed runtime you are not maintaining yourself. Since 2.0 the old argument for LangGraph (“ADK has no real graph”) is much weaker, because ADK now has graphs too.

Upgrading from ADK 1.x to 2.x

ADK 2.0 is designed to run agents written for 1.x, but the docs list real incompatibilities. Check these before you bump the version in a production project:

1. Events have new fields. Events carry node_info and output. A custom BaseSessionService that stores events in rigid SQL columns must be updated first, or inserts and deserialization fail. Storing events as serialized JSON needs no change. Downstream gateways with strict JSON validation (additionalProperties: false) will reject 2.0 events until their schemas are updated.
2. Custom execution overrides are bypassed. BaseAgent now subclasses BaseNode, and the workflow engine ignores overridden _run_async_impl() or generate_content(). Move custom telemetry or state logic into before-agent and after-agent callbacks.
3. Do not append events yourself. Manually appending to context.session.events or using enqueue_event breaks determinism. Yield events from your node or agent instead.
4. Stop swallowing exceptions in tools. A broad except Exception: hides failures from the new automatic retries (for example RetryConfig(max_attempts=3)), and catching BaseException traps NodeInterruptedError, which breaks human-in-the-loop pauses.

Not ready? Stay on the 1.x line with pip install "google-adk~=1.0" (Python 3.10 or newer), and plan the upgrade with the events and callbacks changes in mind.

The Gemini Enterprise Angle

Building the agent is half the story. The other half is everything around it: connecting it to company data, giving it an identity and scaling it to real users. That is the job of Google Cloud’s managed services (Agent Runtime and the Gemini Enterprise platform) on top of ADK. The point is continuity: the agent you built locally is the same agent you deploy, with enterprise connectors and governance wrapped around it, instead of a prototype you rebuild in another tool.

Summary

The Agent Development Kit is Google’s answer to a real problem: most “agents” are demos, and demos do not survive production. ADK gives you a small set of clean primitives (agent, tool, runner, session), typed tools, a built-in evaluation suite, live local tracing and, since 2.0, a graph workflow engine for the parts of your system that must be deterministic. It also gives you a short path from your laptop to a managed runtime.

If you are choosing a framework today: CrewAI gets you a demo fastest, LangGraph gives you the most control over complex flows, and ADK is the one built to be operated in production on Google Cloud. Pick for where the agent has to live, not just where it has to be born.

If you are building agents, reach out. I am sharing what I build under #GoogleCloud, #GoogleCloudPartners and #GoogleCloudAmbassador.

Sources

• ADK: adk.dev, ADK 2.0 guide and migration notes, adk-python releases
• Deployment: Agent Runtime docs
• Models: Gemini API models