Written by: Arjun Karnik, Growth Marketing Specialist

Key Takeaways

  • The A2A protocol has no native citation tracking, so you must add custom provenance wrappers in Artifact.metadata to keep attribution intact across multi-hop agent interactions.
  • Citation metadata belongs in Artifact.metadata for lifecycle survival, in Part.metadata for claim-level attribution, and in Task.metadata only for tracing context to preserve audit boundaries.
  • Extensions declared on AgentCard with required: true ensure downstream agents can verify citation provenance using the x-citation-provenance-v1 schema.
  • Verification status values (agent-reported, verified, conflict-detected, unresolvable) must be enforced by receiving agents to block fabricated attribution in production systems.
  • Arjun Karnik’s test lab methodology provides production-ready patterns for citation provenance; book a demo to apply these patterns to your agent architecture.

JSON Provenance Wrapper Pattern in Artifact.metadata

The recommended citation metadata pattern uses a JSON provenance wrapper embedded in Artifact.metadata under a declared extension URI. This wrapper pairs each claim with its source URL, retrieval timestamp, confidence score, and verification status so any receiving agent can audit attribution without calling back to the originating agent. The wrapper travels with the artifact across every hop.

Metadata is represented as arbitrary key-value data on most core A2A types, including DataPart, TextPart, PartBase, Message, Task, and TaskIdParams, which gives you a standard channel for contextual information across the system. The citation object below uses that channel.

The following example shows a complete provenance wrapper with a single citation and a two-hop chain. Notice how citation_id links the claim to its source and how the provenance_chain array records each agent that touched the artifact.

{ "metadata": { "x-citation-provenance-v1": { "schema_uri": "https://akarnik.com/schemas/citation-provenance/v1", "citations": [ { "citation_id": "cit-001", "claim_text": "A2A v1.0 has no native citation schema.", "source_url": "https://example.com/source-document", "source_title": "Source Document Title", "retrieved_at": "2026-08-16T09:00:00Z", "confidence": 0.92, "verification_status": "agent-reported", "originating_agent": "research-agent-01", "hop_index": 1 } ], "provenance_chain": [ { "agent_id": "research-agent-01", "hop_index": 1, "timestamp": "2026-08-16T09:00:00Z", "action": "retrieved" }, { "agent_id": "synthesis-agent-02", "hop_index": 2, "timestamp": "2026-08-16T09:01:00Z", "action": "forwarded" } ] } } }

Every field is required at write time. Receiving agents must not strip or overwrite x-citation-provenance-v1 when forwarding an artifact.

Placement Rules for Artifact, Part, and Task Metadata

The A2A Python implementation describes a full metadata flow with eight stages: client initiation on TaskIdParams.metadata, transport serialization, CallContextBuilder extraction, DefaultRequestHandler access, proto_utils.ToProto conversion, TaskStore persistence, proto_utils.FromProto restoration, and TaskUpdater.update_status acceptance. Placement decisions map directly to that flow.

Use Artifact.metadata for citation data that must survive the full task lifecycle and remain auditable by downstream agents. An artifact is the terminal output of an agent step. TaskUpdater.add_artifact() accepts an extensions parameter (list of URIs) and a metadata dict, which lets you attach extension declarations and contextual data to artifacts during multi-hop task updates. Place the full provenance wrapper here.

Use Part.metadata for claim-level citation when a single artifact contains multiple independently sourced claims. Metadata is available on DataPart, TextPart, and PartBase. Attach a reduced citation object with citation_id, source_url, confidence, and verification_status to each Part so the retrieval layer can resolve attribution at the claim level without parsing the full artifact.

Use Task.metadata for session-scoped routing and tracing data that supports the citation audit but is not itself a citation. Metadata usage patterns in A2A include tracing via trace_id and span_id, routing via tenant_id and region, analytics via source and user_segment, and debugging via debug_mode and test_id. Store trace_id and session_id at Task level and store citation objects at Artifact and Part level.

The rule is simple: citation content lives at Artifact and Part level, while tracing context lives at Task level. Mixing them collapses the audit boundary.

How to Add Provenance So Downstream Agents Can Verify

A2A Extensions are formalized in Section 4.6 of the specification and can be declared on the AgentCard to embed additional schema information such as per-skill JSON Schema fragments. The extension URI acts as the declaration mechanism that tells receiving agents a citation provenance wrapper is present and required.

