Google Agent Development Kit: What It Actually Takes to Ship an AI Agent That Doesn’t Fall Apart in Production

Most teams building AI agents right now are stuck in the same trap. They can get a single agent to answer questions in a demo. They cannot get five agents to hand off work to each other reliably, remember what happened three steps ago, or fail safely when a tool breaks. That gap between “impressive demo” and “production system” is exactly why Google built the Agent Development Kit.

Google introduced the Agent Development Kit, known as ADK, at Google Cloud NEXT on April 9, 2025. It is an open-source framework designed to simplify the full-stack development of agents and multi-agent systems, and it is not a side project. Google describes ADK as part of the technology used across products such as Agentspace and Google Customer Engagement Suite. You are not adopting a toy framework Google might abandon. You are adopting the plumbing Google uses on itself.

But that promise needs a precise qualification: ADK gives you the building blocks for a production system; it does not make the system production-ready by itself. The difficult work appears at the boundaries, between a local development UI and a deployed runtime, between a session and long-term memory, between an MCP tool and a user credential, and between a human approval prompt and a resumable execution.

This guide covers the current ADK 2.0 direction, the architecture, the agent types, a working code example, orchestration patterns, evaluation strategy, deployment options, security layers, three real case studies, and a production readiness checklist you can run before trusting an agent with real users or real side effects.

Version note: This article reflects public ADK material reviewed on September 2026.  ADK changes quickly, and language packages do not necessarily expose identical APIs at the same time. Pin the version you test and recheck the official release notes before copying a command or code example into production.

What Is Google ADK?

Google Agent Development Kit (ADK) is a modular, code-first, open-source toolkit for building, evaluating, and deploying AI agents and multi-agent systems, with built-in support for tool integration, orchestration, memory, evaluation, and deployment across Google Cloud or any container-based environment.

An AI agent, in Google’s own framing, is a software system that uses AI to pursue goals and complete tasks on behalf of a user, rather than simply answering a single prompt and stopping.

The simplest useful mental model is:

• The model supplies language understanding and probabilistic reasoning.
• The agent supplies instructions, tool access, identity, and behavior boundaries.
• The workflow supplies deterministic execution structure.
• The runner manages events and execution.
• The session service stores the conversation and state.
• The deployment target supplies the runtime, networking, identity, and operational controls.

ADK is optimized for Gemini and Google Cloud, but it is model-agnostic and deployment-agnostic. That does not mean every provider, model, language, or runtime offers identical behavior. Tool calling, structured output, streaming, context handling, evaluation, and authentication should be tested per provider and version.

Google’s current ADK home page lists Python, TypeScript, Go, Java, and Kotlin. The exact feature set and package maturity remain language- and release-specific, so verify the language-specific documentation before relying on an API.

ADK is a runtime and SDK for orchestrating AI-driven workers, not a low-code chatbot builder, not a prompt library. It exists because agent development needed engineering discipline, not another chatbot wrapper.

When Should You Use an Agent Framework?

An agent framework is justified when a task requires more than one model response. Typical signals include tool calls, multiple steps, conditional routing, specialist agents, external state, human approval, long-running execution, or repeatable evaluation.

You probably do not need ADK for a single prompt, a fixed template, or a small API call that your application can control directly. If your “agent” is really one model call, two or three tools, and a retry loop, the right answer may be no framework at all, that’s roughly eighty lines of plain code, and a framework there buys you dependency surface without buying you anything the eighty lines didn’t already do.

ADK becomes more useful when the system must combine adaptive reasoning with controlled execution. For example, a support agent might classify a request, search approved sources, inspect an account, ask for confirmation before changing billing information, and produce an auditable response. The model helps decide which path is relevant, while code and policy enforce what the agent is allowed to do.

ADK 2.0: What Changed from the 1.x Mental Model?

