Google Agent Development Kit (ADK) 2.0: The 2026 Enterprise Guide

What is Google ADK (Agent Development Kit)?

In short

Google ADK is Google's official open-source, code-first framework for building, evaluating and deploying AI agents. It is released under Apache 2.0, ships in Python, Go, Java, Kotlin and TypeScript, and powers the agent runtime that Google Cloud now sells as the Gemini Enterprise Agent Platform.

Google Agent Development Kit (ADK) is Google's answer to the question every enterprise AI team asked in 2024: what does a first-class agent SDK look like when it ships from the same vendor that ships the underlying model and cloud runtime? It is open source under Apache 2.0, code-first (no low-code detour), and available in five languages — Python, Go, Java, Kotlin and TypeScript. That is the widest language coverage of any major agent framework we track in our best AI agent frameworks guide for 2026.

The release cadence has been aggressive. Python 2.0 reached general availability on May 19, 2026, Go 2.0 followed on June 30, 2026, and Java 1.0 shipped on March 30, 2026. Kotlin and TypeScript continue to ship in parallel. ADK is not a research project — Google Cloud sells the managed runtime as the Gemini Enterprise Agent Platform (renamed from Vertex AI Agent Builder at Google Cloud Next 2026), and the same ADK source deploys unchanged to Cloud Run, Vertex AI Agent Engine or GKE.

Two things make ADK distinctive rather than just another SDK. First, deep Gemini grounding: built-in tools include Google Search, BuiltInCodeExecutor, Vertex AI Search, Google Maps and UrlContextTool — every one wired to work with Gemini model responses out of the box. Second, native interop with both open standards that matter in 2026: Model Context Protocol (MCP) for tool integration and Agent2Agent (A2A) for cross-framework agent delegation.

For Alice Labs' Nordic and European clients, ADK is the default recommendation whenever a workload runs on Google Cloud, the model contract requires Gemini, or the target deployment surface is JVM (Spring Boot) or Go microservices. When neither of those conditions holds, LangGraph or the Claude Agent SDK usually moves faster.

Google ADK 2.0: from hierarchical executor to graph engine

In short

ADK 2.0 replaces the 1.x hierarchical agent executor with a graph-based Workflow Runtime where agents, tools and functions are nodes and every edge is a deterministic transition. The change bounds probabilistic LLM output inside a deterministic control layer — a prerequisite for auditable enterprise agents.

The core change in ADK 2.0 is architectural, not cosmetic. Version 1.x used a hierarchical agent executor: a parent agent invoked child agents through method calls, and control flow was implicit in the class hierarchy. Version 2.0 introduces the Workflow Runtime — a graph engine where agents, tools and functions are individual nodes and every edge is a deterministic transition (per the ADK 2.0 release notes).

The result is that probabilistic LLM output is bounded by a deterministic control layer. When a node decides which edge to follow, that decision is either a function of state (deterministic) or an explicit LLM router call (probabilistic, but scoped and traceable). This is the same architectural insight that made LangGraph and Microsoft Agent Framework so quickly production-viable — Google ADK 2.0 catches up to that model while keeping its language-portability advantage.

The 2.0 runtime ships native primitives for the patterns teams used to write by hand:

• Routing — conditional edges that pick the next node based on state.
• Fan-out and fan-in — parallel sub-graph execution with join semantics baked in.
• Loops — cyclic reasoning without the workarounds that 1.x required.
• State management — immutable session events, replay-safe by design.
• Dynamic nodes and nested workflows — for graphs that need to compose at runtime, essential for enterprise back-office automations.

The migration from 1.x is not free. Custom overrides of the legacy _run_async_impl() method no longer function. Logic that lived there must move to BeforeAgentCallback or AfterAgentCallback. The event schema also grew node_info and output fields, so custom session stores need a migration script before the upgrade. Alice Labs' internal playbook is to run a schema-validation pass on the session store before touching agent code — the failure mode when it is skipped is a silent state loss on graph replay.

Google ADK Java 1.0: the enterprise JVM release

In short

Google ADK for Java 1.0 shipped on March 30, 2026. It introduces an App container that manages application-wide Plugins, native Firestore and Vertex AI session services, event compaction for long context windows, and first-class Spring AI integration — the recommended path for enterprise JVM shops embedding agents alongside Spring Boot services.

