Build AI agents with Google ADK: what I learned about orchestration, context and cost

“I want to see my payslip.” “Give me the amount on my last payslip.” “Payslip, now, quick as you like.” Three ways of asking for the same thing. In a system built on linguistic pattern matching, that’s almost three separate use cases.

FERNANDO DE LA TORRE
Software Engineer

It had never crossed my mind to build AI agents with Google ADK until Jesús Relinque — a conversational assistant specialist with twenty years of development behind him — brought it to a Knowledge Sharing session as the end point of a journey that started much earlier: Dialogflow Essentials, then Dialogflow CX and now ADK. Three generations of tooling for the same problem, someone types what they need and the system answers something useful, with completely different decision mechanisms underneath.

Worth pausing here, because “agent” has become an elastic word: today it covers the one writing code just as much as the one running tasks in the background. Jesús’s is a specific kind, the conversational one: someone types, the agent answers, and the answer is judged on the spot. The most demanding case is for latency and predictability.

What I wanted to understand was whether, given that you have to code the agents yourself, adopting ADK buys you anything real or just swaps one kind of complexity for another. The type of agent, the model or the stack doesn’t matter. Underneath there are always the same two questions: how much control you give up and whether the design decisions you get in exchange are the ones you’d have made yourself, and at what point determinism is worth more than intelligence. Now that writing the code is the cheap part, getting those wrong is what turns out expensive. Here’s what I learned following the thread of my own doubts through the session.

From intents to reasoning: three different decision mechanisms

Each of the three generations decides on its answer in a different way:

1. Dialogflow Essentials: linguistic pattern matching over a list of intents. Nothing generative, pure syntactic and morphological analysis of what the user types.
2. Dialogflow CX: a visual state machine, with pages, routes and conditions over session variables. Still no reasoning, but far better at organising complex flows.
3. ADK: an LLM that reasons its way to an answer leaning on context of its own, instead of recognising patterns or following predefined conditions.

Essentials was the starting point, and the payslip example at the top explains neatly why it falls short as soon as the domain grows: tuning the patterns so that “I want to see my payslip” and “give me the amount on my last payslip” don’t collide with each other is manual work, and that effort grows faster than the number of intents. The bottleneck wasn’t the system’s logic; it was the finesse with language. So much so that a new role appeared in the industry: the computational linguist, someone specifically trained in natural language analysis, able to translate the way a real user expresses themselves into the rigid patterns the system needed to recognise it.

CX solves the organisation of those flows, but leaves open something ADK does implement: context. In CX, that memory built up while the user talks is something you maintain and re-inject yourself at every step. With ADK, you still choose where that state lives, but you stop passing it by hand from one agent to the next.

The border between the two eras is in the verb: with Dialogflow you train; with an LLM you guide. Training means feeding the system linguistic patterns, as many variants of the same question as it takes, until it recognises the intent. Guiding is something else: you hand the LLM a set of behavioural guidelines and the model does the rest, with no need for that prior linguistic training. Those guidelines, written in Markdown, follow a logic very close to the instructions we already use to steer a model’s behaviour in any project of our own.

Build AI agents with Google ADK: what the framework actually adds

My first doubt was about lock-in: if I adopt a framework with Google’s name on it, do I end up tied to Gemini, to Vertex and to a Cloud bill, even though I’m the one writing the agent? Jesús took that apart in two sentences. ADK doesn’t tie you to any provider. It’s open and published on GitHub, it’s model-agnostic, and it runs locally with no need for a Google Cloud account. What you pay for, when the time comes, is the LLM you choose to connect to and the infrastructure you choose to deploy on, and neither of those has to be Google’s. So the question wasn’t what it ties you to, but what work it saves you:

• Ready-made connectors for tools: call an API, query a database or plug in an MCP server without writing the integration from scratch.
• Automatic context management: memory is injected at every step of the flow, into both the main agent and the subagents, without you having to save data by hand along the way.
• Model independence: the connector takes whichever LLM you pick.
• Several supported languages, with Python as the dominant option and TypeScript as a valid alternative.

