PACE: Protocol for Agent Communication Exchange

1.1. Design Goals

1. Session Lifecycle: Timed sessions with establishment, update, suspension, and termination.¶

2. Multi-Modal: Concurrent real-time media, chat, and operations.¶

3. Scalable: Relay-based fan-out with failure recovery.¶

4. Flexible Topologies: Point-to-point and point-to-multipoint.¶

5. Agent Identity: Authentication independent of user identity with delegated authorization.¶

6. Protocol Agnostic: Usable by A2A, MCP, and custom protocols.¶

1.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.1. Why MOQT?

Media over QUIC Transport (MOQT) [MoQ-TRANSPORT] is a publish/subscribe protocol over QUIC. PACE adopts MOQT as its transport substrate for the following reasons:¶

• Native pub/sub — Agents publish and subscribe without polling or long-lived HTTP connections; the relay handles fan-out¶

• Prefix-based routing — SUBSCRIBE_TRACKS on an agent's prefix automatically delivers all current and future tracks, enabling session notification without dedicated signaling channels¶

• Relay architecture — No direct peer-to-peer connections required; relays provide NAT traversal and load balancing out of the box¶

• Multi-party fan-out — A single PUBLISH reaches all subscribers via relay; no application-level broadcast logic needed for multi-agent collaboration¶

• Relay caching — Late-joining agents receive cached objects, enabling session recovery and mid-conversation catch-up without peer retransmission¶

• Per-object priority — Real-time audio/video, control messages, and bulk transfers coexist on the same session with differentiated QoS (0-255 priority scale)¶

• Multiple latency spectrums — A single MOQT session supports sub-100ms real-time media, sub-second interactive messaging, and best-effort bulk transfers simultaneously, matching the diverse communication needs of AI agents¶

• Scalability — Relays MAY be organized hierarchically for geographic distribution, enabling thousands of agents across regions without requiring each agent to maintain direct connections to all peers¶

• QUIC foundation — Connection migration (WiFi to cellular), multiplexed streams, 0-RTT resumption, and mandatory TLS 1.3¶

• Namespace-level access control — Maps directly to agent authorization scopes; relays enforce who can publish/subscribe to which namespaces¶

3.1. Namespace Organization

PACE uses MOQT's hierarchical namespace for routing, isolation, and multiplexing. MOQT addresses content using a namespace tuple (an ordered sequence of string fields) combined with a track name. PACE organizes all communication into three namespace scopes defined in the following subsections.¶

  ("pace", "agents", {agent-id}) -- {track}

  ("pace", "agents", {agent-id}, {session-id}) -- {track}

  ("pace", "discovery", "sessions", {agent-id}) -- {session-id}

3.2. Transport Binding

4.1. Session Lifecycle

Sessions progress through defined states:¶

IDLE ──establish──▶ PENDING ──accept──▶ ACTIVE ◀──update──┐
  ◀──reject──────────┘                    │  │             │
                                     suspend  terminate    │
                                          ▼       │       │
                                    SUSPENDED     ▼       │
                                     │  │       CLOSED ◀──┘
                                     │  └resume──▶ ACTIVE
                                     └─timeout──▶ CLOSED

IDLE:

No session exists. Agent is available to initiate or accept sessions.¶

PENDING:

Establishment in progress (negotiation, authentication).¶

ACTIVE:

Session established; data exchange occurring. May be updated.¶

SUSPENDED:

Temporarily inactive, state preserved. Transitions to CLOSED on timeout.¶

CLOSED:

Session terminated. Resources released.¶

4.2. Session Establishment

Session establishment creates a shared communication context between two or more agents. Its goals are to negotiate capabilities and modalities, exchange and verify identity tokens, and set up the MOQT subscriptions so both agents can publish and receive messages.¶

Prerequisite: Both agents must have completed discovery Phase 2 (Section 5.2) — meaning they have issued SUBSCRIBE_TRACKS on each other's agent prefix. This enables the relay to forward PUBLISH messages between them automatically via prefix matching.¶

The following steps describe how Agent A (initiator) establishes a session with Agent B (responder):¶

1. A generates a session-id (UUID).¶