The March 30, 2026 Java 1.0 release (per the Google Developers Blog) is the release JVM shops had been waiting for. It fills the gap left by every Python-only framework and gives enterprise Java teams a first-party agent SDK that runs alongside Spring Boot without wrapper layers or FFI bridges.

The changes that matter for enterprise architects:

• App container and Plugin architecture — an App holds application-wide Plugins for logging, guardrails and global instructions. This is the JVM equivalent of what platform teams built by hand around ADK Python 1.x.
• New grounding tools — GoogleMapsTool, UrlContextTool, ContainerCodeExecutor, VertexAiCodeExecutor and ComputerUseTool now ship in the box.
• First-class session and memory services — FirestoreSessionService, VertexAiSessionService and GcsArtifactService replace the InMemory dev backends the moment you leave your laptop.
• Native A2A — RemoteA2AAgent and AgentExecutor let an ADK Java agent delegate to any A2A-speaking agent in another framework without adapter code.
• Spring AI integration — the MessageConverter contract means an existing Spring Boot service can host an ADK agent as a bean, and the observability stack you already run (Micrometer, Actuator) sees it as a normal component.

ToolConfirmation is the human-in-the-loop primitive JVM teams should reach for first — it lets a node pause and require an explicit approval before proceeding, satisfying EU AI Act Article 14 human-oversight requirements without a Slack-based approval detour. Event compaction (see the ops section below) is another Java 1.0 addition that removes a workaround from every long-running agent.

Guillaume Laforge's "Comic Trip" sample agent, published alongside the release, is the recommended reference walkthrough for a first Java 1.0 build. Alice Labs uses it as the training exercise for engineers ramping onto Google Cloud agent projects.

How ADK Tools work: built-ins, MCP and custom tools

In short

ADK Tools are the callable capabilities an ADK agent invokes at runtime. They include built-ins (Google Search, BuiltInCodeExecutor, Vertex AI Search, Spanner, Bigtable, Pub/Sub, GoogleMapsTool, UrlContextTool, ComputerUseTool), any MCP server exposed via McpToolset, and custom Python, Go or Java functions annotated as tools. ADK is the only major agent SDK with first-class MCP client and server support in the same runtime.

The tool model is the single most common reason teams pick ADK over lighter SDKs. It is broad (built-ins cover Google Search, sandboxed Python execution, Vertex AI Search, Spanner, Bigtable and Pub/Sub connectors), extensible (any Python, Go or Java function can be exposed as a tool), and standards-compliant (bidirectional MCP integration plus native A2A). Full reference lives in the official ADK Tools documentation.

MCP integration is genuinely bidirectional and this matters more than it sounds. McpToolset acts as an MCP client — an ADK agent can consume any MCP server (databases, filesystems, third-party SaaS) without writing a per-integration adapter. Separately, ADK tools can be exposed as an MCP server to any MCP client. That second direction is what lets an Anthropic Claude agent or a LangChain agent reach into the same tool surface an ADK agent uses, with no duplicate code.

A2A support closes the horizontal axis: ADK is the only agent SDK with first-class MCP (vertical tool integration) and A2A (horizontal agent-to-agent integration) in the same runtime. In a multi-vendor enterprise stack — which is what most of Alice Labs' clients actually run — that combination removes an entire class of adapter code.

One live constraint teams hit in production: the built-in Google Search tool currently rejects gemini-2.5-pro. If your reasoning-leaf node needs Pro, keep search on a Flash orchestration node and let Pro consume the retrieved context — do not try to attach both. This is a design constraint to plan around, not a bug to file, and it has been stable across the mid-2026 release train.

One useful ADK Java 1.0 addition: output_schema and tool calls can now coexist inside the same agent — a limitation of the earlier release that pushed teams to split agents in half. In 2.0-generation ADK, you can constrain output structure and still expose tools on the same node.

Gemini agent framework: model choice and grounding inside ADK

In short

Inside ADK, gemini-2.5-flash is the default for orchestration nodes (low latency, low cost, wide tool compatibility). Reserve gemini-2.5-pro for reasoning leaves. Vertex Model Garden exposes 200+ models including Anthropic Claude (Opus, Sonnet, Haiku), Meta Llama and Google Gemma — model swap is a single string change in Agent(model=...).

