Google ADK vs LangGraph for Production Agents

Verdict: LangGraph for Control, ADK for Google Agent Platform

LangGraph is the safer default for a production agent that behaves like a workflow engine: it has state, branches, retries, manual review, and side effects that must be replayed or resumed without losing the run. Google ADK is the better choice when your company has already chosen Google Cloud as the agent platform and wants the runtime, session store, memory store, evaluation service, tracing, and identity layer to sit inside that boundary.

That is the real split. ADK is not just a Python helper around Gemini. Google positions ADK as an open-source agent development framework for building, debugging, and deploying reliable agents at enterprise scale, available in Python, TypeScript, Go, Java, and Kotlin. It gives teams a code-first way into Google Agent Platform services.

LangGraph is not just another agent framework. LangChain describes LangGraph as a low-level orchestration framework and runtime for long-running, stateful agents, focused on durable execution, streaming, human-in-the-loop, and persistence. Its value is that the graph, state transitions, and interruption points are explicit in your application.

The wrong choice is picking based on which demo looks shorter. A production agent fails on run ownership: who stores state, who resumes after a crash, who blocks irreversible tools, who traces the run, and who pays when session and memory traffic grows. If those answers need to live in your product code and span providers, use LangGraph. If those answers should live in Google Agent Platform because the agent is a Google Cloud workload, use ADK.

LangGraph's production orchestration model is already a strong fit for teams that need explicit runtime control. The ADK comparison becomes sharper because Google is offering a platform path, not just a local SDK.

The Axis Is Who Owns the Run

The framework decision is a run-ownership decision. Every production agent needs a durable answer for the same object: a user request enters, tools are called, state changes, approval may be needed, memory may be read or written, and the run either finishes, pauses, retries, or fails.

In LangGraph, that object is modeled as graph state. Persistence saves graph state as checkpoints at every step of execution and organizes the history into threads. Those checkpoints enable human-in-the-loop workflows, conversational memory, time travel debugging, and fault-tolerant execution. If a run pauses for approval, thread_id is the pointer that tells the checkpointer which state to load when the run resumes.

In ADK, the run model is framed around agent platform services. ADK's session docs separate Session, State, and Memory: Session is the single ongoing interaction, State is data inside the current conversation, and Memory is searchable cross-session information. Google Agent Platform then adds managed Agent Runtime, Sessions, Memory Bank, Example Store, Evaluation Service, tracing, built-in observability, Code Execution, and Computer Use.

That changes the engineering trade. LangGraph says: put the workflow truth in code, then choose the hosting and observability stack. ADK says: write the agent in a Google-supported framework, then push it toward Google-managed agent infrastructure.

For a technical founder shipping a workflow agent that can refund an invoice, create a ticket, or write back to a customer database, LangGraph usually gives the clearer safety boundary. The graph node that proposes the action can stop before the tool call, persist the state, expose the approval payload, and resume only when the reviewer responds. That approval step is part of the product.

For a platform team standardizing agent workloads on Google Cloud, ADK can reduce runtime assembly. The same team can use Google Cloud identity, deployment paths, managed runtime, memory services, and tracing rather than assembling every layer independently.

Production Comparison

The practical choice is not which framework can call a tool. Both can. The choice is which one gives your team the least ambiguous production control surface.

The table hides one important point: the open-source framework cost is rarely the bill that surprises you. The surprise is trace volume, session events, memory retrieval, code execution, and idle orchestration work. Google says Agent Runtime billing is rounded to the nearest second and idle time is not billed. That is useful, but it does not remove session and memory costs once the agent is actually used.

LangSmith pricing has a different shape. The Developer plan is free per seat and includes tracing, evals, annotation queues, monitoring, one Fleet agent, and up to 50 Fleet runs per month. The Plus plan is $39 per seat per month and includes one dev-sized agent deployment, up to 500 Fleet runs per month, access to LangSmith Engine, and access to LangSmith Sandboxes. The cost question is not "which SDK is free?" It is "where will traces, runs, deployments, and reviewer queues live once usage is real?"

Use LangGraph When Approval Is Part of the Product

LangGraph wins when a human decision is a normal branch in the agent, not an exception path. Its interrupts pause graph execution at specific points and wait for external input before continuing. When an interrupt is triggered, LangGraph saves the graph state with persistence and resumes later with the same thread.

That matters for any workflow with side effects: purchase approval, account change, customer email, code change, data export, access request, or support escalation. The important question is not whether a person can look at the output. The important question is whether the runtime can stop before the irreversible action, store exactly what the agent wanted to do, expose that payload to a reviewer, then continue with the same state after review.

A minimal approval shape looks like this:

from langgraph.types import interrupt, Command

def approval_node(state):
    approved = interrupt({
        "action": state["proposed_action"],
        "reason": state["reason"],
        "tool": state["tool_name"],
    })
    return {"approved": approved}

config = {"configurable": {"thread_id": request_id}}
stream = graph.stream_events(input_state, config=config, version="v3")

if stream.interrupted:
    enqueue_review(stream.interrupts)

graph.invoke(Command(resume={"approved": True}), config=config)

