Internet-Draft                                           AI/Agent WG
Intended status: Standards Track                          March 2026
Expires: September 15, 2026


         Cross-Protocol Agent Translation (CPAT)
         draft-cpat-cross-protocol-agent-translation-00

Abstract

   This document defines the Cross-Protocol Agent Translation (CPAT)
   framework, a lightweight mechanism enabling AI agents using
   different communication protocols to interoperate through
   capability advertisement and message translation.  With over 90
   competing agent-to-agent (A2A) protocol drafts and no
   interoperability standard, protocol fragmentation is the primary
   barrier to multi-vendor agent ecosystems.  CPAT defines three
   components: a capability advertisement format for agents to
   declare supported protocols, a negotiation handshake to select a
   common protocol or translation path, and a canonical envelope
   format that enables translation gateways to convert messages
   between incompatible protocols.  CPAT reuses existing HTTP
   content negotiation patterns and builds on JSON for simplicity.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document is intended to have Standards Track status.
   Distribution of this memo is unlimited.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Problem Statement
   4.  Protocol Capability Advertisement
   5.  Negotiation Handshake
   6.  Canonical Envelope Format
   7.  Translation Gateway Requirements
   8.  Security Considerations
   9.  IANA Considerations

1.  Introduction

   The IETF AI/agent landscape includes over 90 drafts proposing
   agent-to-agent communication protocols, yet no standard exists
   for agents using different protocols to exchange messages.  This
   fragmentation mirrors the early days of instant messaging, where
   users on different networks could not communicate until gateway
   and federation standards emerged.

   CPAT takes a pragmatic approach: rather than mandating a single
   protocol, it defines the minimum machinery for agents to
   discover each other's protocol support, agree on a common
   format, and fall back to translation gateways when no common
   protocol exists.  The design follows three principles:

   1. Reuse existing standards (HTTP, JSON, TLS) wherever possible.
   2. Keep the core mechanism small enough to implement in a day.
   3. Do not require agents to support any protocol beyond their own
      plus CPAT negotiation.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described
   in RFC 2119 [RFC2119].

   Agent Protocol: A communication protocol used by an AI agent for
   peer-to-peer message exchange (e.g., A2A, MCP, SLIM, uACP).

   Capability Document: A JSON object describing the protocols an
   agent supports, served at a well-known URI.

   Translation Gateway: A service that converts messages between
   two agent protocols using the CPAT canonical envelope as an
   intermediate representation.

3.  Problem Statement

   Consider three agents: Agent A speaks Protocol X, Agent B speaks
   Protocol Y, and Agent C speaks both X and Z.  Today there is no
   standard way for A to discover that B uses a different protocol,
   negotiate a common format, or route through a translator.  Each
   protocol defines its own discovery and messaging layer, creating
   isolated silos.

   Existing work on Agent Name Service (ANS) and agent discovery
   addresses finding agents but not protocol compatibility.  The
   ADOL draft addresses token efficiency within a single protocol
   but not cross-protocol translation.  CPAT fills the gap between
   discovery and communication.

4.  Protocol Capability Advertisement

   Each CPAT-compliant agent MUST serve a capability document at
   the well-known URI /.well-known/cpat.  The document is a JSON
   object with the following structure:

      {
        "cpat_version": "1.0",
        "agent_id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000",
        "protocols": [
          {
            "id": "a2a-v1",
            "version": "1.0",
            "endpoint": "https://agent.example.com/a2a",
            "priority": 10
          },
          {
            "id": "mcp-v1",
            "version": "2025-03-26",
            "endpoint": "https://agent.example.com/mcp",
            "priority": 20
          }
        ],
        "translation_gateways": [
          "https://gateway.example.com/cpat/translate"
        ],
        "envelope_formats": ["cpat-envelope-v1"]
      }

   The "protocols" array MUST contain at least one entry.  Each
   entry MUST include "id" (a registered protocol identifier),
   "version", and "endpoint".  The "priority" field is OPTIONAL;
   lower values indicate higher preference.

   Agents SHOULD also advertise their capability document URI in
   DNS SRV or SVCB records for automated discovery.  The DNS
   record type "_cpat._tcp" SHOULD be used.

