Google ADK for Product Managers: Building Production AI Agents

What ADK Is and Why Google Ships With It

Google released ADK in April 2025 as an open-source framework for building, debugging, and deploying AI agents at enterprise scale. Unlike frameworks that emerged from the research community, ADK was extracted from Google's production codebases: it is the same SDK that powers Agentspace (Google's enterprise AI workspace), the Vertex AI agent gallery, and Customer Engagement Suite.

That production heritage matters for PMs. When a framework is extracted from live products rather than designed in a vacuum, its abstractions have been pressure-tested against real scale, real error modes, and real enterprise requirements. ADK's authentication handling, session management, and observability hooks exist because Google engineers needed them in production, not because they seemed like good ideas.

LanguagesPython, TypeScript, Java, Kotlin (all production-ready as of mid-2026)

LicenseApache 2.0 (fully open-source, commercially usable)

Model supportModel-agnostic via LiteLLM: Gemini optimized, but Anthropic, OpenAI, Mistral, and local models all supported

Deployment targetsAgent Engine (managed), Vertex AI, Cloud Run, local dev (agent.run())

Internal usersAgentspace, Vertex AI agent gallery, Customer Engagement Suite, Google Cloud Support

The Four Core ADK Primitives

ADK organizes agent development around four primitives. As a PM, these map directly to what you need to spec in a PRD, what your engineering team will ask about, and what your QA process needs to cover.

Agents

What it is: The reasoning unit. An agent wraps a model, a system prompt, and a set of tools. It receives messages, reasons about what to do, and either calls a tool or returns a response. ADK supports three agent types: LlmAgent (general purpose), SequentialAgent (ordered pipeline), and ParallelAgent (concurrent subtasks).

PM Implication: When you write agent specs, you need to define: the model, the system prompt, the tool set, and the escalation behavior when the agent is uncertain. Each of these is a product decision, not an engineering default.

Tools

What it is: The actions an agent can take. Tools are functions the agent calls to interact with the world: query a database, call an API, write a file, search the web. ADK includes built-in tools (Google Search, code execution, file access) and makes custom tool registration straightforward.

PM Implication: Tool design is user story design for agentic products. 'Agent can search Salesforce CRM for a contact' is a tool spec. The list of tools defines the agent's capability surface, which is exactly what you need in a PRD.

Sessions

What it is: The persistent state container for a conversation. A session holds the full history of messages and tool calls across a multi-turn interaction. ADK provides in-memory sessions out of the box and integrates with databases and Vertex AI for persistent sessions.

PM Implication: Session design is the hidden complexity in agent products. What does the agent remember? For how long? Does memory persist across browser closes? These are product decisions that determine user experience, compliance posture, and cost.

Runners

What it is: The execution environment that wires agents, sessions, and tools together. The runner manages the agent loop: receive input, route to the right agent, execute tool calls, collect results, and return output. ADK's InMemoryRunner works for local development; Agent Engine handles production.

PM Implication: Runners are infrastructure. As a PM, you primarily care about the deployed runner's latency, reliability SLA, and cost per invocation. These feed directly into your product's pricing and performance commitments.

Multi-Agent Patterns ADK Makes Native

The most significant design decision in ADK is that multi-agent orchestration is a first-class citizen, not an afterthought. In many frameworks, composing agents requires bespoke glue code. In ADK, you nest agents the same way you nest components in a UI framework. This shapes the product patterns you can realistically spec.

Orchestrator-Worker

A top-level orchestrator agent decomposes a task and delegates to specialized worker agents. Example: a contract review agent delegates to a clause extraction agent, a risk flagging agent, and a summary agent. Each worker has a narrow, testable scope.

Sequential Pipeline

Output of one agent becomes input to the next in a fixed order. Useful for structured workflows: draft an email, then fact-check it, then localize it. ADK's SequentialAgent makes this a one-liner configuration.

Parallel Execution

Multiple agents run concurrently on independent subtasks. Example: generate a product name, a tagline, and a feature list in parallel, then synthesize. ADK's ParallelAgent handles concurrency automatically.

Human-in-the-Loop

An agent pauses and requests human confirmation before completing a high-risk action. ADK supports interrupt signals and resume flows natively. This is the pattern for any agent taking irreversible actions.

For PMs, the multi-agent architecture choice belongs in the PRD. A single agent is simpler to debug and cheaper to run. A multi-agent pipeline has higher latency and more failure points, but enables specialization, parallelism, and much cleaner testing. Specify the pattern explicitly, because the architecture will drive the engineering estimate and the QA plan.

Build AI Agents as a Product Manager

The AI PM Masterclass covers agentic product design, tool spec writing, and multi-agent architectures, taught live by a Salesforce Sr. Director PM.

ADK vs. Other Frameworks: When to Use Which

ADK is not the only serious option for building production agents. The build decision turns on a handful of concrete factors, not on brand affiliation.

Your team is already on Google Cloud and uses Gemini

ADK is the default choice. Native integration with Vertex AI, Agent Engine, and Google's tooling reduces ops overhead significantly.

Use ADK

You need model flexibility across OpenAI, Anthropic, and open-weight models

ADK supports all of these via LiteLLM. But if multi-provider routing is your primary requirement, also evaluate LangChain and LlamaIndex, which have longer track records on heterogeneous model routing.

ADK is viable, compare options

You're building on AWS or Azure with tight cloud lock-in constraints

ADK can run anywhere but is optimized for Google Cloud. AWS Bedrock Agents or Azure AI Agent Service will integrate more cleanly with your existing cloud infrastructure.

Consider cloud-native alternatives

You need a managed, low-ops agent runtime for enterprise deployments

ADK on Agent Engine (managed) is purpose-built for this. Session persistence, scaling, and monitoring are handled for you.

Strong ADK fit

You're a small team building fast and want maximum ecosystem support

LangChain has the largest community and most community-contributed integrations. ADK has a smaller ecosystem but better production reliability on Google infrastructure.

Depends on your primary model provider

What ADK's Architecture Means for Your Product Spec

The shift from LLM-powered features to ADK-style agentic systems changes what a good product spec looks like. Here are the sections that most PRDs miss when teams start building with agent frameworks:

Tool list and permissions table

Every tool an agent can call is a surface area for errors, latency, and security exposure. Spec each tool with: the action it takes, whether it is read-only or write, and the confirmation behavior (auto, human-in-the-loop, or blocked).

Session scope and memory policy

What does the agent remember? Per-turn only? Within a session? Across sessions? Does memory follow the user or the conversation? These decisions have privacy, compliance, and cost implications that need to be made at spec time, not discovered at launch.

Failure modes and fallback behavior

Agents fail in ways that LLM features do not: a tool call times out, a sub-agent loops, an orchestrator hits a dead end. Spec the fallback for each failure mode. 'Returns an error' is not a spec; 'returns a graceful message and routes to human support' is.

Observability and audit trail requirements

Enterprise agents need a full trace of every tool call, every model invocation, and every decision point. ADK outputs these traces natively. Decide at spec time how long you retain them, who can access them, and whether they are customer-visible.

Latency and cost budget

Multi-agent pipelines chain multiple model calls and tool executions. A five-step pipeline at 2 seconds per step is 10 seconds of wall-clock latency. Spec a latency budget per use case and a cost ceiling per invocation. These constrain architecture choices.