---
title: "Google Rebuilds ADK Go 2.0 Around Graph-Based Agent Workflows"
subtitle: "ADK Go 2.0 ships a graph-based workflow engine, native human-in-the-loop, and a unified runtime that makes multi-agent Go apps production-ready"
url: "https://alphasignal.ai/news/google-rebuilds-adk-go-2-0-around-graph-based-agent-workflows"
author: "AlphaSignal Newsroom"
author_url: "https://alphasignal.ai/editorial-team"
company: "Google for Developers"
company_url: "https://alphasignal.ai/company/googledevs"
published: "2026-06-30T21:05:18.000Z"
updated: "2026-07-01T12:06:42.067Z"
type: "News"
topics:
  - "Agents"
  - "Development"
subtopics:
  - "Agent Frameworks"
  - "Multi Agent"
  - "Tool Use"
upvotes: 274
read_time: "7 min"
source_url: "https://github.com/google/adk-go/tree/main/examples/workflow"
comments: 0
---

# Google Rebuilds ADK Go 2.0 Around Graph-Based Agent Workflows

> ADK Go 2.0 ships a graph-based workflow engine, native human-in-the-loop, and a unified runtime that makes multi-agent Go apps production-ready

Google just shipped [ADK Go 2.0](https://github.com/google/adk-go/releases/tag/v2.0.0), a major overhaul of its Agent Development Kit for Go. The headline feature is a brand-new graph-based workflow engine that lets you compose agents, tools, and plain Go functions as nodes in a directed graph , with a concurrent scheduler handling execution, retries, state persistence, and human approval checkpoints. The repo already sits at 8.3k stars, and this release brings Go to feature parity with the Python ADK 2.0 that went GA in May.

## The problem with ad-hoc agent orchestration

Most real agent applications are not a single prompt-and-response. They classify inputs, branch to specialist agents, fan out work in parallel, gather results, and sometimes need a human to sign off before proceeding. Expressing that complex orchestration as ad-hoc control flow gets brittle fast. The typical fix , long system prompts with embedded instructions , trades reliability for flexibility, and debugging becomes a guessing game.

The ADK 2.0 release introduces the Workflow Runtime, transitioning ADK from a hierarchical agent executor to a graph-based execution engine where Agents, Tools, and Functions are evaluated as individual nodes within a workflow graph. The mental model shift is significant: instead of writing imperative orchestration code that calls agents in sequence, you declare the shape of your application as a graph and hand execution to a scheduler.

## A graph is just an agent

The cleanest design decision in 2.0 is that a workflow graph is itself an `agent.Agent`. It runs in the same runner, launcher, and console you already use , no special harness, no new server. Here is the minimal wiring to chain two function nodes together:

```
import "google.golang.org/adk/v2/workflow"
upper  := workflow.NewFunctionNode("upper",  upperFn,  cfg)
suffix := workflow.NewFunctionNode("suffix", suffixFn, cfg)
edges := workflow.Chain(workflow.Start, upper, suffix)
wf, _ := workflowagent.New(workflowagent.Config{
    Name:  "simple_sequence_workflow",
    Edges: edges,
})
```

Generics infer the input/output schemas from the function signatures, so you get typed data flowing through the graph without manual wiring. Single agents and full graphs now run on the same execution model.

## Every control-flow shape you need

ADK 2.0 ships a full menu of node types and edge patterns:

- **Function nodes** , wrap a plain typed Go function; generics handle schema inference
- **Emitting function nodes** , same as above but can stream events or pause for human input mid-execution
- **Agent nodes** , drop any `agent.Agent` (including `LlmAgent`) into the graph as a step
- **Tool nodes** , turn a `tool.Tool` into a graph step
- **Join nodes** , fan-in barriers that wait for all predecessors and hand you a map of their outputs
- **Dynamic nodes** , orchestration written in plain Go, for when execution order is only known at runtime
- **Workflow nodes** , embed an entire sub-workflow as a single node; graphs compose recursively
- **Parallel workers** , run a node concurrently across every item in a list and aggregate results

Edges connect nodes and can carry routing conditions: a node emits a routing value, matching edges fire. That single idea gives you every control-flow shape you need. Standard route types include `StringRoute`, `IntRoute`, `BoolRoute`, `MultiRoute`, and a `Default` that fires when nothing else matches.

## Using an LLM as the router

One of the most practical patterns is using a model as the brain of a conditional router. An `LlmAgent` classifies the user's message; a tiny function emits the matching route string; the graph dispatches to the right handler. The model makes the decision, the graph makes it reliable and observable. This hybrid approach uses traditional code for the things code is good at , math, database lookups, strict logic , and LLMs for the things LLMs are good at, like understanding natural language and parsing unstructured data.

```
b := workflow.NewEdgeBuilder()
b.AddRoutes(router, map[string]workflow.Node{
    "question":    answerNode,
    "statement":   commentNode,
    "exclamation": reactNode,
})
b.AddFanOut(planner, researchA, researchB, researchC)
b.AddFanIn(join, researchA, researchB, researchC)
```

## Human-in-the-loop as a first-class primitive

Production agents often need a human to approve, correct, or supply something mid-run. In ADK 2.0, any node can pause the graph and request input , and the workflow durably waits. A node can be configured to pause, the workflow state is serialized and saved, the system waits for an external signal such as a human clicking "Approve" in a UI, and once the signal is received, the workflow deserializes and continues.

Resume comes in two flavors: **Handoff** (the answer flows straight to the next node) and **Re-entry** (the paused node re-runs with the human's response available via `ctx.ResumedInput(...)`). Crucially, resume is durable , the run state lives in the session, and ADK can reconstruct a paused workflow by scanning session history, so a workflow can resume after a process restart, or even across different runtimes, because the interrupt format is shared with Python ADK.

## Resilience and observability baked in

Every node can carry a retry policy with exponential backoff and jitter , no external library required. The default config gives you 5 attempts, a 1-second initial delay, a 60-second cap, 2x backoff, and full jitter. You can also set per-node timeouts and cap graph-wide concurrency with `WithMaxConcurrency(n)`.

The scheduler handles the goroutines, channels, backpressure, and cancellation for you. On the observability side, node and agent execution now shows up in one consistent telemetry span tree, so you can see exactly what your graph did , which node ran, how long it took, and what it emitted.

## LLM agent modes

ADK 2.0 introduces modes for LLM agents , `Chat`, `Task`, and `SingleTurn` , so a coordinator can chat with the user while sub-agents quietly complete tasks or run single-shot. The right helper tools are installed automatically based on each agent's role. This is the mechanism that makes coordinator-plus-specialist architectures clean: each sub-agent knows its job and returns control automatically.

## What changed from 1.0

ADK 2.0 is highly additive , the entire workflow engine is new packages you opt into. The breaking changes are mechanical and few:

- Node and node-function signatures now take `agent.Context` instead of `agent.InvocationContext`
- `ToolContext` and `CallbackContext` are merged into a single `agent.Context`
- The module path moves to `google.golang.org/adk/v2` and requires Go 1.25+
- `session.NewEvent` now takes a `context.Context` as its first argument
- Events carry new node fields; custom session stores should persist them

Public signatures for `runner.Run/RunLive`, `agenttool`, and llmagent callbacks are unchanged. A full [migration guide](https://github.com/google/adk-go/blob/main/README-v2.md) covers every before/after diff.

## Where it fits and where it doesn't

ADK Go gives Go developers access to the full spectrum of agent-based architectures without having to drop into Python or Java. It is a strong fit for teams already running Go backends who want to add intelligent, multi-step automation without switching languages or managing a Python sidecar.

There are real constraints to know about. Live Streaming functionality is not compatible with graph-based workflows. Some third-party integrations may also not work inside a graph context. And while the graph engine itself is GA, the broader ADK ecosystem is still maturing , the Python 2.0 GA only landed in May, and the Go 2.0 GA follows now.

## Getting started

The fastest path to understanding the new primitives is the [workflow examples directory](https://github.com/google/adk-go/tree/main/examples/workflow). Google ships runnable samples for every major pattern:

```
go run ./examples/workflow/basic/
go run ./examples/workflow/routing/llm/      # LLM-as-router
go run ./examples/workflow/dynamic/hitl/     # dynamic + human-in-the-loop
go run ./examples/workflow/hitl_rerun/       # HITL with re-entry resume
go run ./examples/workflow/complex/          # larger multi-shape graph
```

ADK Go 2.0 is free and open source. You pay only for the underlying model calls , Gemini by default, though the framework supports other LLMs through well-defined abstractions. Full API docs are on [pkg.go.dev](https://pkg.go.dev/google.golang.org/adk/v2) and the [official ADK docs](https://adk.dev/graphs/#go) cover the graph workflow concepts in depth.

## Sources

- [X post by @googledevs](https://x.com/googledevs/status/2072063955607192057)
- [Build reliable multi-agent applications with ADK Go 2.0 - Google Developers Blog](https://developers.googleblog.com/announcing-adk-go-20/)
- [Release v2.0.0 · google/adk-go](https://github.com/google/adk-go/releases/tag/v2.0.0)
- [Graph-based agent workflows - ADK Docs](https://adk.dev/graphs/#go)
- [Welcome to ADK 2.0 - Agent Development Kit](https://google.github.io/adk-docs/2.0/)
- [Why google/adk-go Is a Game Changer for Go Devs - DEV Community](https://dev.to/esrom_berhane_4fa205468a0/why-googleadk-go-is-a-game-changer-for-go-devs-and-why-you-cant-ignore-it-5h9g)
