A working agent demo takes an afternoon. An agent that survives contact with real users, recovers from a failed tool call, remembers what happened two turns ago, and reaches production without a rewrite takes considerably longer.
That gap is what Google was aiming at when it open-sourced the Agent Development Kit at Cloud Next in April 2025. ADK is code-first, Apache 2.0 licensed, and Python-first, with Java support arriving later. It is not a no-code builder and not a hosted product you log into. It’s a library, a CLI, and a set of deployment hooks that carry an agent from a local folder to Vertex AI Agent Engine or Cloud Run.
What the Google Agent Development Kit actually is
Google already had Vertex AI Agent Builder, the console-driven tool for wiring prompts to data stores. ADK sits underneath that, built for people who want agent logic in Git alongside the rest of the application. You define agents as Python objects, run them locally with a browser UI that exposes every model call and tool invocation, and deploy with a single command.
It ships optimised for Gemini models, though you can point it elsewhere through LiteLLM. The honest framing: if you’re already on Google Cloud, ADK feels native. If you’re not, it still works, but you’ll spend more time on the plumbing around auth, session storage, and deployment targets.
The four pieces you actually touch
Agents
Everything starts with LlmAgent, usually aliased to Agent. You give it a name, a model string like gemini-2.5-flash, an instruction, and a list of tools. The instruction is where the real engineering happens. ADK passes it as the system prompt, and the model picks tools based on their signatures and docstrings.
Tools
Any plain Python function can be a tool. ADK reads the type hints and docstring to build the schema, so a function called get_order_status(order_id: str) with a clear description just works. Beyond your own code, there are built-in tools for Google Search grounding, sandboxed code execution, Vertex AI Search over private data, and BigQuery. MCPToolset connects to Model Context Protocol servers, which means the growing catalogue of community MCP tools plugs in without custom glue.
Sessions and state
A session holds conversation history plus a state dictionary that persists across turns. ADK ships in-memory, database-backed, and Vertex AI session services, so the same agent code runs locally with zero setup and in production against a managed store. State keys are scoped by prefix, letting you separate user-level facts from app-level data. That matters the moment a second user shows up.
The runner
The runner is the loop that takes a message, calls the model, executes any tool calls, and streams back events. You rarely touch it directly, but it’s what adk web and adk run wrap, and it’s where callbacks attach. Callbacks fire before and after agents, models, and tools, which makes them the natural home for logging, guardrails, caching, and input validation.
Multi-agent systems without the spaghetti
Single agents hit a ceiling fast. Once instructions run past a page or two, model accuracy drops and tool selection gets flaky. ADK’s answer is composition, and it gives you three patterns out of the box:
- Sub-agents and transfer. An LlmAgent can list other agents as
sub_agents. A coordinator hands the conversation to a billing specialist or a returns specialist by callingtransfer_to_agent, and control follows the handoff. - Sequential and parallel workflows.
SequentialAgentruns children in order: fetch, then summarise, then write.ParallelAgentfans out when tasks don’t depend on each other. - Loop agents.
LoopAgentrepeats a sub-agent until a condition fires or a max iteration count is hit, which is how you build a critique-and-revise cycle.
For agents living in different processes, or belonging to different companies, ADK supports the Agent2Agent protocol announced alongside it. A2A defines how agents advertise capabilities and delegate tasks over HTTP. It’s early, but it’s the clearest bet yet on a standard for machine-to-machine handoffs, and it fits the broader shift in how the web is being rebuilt for machine readers and agent consumers.
The daily loop: build, inspect, evaluate, ship
Development happens through the CLI. adk create scaffolds a project with an agent folder, an __init__.py, and a .env file. adk web spins up a local browser interface that shows the full event trace: the prompt sent, each tool call with its arguments and result, and token counts. When something goes sideways, that trace is usually the fastest route to the cause.
Evaluation is the step most teams skip and later regret. ADK lets you define eval sets, sample conversations with expected tool calls and expected response traits, then run them with adk eval. Change a system prompt, rerun the set, see what broke. It won’t replace real user testing, but it catches regressions that are otherwise invisible until someone complains.
Deployment is where the Google integration pays off. adk deploy cloud_run containerises the agent and pushes it up. Vertex AI Agent Engine takes the same code and supplies managed sessions, memory, and scaling. GKE is there for teams that want the cluster. Nothing in the agent code changes between the three.
How it compares to the alternatives
ADK isn’t the only option, and choosing the wrong framework costs weeks.
LangChain still has the widest integration surface: hundreds of connectors, vector stores, and document loaders, plus LangGraph for stateful graph workflows. It’s heavier, and abstractions shift between minor versions. ADK is narrower and more opinionated, with a smaller but steadier core.
If your team lives in type hints, PydanticAI deserves a serious look before you commit. It brings FastAPI’s validation-first feel to agents and gives you structured outputs almost for free. ADK’s edge is the deployment story and the multi-agent primitives. PydanticAI’s is developer ergonomics and predictability.
For voice, ADK isn’t the tool. Real-time speech needs different plumbing entirely: turn detection, interruption handling, low-latency audio streaming. That’s why frameworks like LiveKit Agents exist. A common pattern is a voice front end handing off to an ADK agent for the reasoning-heavy part.
When ADK is the right call
Reach for the Google Agent Development Kit when you’re building on Gemini or already inside Google Cloud, when you need several agents cooperating rather than one enormous prompt, and when you want a real deployment path instead of a notebook. The built-in tracing and eval tooling alone save more time than most teams expect going in.
Look elsewhere if you need dozens of third-party integrations on day one, if your workload is voice-first, or if you’re anchored to AWS or Azure and don’t want the GCP gravity. The framework is young, under a year old at the time of writing, and the documentation has moved around. Budget time for reading source when the reference pages lag behind a release.
What makes it worth learning now is the shape of the thing. Agent frameworks are converging on the same four primitives: typed tools, explicit state, composable agents, and evaluation loops. ADK implements all four without much ceremony, and the concepts transfer even if you eventually swap frameworks. Teams that learn the primitives once, properly, stop rewriting their agent stack every six months.