ADK 2.0 is not a cosmetic release. The current Python repository calls out breaking changes in the agent API, event model, and session schema. It also emphasizes a graph-based workflow runtime with routing, fan-out/fan-in, loops, retries, state management, dynamic nodes, human-in-the-loop support, and nested workflows.

The older mental model centered on an LlmAgent plus template workflow agents such as SequentialAgent, ParallelAgent, and LoopAgent. Those concepts remain useful for understanding orchestration, but current documentation should not imply that one legacy class is the universal architecture for every language and version.

Before an upgrade, pin the ADK package, Python or runtime version, model SDK, and dependency constraints. Export or back up representative sessions, test event consumers, and run a migration rehearsal. A release that installs successfully can still change the way sessions, events, or workflow nodes behave.

If you are starting a new project in 2026, learn the graph-based workflow model from day one. If you are upgrading an existing project, treat the event model and session schema changes as your highest-risk migration items.

Which ADK Architecture Fits Your Project?

Before choosing between a single agent, a graph workflow, MCP, A2A, or a separate memory service, answer the six questions below. The tool will give you a starting architecture based on the requirements you select. Treat the result as an initial design direction, not a substitute for testing the exact ADK version and deployment environment.

Inside the Architecture: The Components You’ll Actually Touch

If you strip away the marketing language, ADK is built from nine components. Understanding how they connect is the difference between reading documentation and being able to design a system.

Agents are the worker units, each one designed for a specific task, capable of using tools and, depending on architecture, coordinating with other agents.

Tools give an agent abilities beyond text generation: calling APIs, searching for information, running code, or invoking other services. The model chooses which tool to use and with what inputs; the tool itself just runs its designed function.

Orchestration defines how multiple agents execute relative to each other, sequentially, in parallel, in a loop, or through dynamic LLM-driven routing.

Callbacks are custom code snippets that run at specific points in an agent’s execution, used for logging, validation, or modifying behavior without touching the core framework.

Session management handles the context of a single conversation, effectively the agent’s working memory for that interaction.

Artifact management lets an agent save, load, and version files or binary data: images, documents, generated reports.

Code execution gives an agent the ability to generate and run code for calculations or predefined actions.

Planning lets an agent break a complex goal into smaller steps and sequence how to achieve them.

Events are the basic unit of communication inside a session, a user message, an agent reply, or a tool call are all represented as events, and the runner is what manages execution flow based on those events.

Sessions, State, Memory, and Artifacts: Not Interchangeable

These concepts are related but not interchangeable:

• A Session represents a conversation or execution context.
• State stores structured values associated with that context, such as a selected account or workflow status.
• Memory refers to information retrieved across sessions or from a dedicated memory service.
• Artifacts are files or binary objects such as reports, images, audio, and documents.

ADK ships three session backends, and which one you pick determines whether a restart wipes your conversation history:

• InMemorySessionService — stores session data directly in the running process. Right choice for local development; wrong choice for anything else. Restart the container in Cloud Run, and every active conversation is gone.
• DatabaseSessionService — persists sessions to a relational database (PostgreSQL, MySQL, or SQLite), giving you durable storage you manage yourself.
• VertexAiSessionService — a managed option backed by Vertex AI Agent Engine.

For cross-session recall, ADK addresses this through a separate memory service, such as Vertex AI’s managed Memory Bank, which stores conversation history as searchable, semantic memory rather than a raw event log.

The components that get skipped in tutorials, artifacts, callbacks, session backends, are usually the ones that determine whether an agent survives contact with real users and real data volumes.

Tools: What Gives an Agent Its Hands

An agent without tools is just a very articulate autocomplete. ADK groups tools into three categories:

1. Function tools — custom code you write for your specific application.
2. Built-in tools — pre-built capabilities Google ships with the framework, such as Google Search for grounding.
3. Third-party tools — connectors from other providers, spanning code execution, data connectors, observability, and search.

A production tool should define:

1. The allowed input schema and validation rules.
2. The identity and authorization checks performed in code.
3. The data it may read or change.
4. A timeout, retry policy, and idempotency strategy.
5. What the user sees before and after a side effect.
6. An audit record that does not expose secrets.

A tool description is not a security boundary. Treat it as a usability hint for the model, not as authorization. If a user cannot delete a resource, the function must reject the operation even if the model asks for it.

Agent Types: The Decision That Shapes Everything Else

ADK gives you three categories of agents, and picking the wrong one early is one of the costliest architecture mistakes teams make.

The decision rule is simpler than it looks: if you need language understanding and dynamic decisions, start with an LLM agent. If you need complex but predictable orchestration, use a workflow or graph pattern. If neither covers your requirement, usually because of a tailored integration or an unusual control flow, drop into a custom agent.

A reliable default is to start with one agent and one or two tools. Add a workflow when the order or termination rules matter. Add multiple agents only when specialization creates a measurable benefit over a single well-instructed agent.

Agent type is an architecture decision, not a style preference. Choosing workflow agents where you actually need LLM reasoning, or the reverse is the single most common source of unpredictable agent behavior.

A Working Multi-Agent Example: Researcher Hands Off to Writer

Here’s the researcher-then-writer pattern, built with ADK’s documented SequentialAgent primitive and the output_key mechanism it uses to pass data between agents through a shared session state.

Python:

 from google.adk.agents import LlmAgent, SequentialAgent

GEMINI_MODEL = "gemini-2.5-flash"

# --- Sub-agent 1: gathers and structures information ---
# Its final answer is written to session.state["research_notes"]
# because of output_key, so the next agent can read it.
researcher_agent = LlmAgent(
    name="ResearcherAgent",
    model=GEMINI_MODEL,
    description="Gathers and structures information on the requested topic.",
    instruction="""You are a research assistant. Given the user's topic, 
    gather the key facts and structure them as clear bullet points. 
    Output only the structured research notes, nothing else.""",
    output_key="research_notes",
)

# --- Sub-agent 2: reads the researcher's output from shared state ---
# The {research_notes} placeholder is filled in automatically by ADK
# from the state key the researcher agent wrote to.
writer_agent = LlmAgent(
    name="WriterAgent",
    model=GEMINI_MODEL,
    description="Formats research notes into a polished summary.",
    instruction="""You are a technical writer. Using the research notes below, 
    write a concise three-paragraph summary for a business audience.

    Research notes:
    {research_notes}
    """,
    output_key="final_summary",
)

# --- Orchestration: runs researcher, then writer, in that order ---
research_and_write_pipeline = SequentialAgent(
    name="ResearchAndWritePipeline",
    sub_agents=[researcher_agent, writer_agent],
) 

Two details here matter more than the code itself. First, notice there’s no manual plumbing to pass the researcher’s output into the writer’s prompt, output_key writes it into a shared session state, and the {research_notes} placeholder in the writer’s instruction pulls it back out automatically. Second, SequentialAgent is deterministic: it isn’t an LLM deciding whether to call the writer next, it’s a fixed, traceable pipeline.

Quickstart: Running the Agent Locally

To run this locally, create a Python 3.10+ environment and install the package:

bash:

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install google-adk

Put the agent in the directory structure required by the current Python quickstart, then run it:

bash:

adk run path/to/my_agent

The development UI can be useful for iteration:

bash:

adk web path/to/agents_dir

Do not expose the development UI to the public internet as if it were a hardened production API. Add your own authentication, authorization, rate limits, timeouts, logging, and deployment-specific session handling.

Orchestration Patterns: Sequential, Parallel, Loop, and Graph

When you move beyond a single agent, you need to decide how multiple agents execute relative to each other.

Sequential execution

Suitable when one step produces an input for the next. Make the handoff explicit and test what happens when an earlier step returns an empty, malformed, or partial result.

Parallel execution

Useful when independent specialists can run at the same time. Define how results are joined, what happens when one branch fails, and whether partial results are acceptable. Parallelism can reduce wall-clock time, but it can also increase cost, rate-limit pressure, and the number of inconsistent states to reconcile.

Loops and retries

A LoopAgent does not decide on its own when to stop looping, that behavior is explicit in Google’s own documentation. ADK gives you two documented ways to put a leash on that:

1. Max iterations: Set a hard ceiling so the loop terminates automatically after a fixed number of passes.
2. Escalation from a sub-agent: Design a critic that explicitly signals a stop condition, for example, returning a PASS status, so the loop breaks the moment the output meets your bar.

Graph workflows

ADK 2.0’s graph-based workflows let you combine deterministic edges with adaptive agent behavior. Use them when the system needs explicit routing, fan-out/fan-in, retries, human input, or nested execution. Keep the graph understandable: name nodes by responsibility, define state contracts, and make every side effect observable.

For a reliable agent system, every node should have a clear owner for failure. If the model fails, can the node retry? If a tool times out, does the graph continue? If a human never responds, does the task expire? These are architecture questions, not prompt-writing details.

Orchestration flexibility cuts both ways, the same loop pattern that makes self-correction possible is the one that can quietly burn your budget if you don’t pair it with an explicit stop condition.

MCP vs A2A: Two Protocols, Two Different Problems

Two protocols matter here, and conflating them is a common mistake.

Model Context Protocol (MCP), introduced by Anthropic in November 2024, standardizes how an AI system connects to external tools and data sources.

Agent2Agent Protocol (A2A), contributed by Google and now governed by the Linux Foundation, standardizes how independent agents discover, authenticate, and communicate with each other, regardless of which framework built them. ADK has native A2A support.

The clean mental model: MCP connects an agent to its tools. A2A connects an agent to other agents.You’ll likely use both in any serious multi-agent deployment.

Once MCP is used to connect agents to real tools and data, the security question moves beyond protocol selection: teams must define tool-level permissions, token boundaries, authorization checks, and audit controls. Our MCP security guide covers that production boundary in detail.

The implementation boundary is less simple

MCP authentication may be needed during tool discovery, not only when a tool is called. A user-scoped token should not be stored in a process-global connection that can be reused by another user. Transport, credential source, connection scope, token revocation, and concurrent isolation must be explicit.

A2A human approval introduces another boundary: the system must persist the pending action and resume the correct remote execution after approval. A visible confirmation message is not enough. Test approval, denial, expiry, duplicate approval, restart, and remote-agent routing.

MCP security focuses on tool discovery, credentials, transport, and user isolation; A2A also requires task routing and resumable execution. Both need explicit testing.

Human-in-the-Loop: Pausing for Approval Before Anything Irreversible

ADK’s answer to this is a documented ToolConfirmation workflow: a tool calls request_confirmation(), which pauses execution and surfaces a payload to a human for approval; once approval comes back, the tool call resumes with the confirmed input.

“The feature exists” and “the feature is production-hardened for your session backend” are two different claims, and only the first one is currently well-supported by evidence.

Security: Defense in Depth, Not a Checkbox

Google’s own ADK safety documentation frames the core risks explicitly: vague instructions, model hallucination, jailbreaks, direct prompt injection, and, the one that catches teams off guard, indirect prompt injection, where an agent calls a tool that reads an external source containing malicious instructions.

Google’s documented, multi-layered mitigation approach includes:

• Identity and authorization — controlling who the agent acts as, through explicit agent auth and user auth.
• In-tool guardrails — designing tools defensively so they enforce policy themselves. Give the read-only agent a tool that physically cannot write, rather than relying on a prompt instruction the model could be talked out of.
• Callbacks for input/output screening — using before_model_callback and after_tool_callback to inspect and validate what flows into and out of the model.
• Model Armor, Google Cloud’s dedicated screening service, which scans for prompt injection and jailbreak attempts and can redact PII in real time.
• Sandboxed code execution, so generated code runs in isolation.
• Network-level controls, such as VPC Service Controls, so a compromised agent can’t exfiltrate data.

