DCP as an A2A Extension (v1)

This page is the specification of the A2A extension identified by the URI https://devcopro.org/a2a/dcp/v1 — hosted at that URI per A2A best practice. It is a community extension: A2A’s governance lets any party define and publish an extension under its own URI, and this one claims no official A2A status.

It defines how agents speaking the A2A protocol (Agent2Agent, a Linux Foundation project) exchange DCP coordination events: A2A authenticates, routes, and correlates; DCP supplies the coordination meaning. Target A2A version: v1.0 (the legacy v0.3 shape is noted at the end).

By InterIP Networks · Last updated 2026-07-06.

Declaring the extension

An agent that emits or understands DCP declares the extension in its AgentCard:

{
  "capabilities": {
    "extensions": [
      {
        "uri": "https://devcopro.org/a2a/dcp/v1",
        "description": "Emits and consumes DCP v1 coordination events (Development Coordination Protocol).",
        "required": false
      }
    ]
  }
}

required should be false: DCP is descriptive coordination data, and a counterpart that ignores it loses nothing but the coordination signal — the same always-ignorable stance DCP’s own extensions field takes.

Carrying a DCP event

A DCP event rides in an A2A Message as a data part whose data member is a complete, unchanged DcpMessage:

• The part’s mediaType must be application/json.
• The Message extensions array must include https://devcopro.org/a2a/dcp/v1, so receivers recognize the part without probing its shape.
• One part carries exactly one DcpMessage; multiple events are multiple parts.
• A2A taskId/contextId do A2A’s correlation job; DCP correlation_id stays a semantic link between DCP messages. Do not conflate them.
• The extracted data must validate against https://schemas.devcopro.org/v1/dcp-message.schema.json unchanged — the same additivity guarantee as the CloudEvents binding.

{
  "messageId": "a2a-8c2f6e1d-5b0a-4f3e-9d47-1c2b3a4d5e6f",
  "role": "ROLE_AGENT",
  "extensions": ["https://devcopro.org/a2a/dcp/v1"],
  "parts": [
    {
      "data": {
        "dcp_version": "1.0",
        "message_id": "msg_01HZ0TASKDONE0001",
        "message_type": "task.completed",
        "issued_at": "2026-06-29T12:30:00Z",
        "body": {
          "event_id": "evt_01HZ0TASKDONE0001",
          "entity_type": "task",
          "verb": "completed",
          "entity_id": "task_schema_validation",
          "occurred_at": "2026-06-29T12:29:30Z",
          "attributed_to": "agent-builder",
          "delta": { "status": { "from": "in_progress", "to": "completed" } }
        }
      },
      "mediaType": "application/json"
    }
  ]
}

The data of this example passes the reference validator unchanged; that check runs before every publication of this spec.

The trust boundary

A2A authenticates the peer, not the claims. A DCP event received over authenticated A2A is still untrusted data in every field: attributed_to is a label, a review_request.approved is a record of an approval and not an authorization, and a consumer validates the extracted message before use — the full treatment is in consuming DCP safely. The A2A-layer identity of the sending agent may be recorded alongside the event, but never written into the DCP fields: origin belongs to the carrying layer (provenance, not identity).

Legacy A2A v0.3 shape

Pre-1.0 A2A (JSON-RPC style) used a kind discriminator on parts; the same binding applies with the part written as { "kind": "data", "data": { … } }. New integrations should target the v1.0 shape above.

Full normative text also lives at docs/bindings/a2a.md in the DCP repository. For the event-infrastructure rail, see DCP over CloudEvents; for how DCP relates to A2A conceptually, see DCP vs. A2A.