Google ADK: An Architectural Tour of the Agent Development Kit

Google’s Agent Development Kit (ADK) entered the conversation in 2025 and consolidated in 2026 as the framework Google ships against when it wants to compete with LangGraph and CrewAI on the same axes — but with a deliberately different architectural pitch. Where LangGraph hands you primitives and CrewAI hands you a role abstraction, ADK hands you a runtime: an event-driven engine that orchestrates agents, tools, and persistent state, deployable on Cloud Run, GKE, or your laptop, with bindings in Python, TypeScript, Go, and Java.

This post is the architectural tour. Not “how do I build my first ADK agent” — that’s a quickstart. The question here is what shape of system are you actually adopting when you pick it.

The pitch in one paragraph

ADK is a code-first agent framework with an event-driven runtime, multi-language SDKs, and a tight integration story with Google Cloud (Gemini models, Vertex AI, Cloud Run, GKE, BigQuery, Spanner). The framework treats workflow agents and LLM-driven agents as first-class peers — you can mix deterministic pipelines with adaptive routing, and the runtime owns persistence, tool execution, and observability.

The runtime

The thing to internalize is that ADK is a runtime first, an SDK second. The runtime knows how to:

Receive an event (HTTP, gRPC, queue message, scheduled trigger).
Look up the agent definition and its workflow.
Execute nodes in the workflow, calling LLMs and tools.
Persist state to a configurable store.
Emit telemetry to a configurable sink.

The deploy story is the part that’s underweight in most LangGraph and CrewAI tutorials. ADK was designed assuming you’ll deploy to Cloud Run or GKE. The same agent definition runs locally for dev, and you gcloud run deploy for prod. No separate adapter layer.

Agent kinds

ADK ships several built-in agent classes that compose:

LlmAgent — the basic ReAct-style agent. Has a model, a system prompt, a tool list, and produces output. This is the workhorse.
SequentialAgent — runs sub-agents in order; the output of one is the input to the next. Equivalent to a CrewAI sequential crew.
ParallelAgent — fans out work to sub-agents concurrently; the runtime collects their results. Equivalent to LangGraph fan-out.
LoopAgent — repeats a sub-agent until a condition is met. The condition can be a function or an LLM judge.

from google.adk.agents import LlmAgent, SequentialAgent, ParallelAgent

researcher = LlmAgent(
    name="researcher",
    model="gemini-pro-2.0",
    instruction="Find 5 primary sources on the topic. Cite each.",
    tools=[web_search, arxiv_lookup],
    output_key="brief",
)

writer = LlmAgent(
    name="writer",
    model="gemini-pro-2.0",
    instruction="Using the brief in state['brief'], write a 1200-word article.",
    output_key="article",
)

pipeline = SequentialAgent(
    name="content_pipeline",
    sub_agents=[researcher, writer],
)

output_key="brief" is the small but important detail: the runtime stores the agent’s output in session state under that key, and downstream agents reference it via state["brief"]. State is the contract between agents, not message-passing. (LangGraph users will recognize this as the same idea — typed state shared across nodes — with a different surface.)

Workflow agents vs. routed agents

ADK distinguishes two execution philosophies, and you can mix them inside one system:

Workflow agents — SequentialAgent, ParallelAgent, LoopAgent. Deterministic structure. You know exactly what runs in what order.
LLM-routed agents — an LlmAgent whose tools include other agents. The LLM decides which child to delegate to. Equivalent to CrewAI’s hierarchical process.

triage = LlmAgent(
    name="triage",
    model="gemini-pro-2.0",
    instruction="Read the user request. Delegate to the right specialist.",
    sub_agents=[billing_agent, technical_agent, account_agent],
)

The pattern that ages well is deterministic outer, adaptive inner — a SequentialAgent at the top with three steps (intake → process → finalize), where the middle step is the LLM-routed triage. Predictable shape, flexible content.

Tools and the surface to the rest of the world

ADK exposes three flavors of tools:

FunctionTool — a Python/TypeScript function with a docstring. Same shape every other framework uses.
BuiltInTool — things the runtime provides out of the box: search, code interpreter, Vertex AI extensions.
MCP and A2A — ADK natively speaks Model Context Protocol (for tools) and Agent-to-Agent (for peer agents). Connect to an MCP server and its tools appear; connect to an A2A peer and you can delegate to an agent in another process.

from google.adk.tools.mcp import MCPToolset

toolset = MCPToolset.from_url("https://mcp.acme.internal/billing")
agent = LlmAgent(name="finance", model="gemini-pro-2.0", tools=[*toolset])

The MCP and A2A story is Google’s bet on interoperability. The same agent should be able to consume tools that LangGraph or CrewAI agents expose, and other frameworks should be able to delegate to ADK agents. By 2026 this isn’t aspirational; it’s working in production deployments documented in the joint codelab Google published with Anthropic, LangChain, and CrewAI.

Sessions, state, and memory

ADK manages three layers of agent memory:

Session state — keyed by a session ID, persisted to the configured store (in-memory for dev, Vertex AI Memory or your own GCS/Spanner backing for prod). Survives across runs of the same session.
Memory — longer-lived facts about the user/entity, stored via the Vertex AI Memory service or a custom backend.
Scratchpad — per-turn working memory, ephemeral.

You access state from inside an agent’s instruction template:

instruction = """
You are a billing specialist. The user's account ID is {user_id}.
The pending invoice list is in {invoices}.
"""

The runtime renders the template with the current session state. This is the cleanest way to thread information from one agent to the next — you don’t pass it manually; you write it to state, you reference it in the instruction.

Deployment

This is where ADK earns its keep relative to “framework only” peers. The deployment commands are real:

adk deploy cloud_run --project=my-project --region=us-central1 ./my_agent

That command containerizes the agent (Dockerfile is generated if you don’t have one), pushes the image to Artifact Registry, creates a Cloud Run service, configures session state to use the Vertex AI Memory service, and wires telemetry to Cloud Trace and Cloud Logging. Five minutes from adk init to a public HTTPS endpoint. GKE follows the same pattern with adk deploy gke.

The reason this matters: most agent frameworks treat deployment as the user’s problem. ADK treats it as a first-class capability. That alone is a reason to pick it if you’re a Google Cloud shop.

Observability

Spans and logs land in Cloud Trace and Cloud Logging by default, with OpenTelemetry semantics so you can also point them at Datadog, Honeycomb, or Langfuse. The traces are agent-aware — you see per-agent spans, per-tool spans, and per-LLM spans, with token counts and latencies attached.

When to pick ADK

The honest decision matrix:

You want…	Use ADK
First-class deploy to Cloud Run / GKE	✅
TypeScript or Go or Java agents (not just Python)	✅
Strong default for MCP and A2A interop	✅
Tight integration with Gemini, Vertex AI, BigQuery	✅
Provider neutrality with multiple LLMs out of the box	⚠️ supports it; LangGraph/LangChain has more breadth
The richest checkpoint and human-in-the-loop story	⚠️ LangGraph is more mature
Lightest-weight role-based prototype	⚠️ CrewAI is faster to first draft

ADK is the framework I’d reach for if I were building a multi-language agent platform inside a GCP-heavy organization. It’s the framework I’d skip if my world is AWS + Anthropic and I already have LangGraph fluency.

Next week we go the other direction on the build-vs-buy spectrum — Claude Managed Agents and Amazon Bedrock AgentCore, where the runtime isn’t a library, it’s a managed service.