What Is Google ADK?

// In plain English

Google ADK (Agent Development Kit) is an open-source framework for building, evaluating, and deploying AI agents — everything from a simple personal assistant to a team of specialized agents handling mission-critical business workflows. It was released at Google Cloud NEXT 2025, is available in Python, TypeScript, Go, Java, and Kotlin, and connects natively to Google's Gemini models while also supporting other providers.

The core design idea is that agents shouldn't just be LLM calls in a loop — they should be graphs. ADK lets you compose agents as nodes in a directed graph, where edges represent task flow: run these steps in sequence, fan out to several agents in parallel, or keep looping until a condition is met. You describe that structure in code (or YAML, or a drag-and-drop visual builder), and ADK's runtime executes it reliably.

Here's an everyday analogy. Think of ADK as a stage manager for a theatre production. You define the cast (specialized agents), the script (the workflow graph), and the props (tools). The stage manager — ADK's runtime — coordinates who acts when, passes information between scenes, and makes sure the show ends correctly even if an actor has to improvise mid-scene. You write the script; ADK runs the show.

// Why it matters

Most LLM frameworks started as wrappers around a single chat() call and added multi-agent support as an afterthought. ADK was designed from the start for multi-agent systems at enterprise scale, which leads to meaningfully different defaults and abstractions.

Graph execution beats ad-hoc loops

When you build a multi-step agent with a plain API, you typically write a while loop, check whether the model wants to call a tool, execute it, and loop again. That works fine for one agent doing one kind of task. For a team of agents with branching logic — where step 3 only runs if step 2 returns a certain value, or two research agents run in parallel before a synthesis agent combines their output — an ad-hoc loop becomes unmaintainable. ADK's graph engine makes that structure explicit and testable.

First-class Gemini integration, with model flexibility

ADK is the official Google framework for Gemini, so you get native access to the latest Gemini models (including gemini-2.5-flash) without any adapter glue. But ADK also ships adapters for non-Gemini models — including locally-running models via Ollama and vLLM — so you're not locked in. This positions it as a Gemini-first but not Gemini-only tool.

Production path built in

ADK agents deploy directly to the Gemini Enterprise Agent Platform on Google Cloud, which handles testing, release management, global scaling, and reliability without you managing the underlying infrastructure. For teams already in the Google Cloud ecosystem, this is a shorter path to production than assembling a deployment pipeline from scratch.

Who should care

• Teams standardizing on Google Cloud who want an agent framework with a native Gemini integration and a direct deployment path to Vertex AI / Agent Engine.
• Engineers building complex multi-agent pipelines — research + synthesis + writing teams, document-processing workflows, or parallel analysis jobs — who need the flow control ADK's workflow agents provide.
• TypeScript and JavaScript developers who previously had fewer good choices for agent frameworks and now have a first-party, code-first option.
• Enterprises that want both code and no-code options — ADK supports Python/TypeScript for developers and a visual drag-and-drop builder for teams that want less code.

// How it works

ADK is built around two primary building blocks: agents and workflows. Agents encapsulate a model, instructions, and tools. Workflows are graph nodes that compose agents into a larger execution structure.

The four agent types

• LlmAgent — the foundational type. Takes a model, an instruction prompt, and a set of tools. It reasons step-by-step using function calling and produces a result. This is the building block everything else is made of.
• SequentialAgent — runs a list of child agents one after another, passing state between them. The output of agent N becomes available to agent N+1 through shared session state.
• ParallelAgent — runs multiple child agents at the same time (concurrently), then collects all their results. Ideal for independent research tasks that don't depend on each other.
• LoopAgent — runs a child agent repeatedly until an exit condition is met. Useful for retry logic, iterative refinement, or polling loops.

The Workflow runtime (ADK 2.0)

In ADK 2.0, Google introduced a graph-based Workflow runtime. A Workflow is defined by a list of edges — each edge is a tuple (source, target_1, target_2, ...) that says "after source finishes, run target_1 and target_2 (in parallel if there are multiple targets)". This lets you express arbitrarily complex agent pipelines as a declarative graph rather than imperative control flow.

from google.adk.agents import Agent, Workflow

