Google Agent Development Kit (ADK) in production 2026: from Cloud Next launch to graph workflows across five languages

Fifteen months ago the Agent Development Kit did not exist outside Google. Today it is the framework behind Gemini Enterprise agents, the six specialist agents Nokia embedded into its Autonomous Networks product, and thousands of open-source projects that ship with a google-adk or @google/adk dependency. ADK started as a Python drop at Google Cloud NEXT 2025, hit 1.0 soon after, added TypeScript, Go, Java, and Kotlin during the year, and reached 2.0 for Python on May 19, 2026 and for Go on June 30, 2026. This article is how we use ADK on client engagements: what the core primitives actually do, how the 2.0 graph runtime changes the shape of the code, and how ADK compares to LangGraph, CrewAI, and the OpenAI Agents SDK for production work.

Why ADK became a serious production choice in one year

The pitch is direct. ADK is the same framework Google runs inside Agentspace and the Customer Engagement Suite (CES), and it is open source under Apache 2.0. That is a rare combination in the agent space: most of the frameworks that ship with Google-scale production usage are proprietary, and most of the open-source frameworks are hobby projects that never touched a real workload. ADK is the exception. The Python SDK crossed 15,000 GitHub stars in less than a year, TypeScript hit 0.2.0 in February 2026, Go and Java reached 1.0, and Google shipped a second major version of Python before most competitors shipped their first.

The framework is deploy-anywhere by design. You can run an ADK agent in a plain Python or Go process, containerize it and drop it on any Kubernetes cluster, or take Google’s managed path through Agent Runtime on the Gemini Enterprise Agent Platform (the product formerly known as Vertex AI). The trade-off is the same one every open framework asks you to make: full flexibility if you own the ops, or a one-command deploy if you hand the runtime to Google.

The 2025 to 2026 timeline

April 9, 2025: Google announces the Agent Development Kit at Cloud NEXT 2025 as an open-source Python framework. The first release ships with LlmAgent, function tools, Google Search and code execution built in, plus the three workflow agents: SequentialAgent, ParallelAgent, and LoopAgent.
Mid-2025: ADK 1.0 GA for Python. The framework becomes production stable. Google ships the adk web visual UI for local debugging, the eval command for regression testing, and one-command deploy to Vertex AI Agent Engine.
Late 2025: ADK 1.0 for Java lands, followed by Go 1.0. The Python SDK gets richer MCP tool support and native A2A protocol integration through to_a2a().
February 27, 2026: The ADK Tools and Integrations Ecosystem launches with curated connectors for GitHub, GitLab, Jira, Confluence, MongoDB, Pinecone, Chroma, Qdrant, GoodMem, Notion, Linear, Asana, Daytona, Postman, and Restate, plus five observability platforms (AgentOps, Arize AX, Freeplay, MLflow, Monocle). The MLflow connector uses OpenTelemetry ingestion, making ADK an OpenTelemetry-native runtime.
March 2026: TypeScript SDK reaches 0.2.0 with LlmAgent, tool functions, and A2A support. ADK 2.0 Alpha 1 for Python opens for early testing: the shift from a hierarchical agent executor to a graph-based workflow engine.
May 19, 2026: ADK Python 2.0 GA. The workflow runtime is now the default, agents are nodes in a graph, dynamic orchestration lets you write branching in plain Python, and human-in-the-loop is a first-class primitive.
June 22, 2026: Nokia and Google Cloud announce a six-agent rollout inside the Nokia Assurance Center, all built on ADK. Nokia reports 50% to 80% faster network problem resolution.
June 30, 2026: ADK Go 2.0 GA. The Go SDK gets the same graph runtime as Python, with typed function nodes, emitting function nodes, agent nodes, tool nodes, join nodes, dynamic nodes, and parallel workers.

Core concepts: Agent, Tool, Runner, Session, Event