If the agent uses retrieval, remember that vector similarity is not access control. For a deeper treatment of authorization alongside retrieval, see document-level access control in RAG. For identity design around autonomous systems, see securing non-human identities.

There is no single “turn on security” switch in ADK. Skipping any one layer leaves a gap the others weren’t designed to cover alone.

ADK vs LangGraph vs CrewAI: When Each One Is the Wrong Choice

The option every comparison list quietly skips: if your “agent” is one model call and a retry loop, the right answer may be no framework at all.

Framework choice is more reversible than any blog post implies, because the hardest parts, tool definitions, evaluation criteria, security boundaries, largely transfer. For a deeper comparison of data frameworks, see LlamaIndex vs LangChain.

Evaluation: Test the Trajectory, Not Only the Final Answer

Traditional software has unit tests that give you a clear pass/fail signal. Agents introduce variability that makes that binary signal harder to get. ADK’s evaluation approach handles this by having you define upfront what success looks like, which tasks are critical, and which metrics you’ll track.

A good evaluation strategy uses several layers:

1. Contract tests: Does the tool reject invalid or unauthorized input?
2. Trajectory tests: Did the agent choose the expected tools and sequence?
3. Response tests: Is the final answer accurate, complete, and grounded?
4. State tests: Does context persist across turns and restarts?
5. Failure tests: Does the system stop safely after timeouts, malformed tool output, or repeated calls?
6. Security tests: Are credentials isolated and are prompt-injection attempts contained?
7. Deployment-parity tests: Does the deployed runner behave like the local runner?

The official ADK evaluation documentation is the right source for the current eval-set format. A useful evaluation record includes the ADK version, language, model version, prompt, tools, configuration, session service, runtime, and expected result. Without those fields, a passing test becomes impossible to reproduce after an upgrade.

Do not treat a passing final-response test as proof that the production system is safe.

Deployment Options: Choose the Runtime Before You Promise Production

ADK is built around containers. If your infrastructure is on Google Cloud, you can deploy as part of Vertex AI Agent Engine or run it on Cloud Run. If you’re outside GCP, any environment that supports containerization works, including on-prem Kubernetes.

Use the official Cloud Run ADK deployment guide for current prerequisites. A deployment that succeeds once is not proof that updates, sessions, or production traffic will work. Test create and update, retain build logs, pin dependencies, and verify the runtime’s session behavior.

For an additional view of why prototypes fail at deployment boundaries, see harness engineering for reliable AI agents.

Real Deployments: What Companies Actually Built

Theory is cheap. Here’s what three organizations shipped with ADK, what changed, and what the evidence supports.

Case Study 1: Supermetrics — From Data Pipelines to an Autonomous Analyst

The challenge: Supermetrics serves more than 15,000 customers across 132 countries in marketing intelligence. Their core problem wasn’t a lack of data, marketing data volume has grown more than 230% since 2020, it was that marketers couldn’t analyze it fast enough to act on it.

The approach: Supermetrics built a Marketing Intelligence Agent on Google Cloud, powered by Vertex AI Agent Builder and ADK. The agent autonomously manages data connections, fixes errors, and analyzes campaign performance as it happens.

The reported outcome: The customer story reports that ADK helped Supermetrics build agents faster and describes more than 15 hours per month saved per marketer in the relevant workflow. Those are company-published figures for a specific implementation; they are not an independent estimate.

What the case teaches: the highest-leverage ADK deployments compress the gap between “data exists” and “a human can act on it.”

Study 2: Geotab — Standardizing an Enterprise AI Agent Practice

The challenge: Geotab, a fleet-management and telematics company, needed a governable way to build agents across multiple teams.