A Gemini agent framework is a runtime that turns Gemini models into tool-using autonomous agents. ADK is Google's official one, and its model handling is deliberately simple: swap the model by changing one string in Agent(model=...). No orchestration rewrites, no per-provider adapter, no prompt-format branch.

The Alice Labs default for orchestration and routing nodes is gemini-2.5-flash. It is low latency, low cost, and works with the widest set of built-in tools (including Google Search — see above). Reserve gemini-2.5-pro for the reasoning leaves where output quality justifies the latency and token spend, and confirm tool compatibility before wiring it in. The full list of currently supported Gemini models is documented in the ADK Gemini model reference.

Because ADK targets Vertex AI as its production home, Vertex Model Garden is a first class citizen. That gives ADK agents access to 200+ models, including Anthropic Claude (Opus, Sonnet and Haiku became first-class citizens post-Cloud Next 2026), Meta Llama and Google Gemma. For teams under EU AI Act pressure to keep options open across providers, this matters: you do not need to rewrite the agent to move from Gemini to Claude if the risk assessment or contract terms change.

Grounding tools break down cleanly by shape of the input problem:

• UrlContextTool — for fetching arbitrary web pages and reasoning over their content.
• GoogleMapsTool — for anything with a spatial or place-based component.
• VertexAiSearch — for RAG over private corpora hosted in Vertex AI Search indexes.
• BuiltInCodeExecutor — for sandboxed Python execution when the model needs to run calculations, not just describe them.

Vertex AI Agents and the Gemini Enterprise Agent Platform rebrand

In short

At Google Cloud Next 2026 (April), Vertex AI Agent Builder was rebranded to the Gemini Enterprise Agent Platform. The platform bundles Agent Studio (visual builder), ADK (code-first SDK), Agent Engine (serverless runtime) and 200+ models. Agent Engine is framework-agnostic — it hosts ADK, LangChain and LangGraph agents without rewrites.

April 2026 clarified Google's positioning. At Google Cloud Next, Vertex AI Agent Builder was rebranded as the Gemini Enterprise Agent Platform (per the Google Cloud announcement). The rename is worth understanding because it settles a naming muddle that had confused enterprise buyers for two years — "Agent Builder" implied a low-code product, when in reality the platform bundled a code SDK, a visual builder, a managed runtime and a model garden.

The four components of the platform, as of mid-2026:

• Agent Studio — the visual builder for teams that want no-code orchestration and configuration.
• ADK — the code-first SDK covered in this guide.
• Agent Engine — the serverless runtime that hosts agents in production.
• Model garden — 200+ models spanning Gemini, Claude, Llama, Gemma and others.

The important detail: Agent Engine is framework-agnostic. It hosts ADK, LangChain and LangGraph agents without rewrites. That matters because it means picking Agent Engine as the runtime does not commit you to ADK as the SDK forever — you can migrate agents between frameworks while keeping the deployment target constant, which flips the usual lock-in calculus on its head.

For regulated workloads, Vertex AI Agent Engine is the recommended target because it inherits Vertex's data residency (EU regions available), IAM and audit controls. In Alice Labs' Nordic financial-services deployments this removes the compliance work that would otherwise have to be done at the ADK layer.

Building a multi-agent workflow with ADK 2.0

In short

ADK 2.0 introduces three LLM agent modes: Chat (multi-turn user-facing), Task (structured delegation) and SingleTurn (one-shot). The dominant enterprise pattern is a coordinator agent in Chat mode delegating to specialised sub-agents in Task mode, so the coordinator never blocks on tool latency.

The 2.0 agent modes matter because they map cleanly to real system boundaries. A coordinator agent runs in Chat mode — it holds the conversation with the user, maintains context across turns, and stays responsive. It delegates work to sub-agents running in Task mode — each sub-agent takes typed inputs, runs its own graph, and returns a typed output. Because the coordinator is not blocked on sub-agent latency, the user experience never freezes while a slow tool call runs behind the scenes.

The SingleTurn mode fills the third slot: one-shot agents used inside batch pipelines or triggered by events, where no conversation history is needed and the invocation is stateless. This is the right mode for scheduled classification jobs, document extraction batches, and webhook responders.