Five primitives carry the whole framework in 1.x and remain the base in 2.0. An Agent is a role, an instruction, a model, a set of tools, and (optionally) a set of sub-agents. A Tool is a Python or Go function the agent can call, an MCP tool exposed by a remote server, or another agent wrapped as an AgentTool. The Runner drives the event loop: it takes user input, calls the agent, streams tool calls and model responses back as events, and persists them in the session. A Session is the durable memory for a single conversation - user id, session id, state dictionary, and the ordered event history. An Event is the unit of work: a user message, a model response, a tool call, or in 2.0 a graph node emission.

ADK execution model (1.x and 2.0)

bash

+----------------------------------------------------+
|  Runner                                            |
|                                                    |
|   +------------+       +------------------------+  |
|   |  User      |------>|  Session Service       |  |
|   |  Input     |       |   - state dict         |  |
|   +------------+       |   - event history      |  |
|                        +-----------+------------+  |
|                                    |               |
|                                    v               |
|                        +------------------------+  |
|                        |  Agent (root)          |  |
|                        |   - LlmAgent           |  |
|                        |   - Sequential/        |  |
|                        |     Parallel/Loop      |  |
|                        |   - sub_agents[]       |  |
|                        |   - tools[]            |  |
|                        +-----------+------------+  |
|                                    |               |
|                        +-----------+------------+  |
|                        |  Model provider        |  |
|                        |   - Gemini / LiteLLM   |  |
|                        |     (Anthropic, OpenAI,|  |
|                        |     Mistral, Meta ...) |  |
|                        +-----------+------------+  |
|                                    |               |
|                                    v               |
|                        +------------------------+  |
|                        |  Events stream         |  |
|                        |   (async generator)    |  |
|                        +------------------------+  |
+----------------------------------------------------+

The smallest useful agent is five lines. The example below is a research agent that can call the built-in Google Search tool.

src/agents/researcher/agent.py

python

from google.adk.agents import LlmAgent
from google.adk.tools import google_search

root_agent = LlmAgent(
    name="researcher",
    model="gemini-2.5-flash",
    instruction=(
        "You help users research topics thoroughly. "
        "Cite every claim with a source URL."
    ),
    description="Researches topics and returns cited notes.",
    tools=[google_search],
)

Four details in that snippet carry the production work. The name is what the framework uses to route delegations and to label events in traces, so it has to be unique across the agent tree. The description is what other agents read when they decide whether to hand off, which makes it the most load-bearing string when you compose agents. The instruction is the system prompt for this agent only; sub-agents get their own. And tools=[google_search] is what turns the agent into more than a prompt: the framework handles the tool-calling loop, the parse of the function response, and the retry on failure.

Workflow agents: Sequential, Parallel, Loop

The step past a single agent is a workflow agent. ADK 1.x ships three of them and 2.0 keeps them as convenience wrappers on top of the graph runtime. SequentialAgent runs its sub-agents one after another and threads the previous output into the next agent’s context. ParallelAgent fans out to sub-agents concurrently and gathers the results. LoopAgent re-runs its sub-agents until an exit condition triggers - either a max iteration count or an agent that emits an escalate event.

The Google Cloud trip planner walkthrough is the cleanest showcase. Three specialist agents (flight, hotel, sightseeing) run in a fan-out plus fan-in pattern under a root SequentialAgent, with a ParallelAgent pulling flight and hotel data concurrently and a summariser that collects the results.

src/agents/trip_planner/agent.py

python

from google.adk.agents import (
    LlmAgent, SequentialAgent, ParallelAgent,
)

flight_agent = LlmAgent(
    model="gemini-2.5-flash",
    name="FlightAgent",
    description="Flight booking agent.",
    instruction=(
        "You are a flight booking agent. "
        "Return a JSON object with airline, price, times."
    ),
    output_key="flight_result",
)