5.  Negotiation Handshake

   When Agent A wants to communicate with Agent B, the following
   negotiation procedure applies:

   Step 1: Agent A fetches Agent B's capability document from
   B's well-known CPAT URI over HTTPS.

   Step 2: Agent A computes the intersection of its own protocol
   list with Agent B's.  If the intersection is non-empty, the
   protocol with the lowest combined priority score is selected.
   Communication proceeds directly using that protocol.

   Step 3: If no common protocol exists, Agent A checks whether
   any translation gateway listed by either agent supports both
   protocols.  Agent A queries the gateway's capability endpoint
   at /.well-known/cpat/gateway:

      GET /.well-known/cpat/gateway?from=a2a-v1&to=slim-v1

   The gateway responds with 200 OK and a translation descriptor
   if it supports the pair, or 404 if not.

   Step 4: If a suitable gateway is found, Agent A sends its
   message wrapped in a CPAT envelope (Section 6) to the gateway,
   which translates and forwards it to Agent B.

   Step 5: If no gateway supports the required pair, Agent A
   SHOULD return an error to its caller indicating protocol
   incompatibility, using the CPAT error code "no_translation_path".

   The entire negotiation is stateless and cacheable.  Agents
   SHOULD cache capability documents for the duration indicated by
   HTTP Cache-Control headers, defaulting to 3600 seconds.

6.  Canonical Envelope Format

   The CPAT envelope wraps a protocol-specific message in a
   standard container for gateway translation.  The envelope is a
   JSON object:

      {
        "cpat_version": "1.0",
        "message_id": "urn:uuid:6ba7b810-9dad-11d1-80b4-00c04fd430c8",
        "timestamp": "2026-03-01T12:00:00Z",
        "source": {
          "agent_id": "urn:uuid:...",
          "protocol": "a2a-v1"
        },
        "destination": {
          "agent_id": "urn:uuid:...",
          "protocol": "slim-v1"
        },
        "intent": "task_request",
        "payload": {
          "content_type": "application/json",
          "body": "...base64-encoded protocol-specific message..."
        },
        "trace": ["urn:uuid:...source", "urn:uuid:...gateway"]
      }

   The "intent" field MUST be one of: "task_request",
   "task_response", "notification", "error", "capability_query".
   This allows gateways to perform semantic translation even when
   protocol message structures differ significantly.

   The "trace" array provides a simple provenance chain of all
   agents and gateways that have handled the message.  Each
   intermediary MUST append its own identifier.

   The "payload.body" field contains the original protocol message,
   base64-encoded.  Gateways translate by decoding the source
   protocol message, mapping it to the CPAT semantic model (intent
   + standard fields), and re-encoding in the destination protocol.

7.  Translation Gateway Requirements

   A CPAT translation gateway MUST:

   1. Serve a capability document listing all supported protocol
      pairs at /.well-known/cpat/gateway.

   2. Accept CPAT envelopes via HTTP POST at its translate endpoint.

   3. Validate envelope integrity before translation.

   4. Preserve message semantics: the intent, core payload content,
      and metadata MUST survive translation.  Fields with no
      equivalent in the destination protocol SHOULD be carried in
      a protocol-specific extension field or dropped with a warning.

   5. Return the translated envelope in the response body, or
      forward it directly to the destination agent.

   6. Log all translations with source, destination, and timestamp
      for audit purposes.

   A gateway MUST NOT modify the payload semantics during
   translation.  If exact translation is not possible, the gateway
   MUST include a "translation_warnings" array in the envelope
   listing fields that were approximated or dropped.

   Gateways SHOULD implement rate limiting per source agent and
   MUST require TLS 1.3 [RFC8446] for all connections.

8.  Security Considerations

   Capability documents are served over HTTPS, ensuring transport
   security.  Agents SHOULD verify the TLS certificate of peers
   before trusting their capability documents.

   CPAT envelopes in transit through gateways are visible to the
   gateway operator.  For end-to-end confidentiality, agents MAY
   encrypt the payload.body field using a shared key established
   out of band.  The envelope metadata (intent, agent IDs,
   timestamps) remains visible to enable routing.

   Gateways are trusted intermediaries.  Deployments SHOULD use
   gateways operated by mutually trusted parties or verified
   through attestation mechanisms such as those in
   draft-aylward-daap-v2.

   The trace array enables detection of routing loops and
   unauthorized intermediaries.  Agents SHOULD reject messages
   with unexpected entries in the trace.

   Denial-of-service attacks against gateways are mitigated by
   rate limiting (Section 7) and standard HTTP-layer protections.

9.  IANA Considerations

   This document requests IANA establish the following:

   1. A "CPAT Protocol Identifier" registry under Expert Review
      policy.  Initial entries: "a2a-v1", "mcp-v1", "slim-v1",
      "uacp-v1", "ainp-v1".

   2. A "CPAT Intent Type" registry under Specification Required
      policy.  Initial entries: "task_request", "task_response",
      "notification", "error", "capability_query".

   3. A well-known URI registration for "cpat" per RFC 8615.

Author's Address

   Generated by IETF Draft Analyzer
   2026-03-01
