--- title: Google ADK vs LangGraph: which agent stack deploys cleaner? url: https://deepthinkingai.org/google-adk-vs-langgraph/ published: 2026-09-16 author: Shekhar Singh topic: Agents & Protocols tags: agents, google-adk, langgraph, deployment site: DeepThinking AI --- # Google ADK vs LangGraph: which agent stack deploys cleaner? **Summary:** Google ADK is the cleaner fit when your agent already lives beside Gemini, Vertex AI and Google Cloud identity. LangGraph is the cleaner fit when the hard part is a stateful workflow you want to run on your own runtime. Manual deployment for both starts with packaging the agent as an API. ## Key takeaways - Google ADK optimises for a model-native agent loop with Google Cloud deployment paths and built-in development tooling. - LangGraph optimises for explicit state machines, durable checkpoints and human review points inside long-running workflows. - Manual ADK deployment is easiest when the service account, Gemini access and environment configuration match the target runtime before packaging. - Manual LangGraph deployment depends on selecting persistence first, because checkpoints define how the graph survives restarts. - Choose ADK for Google-centred agent products and LangGraph for portable orchestration that must outlive one model provider. 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](/topics/agents-and-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](/agent-controls-read-vs-write/) 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** | 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. | Read the scores as an operating model. They are a benchmark only for the runtime you are prepared to own. ## 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** 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 --- 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. ADK pushes you toward Google Cloud conventions. LangGraph leaves more runtime decisions in your hands, which is useful only if you want to own them. ## 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. ## Manually deploy either framework without hiding the hard parts Treat the agent as a service before choosing a cloud button. The manual path is mainly about making ownership visible. 1. **Package the agent behind one HTTP boundary**: Expose a small API for chat, task submission or webhook handling. Keep model calls and tool calls behind that boundary so the runtime can be swapped without changing clients. 2. **Pin credentials before building the image**: Create a service account or secret set for model access, tool access and storage. Verify those credentials from the same network where the service will run. 3. **Select persistence before adding users**: ADK may need session or memory storage depending on the agent shape. LangGraph needs a checkpointer for any workflow that must survive a restart. 4. **Containerise the service with a health endpoint**: Build one image, pass configuration through environment variables, and expose readiness separately from a successful model call. A model outage should fail the request. The platform should still know the process is alive. 5. **Add logs around every tool and model boundary**: Record request ids, selected tools, model names, checkpoint ids and approval decisions. Those fields matter more than framework traces when an agent does the wrong thing. 6. **Roll out behind a narrow traffic path**: Start with an internal route or one customer cohort. Keep the previous automation path available until you have replayed failed tasks through the new service. ## Frequently asked questions ### Is Google ADK the same kind of framework as LangGraph? They overlap, but their centres of gravity differ. ADK is an agent development kit aligned with Gemini and Google Cloud services. LangGraph is a graph runtime for stateful agent workflows that can call many model providers and tools. ### Which one is easier to deploy manually? ADK is easier if your target is Google Cloud, because identity, model access and the suggested deployment surfaces line up. LangGraph is easier if you already deploy Python APIs and want the graph to run inside your existing containers, queues and databases. ### Can I run LangGraph without LangGraph Platform? Yes. You can embed a compiled graph in your own API process and provide your own persistence, streaming and worker model. LangGraph Platform adds managed runtime features, but the graph library itself can run inside a normal application. ### Can I run Google ADK outside Google Cloud? Yes, if you package the agent as a normal service and provide model credentials plus tool credentials. The closer you stay to Gemini and Google Cloud identity, the less platform glue you have to replace. ### Which one should a small team start with? Start with the one whose operational owner is obvious. A Google Cloud team shipping Gemini agents should try ADK first. A platform team that already owns workflow services, databases and approval queues should try LangGraph first. ## Sources - [Google Agent Development Kit documentation](https://google.github.io/adk-docs/). Google - [ADK deployment documentation](https://google.github.io/adk-docs/deploy/). Google - [LangGraph documentation](https://langchain-ai.github.io/langgraph/). LangChain - [LangGraph deployment documentation](https://langchain-ai.github.io/langgraph/concepts/deployment_options/). LangChain --- Canonical HTML: https://deepthinkingai.org/google-adk-vs-langgraph/