hotel_agent = LlmAgent(
    model="gemini-2.5-flash",
    name="HotelAgent",
    description="Hotel booking agent.",
    instruction=(
        "You are a hotel booking agent. "
        "Return a JSON object with hotel, price, nights."
    ),
    output_key="hotel_result",
)

sightseeing_agent = LlmAgent(
    model="gemini-2.5-flash",
    name="SightseeingAgent",
    description="Sightseeing information agent.",
    instruction=(
        "Return the top three sights near the destination "
        "as a JSON list of name, category, and open hours."
    ),
    output_key="sights_result",
)

plan_parallel = ParallelAgent(
    name="ParallelTripPlanner",
    sub_agents=[flight_agent, hotel_agent],
)

trip_summary = LlmAgent(
    model="gemini-2.5-flash",
    name="TripSummaryAgent",
    instruction=(
        "Summarise the trip using flight_result, hotel_result, "
        "and sights_result from session state."
    ),
    output_key="trip_summary",
)

root_agent = SequentialAgent(
    name="PlanTripWorkflow",
    sub_agents=[sightseeing_agent, plan_parallel, trip_summary],
)

Three details make this production-ready. The output_key field on each sub-agent tells the framework to store the result under a named key in the session state; the summariser then reads those keys directly, so the handoff is typed rather than parsed out of prose. The ParallelAgent is a genuine asyncio.gather under the hood, so the flight and hotel lookups happen at once and the walltime is the slower of the two. And composing a ParallelAgent inside a SequentialAgent is the standard fan-out plus fan-in pattern for any pipeline with independent steps.

Agents as tools: hierarchies without lock-in

The other composition path is AgentTool: wrap a specialist agent as a callable tool and pass it into a coordinator. This shape works better than sub-agent delegation when the coordinator needs to stay in the loop, call the specialist more than once, and then continue reasoning with the result. The Google Cloud trip planner post walks through the upgrade path from a plain sub_agents list (where the coordinator hands off and cannot come back) to the tool pattern (where it keeps control).

src/agents/coordinator/agent.py

python

from google.adk.agents import LlmAgent, agent_tool

flight_tool = agent_tool.AgentTool(agent=flight_agent)
hotel_tool = agent_tool.AgentTool(agent=hotel_agent)
sightseeing_tool = agent_tool.AgentTool(agent=sightseeing_agent)

root_agent = LlmAgent(
    model="gemini-2.5-pro",
    name="TripPlanner",
    instruction=(
        "You are a trip planner. Call the flight, hotel, "
        "and sightseeing tools in the order that best "
        "answers the user's request. Combine the results "
        "into a single itinerary."
    ),
    tools=[flight_tool, hotel_tool, sightseeing_tool],
)

The switch from sub_agents=[...] to tools=[AgentTool(...), ...] is a small code change with a large behavioural one: the coordinator now decides the call order, can call the same specialist twice, and can weave tool calls together with its own reasoning. The trade-off is cost. Every tool call adds a round-trip through the coordinator’s model, so this pattern is more expensive per run than a Sequential or Parallel workflow with the same set of specialists.

Model choice: Gemini first, LiteLLM for the rest

ADK is optimised for Gemini but not tied to it. The default path is a Gemini model string (gemini-2.5-flash, gemini-2.5-pro, or the newer experimental releases), which the framework wires to either Google AI Studio (for API-key access) or Vertex AI (for enterprise auth and audit). Every other provider goes through LiteLLM: Anthropic, OpenAI, Mistral, Meta, AI21, plus local models via Ollama. The pattern is the same everywhere.

src/agents/multi_model.py

python

from google.adk.agents import LlmAgent
from google.adk.models.lite_llm import LiteLlm

planner = LlmAgent(
    model="gemini-2.5-pro",
    name="Planner",
    instruction="Plan the work. Delegate to workers.",
)

worker_openai = LlmAgent(
    model=LiteLlm(model="openai/gpt-5.1-mini"),
    name="WorkerOpenAI",
    instruction="Do the specific step assigned.",
)

