PACE: Protocol for Agent Communication Exchange

1.1. Scope and Goals

Agent interactions are increasingly live dialogs rather than one-shot requests. A user speaks while an agent answers, cuts in, and expects the agent to stop. Voice and video run alongside chat, streaming model output, and tool calls. Several agents and people work on the same task, and the task can outlast a single connection or network. In natural spoken conversation, people take turns within a few hundred milliseconds [STIVERS], so an interruption has to take effect ahead of output that is already queued. PACE is designed for these dialogs.¶

PACE addresses the following goals.¶

• Dialog correlation: A dialog identifier that stays stable across hops, intermediaries, trust boundaries, modality changes, and time. Defined by the dialog context: identifier, generation, state, controller, and participants (Section 3.1).¶

• Multi-modal exchange: Real-time media, chat, streaming model output, and request/response operations in one dialog. Each modality keeps its own latency and reliability, and none of them delays the others, even when they share one transport session (Section 5).¶

• Multi-party exchange: Point-to-point, point-to-multipoint, and multi-party dialogs among agents and people. Relays fan out each message, so a sender publishes once however many participants there are, and late joiners catch up from relay caches (Section 6).¶

• Low-latency interaction: Dialog control, including interruption and cancellation, takes effect within the latency of natural conversation and ahead of queued content, so that agents can hold an interactive voice conversation (Section 5).¶

• Dialog lifecycle: Opening, updating, and terminating dialogs, and revoking propagation relationships, with the controller as the single authoritative source of state (Section 3.2).¶

• Resilience: Recovery from path and intermediary failures, resumption after interruption, and defined behavior when a participant or the controller is unreachable (Section 3.3, Section 4.3.5).¶

• Transport independence: A dialog model that any transport can carry. This document specifies a MOQT binding: namespaces, tracks, operation mapping, and delivery (Section 4).¶

• Application protocol reuse: MCP, the Personal Agent Protocol, AutoGen, and A2A keep their native messages and carry the dialog context (Section 8).¶

• Identity and authorization reuse: Agent identity separate from user identity, delegated authorization, and selective disclosure, without mandating a token format (Section 7, Section 9).¶

• Privacy: Mitigations for linkage through persistent dialog and participant identifiers (Section 9.3).¶

PACE does not define trust frameworks, authorization protocols, or audit data structures; deployments use existing mechanisms, and auditing systems can use dialog identifiers. Dialog content, model behavior, planning, and task semantics are also out of scope.¶

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.¶

1.3. Terminology

Dialog:

The correlated sequence of interactions between two or more participants over the course of a task. A dialog can outlast any single message exchange, MOQT session, or transport connection. A two-party dialog is an agentic dialog [ARCH], which composes larger topologies by cascading two-party dialogs; PACE supports both cascaded and multi-party dialogs (Section 6).¶

Dialog context:

The identifiers and lifecycle state needed to correlate and maintain a dialog (Section 3.1). The dialog context does not include content exchanged with AI models, such as conversation memory, retrieved documents, prompts, or media payloads. It corresponds to the meta-data of the [ARCH] dialog context. The [ARCH] log is the dialog's content, which a binding carries; in the MOQT binding, it is the sequence of objects on the dialog's content tracks (Section 4.2.2).¶

Dialog identifier (dialog-id):

A UUID that names a dialog for its whole lifetime.¶

Participant:

A user-facing client, agent, tool, or service that takes part in a dialog and processes its dialog context. Each participant has a participant identifier that is unique within the dialog. In the MOQT binding, the participant identifier is the agent-id field of the participant's tracks in the dialog namespace (Section 4.1). A participant plays the principal or agent role of [ARCH]; the controller is usually the principal's client.¶

Controller:

The participant that opened the dialog. The controller is the authoritative source of the dialog context and the only participant that changes the participant set, expiration, generation, or terminal state.¶

Intermediary:

An entity that forwards dialog context between participants without being the source of it. A MOQT relay that forwards PACE tracks is an intermediary, and so is a gateway that transforms one modality into another.¶

Propagation relationship:

The authorization and forwarding relationship that allows a participant or intermediary to receive or forward a dialog's context. PACE signals the creation and revocation of such relationships; the deployment's authorization mechanism enforces them.¶

MOQT session:

A transport-level session established with MOQT SETUP. A MOQT session is not a dialog: one dialog can span several MOQT sessions, and one MOQT session can carry several dialogs.¶

2.1. Transport Requirements

Live dialogs (Section 1.1) place the following requirements on the transport that carries them. They refine the transport aspects of Section 8 of [ARCH] for live, multi-modal dialogs.¶

• Low latency: Each flow reaches participants within the latency its modality needs: under 100 ms for real-time media, and under a second for chat and streaming model output (Section 5). A loss or a backlog on one flow does not add delay to another.¶

• Push delivery: Content, new participants, new flows, and new dialogs reach participants as soon as they are published, without polling.¶

• Interruption: Dialog control, such as an interruption or a cancellation, reaches its receiver ahead of content that is already queued. Real-time content that is too late to be useful is dropped instead of being delivered late.¶

• Concurrent flows: Real-time media, chat, streaming model output, tool calls, and bulk transfers share one dialog and one connection, each with its own priority and reliability.¶

• Fan-out: One message reaches every participant without the sender sending a copy to each. Participants that join late or reconnect can catch up.¶

• Continuity: A dialog survives connection migration, network changes, reconnection, and intermediaries.¶

• Scale and control: Dialogs scale through intermediaries across regions, and each intermediary enforces who may send and receive.¶

