Google’s ADK shows where agent frameworks are heading: code-first, stateful, and built for real systems

Google’s Agent Development Kit, or ADK, is one of the clearest signs yet that agent tooling is maturing.

The core idea is simple: stop building AI agents like chat wrappers and start building them like software. ADK is open source and organized around four parts: agents, tools, runners, and sessions/memory. That structure matters. It pushes teams toward explicit architecture instead of the usual pile of prompts, glue code, and framework hand-waving.

For teams already on Vertex AI, ADK fits neatly into Google’s larger agent stack. For everyone else, the interesting part is the portability story. ADK is pitched as model-agnostic and deployment-agnostic, with LiteLLM support for models beyond Gemini, including OpenAI, Anthropic, Meta, and Mistral. Google plainly wants it to look open while keeping it closely tied to its own cloud.

That’s a sensible strategy. The hard parts of agent systems were never the demo layer. They’re orchestration, state, observability, and failure handling. ADK appears to be built around those problems.

What Google is building

ADK is aimed at engineers building systems with several moving parts, not somebody wiring up a weekend bot.

At the center is a code-first model. You define agents in code. You attach tools in code. You manage execution and memory explicitly. That’s less friendly than visual builders, and for many teams that’s fine. The abstraction boundary is clearer. It matters when an agent needs to call internal APIs, hit a database, carry context across turns, and produce something you can actually audit.

Google breaks ADK into four pillars:

• Agents handle reasoning and decision-making
• Tools let agents interact with external systems
• Runners orchestrate execution
• Sessions and memory keep conversation state and history

That’s a good split. Production systems fail along those same boundaries. Reasoning bugs are different from tool failures. State corruption is a different class of problem from orchestration bugs. If ADK keeps those concerns separate, debugging gets easier.

Pay attention to the Runner

Every agent framework talks about agents. In ADK, the more important piece may be the Runner.

The Runner is the execution layer. It takes a user request, looks up the right session, prepares context, invokes the root agent, manages tool calls, updates state, logs events, and returns the response. That’s the plumbing that usually gets scattered across middleware, callbacks, prompt wrappers, and custom orchestration code.

And that plumbing is where a lot of these systems fall apart.

A model can decide to call a tool. Something still has to:

1. fetch the right session
2. merge prior state with the new request
3. route to the right agent
4. record tool outputs and responses in order
5. persist the updated conversation state
6. recover when one of those steps fails

ADK turns that into a first-class component instead of leaving it as framework residue. For teams building stateful, multi-turn systems, that’s the difference between a prototype and software you can live with.

Google also exposes synchronous and async execution through methods like runner.run() and runner.run_async(). That’s another clue that ADK is meant for real backend workloads, not notebook demos.

Sessions are carrying real weight

The other piece worth taking seriously is Session design.

A session in ADK isn’t just a chat transcript. It includes three useful things:

• identifiers and metadata, including app name and user ID
• an append-only event log
• mutable state as a key-value store

That split between event history and session state is solid engineering.

The event log gives you a chronological record of what happened: user messages, agent responses, tool calls, tool return values. If you care about debugging, auditability, or replay, that matters. The state dictionary is the scratchpad for session-specific memory, such as preferences, in-progress workflow data, or temporary facts that need to survive across turns.

That also says something about how ADK thinks about memory. It’s not treating memory as a vague semantic retrieval layer. It has a plain operational model. That’s less magical and much easier to reason about.

It also brings up the right questions:

• How large can sessions get before retrieval or replay becomes expensive?
• How are state mutations validated?
• What guarantees exist around ordering, retries, and idempotency?
• How do you separate short-term session state from durable business data?

Those questions decide whether your support agent duplicates orders, whether your internal assistant loses workflow context, and whether your logs are useful during an incident.

Why this matters for multi-agent systems

Google is positioning ADK for multi-agent systems that break larger tasks into smaller specialized jobs. That’s a sensible target. Single-agent apps hit a ceiling quickly once you need planning, tool diversity, and tighter context boundaries.

The common pattern looks like this:

• a root agent receives the request
• it delegates to specialized sub-agents
• those sub-agents use tools for search, retrieval, API calls, or computation
• the runner coordinates execution
• the session records what happened

For advanced customer support, internal automation, or research workflows, that structure holds up. A root agent can handle routing and policy. A billing agent can talk to payments APIs. A document agent can search policy docs. A workflow agent can track progress in session state.

That’s cleaner than stuffing one giant prompt with instructions and tool descriptions.

Still, multi-agent systems carry a familiar tax: latency, cost, and coordination overhead. Every handoff adds tokens, time, and another point of failure. Frameworks can make this easier to build. They can’t erase those limits. Teams using ADK should resist building agent graphs when a deterministic workflow plus one LLM call would do the job faster and cheaper.

Open on paper, centered on Vertex

ADK’s model-agnostic story matters. LiteLLM integration means teams can use models from OpenAI, Anthropic, Meta, or Mistral and swap based on price, quality, or policy constraints. That helps, at least in theory.

But the center of gravity is obvious. ADK is tuned for Google’s stack, especially Gemini and the Vertex AI ecosystem. Google wants developers to build with ADK, deploy on its infrastructure, connect to Vertex AI Search and Agent Engine, and stay inside its operational tooling.

That’s not a flaw. It’s the business model.

For engineering leaders, the practical read is straightforward: ADK seems flexible enough to avoid hard model lock-in, but the smoothest path still runs through Google Cloud. If your stack is already there, ADK gets more appealing. If you’re deep in AWS Bedrock or Azure AI, the real test is how portable it feels after a prototype, not how portable it sounds in documentation.

What ADK gets right

A few things stand out.

First, it treats agent development like application development. That should be standard by now, but plenty of tools in this category still act like prompt editors with API hooks attached.

Second, the separation between orchestration, tools, and state gives teams better control over testing. You can reason about a tool separately from an agent. You can inspect session history. You can swap a model without rewriting the whole execution layer.

Third, the append-only event history hints at better observability. If Google exposes those events well, that matters a lot. Most teams shipping LLM systems need traces far more than they need another abstraction for “intelligent workflows.”

Where it gets hard

ADK is for strong engineering teams. Google more or less says so.

The learning curve will be steeper than with UI-first builders. You need to think about session design, tool contracts, orchestration boundaries, persistence, and model behavior at the same time. That’s not beginner-friendly.

There are also security questions that any serious team has to answer before shipping:

• How are tools permissioned?
• How is sensitive session data stored and scoped?
• What prevents prompt injection from triggering high-risk tool calls?
• How do you audit agent actions across users and services?

A framework can give you structure. It can’t fix weak tool design or sloppy access control. In enterprise systems, tools are where the blast radius lives.

And then there’s performance. Stateful runners and multi-agent flows sound good until they hit production latency budgets. If every request fans out into several model calls plus external tools, users will notice. ADK supports complexity. It doesn’t make complexity cheap.

What ADK means right now

ADK matters because it reflects a broader correction in AI engineering.

The first wave of agent tooling leaned hard on autonomy and demos. The current wave is about control: state, traces, orchestration, deployment, and model choice. ADK sits squarely in that camp.

That’s where the better frameworks are going. Serious teams want agents they can test, inspect, and wire into existing systems without depending on brittle framework magic.

ADK won’t rescue bad ideas. It won’t stop teams from overbuilding. But it points in a better direction. More code. Less hand-waving. More system design. Less chatbot theater.

That’s real progress.