a2a-python: the A2A SDK for agents that need to talk to other agents
Official Python SDK for the Agent2Agent (A2A) Protocol
At a glance
- What is it?
- The official Python SDK for the Agent2Agent protocol gives you client and server implementations over JSON-RPC, HTTP+JSON/REST and gRPC, with a 0.3 compatibility mode. It is a protocol plumbing library, not an agent framework, and the extras you install decide how much of it you actually get.
- Who is it for?
- Adopt a2a-python if you are building an A2A server or client in Python and want the protocol layer handled rather than hand-rolled, and if you can commit to Python 3.10+ and an async codebase. Do not adopt it if you need a framework that decides how your agent reasons, plans or calls tools; this SDK stops at transport and task lifecycle.
- 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 Python, 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-python fills: agent-to-agent calls, not agent-to-tool calls
Most Python agent tooling answers one question: how does this agent call a function, a retriever or a model. a2a-python answers a different one. It is the official Python SDK for the Agent2Agent protocol, and its stated purpose in the README is running agentic applications as A2A Servers. That means you already have an agent, written in whatever stack you like, and you now need other agents to discover it, send it work and receive results back in a shape both sides agree on. The protocol supplies that shape; this package supplies the Python implementation of it. The audience is therefore narrow and specific: teams exposing an internal agent to another team's agent, or consuming someone else's agent as a dependency, where the two sides are not going to negotiate a bespoke HTTP contract. If your agents only ever talk to your own code in one process, the SDK adds a protocol boundary you do not need. It is also not a model wrapper, a planner or a tool registry. The README's feature list is about compliance, extensibility, async execution and optional integrations, which is a fair description of a transport and lifecycle library and a poor description of an agent framework.
What the SDK actually implements: three transports and two spec versions
The compatibility table is the most informative part of the README, because it defines the surface area precisely. The SDK implements A2A Protocol Specification 1.0 with a compatibility mode for 0.3, and the table marks client and server support as present for both spec versions across JSON-RPC, HTTP+JSON/REST and gRPC. That is six supported combinations, and it tells you the design separates the protocol semantics from the wire transport. You pick a transport, and the same task and message concepts travel over it. The 0.3 row is labelled compat, and the README points at issue #742 for the compatibility scope rather than claiming full parity. That wording matters: a compatibility mode is a translation layer, and translation layers have edges. If you are integrating with a counterpart that still speaks 0.3, the honest position is that the SDK supports it, but the exact boundaries of that support live in the issue tracker, not in the README. Read it before you promise a partner that 0.3 interop will just work.
Extras decide your dependency footprint
The core install is deliberately thin. The README's installation table lists uv add a2a-sdk or pip install a2a-sdk for the core, then a set of extras: http-server, fastapi, grpc, telemetry, encryption, and database drivers for PostgreSQL, MySQL and SQLite, with sql as an aggregate for all three drivers and all as the everything option. This is the practical decision point. A client-only integration needs the core and nothing else. A server that speaks gRPC pulls the gRPC stack; a server that uses FastAPI pulls FastAPI and Starlette. The database extras exist because the optional integrations include SQL backends, which in practice means task and state persistence rather than in-memory storage. The README does not spell out the schema or the persistence semantics, so treat the SQL extras as an available backend rather than a documented storage design. The telemetry extra wires OpenTelemetry tracing, which is the right call for a protocol boundary: when two agents from different teams fail to complete a task, the trace is usually the only artifact that shows which side stopped responding. Installing a2a-sdk[all] is convenient in development and a poor default in production, since it drags in every transport and every driver whether you use them or not.
Getting a server and client running: the commands the README gives
The README's getting started path is short and points outward. Prerequisites are Python 3.10+ and either uv (recommended) or pip. Install with uv add a2a-sdk or pip install a2a-sdk, adding the extras you need from the table. The worked example is the helloworld sample in the separate a2a-samples repository, and the README gives the exact sequence: git clone https://github.com/a2aproject/a2a-samples.git, then cd a2a-samples/samples/python/agents/helloworld, then uv run . to start the remote agent. In a second terminal, from the same directory, uv run test_client.py runs the client. The third step is validation: the README directs you to the a2a-inspector repository and its instructions. There is no configuration key list in the README, no agent card example and no server bootstrap snippet, so the sample repository is where the actual wiring lives. That is a real gap for anyone evaluating the SDK from the README alone: you cannot judge the ergonomics of defining an agent card or registering a task handler without leaving this repository. The upgrade note is the one piece of version-specific instruction present, and it is easy to miss: if you are moving from 0.3 to 1.0, the README sends you to docs/migrations/v1_0/README.md in this repository before anything else.
The migration from 0.3 to 1.0 is the largest cost you will pay
The README opens with an IMPORTANT block aimed squarely at people upgrading from 0.3 to 1.0, which is a strong signal about where the pain is. A major version bump in a protocol SDK is rarely cosmetic. The compatibility table shows the SDK still speaks 0.3 on the wire, but that is interop with other agents, not backward compatibility for your own code. Your imports, your server construction and your handler signatures are the things that move. The material here does not enumerate what changed, so the only responsible statement is that the migration guide exists at docs/migrations/v1_0/README.md and should be read before you start, not after your tests fail. Budget for this explicitly if you have a 0.3-era service in production. The related risk is version skew across a fleet: one agent on 1.0 and another on 0.3 will interoperate through the compat path, but you are then debugging two translation surfaces instead of one. Pinning every agent in a mesh to the same spec version removes a class of failure that is otherwise hard to reproduce.
Where a2a-python is the wrong tool
Three cases stand out. First, single-process agents. If your planner and your tools live in one Python program, an A2A server between them is overhead: serialization, a network hop and a task lifecycle for something a function call already does. Second, anything that needs the SDK to decide agent behaviour. This library is compliant, extensible and asynchronous, per its own feature list, and none of those words describe planning, memory or tool selection. Reaching for a2a-python expecting an agent runtime will leave you writing the runtime yourself on top of it. Third, teams that cannot run async Python. The SDK is built on modern async Python, and that is a constraint on your whole call path, not a flag you set. If your existing service is synchronous WSGI, wrapping it means either an async rewrite or a thread boundary that you will have to reason about under load. There is also a documentation limitation worth naming plainly: the README is a pointer document. It links to the API reference at a2a-protocol.org, to the samples repository and to the inspector, and it does not carry the detail itself. That is normal for an SDK of this kind, but it means your evaluation depends on material outside this repository.
Alternatives: A2A over MCP, and hand-rolled HTTP contracts
The topics list on this repository includes a2a-mcp, which reflects the common question of how A2A relates to the Model Context Protocol. The distinction is architectural. MCP is designed for an agent reaching tools and context sources, typically within one trust and ownership boundary. A2A is designed for one agent delegating to another agent, which implies independent owners, independent deployments and a need to describe capabilities before calling them. If your problem is giving one agent access to a database or a filesystem, MCP is the closer fit and a2a-python is answering a question you did not ask. The other alternative is the one most teams already have: a private HTTP endpoint with a JSON schema you control. That approach wins when there are exactly two parties, both under your control, and the contract changes often. It loses the moment a third party needs to discover your agent or when you want the task lifecycle semantics the protocol defines. The honest trade is that a bespoke endpoint is faster to ship and cheaper to change, while A2A buys interoperability at the cost of conforming to a specification and its versioning. Choose based on how many independent implementations will ever speak to your agent.
Licence, maintenance and what to verify before committing
The repository is licensed Apache-2.0, stated in the README and shipped as a LICENSE file. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices and state changes; it is not legal advice to say so, and if you are redistributing the SDK inside a product, your own counsel should confirm the notice obligations. On maintenance, the material shows a steady release cadence through the 1.1.x line, with v1.1.4 in September 2026 following v1.1.3 and v1.1.2 at roughly monthly intervals, and the repository is not archived. That pattern suggests active upkeep, but it says nothing about whether the specific transport you need is well exercised. Verify that yourself. Concretely: install the extras for your chosen transport, run the helloworld sample end to end, point the a2a-inspector at your server, and only then read docs/migrations/v1_0/README.md to decide whether your existing code is a rewrite or a patch. The SDK is the right layer for a Python team that has decided to speak A2A and wants the protocol handled. It is the wrong layer for anyone still deciding what their agents should do.
Editorial conclusion
Adopt a2a-python if you are building an A2A server or client in Python and want the protocol layer handled rather than hand-rolled, and if you can commit to Python 3.10+ and an async codebase. Do not adopt it if you need a framework that decides how your agent reasons, plans or calls tools; this SDK stops at transport and task lifecycle. Before writing production code, read docs/migrations/v1_0/README.md if you have any 0.3-era code, confirm which spec version your counterpart agents speak, and run the helloworld sample against the a2a-inspector so you see the wire format your server actually emits.
Community notes