A2A v1.0 supplies the contract, while 6 SDKs supply the code
A2A v1.0 defines how one agent discovers and delegates work to another without learning the remote agent's model, memory, or tools. The repository README points to 6 SDKs, covering Python, Go, JavaScript, Java, .NET, and Rust, plus a separate samples repository. That split matters. Cloning a2aproject/A2A gives you the specification, schema, documentation, and site tooling. It does not give you a universal agent process ready to deploy.
The useful boundary is organizational as much as technical. A2A earns its place when the remote agent belongs to another team, runs as another service, or uses another framework. If one codebase owns the full workflow, a framework such as AutoGen or LangGraph can coordinate the steps with less protocol surface. If the job is letting one model call a database or fixed function, the A2A v1.0 documentation assigns that connection to MCP.
A2A v1.0 covers discovery plus 3 ways to follow work
A2A v1.0 starts with an Agent Card, a JSON document describing an endpoint, skills, capabilities, and security requirements. Messages carry text, file references, raw bytes, or structured data. Longer jobs become Tasks with state and Artifacts as their outputs. Clients can wait for a response, receive updates over Server-Sent Events, or accept push notifications after disconnecting. Those 3 interaction patterns address work that outlives a normal request.
The protocol uses familiar web pieces, including HTTP(S), JSON-RPC 2.0, OAuth-style credentials, and Server-Sent Events. Familiar parts do not remove operational work. Each deployment still has to decide which Agent Cards to trust, issue and rotate credentials, authorize actions, expose status safely, and operate callbacks. A2A standardizes the conversation between 2 sides. It cannot decide whether a remote agent should be allowed to book, buy, delete, or disclose something.
What happened when we ran it
Our sandbox installed 35 Python packages in 7 seconds and occupied 37 MB on disk. The repository build completed successfully in 1 second. We ran commit afda831 in an unprivileged Debian container with 3 CPUs and 8 GB of RAM, without secrets. Those numbers make the specification repository inexpensive to inspect and build. They do not measure an SDK server, an agent request, streaming latency, or compatibility between implementations.
There was no test script or target, so the test step was skipped. Pip-audit reported 0 known vulnerabilities among the installed Python packages. The checkout contained 135 files, roughly 1,223 lines of source, and 2.2 MB before installation. It also had 11 CI workflow files, no Dockerfile, and no tests directory. A successful 1-second build therefore confirms that this checkout's build path worked, not that the protocol passes cross-language conformance tests.
Version 1.0 makes compatibility part of the application
A2A v1.0 changed several shapes that clients and servers parse. The migration guide replaces separate text, file, and data part types with one Part structure. It also changes stream-event discrimination, Agent Card interfaces, pagination, enum values, and error responses. Each interface can advertise its protocol version, which lets an agent expose more than one version during a migration. Your client still needs code for every version it accepts.
The latest tagged release was v1.0.1 on May 28, 2026. Its notes list 3 specification fixes involving the preferred HTTP media type, transcoding-related errors, and TaskStatus values. Release tags are only one health signal, and the main branch continued moving after May. For an integration, pin the protocol and SDK versions together, then keep captured Agent Cards and task exchanges as regression fixtures before either side upgrades.
Two open signing reports deserve cross-SDK tests
Open issue 2122 reports that a2a-python 1.1.2 and the JavaScript SDK 1.0.1 produce different canonical bytes for some signed Agent Cards. The report covers non-ASCII strings, object-key ordering, number serialization, and required fields with default values. It also says neither SDK reproduces one worked example in the specification. That is directly relevant when a Python agent must verify a card signed by a JavaScript agent.
A second report, issue 2249 from September 20, says the published signing example lacks the public verification key and does not identify the exact signed payload. Its scope is Agent Card signing, so it does not establish a failure in ordinary task messages. Still, teams using signatures should create their own shared vectors and make every chosen SDK sign and verify them. A green build in this 135-file repository cannot substitute for that check.
September activity supports adoption with a narrow first deployment
GitHub recorded the last push on September 21, 2026, and listed 25,885 stars plus 262 combined issues and pull requests when fetched. The signing reports were updated in September, while v1.0.1 shipped in May. That combination points to an active specification with unresolved design and implementation work, rather than an abandoned tag. The combined open count is a work queue, not a count of confirmed defects.
Start with 1 client, 1 remote agent, and one task whose side effects can be reversed. Pin A2A v1.0 behavior, test polling and whichever asynchronous path you use, and prove authentication plus cross-SDK serialization before adding more agents. For an internal workflow, keep the protocol out until a genuine service boundary appears. A2A earns its keep when the second agent is owned, deployed, or built somewhere else.