Because Task mode enforces typed input and output, sub-agent hand-offs become testable like any function contract. In Alice Labs' internal test suite for ADK projects, each sub-agent has its own contract test using golden input/output pairs — failures show up in CI, not in production traces. The full multi-agent pattern reference is in the ADK multi-agent documentation.

Two 2.0 features that pull weight in enterprise deployments:

• Human-in-the-Loop as a core primitive — the scheduler can pause execution automatically when a node is marked high-stakes. This is the same architectural idea as LangGraph's interrupt_before, wired directly into the ADK runtime instead of a compile-time flag.
• Nested workflows — sub-graphs compose. For a large enterprise back-office automation with dozens of steps, nested workflows are what make the graph legible instead of a 200-node flat diagram.

For a deeper dive on multi-agent architecture patterns independent of framework choice, see the multi-agent systems guide.

Google ADK Java: your first agent in the JVM

In short

Google ADK for Java 1.0 is distributed via Maven Central under com.google.adk:google-adk. Minimum JVM version is Java 17, Spring Boot integration is officially supported via Spring AI's MessageConverter, and Agent, Tool and Runner are the three classes JVM developers touch first.

The JVM path is deliberately short. Add the Maven dependency, wire an Agent to a Gemini model, register a Tool, hand it to a Runner, and call it. Full walkthrough in the official Java quickstart.

Minimal Maven coordinates:

<dependency>
    <groupId>com.google.adk</groupId>
    <artifactId>google-adk</artifactId>
    <version>1.0.0</version>
</dependency>

The smallest usable agent:

import com.google.adk.agents.Agent;
import com.google.adk.runner.Runner;
import com.google.adk.sessions.InMemorySessionService;

Agent agent = Agent.builder()
    .name("support_agent")
    .model("gemini-2.5-flash")
    .instruction("You handle first-line customer questions.")
    .build();

Runner runner = new Runner(agent, new InMemorySessionService());
var response = runner.run("How do I reset my password?");
System.out.println(response.finalOutput());

Three classes cover 90 percent of JVM developer surface area:

• Agent — the LLM node that reasons, picks tools and produces output.
• Tool — the callable capability wrapper, either a built-in or a custom function annotated as a tool.
• Runner — the execution driver that glues an agent to a session service and drives the run.

Use InMemorySessionService for local dev; switch to FirestoreSessionService the moment the code leaves your laptop. If the hosting service is Spring Boot, the Spring AI MessageConverter integration lets you expose the agent as a normal @Bean, hit it from any controller, and use the observability stack you already run (Micrometer, Actuator, Zipkin).

The Guillaume Laforge "Comic Trip" sample agent published alongside the 1.0 release is the recommended first-build reference — it exercises tools, session state and a multi-turn conversation without depending on Google Cloud services beyond a Gemini API key.

Deploying ADK agents: Cloud Run vs Agent Engine vs GKE

In short

ADK ships three official deployment targets. Cloud Run is the fastest path from laptop to production (single adk deploy command, scale-to-zero). Vertex AI Agent Engine is the managed runtime with built-in session state, tracing and evaluation — recommended for regulated workloads. GKE fits teams already on Kubernetes that need to run agents in a shared VPC alongside other services.

Deployment target is a build-time decision, not a code decision — the same ADK module runs on all three. That is the load-bearing detail: teams can start on Cloud Run to get a running endpoint quickly, then migrate to Agent Engine or GKE when governance, observability or shared-VPC requirements demand it, without rewriting agent logic. Full deployment reference in the official ADK deployment documentation.

ADK Deployment Targets Compared

OpenTelemetry logging and tracing are built into all three targets — you do not wire observability separately. In Alice Labs' Nordic financial-services deployments, the OTel traces feed directly into the client's existing SIEM, which removes a certification detour that self-built observability would trigger.

For a broader operational lens across cloud AI deployment beyond the ADK layer, see the AI production deployment checklist.

Agent2Agent (A2A) protocol: cross-framework agent interop

In short

