Agent Development Kit (ADK): What It Does

The Agent Development Kit is Google's open-source framework for building AI agents, and the two things most worth knowing about it are the two most often assumed wrong:

• It is model-agnostic, not Gemini-only. The official documentation states ADK "can work with almost any generative AI model," with native Gemini integration plus adapters for other providers, local models, and enterprise-hosted services.
• It covers five languages — Python, TypeScript, Go, Java, and Kotlin. Python is the oldest and has the most samples; the others are real implementations rather than thin ports.

Google describes it as "the open-source agent development framework that lets you build, debug, and deploy reliable AI agents at enterprise scale." The words doing the work there are debug and deploy — ADK's pitch is less about making an agent possible and more about making one operable.

What You Actually Get

Agents and multi-agent composition

The base unit is an LLM-backed agent with instructions and tools. Agents compose — one agent can delegate to another as a sub-agent — which is how ADK expresses multi-agent systems. Nothing exotic, but it's a first-class concept rather than a pattern you assemble yourself.

Graph workflows

ADK 2.0's addition, described in Google's own framing as a way to "weave deterministic code with adaptive AI reasoning." Structured, graph-based orchestration where some steps are fixed code and some are model decisions.

This is the most interesting part of the framework, because it addresses the real production problem: most useful systems are mostly deterministic with a few genuinely uncertain steps. A framework that forces everything through a model wastes latency and predictability. One that lets you draw the fixed parts as a graph and reserve reasoning for the uncertain nodes matches how these systems actually get built. Our take on agentic workflows covers where that line sits.

Tools

The usual capability layer — functions the agent can call — plus a tool-confirmation flow for human-in-the-loop steps. That confirmation flow matters more than it sounds: it's the hook for "ask before you do the irreversible thing," and having it in the framework beats bolting it on.

Evaluation

Built-in, and the reason to take ADK seriously. Evaluation covers criteria, user simulation, and custom metrics — running an agent against defined cases and scoring it.

Most agent frameworks treat this as an afterthought, which is how teams end up with agents whose quality silently drifts. Having it in the box is a genuine argument for the framework, independent of anything else.

Deployment

Run it on your own infrastructure, or deploy to Google Cloud — Agent Runtime, Cloud Run, GKE — without code changes. The portability claim is real, though the smoothest path is unsurprisingly the Google Cloud one.

The Samples

"ADK samples" is the search that brings most people here, and the google/adk-samples repository is the answer — a collection of working sample agents, with the Python set the most complete.

How to use them well:

• Read one end to end before writing anything. The samples show the intended structure, and ADK has opinions about layout that are easier absorbed than inferred.
• Start from the closest sample rather than a blank project. Faster, and you inherit the evaluation scaffolding.
• Don't take a sample to production unmodified. They demonstrate mechanics, not your error handling, permissions, or cost controls.

The adk-python and adk-java repositories are the implementations themselves, and both are readable if you want to see how the loop is actually assembled.

When ADK Fits, and When It Doesn't

Reach for it when:

• You need evaluation built in — the strongest single reason
• Your system is mostly deterministic with some reasoning steps, which graph workflows model directly
• You're deploying on Google Cloud, where the integration path is genuinely shorter
• You need a JVM or Go implementation — this is a real gap in most agent frameworks and ADK covers it
• You want human-in-the-loop confirmation as a framework feature rather than custom code

Skip it when:

• You're learning what an agent is. Start with a provider SDK and write the loop yourself; frameworks hide exactly the mechanics you're trying to understand.
• The task is a fixed sequence. That's a script with a model call in it, not an agent, and no framework improves that.
• You're committed to one provider's ecosystem and using its own SDK, where staying native is usually simpler.
• It's a prototype you'll throw away. Framework setup is overhead you won't recoup.

For the wider comparison, agentic AI frameworks covers how the options differ on control model and maintenance.

The Practical Judgment

The agent framework market has a lot of entrants and most differentiate on ergonomics, which is a weak axis — you can learn any of them in a week. ADK differentiates on two stronger ones: evaluation as a first-class feature, and language coverage beyond Python.

If neither matters to you, the framework choice is close to arbitrary and you should pick whatever your team already knows. If either matters — and evaluation should matter to anyone running agents in production — ADK has a real argument.

The thing no framework solves: an agent is only as good as its tools and the clarity of its task. Teams that struggle with agents are rarely struggling with orchestration. They're struggling because the task was underspecified, the tool descriptions were vague, or nobody defined what success meant. Our guide to building agents covers that groundwork, which no kit substitutes for.

Key Points

• ADK is open source and model-agnostic, not a Gemini-only framework, per Google's own documentation
• Five languages — Python, TypeScript, Go, Java, Kotlin — with Python the most mature and best-sampled
• Graph workflows mix deterministic code with model reasoning, matching how real systems are built
• Built-in evaluation is the strongest reason to choose it; most frameworks treat this as optional
• Start from google/adk-samples, read one fully, and don't ship one unmodified
• Skip it while learning, for fixed sequences, and for throwaway prototypes

If your blocker is running someone else's agent setup rather than writing your own, that's a different problem — Taku mirrors a working AI setup into a desktop workspace and runs it without the environment rebuild. It's in Beta, and the Mac app is available now.

FAQ

What is Google's Agent Development Kit?

An open-source framework for building, evaluating, and deploying AI agents. It provides agents and sub-agent composition, tools, graph-based workflows, built-in evaluation, and deployment to your own infrastructure or Google Cloud.

Is ADK only for Gemini models?

No. The official documentation states it works with almost any generative AI model, offering native Gemini integration alongside adapters for other providers, locally-running models, and enterprise-hosted services.

What languages does ADK support?

Python, TypeScript, Go, Java, and Kotlin. Python came first and has the largest sample collection; the JVM and Go implementations are a genuine differentiator since most agent frameworks are Python-only.

Where do I find ADK samples?

The google/adk-samples repository on GitHub, which holds working sample agents for multiple languages. Read one completely before starting your own — the framework's structure is much easier to absorb from a sample than to infer.

Is ADK better than other agent frameworks?

Better on two specific axes: built-in evaluation and non-Python language support. On general ergonomics the frameworks are close enough that team familiarity should decide. Pick on the axis you actually need rather than on a feature matrix.

Do I need ADK to build an agent?

No. An agent loop is a few dozen lines against any provider's API. A framework earns its place when you need evaluation, multi-agent structure, human-in-the-loop confirmation, and deployment tooling you'd otherwise write yourself.

What's the difference between ADK and an agent protocol like A2A?

ADK is how you build an agent. A protocol defines how separately built agents talk to each other. They operate at different layers, and using one says nothing about whether you need the other.