worker_anthropic = LlmAgent(
    model=LiteLlm(model="anthropic/claude-4.7-sonnet"),
    name="WorkerAnthropic",
    instruction="Do the specific step assigned.",
)

worker_local = LlmAgent(
    model=LiteLlm(model="ollama/llama-4-8b"),
    name="WorkerLocal",
    instruction="Do the specific step assigned.",
)

The practical rule is: pin the model per agent, not per workflow. The coordinator or planner runs on the bigger model because its output steers the whole run; the workers run on the cheap or local model because their prompts are narrow. Teams that skip this end up paying pro-tier prices for every step in a Sequential workflow that could have been served by a smaller model on the leaves.

MCP and A2A: talking to the rest of the agent world

ADK talks two cross-vendor protocols out of the box. The Model Context Protocol (MCP) is how ADK agents pick up remote tool servers, and the Agent2Agent (A2A) protocol is how ADK agents call, and expose themselves to, agents in other frameworks. Both are first-party in ADK: MCP through the MCPToolset class, A2A through the to_a2a() helper that lifts any ADK agent into an A2A server.

src/agents/mcp_agent.py

python

from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool import MCPToolset, StdioServerParameters

filesystem_mcp = MCPToolset(
    connection_params=StdioServerParameters(
        command="npx",
        args=["-y", "@modelcontextprotocol/server-filesystem", "/data"],
    ),
)

agent = LlmAgent(
    name="doc_agent",
    model="gemini-2.5-flash",
    instruction=(
        "Read and summarise files under /data. "
        "Only touch files you were asked about."
    ),
    tools=[filesystem_mcp],
)

A2A is the other direction. Once an ADK agent is wrapped with to_a2a(), it exposes an A2A-compliant HTTP endpoint that any other A2A client (CrewAI, LangGraph, the OpenAI Agents SDK, the Microsoft Agent Framework) can call. The same agent artefact serves internal tools and external partners without a rewrite. This is the same story we covered in the a2a-protocol-cross-vendor-agents-2026 article, just from the ADK side.

ADK 2.0: the graph runtime and why it matters

The shift from 1.x to 2.0 is the biggest change in the framework so far. In 1.x, agents were the executors and the workflow agents were the only path to composition. In 2.0, everything is a node in a graph, and the graph engine is the executor. Agents, tools, and plain functions all live under a single BaseNode contract, edges route between them, and the engine handles concurrency, state persistence, retries, and pauses for human input.

The direction is the same one LangGraph took two years earlier and the one the Claude Agent SDK is taking with sub-agents plus skills. The move matters because it makes durable execution, cyclic workflows, and human-in-the-loop into first-class primitives rather than patterns you have to build. A workflow that pauses for a manager to approve a refund, resumes an hour later, and passes the human’s input into the next node is a few lines of graph code in 2.0; in 1.x it was a session-state hack.

src/workflows/refund_flow.py (ADK 2.0)

python

from google.adk.workflows import (
    Workflow, function_node, agent_node, join_node,
    StringRoute,
)
from google.adk.workflows.hitl import request_human_input

classifier = agent_node(classifier_agent)
lookup = function_node(lookup_order)   # plain typed Python
approver = function_node(
    lambda ctx, order:
        request_human_input(
            ctx,
            question=f"Approve refund for {order.id}?",
            schema=ApprovalSchema,
        )
)
issue = function_node(issue_refund)
reject = function_node(record_rejection)

wf = (
    Workflow(name="refund_flow")
    .add_edge(classifier, lookup, StringRoute("refund"))
    .add_edge(classifier, reject, StringRoute("not_refund"))
    .add_edge(lookup, approver)
    .add_edge(approver, issue, StringRoute("approved"))
    .add_edge(approver, reject, StringRoute("denied"))
)

