DEV Community: Daathwi Naagh

Google ADK vs LangGraph — The Definitive Comparison for Agent Builders

Daathwi Naagh — Fri, 10 Apr 2026 01:11:39 +0000

Choosing the wrong framework doesn't just slow you down. It shapes every architectural decision that follows. Here's how to get it right.

Why This Decision Matters More Than You Think

The agent framework you pick isn't just a tooling choice. It determines:

How you model state and orchestration
How you debug when things go wrong in production
What cloud infrastructure you're implicitly committing to
How fast your team can move from prototype to deployment

Both LangGraph and Google ADK are serious, production-capable frameworks. But they have fundamentally different philosophies — and that gap matters enormously depending on what you're building.

Let's go deep.

At a Glance

Dimension	LangGraph	Google ADK
Released by	LangChain Team	Google (Google Cloud NEXT, April 2025)
Core philosophy	Graph-based state machines	Code-first, hierarchical agent trees
Abstraction level	Low-level, explicit control	Higher-level, batteries-included
Model support	Fully model-agnostic	Optimized for Gemini, but model-agnostic
Cloud tie-in	Deploy anywhere	Native Vertex AI / GCP integration
Learning curve	Medium–High	Medium
Best for	Precision, auditability, complex flows	Speed, multi-agent systems, GCP environments
Observability	LangSmith / Langfuse	OpenTelemetry-native
State management	Built-in checkpointing + time travel	Session state with pluggable backends
Streaming	Per-node token streaming	Bidirectional audio/video + text (Gemini Live API)
Production maturity	High (battle-tested)	Early–Medium (growing fast)

Philosophy: Where They Diverge Fundamentally

LangGraph — "You Are the Architect"

LangGraph is an extension of LangChain that treats your agent as a directed graph (or DAG). Every step, every branch, every loop — you define it explicitly.

You construct nodes (LLM calls, tool calls, custom logic) and edges (transitions, conditions, cycles). The agent's entire execution path is a graph you designed.

# LangGraph — you define the graph explicitly
from langgraph.graph import StateGraph

builder = StateGraph(AgentState)
builder.add_node("classify", classify_intent)
builder.add_node("search", run_search)
builder.add_node("respond", generate_response)

builder.add_conditional_edges("classify", route_by_intent, {
    "search_needed": "search",
    "direct": "respond"
})
builder.add_edge("search", "respond")
builder.set_entry_point("classify")

graph = builder.compile(checkpointer=MemorySaver())

This is powerful. And demanding. You own the architecture completely.

Google ADK — "You Define the Agents, ADK Handles the Rest"

ADK treats agents as hierarchical tree structures. A root agent delegates to specialized sub-agents. Orchestration is handled through pattern primitives: SequentialAgent, ParallelAgent, LoopAgent.

# ADK — declare agents and their roles, ADK orchestrates
from google.adk.agents import LlmAgent, SequentialAgent

research_agent = LlmAgent(
    name="researcher",
    model="gemini-2.5-flash",
    instruction="Research the given topic thoroughly.",
    tools=[google_search]
)

writer_agent = LlmAgent(
    name="writer",
    model="gemini-2.5-flash",
    instruction="Write a concise summary based on research.",
)

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

ADK provides the scaffolding. You define the logic, roles, and tools. The framework manages context, routing, state, and lifecycle.

Deep Dive: Feature by Feature

1. Orchestration Model

LangGraph uses a graph model — nodes and edges. It shines when your workflow has:

Complex conditional branching
Loops and retries with custom exit conditions
Parallel branches that must merge at specific points
Precise control over which step runs when

ADK uses a hierarchical agent tree. It shines when your workflow looks like:

A root "manager" agent that delegates to specialists
Tasks that can run sequentially or in parallel by design
Multi-agent workflows where each agent has a clear, encapsulated role

The key difference: LangGraph models flow as a graph. ADK models flow as a team.

2. State Management

This is where LangGraph has a significant technical edge for complex use cases.

LangGraph has built-in checkpointing — state is persisted at every node. This enables:

Time travel debugging: replay your agent from any prior state
Resuming interrupted runs
Human-in-the-loop flows (pause, wait for approval, continue)
Fault tolerance in long-running workflows

# LangGraph time-travel: rewind to any past state
config = {"configurable": {"thread_id": "abc123"}}
graph.update_state(config, {"messages": [...]}, as_node="classify")

ADK manages state through Session objects — short-term state per conversation, with pluggable backends for longer-term memory. It's cleaner for conversational flows and multi-session memory, but doesn't natively offer the time-travel / checkpoint replay that LangGraph does.

Winner for complex state: LangGraph. Winner for conversational memory across sessions: ADK.

3. Multi-Agent Systems

Both frameworks support multi-agent architectures, but they approach it very differently.

LangGraph: You build multi-agent systems by composing graphs. One graph can invoke another as a subgraph. Communication between agents is via shared state passed through the graph. It's powerful but requires you to design the topology explicitly.

ADK: Multi-agent is a first-class primitive. ADK is explicitly designed for hierarchical agent teams. Sub-agents can be:

Invoked sequentially (SequentialAgent)
Invoked in parallel (ParallelAgent)
Looped until a condition is met (LoopAgent)
Called as tools by a root agent (AgentTool)

ADK also supports Agent2Agent (A2A) Protocol — a standardized interface allowing ADK agents to call agents built in LangGraph, CrewAI, or other frameworks. This is a major interoperability win.

# ADK: Run flight and hotel agents IN PARALLEL
from google.adk.agents import ParallelAgent

booking_pipeline = ParallelAgent(
    name="booking_pipeline",
    sub_agents=[flight_agent, hotel_agent]  # runs concurrently
)

Winner for multi-agent-first design: ADK.

4. Observability and Debugging

LangGraph integrates tightly with LangSmith (and Langfuse via callbacks). You get:

Step-by-step trace of every node execution
Token usage per node
Visual graph replay of agent runs
LangGraph Studio: visual debugging UI

ADK is built with OpenTelemetry natively. This means:

Plugs into any OTel-compatible backend (Jaeger, Grafana, Datadog, etc.)
One-click integrations with Langfuse and other LLM observability platforms
Built-in evaluation framework for both final responses and intermediate steps
Visual Web UI + CLI for local debugging
When deployed on Vertex AI: Cloud Trace integration out of the box

LangGraph's edge: LangSmith is mature and deeply integrated.
ADK's edge: OpenTelemetry-first avoids vendor lock-in.

5. Tool Ecosystem

LangGraph/LangChain has a massive, mature ecosystem — thousands of pre-built integrations, tools, and chains built over years. It's hard to beat for breadth.

ADK brings:

Pre-built tools: Google Search, Code Execution, BigQuery, AlloyDB
MCP (Model Context Protocol) tool support
LangChain tools usable inside ADK (interoperability)
Other agent frameworks (CrewAI, LangGraph agents) usable as tools
Support for 200+ models via LiteLLM

ADK's tool interoperability story is strong — it can consume LangChain tools, which largely closes the ecosystem gap.

6. Deployment

LangGraph: Deploy anywhere. Containerize your graph and run it on any infrastructure. LangGraph Cloud (managed service) available for scale. Truly cloud-agnostic.

ADK: "Deploy anywhere" is the stated goal, and it works — but the native experience is GCP:

One-command deploy to Vertex AI Agent Engine
Native Cloud Run, GKE support
Managed sessions, auth, and tracing on Vertex AI automatically

If you're on GCP, ADK's deployment story is a genuine competitive advantage. If you're on AWS, Azure, or self-hosted, LangGraph is simpler.

7. Streaming

LangGraph: Per-node token streaming. Standard LLM streaming, solid and reliable.

ADK: Bidirectional audio and video streaming via the Gemini Live API. This is unique — no other major framework natively supports this. For voice agents, customer support bots, or multimodal applications, ADK is in a different league here.

8. Developer Experience

LangGraph feels like a graph DSL — powerful, but you're working at a lower abstraction level. It rewards engineers who want transparency and deterministic behavior. The cost: more boilerplate, steeper learning curve, fragmented documentation.

ADK feels like a full-stack Python application framework — Web UI, CLI, API server, test harness, deploy pipelines, all included. It rewards engineers who want to move fast and think in terms of agents and roles rather than nodes and edges.

The Honest Tradeoffs

LangGraph Strengths

Unmatched precision and control over execution flow
Best-in-class state checkpointing and time-travel debugging
Mature ecosystem, battle-tested in production
Truly model-agnostic and cloud-agnostic
Excellent for compliance-heavy environments (every decision is auditable)

LangGraph Weaknesses

Verbose code for straightforward multi-agent patterns
Steeper learning curve — graph thinking isn't intuitive for all teams
Documentation can be fragmented
No native multimodal streaming

ADK Strengths

Fastest path to hierarchical multi-agent systems
Built-in evaluation, Web UI, CLI — production-grade DX out of the box
Native A2A protocol for cross-framework agent interoperability
OpenTelemetry-native observability (no vendor lock-in)
Best multimodal/streaming support of any major framework
Actively backed by Google, powering internal products (Agentspace, Customer Engagement Suite)

ADK Weaknesses

Newer — less production battle-testing than LangGraph
GCP ecosystem makes it awkward outside Google Cloud
Less fine-grained control than LangGraph for complex cyclical flows
Gemini optimization means other models are second-class (though supported)

Decision Guide: When to Choose What

Choose LangGraph when...

You need surgical precision over every execution step.
Compliance systems, financial workflows, healthcare automation — any domain where you must prove exactly what happened and why.

Your workflow has complex, custom loops and branching logic.
Non-standard patterns that don't fit "sequential" or "parallel" — LangGraph lets you model any flow you can imagine.

You're building long-running tasks that must survive interruptions.
Checkpointing + resume is a LangGraph superpower. Multi-day agent runs, workflows requiring human approval mid-execution.

You're multi-cloud or cloud-agnostic.
If AWS, Azure, or self-hosted infrastructure is non-negotiable, LangGraph is the frictionless path.

Your team already knows LangChain.
The ecosystem familiarity is a real productivity advantage.

You need the widest model support without friction.
OpenAI, Anthropic, Mistral, local models — all first-class citizens.

Choose Google ADK when...

You're building on Google Cloud (Vertex AI, GCP).
One-command deployment, managed sessions, Cloud Trace — the native experience is genuinely excellent.

Speed to production matters more than architectural customization.
ADK's batteries-included approach gets you from prototype to deployed agent faster than anything else.

You're building hierarchical multi-agent systems.
Agent teams with clear roles and delegation are ADK's native strength.

You need multimodal or voice agents.
Bidirectional audio/video streaming via Gemini Live API is uniquely available here.

You want cross-framework agent interoperability via A2A.
If your org is mixing ADK agents, LangGraph agents, and CrewAI agents — the A2A protocol makes ADK the best orchestration hub.

Your model choice is Gemini (or you want access to Gemini 3 Pro/Flash).
ADK and Gemini are deeply co-designed. You'll get the best performance, streaming, and tooling here.

Situational Cheatsheet

Situation	Recommendation
Compliance/audit-critical workflow	LangGraph
GCP-native enterprise deployment	ADK
Complex custom loops and cycles	LangGraph
Multi-agent delegation with clear roles	ADK
Long-running tasks with resume/replay	LangGraph
Voice/multimodal agents	ADK
AWS or Azure infrastructure	LangGraph
Fast prototyping to production	ADK
You need every model under the sun	LangGraph
Google Gemini is your primary model	ADK
HITL (Human-in-the-loop) workflows	LangGraph
Cross-framework agent interop (A2A)	ADK
Team prefers explicit flow control	LangGraph
Team prefers role-based agent design	ADK

Can You Use Both?

Yes — and increasingly, teams do.

ADK can treat a LangGraph agent as an AgentTool. LangGraph can call ADK-built agents as subgraphs via API. With MCP and A2A protocol support in ADK, the two frameworks are becoming interoperable rather than mutually exclusive.

A pragmatic architecture some teams use:

Root Orchestrator (ADK — hierarchical multi-agent)
├── Research Agent (ADK — Google Search, BigQuery)
├── Processing Agent (LangGraph — complex stateful loop)
│   ├── Validate Node
│   ├── Transform Node
│   └── Retry Node (with checkpointing)
└── Output Agent (ADK — Gemini streaming response)

Use each where it's strongest.

Final Verdict

LangGraph is the engineer's framework. It gives you the surgical control, auditability, and state management that complex production systems demand. You pay for it in learning curve and boilerplate. For compliance-heavy, custom-flow, cloud-agnostic workloads — it's the right tool.

ADK is the product team's framework. It's fast, cohesive, and opinionated in the right ways. Multi-agent orchestration is a first-class citizen, deployment is frictionless on GCP, and the multimodal streaming story is unmatched. For hierarchical agent teams, GCP environments, and teams that want to move fast — it's compelling and only getting better.

The framework you pick should match your workflow pattern, your infrastructure, and your team's mental model. Neither is universally better.

Pick the one that makes your specific problem easier to model — then go build.

Have you shipped production agents on either? I'd be curious what failure modes you've hit in practice — that's where the real framework comparison happens.

100s of Tools in Your Agent — Here's How to Actually Pick the Right One

Daathwi Naagh — Fri, 10 Apr 2026 00:49:45 +0000

The Problem Nobody Talks About

You've built an agent. You've wired up 100+ tools. You feel good about it.

Then it starts hallucinating. Picking the wrong tool. Collapsing entire workflows over a single misclassified query.

The failure isn't the LLM. It's the architecture.

My previous post covered a genuine use case I found for Gemma4 — and this is exactly where it fits in.

The Naive Approach (and Why It Fails)

Load all tools into LLM context and let it decide.

Sounds simple. It is. And it breaks at scale.

Hallucinations increase with context length
Bloated context = slower, more expensive calls
LLM gets confused choosing between 50+ tool descriptions

Result: Slow. Unreliable. Expensive agents.

The "Slightly Smarter" Approach (Still Broken)

RAG over tool descriptions. Seems reasonable:

User query → embedding → top 5 matches → LLM picks

Sounds clean. But embeddings can't distinguish intent.

Similar words ≠ same meaning.

Example:

User says: "I need iPhone"
Tool: check_product_catalog

Embedding search may:

Miss the tool completely
Retrieve irrelevant tools
Break the entire downstream workflow

Wrong tool gets selected. Entire workflow collapses.

The problem isn't the embedding model. It's that you're asking a single layer to carry too much responsibility.

What Actually Worked: A Layered Filtering Stack

The approach that works in production is layered filtering — not pure semantic search, not raw LLM reasoning. Both together, in the right order.

Here's the stack I use:

Layer	Tool	Role
Intent Classification	`gemma4:e4b` via Ollama (9.6 GB, local)	Fast, private intent routing
Semantic Search	`nomic-embed-text` via Ollama (274 MB)	Embedding over filtered subset

The 5-Step Architecture

Step 1 — Classify Intent First

A lightweight LLM maps the query to a high-level category before any search happens.

This eliminates entire irrelevant domains upfront. If the user is asking about orders, you never even look at inventory tools.

"I need iPhone" → category: product_discovery

Step 2 — Hard Filter by Metadata

Deterministic rules. Not embeddings.

Only tools matching the classified intent category are eligible. The search space collapses from 100+ tools to maybe 10–15.

category: product_discovery → eligible tools: [check_catalog, search_products, get_inventory, ...]

Step 3 — Semantic Search Within the Clean Subset

Now RAG works — because it's running over a small, relevant set, not noisy hundreds.

nomic-embed-text finds the closest semantic matches within your filtered pool. False positives drop dramatically.

Step 4 — Score and Rank

Confidence scoring on the top candidates. Auditable. Explainable.

No black box decisions. You can log exactly why a tool was selected — which matters when things break in production.

Step 5 — LLM Final Pick

Send the top candidates + the original user query to the LLM.

Now it's choosing between 3–5 relevant tools, not 100+. The context is clean. The decision is accurate.

[check_product_catalog, search_products, get_item_details] + "I need iPhone"
→ LLM picks: check_product_catalog

Why This Works

Each layer does one job. No single layer carries too much responsibility.

Intent classifier  → reduces domain space
Metadata filter    → reduces tool count (deterministic, fast)
Semantic search    → finds closest match in clean subset
Scoring            → adds confidence + auditability
LLM               → makes final call with minimal context

That's why it's reliable. That's why it's fast.

The Part No One Talks About

Even the best architecture fails if your tool descriptions are written like API docs.

# Bad — written for engineers
def check_product_catalog(sku: str, region: str) -> dict:
    """Queries product catalog by SKU with region filtering."""

# Good — written for users
def check_product_catalog(...):
    """
    Use this when someone wants to find a product, check if something 
    is available, look up an item by name or model, or browse what's 
    in stock. Works for queries like 'do you have iPhone 15?' or 
    'show me your laptop options'.
    """

Write descriptions in the language your users actually speak.

Think about how someone types a message to an agent — not how an engineer names a function.

The system learns from the language you give it.

Results

Metric	Value
End-to-end latency (all 4 steps)	< 2 seconds
Tool selection accuracy	Significantly higher than pure RAG
Model infra	Fully local, private
Bottleneck	1000+ concurrent users (next problem to solve)

The Real Lesson

We don't need smarter models.

We don't need infinite context windows.

We need better system design and the discipline to think like a user.

A layered architecture with good tool descriptions, running on lightweight local models, will outperform a bloated LLM context every time.

That's the real work.

Built this in production. Happy to discuss the concurrent scaling problem — that's a different beast entirely.

Found this useful? Follow for more on agent architecture and production ML systems.