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