# wf is an agent. It runs in the same Runner as any other
# ADK agent, and the graph pauses durably at the approver.

Three properties of the 2.0 engine change how you design real workflows. First, the graph pauses durably: when the approver node calls request_human_input, the state is persisted, the process can restart, and the workflow resumes when the human replies (even across process restarts). Second, retries are built in: each node carries a RetryConfig with exponential backoff and jitter, so you no longer wrap tool code in a manual try or except loop (and if you do, the 2.0 docs warn that catching BaseException breaks the HITL pause mechanism). Third, observability is native: every node emits OpenTelemetry spans, so the workflow shows up in Cloud Trace, MLflow, Arize AX, or any OTel-aware backend without extra instrumentation.

Five languages, one contract

The five-language rollout is the other thing that sets ADK apart from most agent frameworks. Python is the reference, TypeScript is the web-first path, Go is the SDK teams pick when they already run agent code inside their existing Go services, Java and Kotlin are the enterprise picks for teams on Spring or Ktor. The API surface is the same across all five, and the interrupt format is shared, so a Python workflow can be paused, the state serialised, and the run resumed by a Go worker on a different node.

src/agents/researcher.ts (TypeScript)

typescript

import { LlmAgent, GOOGLE_SEARCH } from "@google/adk";

export const researcher = new LlmAgent({
  name: "researcher",
  model: "gemini-2.5-flash",
  instruction: "You help users research topics thoroughly.",
  description: "Researches topics and returns cited notes.",
  tools: [GOOGLE_SEARCH],
});

ADK Go 2.0 workflow node types

bash

Function node        typed Go function            input -> output
Emitting function    fn + emit callback          streams events, pauses
Agent node           any agent.Agent             LlmAgent as a step
Tool node            any tool.Tool               a tool as a step
Join node            fan-in barrier              wait for all predecessors
Dynamic node         plain Go orchestration      RunNode(...) in a loop
Workflow node        embedded sub-workflow       graphs compose
Parallel workers     one node * many items       aggregate results
State-bound node     Params from session state   no manual plumbing

Two things are worth calling out about the Go release. First, the ADK Go 2.0 announcement (June 30, 2026) landed with a iter.Seq2-based event stream that integrates naturally into idiomatic Go services - the runtime does not force a special harness or a new server. Second, the interrupt format is shared with Python, so a graph paused for HITL in Python can be resumed in Go, which is exactly what teams with mixed-language codebases have been asking for.

Deployment: Agent Runtime, Cloud Run, or your own container

ADK does not lock you into Google Cloud, but it makes the Google path the shortest. The three deployment options in production are Agent Runtime on the Gemini Enterprise Agent Platform (fully managed, one-command deploy, built-in auth and Cloud Trace), Cloud Run or GKE (containerised, you own the ops but you get the rest of Google Cloud), and a container on any Kubernetes cluster or bare VM (no Google Cloud dependency at all).

src/deploy/agent_engine.py

python

import vertexai
from vertexai import agent_engines
from google.adk.agents import LlmAgent

vertexai.init(
    project="my-gcp-project",
    location="us-central1",
    staging_bucket="gs://my-adk-staging",
)

root_agent = LlmAgent(
    name="assistant",
    model="gemini-2.5-flash",
    instruction="You are a helpful assistant.",
)

# One-command deploy to Vertex AI Agent Engine
remote_agent = agent_engines.create(
    agent_engine=root_agent,
    requirements=["google-adk>=2.0"],
    display_name="production-assistant",
)

print("Deployed to:", remote_agent.resource_name)

Cloud Run deployment

bash

# Package with the ADK CLI
adk deploy cloud-run \
  --project my-gcp-project \
  --region us-central1 \
  --service assistant \
  --path ./src/agents/assistant

# Or containerize manually and deploy anywhere
docker build -t gcr.io/my-gcp-project/assistant:v1 .
gcloud run deploy assistant \
  --image gcr.io/my-gcp-project/assistant:v1 \
  --region us-central1