The code is small, but the design rule is the product. The approval payload should include the proposed action, the tool name, the arguments that will be sent, the user-visible consequence, and the reason the agent believes the action is allowed. The reviewer response should be stored as a first-class event, not as a note in a chat transcript.

That is where LangGraph's persistence model earns its complexity. Checkpoints are not only for crash recovery. They let you inspect state, pause for review, resume after approval, fork a run for debugging, and avoid re-running successful nodes after a failure. If the agent is part of a regulated or high-trust product workflow, those mechanics are not optional.

LangGraph also leaves the platform choice open. You can deploy through LangSmith, run your own server, use a database-backed checkpointer, send traces to your observability stack, or wrap it in the app infrastructure your team already operates. That flexibility costs engineering time, but it avoids making Google Agent Platform the permanent owner of your agent runtime.

The OpenAI Agents SDK versus LangGraph decision follows the same pattern: the more the agent looks like a durable business process, the more explicit orchestration matters.

Use Google ADK When the Platform Is the Product Boundary

Google ADK wins when the agent is meant to live inside Google's agent platform and the managed services remove work your team would otherwise own. ADK's strongest production path is not only the local framework. It is the path from code to Agent Runtime, Sessions, Memory Bank, evaluation, tracing, identity, and Google Cloud integrations.

ADK can start locally with familiar package installs:

pip install google-adk
npm install @google/adk
go get google.golang.org/adk

The platform story matters after that. ADK's Agent Runtime deployment guide supports Python and Go v1.2.0. Standard deployment uses Cloud Console and the ADK command line interface. Agents CLI deployment sets up a Google Cloud environment with CI/CD, infrastructure-as-code, and deployment pipelines, and it requires a Google Cloud project with billing enabled.

That is useful when the agent is not a standalone product runtime. For example, a SaaS platform team already using Google Cloud may want agents to call BigQuery, use Google Cloud Agent Identity, connect APIs through Apigee API Hub, trace with Google Cloud Trace, and persist conversational context through Sessions and Memory Bank. In that case, choosing ADK can make the agent easier to govern because the security and runtime boundaries align with the rest of the platform.

ADK also gives a clearer path for platform-style evaluations. Its evaluation docs recommend automated evaluations beyond prototype and split evaluation into trajectory/tool-use evaluation plus final-response evaluation. That is the right split for production agents because the final answer can be acceptable while the path was unsafe, wasteful, or policy-violating.

The production caution is lock-in and hidden platform cost. Agent Runtime pricing is compute and memory based, but Agent Platform also prices session events and memory operations. Sessions billing is based on stored session events that include content. Memory Bank charges for stored memories and returned memories. Starting February 11, 2026, billing begins for Code Execution, Sessions, and Memory Bank. If your agent writes memory too eagerly, stores noisy session events, or retrieves memory on every request, the platform services become part of the unit economics.

So the ADK checklist is not only "can it deploy?" It is:

The Decision Rule That Flips the Choice

Default to LangGraph unless Google Agent Platform materially reduces the production work your team must own. Flip to ADK when Google Cloud is already the control plane and the agent benefits from managed runtime, identity, session, memory, evaluation, and tracing services.

The cleanest decision rule:

There is also a hybrid path, but it should be temporary or deliberately bounded. LangSmith Deployment documents support for agents built with LangGraph, Google ADK, and other frameworks. It can deploy Google ADK agents as a LangGraph with a wrapper package. That is useful for migration and unified observability, but it also creates another boundary: ADK owns one part of the agent semantics, LangSmith owns deployment and tracing, and your product still owns the side effects.

Hybrid stacks fail when nobody can answer a simple incident question: where did this run pause, what state was persisted, which reviewer approved it, what memory was read, and what exact tool payload executed? If the stack cannot answer that quickly, the framework choice was not finished.

Implementation Checklist

Whichever framework you choose, build the control layer before traffic exposes the gaps. A production agent needs durable IDs, policy checks, evaluator outputs, approval records, and cost telemetry from the first shipped version.

Log these fields for every run:

• run_id, thread_id, user or account scope, and environment.
• Model provider, model name, prompt or instruction version, and tool registry version.
• Tool call name, tool arguments, tool result, tool latency, and whether the tool was dry-run, approved, blocked, or executed.
• Memory read keys, memory write candidates, memory writes accepted, and memory writes rejected.
• Retrieval sources or context documents when the agent reads knowledge.
• Human reviewer, approval payload, reviewer decision, and resume event.
• Evaluator name, trajectory result, final-response result, and policy violations.
• Token usage, runtime compute, session event count, memory retrieval count, and code execution usage where the platform exposes them.

The framework only makes some of those fields easier. It does not remove the need to design the operational surface. LangGraph gives you a direct place to bind state and approvals. ADK gives you a direct path into Google-managed runtime services. Both still need a product-specific answer for access control, evaluator thresholds, cost ceilings, and incident review.

Use LangGraph if your team wants the agent runtime to be part of the application architecture. Use Google ADK if your team wants Google Agent Platform to be the agent runtime. Do not choose either because the starter example is shorter.