A2A is an open standard originally announced by Google in April 2025 and contributed to the Linux Foundation in June 2025 under Apache 2.0. As of April 2026, 150+ organisations back the standard, including Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday and IBM. A2A v1.0 (April 2026) added signed Agent Cards, gRPC transport and the AP2 payments extension.

A2A matters because it is the standard that lets a multi-vendor agent stack behave as one system. Google announced A2A in April 2025 and handed it to the Linux Foundation in June 2025 under Apache 2.0 — the same open-source foundation model that made Kubernetes and MCP viable across vendors. The v1.0 spec, published in April 2026 (see the A2A protocol site), added three things enterprise buyers wanted: signed Agent Cards, gRPC transport, and the AP2 payments extension.

The protocol shape:

• Transport — JSON-RPC 2.0 over HTTPS with Server-Sent Events for streaming; gRPC as of v1.0 for high-throughput agent-to-agent calls.
• Auth — OAuth 2.0 mutual auth, JWTs for signed capability tokens, and signed Agent Cards for identity attestation.
• Discovery — Agent Cards describe capabilities, endpoints and auth requirements in a machine-readable form.

The adoption count is the material fact. As of April 2026, 150+ organisations support A2A, including Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday and IBM. That is not the usual "10 partners at launch" number — it is the multi-vendor tipping point at which cross-framework agent delegation stops being a research problem and starts being a procurement question.

Native support in ADK via RemoteA2AAgent means an ADK agent can delegate to a LangChain, Semantic Kernel or Claude Agent SDK agent without adapter code — the remote agent looks like a local sub-agent to the coordinator graph. For enterprise stacks running agents from multiple vendors (which describes most real deployments), this is the wiring that keeps the architecture legible.

When to choose Google ADK: honest fit assessment

In short

Choose ADK when the team is on Google Cloud, needs Gemini-native tool grounding, or must ship in Java or Go. Skip ADK when the team has no Google Cloud footprint and no JVM constraint — LangGraph or the Claude Agent SDK usually move faster. ADK wins the deployment race but LangGraph benchmarks show roughly 47% lower token cost on comparable graphs.

This is the load-bearing section. The honest positioning of ADK, from Alice Labs' production evaluation across 100+ enterprise implementations:

Choose ADK when:

• The team is already on Google Cloud and Gemini is the contracted model.
• The deployment target is JVM or Go — no other major framework matches the language coverage.
• Cross-vendor A2A interop is a hard requirement (ADK + Microsoft Agent Framework are the two SDKs with native A2A).
• The workload needs Vertex AI Search, Google Search grounding, or Google Maps as first-class tools.
• Regulated data must stay in an EU Vertex AI region with IAM and audit controls inherited from the platform.

Skip ADK when:

• The stack has no Google Cloud footprint and no JVM constraint — LangGraph will ship faster in Python.
• The model contract locks you to Claude — the Claude Agent SDK is more idiomatic for Anthropic-native workflows.
• The workload is a two-week prototype and CrewAI's role-based sketch is faster to demo.

ADK wins the deployment race — a Cloud Run agent goes from laptop to public HTTPS endpoint in one CLI command, which no other framework matches at that latency. LangGraph benchmarks, per Requesty's 2026 SDK comparison, show ~47% lower token cost on comparable graphs because explicit edges avoid LLM-driven routing. ADK 2.0's graph engine closes most of that gap but not all — if token cost is the constraint you are optimising, LangGraph still leads.

For prototyping speed, CrewAI remains faster to sketch. For production Gemini + Vertex stacks, ADK is the clear default. For a broader comparison across LangGraph, CrewAI, AutoGen and Claude SDK, see the best AI agent frameworks pillar — this Google ADK guide is the deep dive that hangs off it.

ADK evaluation, observability and event compaction

In short

ADK ships a built-in evaluation harness that runs agent trajectories against golden datasets, native OpenTelemetry tracing on every node transition, tool call and LLM completion, and EventsCompactionConfig (Java 1.0) that summarises long histories to stay within the context window. Session events are immutable and yielded through the framework — direct append is prohibited in 2.0 to prevent race conditions in graph replay.

The ops surface is often the reason enterprise buyers pick ADK over LangGraph. ADK ships evaluation, tracing and event compaction as first-class primitives — not as plugins bolted on later. Full evaluation reference lives in the ADK evaluation documentation.

The built-in evaluation harness runs agent trajectories against golden datasets. It ships out of the box in Python and Java 1.0 — no separate framework, no evals-as-a- service integration required. In Alice Labs' internal delivery process, every ADK project has a golden dataset committed to the repo alongside the agent code, and CI runs the harness on every pull request. This catches regressions in prompt or tool behaviour before they reach staging.

OpenTelemetry traces every node transition, tool call and LLM completion. Point the OTLP exporter at Cloud Trace, Honeycomb, Grafana Tempo or any OTLP collector — no per-vendor wiring. This is the same "observability without integration work" pattern that made LangGraph's LangSmith integration decisive, generalised to any OTel- speaking backend.

EventsCompactionConfig (Java 1.0) summarises long histories so the agent stays within the model's context window. Historically, teams solved this with a hand-rolled summarisation node inserted every N turns. ADK 1.0's compaction primitive replaces that pattern with a runtime concern — a first-class configuration surface rather than a user-space workaround. Long-running enterprise agents that would previously have failed with context overruns now degrade gracefully instead.

The Plugin architecture — LoggingPlugin, ContextFilterPlugin, GlobalInstructionPlugin — lets platform teams enforce guardrails across every agent in an App container. Platform-level rules (redact PII from logs, prepend a compliance disclaimer to every instruction, filter outgoing tool arguments) do not require touching agent code, which is what makes them enforceable at scale.

One 2.0 rule to internalise: session events are immutable and yielded through the framework. Direct append is prohibited. In 1.x, custom code that mutated session events directly worked most of the time and produced silent race conditions on graph replay the rest of the time. 2.0 removes the footgun by making the mutation impossible.

Alice Labs' Google ADK production checklist

In short

Alice Labs' production ADK checklist: pin google-adk to a minor version, default to gemini-2.5-flash for orchestration and reserve gemini-2.5-pro for reasoning leaves, wire OpenTelemetry to a persistent trace store on day one, use FirestoreSessionService from the first staging deploy, and model Human-in-the-Loop nodes explicitly for anything touching customer data.

This is the operational layer, distilled from Alice Labs' 100+ production AI implementations. It is opinionated because production is opinionated — the defaults below are the ones that survived post-mortems, not the ones that read well on paper.

• Pin google-adk to a minor version. The bi-weekly release cadence ships breaking event-schema changes without semantic-version drama. Unpinned installs in CI/CD pipelines cause silent failures that only surface in production traces. Pin, then upgrade on a staged rollout.
• Default to gemini-2.5-flash for orchestration nodes; reserve gemini-2.5-pro for reasoning leaves. Confirm Google Search tool compatibility before wiring Pro anywhere near a search node — as of mid-2026, the built-in Search tool rejects Pro.
• Wire OpenTelemetry to a persistent trace store on day one. Post-hoc debugging of graph runs is impossible without full traces. Cloud Trace, Honeycomb or Grafana Tempo all work — the choice matters less than the "day one" part.
• Use FirestoreSessionService (not InMemory) from the first staging deploy. The state model, TTL, and quota behaviour of a real backend surfaces bugs the InMemory backend hides. Staging on InMemory then flipping to Firestore in production is a known failure pattern.
• Model Human-in-the-Loop nodes explicitly for anything touching customer data. EU AI Act Article 14 requires demonstrable oversight, not a Slack ping. Use ToolConfirmation (Java 1.0) or the equivalent HITL primitive in Python — treat it as a compliance artifact, not a UX pattern.

Two additional habits from Alice Labs' delivery playbook that are worth adopting early. First, commit a golden dataset alongside the agent code and run the ADK evaluation harness on every pull request — regressions in prompt or tool behaviour should fail CI, not surface in production. Second, keep a version-pin changelog in the repo that documents every google-adk upgrade with the schema-diff impact — this is the single artifact that makes ADK upgrades non-scary in enterprise deployments.

If your team is weighing whether to build the ADK expertise in-house or bring in external support, the build vs buy AI framework is the same decision framework Alice Labs uses with clients. For the wider framework landscape beyond ADK — where LangGraph, Claude Agent SDK and Microsoft Agent Framework sit — see the best AI agent frameworks for 2026 pillar.