google/adk-go: a Go toolkit for agents that need to ship

The problem google/adk-go solves, and for whom

Most agent frameworks arrive as a Python package plus a prompt file. That is fine until the agent has to sit inside a service that already has a deployment pipeline, a metrics stack and a code review process. google/adk-go takes the opposite position: the agent is Go source. The README describes it as "an open-source, code-first Go toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control", and the repository backs that up with top-level packages for the pieces you would otherwise write yourself: agent/, tool/, runner/, session/, memory/, artifact/, auth/, plugin/, telemetry/ and workflow/. There is also a cmd/ directory and a server/ package, which suggests a runnable binary and an HTTP surface rather than a library alone.

The intended audience is narrow and specific. The README says the Go version "is ideal for developers building cloud-native agent applications, leveraging Go's strengths in concurrency and performance". If you are writing a one-off script to summarise documents, this is more machinery than you need. If you are adding an agent to an existing Go service, the calculus changes: you get compile-time checking of tool signatures, goroutine-friendly concurrency, and a single binary to containerise. The README also notes the framework is "optimized for Gemini" but "model-agnostic, deployment-agnostic, and compatible with other frameworks". The go.mod file makes the model-agnostic claim concrete: it requires both google.golang.org/genai and github.com/openai/openai-go/v3, so an OpenAI-compatible path exists in the dependency graph, and examples/openai/ exists in the tree.

How ADK Go is put together: agents, tools, runner, sessions

The repository layout is the clearest description of the architecture. An agent is defined under agent/. The capabilities it can call are under tool/, and the README lists the sources of those capabilities: "pre-built tools, custom functions, or integrate existing tools". Execution flows through runner/, which drives an agent against a request. State lives in session/, with memory/ and artifact/ as separate stores for longer-lived context and produced files. Cross-cutting behaviour is handled by plugin/, and observability by telemetry/, which pulls in the OpenTelemetry SDK and OTLP exporters for both traces and logs according to go.mod.

Multi-agent work is a first-class concern rather than an afterthought. The README lists "Modular Multi-Agent Systems" as a key feature and describes "composing multiple specialized agents". The workflow/ package and the examples/workflow/ and examples/workflowagents/ directories are where that composition appears to be expressed. The dependency list also includes github.com/a2aproject/a2a-go and its v2 counterpart, plus github.com/modelcontextprotocol/go-sdk, so the toolkit speaks both A2A (agent-to-agent) and MCP (tool servers) without you writing protocol glue. The topics list on the repository confirms the same set: a2a, mcp, multi-agent-collaboration, vertex-ai, gemini.

The design choice worth flagging is the split between definition and execution. Because tools are Go functions and agents are Go values, the same agent can be constructed in a test with a stub model and in production with a real one, provided the model interface is respected. That is the main reason to prefer this over a configuration-driven framework: the boundary between your logic and the framework is a function signature, not a YAML schema.

Installing google/adk-go and running a first agent

The README gives exactly one installation step, and it targets the v2 module path. Run it inside an existing Go module. The go.mod in the repository declares go 1.26.6, so a toolchain at least that new is required; an older Go will refuse to build the module rather than fail at runtime.

go get google.golang.org/adk/v2

After that command, google.golang.org/adk/v2 and its transitive dependencies appear in your go.mod. The module path matters: the repository also ships a v1.6.x line, and the two are separate module versions, so the import path you choose determines which API you get.

For a first real use, the README points at the samples rather than inlining a full program. The examples/quickstart/ directory is the intended starting point, and examples/README.md describes what the samples cover. The README also offers a machine-readable route for coding agents: adk.dev/llms.txt is an index of the documentation and adk.dev/llms-full.txt is the whole documentation in one file, including the Go API reference and samples. The README gives this prompt as an example of how to use it:

Plan and implement an agent that reviews customer issues and generates a report. Use the ADK Go framework, referring to https://adk.dev/llms-full.txt for sample code.

What you should see, once an agent is wired up, depends on how you run it. The presence of cmd/ and server/ suggests a server mode, and examples/web/ and examples/rest/ suggest HTTP exposure. The README does not document the exact command for launching a sample, so read examples/README.md before assuming a flag. Deployment is described at the level of intent: the README says agents can be "easily containerize[d]" and notes "strong support for cloud-native environments like Google Cloud Run", with examples/agentengine/ and examples/vertexai/ covering the Google Cloud paths.

Two module lines, and what that costs you

The release history is the most important operational fact about this project. v1.6.1 was published on 2026-09-07, v2.3.0 on 2026-08-31, and v1.6.0 on 2026-08-12. Both lines are receiving releases within weeks of each other, and the repository carries both README.md and README-v2.md at the top level. That is a deliberate arrangement, not an accident, but it has consequences. A tutorial you find for v1 will not compile against v2 imports, and the migration surface between them is not described in the README. The README does not document rollback between module versions either, which is what you would want to know before pinning v2 in a production service.

