Google's Agent Development Kit, and when to reach for it

When Google released the Agent Development Kit (ADK) in April 2025, the framing was unusual for a Google launch. The team explicitly said this is not trying to be the LangGraph of the universe. It is, in their own words, “the same framework powering agents within Google products like Agentspace and the Customer Engagement Suite,” now open-sourced as the SDK Google’s own teams use.

The honest read, a year later, is that they meant it. ADK is smaller than LangGraph, smaller than MAF, smaller than most of its competitors. It does fewer things. The things it does, it does because they map directly to capabilities Gemini and Vertex AI already offer. Outside Google Cloud, ADK is a fine SDK; inside Google Cloud, it is the path of least resistance.

What ADK is, structurally

An ADK agent is a Python (or Java) class that wraps a model, a set of tools, and an optional set of sub-agents. There’s no graph builder, no explicit state machine, no checkpointer concept exposed by default. You declare what the agent can do, and the model decides what to do.

from google.adk.agents import Agent
from google.adk.tools import google_search

root_agent = Agent(
    name="research_assistant",
    model="gemini-2.5-pro",
    instruction="Help the user investigate a topic thoroughly.",
    tools=[google_search],
)

That’s a complete agent. You run it with adk run for a local loop, adk web to get a debugging UI, or adk deploy agent-engine to push it to Vertex AI’s managed agent runtime. The flatness is the design point.

The thing ADK actually does better than the alternatives

If you read ADK’s documentation expecting “LangGraph but Google,” you’ll be disappointed. The thing it does uniquely well is wire Gemini’s native capabilities into agents with no plumbing.

Grounding with Google Search is one line:

from google.adk.tools import google_search

root_agent = Agent(
    model="gemini-2.5-pro",
    instruction="Be accurate. Cite sources.",
    tools=[google_search],
)

This is not a “we wrote a search wrapper” — this is the model invoking Google’s actual search grounding, the same one Gemini uses in its own product, with grounding metadata returned alongside the text. If your agent has to answer questions about the world that changed in the last hour, this is the only frictionless way to do it. LangChain has a Google Search tool too, but the grounding integration is a different class of feature.

BigQuery as a tool is similarly first-class — there’s a bigquery toolset that gives the agent the ability to query datasets in BigQuery with the agent’s service-account permissions. For analytics agents inside a company on GCP, this collapses a multi-day “wire up SQL tool calling” project to a one-line import.

Vertex AI RAG, the Google-managed retrieval service, plugs in the same way. You point at a corpus, the model uses the retrieval as part of its reasoning, and grounding metadata flows back through the agent trace.

The pattern is consistent: anywhere Google Cloud already has a service that an agent would want, ADK gives you a one-line tool that uses it with the proper IAM scoping. That is a non-trivial amount of production plumbing handed to you for free.

Agent Engine is half the value

The Vertex AI Agent Engine is the managed runtime that ADK agents deploy to. Calling it “Cloud Run for agents” is the easiest mental model, but it has a few agent-specific properties that matter:

• Sessions are managed. You don’t run a Postgres for conversation state; Agent Engine handles session persistence and gives you a session ID per user.
• Memory is a first-class concept. Long-term user-scoped memory is a built-in service, not something you build on top of pgvector.
• The runtime scales sessions independently. A long-lived session doesn’t pin a worker — the runtime stitches the conversation across worker processes the way LangGraph stitches it across checkpointed state.
• It speaks A2A. The Agent-to-Agent (A2A) protocol, Google’s open protocol for agents to call each other, is the native inter-agent transport.

Deploy is one command:

adk deploy agent-engine \
  --project=my-gcp-project \
  --region=us-central1

This packages the agent, uploads it, registers it as an Agent Engine resource, and gives you back an endpoint. The first time you do it, you’re surprised it actually works. The second time, you stop being surprised, which is the highest compliment a production deploy story can get.

Where ADK is honestly the wrong choice