Request/response mechanisms might not meet these requirements. When a dialog's flows share one ordered connection, a cancellation waits behind output that has already been sent, and one lost packet stalls every flow. Delivery to several participants, and learning about new ones, are left to the application.¶

2.2. Why MOQT?

This document specifies a MOQT binding for exchanging dialogs. Media over QUIC Transport (MOQT) [MoQ-TRANSPORT] is a publish/subscribe protocol over QUIC [RFC9000]. It meets each requirement in Section 2.1 with a transport mechanism, so agent protocols do not need to rebuild them.¶

• Low latency: Objects are sent as soon as they are produced, on QUIC streams or datagrams alike, and relays forward them as they arrive, without waiting for the rest of a group. Each track has its own streams, so a loss on one flow does not hold up the others. Datagrams are not retransmitted, so real-time media keeps flowing under congestion instead of waiting for lost data.¶

• Push delivery: Agents publish and subscribe directly, with no polling and no long-lived HTTP connections. Content reaches subscribers as soon as it is published. SUBSCRIBE_TRACKS on a namespace prefix delivers all current and future tracks under that prefix, so new participants and flows appear without a separate signaling channel. Output that arrives minutes or hours after its input reaches the subscriber without a webhook or a client-side HTTP server.¶

• Interruption: Publisher priority (per subgroup or datagram) and subscriber priority (per subscription) let dialog control overtake queued lower-priority data, so a cancellation reaches the agent ahead of output already in flight. Per-track delivery timeouts let the publisher mark time-sensitive objects: objects that miss the deadline, such as a voice frame whose playout window has passed, are dropped at the relay instead of wasting bandwidth and queue depth.¶

• Concurrent flows: One MOQT session carries sub-100ms media, sub-second chat, and best-effort bulk transfers at the same time, in one congestion control context. Objects can be delivered over QUIC datagrams, which suit real-time audio and video where lower latency matters more than retransmission, or over QUIC streams, which suit agent chat, operations, and bulk transfers that need ordered, reliable delivery.¶

• Fan-out: A single PUBLISH reaches every subscriber through the relay, so multi-agent collaboration does not need application-level broadcast code, and the publisher keeps no per-subscriber state. Relay caches let late-joining or reconnecting agents catch up without the publisher retransmitting.¶

• Continuity: QUIC provides connection migration (for example, from Wi-Fi to cellular) and 0-RTT resumption. A dialog is not tied to a MOQT session: one dialog can span several sessions (Section 1.3). An agent namespace is not tied to a host either, so the principal and the agent can each move between hosts over a dialog's lifetime and a new client instance catches up from relay caches.¶

• Scale and control: Relays handle NAT traversal, load balancing, and fan-out without direct peer-to-peer connections, and they can be stacked hierarchically to spread load across regions without an all-to-all mesh. Namespace-level access control maps onto agent authorization scopes: the relay decides who may publish or subscribe to each namespace. QUIC provides TLS 1.3 for every hop.¶

Where UDP is blocked, the same MOQT binding can run over QMux [QMUX], which provides QUIC stream and datagram operations over TLS over TCP. Agents keep one protocol stack instead of falling back to a separate one, at the cost of TCP head-of-line blocking and reliable, ordered datagrams.¶

3.1. Dialog Context

A dialog context contains the following fields:¶

• dialog_id: A UUID version 4 [RFC9562]. The controller generates it when opening the dialog. It remains unchanged for the lifetime of the dialog, including when the dialog crosses an intermediary, changes modality, or resumes after a connection loss.¶

• generation: An unsigned integer identifying the current controller state. The initial generation is 0. The controller increments it by one for each committed change to the dialog context, including a change in a participant's state.¶

• state: One of pending, active, or terminated.¶

• controller_id: The participant identifier of the controller.¶

• participants: The set of participant identifiers in the dialog, each with a state: invited, active, left, rejected, or revoked.¶

• expires_at: An optional absolute time in RFC 3339 date-time format. When present, participants treat the dialog as terminated at that time.¶

• parent_dialog_ids: An optional list of dialog-ids, set by the controller in OPEN when the dialog is opened to carry out work delegated from another dialog. The first entry is the dialog that triggered this one, followed by that dialog's own parents, so the list traces the delegation chain back to the originating dialog (Section 6.2.1 of [ARCH]). It does not change after OPEN.¶

The context is encoded as a JSON object:¶

{
  "dialog_id": "550e8400-e29b-41d4-a716-446655440000",
  "generation": 0,
  "controller_id": "agent-a",
  "state": "pending",
  "participants": [
    {"participant_id": "agent-a", "state": "active"},
    {"participant_id": "agent-b", "state": "invited"}
  ],
  "expires_at": "2026-10-23T12:00:00Z"
}

The expires_at member is omitted when the dialog has no configured expiration, and parent_dialog_ids is omitted when the dialog was not opened from another dialog. A context snapshot MUST contain every other member, including participants whose states are left, rejected, or revoked. A controller MUST NOT remove a participant from a later snapshot; it changes that participant's state instead. The controller MUST appear in the participant set with state active.¶

The identity of the principal on whose behalf a delegated dialog runs travels in the credentials member as a delegation chain (Section 7.1.2), not in the dialog context.¶

These identifiers are correlation values. They MUST NOT be treated as credentials or bearer authorization. Knowing a parent dialog-id does not grant access to the parent dialog. A participant identifier MUST NOT encode personal or task information.¶

3.2. Lifecycle and Control Operations

