google/adk-java: a code-first Java toolkit for building AI agents

What google/adk-java solves for Java teams

Most agent frameworks arrive as Python packages, and Java teams end up either running a second runtime next to their services or wrapping a Python sidecar in an HTTP call. ADK for Java takes the other route: the agent is a Java object, defined in the same source tree as the rest of your application. The README describes it as "an open-source, code-first Java toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control", and the code-first part is the real claim. Agent behaviour, orchestration and tool use are declared in Java, so they go through the same compiler, the same test suite and the same release process as any other class.

The target reader is a developer who already ships JVM services and wants agents tightly integrated with Google Cloud services. The README says the project is designed for developers who need fine-grained control and for agents that are "tightly integrated with services in Google Cloud". That is a scope statement, not a limitation to hide: if your stack is not on Google's side, the fit is weaker.

The toolkit is a sibling of the Python ADK, and the README points at both the Python repository and the samples repository as companion links. The interface is deliberately familiar: the same feature set and the same style of agent declaration as the Python version, expressed in Java idioms.

How the agent model works: LlmAgent, tools and composition

The core abstraction visible in the README is LlmAgent, built through a builder. You give it a name, a description, a model identifier, an instruction string and a list of tools. The model field in the README example is "gemini-2.0-flash", with a comment noting that other models are possible. The instruction is plain text and acts as the system prompt. Tools are objects, and the README names three sources for them: pre-built tools, custom functions and OpenAPI specs.

Orchestration is the second half of the model. The README describes "modular multi-agent systems" where multiple specialized agents are composed into hierarchies. In practice this means an agent is a node, and the structure of the application is the structure of the tree you build. That is a different design from frameworks where a planner decides at runtime which worker to call. Here you declare the hierarchy and the runtime follows it, which makes the control flow readable in the source and debuggable with ordinary Java tooling.

For remote calls between agents, the README states that ADK integrates with the A2A protocol and points to a2a/README.md for end-to-end setup instructions and sample commands. The repository layout backs this up: there is a top-level a2a/ directory alongside core/, dev/, contrib/, maven_plugin/, tokt/ and tutorials/. The presence of separate core and dev modules matches the two Maven artifacts, google-adk and google-adk-dev.

Installing google/adk-java from Maven and building a first agent

The README gives Maven as the installation path. Add the dependency to your pom.xml, using the version the README shows, 1.9.0. There is a second artifact for the development UI.

<dependency>
  <groupId>com.google.adk</groupId>
  <artifactId>google-adk</artifactId>
  <version>1.9.0</version>
</dependency>
<dependency>
  <groupId>com.google.adk</groupId>
  <artifactId>google-adk-dev</artifactId>
  <version>1.9.0</version>
</dependency>

With the dependency in place, the README's feature highlight is a complete agent definition. It imports LlmAgent and GoogleSearchTool, then builds an agent that can search the web.

import com.google.adk.agents.LlmAgent;
import com.google.adk.tools.GoogleSearchTool;

LlmAgent rootAgent = LlmAgent.builder()
    .name("search_assistant")
    .description("An assistant that can search the web.")
    .model("gemini-2.0-flash")
    .instruction("You are a helpful assistant. Answer user questions using Google Search when needed.")
    .tools(new GoogleSearchTool())
    .build();

That is the whole first use: a named agent, a model, an instruction and one tool. What you should see is a compiled LlmAgent instance you can pass to your own entry point. The README does not show a run command, a main method or a server startup line, so the next step is the documentation site rather than the README.

The README also notes that an unreleased version can be consumed through JitPack at https://jitpack.io/#google/adk-java/, and links to an external example of that setup. Use that only if you need a commit that has no Maven Central release yet.

The development UI, and where the README goes quiet

The dev artifact exists to support a built-in development UI, described in the README as the same UI as the Python Development UI, for testing, evaluating, debugging and showing agents. The README includes a screenshot of a function call view but does not document how to start the UI, which port it binds, or what configuration it reads. The dev/ directory in the repository is where that code lives, and the documentation site is the likely place to look, but the README itself is silent on the mechanics.

