A2A v1.0 Protocol Support

[zeroasterisk]

A2A v1.0 Protocol Support

This is a tracking issue for adding A2A v1.0 protocol support to a2a-elixir. The work comes from zeroasterisk/a2a-elixir, which implemented the full v1.0 spec as a standalone SDK. Rather than maintain two competing Elixir A2A packages, we'd like to contribute that work here as a series of focused PRs.

Context

The A2A v1.0 spec (currently in alpha on a2aproject/a2a-python 1.0-dev branch) introduces breaking changes from v0.3:

• PascalCase JSON-RPC method names (e.g., SendMessage instead of message/send)
• Flat Part structure (replaces discriminated TextPart/FilePart/DataPart)
• SCREAMING_SNAKE_CASE enums (TASK_STATE_WORKING instead of working)
• New fields on AgentCard (supportedInterfaces[], documentation_url, signatures, icon_url)
• Extension mechanism (A2A-Extensions header negotiation)
• Version header support (A2A-Version header validation)
• New error types (ExtensionSupportRequiredError, VersionNotSupportedError)
• New methods (ListTaskPushNotificationConfigs, DeleteTaskPushNotificationConfig, GetExtendedAgentCard)
• Push notification CRUD (full implementation, not just stubs)
• Multi-tenant server support

Proposed PR Series

Each PR is self-contained with tests and backward compatibility:

1. v1.0 data model — Update structs for v1.0 fields (AgentCard, Part, Message, Task, etc.) while keeping v0.3 wire format working
2. v1.0 JSON-RPC method names — Accept both PascalCase and legacy method names on server; client sends v1.0 names
3. v1.0 error types — Add ExtensionSupportRequiredError (-32008) and VersionNotSupportedError (-32009)
4. Extension mechanism — A2A-Extensions header negotiation on server and client
5. A2A-Version header — Version validation with VersionNotSupportedError
6. Push notification CRUD — Full implementation of set/get/list/delete with webhook sender behaviour
7. Multi-tenant server — Path-based /:tenant/:agent/ routing with per-tenant task isolation (optional Plug)

Approach

• All PRs maintain backward compatibility with v0.3 clients
• Server accepts both v0.3 and v1.0 method names/formats
• Each PR includes tests
• Builds on the existing architecture (Agent behaviour, TaskStore, Plug, etc.)

We admire the TCK integration, agent runtime, and overall ergonomics of this library — it's the right foundation for the Elixir A2A ecosystem.

cc @zeroasterisk

[zeroasterisk]

ITK Real Interop Test Results — 2026-03-21

ALL PASSED ✅

Tests Run

Test	Result
elixir-v10-python-v10-jsonrpc	✅ PASSED
elixir-v10-go-v10-jsonrpc	✅ PASSED

Each test performs a full Euler traversal (3-hop multi-agent chain) with protobuf instruction passing through the ITK framework.

Key Findings

1. GenServer deadlock — The A2A.Agent GenServer blocks during multi-hop chains. Fixed by bypassing it with a custom Plug router + stateless instruction handler.
2. v0.3 vs v1.0 wire format differences — Method names, role enums, Part format, response wrapping, protocol binding casing, and version headers all differ between the Pydantic SDK (v0.3) and proto SDKs (v1.0). The Elixir agent now serves both.
3. Streaming not yet tested — SSE interop needs to be validated separately.

Commit: 4a1eac2 on feat/elixir-itk-agent in a2a-samples.

[zeroasterisk]

ITK Streaming Update

SSE streaming endpoint has been added to the Elixir ITK agent (feat/elixir-itk-agent branch, commit ff5ff0a).

What's implemented:

• Itk.Router handles SendStreamingMessage and message/stream methods
• Returns SSE chunks: TaskStatusUpdateEvent and TaskArtifactUpdateEvent
• Verified working via curl

SDK wire format mismatch discovered:

The ITK test runner (pydantic SDK v0.3.25) and Python v10 agent (protobuf SDK v1.0) use incompatible SSE wire formats:

• Pydantic: flat events with kind discriminator (status-update, artifact-update), lowercase states
• Protobuf: events wrapped in StreamResponse oneOf (statusUpdate, artifactUpdate), TASK_STATE_* states

No single format satisfies both consumers. The Elixir agent card does not advertise capabilities.streaming=true to avoid parse failures during multi-hop callbacks. Both test scenarios pass.

This may be worth tracking as an upstream SDK compatibility issue.