The dialog lifecycle has three states:¶

                  OPEN (controller, generation 0)
                                |
                                v
                         +-------------+
              UPDATE +-->|   PENDING   |------------------+
                     |   +-------------+                  |
                     |      |      |                      |
                     +------+      | UPDATE committing    | TERMINATE
                                   | an invitee's ACCEPT  | or expiry
                                   v                      v
                         +-------------+            +------------+
      UPDATE, REVOKE +-->|   ACTIVE    |----------->| TERMINATED |
                     |   +-------------+ TERMINATE  |  (final)   |
                     |      |            or expiry  +------------+
                     +------+

pending:

The controller has opened the dialog, but no invitee has accepted.¶

active:

At least one invitee has accepted, and the dialog has not been terminated or expired. The context can be modified with UPDATE and REVOKE.¶

terminated:

The controller has terminated the dialog, or its expiration time has passed. This state is final.¶

Only the controller causes transitions. UPDATE, REVOKE and TERMINATE each advance the generation by one. ACCEPT, REJECT, JOIN_REQUEST and LEAVE are requests the controller commits with UPDATE. Interruptions and cancellations do not change the state.¶

An interruption, such as a lost connection or relay failure, does not change the dialog state. Participants recover the current context as described in Section 3.3. A participant's own state is tracked separately from the dialog state: joining or leaving does not by itself terminate the dialog. When the controller commits a LEAVE that leaves it as the only active participant, it SHOULD publish TERMINATE. This lets an agent that is not the controller end a two-party dialog.¶

The control operations below cover the lifecycle functions of Section 6.1.2 of [ARCH]. Initiation is OPEN, and termination is TERMINATE, expiry, or a LEAVE that ends a two-party dialog. Suspension needs no operation: a dialog persists through idle periods with no transport connection, and a binding can pause individual flows. Resumption is STATE_REQUEST together with the binding's recovery of missed content (Section 4.3.5 for MOQT), and cancellation is CANCEL (Section 3.2.3).¶

PACE defines the following control operations:¶

3.3. Propagation and Continuity

• Correlation across hops: An intermediary MUST preserve the dialog identifier, generation, and lifecycle operation when forwarding dialog context. It MUST NOT create a new dialog identifier or change the dialog state. This document defines no identifier-alias mechanism; a deployment that needs aliases requires a separate mechanism that securely correlates the alias with the original dialog.¶

• Trust boundaries: A participant forwarding dialog context into another trust domain does so only within a propagation relationship that the deployment's authorization mechanism permits. Authorization to forward or subscribe at the transport layer does not by itself make an entity a participant.¶

• Modality changes: Transforming a modality, such as converting audio to text, does not create a new dialog. Participants and intermediaries MUST keep the same dialog identifier and current lifecycle state across the transformation.¶

• Continuity over time: After a connection loss, a participant MAY reconnect, over a new transport session if necessary, using the existing dialog identifier. It MUST obtain the current context from the controller with STATE_REQUEST before acting on state that may have changed while it was disconnected. Recovering the dialog context does not imply that any application operation was delivered or completed, or that it is safe to retry.¶

• Unreachability: If the controller is unreachable, participants MUST suspend actions that depend on an unconfirmed context change. Each participant remains at the last generation it accepted until the controller is reachable again or the dialog expires. Participants MUST NOT create a replacement dialog solely because a path or intermediary failed. If an invitee or participant is unreachable, the controller MAY revoke it or let the dialog expire, according to deployment policy.¶

3.4. Control Message Encoding

A PACE control message is a UTF-8 encoded JSON object [RFC8259]. Every control message contains these members:¶

• version: The integer 1.¶

• type: One of the operations in Section 3.2.¶

• dialog_id: The canonical textual form of the dialog's UUID.¶

• generation: A non-negative integer no greater than 2^53 - 1.¶

• sender_id: The sender's participant identifier.¶

• message_id: A UUID version 4 unique to this message.¶

Control messages also carry the following type-specific members:¶

• context: The complete dialog context, encoded as the JSON object defined in Section 3.1.¶

• in_reply_to: The message_id of the OPEN or UPDATE being accepted or rejected, of the CANCEL being acknowledged, or of the message an ERROR rejects.¶

• target_id: The participant identifier whose propagation relationship is revoked.¶

• scope: The cancellation scope: operation, subtree, or dialog (Section 3.2.3).¶

• target: The operation to cancel when scope is operation. Its form is defined by the transport binding (Section 4.3.6).¶

• outcome: One of stopped, completed, or irreversible.¶

• last_accepted_generation: The highest generation the sender has accepted from the controller, or -1 if it has accepted none.¶

• reason: One of malformed, unsupported-version, unsupported-operation, stale-generation, unauthorized, authorization-unavailable, or policy-rejected. These distinguish validation, authorization, and policy failures from transport failures, which MOQT reports separately (Section 6.1.5 of [ARCH]).¶

Each type requires the members listed below:¶

For OPEN, context has generation 0 and state pending, and carries parent_dialog_ids when the dialog is delegated. For UPDATE, REVOKE, and TERMINATE, context has the next generation, and a TERMINATE context has state terminated. An UPDATE that adds a participant sets that participant's state to invited; the participant becomes active only after it accepts and the controller publishes a later UPDATE.¶

Three optional members carry information that is not part of the dialog context:¶

• parameters: On OPEN, ACCEPT, UPDATE, and JOIN_REQUEST, the dialog parameters being proposed or accepted, such as modalities and application protocols (Section 3.1.1).¶

• credentials: On any message, an identity assertion or authorization proof in a format selected by the deployment (Section 7.1.1). A participant refreshes its credentials before they expire by including new ones on a later message.¶

• nonce: On OPEN, ACCEPT, UPDATE, and JOIN_REQUEST, a fresh random value, with at least 128 bits of entropy and base64url-encoded, to which the recipient binds the presentation in its next credentials (Section 7.1.4).¶