The rule we use is: start on Cloud Run for anything under a hundred requests per second, move to Agent Runtime once you need managed session storage, built-in auth flows, and Cloud Trace observability without instrumentation, and pick your own container on Kubernetes only when you have a hard requirement to run inside your own VPC without the Vertex AI control plane in the middle.

The ADK Tools and Integrations Ecosystem

The February 27, 2026 release of the ADK Tools and Integrations Ecosystem was the moment ADK stopped looking like just a framework and started looking like an execution layer. The announcement shipped curated connectors in four categories: code and development (Daytona, GitHub, GitLab, Postman, Restate), project and work management (Asana, Atlassian, Linear, Notion), data and memory (Chroma, MongoDB, Pinecone, GoodMem, Qdrant), and observability (AgentOps, Arize AX, Freeplay, MLflow, Monocle).

The MLflow integration is the one to watch. ADK emits OpenTelemetry spans natively for agent runs, tool calls, and model requests, and MLflow 3.6.0 or newer ingests them through OTLP. That means agent behaviour flows into the same observability pipelines as infrastructure metrics and application traces, which is exactly the pattern Futurum Research called out as the observability-native architecture. Once agent behaviour is treated as primary telemetry, it can be queried the same way any other production signal is: SLOs, alerts, incident timelines, and audit trails without custom instrumentation per agent.

Real production: Nokia, Agentspace, and Google’s own products

The reference deployment for ADK is Google itself. The framework is what runs Agentspace (Google’s enterprise agent surface) and the Customer Engagement Suite (CES), which is the same product used at Google’s scale. The open-sourcing decision was the point at which the framework Google used internally became the framework anyone can pick up.

Nokia Autonomous Networks (June 2026). Nokia shipped six specialist agents inside the Nokia Assurance Center, all built with ADK on the Gemini Enterprise Agent Platform. The set includes a router agent (central orchestration and guardrails), an event triage agent (correlate alarms against historical patterns), a KPI selector agent (domain interpretation of performance metrics), an anomaly reasoner (deviation vs false alarm), an action reasoner (map events to remediation catalogue), and a dashboard agent (generate visual analytics from natural language). Nokia reports 50% to 80% faster network problem resolution and cites “glass box autonomy” as the operating pattern: agents recommend, humans approve, closed-loop only for low-risk policy-approved scenarios. The stack is Kubernetes plus Google Cloud Storage with no custom managed services in between, and the availability model is SaaS on Google Cloud Marketplace starting September 2026.

Agent Garden and public code samples. Google’s google/adk-samples repo is the other place to see production shape. The samples include a short-movie agent (a multi-modal pipeline that produces a scripted 90-second video), a multi-agent research assistant with BigQuery and Vertex AI Search, and a data-analysis agent that connects to AlloyDB and BigQuery through the connector layer. Each sample is a full project with the deployment config, the eval set, and the trace setup.

ADK vs LangGraph vs CrewAI vs OpenAI Agents SDK

The framework choice in 2026 is not a winner-takes-all question, and every serious client engagement we run involves at least two of these four SDKs living in the same codebase. Here is the honest read on when ADK is the right pick.

Pick ADK when you are already on Google Cloud, when you want a single framework that covers Python, TypeScript, Go, Java, and Kotlin, when the deploy target is Vertex AI Agent Engine (the one-command path is real), or when you need graph workflows, HITL, and durable execution as first-class primitives without a separate durable runtime under the graph. The BigQuery, AlloyDB, and Apigee integrations are also unique to ADK; if your agents need to reach a hundred pre-built enterprise connectors without custom code, ADK is the shortest path.

Pick LangGraph when the workflow is a complex state machine that predates the graph-based rewrite in ADK 2.0 and your team already knows LangSmith. LangGraph is more mature on the graph story by a year of production usage, and the LangSmith trace surface is still the reference for graph debugging.