# Two specialist agents that can run in parallel
research_agent = Agent(
    name="research_agent",
    model="gemini-2.5-flash",
    instruction="Search for information on the given topic and return key facts.",
)

analysis_agent = Agent(
    name="analysis_agent",
    model="gemini-2.5-flash",
    instruction="Analyse the raw facts and identify the three most important trends.",
)

synthesis_agent = Agent(
    name="synthesis_agent",
    model="gemini-2.5-flash",
    instruction="Combine the research and analysis into a concise executive summary.",
)

# Graph: research and analysis run in parallel, then synthesis runs
workflow = Workflow(
    name="research_pipeline",
    edges=[
        ("START", research_agent, analysis_agent),  # fan-out
        (research_agent, synthesis_agent),
        (analysis_agent, synthesis_agent),           # fan-in
    ],
)

Tools and MCP

ADK agents get tools in three ways: plain Python (or TypeScript) functions annotated with a decorator, OpenAPI specs that ADK converts into callable tools automatically, and MCP (Model Context Protocol) servers for connecting to external systems. All three approaches produce tools the LLM can call in exactly the same way, so you can mix them freely.

Session state and context

ADK describes its approach to context as "manage context like source code." Each agent run has a session with shared state that agents can read and write. ADK applies automatic context filtering, summarization, and lazy-loading to stay inside the model's context window on long runs. Token tracking lets you observe cost in real time rather than discovering it after the fact.

// ADK vs Claude Agent SDK: different bets on architecture

Both ADK and the Claude Agent SDK are first-party agent SDKs from major AI labs, but they make different bets about what the hard problem of agents actually is.

The Claude Agent SDK's philosophy is simplicity first: one query() function, a built-in tool runtime that runs on your machine, and a permission model so the agent can safely operate on real files and processes. Its multi-agent support is real but modeled as delegation from a main agent to named subagents — closer to function calls than to a workflow graph.

ADK's philosophy is explicit structure first: you declare the graph of agents upfront, then the runtime executes it. This is a better fit for pipelines where the sequence and parallelism matter (ETL-style, batch processing, multi-stage analysis). It's more boilerplate for a simple single-agent task, but that boilerplate buys you testability and observability on complex workflows.

// Going deeper

Once you're comfortable with the basics, ADK has several advanced features worth understanding before you go to production.

Human-in-the-loop

ADK 2.0's workflow runtime includes human-in-the-loop support: a workflow can pause at a designated node, surface information to a human reviewer, and resume only after explicit approval. This is important for high-stakes pipelines where autonomous execution can't be fully trusted — contract review, medical record triage, financial approvals. It's not bolted on after the fact; it's a first-class workflow node type.

Action confirmations and safety

ADK tools support action confirmations: before a destructive or irreversible tool call executes, the framework can require explicit confirmation from a human or a policy engine. This is ADK's equivalent of the Claude Agent SDK's permission model — a way to enforce a safety boundary around what the agent is allowed to do autonomously. Both frameworks converge on the same idea: unrestricted tool access is the primary risk in production agent systems.

Evaluation

ADK ships built-in evaluation tooling — you define test cases with expected outputs, run the workflow against them, and get pass/fail results plus tracing. This is tighter integration than most frameworks offer and reflects Google's emphasis on "reliable logic" alongside intelligent reasoning. Evaluating LLM-powered workflows is notoriously hard; having it in the SDK rather than as an afterthought helps.

Multi-language and deployment targets

ADK's five language runtimes (Python, TypeScript, Go, Java, Kotlin) all maintain consistent API patterns, which matters for organizations where different teams own different parts of the stack. An orchestrator written in Python can delegate to a Java-based microservice agent. On the deployment side, agents can run locally, in a container, or on the Gemini Enterprise Agent Platform (formerly called Vertex AI Agent Engine) — a fully managed runtime that handles scaling, release management, and global availability.

The open questions

Like every agent framework, ADK inherits the hard open problems of the field: cost control on long autonomous runs, non-determinism in evals, reliable handling of prompt injection from fetched data, and the tradeoffs between a tightly structured workflow graph (predictable, but rigid) and a more open-ended planning loop (flexible, but harder to test). ADK's graph model gives you more control than most frameworks over the first three; the last one remains an active research area regardless of which SDK you use.