Build production-ready, multi-agent applications with @golang

The Agent Development Kit for Go 2.0 runs single agents and complex graphs on the same execution model.

Dynamic orchestration written in plain Go Native human-in-the-loop primitives Built-in retry policies Unified telemetry spans

Learn more: https://goo.gle/444xsMk

Build reliable multi-agent applications with ADK Go 2.0. Discover our new graph-based workflow engine, built-in human-in-the-loop, and dynamic orchestration

Source: https://developers.googleblog.com/announcing-adk-go-20/ Toni KlopfensteinDeveloper Relations EngineerADK Developer Relations

ADK for Go 2.0: build agent workflows as a graph

Building real-world agent applications is rarely as simple as sending a single prompt. Production agents must classify, branch, fan out, ask a human to approve something, retry on failure, and loop until done. Expressing that complex orchestration as ad-hoc control flow gets brittle fast.

Since its 1.0 release, Agent Development Kit (ADK) for Go has helped Go developers build production agents with a clean, idiomatic API — strong typing,iter\.Seq2event streams, and a runtime that fits naturally into existing Go services. That foundation has been a real success, and it’s exactly what made the next step possible.

Today we’re excited to shareADK for Go 2.0. The headline is a brand-new, first-class way to compose multi-agent applications: agraph-based workflow engine. Alongside it comehuman-in-the-loop (HITL)as a built-in primitive,dynamic orchestration written in plain Go,LLM agent modes, and aunified node runtimethat brings all of this together — single agents and full graphs now run on the same execution model.

If you’ve followedPython ADK 2.0, this will feel familiar: it’s the same graph-first direction, designed from the ground up to feel like Go.

Why a graph?

Real agent applications are rarely a single prompt. They classify, branch, fan out to specialists, gather results, ask a human to approve something, retry on failure, and loop until done. Expressing that as ad-hoc control flow gets brittle fast.

ADK 2.0 lets you describe theshapeof your application as agraph of nodes connected by edges, and hands execution to a scheduler that knows how to run it concurrently, persist its state, pause for a human, and resume later — even across process restarts. Here is how simple it is to chain 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,
})

Go

Copied

Thatwfis just anagent\.Agent. It runs in the same runner, launcher, and console you already use — no special harness, no new server.A graph is an agent.

The building blocks

Nodes for everything

A node is any unit of work that implements theNode interface. You rarely write that interface by hand — ADK ships typed node constructors for the common cases:

• Function nodeswrap a plain typed Go function. Generics infer the input/output schemas for you:

workflow.NewFunctionNode("classify",
    func(ctx agent.Context, in string) (Category, error) { ... }, cfg)

Go

Copied

• Emitting function nodesare function nodes that also get anemitcallback, so a single function canstream events or pause for a humanwithout dropping down to a dynamic node:

workflow.NewEmittingFunctionNode("progress",
    func(ctx agent.Context, in Job, emit func(*session.Event) error) (Result, error) { ... }, cfg)

Go

Copied

• Agent nodesdrop anyagent\.Agent(like anLlmAgent) into the graph.
• Tool nodesturn atool\.Toolinto a graph step.
• Join nodesare fan-in barriers: they wait forallpredecessors and hand you a map of their outputs.
• Dynamic nodeslet you orchestrate in code (more on this below).
• Workflow nodesembed an entire sub-workflow as a single node — graphs compose.
• Parallel workersrun a node concurrently across every item in a list and aggregate the results.
• State-bound nodes(NewFunctionNodeFromState) pull selected session-state values straight into a typed Params struct viastate:"<key\>"tags — no manual state plumbing.

Edges, routing, and the shapes you need

Edges connect nodes, and they can carry routing conditions. A node emits a routing value; matching edges fire. That single idea gives you every control-flow shape you need:

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

Go

Copied

Sequential chains, conditional routers, fan-out/fan-in, nested sub-graphs, and evenloops(a completed node can be re-triggered, so cycles are first-class) — all from edges and routes. Standard routes come inStringRoute,IntRoute,BoolRoute,MultiRoute, and aDefaultthat fires when nothing else matches. For deeper configuration, leverage theRoute interface.

Let an LLM steer the graph

One of the most useful patterns is using a model as thebrainof a router. An LlmAgent classifies the user’s message; a trivial function emits the matching route; the graph dispatches to the right handler:

User -> What time is it?    Agent -> question     answering question...
User -> Hello world!        Agent -> exclamation  reacting to exclamation...
User -> The sky is blue.    Agent -> statement    commenting on statement...

Plain text

Copied

The model makes the decision; the graph makes it reliable, observable, and resumable. (Seeexamples/workflow/routing/llm/.)

Dynamic orchestration — in plain Go

Sometimes the execution order isn’t known until runtime: it depends on data, on a loop count, on what the model just said. For that, ADK 2.0 gives youdynamic nodes, where the orchestration body is ordinary Go code that callsRunNode\(\.\.\.\)for each child:

greeter := workflow.NewDynamicNode("greeter_workflow",
    func(nc agent.Context, in string, emit func(*session.Event) error) (string, error) {
        return workflow.RunNode[string](nc, greeterNode, in)
    },
    workflow.NodeConfig{},
)

Go

Copied

Loops, conditionals, accumulation, fan-out across a dynamic list — all expressed with the Go you already know. Options likeWithRunID,WithUseSubBranch,WithUseAsOutput, andWithIsolationScopegive you precise control over child identity, history isolation, and output delegation. This is the Go counterpart to Python ADK’s dynamic graphs.

Human-in-the-loop, built in

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 ask a human a question— and the workflow durably waits for the answer:

event := workflow.NewRequestInputEvent(ctx, session.RequestInput{
    InterruptID:    "approve_refund",
    Message:        "Approve a $200 refund? (yes/no)",
    ResponseSchema: schema,
})
// yield the event; the node moves to "waiting"

Go

Copied

When the human replies on a later turn, the workflow resumes. You choose how:

• Handoff— the answer flows straight to the next node.
• Re-entry— the paused node re-runs with the human’s response available viactx\.ResumedInput\(\.\.\.\).

And resume isdurable. The run state lives in the session, and ADK can evenreconstruct 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. Responses are validated against a schema, resume is idempotent, and you get clear errors (ErrInvalidResumeResponse,ErrNothingToResume) when something doesn’t line up.

Both the console launcher and the Web UI understands HITL out of the box, surfacing both tool-confirmation prompts and workflow input requests.

Resilience without the boilerplate

Every node can carry a retry policy with exponential backoff and jitter — no external dependency required:

cfg := workflow.NodeConfig{ RetryConfig: workflow.DefaultRetryConfig() }
// 5 attempts, 1s initial delay, 60s cap, 2x backoff, full jitter

Go

Copied

Add a per-nodeTimeout, cap graph-wide concurrency withWithMaxConcurrency\(n\), and isolate parallel branches so one branch’s chatter never leaks into another’s LLM prompt history. The scheduler handles the goroutines, channels, backpressure, and cancellation for you.

Agent modes and one runtime to run them all

ADK 2.0 introducesmodesfor LLM agents —Chat,Task, andSingleTurn— so a coordinator can chat with the user while sub-agents quietly complete tasks or run single-shot. The right helper tools (finish\_task,single\_turn,task) are installed automatically based on each agent’s role.

Under the hood, the runner now drives a plainLlmAgentthrough thesame node runtimethat powers workflows. The payoff: single-agent apps and full graphs share one execution model, andhuman-in-the-loop now works for a plain LLM agent too— not just inside a workflow.

We also smoothed the programming model:ToolContextandCallbackContextare now a single unified toagent\.Context— one type to learn, whether you’re writing a tool, a callback, or a graph node — and node/agent execution shows up in one consistent telemetry span tree, so you can see exactly what your graph did.

Upgrading from 1.0

ADK 2.0 is highly additive — the entire workflow engine is new packages you opt into. There are a few new and breaking changes that come with unifying the runtime; each has a simple, mechanical fix:

• Node and node-function signatures take**agent\.Context****.**If you write nodes or node functions, change the first parameter fromagent\.InvocationContexttoagent\.Context(it embedsInvocationContext, so every method you used still works):

// before:  func(ctx agent.InvocationContext, in string) (string, error)
// after:   func(ctx agent.Context,           in string) (string, error)

Go

Copied

• One unified context.ToolContext,CallbackContextare gone – tools, callbacks, and workflow nodes all receiveagent\.Contextdirectly. If you mocked a context in tests,agent/context\_mock\.gois retained; useStrictContextMockfrom that file as your test double.
• Custom**InvocationContext****implementations**need two methods:IsolationScope\(\)andResumedInput\(id string\). Most code embeds the provided implementation and gets these for free.
• **Event streams are richer.**Events now carry node fields (IsolationScope,Output,Routes,RequestedInput) and a metadata field (NodeInfo). If you assert on exactsession\.Eventequality in tests, expect the new fields; custom session stores should persist them.
• **llmagent\.New****may install mode-specific tools.**If you set sub-agent modes, the effective tool set reflects them;task-mode agents can’t be used as static graph nodes.
• session.NewEvent takes a context. The signature is nowNewEvent\(ctx context\.Context, invocationID string\). Migrate call sites by passing thecontext\.Contextalready in scope as the first argument.

That’s the whole list. Public signatures forrunner\.Run/RunLive,agenttool, and the llmagent callbacks are unchanged. For step-by-step before/after instructions, see theADK Go 2.0 migration guide.

Try it

The fastest way to get a feel for ADK 2.0 is thenew workflow examples:

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/          # a larger, multi-shape graph

Shell

Copied

ADK 1.0 proved that building serious agents in Go could be clean and productive. ADK 2.0 takes the next step: compose those agents into reliable, observable, resumableworkflows— as a graph, in idiomatic Go, with humans in the loop when it matters.

We can’t wait to see what you build.

— The ADK for Go team