Investigation: verify the A2A adapter against A2A v1.0 (signed AgentCards, canonical data model)

Summary

Investigate whether the A2A adapter still matches the Agent2Agent protocol as standardized: A2A reached v1.0 under Linux Foundation governance with a canonical Protobuf/JSON-Schema data model, signed AgentCards, and multi-protocol bindings — and adapters/a2a.py was written against the earlier dict shapes.

Priority: P2 · Confidence: High (that verification is needed) / Low (on what will be found — hence investigation)

Why this matters

The README advertises A2A support as one of three first-class protocol integrations ("Standardization via Protocol Support"). If the adapter parses pre-1.0 card/message shapes, users following current A2A documentation will hit silent field drops or conversion failures, and the claim quietly becomes stale — the worst kind of integration decay, discovered by users rather than tests. A focused audit either confirms compatibility cheaply or produces a precise upgrade plan.

Current evidence

Evidence is partial; this is an investigation issue.

• src/contextweaver/adapters/a2a.py: a2a_agent_to_selectable(agent_card: dict) parses name/skills from plain dicts (lines ~24–88), stamps namespace="a2a"; load_a2a_session_jsonl replays session files; no protocol-version detection or signature awareness anywhere in the module.
• examples/data/a2a_session.jsonl and tests/ fixtures encode the wire shapes the adapter was built against — vintage unknown relative to v1.0.
• docs/integration_a2a.md describes the integration without naming a supported A2A version.

External context

Google donated A2A to the Linux Foundation (June 2025); the protocol reached v1.0 in early 2026 with: a canonical data model (AgentCard, AgentSkill, Task, Message, Part, Artifact) defined in Protobuf and published as JSON Schema 2020-12; signed AgentCards (cryptographic issuer verification); multi-tenancy; and JSON-RPC + gRPC bindings (a2a-protocol.org).

Proposed implementation

Investigation steps:

1. Diff the v1.0 AgentCard/AgentSkill JSON Schema against the fields a2a_agent_to_selectable reads; likewise Message/Part/Artifact against a2a_result_to_envelope and the session loader. Produce a field-level compatibility table.
2. Test the adapter against v1.0-conformant sample documents (from the spec repo's examples); record failures/drops.
3. Decide the signature posture: contextweaver consumes cards as data — signature verification is likely out of scope (the runtime's job), but the adapter should at minimum preserve signature fields losslessly in metadata. Confirm.
4. Write the outcome: (a) compatible — pin fixtures to v1.0 shapes and state the supported version in docs; or (b) gaps — file a follow-up implementation issue with the field mapping, including how to handle both old and v1.0 shapes (version sniffing vs explicit parameter).

AI-agent execution notes

• Inspect first: adapters/a2a.py end-to-end, its tests/fixtures, docs/integration_a2a.md; the v1.0 spec at a2a-protocol.org (work from the published JSON Schemas, not prose).
• Run: pytest tests/test_adapters.py -q (A2A coverage lives there — verify) plus ad-hoc conversion runs against v1.0 samples.
• Deliverable: the compatibility table + go/no-go follow-up in this issue; only fixture additions land as code here.
• Do not refactor the adapter during the investigation.

Acceptance criteria

• A field-level compatibility report (adapter vs v1.0 schemas) committed to this issue.
• v1.0 sample documents added as test fixtures exercising the adapter (passing or xfail-with-issue-link).
• Docs state the verified supported A2A version; follow-up issue filed if gaps exist.

Test plan

Fixture-driven conversion tests against v1.0 samples; lossless-metadata round-trip assertions for any preserved-but-unparsed fields (signatures).

Documentation plan

docs/integration_a2a.md gains a supported-version statement; README protocol section wording verified; CHANGELOG if fixtures/behavior change.

Migration and compatibility notes

Investigation itself: none. A follow-up adapter upgrade would need to keep accepting older session fixtures or document the break — covered in the follow-up.

Risks and tradeoffs

Risk of over-scoping into full v1.0 feature support (Tasks, gRPC) — the adapter's charter is cards/sessions/results as data, and the investigation should hold that line. The cheap outcome ("shapes are compatible, pin and document") is fully satisfactory.

Suggested labels

investigation, integration, reliability

Inspect src/contextweaver/adapters/a2a.py, its tests and fixtures, and docs/integration_a2a.md, then run pytest tests/test_adapters.py -q. Compare the adapter with published A2A v1.0 JSON Schemas using sample documents, record field compatibility and signature handling, add fixtures, and document the verified version or a follow-up issue for gaps.