JSON member order is insignificant. Receivers MUST ignore unrecognized optional members, MUST reject an unrecognized type, and MUST reject messages with missing required members, invalid member types, or an unsupported version. Receivers MUST limit the size of a control message to a locally configured maximum. A participant MUST NOT include application content in a control message.¶

4.1. Namespace Organization

PACE uses MOQT's hierarchical namespace for routing, isolation, and multiplexing. In MOQT, content is addressed by a Track Namespace (an ordered set of up to 32 fields, compared as byte sequences [MoQ-TRANSPORT]) together with a Track Name. PACE organizes communication into two namespace scopes: an agent namespace for each agent's identity and invitations, and a dialog namespace for all of a dialog's traffic.¶

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

  ("pace", "dialogs", {dialog-id}, {agent-id}) -- {track}

("pace", "dialogs", {dialog-id}, {agent-id}, {proto}, {category},
 ...) -- {id}

A2A: "agent-a" sends request "r1" (in a dialog with "agent-b")
  ("pace","dialogs",D,"agent-a","a2a","request") -- "r1"

A2A: "agent-b" publishes updates for task "t1"
  ("pace","dialogs",D,"agent-b","a2a","task") -- "t1"

MCP: client "agent-a" calls tool "read_file" on "fs-server"
  ("pace","dialogs",D,"agent-a","mcp","tools","read_file")
      -- "request"

MCP: "fs-server" publishes the result of that call
  ("pace","dialogs",D,"fs-server","mcp","tools","read_file")
      -- "response"

  ("pace", "agents", {controller-id}, "invites") -- {invitee-id}

4.2. Transport Binding

4.3. Dialog Operations over MOQT

This section specifies how the operations of Section 3 are carried over MOQT. Each control message is one MOQT object on the sender's ctrl track under ("pace","dialogs",{dialog-id},{agent-id}). MOQT control messages (PUBLISH, SUBSCRIBE, their responses, PUBLISH_DONE) establish and end the subscriptions that carry those objects. They are not dialog operations: PUBLISH_OK accepts a MOQT subscription, not a dialog, and a participant MUST NOT infer acceptance, rejection, or termination of a dialog from a MOQT response or cancellation alone.¶

The ctrl track MUST use Subgroup Delivery Mode and MUST NOT use Datagram Delivery Mode or a finite delivery timeout. A participant publishes control objects in increasing Object ID order, and the controller publishes state-changing operations in increasing generation order. Because ctrl is a track of its own, a CANCEL, ERROR, or TERMINATE is not lost or delayed when a content track fails or falls behind.¶

{
  "namespace": ["mcp", "tools", "search"],
  "track": "request",
  "group": 3
}

5.1. Modality Types

PACE defines the following data modality classes:¶

These classes correspond to the low-latency loss-tolerant, reliable ordered, and high-throughput reliable delivery semantics of Section 8.1 of [ARCH].¶

5.2. Channel Architecture

Each modality maps to dedicated MOQT tracks within the dialog namespace (Section 4.1.2). Different modalities are isolated by track name while sharing the dialog context and authorization.¶

Within a track, a MOQT group is a synchronization point. The objects in a group carry what belongs together at that point, such as one message, one request and its incremental results, or one phase of an operation, and relays carry them together. A publisher starts a new group at each point where a receiver can begin consuming the track without earlier objects, so a subscriber that joins or recovers starts at a group boundary (Section 4.3.5).¶

5.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 tiers of subscriber priority:¶

MOQT relays forward Publisher Priority unchanged, so PACE applies policy through subscriber priority, which MOQT applies before publisher priority. A subscriber sets the subscriber priority of each subscription according to its policy for that peer and track, and can change it with REQUEST_UPDATE, so a publisher cannot raise the urgency of its traffic beyond what its subscribers allow. A subscriber MUST subscribe to a ctrl track with a subscriber priority in the Dialog Control tier.¶

5.4. Request/Response Pattern

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

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

5.5. Streaming Pattern

Long-running operations produce incremental results as MOQT objects. The publisher starts a new group at each synchronization point (Section 5.2), such as a phase transition (initialization, progress, completion), and the objects in a group carry the incremental data for that phase.¶

Late-joining subscribers catch up mid-operation with a join fetch, and retrieve a specific range with a bounded fetch (Section 4.3.5).¶

Upon operation completion, the publisher sends PUBLISH_DONE on the operation track to signal end-of-stream. Receivers treat PUBLISH_DONE as the authoritative completion marker; publishers MUST NOT emit further objects on that track after PUBLISH_DONE.¶

To cancel an in-progress streaming operation, the requester publishes CANCEL on its ctrl track (Section 4.3.6), or the application protocol's own cancel message on its request or operation track. The publisher then stops the operation and sends PUBLISH_DONE to end the stream. REQUEST_UPDATE with FORWARD=0 only pauses delivery to that subscriber; it does not cancel the operation.¶

5.6. Real-Time Media Exchange

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

7.1. Agent Identity Model

PACE treats the agent as an authenticated principal distinct from the user it represents. Separating the two makes it possible to revoke an agent without affecting the user, scope an agent to a subset of what the user is allowed to do, and audit what the agent did on its own versus what the user initiated.¶

PACE does not define a new identity token format or claim set. The credential an agent presents in the credentials member of the control message it uses to open, accept, or join a dialog (Section 3.4) identifies:¶

• the agent, by its participant identifier in the dialog or by an identifier that the protocol binding relates to it, such as the Poppy client_id (Section 8.4);¶

• the user, workload, or organization the agent acts for; and¶

• when the agent acts for another agent, the delegation chain (Section 7.1.2).¶