The A2A protocol defines AgentExtension with fields uri (str), description (str or None), params (dict or None), and required (bool or None). When required is True, agents reject requests from clients lacking support for the extension. Set required: true for any agent that must emit verifiable citations. When required is true, agents reject requests from clients that do not declare support for the extension.

The verification_status field distinguishes what an agent reported from what has been independently confirmed. Receiving agents must read this field before treating a citation as ground truth. To ensure downstream agents can read and enforce this field, you must first declare the citation extension on the AgentCard.

Example AgentCard Extension for Citations

Declare the extension on the AgentCard before any task starts so client agents can evaluate capability before delegating work. This signals to client agents that citation provenance is a required capability. The example below shows how the required: true flag enforces the extension and how the params object sets minimum quality thresholds.

{ "agentCard": { "name": "research-agent-01", "version": "1.0.0", "extensions": [ { "uri": "https://akarnik.com/schemas/citation-provenance/v1", "description": "Embeds source attribution and provenance chain in Artifact.metadata for downstream verification.", "required": true, "params": { "min_confidence": 0.7, "require_source_url": true, "require_retrieved_at": true } } ] } }

Extensions are signaled differently by transport, with JSON-RPC using params.extensions, REST using the X-A2A-Extensions header, and gRPC using metadata headers, but all populate ServerCallContext.extensions for uniform access in AgentExecutor implementations. The URI above is the stable identifier across all three transports.

Verification Status Field Patterns for Production Safety

The verification_status field carries one of four values. Each value has a defined meaning that receiving agents must enforce rather than interpret loosely.

  • agent-reported: The originating agent retrieved and included this citation. No independent check has been performed. Receiving agents must treat this as unverified.
  • verified: A dedicated verification agent has confirmed the claim against the source URL and the source content matched at retrieval time. The verified_by and verified_at fields must be populated when this status is set. Receiving agents must not promote agent-reported to verified without executing an independent retrieval check, because promotion without verification is the primary failure mode in multi-hop citation chains.
  • conflict-detected: Two or more agents returned contradictory claims for the same citation_id. The full set of conflicting citations must be preserved in a conflicts array. Contradictions must retain full attribution and explanatory context rather than being resolved silently.
  • unresolvable: The source URL returned a non-200 response at verification time or the source content no longer matches the claim. The checked_at timestamp must be populated.

Receiving agents must enforce these meanings consistently to keep fabricated attribution out of production systems.

Full Artifact Example for Independent Audit

The following example shows a complete, production-ready Artifact that a receiving agent can consume and audit without calling back to the originating agent. This example differs from earlier fragments by including the full provenance chain with three hops (retrieve, verify, forward) and a verified status with timestamps, which gives everything needed for independent audit.

{ "artifact": { "artifact_id": "art-20260816-001", "task_id": "task-20260816-research-001", "created_at": "2026-08-16T09:01:30Z", "content": { "type": "text", "text": "A2A v1.0 has no native citation schema. Engineers must add a provenance wrapper." }, "extensions": [ "https://akarnik.com/schemas/citation-provenance/v1" ], "metadata": { "x-citation-provenance-v1": { "schema_uri": "https://akarnik.com/schemas/citation-provenance/v1", "citations": [ { "citation_id": "cit-001", "claim_text": "A2A v1.0 has no native citation schema.", "source_url": "https://chatforest.com/guides/a2a-protocol-v1-production-ready", "source_title": "A2A Protocol v1 Production Ready Guide", "retrieved_at": "2026-08-16T08:55:00Z", "confidence": 0.95, "verification_status": "verified", "verified_by": "verification-agent-03", "verified_at": "2026-08-16T09:00:45Z", "originating_agent": "research-agent-01", "hop_index": 1 } ], "provenance_chain": [ { "agent_id": "research-agent-01", "hop_index": 1, "timestamp": "2026-08-16T08:55:00Z", "action": "retrieved", "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736" }, { "agent_id": "verification-agent-03", "hop_index": 2, "timestamp": "2026-08-16T09:00:45Z", "action": "verified", "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736" }, { "agent_id": "synthesis-agent-02", "hop_index": 3, "timestamp": "2026-08-16T09:01:30Z", "action": "forwarded", "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736" } ] }, "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736", "span_id": "00f067aa0ba902b7" } } }

