Google ADK vs LangGraph: which agent stack deploys cleaner?

Google’s Agent Development Kit and LangGraph are often compared as if they were skins over the same agent loop. They are closer than the marketing suggests, but their design pressure points are different. ADK asks you to describe agents, tools, sessions and evaluation inside a Google-friendly development kit. LangGraph asks you to draw the workflow as a graph whose nodes, edges and state updates are inspectable.

That difference matters most when the demo ends. Production agent systems fail around identity, state, retries, tool approvals and observability, the same edges covered in this site’s agent protocols cluster. The deployment question is therefore less about which framework can call a model and more about which runtime burden your team is ready to own.

What is Google ADK good at?

Google ADK is a strong fit when the agent product already belongs in the Google ecosystem. The framework gives you a structure for agents, tools, sessions, evaluation and local development while aligning naturally with Gemini, Vertex AI and Google Cloud deployment targets. If the security team already approves service accounts, Cloud Run and Vertex access, ADK lets the agent follow those rules rather than inventing a parallel runtime. That same boundary discipline matters for agent write access once tools can change production systems.

The trade is strategic coupling. ADK can run outside Google Cloud as normal code, but the cleanest path uses Google’s identity model, deployment documents and model services. That is a benefit when your product is Google-centred and a cost when portability across providers is the first requirement.

ADK also suits teams that want an agent kit before they want a workflow language. You can describe sub-agents and tools directly, test them locally, then move the same shape toward a Google deployment. The framework feels closest to an application kit for Gemini agents.

What is LangGraph good at?

LangGraph is a strong fit when control flow is the product. A graph makes each step explicit: call a model, route by state, wait for a human review, call a tool, retry a failed edge, then checkpoint the result. That shape works well for research agents, support automation, coding agents and internal workflows where you need to explain why a system took the next step.

The centre of LangGraph is state. A compiled graph can run in your own Python service, while a checkpointer stores progress so the workflow survives process restarts and long pauses. LangGraph Platform adds a packaged runtime, but manual deployment is still practical if your team already runs APIs, workers and storage.

The trade is operational ownership. LangGraph gives you portability across model providers and hosting choices. In exchange, you choose the database, worker model, streaming surface, queueing behaviour and observability. That is exactly what many platform teams want, and exactly what some product teams do not want.

Best fit by operating model

Show data

Best fit by operating model. Bar chart. Google-first agent product: 90 fit score. Provider-portable workflow service: 85 fit score. One quick chatbot prototype: 55 fit score.

Item	Value (fit score)	Note
Google-first agent product	90	ADK lines up with Gemini and Google Cloud deployment.
Provider-portable workflow service	85	LangGraph lines up with explicit orchestration.
One quick chatbot prototype	55	Either stack may be more framework than you need.

How do you deploy Google ADK manually?

Start by deciding whether manual means “Google Cloud without a managed agent button” or “outside Google Cloud entirely”. The first path is smoother. Package the ADK agent as a service, grant a service account access to Gemini or Vertex AI, provide tool credentials through Secret Manager or your own secret store, then run the service on Cloud Run or GKE. Use the ADK local runner during development, then move the same entry point into the container.

The manual checklist is simple but easy to skip. Pin the Python version and ADK package version. Put project id, region, model name and tool endpoints in environment variables. Add a health endpoint that checks process readiness rather than making a live model call. Log every model call, tool call, session id and user approval decision.

Outside Google Cloud, the shape stays the same and the glue changes. You still need Gemini or model credentials, tool credentials, persistent session storage if your agent relies on it, and a web boundary that your product can call. The more Google-managed services you replace, the more of ADK’s deployment convenience you are choosing to own yourself.

How do you deploy LangGraph manually?

With LangGraph, decide persistence before you decide hosting. A graph without a checkpointer is fine for a short request. A graph that waits for humans, retries tools or resumes after a webhook needs durable state. Choose the checkpointer and storage engine first, then package the graph behind an API that accepts a thread or task id and returns either a result or a streaming event feed.

A small manual deployment usually has three parts: an API process that receives requests, a worker process that runs longer graph steps, and a database that stores checkpoints plus application state. You can combine the API and worker at first, provided you know when to split them. Containerise both with the same code revision so a resumed checkpoint does not load a different graph definition by accident.

Operationally, LangGraph needs traces around node entry, node exit, state update, checkpoint id and interrupt or approval events. The framework makes those events natural because the workflow is already a graph. Your job is to make them visible in the platform where operators actually look.

Where each framework puts the deployment burden

Show as text

Where each framework puts the deployment burden. Diagram: 7 ordered layers. Google ADK agent code, then Google identity and Gemini access, then Cloud Run, GKE or Agent Engine, then compare with LangGraph (breakpoint), then LangGraph state graph, then Checkpointer and durable store, then API, workers and observability.

#	Layer	Note
1	Google ADK agent code	Prompts, tools and agents sit together.
2	Google identity and Gemini access	Cloud IAM carries much of the load.
3	Cloud Run, GKE or Agent Engine	Pick the Google runtime you already run.
·	compare with LangGraph (breakpoint)
4	LangGraph state graph	Nodes and edges make control flow explicit.
5	Checkpointer and durable store	Required for restart-safe workflows.
6	API, workers and observability	Your runtime owns the production shape.

Which framework should you choose?

Choose ADK when the agent is part of a Google Cloud product and Gemini is the expected model path. The deployment story is cleaner because the framework’s assumptions match the environment: Google identity, Google model access, Google runtime choices and Google documentation. You spend less time designing the platform shape.

Choose LangGraph when the agent is a stateful workflow service whose control flow must be inspectable and portable. The graph is the durable product artefact. You can move model providers, run in your own containers, insert human approvals and resume tasks after failures without treating the agent loop as a black box.

The deciding question is who owns production. If the answer is a Google Cloud application team, ADK will usually feel lighter. If the answer is a platform team that already owns APIs, workers, queues and databases, LangGraph will usually feel more honest because it exposes the moving parts instead of hiding them.