In JWT-based formats, these map to the registered claims sub, iss, iat, and exp [RFC7519] and to the act (actor) claim [RFC8693] for delegation. Other formats carry the equivalent information in their own fields. The token format and the trust framework are chosen by the deployment.¶

7.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 4.1. Each agent is identified by a globally unique agent-id (UUID), verifiable via the Agent Card (see Section 7.2.3).¶

8.1. Carrying Dialog Context in Application Protocols

An application message joins a dialog by carrying a dialog reference in the protocol's own extension point, whether or not the protocol runs over MOQT. The reference is this object, under the metadata key org.ietf.agentproto/dialog-context:¶

{
  "dialog_id": "550e8400-e29b-41d4-a716-446655440000",
  "generation": 3
}

generation is the latest generation the sender knows. The controller's ctrl track stays authoritative; a receiver that needs the full context sends STATE_REQUEST.¶

A dialog-id MUST NOT be used as a task, request, content, or session identifier, or as a credential.¶

8.2. Binding Architecture

A binding specifies:¶

• Protocol identifier: the namespace field that follows the dialog-id.¶

• Namespace pattern: how operations map to namespace fields and track names within the agent's dialog namespace.¶

• Message serialization: how native messages are encoded in MOQT object payloads. Bindings SHOULD use the native wire format as the object payload (Section 4.2.3).¶

• Dialog reference: where messages carry the dialog reference (Section 8.1).¶

• Priority: which PACE priority tier its tracks use (Section 5).¶

• Identity and authorization: how the protocol's own identity and authorization constructs (if any) relate to the credential mechanisms (Section 7.1.1) in this document.¶

A complete mapping of each protocol operation to MOQT primitives belongs in a protocol-specific document, such as [MCP-MOQT] for MCP.¶

Protocols use distinct protocol namespace fields within PACE dialogs. In the tables of this section, a pattern such as ("a2a", "task") -- {task-id} gives the namespace fields that follow ("pace", "dialogs", {dialog-id}, {agent-id}), then the track name.¶

In the examples, D is the dialog-id.¶

8.3. MCP Binding

The Model Context Protocol [MCP] binding enables tool and resource access for agents. Within a PACE dialog, MCP tracks add an "mcp" namespace field after the dialog-id, under the namespace of the agent that publishes the track:¶

Namespace: ("pace", "dialogs", {dialog-id}, {agent-id}, "mcp",
            {category}, ...)
Tracks:    {track-name}

The complete MCP over MOQT specification, covering track structure, operation mapping, message serialization, Agent Skills, and relay support, is defined in [MCP-MOQT]. PACE adopts its track semantics. The mapping is mechanical: the leading (mcp, {server-id}, clients, {client-id}) or (mcp, {server-id}) fields of an MCP over MOQT namespace are replaced by ("pace", "dialogs", {dialog-id}, {agent-id}, "mcp"), and the remaining namespace fields and the track name are kept unchanged. For example, with {cli} and {srv} the agent-ids of the MCP client and server:¶

MCP needs no handshake of its own, and MCP over MOQT client IDs are not used within PACE: PACE supplies the dialog-id, and peers learn each other's MCP tracks through SUBSCRIBE_TRACKS on the dialog prefix.¶

MCP messages keep their native JSON-RPC format as the object payload (Section 4.2.3) and carry the dialog reference in _meta (Section 8.1). Key operations map as follows:¶

MCP tracks use the PACE priority tiers (Section 5) as [MCP-MOQT] assigns them: control, tool, prompt, task and skill execution tracks use Standard Operations, catalog and skill content tracks Discovery, and resource tracks Bulk Transfer.¶

An MCP server that holds an MCP SD-Card returns a key-bound presentation to the client that requests one (Section 8.2.4 of [SD-CARD]). That presentation is specific to the requesting client, and SD-Card requires the response carrying it to have a private cacheScope. Within PACE, relay authorization keeps the response track within the dialog (Section 9.2.1). The nonce and audience prevent replay of the presentation, but other participants of the dialog can read the claims it discloses, so the server discloses only claims that every participant may see.¶

When a Key Binding JWT carries an interaction_id, an agent includes it in the MCP requests it makes for that interaction (Section 8.5 of [SD-CARD]). Agents MAY use the dialog-id as the interaction_id, so that presentations and messages correlate on the same identifier.¶

8.4. Personal Agent Protocol Binding

The Personal Agent Protocol (Poppy) [POPPY] lets a person's own agent (the Personal Agent) sign in to a Company and talk to the Company's agent (the Company Agent). Poppy defines discovery through a poppy.json document, OAuth-based identity with pairwise user identifiers, API access through OpenAPI and MCP, and a Conversations protocol over HTTPS.¶

This binding carries Poppy Conversations over PACE. Poppy discovery, OAuth sign-in, web browsing, feedback and excluded-task documents are unchanged and continue to use HTTPS. Poppy APIs of type mcp can use the MCP binding (Section 8.3) when the Company offers MCP over MOQT.¶

{
  "agent": {
    "protocols": [
      { "type": "poppy", "endpoint": "https://acme.example/agent" },
      {
        "type": "pace",
        "binding": "poppy",
        "endpoint": "https://acme.example/poppy/pace",
        "relayEndpoint": "moqt://relay.acme.example:4443",
        "namespace": ["pace", "agents", "acme"]
      }
    ]
  }
}

Namespace: ("pace", "dialogs", {dialog-id}, {agent-id}, "poppy",
            "conversation")
Tracks:    "messages" | "requests" | "events" | "deltas"

8.5. A2A Binding

