# Google Ships ADK for Go 2.0 With a Graph-Based Workflow Engine **Google's ADK for Go 2.0 lets developers compose multi-agent applications as a graph, with built-in human-in-the-loop and retries.** ## What Google announced Google has released version 2.0 of the Agent Development Kit (ADK) for Go, and the headline feature is a brand-new, first-class way to compose multi-agent applications: a graph-based workflow engine. Since its 1.0 release, ADK for Go has helped Go developers build production agents with a clean, idiomatic API, including strong typing and iter.Seq2 event streams. Google says 2.0 follows the same graph-first direction as Python ADK 2.0, designed from the ground up to feel like Go. ## Why a graph Google's post argues that real agent applications are rarely a single prompt. Production agents must classify, branch, fan out to specialists, gather results, ask a human to approve something, retry on failure, and loop until done, and expressing that as ad-hoc control flow gets brittle fast. ADK 2.0 lets a developer describe the shape of an application as a graph of nodes connected by edges, and hands execution to a scheduler that can run it concurrently, persist its state, pause for a human, and resume later, even across process restarts. A workflow built this way is still just an agent.Agent, so it runs in the same runner, launcher, and console a developer already uses. ## The building blocks: nodes and edges A node is any unit of work that implements the Node interface, and ADK ships several typed node constructors for common cases. Function nodes wrap a plain typed Go function, with generics inferring the input and output schemas. Emitting function nodes are function nodes that also get an emit callback, so a single function can stream events or pause for a human. Agent nodes drop any agent.Agent, such as an LlmAgent, into the graph, while Tool nodes turn a tool.Tool into a graph step. Join nodes act as fan-in barriers that wait for all predecessors and hand back a map of their outputs. Dynamic nodes let a developer orchestrate in code, Workflow nodes embed an entire sub-workflow as a single node so graphs compose, Parallel workers run a node concurrently across every item in a list, and state-bound nodes pull selected session-state values straight into a typed Params struct. Edges connect nodes and can carry routing conditions: a node emits a routing value, and matching edges fire, giving sequential chains, conditional routers, fan-out and fan-in, nested sub-graphs, and loops. Standard routes include StringRoute, IntRoute, BoolRoute, MultiRoute, and a Default that fires when nothing else matches. One pattern Google highlights is letting an LlmAgent classify a user's message and a trivial function emit the matching route, so the graph dispatches to the right handler while the model makes the decision and the graph makes it reliable, observable, and resumable. ## Human-in-the-loop, durably Production agents often need a human to approve, correct, or supply something mid-run, and ADK 2.0 makes that a built-in primitive rather than something a developer has to bolt on. Any node can pause the graph and ask a human a question, such as approving a $200 refund, and the workflow durably waits for the answer. A developer chooses how the workflow resumes: with Handoff, the answer flows straight to the next node, and with Re-entry, the paused node re-runs with the human's response available. Google says this works because a workflow's progress is stored as part of its session record, so ADK can rebuild a paused workflow by reading back through that session history. That is what lets a workflow pick back up after the server restarts, or even move to a different runtime, since Python ADK uses the same format for these pause-and-resume interrupts. Responses are validated against a schema, resume is idempotent, and clear errors surface when something doesn't line up. Both the console launcher and the Web UI understand human-in-the-loop out of the box, surfacing tool-confirmation prompts and workflow input requests. ## Resilience without the boilerplate Every node can carry a retry policy with exponential backoff and jitter, with no external dependency required; Google's example configuration runs 5 attempts. Developers can add a per-node timeout, cap graph-wide concurrency, and isolate parallel branches so one branch's activity never leaks into another's prompt history. Google says the scheduler handles the goroutines, channels, backpressure, and cancellation for the developer. ADK 2.0 also introduces modes for agents built on a language model, called Chat, Task, and SingleTurn, so a coordinator can talk with the user while sub-agents quietly complete tasks or run single-shot, with helper tools installed automatically based on each agent's role. ## Key facts - ADK for Go 2.0 adds a graph-based workflow engine for composing multi-agent applications. - Human-in-the-loop (HITL) is now a built-in primitive, letting any node pause and ask a person for approval. - Dynamic orchestration can be written in plain Go, calling RunNode for each child node. - Every node can carry a retry policy with exponential backoff and jitter; Google's example config uses 5 attempts. - ADK 2.0 follows the same graph-first direction as Python ADK 2.0. ## Check your understanding - What are the two ways Google says a paused human-in-the-loop workflow can resume once a person responds? - Why does Google say expressing complex agent behavior as ad-hoc control flow gets brittle, and how does the graph-based workflow engine address that? ## Sources - [ADK for Go 2.0: build agent workflows as a graph (Google Developers Blog)](https://developers.googleblog.com/announcing-adk-go-20/) --- - Category: implement (tooling) - Affects: — - Published: 2026-06-30T00:00:00.000Z - Original: https://developers.googleblog.com/announcing-adk-go-20/ - Generated by tinker news