The same flatness that makes ADK pleasant on a clean Gemini-and-GCP project becomes a tax in some scenarios:

• You want a portable, model-agnostic framework. ADK supports non-Gemini models (via LiteLLM and direct provider clients), but Gemini-native features — search grounding, multimodal input, caching — are where the productivity comes from. If you’re switching between Claude and GPT on a weekly basis, you’re not getting the ADK premium.
• You need a complex, explicit graph with conditional routing and human approvals across days. ADK’s Workflow agents exist, but the workflow abstraction is less mature than LangGraph’s. If your agent is genuinely a long-running state machine, LangGraph is the honest answer.
• You’re not on GCP. You can run ADK locally and deploy to your own infrastructure, but you’re throwing away most of the value. The pitch is “Agent Engine gives you the runtime”; without Agent Engine, you’ve adopted a small SDK and given up the bigger ecosystem.

A small but realistic example

A research assistant that knows your internal docs and the public web:

from google.adk.agents import Agent
from google.adk.tools import google_search
from google.adk.tools.bigquery import bigquery_toolset
from google.adk.tools.vertex_rag import VertexRagTool

internal_docs = VertexRagTool(
    rag_corpus="projects/my-proj/locations/us-central1/ragCorpora/123",
)

research_agent = Agent(
    name="research_assistant",
    model="gemini-2.5-pro",
    instruction=(
        "Answer questions thoroughly. "
        "Prefer internal docs; fall back to web search. "
        "Cite all sources."
    ),
    tools=[
        google_search,
        internal_docs,
        bigquery_toolset(project="my-proj"),
    ],
)

That’s it. Locally you run adk web to chat with it; in production you adk deploy agent-engine. The agent has structured tool calls, grounding citations, BigQuery access scoped to its service account, and end-to-end traces in Cloud Logging.

To build the equivalent on LangGraph, you’d be writing a search grounding integration, a Vertex RAG retriever, a BigQuery tool, and your own deploy story to Cloud Run with session persistence in Postgres. That is a real week of work versus an afternoon.

What the production stories look like

A useful sample of public deployments:

• Snap has talked publicly about using Agent Engine + ADK for internal agent tooling — their Google Cloud Next 2025 talk walks through the architecture.
• Wells Fargo demonstrated an internal financial-research agent at the same event, using Agent Engine’s memory and grounding features.
• A long tail of GCP-first startups have published smaller case studies on the Google Cloud blog.

The pattern: Gemini-heavy workloads, GCP-native data, organisations that already have an IAM / VPC / billing model on Google Cloud. The adopters look very different from MAF’s adopters (.NET enterprises) or LangGraph’s adopters (Python-heavy AI-native shops). The ecosystems are self-selecting by where the rest of the stack already lives.

When to pick ADK

The simplest rubric:

• You’re already on GCP.
• Gemini’s native grounding, multimodality, or BigQuery integration are load-bearing for your agent.
• You want a managed runtime instead of standing up your own.

If all three are true, ADK is the obvious choice and the deploy story is significantly better than the alternatives. If one or two are true, it’s worth considering. If none are true, you’re better off with something more model-agnostic.

What to take away

ADK is the right shape for what Google is actually trying to do: package the Gemini + Vertex AI advantages into a deployable agent runtime, without inventing a competing framework abstraction. It is deliberately not the Swiss Army knife. It is the most pleasant way to take a Google Cloud-native agent from prototype to production, and that turns out to be a more focused goal than “win the agent framework wars.”

If your stack already lives on GCP, the question isn’t “ADK or LangGraph” — it’s “ADK plus a thin layer of your own orchestration when you outgrow it.” Which is, ultimately, the same trade every framework asks you to make.

---

Further reading: the ADK documentation is the canonical reference. The Vertex AI Agent Engine overview covers the deploy and runtime story. For multi-agent patterns, the A2A protocol spec is worth reading even if you never call it directly.