The Agent-to-Agent Protocol [A2A] binding places A2A messages on tracks under each agent's dialog namespace, using the "a2a" protocol namespace field:¶

A2A messages keep their native JSON-RPC 2.0 format as the object payload (Section 4.2.3) and carry the dialog reference in the message metadata (Section 8.1). Key operations map as follows:¶

A response that creates a task carries the A2A task-id, which names the server's task track. A2A tracks use the Interactive priority tier for requests and responses and the Standard Operations tier for task updates (Section 5). An A2A agent advertises PACE support through A2A's own Agent Card extension mechanism, pointing to its PACE Agent Card (Section 7.2.3).¶

An A2A agent that holds an A2A SD-Card (Section 8.4 of [SD-CARD]) publishes it as its PACE Agent Card. Its supportedInterfaces claim is disclosed per element and its capabilities claim selectively, so the agent can disclose its PACE interface and extension only in the discovery contexts it chooses. The SD-Card A2A extension, which carries a key-bound presentation in the metadata of the first Message or Task in a context, works unchanged over these tracks because A2A messages keep their native format. An A2A contextId is used within one dialog, so the agent presents its SD-Card at most once per contextId in that dialog.¶

A complete mapping of A2A operations to MOQT is left to a separate document coordinated with the A2A maintainers, as [MCP-MOQT] does for MCP.¶

8.6. Generic Binding

A protocol without its own binding uses the "ext" protocol namespace field followed by a field naming the protocol:¶

Namespace: ("pace", "dialogs", {dialog-id}, {agent-id}, "ext",
            {protocol-name}, ...)
Tracks:    {identifier}

The protocol's native messages are the object payloads (Section 4.2.3), and they carry the dialog reference in the protocol's own extension point (Section 8.1). The protocol defines its own namespace fields and track names below {protocol-name}.¶

9.1. Authorization Model

Access in PACE is granted through authorization proofs scoped to the operations an agent may perform. PACE does not define a new authorization protocol or scope syntax. The scope representation, token format, issuance mechanism, and verification policy come from the mechanism the deployment selects (Section 7.1.1).¶

9.2. Transport Security

All PACE traffic is encrypted under TLS 1.3 because QUIC requires it. MOQT relays terminate QUIC and TLS on each hop, so transport-layer authentication identifies only the adjacent hop. PACE therefore authenticates participants at the application layer, through the credentials member of control messages, as Section 7.2 of [ARCH] requires when intermediaries terminate TLS. Identity assertions and authorization proofs are signed and short-lived. MOQT Common Access Tokens [MoQ-C4M] handle namespace-level authorization at the relay. Relays cannot read payload content unless the deployment explicitly trusts them to.¶

9.3. Privacy Considerations

PACE dialog and participant identifiers (dialog-ids and agent-ids) can persist across intermediaries and trust boundaries. If several parties see them in the clear, they can be used to correlate interactions that would otherwise look unrelated. This is a known risk for any dialog management protocol. Deployments mitigate it as follows:¶

• Identity claims and agent metadata are disclosed selectively (Section 7.1.3): agents reveal only what each peer needs. Selective disclosure does not hide the agent's identity (Section 7.2.3).¶

• Authorization proofs are narrowed to the minimum scope and refreshed before expiration so intermediaries cannot replay broad grants.¶

• Agents acting for an individual person SHOULD use pairwise or per-dialog agent-ids in their dialog namespaces, so that relays cannot link that person's dialogs with different peers. The Poppy binding requires this (Section 8.4).¶

• Dialog-ids SHOULD be fresh per dialog. Reusing a dialog-id across unrelated interactions re-introduces the linkage risk the identifier is supposed to avoid.¶

• Payload content SHOULD remain encrypted end-to-end with respect to relays unless the relay is explicitly trusted.¶

• Long-lived dialogs SHOULD rotate keys periodically; QUIC provides the key material lifecycle.¶

• Agent Cards SHOULD advertise only what discovery requires. Relays and every subscriber to the "card" track see it. Finer capability details can be disclosed in a key-bound presentation after a dialog begins (Section 7.2.3).¶

Relay operators MUST NOT retain content past operational need. Agents SHOULD send only what the task requires.¶

10.1. Failure Modes and Recovery

Agent network loss and relay failure are recovered as described in Section 4.3.5. An unreachable participant or controller is handled by the rules in Section 3.3, and a dialog that outlasts its expiration or idle timeout ends as described in Section 3.1.2.¶

13.1. Normative References

[MoQ-TRANSPORT]

Nandakumar, S., Vasiliev, V., Swett, I., Ed., and A. Frindell, Ed., "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-22, October 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>.