The A2A specification recommends including W3C Trace Context headers (traceparent and tracestate) on every call to enable tracing of a single user request across an entire multi-agent chain. The trace_id and span_id fields in the example above satisfy that requirement and link the citation audit record to the observability trace.

Book a demo to walk through this Artifact pattern against your own agent topology with Arjun Karnik’s test lab.

Performance Numbers from Arjun Karnik’s Test Lab

The following numbers come from Arjun Karnik’s own site and test lab, not from AI Growth Agent case studies.

In Arjun’s tests, pages can drop 78% to 99% in two months without updates. That decay rate applies equally to agent-generated content that is not refreshed after initial publication. The citation provenance patterns documented here were developed and validated on his own properties, with controls held back to isolate the effect of structured metadata on retrieval and citation behavior.

New articles on Arjun’s site reached thousands of monthly Google impressions within weeks of deployment. The GEO subfolder went from zero to the only source of new impressions on the entire domain in 60 days, measured in Google Search Console. Pages rewritten to match extracted fan-out queries earned citations while control pages did not. These results are from his own site, not from client engagements.

For independent market context, Seer Interactive analyzed 47,097 AI citations across 7,683 pages in ChatGPT, Gemini, and Perplexity between March and June 2026, and found that 75% of cited pages had been updated within the last year, with consistently cited pages averaging under six months since their last update. Structured, fresh content earns citations. The provenance wrapper is the structural component and freshness is the operational one.

Bar chart showing 75 percent of pages cited by AI assistants were updated within the last year and 25 percent were older. Source: Seer Interactive, July 2026, 7,683 pages and 47,097 citations across ChatGPT, Gemini and Perplexity.
Three quarters of cited pages were updated inside a year, and the consistently cited ones averaged under six months. The page you refresh beats the page you write.

AI Growth Agent case studies are AI Growth Agent’s results, not Arjun’s. They are cited separately and attributed to AI Growth Agent wherever they appear.

Frequently Asked Questions

What is a citation object in the A2A protocol?

A citation object is a JSON structure embedded in Artifact.metadata that pairs a claim with its source URL, retrieval timestamp, confidence score, and verification status. The A2A spec does not define one natively. Engineers must add it using the extension and metadata surfaces the spec provides. The citation object travels with the artifact across every agent hop so downstream agents can audit attribution without calling back to the originating agent.

What is a provenance wrapper and why does it matter?

The provenance wrapper is the outer JSON structure that contains both the citations array and the provenance chain array, as described in the recommended pattern above. The citations array records what was claimed and where it came from, and the provenance chain records which agent handled the artifact at each hop and what action it took. Together they give a receiving agent a complete, auditable record of how a claim moved through the system.

Where exactly should citation metadata be stored, Artifact, Part, or Task?

Store the full provenance wrapper in Artifact.metadata as described in the placement rules section. Store a reduced citation object with citation_id, source_url, confidence, and verification_status in Part.metadata when a single artifact contains multiple independently sourced claims. Store only tracing and routing data such as trace_id and session_id in Task.metadata. Citation content belongs at Artifact and Part level and tracing context belongs at Task level.

What is the difference between agent-reported and verified citation status?

See the “Verification Status Field Patterns for Production Safety” section for the full definitions of agent-reported versus verified status and the rules for promotion.

How do I declare the citation extension URI on an AgentCard?

See the “How to Add Provenance So Downstream Agents Can Verify” section for details on declaring the extension URI, setting required: true, and configuring the params object.

Conclusion and Next Steps for Production Rollout

The A2A protocol provides the extension and metadata surfaces needed to carry citation provenance across agent hops, but it does not provide the citation schema itself. Engineers must add the provenance wrapper, declare the extension URI on the AgentCard, place citation objects at Artifact and Part level, and enforce the verification status field so receiving agents can distinguish agent-reported claims from verified ones.

The four required components are:

  1. A declared extension URI on the AgentCard with required: true
  2. A citations array in Artifact.metadata containing claim text, source URL, retrieval timestamp, confidence, and verification status
  3. A provenance chain array recording each agent hop, action, and timestamp
  4. A verification agent that promotes agent-reported to verified only after an independent retrieval check

Arjun Karnik’s test lab has documented the implementation patterns, placement rules, and verification mechanisms on his own properties, with controls and misses included. The methodology is public and self-verifying.

Book a demo to review the full citation provenance schema, extension URI declaration, and verification patterns against your specific agent architecture.