Pick CrewAI when the work maps cleanly to named roles (researcher, writer, editor) and the time-to-first-prototype matters more than the time-to-first-edge-case. CrewAI’s role-goal-backstory abstraction reads well to non-technical stakeholders, and Crews plus Flows gives you a two-tier path from prototype to production.

Pick the OpenAI Agents SDK when the workflow is OpenAI-first, when the AgentKit visual layer is the right surface for non-engineers to maintain, or when the built-in Realtime API is the binding constraint (voice, sub-second latency, native streaming to a browser).

The rule we use on engagements: if the first sentence that describes the workflow starts with “our Google Cloud tenant already has…” or “we run a mixed Python and Go stack and…”, ADK is probably the right pick. If it starts with “a state machine that loops…”, LangGraph. If it starts with “a team of agents that…”, CrewAI. If it starts with “an OpenAI-first product…”, the OpenAI Agents SDK.

Advantages and limitations

Five honest reads on what ADK gets right and where it still bites.

Strengths. ADK is the only major agent framework that ships in five languages with a shared contract, which alone makes it the default pick for teams with mixed-language codebases. The graph runtime in 2.0 is a proper first-class engine, not a wrapper over sub-agent delegation, and HITL, durable pause, retries, and OpenTelemetry tracing are all built in. The Vertex AI Agent Engine and Cloud Run deploy paths are the shortest we have seen from any framework: a single command gets you a managed HTTPS endpoint with auth, quotas, and traces. And ADK works with any LLM through LiteLLM, so the Gemini-first framing does not lock you into one provider.

Trade-offs. The 2.0 rewrite introduced real breaking changes: the event schema added node_info and output fields, custom session storage with rigid columns needs a migration, and any code that manually appended events to the session (a common 1.x hack) breaks the graph engine. The migration is mechanical but it is not zero. The TypeScript SDK is still at 0.2.0 and lags the Python and Go SDKs on features; production TypeScript teams should treat it as beta-quality until 1.0 lands. And the ecosystem story leans hard on Google Cloud - the framework does run anywhere, but the connector library, the Agent Garden, and the deploy story are richer if you stay inside the Google Cloud tenant.

When not to use it. If your team needs a mature LangGraph-style graph runtime today and cannot risk any 2.0 rough edges, LangGraph is the safer pick. If your workflow is a single agent with a single tool, ADK is overkill; call the model directly through google-genai or the provider SDK. If the constraint is browser-side agents (React or Next.js UI that runs the model inline), the Vercel AI SDK plus AG-UI protocol is a better fit than ADK.

Six production patterns we run on every ADK engagement

1. Pin the model per agent, not per workflow. Planners and coordinators run on gemini-2.5-pro because their output steers the whole run. Workers run on gemini-2.5-flash or a LiteLLM-routed smaller model. The cost delta at scale is typically a factor of three or more.

2. Use output_key and typed Pydantic outputs on every step that feeds another step. A step that returns free-form prose is hard for the next agent to consume. A step that writes a typed value to session state is a clean handoff and shows up in traces as a structured object.

3. Trace with OpenTelemetry from day one. ADK emits OTel spans natively. Wire them into Cloud Trace, MLflow, or Arize AX before the first user touches the agent. The cost of figuring out why a graph misbehaved at 2 AM is much higher without a trace than with one.

4. Move to ADK 2.0 graphs the moment you need retries, HITL, or a cycle. The Sequential, Parallel, and Loop agents in 1.x cover clean pipelines. The moment you need durable pauses, cyclic workflows, or a retry with jitter, drop into the graph runtime. Do not build any of these in session-state hacks; the 2.0 primitives are cleaner and observable.

5. Run ADK agents behind a job queue when the runtime is over a few seconds. An HTTPS request handler is not the right shape for an agent run that takes 30 seconds. Push the kickoff to a background worker (Cloud Run Jobs, a Pub/Sub topic, or a Celery worker) and return a job id.

