A2A Protocol Technical Documentation
Community Hub
What Changed in A2A v1.0

What Changed in A2A v1.0

A2A has moved from early draft-era conventions to a more formal v1.0 release-candidate model.

One-minute summary

  • The protocol is stricter and more explicit across JSON-RPC, gRPC, and REST mappings.
  • The protobuf model (a2a.proto) is the canonical definition source.
  • Some older field and event conventions are no longer preferred in v1-style implementations.

What each audience should care about

Decision makers

  • Compatibility governance now matters more than before.
  • Version strategy and rollout policy should be explicit per interface.
  • Security and identity requirements are more clearly specified.

Beginners

  • Learn the core sequence first: discover card, send message, check task, stream or subscribe.
  • Understand that task state and stream closure indicate completion.

Developers

  • Keep Task as the durable source of truth.
  • Treat Message as interaction input and Artifact as structured output.
  • Implement capability-aware behavior and operation-level error handling.

Advanced teams

  • Build migration tests for mixed-client populations.
  • Validate cross-binding equivalence (JSON-RPC, gRPC, REST).
  • Add compatibility layers only where required, and remove them with version policy.

High-impact behavioral changes

  • Completion signaling in streams should not depend on a final field.
  • Operation naming and mapping are more standardized.
  • Version/service parameters are explicit and should be validated.
  • Task identity semantics are clearer: IDs are server-generated for new tasks.

Migration checklist

  1. Inventory old assumptions in streaming and task completion logic.
  2. Update operation mapping and error handling to v1 semantics.
  3. Regenerate schemas/SDK contracts from current proto definitions.
  4. Re-run end-to-end tests for polling, streaming, and push notification flows.
  5. Document compatibility guarantees for clients by version.

References

Roadmap