[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>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[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>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

13.2. Informative References

[A2A]

Linux Foundation, "Agent-to-Agent Protocol Specification", Version 1.0, 2025, <https://a2a-protocol.org/latest/>.

[ARCH]

Rosenberg, J., Sarker, Z., Reddy.K, T., Yao, K., Liu, D., and S. Krishnan, "Architecture for AI Agent Communications on the Internet", Work in Progress, Internet-Draft, draft-manyfolks-agentproto-arch-00, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-manyfolks-agentproto-arch-00>.

[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]

Linux Foundation, "Model Context Protocol Specification", Version 2026-07-28, July 2026, <https://modelcontextprotocol.io/specification/2026-07-28>.

[MCP-MOQT]

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

[MoQ-C4M]

Law, W., Lemmons, C., Simon, G., and S. Nandakumar, "Authorization scheme for MOQT using Common Access Tokens", Work in Progress, Internet-Draft, draft-ietf-moq-c4m-01, 2026, <https://datatracker.ietf.org/doc/draft-ietf-moq-c4m/>.

[POPPY]

Sierra and Meta, "Personal Agent Protocol (Poppy) Specification", Version Draft 0.3, 2026, <https://personalagentprotocol.org/docs/0.3/spec>.

[QMUX]

Oku, K., Pardue, L., Iyengar, J., and E. Kinnear, "QMux", Work in Progress, Internet-Draft, draft-ietf-quic-qmux-02, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-qmux-02>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[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>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[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>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9576]

Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June 2024, <https://www.rfc-editor.org/rfc/rfc9576>.

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/rfc/rfc9635>.

[RFC9901]

Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, <https://www.rfc-editor.org/rfc/rfc9901>.

[SD-CARD]

Nandakumar, S. and C. Jennings, "Agent SD-Card: Selective Disclosure of Agent Metadata for Discovery and Authentication", Work in Progress, Internet-Draft, draft-nandakumar-agent-sd-card-00, October 2026, <https://datatracker.ietf.org/doc/draft-nandakumar-agent-sd-card/>.

[STIVERS]

Stivers, T., Enfield, N. J., Brown, P., Englert, C., Hayashi, M., Heinemann, T., Hoymann, G., Rossano, F., de Ruiter, J. P., Yoon, K., and S. C. Levinson, "Universals and cultural variation in turn-taking in conversation", Proceedings of the National Academy of Sciences, vol. 106, no. 26, pp. 10587-10592, DOI 10.1073/pnas.0903616106, June 2009, <https://doi.org/10.1073/pnas.0903616106>.

[WIMSE-CREDS]

Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft-ietf-wimse-workload-creds-03, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-03>.

A.1. Delegating a Task with A2A

A asks B to do a task. This example shows the complete dialog lifecycle; the later examples abbreviate it.¶

A publishes:
  ("pace","dialogs",D1,"agent-a") -- "ctrl"        OPEN, UPDATE,
                                                   TERMINATE
  ("pace","dialogs",D1,"agent-a","a2a","request") -- "r1"
                                                   task request
B publishes:
  ("pace","dialogs",D1,"agent-b") -- "ctrl"        ACCEPT
  ("pace","dialogs",D1,"agent-b","a2a","response") -- "r1"
                                                   task result

1. A publishes OPEN on its ctrl track (gen 0, B invited) and an invitation on ("pace","agents","agent-a","invites") -- "agent-b".¶

2. B reads OPEN on A's ctrl track and publishes ACCEPT on its own ctrl track.¶

3. A publishes UPDATE (gen 1, B active). The dialog is active.¶

4. A publishes the A2A request on its request track r1: {"jsonrpc":"2.0","method":"SendMessage","params":{...},"id":"r1"}, with the dialog reference in the message metadata (Section 8.1).¶

5. B publishes the result on its response track r1.¶

6. A publishes TERMINATE (gen 2). B could instead have sent LEAVE.¶

A.2. Calling an MCP Tool

A reads a file through an MCP server, fs-tool.¶

A publishes:
  ("pace","dialogs",D2,"agent-a") -- "ctrl"
  ("pace","dialogs",D2,"agent-a","mcp","tools","readFile")
      -- "request"                                 tools/call
fs-tool publishes:
  ("pace","dialogs",D2,"fs-tool") -- "ctrl"
  ("pace","dialogs",D2,"fs-tool","mcp","tools","readFile")
      -- "response"                                result

1. A opens the dialog with fs-tool (OPEN, ACCEPT, UPDATE).¶

2. A publishes the call as Object 0 of a new group, say Group 7, on its readFile request track: {"jsonrpc":"2.0","method":"tools/call","params":{"name":"readFile", "arguments":{"path":"/data/report.csv"}},"id":"t1"}.¶

3. fs-tool publishes the result as the final object in Group 7 of its readFile response track: {"jsonrpc":"2.0","id":"t1","result":{"resultType":"complete", "content":[...]}}. The JSON-RPC id pairs the response with the request; the matching Group ID helps relays and recovery ([MCP-MOQT]).¶

4. A makes further calls as new groups, or terminates the dialog.¶

A.3. Long-Running Tool Call with Progress

A asks code-tool to generate code. The call takes a while, so code-tool reports progress while it works and sends the code in the final result.¶

A publishes:
  ("pace","dialogs",D3,"agent-a") -- "ctrl"
  ("pace","dialogs",D3,"agent-a","mcp","tools","generateCode")
      -- "request"                                 tools/call,
                                                   cancellation
code-tool publishes:
  ("pace","dialogs",D3,"code-tool") -- "ctrl"
  ("pace","dialogs",D3,"code-tool","mcp","tools","generateCode")
      -- "response"                                progress, result

1. A opens the dialog with code-tool (OPEN, ACCEPT, UPDATE).¶

2. A publishes the call as Object 0 of Group 5 on its generateCode request track, asking for progress with a progressToken: {"jsonrpc":"2.0","id":"g1","method":"tools/call","params": {"name":"generateCode","arguments":{"language":"python"}, "_meta":{"progressToken":"g1"}}}.¶

3. code-tool publishes Group 5 of its generateCode response track as shown in the table below. It sends the progress notifications in one subgroup and the result in another, so that each is on its own QUIC stream and a large result does not delay the progress updates ([MCP-MOQT]). A receives each object as soon as it arrives, orders them by Object ID, and knows the call is complete when the result arrives.¶

4. To cancel instead, A publishes notifications/cancelled as the next object in Group 5 of its request track ([MCP-MOQT]). code-tool stops and ends Group 5 of its response track with a JSON-RPC error.¶

The table lists the objects in code-tool's reply, in Object ID order, and the subgroup that carries each.¶

A.4. Interrupting a Voice Agent

A user's client, U (agent-id user-u), talks to a voice agent, V (agent-id agent-v). V answers by voice while a tool call it made to search-tool is still running. The user cuts in, and V has to stop speaking and cancel the tool call at once.¶

U publishes:
  ("pace","dialogs",D4,"user-u") -- "ctrl"         ACCEPT
  ("pace","dialogs",D4,"user-u") -- "audio"        microphone
V publishes:
  ("pace","dialogs",D4,"agent-v") -- "ctrl"        OPEN, UPDATE,
                                                   CANCEL
  ("pace","dialogs",D4,"agent-v") -- "audio"       speech
  ("pace","dialogs",D4,"agent-v") -- "chat"        reply text
  ("pace","dialogs",D4,"agent-v","mcp","tools","search")
      -- "request"                                 tools/call
search-tool publishes:
  ("pace","dialogs",D4,"search-tool") -- "ctrl"    ACCEPT,
                                                   CANCEL_ACK
  ("pace","dialogs",D4,"search-tool","mcp","tools","search")
      -- "response"                                results

1. V opens the dialog with U (OPEN, ACCEPT, UPDATE) and adds search-tool the same way.¶

2. V answers the user. It publishes speech on its audio track as datagrams at media priority (32-63), with a short OBJECT_DELIVERY_TIMEOUT, and the reply text on chat at interactive priority (64-95). Its call to search-tool, Group 3 of the search request track, is still running.¶

3. The user starts speaking. U publishes microphone audio on its audio track, and the relay forwards each frame to V as it arrives. The dialog does not change.¶

4. V detects the user's speech and stops producing speech and text. It publishes CANCEL on its ctrl track at critical priority (0-15), with scope operation and a target naming Group 3 of its search request track (Section 4.3.6). The cancellation is sent ahead of any chat objects V has already queued, and a loss on the audio datagrams does not delay it.¶

5. Speech objects that the relay has not delivered within their delivery timeout are dropped at the relay, so the user does not hear the rest of the old answer after cutting in.¶

6. search-tool applies the CANCEL as MCP notifications/cancelled, stops, publishes no further objects in Group 3, and publishes CANCEL_ACK with outcome stopped on its ctrl track. V listens to the rest of the user's audio and answers in new groups on its audio and chat tracks.¶

The dialog, its generation, and the MOQT sessions stay the same throughout: an interruption changes the content of a dialog, not the dialog. If the dialog's flows shared one ordered connection, the cancellation in step 4 would wait behind the output V had already sent.¶

A.5. Collaborating in a Multi-Party Dialog

A coordinates research by B, a web researcher, and C, a data analyst.¶

A publishes:
  ("pace","dialogs",D5,"agent-a") -- "ctrl"        OPEN, UPDATE,
                                                   TERMINATE
  ("pace","dialogs",D5,"agent-a") -- "chat"        assignments
B publishes:
  ("pace","dialogs",D5,"agent-b") -- "ctrl"        ACCEPT
  ("pace","dialogs",D5,"agent-b") -- "chat"        status
  ("pace","dialogs",D5,"agent-b","a2a","task") -- "research-1"
                                                   findings
C publishes:
  ("pace","dialogs",D5,"agent-c") -- "ctrl"        ACCEPT
  ("pace","dialogs",D5,"agent-c") -- "chat"        status
  ("pace","dialogs",D5,"agent-c","a2a","task") -- "analysis-1"
                                                   results

Because each participant subscribes to the dialog prefix, every agent receives every other agent's tracks in D5; no per-track subscriptions are needed.¶

1. A publishes OPEN (gen 0, B and C invited). B and C each publish ACCEPT, and A commits both in one UPDATE (gen 1).¶

2. A posts assignments on chat. The relay delivers each object once to B and once to C.¶

3. B publishes findings on research-1 as they arrive, one group per research phase.¶

4. C reads B's findings as they arrive and publishes its analysis on analysis-1.¶

5. A follows both tracks, posts a summary on chat, and publishes TERMINATE (gen 2). Each agent then ends its dialog tracks with PUBLISH_DONE.¶

A.6. Group Chat with an AutoGen Runtime

An AutoGen [AutoGen] runtime, R, hosts a group chat with a human, H, and a remote agent, B. AutoGen has no binding of its own, so R uses the generic binding (Section 8.6) with "autogen" as the protocol name, and each AutoGen message carries the dialog reference in its metadata (Section 8.1).¶

R publishes:
  ("pace","dialogs",D6,"runtime-r") -- "ctrl"      OPEN, UPDATE,
                                                   TERMINATE
  ("pace","dialogs",D6,"runtime-r","ext","autogen") -- "conv1"
                                                   R's agents' turns
H publishes:
  ("pace","dialogs",D6,"user-h") -- "ctrl"         ACCEPT
  ("pace","dialogs",D6,"user-h") -- "chat"         human input
B publishes:
  ("pace","dialogs",D6,"agent-b") -- "ctrl"        ACCEPT
  ("pace","dialogs",D6,"agent-b","ext","autogen") -- "conv1"
                                                   B's turns

1. R opens D6 (gen 0, H and B invited), and commits both ACCEPTs in one UPDATE (gen 1).¶

2. R's group chat manager picks the next speaker, as AutoGen does. The speaker's message goes out once on its publisher's conv1 track, and the relay delivers it to every other participant.¶

3. When the manager asks the human, H answers on chat.¶

4. For a nested chat, R opens a child dialog D7 whose parent_dialog_ids is [D6], and posts its result back in D6.¶

5. R publishes TERMINATE (gen 2) when the chat ends.¶