Google ADK 2.0: Graph Workflows Ship, LangGraph Has a Fight

Google shipped ADK 2.0 at I/O last week with a feature that changes the conversation: a graph-based workflow runtime. For the past year, the main reason developers chose LangGraph over Google’s Agent Development Kit was control — LangGraph gave you explicit state machines with deterministic routing; ADK gave you LLM-directed delegation that worked great until it didn’t. That gap has closed. ADK 2.0’s Workflow Runtime brings the same graph-based execution model, backed by native A2A protocol support and Google Cloud integration that LangGraph can’t match. The catch? If you’re on ADK 1.x, there are four breaking changes waiting for you.

From Trees to Graphs: What Actually Changed

ADK 1.x modeled agents as a hierarchical tree. A root LlmAgent would delegate to child agents in a top-down chain — simple to reason about, but brittle for anything requiring parallel execution, retry logic, or conditional branching. ADK 2.0 replaces this with a graph execution engine where every Agent, Tool, and Function is a node in a directed graph.

The new Workflow class makes the structure explicit:

from google.adk import Agent, Workflow

fetch_agent = Agent(
    name="fetch_agent",
    model="gemini-2.5-flash",
    instruction="Fetch and return the raw content from the given URL.",
)

summarize_agent = Agent(
    name="summarize_agent",
    model="gemini-2.5-flash",
    instruction="Summarize the provided text concisely.",
)

root_agent = Workflow(
    name="root_agent",
    edges=[("START", fetch_agent, summarize_agent)],
)

For pure Python function nodes, the @node decorator bypasses the LLM overhead entirely. Parallel execution drops to standard asyncio:

tasks = [ctx.run_node(worker_node, item) for item in items]
results = await asyncio.gather(*tasks)

This isn’t a UI-level change — it’s the framework’s execution model, rebuilt from the ground up. You get routing, fan-out/fan-in parallelism, retry policies, and human-in-the-loop pauses as first-class primitives. Things that were workarounds in ADK 1.x are now the default way to build.

Four Breaking Changes That Will Bite You

ADK 2.0 is backwards-compatible with ADK 1.28+ sessions (extra fields get ignored), but the code migration has four landmines worth knowing before you start.

• Event schema. Two new fields — node_info and output — appear on Event objects. If you’re running a custom BaseSessionService with a rigid database schema, that schema needs updating before you deploy. JSON-blob storage sidesteps this in most cases.
• BaseNode subclassing. Agents now subclass BaseNode. If you’ve overridden _run_async_impl() in custom agents, those overrides are silently ignored by the new engine. Your code will compile and run — it just won’t do what you expect. Migrate to the callback-based patterns instead.
• Event handling. The old pattern of directly appending to context.session.events breaks graph determinism. The new engine needs strict control over event emission. Use yield from within your nodes.
• Exception handling. Broad except Exception blocks disable ADK 2.0’s automatic retry mechanism. Worse, catching BaseException traps NodeInterruptedError, which breaks human-in-the-loop entirely. Narrow your exception handlers and let the framework see what it needs to see.

The migration order: update session DB schema, replace _run_async_impl() overrides with callbacks, switch events.append() to yield, audit exception handlers. Do this before writing any ADK 2.0 sessions to a shared database — the format mismatch will cause validation failures.

ADK 2.0 vs LangGraph: An Honest Take

ADK 2.0 is now architecturally competitive with LangGraph for production agent systems. That said, “competitive” is not “ahead.”

LangGraph still holds real advantages: 24,600+ GitHub stars to ADK’s 13,100, a 10.6M monthly PyPI download rate versus ADK’s 1.2M, and an ecosystem built on years of LangChain integrations. LangSmith’s observability tooling is particularly strong for teams with regulatory requirements. If you’re on AWS or Azure and deeply embedded in LangChain, the practical switching cost is high.

ADK 2.0’s real edge is different. It’s the only agent framework with first-class support for both A2A and MCP protocols simultaneously. For teams building systems where agents need to call agents across organizational boundaries — or where mobile agents (Kotlin support is new in 2.0) need to coordinate with backend Python agents — ADK 2.0 has no equivalent. The OpenTelemetry-based observability also means you’re not locked into a proprietary monitoring stack.

Feature	ADK 2.0	LangGraph	CrewAI
Architecture	Graph nodes	State machine	Role-based
Learning curve	Medium	High	Low
GCP integration	Native	None	None
A2A protocol	Native	Third-party	Basic
MCP support	Native	Via LangChain	Basic
GitHub stars	13.1K	24.6K	45.9K
Best for	GCP + A2A	Complex workflows	Fast prototyping

The decision isn’t complicated: if you’re on GCP or building A2A cross-agent systems, ADK 2.0 is the right choice now. If you’re on AWS/Azure and already invested in LangChain, LangGraph still wins on ecosystem.

The Google Credibility Problem

Something worth naming directly: developers don’t fully trust Google to maintain developer tooling. Gemini CLI is being sunsetted in June. Antigravity has been renamed twice in six months. The pattern of launch-rename-sunset is etched into the community’s memory.

Two things push back on that here. First, ADK 2.0 is Apache 2.0 licensed and fully open source — even in the worst-case scenario of Google pulling support, the codebase doesn’t disappear. That’s meaningfully different from a proprietary service getting shut down. Second, the GA label at I/O — not preview, not alpha, GA — alongside Kotlin language support and Vertex AI integration is the kind of commitment signal that goes beyond a quick announcement.

That doesn’t mean trust is fully restored. It means ADK 2.0 has earned a closer look.

Should You Migrate?

If you’re starting a new project: use ADK 2.0 directly, especially on GCP. No migration cost, full access to the graph runtime from day one.

If you have a working ADK 1.31.x production system: assess whether you actually need what 2.0 provides. The graph-based engine matters when you hit the complexity wall — parallel execution requirements, sophisticated conditional routing, deterministic HITL flows. If your system isn’t there yet, stable 1.31.x will serve you fine while the 2.0 ecosystem matures.

For teams evaluating agent frameworks from scratch: ADK 2.0 belongs in your shortlist alongside LangGraph and CrewAI. The comparison is no longer “mature framework vs. Google experiment.” It’s a real three-way evaluation based on your infrastructure, protocol requirements, and use case. Start with the official ADK 2.0 docs and set aside an afternoon to prototype. The framework has come far enough that you’ll have a working agent before the day is over.