The second constraint is the toolchain. Go 1.26.6 in go.mod is aggressive. Teams on an older release, or on a build image that lags, will have to upgrade Go before they can evaluate the framework at all. That is a real cost and it is not hidden: it is the first line of the module file.

The third is dependency weight. The direct requirements include the Google Cloud AI Platform client, Cloud Storage, gRPC, protobuf, GORM with a pure-Go SQLite driver, Cobra, gorilla/mux, and two protocol SDKs. An agent that only calls one model still links a substantial tree. For a containerised service this is usually acceptable; for a small CLI tool it may not be. The repository does flag one licensing exception worth reading before you ship: the README states that internal/httprr is covered by its own LICENSE file rather than by the project licence.

When google/adk-go is the wrong tool

The clearest case against it is a team that does not write Go. The Python ADK, the Java ADK, the Kotlin ADK and the TypeScript ADK are all linked from the README as siblings. If your engineers are Python-native and your deployment target is a notebook or a managed runtime, adopting the Go toolkit means adopting a second language for the sake of the agent, which is a bad trade. The README itself points at the Python repository first in its links block.

A second case is a workflow that is genuinely declarative. If the agent is a fixed sequence of steps with a few branches, and the people maintaining it are not engineers, a code-first framework adds a compile and release cycle to every prompt change. ADK Go gives you versioning and testability, and those are exactly the properties you do not need when the logic is stable and the instructions change weekly.

A third case is a single-shot LLM call. The framework's value is in runner/, session/, memory/ and the multi-agent composition in workflow/. A program that sends one prompt and prints one response gets nothing from that structure and inherits the full dependency graph. Finally, anyone who needs a documented upgrade path between major versions should treat the concurrent v1.6.x and v2.x lines as an open question rather than a solved one, because the README does not address it.

Alternatives: what changes if you pick something else

The most direct alternative is the Python ADK, which the README links as adk-python. The conceptual model is shared: agents, tools, sessions, multi-agent composition. The difference is the runtime and the ecosystem. Python gives you the widest set of model clients, notebooks and quick iteration; Go gives you a single static binary, goroutine-based concurrency and a type checker that rejects a malformed tool signature before deployment. Choosing between them is mostly a question of which language already owns your production surface, and the README's framing supports that reading by describing the Go version as aimed at cloud-native applications.

A second alternative is Eino, which appears in the search data as a comparison point ("adk go vs eino"). Eino is a Go LLM framework as well, so the language objection does not apply. The difference in approach is scope: ADK Go ships protocol integrations for A2A and MCP, a session and memory layer, an artifact store, a plugin system and OpenTelemetry wiring as part of the toolkit, whereas a lighter Go framework leaves more of that to you. That is a trade of assembly work for dependency weight and for the framework's opinions about how state is stored.

A third option is to skip the framework entirely and call a model SDK such as google.golang.org/genai or the OpenAI Go client directly. You keep full control and a small dependency tree, and you give up the runner, the session store, the tool registry and the multi-agent composition. For a single agent with three tools, that is often the better engineering decision.

Licence, maintenance and upgrade cost

google/adk-go is Apache-2.0. That is a permissive licence, and for most teams the practical implication is that you can use, modify and redistribute the code, including in closed-source products, provided you keep the notices. The README names one exception: internal/httprr carries its own LICENSE file, so if you vendor or depend on that package, read it separately. Nothing here is legal advice, and the LICENSE file in the repository is the authority.

Maintenance looks current on the evidence available. The repository is not archived, and the last push was on 2026-09-09, eight days before this writing. Three releases landed in the six weeks before that: v1.6.0 on 2026-08-12, v2.3.0 on 2026-08-31 and v1.6.1 on 2026-09-07. The repository also carries a nightly check workflow, a CONTRIBUTING.md and an AGENTS.md for people working on the codebase rather than with it.

The upgrade cost is the part to budget for. Two module lines are being released in parallel, which means a dependency bump can cross a major version boundary if you are not explicit about the path. Pin google.golang.org/adk/v2 or the v1 path deliberately, and read README-v2.md before moving. Because the framework is a library rather than a runtime you deploy separately, an upgrade is a code change plus a go.sum change, and it lands in the same review process as the rest of your service. That is the upside of the code-first choice.

Editorial conclusion

Adopt google/adk-go if your agents live inside Go services, you want them versioned and tested like the rest of your code, and you can accept the Go 1.26.6 toolchain requirement and the two concurrent module lines. Do not adopt it if you need a language-agnostic runtime, a visual builder, or a framework whose docs cover rollback and upgrade paths in detail. Before writing agent logic, check which line you are pinning (v1.6.1 or v2.3.0), read README-v2.md for the v2 API, and confirm that the model you intend to call is reachable through the model/ package rather than through an adapter you would have to write.

Frequently asked questions

Official sources

1. google/adk-go on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases