Google ADK vs LangGraph: choose by workflow truth and recovery responsibility

Key takeaways

• LangGraph makes workflow state and transitions explicit in a graph.
• Google ADK organizes defined tool capabilities around request handlers.
• LangGraph checkpoints preserve state, but recovery still needs operating controls.

The useful Google ADK vs LangGraph question is not which framework has the longer feature list. It is where each system records the truth of a run, how it chooses the next action, and which recovery duties remain with your team.

Google ADK vs LangGraph at a glance

Start with the control surface you want engineers to inspect. LangGraph puts states and transitions in an explicit graph. Google ADK centers defined tool capabilities and routes requests to their handlers. The matrix also separates documented recovery behavior from controls that your team must define before choosing. Checkpoint state and recovery ownership are separate decisions. In LangGraph, a checkpointer alone does not add automatic failure detection, automatic resumption, or coordination that prevents two workers from resuming the same thread.

Both frameworks are free and open source under different licenses. That baseline does not answer the control questions above.

What should you compare before choosing?

Compare the routing decision first. Routing selects the next workflow step from conditions, so it is where an agent workflow turns model output or system data into execution. If you cannot point to that decision, a broad framework label will not make the control path clearer.

Apply the same two questions to both frameworks: what chooses the next step, and where is that choice represented? The answer might be an LLM, a predefined rule, or embedding similarity. Those are different routing mechanisms, even when they sit inside the same application.

An LLM-based route places the choice in a model decision. A predefined rule places it in deterministic logic. Embedding similarity places it in a similarity comparison. The framework decision begins after you identify which of these mechanisms your workload actually uses. Then you can inspect whether that mechanism is expressed as a graph transition, a handler selection, or another explicit control in your system.

This comparison method also keeps the frameworks on equal terms. Do not ask only whether LangGraph exposes a graph or only whether Google ADK exposes tools. Trace one route in each candidate from its input condition to the selected step. Name the decision mechanism, the representation that holds it, and the code an engineer would inspect when the route is wrong.

Our Google agent design-pattern notes provide another implementation lens for that routing question. The point is not to award a label. It is to make the deciding unit visible before the workflow grows around it.

Two reference scenarios expose the architecture split

Consider a hypothetical multi-step workflow in which preserving progress is part of the design. In LangGraph, a graph compiled with a checkpointer saves a graph-state snapshot at every step. If a node fails, persistence can restart the graph from the last successful step. Pending writes keep completed nodes from running again.

That workload shape favors an explicit account of state. The graph says which state exists and which transition comes next. The checkpointer records step-level progress. The restart behavior begins from the last successful step instead of treating the entire run as untouched. This is a reference scenario, not a claim that every controlled workflow should use LangGraph.

Now consider a different hypothetical workload. A coordinator receives work that can be divided into independent subtasks. Google ADK can delegate those subtasks to specialized agents that operate concurrently. Here, the central mechanism is coordinator-led delegation: the coordinator assigns work, and the specialized agents handle separate pieces at the same time.

The distinction is structural. The first scenario asks for explicit step state and restart behavior across a controlled sequence. The second asks for delegation across independent work. Neither scenario proves a universal winner, and neither substitutes for tracing your actual routes. They show which architecture question deserves attention before implementation details multiply.

Use the scenario that resembles the hard part of your workload. If preserved progress is the concern, inspect the graph state, snapshots, and restart boundary. If independent delegated work is the concern, inspect the coordinator, the specialized agents, and the subtask boundaries. For a deeper view of explicit coordination, our LangGraph multi-agent systems notes stay close to those mechanisms.

The controlled graph scenario has one important edge. Saved state is not the same thing as an operating recovery system.

What does LangGraph checkpointing leave to you?

A LangGraph checkpointer preserves useful execution state, but the checkpointer alone does not detect a failure, resume work automatically, or stop two workers from resuming the same thread. Those are separate runtime responsibilities.

At scale, the developer remains responsible for three controls: crash detection, selecting the correct thread to resume, and distributed locking. Crash detection identifies the failed run. Correct thread selection connects recovery to the intended persisted state. Distributed locking prevents competing workers from resuming the same thread.

This boundary should change how you assess a checkpointing demo. A successful state snapshot answers, "What was saved?" It does not, on its own, answer, "Who notices the crash?", "Which thread resumes?", or "What prevents a duplicate resume?" Those questions belong in the runtime control contract around the graph.

LangGraph Agent Server handles hosting and deployment. It does not add automatic failure detection and recovery. That makes hosting a distinct decision from the recovery controls your workload requires. Moving the graph into a hosted environment does not remove the need to account for those controls.

Human intervention is another explicit boundary worth designing, but it should not be confused with automatic crash recovery. Our LangGraph human-in-the-loop notes focus on that implementation problem. For the framework decision here, write down who owns the three runtime duties before treating persistence as a complete recovery answer.

Parallel work trades latency for operating complexity

Concurrency is attractive when the work is genuinely independent. Running independent subtasks at the same time can reduce overall latency, especially when a workflow makes several model calls or external-service calls. Google ADK supports this shape through coordinator-led delegation to specialized agents.

The latency case has a clear condition: the subtasks must be able to run concurrently. Once that condition holds, the architecture can avoid waiting for each model or service call to finish before starting the next independent call. That is the useful promise to test in a candidate workflow.

The operating bill grows with the concurrency. A concurrent workflow adds complexity and cost to design, debugging, and system logging. Design has to account for more than one active path. Debugging must follow concurrent work. Logging must preserve enough execution detail to understand what happened across those paths. These are not reasons to reject parallel work. They are part of the architecture you are choosing.

Observability has a concrete destination in Google ADK: it routes OpenTelemetry data to Cloud Trace and Cloud Logging. That tells you where telemetry can go. It does not make the concurrent workflow simpler by itself, so evaluate the logging path alongside the delegation path.

Use one representative parallel route in your comparison. Mark the independent subtasks, the coordinator's assignments, and the model or external-service calls. Then inspect what your logging setup would retain for each concurrent path. This exercise tests the exact latency condition while keeping the design, debugging, and logging burden visible.

If the subtasks are not independent, this specific concurrency benefit does not describe the workload. If they are independent, compare the latency opportunity with the operational work your team will own. That is a sharper decision than treating "multi-agent" as a benefit on its own.

Infrastructure and maintenance drive production cost

Framework license cost is only one line in a production budget. Infrastructure and maintenance add costs beyond licensing. The architecture determines which resources run and which controls engineers must maintain, so an open-source framework can still carry a meaningful operating burden.

Start with the shared categories. Record the infrastructure used to run the workflow and the maintenance needed to keep its routes, state, recovery controls, debugging path, and logging path working. This does not require a speculative dollar figure. It requires naming the units your team will operate.

LangGraph adds a specific hosting choice. It is available as a free, MIT-licensed open-source library and as a hosted platform with paid deployment and scaling tiers. Hosted usage is measured through executed workflow nodes and deployment minutes. Those two meters should stay visible in any hosted cost model.

Executed nodes describe workflow activity. Deployment minutes describe how long the deployment runs. A cost review that tracks only one of those units misses part of the hosted measurement model. The exact dollar result depends on the deployment and its use, so the useful comparison begins with expected node execution and deployment time rather than a single headline price.

A Google ADK cost model still needs infrastructure and maintenance. When the architecture uses concurrent work, include its design, debugging, and system-logging burden. Hosted LangGraph's executed-node and deployment-minute meters apply to that hosted platform.

The result should be an operating-cost map, not a license-price verdict. Put infrastructure, maintenance, and any hosted usage meters beside the architecture choices that create them. That makes the cost discussion useful before an exact deployment bill exists, while avoiding a false claim that either framework is always cheaper.

Which framework should you choose?

Use four conditions to make the choice. Each one gives you a positive fit or a clear reason to remove a framework from the shortlist.

Keep LangGraph when explicit state earns its upfront work

LangGraph requires upfront work on the state schema and graph topology. Keep it when your team accepts that work because predictable, auditable maintenance matters. A controlled sequence can make that trade worthwhile: a graph compiled with a checkpointer saves a graph-state snapshot at every step, and persistence can restart from the last successful step while pending writes keep completed nodes from running again.

That state model does not remove the runtime work around it. At scale, engineers still own crash detection, correct-thread resumption, and distributed locking. Choose LangGraph when explicit state and topology are worth designing up front, and when the team is prepared to operate the controls that turn saved state into a reliable recovery path.

Remove LangGraph when exploratory changes make the surface too large

Remove LangGraph when the workflow is still changing so quickly that its explicit structure becomes drag. Defining branching conditions, state transitions, and error handlers increases the development surface for iterative or exploratory builds. That is the removal condition, not the mere presence of a graph.

An exploratory build may need repeated changes to branches, transitions, and error handling. LangGraph makes those elements explicit, so they become part of the development surface the team must revise. Remove it when the workload is too unsettled for the team to benefit from committing those decisions to a graph topology and state schema.

Keep Google ADK when initial deployment speed matters

Google ADK can deploy faster initially. Keep it when that early speed matters and the workload fits defined tool capabilities and handler routing. The fit becomes more concrete when a coordinator can assign independent subtasks to specialized agents that work at the same time. Concurrent independent work can reduce overall latency when the workflow makes several model or external-service calls.

That positive case carries an operating tradeoff. Concurrent workflow architecture adds complexity and cost to design, debugging, and system logging. Trace the routing unit, coordinator assignments, and subtask boundaries before choosing. Keep Google ADK when faster initial deployment and delegated independent work are useful enough to justify the concurrent system your team will maintain.

Remove Google ADK when agent count outruns routing discipline

Remove Google ADK when a proposed system spans dozens of agents and the team cannot keep recovery and routing under strict discipline. At that scale, complex recovery and routing logic can become tangled.

Make the removal decision against the controls the team can actually sustain. Engineers should be able to identify the owner of each route and recovery control as the agent count grows. Google ADK routes OpenTelemetry data to Cloud Trace and Cloud Logging, which gives its telemetry a concrete destination. The framework stays on the shortlist only when routing and recovery remain legible under the team's operating discipline.

Apply this control-contract test to your shortlist: identify workflow truth, trace the routing decision, name the recovery owner, and account for the operating units. Then use our open-source agentic AI framework notes to carry those questions into the rest of your framework evaluation.