Jesús framed the decision as a question that comes up over and over in development, illustrating it with a CMS like Drupal versus a custom backend: do we build it by hand or take the framework? Accept its rules, whether you like them or not, in exchange for moving faster; or do everything your way, with the time and maintenance that drags along behind it. The fact that what you’re building this time is an AI agent doesn’t change the question.

What you take away from a session about a stack you don’t use every day isn’t the tool itself; it’s the judgement to assess it. Knowing how three different generations of technology handle orchestration, context, and tools is what lets you walk into an architecture conversation with arguments of your own, instead of defaulting to the usual answer. Anyone can write the code, AI included. Deciding what to build and with which pieces is what separates an assistant that works in production from a demo that falls over on the second use case.

Orchestration, subagents and shared state

The architecture Jesús laid out for ADK has three fixed pieces, whatever the use case:

1. An orchestrator agent that receives the flow first and decides where to send it, leaning on the LLM or on a RAG if it needs to.
2. Specialised subagents for specific tasks: one connects to the model, another to the document repository, another to an external API.
3. Communication protocols between agents that optimise the timings, because a complex question can pass through the orchestrator, the RAG and two subagents before coming back, and in a conversational assistant latency shows as much as accuracy does.

The idea is to build yourself a main agent plus little agents that handle much more specific tasks. Divide and conquer.

JESÚS RELINQUE
Software Architect

Context and memory are shared between the main agent and the subagents, and they get injected on their own at every step of the flow. That’s the real advantage over the two previous generations, where that work fell to whoever was implementing the system. Jesús was realistic about the limit: on very complex use cases, it may not end up working well, though his overall experience has been good.

On version control, an ADK agent is still just a microservice you run locally, one you give some guidelines to and where you implement whatever business logic is needed. Versioning, branches, and deployment work as they do in any other application, and Jesús considers that indispensable.

Where the real cost sits, and why that’s a business question

One doubt I brought from an earlier experience with Google’s AI services, where the GPU drove the price and some of them didn’t even let you pick the card, was whether you get to choose the compute when working with ADK. The answer draws a clean line around the problem: ADK doesn’t run inference. All it does is give you the tools to connect to the LLM, to other agents or to your own tools; the compute power is decided wherever you have the model contracted. Treating those two layers as one is the fast route to a wrong cost estimate.

The real cost of an assistant built with ADK splits into three separate blocks, and it was Wilber, an Orbitant colleague and AI engineer, who asked about the ecosystem as a whole:

• The framework, free, with no licences or fees involved.
• The LLM consumption of whichever model you choose, which varies with the model and the volume of use.
• The deployment infrastructure, for example Cloud Run or another managed service, sized according to the scale you expect.

An assistant built on Dialogflow Essentials or CX, with few use cases and well-defined paths, comes out cheap in development time because there’s no LLM to consume. With ADK, you can experiment without spending anything: you download the framework and run an agent locally. The real spend shows up when you define the expected usage and decide where and how much that agent has to scale.

Looked at that way, with each generation adding more capacity to decide, it seems like ADK always wins the comparison, but it isn’t that simple: there are scenarios where the business needs the answer to be predictable before it’s intelligent. With predefined rules, you know that “I want to know the amount on my payslip” will always travel the same path. An LLM, however good, can get it wrong, and there are use cases where that failure costs more than the reasoning contributes.

That’s the judgement a session like this leaves behind, and it travels further than any specific framework: knowing what each architecture offers so you can choose with arguments of your own in front of a client, instead of letting the answer depend on whichever tool you happen to be most comfortable with. The next step is the one Jesús suggested himself, and it’s the one I intend to take: download ADK, run an agent locally, and see first-hand how shared context behaves once the flow gets complicated. When I have results, I’ll write them up here.

Frequently asked questions

Is Google ADK a paid product?
No. The framework is open and free, published on GitHub under the Apache licence. The real cost comes from the consumption of the LLM you connect and from the infrastructure you deploy the agent on.

Does ADK only work with Gemini?
No. It’s model-agnostic: as well as Gemini, it integrates with LiteLLM to connect to models from other providers such as Anthropic or Mistral AI.

Can I try ADK without being a Google Cloud customer?
Yes. You can download the framework, develop your agent and run it locally. Google Cloud only comes into play if you decide to deploy your service there.