6. Never catch BaseException inside a tool. The ADK 2.0 docs are explicit: NodeInterruptedError is what the framework uses to pause a graph for HITL. A broad exception catch inside a tool swallows the pause and permanently disables the retry mechanism for that step. Let exceptions propagate and let the RetryConfig handle them.

Future trends: what to watch for the rest of 2026

Four shifts shape the next twelve months for ADK specifically and the Google agent stack in general.

ADK as the OpenTelemetry-native standard for agents. The MLflow OTLP ingestion is the first step. Watch for Google to contribute to the OpenTelemetry semantic conventions for agent traces, which would make ADK the reference implementation for a cross-vendor agent trace schema. That is a durable structural advantage.

Cross-language workflow portability. The Python and Go 2.0 releases share an interrupt format. Once TypeScript and Java catch up, a workflow paused in one language will resume in another as a matter of course. That is the piece most enterprise stacks want and no other framework offers.

Agent Studio and Agent Garden as the default entry point for non-engineers. Google’s no-code Agent Studio is graduating out of preview, and the Agent Garden is the reference library for starter agents. Expect a Salesforce-flow-style division of labour: engineers ship the scaffolding and connectors, product managers and domain experts edit the prompts, agents, and tool selection in the Studio.

Deeper A2A and MCP integration across the vendor space. ADK, the OpenAI Agents SDK, the Claude Agent SDK, and the Microsoft Agent Framework are all converging on MCP for tool servers and A2A for cross-framework calls. The framework choice in 2027 will matter less than the choice of observability stack, deployment target, and team operating model, and ADK is positioned as the reference for the Google Cloud path.

Conclusion: the Google Cloud path is the shortest one to production

For a team building its first production agent system on Google Cloud in 2026, ADK is the default pick. The five-language rollout removes the write-once-in-Python constraint that most other frameworks impose, the graph runtime in 2.0 gives you HITL, durable pause, and retries as primitives, and the Vertex AI Agent Engine deploy path removes the ops work that usually eats the second month of a project. Nokia’s June 2026 rollout is the proof point that a six-agent system can ship on standard Kubernetes plus Google Cloud Storage with no custom managed services in the middle.

The move on a new project is incremental. Start with a single LlmAgent and the built-in tools. Add a Sequential or Parallel workflow the moment you have more than one specialist. Move to the 2.0 graph runtime when you need HITL, cycles, or retries. Deploy on Cloud Run for the first cut, then move to Agent Runtime once you need managed sessions, auth, and traces. Instrument OpenTelemetry from day one. Pin the model per agent to keep the cost curve reasonable. Wire A2A and MCP the moment you need to talk to agents in other frameworks or to remote tool servers. That path is the one we run on every ADK engagement, and it is the one that keeps the prototype-to-production gap small - which is the gap most agent projects fail to cross.

Google Agent Development Kit (ADK) in production 2026: from Cloud Next launch to graph workflows across five languages

Why ADK became a serious production choice in one year

The 2025 to 2026 timeline

Core concepts: Agent, Tool, Runner, Session, Event

Workflow agents: Sequential, Parallel, Loop

Agents as tools: hierarchies without lock-in

Model choice: Gemini first, LiteLLM for the rest

MCP and A2A: talking to the rest of the agent world

ADK 2.0: the graph runtime and why it matters

Five languages, one contract

Deployment: Agent Runtime, Cloud Run, or your own container

The ADK Tools and Integrations Ecosystem

Real production: Nokia, Agentspace, and Google’s own products

ADK vs LangGraph vs CrewAI vs OpenAI Agents SDK

Advantages and limitations

Six production patterns we run on every ADK engagement

Future trends: what to watch for the rest of 2026

Conclusion: the Google Cloud path is the shortest one to production

Further reading

Want to build something amazing? Let's bring it to life.