a2a-java: The Official Java SDK for the Agent2Agent Protocol
Official Java SDK for the Agent2Agent (A2A) Protocol
At a glance
- What is it?
- The a2a-java project packages client and server support for the A2A agent protocol into a multi-module Maven library, with reference transports for JSON-RPC, gRPC and REST. It is aimed at Java teams that want their existing applications to speak A2A rather than at teams building an agent framework from scratch.
- Who is it for?
- Adopt a2a-java if you already have a Java 17+ service that needs to expose or consume A2A, and you want the protocol layer handled by the project that tracks the specification. Do not adopt it as a general agent framework: it is a transport and protocol SDK, and the agent logic is still yours.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap a2a-java fills between an agent and a protocol
Writing an agent is one problem. Making it reachable by another agent, over a wire format both sides agree on, is a different one. The A2A protocol defines that second problem, and a2a-java is the official Java implementation of it. The README describes the library as something that helps run agentic applications as A2A servers, and the client half is the mirror image: communicating with any A2A-compliant agent.
The audience is narrow and identifiable. It is a Java team that already has an application doing something useful, and now needs that application to advertise itself as an A2A agent, accept tasks, and return results. It is not an audience looking for a planner, a memory store, or a prompt orchestration layer. The SDK sits at the protocol boundary. Everything behind that boundary, including how a task is actually executed, remains the developer's responsibility.
The README's Hello World examples make the boundary visible: one example is a Java A2A server paired with a Python client, and the other is a Java A2A client paired with a Python server. That pairing is the point. The SDK is meant to interoperate with implementations in other languages, not to build a Java-only ecosystem.
Module layout and the three transports
The repository is a multi-module Maven project. The README states that it provides client and server support for A2A agent communication over JSON-RPC, gRPC, and REST transports. Those are three distinct wire formats, and the module structure reflects that separation rather than hiding it behind a single facade.
The Quick Start points at one concrete artifact for the server side: org.a2aproject.sdk:a2a-java-sdk-reference-jsonrpc. The name is literal. It is a reference server implementation for the JSON-RPC transport, and the README directs readers to the Server Guide for the full setup rather than reproducing it. The existence of a transport-specific reference artifact implies that the other transports have their own counterparts, though the README only names the JSON-RPC one in the dependency block.
gRPC support is generated rather than hand-written. The README explains the process: the a2a.proto file is copied from the upstream specification repository into the spec-grpc module, and the java_package option is adjusted to org.a2aproject.sdk.grpc. The spec-grpc module is then built with mvn clean install -Dskip.protobuf.generate=false to regenerate the classes. That flag matters. The default build skips protobuf generation, so a plain mvn clean install will not regenerate gRPC sources. Anyone changing the proto file has to remember the property.
The extras folder is where optional infrastructure lives. The README lists OpenTelemetry, a JPA-backed task store, a Kafka-based replicated queue manager, and Vert.x and Android HTTP clients. Read that list as an admission about the core: task storage and queue management are pluggable, and the defaults are not described in the README as durable or distributed.
Getting a reference server onto the classpath
The README gives one dependency block and one build command. Java 17 or later is required, which is stated plainly at the top of the Quick Start. The dependency is the JSON-RPC reference server:
<dependency> <groupId>org.a2aproject.sdk</groupId> <artifactId>a2a-java-sdk-reference-jsonrpc</artifactId> <version>${org.a2aproject.sdk.version}</version> </dependency>
The version is deliberately left as a property, with a comment pointing at the releases page. That is a sensible convention and also a hint: this project releases often. The three most recent releases in the supplied material are v1.3.0.Final, v1.3.1.Final and v1.3.2.Final, published within roughly two weeks of each other. Pinning a property in a parent POM is the right way to absorb that cadence.
Building the project from source is a single command, mvn clean install. Regenerating the gRPC classes requires the extra flag described above. The README does not document server configuration keys, port bindings, or a main class in the material provided; those details are deferred to the Server Guide at a2aproject.github.io/a2a-java/server. That is a real gap for anyone evaluating the library from the repository alone, and it is worth opening the guide before assuming the setup is a few lines of configuration.
Where the SDK stops and your code has to start
The most useful limitation is structural rather than a bug. This is a protocol SDK. It handles serialization, transport negotiation and the request and response shapes defined by A2A. It does not decide what your agent does with a task, how long a task may run, or what happens when the work fails halfway through.
That has a practical consequence for persistence. The README lists a JPA-backed task store as an extra, which means the task store is a component you choose rather than something the core library guarantees. If you run the reference server without selecting a durable store, the documentation does not claim your tasks survive a process restart. For a demo that is fine. For anything handling long-running work, it is the first thing to settle.
The same applies to scaling. A Kafka-based replicated queue manager appears in the extras list. Its presence implies that the default queue manager is not replicated, and that horizontal scaling across multiple server instances requires opting into the Kafka module. The README does not describe the default queue manager's behaviour, so the safe reading is that single-instance operation is the baseline and distribution is an add-on.
A third boundary is versioning. The .Final suffix on every release tag signals a deliberate stability convention, but the release interval is short. A team that pins loosely will absorb frequent upgrades.
a2a-java next to a framework like Spring AI or LangChain4j
The obvious comparison is not another A2A SDK. It is a Java agent framework such as Spring AI or LangChain4j. The difference is the layer each one occupies.
A framework like Spring AI gives you abstractions for models, prompts, tool calling and conversation state. It helps you build the agent. It does not, on its own, make that agent addressable by an arbitrary external agent that speaks A2A. a2a-java does the opposite: it gives you the A2A server and client surface, and assumes the agent behind it already exists in some form.
The two are complementary rather than competing, and the README's framing supports that reading. The library is described as helping run agentic applications as A2A servers, not as building them. If you pick a framework and expect it to provide A2A interoperability, you will be writing the protocol plumbing yourself. If you pick a2a-java and expect it to manage prompts or model calls, you will be disappointed.
The other integration axis is the runtime. The README names Quarkus as the home of the reference implementations for all three transports, and points to a separate a2a-jakarta project for runtimes supporting the Jakarta EE Web Profile. That means the choice of application runtime partly determines which integration you use, and the Jakarta path is maintained outside this repository.
Maintenance, release cadence and the Apache-2.0 terms
The project is licensed under Apache-2.0, stated in the README and shown as a badge. That is a permissive licence, and it is the same licence family used across most of the Java ecosystem. It permits commercial use and modification. It also comes with the usual absence of warranty, and the licence text itself is the authority rather than any summary here. If you redistribute the library or a modified version, read the LICENSE file for the notice and attribution requirements.
Maintenance signals visible in the supplied material are the release history and the documentation site. Three .Final releases landed between late August and early September 2026, and the repository's last push timestamp is 2026-09-09. The README links a dedicated announcements page, a community articles page, and a contributing guide, which suggests an active project rather than a frozen one.
The upgrade cost is mostly a function of surface area. If you depend only on the JSON-RPC reference server artifact, upgrades are a version bump in one property. If you depend on the gRPC modules, upgrades can also involve regenerating protobuf classes, and the regeneration command is not the default build. If you use the extras, each extra is a separate artifact with its own release alignment. The more of the module tree you consume, the more places a version bump has to land.
A short verdict on who this is for
Use a2a-java when the A2A protocol is a requirement and Java is the runtime you are keeping. The SDK gives you the client and server sides of that protocol with reference implementations for JSON-RPC, gRPC and REST, and it is maintained by the project that owns the specification, which reduces the risk of drift between your implementation and the protocol text.
Do not use it as a substitute for an agent framework, and do not assume the defaults are production-shaped. The extras list is the tell: durable task storage, a replicated queue manager, and telemetry are all opt-in. Treat the reference server as a starting point that proves connectivity, then decide which extras you actually need.
The concrete next step is to read the Server Guide at a2aproject.github.io/a2a-java/server, because the README stops at the dependency block and the material here does not document the configuration keys or the entry point. Confirm the transport your counterpart speaks before you pick an artifact, and confirm the extras you need exist at the version you pin.
Editorial conclusion
Adopt a2a-java if you already have a Java 17+ service that needs to expose or consume A2A, and you want the protocol layer handled by the project that tracks the specification. Do not adopt it as a general agent framework: it is a transport and protocol SDK, and the agent logic is still yours. Before committing, verify which transport your counterparty speaks, confirm that the reference server artifact for that transport exists at your chosen version, and check the extras modules for the task store and queue manager you need, because an in-memory default will not survive a restart.
Community notes