Google launches ADK for Java 1.0.0 and puts AI agents at the heart of the enterprise ecosystem
AI agents are increasingly becoming part of everyday software development, and the ADK — Google’s Agent Development Kit — is one of the most solid bets for anyone looking to build this kind of solution in an organized and scalable way.
When the kit first launched, the focus was entirely on Python. Makes sense, right? The language has dominated the machine learning and AI ecosystem for years. But Google didn’t stop there. The ADK evolved into a multi-language ecosystem that now spans Python, Java, Go, and TypeScript. And now the framework has officially arrived in the Java universe with the release of version 1.0.0 — a version that isn’t just an incremental update, but a real milestone in maturity.
Think about the scale of this: Java runs a huge chunk of the world’s enterprise systems 🌍. Banks, fintechs, healthcare platforms, logistics systems… an enormous amount of critical infrastructure is built on Java. Bringing the ADK to this ecosystem means opening the doors to building AI agents for millions of developers who already know the language and don’t need to switch stacks to start working with real AI.
In this release, Google packed a pretty robust set of new features:
- New grounding tools with Google Maps data (GoogleMapsTool) and web content reading (UrlContextTool)
- Local code execution via ContainerCodeExecutor and cloud execution with VertexAiCodeExecutor
- A centralized plugin architecture with the new App concept
- Context control with event compaction
- Support for flows with human approval (Human-in-the-Loop)
- Session and memory management with persistence options on Vertex AI and Firestore
- Native compatibility with the Agent2Agent (A2A) protocol for communication between remote agents
Let’s break down each of these points and understand what actually changes — in practice — for Java developers. 🚀
What ADK Java 1.0.0 brings to the table
Version 1.0.0 of the ADK for Java isn’t just a port of what already existed in Python. Google built something designed for the Java ecosystem from the ground up, leveraging the language’s strengths — like static typing, robustness in high-concurrency environments, and integration with widely used enterprise tools. This means Java developers won’t feel like second-class citizens within the framework. Quite the opposite — the experience was designed to be native, smooth, and compatible with the standards the enterprise world already knows and trusts.
One of the most significant changes in this version is how the ADK organizes its tools. The new centralized plugin architecture allows teams to add, remove, and configure AI agent capabilities in a much cleaner and more modular way. In large projects where multiple teams work on the same codebase, this makes a huge difference. Instead of having integrations scattered throughout the project, everything goes through a central control point — the App class — which makes both maintenance and auditing of what each agent can do much easier.
Another point worth highlighting is the support for event compaction, a context control mechanism that solves a classic problem for anyone working with agents in production. When a conversation or task extends over many steps, the event history grows quickly, and keeping everything in memory starts getting expensive and inefficient. Event compaction allows you to intelligently compress that history, preserving the most relevant information and discarding what no longer adds value to the agent’s current state. It’s the kind of feature that sounds too technical on paper but has a direct impact on the stability and operational cost of real systems.
Grounding Tools: Google Maps and URL reading
The new grounding tools are probably one of the most exciting items in this release. Grounding, in the context of AI, is the process of connecting the model to real-world information sources, preventing it from operating solely on what it learned during training.
Anyone who already worked with the ADK knew about GoogleSearchTool, which allows grounding responses in Google search results. Now, with ADK Java 1.0.0, GoogleMapsTool enters the scene, available on Gemini 2.5, bringing geolocated data from Google Maps directly into the agent’s workflow. This opens up a massive range of possibilities for building agents that need up-to-date geographic information, like restaurant recommendations, route calculations, or any task involving location.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
To illustrate: imagine a restaurant guide agent configured with GoogleMapsTool. If someone asks about the most upscale restaurant near the Eiffel Tower in Paris, the agent can identify the famous Jules Vernes — a restaurant located inside the tower itself — and even present reviews and ratings for the venue. All of this without any manual geographic data retrieval pipeline.
Meanwhile, UrlContextTool allows Gemini to fetch and process the content of URLs provided by the user in conversation. In practice, you don’t need to create a separate pipeline to feed the agent with web content. Just pass the URL and the agent handles the reading, interpretation, and summarization automatically. It’s the kind of feature that transforms an agent from a simple question answerer into an active research tool.
Code execution: local and in the cloud
Code execution, both local and cloud-based, complements this set of tools in a pretty powerful way. ContainerCodeExecutor lets you run code locally in Docker containers, while VertexAiCodeExecutor executes code directly on Vertex AI infrastructure in Google Cloud.
AI agents built with the ADK can now execute code snippets as part of their reasoning and decision-making process, which completely transforms the types of tasks they can handle. An agent that only answers questions is useful, but an agent that answers, processes data, and executes automated actions based on results is an entirely different category.
Beyond that, the framework includes the ComputerUseTool abstraction, which can be used to control a real browser or computer. To do this, you need to implement a concrete version of BaseComputer — for example, integrating with the Chrome browser via Playwright. This capability, combined with the robust library ecosystem that Java offers, creates a very fertile environment for building complex enterprise solutions with AI at the center.
Plugins and the App class: centralized execution control
Before the App and Plugins concept, anyone who needed to add global behaviors to agents — like logging or security rules — had to apply callbacks individually to each agent and sub-agent in the hierarchy. It worked, but it didn’t scale well.
Now, the App class works as a top-level container for the entire application. It anchors the root agent, maintains global configurations (like event compaction), and manages plugins that apply to all agents at once. It’s an aspect-oriented approach that intercepts and modifies the behaviors of agents, tools, and LLM calls in a cross-cutting fashion.
The ADK already comes with some ready-to-use plugins:
- LoggingPlugin — provides detailed, structured logs of agent executions, LLM requests and responses, tool calls, and errors
- ContextFilterPlugin — keeps the LLM’s context window manageable by intelligently filtering older conversation turns while preserving mandatory function call and response pairs
- GlobalInstructionPlugin — applies a consistent, global instruction to all agents in the application, such as identity, security, or personality rules
And of course, you can extend the abstract BasePlugin class to create custom plugins with your project’s specific rules. This centralized model reduces code duplication and makes agent governance much more practical in enterprise environments.
Context engineering with event compaction
Event compaction is a context engineering feature that manages the size of an agent’s event stream — its history. In long sessions, the number of events grows fast and can exceed the LLM’s context window token limits, increasing latency and costs.
With event compaction, the ADK keeps only a sliding window of the most recent events and can summarize older events before discarding them. The configuration offers granular control: compaction interval, overlap size, token limit, event retention size, and even a customizable LLM-based summarizer.
For those who need even finer control, you can implement the BaseEventSummarizer and EventCompactor interfaces to fully customize how events are summarized and compacted. In practice, this ensures that agents in production stay stable, fast, and cost-effective, even in very long conversations or complex tasks with many steps.
Human-in-the-Loop: when the agent needs human approval
Support for human approval flows addresses one of the biggest concerns for anyone putting AI agents into production: control. There are situations where an agent shouldn’t act fully autonomously — whether due to regulatory requirements, security concerns, or simply because the impact of an action is too significant to be taken without review.
The Human-in-the-Loop (HITL) flow in the ADK is built around the concept of ToolConfirmation. Here’s how it works: when a tool requires human intervention, it can pause the execution flow and ask the user for confirmation. The process happens in three steps — interception, resumption, and context management. During interception, the tool accesses its ToolContext and calls requestConfirmation(), pausing the LLM flow. During resumption, when the human provides approval (and optional data), the ADK resumes execution. And in context management, the framework automatically cleans up intermediate events and injects the confirmed function call into the context of the next LLM request, ensuring the model understands the action was approved without getting stuck in a loop.
This brings a layer of governance that makes a real difference in contexts like healthcare, finance, and critical operations, where responsibility for the final outcome still needs to be in human hands 🤝.
Session, Memory, and Artifacts
Session and memory management is one of the features that most impacts the experience of anyone using an agent — even if the end user never knows it exists. Without good session control, an agent loses the thread of conversation between interactions, which leads to disconnected responses and a frustrating experience.
ADK Java 1.0.0 defines clear contracts for managing state, history, and files throughout conversations. For individual sessions, the following are available:
- InMemorySessionService — lightweight, in-memory storage, ideal for local development
- VertexAiSessionService — backed by the managed sessions API from Vertex AI on Google Cloud
- FirestoreSessionService — a robust and scalable implementation using Google Cloud Firestore, contributed by the community itself
For long-term memory across multiple sessions, the framework offers InMemoryMemoryService for local testing and FirestoreMemoryService for real persistence. Just attach LoadMemoryTool to the agent and it automatically queries the configured memory service to retrieve historical context.
For managing large files — like images and PDFs shared during a session — there’s InMemoryArtifactService for local storage and GcsArtifactService for persistent, versioned management via Google Cloud Storage.
For teams building B2B products or customer service platforms in Java, this is transformative. Previously, implementing this kind of behavior required a considerable amount of engineering — creating state tables, managing expirations, handling concurrency. The ADK abstracts away much of this complexity, allowing developers to focus on the agent’s behavior itself rather than the infrastructure supporting it.
Agents that talk to each other: the Agent2Agent protocol
Native support for the Agent2Agent (A2A) protocol is one of the most strategic aspects of version 1.0.0. In more sophisticated AI systems, there’s rarely just one agent working in isolation. The most common pattern in modern architectures is having multiple specialized agents, each responsible for a piece of the problem, collaborating with each other to reach a result.
ADK Java has migrated to use the official A2A Java SDK. Now you can resolve an AgentCard — the URL that identifies a remote agent, representing its capabilities and communication preferences — from a remote endpoint, build the client, and wrap it in a RemoteA2AAgent. This remote agent can be placed within the ADK’s agent hierarchy and works exactly like a local agent, streaming events back to the Runner natively.
To expose your own ADK agents via the A2A protocol, just create an A2A AgentExecutor. It wraps the agents and makes them available through a REST JSON-RPC endpoint, making your creations instantly accessible to the entire A2A ecosystem.
This has enormous implications for companies that already have AI agents in production and want to expand or integrate them with new systems. Instead of rewriting everything from scratch or building fragile, proprietary integrations, Agent2Agent offers a cleaner and more sustainable path. ADK Java fits naturally into this ecosystem, which is a significant advantage for teams working in enterprise environments with multiple teams and legacy systems that need to evolve gradually.
What this means for the Java ecosystem
The complete set of these features — grounding, code execution, Agent2Agent, human approval, centralized plugins, and memory management — positions ADK Java as a framework mature enough to be taken seriously in production environments. It’s no longer an experiment or a beta version with caveats. Version 1.0.0 is a clear statement from Google that Java is a first-class citizen in the AI agent development ecosystem, and that teams working with this language now have a toolkit that matches the real challenges they face every day 💡.
For anyone looking to get started, the official ADK documentation includes a getting started guide specifically for Java. And since the project is open source, the community can contribute improvements, fixes, and new features directly to the GitHub repository. In fact, the FirestoreSessionService mentioned earlier is a concrete example of a community contribution that’s already part of the official release.
The AI agent ecosystem is evolving fast, and having a robust, well-documented framework with solid corporate backing makes a big difference when it comes to turning prototypes into real products. ADK for Java 1.0.0 delivers exactly that — and based on what Google has indicated, more in-depth articles and videos about each of these features should be coming in the next few months. Definitely worth keeping an eye on 👀.