That silence matters for adoption planning. If your team expects to run the agent locally with a browser interface on day one, budget time to read the docs and the dev module rather than assuming the README is enough. The same applies to evaluation: the README's evaluation section says only "Coming soon...". Anyone choosing this toolkit for its stated ability to evaluate agents should treat that capability as not yet available in the Java version and verify its status before committing.

The README also carries a Preview notice pointing at Google Cloud's Pre-GA terms, stating that pre-GA features are available "as is" and might have limited support. That is a support-policy statement, not a technical one, but it belongs in the decision: you are adopting something Google labels pre-GA.

Limits, wrong fits and the Python comparison

The most direct limitation is the one the README states: evaluation is not there yet. A toolkit that helps you build agents but not score them leaves the measurement work to you.

The second is model and cloud gravity. The README frames the project around tight integration with Google Cloud services and the example uses a Gemini model. If you are running models from other providers, or you want your agent code to stay provider-neutral, the value of the pre-built tools and integrations drops. The code-first design still works, but you are paying for an ecosystem you are not using.

The third is the Java-versus-Python question, which is the comparison people actually search for. The README claims the same features and a familiar interface as the Python ADK, and points to the Python repository as a peer link. What it does not claim is feature parity at every moment: the evaluation gap shows that the Java port can lag. The Python ADK is the reference implementation in this family, and the samples repository is shared. If your team has no JVM constraint, the Python side is the more established path. If your team does have a JVM constraint, that is precisely the case this project exists for.

A fourth point is the A2A surface. The README delegates the details to a2a/README.md, so the integration is documented in the repository rather than in the README. Plan to read that file before designing a multi-process agent topology.

Alternatives and how they differ in approach

The obvious alternative is the Python ADK, linked from the README as the sibling project. The difference is not only language. Choosing Python means your agents run in a separate process from your Java services, which reintroduces the sidecar or RPC boundary that a Java toolkit removes. Choosing Java means accepting that the Java port may trail the Python one on specific features, as the evaluation section suggests. Same agent model, different deployment shape.

The second alternative worth naming is LangChain4j, which appears in the related searches as an integration topic rather than a competing framework. The approaches differ: LangChain4j is a general Java library for wiring language models into applications, with its own chain and tool abstractions, while ADK is an agent-first toolkit with a defined agent object, a hierarchy model and an A2A path for remote agents. If you want a model-integration library, the former is the broader fit. If you want a named agent with declared tools and a composition tree, ADK is the more opinionated match.

A third option is to write the orchestration yourself against a model SDK. That gives full control and no framework upgrade cycle, at the cost of building the tool-calling loop, the hierarchy and the dev UI from scratch. ADK's value is that it hands you those pieces as a versioned Maven artifact.

Maintenance, release cadence and licence

The repository is not archived, and the last push to main was on 2026-09-09. Releases are frequent: v1.9.0 on 2026-08-31, v1.8.0 on 2026-08-17 and v1.7.1 on 2026-08-03. That is roughly a release every two weeks across August 2026, and the repository carries release-please-config.json and .release-please-manifest.json at the top level, which is the tooling behind those version bumps. The README's dependency snippet is wrapped in markers labelled x-release-please, so the documented version is updated by the same automation.

That cadence is the upgrade cost. You are tracking a pre-GA artifact that moves on a two-week rhythm, so pin the version in pom.xml and move deliberately rather than following every release. The CHANGELOG.md at the repository root is the place to read before bumping.

The licence is Apache-2.0, stated in the README badge and the LICENSE file, and the repository includes license-checks.xml and java.header, which suggests licence headers are enforced in the build. Apache-2.0 is a permissive licence with an explicit patent grant, which is the usual reason enterprise teams accept it. This is a description of the licence, not legal advice; your own counsel decides what your product can ship.

Editorial conclusion

Adopt google/adk-java if your agents must live inside an existing JVM service and be built, reviewed and versioned like the rest of your Java code. Do not adopt it if you need agent evaluation today, since the README lists that feature as coming soon, or if you want a framework that is not tied to Google models and Google Cloud services. Before writing production code, check the version of com.google.adk:google-adk on Maven Central against the README, read the a2a/README.md if you plan remote agent-to-agent calls, and confirm the current state of the dev UI. The last push to main was on 2026-09-09 and the newest release is v1.9.0 from 2026-08-31.

Frequently asked questions

Official sources

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