ADK v2 Is a Complete Game Changer — How Google Leapfrogged Every Agent Framework

The Before Times

When Google shipped the Agent Development Kit (ADK) at Cloud Next 2025, the reception was mixed. On one hand: a clean, code-first framework with native MCP and A2A support, four language SDKs, and a frictionless path to Vertex AI. On the other: hierarchical agents and exactly three rigid workflow types — SequentialAgent, ParallelAgent, and LoopAgent.

Everyone asked the same question: "Can it do what LangGraph does?"

The honest answer was no. LangGraph gave you graph-based state machines with conditional routing, cycles, checkpointing, and human-in-the-loop. ADK gave you LLM-driven routing where a parent agent read child descriptions and hoped it picked the right one. Useful for simple delegation, frustrating for anything that needed precision.

That was then.

On May 19, 2026, ADK Python v2.0 shipped GA. ADK Go v2.0 followed on June 30. The headline feature — a graph-based Workflow Runtime — fundamentally changes the calculus.

This is the story of what changed and how ADK v2 now stacks up against every major competitor.

What ADK v1 Gave You

ADK v1's orchestration model was a hierarchical agent tree. A root agent delegated to sub-agents via LLM-driven routing — the parent read each child's description and decided who to call. For execution patterns, you had three primitives:

SequentialAgent  → run agents one after another
ParallelAgent    → run agents concurrently, wait for all
LoopAgent        → repeat until a condition

These worked for straightforward pipelines. But any non-trivial flow — conditional branching, fan-out with result aggregation, retry logic, human handoffs — required you to build it yourself on top of the framework.

# ADK v1 — rigid types, limited control
from google.adk.agents import SequentialAgent, ParallelAgent, LoopAgent

pipeline = SequentialAgent(
    name="research_pipeline",
    sub_agents=[research_agent, analysis_agent, report_agent],
)

The problem wasn't that this was bad. It was that compared to LangGraph's graph-based approach, it felt like coding with one hand tied behind your back. LangGraph let you define any execution topology. ADK gave you three presets.

The v2 Revolution: Workflow Runtime

ADK v2 replaces those three rigid types with a single, composable Workflow class backed by a graph-based execution engine. You define nodes (agents, functions, or tools) and connect them with edges that describe the execution graph. The scheduler handles routing, concurrency, state persistence, retries, and human-in-the-loop.

Conditional Routing

Instead of an LLM deciding which agent runs next, you define explicit routes in code:

# ADK v2 — explicit conditional routing
from google.adk.workflow import Workflow

def router(node_input: str):
    if "urgent" in node_input.lower():
        return Event(route="HANDLE_URGENT")
    return Event(route="HANDLE_NORMAL")

root_agent = Workflow(
    name="support_workflow",
    edges=[
        ("START", classifier_agent, router),
        (router, {
            "HANDLE_URGENT": priority_agent,
            "HANDLE_NORMAL": standard_agent,
        }),
        (priority_agent, escalation_check),
        (standard_agent, response_agent),
    ],
)

No LLM inference for routing decisions. Faster execution, deterministic behavior, fully testable. The edges declaration maps cleanly to a directed graph: (source, target) or (source, {route: target}) for conditional branches.

Fan-Out/Fan-In with JoinNode

Parallel work with result aggregation — something you had to code yourself in v1:

# ADK v2 — proper fan-out/fan-in
from google.adk.workflow import Workflow, JoinNode

join = JoinNode(name="aggregate_results")

root_agent = Workflow(
    name="parallel_workflow",
    edges=[
        ("START", data_fetch_agent, join),
        ("START", sentiment_agent, join),
        ("START", trend_analysis_agent, join),
        (join, report_generator),
    ],
)

Three nodes run concurrently from START. JoinNode blocks until all three complete, then report_generator receives the aggregated output. One constraint: all parallel nodes must produce Event output or the workflow stalls. For batch processing, analysis pipelines, and multi-source research, this pattern alone justifies the upgrade.

Dynamic Workflows with @node

Static graphs handle 80% of cases. For the other 20% — iterative refinement, adaptive loops, runtime-determined branching — ADK v2 adds dynamic workflows using native Python control flow:

# ADK v2 — dynamic workflow with native Python
from google.adk.workflow import node, Context, Workflow

@node(rerun_on_resume=True)
async def code_workflow(ctx: Context):
    code = await ctx.run_node(coder_agent)
    check = await ctx.run_node(linter_agent, code)

    while check.findings:
        yield Event(state={"code": code, "findings": check.findings})
        code = await ctx.run_node(fixer_agent, code)
        check = await ctx.run_node(linter_agent, code)

    return code

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

Write code, lint, fix, repeat — using a while loop. The @node decorator and ctx.run_node() let you compose agents and functions using standard Python async/await. ADK handles checkpointing automatically: if the workflow pauses for human input and resumes, completed nodes are skipped.

Try expressing that in LangGraph's static graph DSL. You can — but it takes a StateGraph, conditional edges with a routing function, and a manual loop counter in state. ADK's version reads like regular Python because it is regular Python.

Side-by-Side: v1 → v2 Migration

The Task API: Delegation With Precision

The second major v2 feature is the Task API, which formalizes agent-to-agent delegation into three explicit modes. ADK v1 only had one mode: hand off to sub-agent and let it talk to the user indefinitely. V2 gives you:

Chat mode (default): The sub-agent gets full user interaction and must explicitly transfer control back. Same as v1.

Task mode: The sub-agent can ask clarification questions but automatically returns when done. Operates in isolated session branches — only sees its own events.

Single-turn mode: One input, one output, no user interaction. Supports parallel execution because multiple single-turn agents can run simultaneously.

from google.adk.workflow.agents.llm_agent import Agent

weather_agent = Agent(
    name="weather_checker",
    mode="single_turn",
    tools=[get_weather, geocode_address],
)

flight_agent = Agent(
    name="flight_booker",
    mode="task",
    tools=[search_flights, book_flight],
)

root = Agent(
    name="travel_planner",
    sub_agents=[weather_agent, flight_agent],
)

The practical value: a weather check and hotel search run in parallel (both single-turn), then hand off to a booking agent (task mode) that can ask date preferences. In v1, the orchestrator handled everything sequentially through LLM routing.

No other framework has this. LangGraph doesn't natively define delegation modes — you build them yourself. OpenAI Agents SDK has handoffs but no concept of task vs single-turn isolation. CrewAI's task delegation is role-based, not mode-based.

vs LangGraph: The Gap Closes

LangGraph has been the gold standard for graph-based agent orchestration. ADK v2 directly challenges that.

Where ADK v2 wins:

Where LangGraph still leads:

The honest take: ADK v2 matches LangGraph on graph capabilities and surpasses it on the Task API, dynamic workflows, and protocol support. LangGraph's maturity advantage will narrow over time. If you're starting a new project today, the gap is small enough that framework choice should be driven by your cloud provider and preferred programming language, not by capability.

vs CrewAI: Different Leagues Now

CrewAI popularized role-based agent teams — "researcher," "writer," "critic" — with a simple task-driven model. Its Flows system (@start/@listen/@router decorators) adds an event-driven graph layer: conditional routing, fan-out/fan-in via or_/and_, state persistence, and a @human_feedback decorator for human-in-the-loop. It's accessible, Pythonic, and has a loyal following.

So why isn't that enough? Because CrewAI Flows, while capable, is a decorator-based abstraction — you compose Python methods and let the framework infer the graph. ADK v2's Workflow class models the graph directly: nodes, edges, and routers are first-class objects you can inspect, test, and debug in isolation.

What ADK v2 gives you that CrewAI cannot:

CrewAI remains a good choice for role-based teams and rapid prototyping. ADK v2 is in a different category — it competes with LangGraph, not CrewAI.

vs OpenAI Agents SDK: Missing the Graph Entirely

The OpenAI Agents SDK (released late 2025) brought guardrails, handoffs, and a clean API to the Python agent ecosystem. It's well-designed for what it does — lightweight agent chains with safety filters.

What it doesn't have: graph-based workflow primitives.

OpenAI's SDK models execution as handoffs and agent-as-tool calls. It ships sessions (state persistence), human-in-the-loop guardrails, and supports parallel agents via asyncio — useful building blocks. What it lacks is explicit graph constructs: no conditional routing primitives, no loops, no join nodes for fan-in, no workflow-level pause/resume checkpointing. Any non-trivial flow topology requires custom orchestration logic on top of handoffs.

ADK v2 offers all of that plus what OpenAI can't replicate: native A2A protocol support (letting your agents talk to non-OpenAI agents), MCP integration, and multi-cloud model support via LiteLLM (200+ models, not just OpenAI).

OpenAI Agents SDK is fine for simple chat-based agents with safety guardrails. ADK v2 handles that use case and every more complex one.

The Board: What No Other Framework Has

ADK v2 is the first agent framework that credibly supports all three orchestration styles:

No other framework covers all three. LangGraph is strong on #2, weaker on #1 and #3. CrewAI covers #1 and #2 but not #3. OpenAI SDK only covers #1.

This matters because real applications don't fit one paradigm. A customer support agent might use LLM routing for intent classification (style 1), a deterministic workflow for refund processing (style 2), and a dynamic loop for iterative troubleshooting (style 3). ADK v2 lets you mix all three in a single application.

Migration Strategy

If you're on ADK v1, migration is incremental:

1. Keep your agents as-is. LlmAgent definitions with MCP tools and A2A connections work unchanged.

2. Replace `SequentialAgent` with `Workflow` edges when you need conditional routing or fan-out.

3. Replace `ParallelAgent` with `JoinNode` patterns when you need result aggregation.

4. Add Task API modes to sub-agents that currently rely on LLM-driven routing.

5. Use `@node` dynamic workflows for iterative processes that were awkward with LoopAgent.

The v1 types still work in v2. You don't need to rewrite everything at once.

Breaking changes to watch:

The Bottom Line

ADK v1 was a solid framework with a critical gap — no graph-based workflow control. v2 closes that gap and adds capabilities (Task API, dynamic workflows, native MCP/A2A) that no competitor matches.

The framework landscape for 2026 looks like this:

The calculus that led teams to pick LangGraph over ADK in 2025 no longer holds. The question isn't "does ADK have graph workflows?" anymore. It's "what else do you need that ADK v2 doesn't already have?"

Full source and samples at github.com/google/adk-python and github.com/google/adk-go. Docs at adk.dev.

_Check more open source repos at: github.com/mnkrana/_