The approach: Geotab uses Vertex AI Agent Builder with ADK for its AI Agent Center of Excellence, specifically because it lets them orchestrate multiple frameworks under a single governable path.

The reported outcome: In Geotab’s own words, the setup “provides the flexibility to orchestrate various frameworks under a single, governable path to production.” This is a governance claim, not a neutral time-and-motion study.

What the case teaches: for enterprises, the value isn’t just the framework, it’s the shared governance layer that keeps a dozen agent projects from becoming a dozen unmaintainable systems.

Case Study 3: Revionics — Multi-Agent Retail Pricing

The challenge: Retail pricing must balance competitiveness against margin while forecasting the downstream impact of any change.

The approach: Revionics is building a multi-agent system with ADK to help retailers set prices according to their own business logic.

The reported outcome: The multi-agent structure decomposes a genuinely multi-factor decision into specialized agents instead of one monolithic model.

What the case teaches: multi-agent design is most defensible when the domain already contains semi-independent decisions with different inputs, policies, or owners.

Google Cloud also reported more than seven million downloads for the Python package in a November 2025 snapshot. That number is an adoption signal at a particular date, not proof of production success.

Common ADK Problems and How to Diagnose Them

These patterns are drawn from documented GitHub issue reports and community discussions, not from a failure-rate study. Read the official ADK limitations documentation before turning a workaround into a general recommendation.

Seven Mistakes That Quietly Break ADK Projects

1. Starting with an LLM agent when a workflow agent was the right call. If your process is a fixed sequence, wrapping it in an LLM adds cost and unpredictability with no benefit.
2. Writing vague tool docstrings. The model chooses tools based on your descriptions, not your intent.
3. Treating adk web as a production API. Use it for development and test the real API and runtime separately.
4. Routing binary data through conversational context. If it’s a file, it’s an artifact, not a chat message.
5. Shipping a LoopAgent with no max_iterations and no explicit exit condition. This is the mistake that shows up on the invoice.
6. Adding MCP before defining credential scope.Decide whether a connection is per request, session, user, or process.
7. Evaluating only the final answer. Test trajectories, state, security, failure recovery, and deployment parity.

Production Readiness Checklist

Before launch, verify the following in the target deployment:

• ✅ The same model and ADK version used in evaluation
• ✅ Stable app_name, user_id, and session_id behavior
• ✅ Repeated turns, process restarts, and concurrent users
• ✅ Session persistence and cleanup rules
• ✅ Tool authorization independent of model instructions
• ✅ MCP tool discovery and call-time authentication
• ✅ Per-user token isolation and revocation
• ✅ Maximum model calls, loop iterations, retries, and total time
• ✅ Human approval resume, denial, expiry, and duplicate handling
• ✅ Redaction of credentials in logs
• ✅ Rate limits, timeouts, quotas, and graceful degradation
• ✅ A rollback path for package, model, prompt, and runtime changes

Interactive Calculator: Estimating Monthly Labor Savings

If you’re deciding whether an ADK-based agent is worth building, the math usually comes down to hours saved versus hours invested.

Should You Choose ADK?

ADK is a strong candidate when you want a code-first framework, Google Cloud integration, multiple supported languages, agent tools, structured evaluation, and a path from a small agent to graph-based multi-agent workflows.

It is a less obvious choice when your application needs a highly customized runtime that another framework already expresses more directly, when your team cannot absorb a rapidly changing API surface, or when your main problem is data indexing rather than agent orchestration.

The right decision is not “Which framework is best?” It is “Which framework makes the important failure modes visible and testable for this workload?”

About The Author

A Gadallh

Ahmed Gadallah is the Founder and Editor of Vertex Frontier, where he publishes research-driven articles on AI, data science, cloud computing, cybersecurity, software engineering, and emerging technologies, with a focus on technical accuracy, clarity, and practical insights.

View all articles by A Gadallh →