2. A publishes SESSION_INIT — A issues PUBLISH on ("pace","agents","agent-a",{session-id}) -- "ctrl" containing proposed session parameters (target=agent-b, capabilities, modalities, identity token, supported protocols).¶

3. Relay forwards PUBLISH to B — B's existing SUBSCRIBE_TRACKS on ("pace","agents","agent-a") prefix-matches the new track. The relay forwards the PUBLISH message to B.¶

4. B accepts the PUBLISH — this implicitly subscribes B to A's ctrl track. B receives the SESSION_INIT object, inspects the parameters, and decides whether to accept.¶

5. B publishes SESSION_ACCEPT — B issues PUBLISH on ("pace","agents","agent-b",{session-id}) -- "ctrl" containing accepted capabilities and modalities.¶

6. Relay forwards PUBLISH to A — A's existing SUBSCRIBE_TRACKS on ("pace","agents","agent-b") prefix-matches. The relay forwards the PUBLISH message to A.¶

7. A accepts the PUBLISH — A receives the SESSION_ACCEPT object.¶

8. Session is ACTIVE — both agents can now publish additional tracks under their respective session namespaces. The relay forwards all new PUBLISH messages to the peer via the existing SUBSCRIBE_TRACKS prefix match.¶

4.3. Timed Sessions

Sessions are either short-lived (bounded duration, auto-terminates on completion or timeout) or long-lived (indefinite, survives idle periods via SUSPENDED state). The session-timeout parameter defines the maximum idle period before automatic transition to CLOSED.¶

4.4. Session Update

Active sessions can be updated by publishing a SESSION_UPDATE message on the control track. Updates can modify modalities, participants, authorization scopes, or timeout. All participants MUST acknowledge the update before new parameters take effect.¶

4.5. Session Recovery

PACE provides graceful recovery from network and server failures:¶

QUIC Connection Migration:

Sessions survive network path changes (e.g., WiFi to cellular) via QUIC's connection ID mechanism without re-establishing the MOQT session.¶

Relay Caching:

Relays cache recent objects, allowing reconnecting agents to receive missed messages without requiring peer retransmission.¶

Session Resumption:

Agents resume SUSPENDED sessions by reconnecting to the relay, re-issuing PUBLISH_NAMESPACE and SUBSCRIBE_TRACKS on their agent prefix. The relay delivers cached objects from the point of disconnection.¶

State Checkpointing:

Agents SHOULD periodically publish state checkpoints on a dedicated track, enabling recovery after relay failures.¶

4.6. Session Termination

Sessions terminate explicitly via SESSION_CLOSE on the control track or implicitly via timeout. Upon termination, all subscriptions are cancelled, pending operations receive cancellation notifications, and session resources are released after a configurable grace period.¶

5.1. Agent Identity Model

PACE authenticates agents independently of the users they represent. This enables independent revocation, capability-scoped permissions, audit trails for agent actions, and delegation chains.¶

5.2. Agent Discovery

Agent discovery uses MOQT's namespace operations to find agents and follow their activity. Discovery operates on the Agent Namespace scope defined in Section 3.1. Each agent is identified by a globally unique agent-id (UUID), verifiable via the Agent Card (see Section 5.2.3).¶

6.1. Modality Types

PACE defines the following data modality classes:¶

6.2. Channel Architecture

Each modality maps to dedicated MOQT tracks within the Session Communication Namespace (Section 3.1). Different modalities are isolated by track name while sharing session context and authorization.¶

6.3. Priority and Quality of Service

MOQT's 0-255 priority scale enables differentiated treatment of messages based on urgency and modality. PACE defines the following priority tiers:¶

6.4. Request/Response Pattern

Request/response interactions use coordinated publish operations. Agent A publishes a request object on its own track ("pace","agents","agent-a",{sid}) -- "ops/{req-id}". Agent B, which has subscribed to A's session namespace, receives the request, processes it, and publishes the response on its own corresponding track ("pace","agents","agent-b",{sid}) -- "ops/{req-id}". Agent A receives the response through its subscription to B's session namespace.¶

For a detailed example of request/response over MOQT tracks, see [MCP-MOQT] which defines this pattern for MCP tool invocations.¶

6.5. Streaming Pattern

Long-running operations produce incremental results as MOQT objects organized into groups representing execution phases. The server advances to a new group at each phase transition (e.g., initialization, progress, completion). Multiple objects within a group represent incremental data for that phase.¶

Late-joining subscribers receive the latest complete group from relay cache, enabling mid-operation catch-up without replaying the full history.¶

6.6. Real-Time Media Exchange

Audio and video streams use dedicated tracks ("audio", "video") with descending group order (newest-first) and high priority (32-63), ensuring media frames preempt lower-priority data under congestion.¶

8.1. Binding Architecture

Protocol bindings sit between application protocols and the PACE session layer. Each binding defines:¶

• Protocol Identifier: Unique string used as the track name prefix¶

• Namespace Pattern: How operations map to track names¶

• Message Serialization: Encoding within MOQT object payloads¶

• Operation Mapping: Protocol operations to MOQT primitives¶

• Priority Mapping: Message types to PACE priority tiers¶

Protocols use distinct track name prefixes within PACE sessions:¶

8.2. A2A Binding

The Agent-to-Agent Protocol [A2A] binding maps A2A task delegation and collaboration to MOQT primitives using the a2a/ category prefix.¶

Namespace: ("pace", "agents", {agent-id}, {session-id})
Tracks:    "a2a/{subcategory}/{identifier}"

{
  "jsonrpc": "2.0",
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [{"kind": "text", "text": "Hello agent"}]
    }
  },
  "id": "req-001"
}

{
  "name": "research-assistant",
  "protocolVersion": "0.3.0",
  "capabilities": {"streaming": true, "pushNotifications": true},
  "skills": [{"id": "web-research", "name": "Web Research"}],
  "authentication": {"schemes": ["bearer", "oauth2"]},
  "moqt": {
    "relayEndpoint": "moqt://relay.example.com:4443",
    "webTransportEndpoint": "https://relay.example.com:4443/moqt",
    "namespace": ["pace", "agents", "research-assistant"],
    "supportedExtensions": ["pace-v1"],
    "maxConcurrentSubscriptions": 100,
    "cacheTTL": 300
  },
  "signature": "base64-encoded-ed25519-signature"
}

8.3. MCP Binding

The Model Context Protocol [MCP] binding enables tool and resource access for agents. Within a PACE session, MCP tracks use the "mcp/" prefix under the agent's session namespace:¶

Namespace: ("pace", "agents", {server-id}, {session-id})
Tracks:    "mcp/{subcategory}/{identifier}"

The complete MCP over MOQT specification — including track structure, operation mapping, message serialization, Agent Skills architecture, and relay support — is defined in [MCP-MOQT]. PACE adopts that specification's track semantics, mapping its namespace tuples (e.g., (mcp, {session-id}, tools) -- ({tool-name})) into PACE track names (e.g., "mcp/tools/{tool-name}") as described in Section 3.1.¶

8.4. AutoGen Binding

AutoGen [AutoGen] is a multi-agent conversation framework. This binding maps AutoGen's conversation patterns to MOQT within PACE sessions.¶

Namespace: ("pace", "agents", {runtime-id}, {session-id})
Tracks:    "autogen/{subcategory}/{identifier}"

{
  "sender": "agent-name",
  "recipient": "agent-name | broadcast",
  "content": "message content or structured data",
  "metadata": {
    "conversation_id": "conv-123",
    "turn": 5,
    "role": "assistant | user | system"
  }
}

8.5. Generic JSON-RPC Binding

This binding provides a baseline for custom protocols using JSON-RPC 2.0 messaging.¶

Namespace: ("pace", "agents", {agent-id}, {session-id})
Tracks:    "ext/{protocol-name}/{subcategory}/{identifier}"

{
  "jsonrpc": "2.0",
  "method": "protocol.method",
  "params": {},
  "id": "request-id"
}

9.1. Authorization Model

PACE implements a behavior-driven authorization model where access tokens are scoped to specific operations an agent is permitted to perform.¶

9.2. Transport Security

All PACE communication is encrypted via TLS 1.3 (QUIC requirement). Agent identity tokens are cryptographically signed with short expiry. MOQT Common Access Tokens [MoQ-C4M] provide relay-level namespace authorization. Relay nodes cannot access payload content unless explicitly authorized as trusted intermediaries.¶

9.3. Privacy Considerations

Agents SHOULD minimize shared data to what is necessary for the task. Long-lived sessions SHOULD support forward secrecy through periodic key rotation. Relay operators MUST NOT retain content beyond operational necessity.¶

10.1. Failure Modes and Recovery

Session recovery mechanics are defined in Section 4.5.¶

12.1. MOQT Setup Parameter Registry

This document requests registration of the following MOQT setup parameters:¶

12.2. PACE Protocol Binding Registry

IANA is requested to create a registry for PACE protocol bindings. Each entry contains:¶

• Protocol Identifier (string)¶

• Protocol Version¶

• Namespace Prefix Pattern¶

• Reference Document¶

Initial entries:¶

12.3. PACE Message Type Registry

IANA is requested to create a registry for PACE session control message types:¶

13.1. Normative References

[MoQ-TRANSPORT]

Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-16, January 2026, <https://datatracker.ietf.org/doc/draft-ietf-moq-transport/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

13.2. Informative References

[A2A]

A2A Project, "Agent-to-Agent Protocol Specification", Version 0.3.0, 2025, <https://google.github.io/A2A/specification/>.

[AutoGen]

Wu, Q., Banber, G., Zhang, Y., Wu, Y., Li, B., Zhu, E., and A. Awadallah, "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv 2308.08155, 2023, <https://arxiv.org/abs/2308.08155>.

[MCP]

Anthropic, "Model Context Protocol Specification", Version 2025-06-18, June 2025, <https://modelcontextprotocol.io/specification/>.

[MCP-MOQT]

Jennings, C., Swett, I., Rosenberg, J., and S. Nandakumar, "Model Context Protocol and Agent Skills over Media over QUIC Transport", Work in Progress, Internet-Draft, draft-mcp-over-moqt, 2025, <https://datatracker.ietf.org/doc/draft-mcp-over-moqt/>.

[MoQ-C4M]

Jennings, S., "Common Access Token for Media over QUIC", Work in Progress, Internet-Draft, draft-ietf-moq-c4m, 2025, <https://datatracker.ietf.org/doc/draft-ietf-moq-c4m/>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7540]

Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/rfc/rfc7540>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9297]

Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August 2022, <https://www.rfc-editor.org/rfc/rfc9297>.

[SD-AGENT]

Nandakumar, S. and C. Jennings, "SD Agent: Selective Disclosure for Agent Discovery and Identity Management", Work in Progress, Internet-Draft, draft-nandakumar-agent-sd-jwt-02, February 2026, <https://datatracker.ietf.org/doc/draft-nandakumar-agent-sd-jwt/>.

A.1. Agent-to-Agent: Task Delegation

Agent A (a coordinator) delegates a research task to Agent B. This is a point-to-point session using the A2A binding.¶

Setup: Agent A generates session-id s1 (a UUID) and establishes a session with Agent B via the flow in Section 4.¶

Resulting namespace layout:¶

Agent A publishes:
  ("pace","agents","agent-a","s1") -- "ctrl"            (SESSION_INIT)
  ("pace","agents","agent-a","s1") -- "a2a/request/r1"  (task request)

Agent B publishes:
  ("pace","agents","agent-b","s1") -- "ctrl"            (SESSION_ACCEPT)
  ("pace","agents","agent-b","s1") -- "a2a/response/r1" (task result)

Flow:¶

1. A publishes SESSION_INIT on its "ctrl" track — the relay forwards to B via B's SUBSCRIBE_TRACKS prefix match¶

2. B accepts the forwarded PUBLISH, publishes SESSION_ACCEPT on its own "ctrl" track¶

