I built a customer support agent for a fictional UK transport company, UKConnect. The 8-part series builds it on Google's Agent Development Kit (ADK).

Then I built the whole thing again on LangGraph.

Same Gemini model. Same SQLite database and the same policy documents. Same two specialist agents. The only thing I changed was the framework. So it's a fair comparison — and it answers the question I get asked most: which one should I use?

The system is the same shape

Both versions work the same way. Something reads the message and decides what it needs. Then a specialist handles it — one answers from policy documents, one acts on the booking database.

Multi-agent architecture: a customer query reaches the Master Agent, which routes to a Policy Agent (RAG over a vector database) or a Ticket Agent (SQLite database and tools)

Same system, two frameworks

Feature comparison of the Google ADK and LangGraph versions: agent framework, routing, vector database, LLM provider, state management and dependencies

All of that comes down to one thing: who decides where a message goes, and how much of that I write myself.

ADK decides for you

In ADK, the Master Agent is an LlmAgent, and the two specialists are registered under it. I describe each agent and let the framework hand the work over. The model picks who should answer; ADK does the routing. Guardrails sit on before/after callbacks. State lives in the ADK session.

The good part is how little I had to write. I described the agents and the tools, and the framework wired the conversation together. If you've already picked Gemini and Google's stack, that's a lot of plumbing you don't have to own.

LangGraph makes you draw it

LangGraph turns the flow into a graph I draw myself. A low-temperature Gemini call in a router node reads each message and tags it — policy, ticket, or general. Then conditional edges send it to the right node. The specialists are ReAct agents. Policy search runs on FAISS. A MemorySaver checkpointer keeps the state, so a conversation can be resumed or replayed.

LangGraph StateGraph: user input enters a router node that classifies the message as policy, ticket or general, routing to a Policy Agent (ReAct + FAISS), a Ticket Agent (ReAct + SQLite tools), or a general response, then returns a reply

I wrote more code than with ADK. In return I can see the routing, log it, and test it edge by edge. And the state is something I can save and replay.

What actually changed

Routing

This is the whole decision. ADK routes for you — less code, and you trust the model to get it right. LangGraph makes you write the routing — more code, but you can inspect it and test it. When something goes wrong, being able to point at the exact edge that fired is worth a lot. For anything regulated or high-stakes, I want that.

Retrieval

The ADK build uses plain scikit-learn cosine similarity. No extra infrastructure, and fine for a few hundred policy chunks. The LangGraph build uses FAISS, which is worth it once the document set grows. Pick for your data size, not the logo.

State

ADK session state is enough for one conversation. LangGraph's checkpointer makes the state durable — save it per session, resume it later, replay a run to debug it. That matters more in production than in a demo.

Lock-in

ADK is Google-native. It gives you the most for the least when you're all-in on Gemini. LangGraph sits in the wider LangChain ecosystem, so swapping models or reusing tools is easier. Both of mine run on Gemini on purpose — I wanted the framework to be the only thing that differed.

So which one?

Use ADK if you're committed to Google and Gemini and want to write as little orchestration as possible.
Use LangGraph if you want routing you can see and test, state you can replay, or room to move across models and tools.
Most of the time, someone eventually asks "why did it do that?" — and that's when the explicit version pays for itself.

Both are open source

You can read and run both:

For the full ADK walkthrough — architecture, RAG, the database layer, orchestration, testing, ROI — start with the series.

Need this built?

Picking the right framework and shipping it to production — with guardrails, evaluation, and a flow you can actually explain — is what I do at twentytwotensors. Get in touch and tell me about your use case.