3. A receives SESSION_ACCEPT via the relay (A's SUBSCRIBE_TRACKS on B)¶

4. A publishes a JSON-RPC request on "a2a/request/r1": {"jsonrpc":"2.0","method":"message/send","params":{...},"id":"r1"}¶

5. B receives the request (via its subscription to A's namespace), processes it, and publishes the result on "a2a/response/r1"¶

6. A receives the response via its subscription to B's namespace¶

7. Either agent publishes SESSION_CLOSE on "ctrl" to terminate¶

A.2. Agent-to-Tool: MCP Tool Invocation

Agent A needs to read a file using a filesystem tool (an MCP server).¶

Setup: Agent A generates session-id s2 and establishes a session with the filesystem tool.¶

Resulting namespace layout:¶

Agent A publishes:
  ("pace","agents","agent-a","s2") -- "ctrl"
  ("pace","agents","agent-a","s2") -- "mcp/tools/readFile"  (tool call)

Tool publishes:
  ("pace","agents","fs-tool","s2") -- "ctrl"
  ("pace","agents","fs-tool","s2") -- "mcp/tools/readFile"  (tool result)

Flow:¶

1. A establishes a session with the tool (SESSION_INIT / ACCEPT)¶

2. A publishes a tool call on "mcp/tools/readFile": {"jsonrpc":"2.0","method":"tools/call","params":{"name":"readFile", "arguments":{"path":"/data/report.csv"}},"id":"t1"}¶

3. Tool receives the call, reads the file, publishes the result on its own "mcp/tools/readFile" track¶

4. A receives the file contents¶

5. A may issue additional tool calls within the same session or close it¶

A.3. Multi-Agent Collaboration

Agent A (coordinator) creates a research session and invites Agent B (web researcher) and Agent C (data analyst) to collaborate.¶

Setup: Agent A generates session-id s3 and publishes SESSION_INIT on its ctrl track — the relay forwards to B and C via their SUBSCRIBE_TRACKS prefix match on A's agent namespace.¶

Resulting namespace layout:¶

Agent A publishes:
  ("pace","agents","agent-a","s3") -- "ctrl"     (session mgmt, assignments)
  ("pace","agents","agent-a","s3") -- "chat"     (coordination messages)

Agent B publishes:
  ("pace","agents","agent-b","s3") -- "ctrl"     (SESSION_ACCEPT)
  ("pace","agents","agent-b","s3") -- "chat"     (status updates)
  ("pace","agents","agent-b","s3") -- "a2a/task/research-1"  (findings)

Agent C publishes:
  ("pace","agents","agent-c","s3") -- "ctrl"     (SESSION_ACCEPT)
  ("pace","agents","agent-c","s3") -- "chat"     (status updates)
  ("pace","agents","agent-c","s3") -- "a2a/task/analysis-1"  (results)

Subscriptions: Each agent subscribes to the other two agents' session namespaces:¶

• A subscribes to ("pace","agents","agent-b","s3") and ("pace","agents","agent-c","s3")¶

• B subscribes to ("pace","agents","agent-a","s3") and ("pace","agents","agent-c","s3")¶

• C subscribes to ("pace","agents","agent-a","s3") and ("pace","agents","agent-b","s3")¶

Flow:¶

1. A establishes session, B and C accept¶

2. A publishes task assignments on "chat" — the relay fans out to both B and C¶

3. B performs web research, publishes findings incrementally on "a2a/task/research-1" (using MOQT groups for phases)¶

4. C subscribes to B's research track, receives findings as they arrive, and begins analysis¶

5. C publishes analysis results on "a2a/task/analysis-1"¶

6. A monitors all progress through its subscriptions and publishes a final summary when complete¶

7. A publishes SESSION_CLOSE — all participants unsubscribe¶

A.4. Agent-to-Tool with Streaming: Long-Running Operation

Agent A invokes a code-generation tool that produces output incrementally.¶

Setup: Same as tool invocation — Agent A and the tool share session-id s4.¶

Flow:¶

1. A publishes a tool call on "mcp/tools/generateCode"¶

2. Tool begins generating code and publishes results using MOQT groups:¶

   • Group 0: {"status":"started","language":"python"}¶

   • Group 1, Object 0: first code block¶

   • Group 1, Object 1: second code block¶

   • Group 2: {"status":"complete","totalLines":142}¶

3. A receives objects as they are published (ascending group order)¶

4. If A needs to cancel, it publishes a cancellation on "ctrl"¶

5. Tool receives cancellation, stops generation, publishes final status¶