What Is the PACE Protocol? The Beginner's Guide to Agent Communication Exchange (IETF Draft)

CodexFuse Team · 2026-11-05T12:35:25.124Z · 28 min read min read

What Is the PACE Protocol? The Beginner's Guide to Agent Communication Exchange (IETF Draft)

PACE is the answer to a problem every agent developer has already felt: a conversation that breaks the moment the network drops, the user switches from voice to text, or a second agent joins halfway through. The pace ietf draft, published on 1 November 2026, defines a protocol for agent communication exchange — a shared way for agents to track one conversation across all of that. If you searched for what is pace protocol, the one-sentence answer is this: PACE is an agent dialog management protocol that keeps the identifiers and lifecycle of one task's conversation coherent, without reading or defining the conversation's content.

It is an Internet-Draft, version -00, the first version under this name. That means it is work in progress, not an IETF standard, and it expires on 5 May 2027 unless a newer version replaces it.

The authors state an intent to pursue the Standards Track, but that is an aim, not an approval. The draft is four days old as of today, 5 November 2026, and no independent explainer of it exists yet.

This guide explains what a PACE dialog is, the problem it solves, how it differs from A2A and MCP, the fields and operations that run a dialog, and how its MOQT binding carries everything. Every fact comes from the draft text itself, and the draft's own limits are stated where they belong.

What Is PACE?

PACE, the Protocol for Agent Communication Exchange, is an agentic dialog management protocol with a binding to Media over QUIC Transport (MOQT). A dialog is the correlated sequence of interactions between two or more participants over the course of a task. PACE defines a transport-independent dialog context and the control operations that establish, modify, and terminate dialogs.

It specifies how that context stays coherent across intermediaries, trust boundaries, modality changes, and interruptions, and how it is carried over MOQT. PACE does not interpret or define dialog content.

The full name behind the acronym is the Protocol for Agent Communication Exchange, and the pace protocol agent communication exchange draft is the document this guide explains. Its authors are Suhas Nandakumar and Cullen Jennings, both of Cisco.

The draft runs to 62 pages, with 13 numbered sections, 15 numbered tables, and an appendix of six example workflows. It sits in the IETF's Agent Communication Protocols working group, known as agentproto, and it realizes the Agentic Dialog Management block of that group's architecture draft, published on 30 October 2026.

PACE has two parts. The first is a transport-independent dialog management protocol: the dialog context, the control operations that manage its lifecycle, and the rules participants and intermediaries follow when propagating it. The second is a binding of that protocol to MOQT, which carries the dialog context on MOQT tracks and uses MOQT relays for fan-out, prioritization, and multiplexing of dialog control alongside text, audio, video, and request/response exchanges.

How a PACE dialog opens, in 7 steps:

1. The controller generates a dialog-id, a UUID version 4, and subscribes to the dialog prefix.
2. The controller publishes its control track and sends OPEN at generation 0, naming the invitees.
3. The controller sends an invitation on its invitation track for each invitee.
4. The invitee subscribes to the controller's control track, reads OPEN, and decides. Until it accepts, it subscribes to nothing else and receives no dialog content.
5. The invitee publishes its own control track and sends ACCEPT, or REJECT, then subscribes to the dialog prefix.
6. The relay forwards the ACCEPT to the controller.
7. The controller sends UPDATE at generation 1, marking the invitee and the dialog active.

Two housekeeping notes before you go further. If you download draft text or tools while following along, the SHA-256 hash generator checks a file's fingerprint in seconds, which is a good habit before you trust a download. The protocols in this guide run on ordinary always-on servers, and VPS hosting is the usual home for that kind of infrastructure.

What Is a "Dialog" in PACE?

A dialog is the whole conversation-plus-work that belongs to one job: every message, voice turn, tool call, and file shared while that job is running, kept together as one thing. It outlasts any single message exchange, MOQT session, or transport connection.

A two-party dialog is called an agentic dialog. Larger topologies are built by cascading two-party dialogs or by multi-party dialogs, and the draft names four topologies in total: point-to-point, point-to-multipoint, multi-party, and hierarchical teams.

A dialog is not the same as a chat session. A chat session is usually one connection to one model, and it ends when that connection ends.

A dialog survives the connection ending, the user switching from voice to text, and new agents joining halfway through. The dialog-id stays the same through all of it, which is what lets every participant agree they are still talking about the same task.

Dialogs also have a beginning before PACE takes over. A session-initiation protocol establishes the dialog, and PACE manages it from there.

That is the job of A-SIP, and what A-SIP is explains the establishment half of the story. PACE picks up once the dialog exists and keeps it coherent until it ends.

The dialog context is metadata, not content. It does not include conversation memory, retrieved documents, prompts, or media payloads.

Content is opaque to PACE, and the MOQT binding carries it on content tracks without interpreting it. That separation is deliberate: PACE correlates the conversation without ever needing to read it.

Some things are negotiated around a dialog but are not part of its context. The draft lists six dialog parameters: dialog type, meaning short-lived or long-lived; idle timeout; maximum participants; supported modalities; supported protocols; and content encoding, such as gzip. These are agreed between participants, while the context itself stays small and strictly defined.

The Problem PACE Solves: Why Agent Conversations Break Today

Agent interactions are increasingly live dialogs, not 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.

Today, each of those facts breaks the conversation in a different way. An interruption has to take effect ahead of output already queued, and over one ordered connection a cancellation waits behind the output already sent. A relay or gateway in the middle can lose track of which conversation a message belongs to.

A message crossing into another trust domain can arrive without the authorization that should govern it. A switch from voice to text can look like a brand-new conversation. And a dropped connection can leave every participant unsure whether the conversation still exists.

PACE exists so participants have a common way to correlate a dialog and maintain its lifecycle across multiple hops, intermediaries, trust boundaries, and changes of modality or network attachment, without sharing the content of the dialog itself. The draft lists ten goals for the protocol: dialog correlation, multi-modal exchange, multi-party exchange, low-latency interaction, dialog lifecycle, resilience, transport independence, application protocol reuse, identity and authorization reuse, and privacy.

The interruption case shows why the design looks the way it does. In natural spoken conversation, people take turns within a few hundred milliseconds, a figure the draft cites from Stivers and colleagues in a 2009 paper in the Proceedings of the National Academy of Sciences. A "stop" that arrives a second late is not a stop at all.

PACE gives control messages their own track and the top priority tier, so a CANCEL overtakes content already queued. That single design choice, a separate fast lane for control, is the heart of the protocol.

After a connection loss, recovery follows a fixed pattern. The participant reconnects, over a new transport session if needed, using the existing dialog-id. It then fetches the current context with a STATE_REQUEST before acting.

Relay caches let a reconnecting agent pick up content it missed, and a join fetch gives a new participant the prior content and then the live stream, atomically. One dialog can span several MOQT sessions, and one MOQT session can carry several dialogs.

PACE vs. A2A vs. MCP: What Each Protocol Actually Does

The most common misunderstanding about PACE is that it competes with the agent protocols you already know. It does not.

PACE manages dialogs, while A2A, MCP, AutoGen, and Poppy keep their own message formats and ride inside dialogs as bindings. PACE does not replace application-layer agent protocols, and any standardized mapping is coordinated with their maintainers.

A2A is Google's agent-to-agent protocol: agents discover each other through Agent Cards and exchange tasks and messages. MCP is Anthropic's Model Context Protocol, the agent-to-tools protocol: the standard way LLM applications call tools, read resources, and use prompts. AutoGen is Microsoft's multi-agent framework.

Each of them already has a way to say what it is doing. None of them has a shared way to say which conversation it is doing it in, across a relay, a modality change, and a dropped connection. That is the gap PACE fills.

Each protocol carries the dialog reference through its own extension point, under the metadata key org.ietf.agentproto/dialog-context. MCP carries it in _meta, A2A and AutoGen in message metadata, and Poppy in its track namespace.

The value is small: a dialog-id and the latest generation the sender knows. The controller's control track stays authoritative, so the extension-point copy is a hint, never the source of truth.

Several bindings can coexist in one dialog. One agent can speak A2A to a peer and MCP to a tool in the same dialog, because each uses its own protocol field after the agent-id in the namespace. That is the practical payoff of the layering: the dialog is one thing, and the protocols inside it stay separate.

The Dialog Context: The Fields That Hold a Conversation Together

Pace dialog management is, at its core, the care of one small context object. The dialog context has seven fields, and six of them are always present. Everything else about the conversation lives outside it, in the application protocols and the content tracks.

A context snapshot must contain every member except the optional ones, including participants in left, rejected, and revoked states. The controller never removes a participant; it changes their state. That rule keeps the history of who was involved intact, which matters for auditing and for debugging a dialog that went wrong.

Identifiers are correlation values only. They must not be treated as credentials, and a participant identifier must not encode personal or task information. The draft is explicit on both points, because an identifier that leaks task details would turn the context itself into a privacy problem.

The generation number does quiet, essential work. It is a non-negative integer with a maximum of 2^53 - 1, which is about 9 quadrillion, so no real dialog will ever exhaust it. A receiver must reject a controller operation with a lower generation than the latest it accepted.

On seeing a skipped generation, it must send STATE_REQUEST and must not infer the missing changes. That rule is what keeps every participant's copy of the context identical, even when messages arrive out of order.

The Dialog Lifecycle: Pending, Active, Terminated

A dialog has three states and no more. It starts pending, when the controller has opened it but no invitee has accepted. It becomes active when at least one invitee accepts.

It ends terminated, which is final. Only the controller causes transitions between these states.

Three operations advance the generation by one each time they are committed: UPDATE, which replaces the participant set or the expiration; REVOKE, which revokes a participant's propagation relationship; and TERMINATE, which ends the dialog. Interruptions and cancellations do not change the state at all. A dialog that is interrupted is still active, and a cancellation stops work without ending the conversation.

Suspension needs no operation. A dialog persists through idle periods with no transport connection at all, which is what makes long-lived dialogs possible: a task that runs for hours or days does not need a connection held open the whole time.

Expiry has the same effect as TERMINATE, except that it creates no new generation. And resuming a transport connection does not reopen a terminated or expired dialog; once it is over, it is over.

The participant states tell the rest of the story. A participant is invited when named in OPEN, active when they have accepted, left when they leave, rejected when they decline, and revoked when the controller removes their propagation relationship. Five states, one per participant, all visible in the shared context.

The 13 Control Operations That Run a Dialog

Thirteen control operations run a dialog, and the draft lists them in a single table. Only the controller changes the context.

Other participants send requests, and the controller commits the result with an UPDATE carrying the complete context at the next generation. The controller must serialize state-changing operations and must not reuse a generation.

A control message is a UTF-8 JSON object at version 1. Every message carries a version, a type, a dialog-id, a generation, a sender-id, and a message-id, which is a UUID version 4. Type-specific members add the context, the message being replied to, the target, the scope, the outcome, the last accepted generation, or the reason.

Optional members carry parameters, credentials such as an identity assertion or authorization proof, and a nonce: a fresh random value with at least 128 bits of entropy, base64url-encoded. A participant must not include application content in a control message.

When something goes wrong, the ERROR operation says why, with one of seven reasons: malformed, unsupported-version, unsupported-operation, stale-generation, unauthorized, authorization-unavailable, or policy-rejected. The list is short on purpose. It covers bad messages, old versions, unknown operations, out-of-date context, and authorization problems, and nothing else.

Interruptions and Cancellation: Stopping an Agent Mid-Sentence

CANCEL is the operation that makes PACE feel like a real conversation. It does not change the dialog context, and it does not end the dialog. It asks receivers to stop work the sender started, and it is idempotent, so sending it twice has the same effect as sending it once.

Its scope selects the work to stop. A scope of operation stops one operation the sender started, named in the target field. A scope of subtree stops all work in delegated dialogs whose parent dialog list includes this dialog, so cancellation propagates down the delegation chain.

A scope of dialog stops all work the sender started in this dialog plus its subtree. The receiver applies CANCEL through the application protocol's own cancellation where one exists, such as MCP's notifications/cancelled or A2A's CancelTask.

The acknowledgement carries one of three outcomes: stopped, completed, or irreversible. Irreversible is the honest one.

Some work cannot be undone, and the draft does not pretend otherwise. It reports the outcome instead of hiding it.

The draft's own worked example shows why cancellation matters for long-running work. In one appendix workflow, a code-generation tool call reports progress from 0 to 3 and returns 142 lines of generated code.

That is the kind of slow, expensive job a user interrupts halfway through, and the kind where a late cancellation wastes real money. PACE puts CANCEL on the control track at the top priority tier precisely so it overtakes the output already queued.

How PACE Rides on MOQT: Relays, Tracks, and Fan-Out

The pace moqt binding is the second half of the draft, and it is where the abstract ideas become concrete wires. MOQT, Media over QUIC Transport, is a publish/subscribe protocol over QUIC, defined in its own draft dated October 2026. PACE uses it because it supplies what dialog management needs: low latency, push delivery, interruption, concurrent flows, fan-out, continuity, and scale.

Objects are sent as produced, and per-track streams mean one flow's loss does not stall the others. Datagrams are not retransmitted, which is right for real-time audio and video. Publisher and subscriber priorities let control overtake queued data, and delivery timeouts drop stale media at the relay.

QUIC connection migration and 0-RTT resumption keep a dialog alive across network changes. Hierarchical relays, namespace-level access control, and TLS 1.3 per hop supply the scale and the security. Where UDP is blocked, the same binding can run over QMux, which is QUIC over TLS over TCP.

PACE uses two namespace scopes. The agent namespace, ("pace", "agents", {agent-id}), is the agent's persistent identity. It carries a card track with the Agent Card, meaning capabilities, identity claims, auth schemes, and MOQT connectivity, plus one invitation track per invited agent.

The dialog namespace, ("pace", "dialogs", {dialog-id}, {agent-id}), carries all of a dialog's traffic. Each participant publishes under its own agent-id and subscribes to the dialog prefix, so it receives every participant's tracks, including participants added later.

Each participant publishes six kinds of track: ctrl for dialog control messages, which is the only track carrying dialog context; chat for chat and streaming LLM output; audio; video; progress for token counts, elapsed time, and liveness; and ops/{req-id}, one track per request/response operation. Protocol bindings add their own fields after the agent-id, with the protocol name and category.

Relays do the fan-out. A single PUBLISH reaches every subscriber through the relay, and the publisher keeps no per-subscriber state and writes no application-level broadcast code.

Relay caches let late joiners and reconnecting agents catch up without the publisher retransmitting. One MOQT session carries sub-100 millisecond media, sub-second chat, and best-effort bulk transfers at the same time, each with its own priority and reliability.

Priority is the mechanism that makes all of this work, and the draft defines eight tiers across the MOQT 0 to 255 scale. A subscriber must subscribe to a control track with a subscriber priority in the Dialog Control tier. Subscriber priority is applied before publisher priority, so a publisher cannot raise its own urgency beyond what subscribers allow.

The tiers are not evenly sized, and the sizes tell you the priorities. Dialog Control and Urgent Signals get 16 values each, the four middle tiers get 32 each, and Bulk Transfer gets 64.

The top of the scale is narrow because control traffic is small and urgent; the bottom is wide because bulk traffic is large and patient. Modalities fall into three classes on top of this: real-time under 100 milliseconds for voice, video, and screen share; semi-real-time under 1 second for chat and streaming LLM output; and best-effort for tool calls, file transfers, and documents.

Discovery and setup follow a fixed bootstrap. Agents establish native QUIC with the moqt application protocol name, or a WebTransport session, then announce their agent namespace, publish an Agent Card, and discover peers by subscribing to the agents namespace. One PACE setup option is defined, pace-version, with the identifier 0x50414301, carrying the highest PACE control-message version supported.

Following an agent means subscribing to its card and to the invitation track named by the follower's own agent-id. Invitations carry only a dialog-id, a controller-id, and an optional expiry, and relay authorization forwards each invitation track only to the invitee it names.

To see how the transport and the dialog layer fit together, what MCP over MOQT is explains the other half of the pairing: how MCP messages map onto MOQT objects and tracks, and how the same tracks run standalone or inside a PACE dialog.

How MCP Fits Inside a PACE Dialog

MCP is the protocol most likely to ride inside a PACE dialog first, and the mapping is mechanical. The leading fields of an MCP-over-MOQT namespace are replaced by the PACE dialog namespace.

A client-scope namespace of (mcp, {server-id}, clients, {client-id}) becomes ("pace", "dialogs", {did}, {agent-id}, "mcp"), and the remaining fields and track name stay unchanged. A tool request becomes ("pace", "dialogs", D, {client}, "mcp", "tools", {tool-name}) with a request track, and the tool response uses the server's agent-id with a response track.

MCP messages keep their native JSON-RPC 2.0 format as the object payload, and they carry the dialog reference in _meta. MCP needs no handshake of its own inside PACE, and MCP-over-MOQT client IDs are not used inside a dialog: PACE supplies the dialog-id, and peers learn each other's MCP tracks through subscribing to the dialog prefix. A PACE CANCEL with operation scope naming an MCP request track and group has the same effect as an MCP notifications/cancelled message in that group.

There are two deployment modes, and the MCP-over-MOQT draft states the choice plainly. Standalone mode suits a client that talks directly to one or more MCP servers. PACE mode suits MCP tool access that is one part of a larger, multi-agent dialog.

Both modes use the same tracks and the same message handling; only the namespaces change. PACE takes over the dialog reference, cancellation, identity and authorization, and priorities, while MCP keeps doing what it does.

The same pattern applies to the other protocols. A2A rides inside a dialog with its operations, such as SendMessage, SendStreamingMessage, GetTask, SubscribeToTask, and CancelTask, carried in its own binding. AutoGen has no binding of its own and uses the generic binding, with "autogen" as the protocol name.

Poppy, the Personal Agent Protocol, carries its dialog reference in its track namespace. The rule for all of them is the same: keep your native messages, carry the dialog reference through your own extension point, and let the controller's control track stay authoritative.

Identity, Delegation, and Trust Boundaries

PACE separates agent identity from user identity, so an agent can be revoked without affecting the user, scoped to a subset of the user's permissions, and audited separately. That separation is what makes delegation safe to reason about. The identity of the principal travels in the credentials member of a control message, not in the dialog context, and the context itself carries only identifiers.

Delegation chains follow one rule: each hop must narrow or preserve scope. If an agent holds scope S, it can grant a sub-scope S' that sits inside S, and no agent down the chain may hold more than its delegator granted.

The chains travel in the credentials member, for example as nested act claims under RFC 8693, the OAuth 2.0 token exchange standard. A typical chain runs User, then Coordinator, then Researcher, then Tool, with each step holding a smaller slice of the original authority.

The draft lists eight credential mechanisms a deployment can choose from: JWT, SD-JWT, SD-Card, OAuth 2.0 access token, GNAP, WIMSE workload credentials, mTLS client certificate, and Common Access Token. PACE defines no new token format, and it does not define an Agent Card format either. A deployment profile must pick at least one mechanism for identity and one for authorization, and the draft leaves that choice to the deployment.

Trust boundaries are governed by propagation relationships. A participant forwards context into another trust domain only within a propagation relationship the deployment's authorization mechanism permits.

Authorization to forward or subscribe at the transport layer does not by itself make an entity a participant. An intermediary must preserve the dialog-id, the generation, and the lifecycle operation, and must not create a new dialog-id or change the dialog state.

The participants in a real dialog are often coding agents themselves, working on the same task a developer started. If you run one, how to use Claude Code covers the practical side of driving it, while PACE covers how several such agents would keep one shared conversation coherent.

What PACE Does Not Do (and What's Still Missing)

PACE does not define trust frameworks, authorization protocols, or audit data structures. Deployments use existing mechanisms, and auditing systems can use dialog identifiers.

It does not define or interpret dialog content, and content, model behavior, planning, and task semantics are all out of scope. It does not define a new identity token format or claim set, and it does not define an identifier-alias mechanism, so intermediaries must not invent one.

Two gaps are stated openly in the draft. There is no defined way to invite an agent that neither follows the controller nor can be reached out of band, and no way to advertise a dialog for others to join; both are explicitly left for future work. The Security Considerations section is largely a stub that reads "TODO: further considerations", with one firm rule: state-changing or cancelling control messages, including OPEN, ACCEPT, UPDATE, JOIN_REQUEST, LEAVE, REVOKE, TERMINATE, and CANCEL, must not be sent in QUIC or TLS 1.3 0-RTT data, because 0-RTT data can be replayed.

One more thing to know before you cite PACE: the name is older than the current draft, and the current draft is a re-scope, not a revision. The June 2026 draft defined PACE as a session protocol over MOQT only.

The 1 November 2026 draft redefines it as a transport-independent dialog management protocol plus a MOQT binding. Quote the November draft for anything normative, and treat the June draft as history.

The gap between the two drafts is 126 days, from 28 June to 1 November 2026. The November draft then has a 185-day life, from 1 November 2026 to its expiry on 5 May 2027, which leaves 181 days from today. The related MCP-over-MOQT draft was published the same day, 1 November 2026, also expires on 5 May 2027, and carries the intended status Experimental rather than Standards Track.

The neighbouring architecture draft is dated 30 October 2026, and the ACP wire-format draft followed on 2 November 2026. The whole agentproto family is moving in the same weeks, and PACE is the dialog-management piece of it.

Sources

PACE, the current draft and main source: Suhas Nandakumar and Cullen Jennings, "PACE: Protocol for Agent Communication Exchange", draft-nandakumar-agentproto-pace-00, 1 November 2026, intended Standards Track, expires 5 May 2027. Fetched 5 November 2026 from the IETF datatracker at https://datatracker.ietf.org/doc/html/draft-nandakumar-agentproto-pace-00 and the plain-text version at https://www.ietf.org/archive/id/draft-nandakumar-agentproto-pace-00.txt.

PACE over MOQT, the predecessor draft: Suhas Nandakumar and Cullen Jennings, "PACE: Protocol for Agent Communication Exchange", draft-nandakumar-agentproto-moq-pace-00, 28 June 2026, intended Standards Track, expires 30 December 2026. Fetched 5 November 2026 from https://datatracker.ietf.org/doc/html/draft-nandakumar-agentproto-moq-pace-00.

MCP over MOQT, Section 8 and abstract only: Cullen Jennings, Ian Swett, Jonathan Rosenberg, and Suhas Nandakumar, "Model Context Protocol and Agent Skills over Media over QUIC Transport", draft-jennings-agentproto-mcp-over-moqt-01, 1 November 2026, intended Experimental, expires 5 May 2027. Fetched 5 November 2026 from https://datatracker.ietf.org/doc/html/draft-jennings-agentproto-mcp-over-moqt-01.

Architecture for AI Agent Communications on the Internet, draft-manyfolks-agentproto-arch-00, 30 October 2026, cited inside the PACE draft as the architecture whose Agentic Dialog Management block PACE realizes. Listed on the agentproto working group documents page at https://datatracker.ietf.org/wg/agentproto/documents/; not fetched in full for this article.

The Agent Communication Protocol (ACP), draft-liu-agentproto-acp-00, 2 November 2026, the neighbouring wire-format draft in the same working group. Listed on the agentproto working group documents page; not fetched in full for this article.

Media over QUIC Transport, draft-ietf-moq-transport-22, October 2026, cited inside the PACE draft as the transport its MOQT binding uses. Referenced through the PACE draft text; not fetched in full for this article.

Stivers and colleagues, 2009, Proceedings of the National Academy of Sciences, on turn-taking timing in natural conversation, cited inside the PACE draft for the few-hundred-milliseconds figure. Referenced through the PACE draft text; not fetched in full for this article.

RFC 8693, OAuth 2.0 Token Exchange, cited inside the PACE draft for nested act claims in delegation chains. Referenced through the PACE draft text; not fetched in full for this article.

The PACE draft source repository, https://github.com/suhasHere/draft-nandakumar-agentproto-pace, linked from the draft itself. The latest HTML rendering is published at https://suhasHere.github.io/draft-nandakumar-agentproto-pace/draft-nandakumar-agentproto-pace.html.

Frequently Asked Questions

Is PACE an official IETF standard yet?

No. PACE is an Internet-Draft, version -00, published on 1 November 2026, and the draft itself says Internet-Drafts are work in progress.

The header states an intent to pursue the Standards Track, but the IETF has not adopted or approved it. It expires on 5 May 2027 unless a newer version replaces it.

Does PACE replace MCP or A2A?

No. PACE manages dialogs, while MCP, A2A, AutoGen, and Poppy keep their own message formats and ride inside dialogs as bindings.

MCP still speaks JSON-RPC 2.0 to tools, and A2A still exchanges tasks between agents. PACE gives them a shared dialog to run inside; it does not take over their jobs.

What is the difference between a PACE dialog and a chat session?

A chat session is usually one connection to one model, and it ends when that connection ends. A PACE dialog is the correlated sequence of interactions between two or more participants over the course of a task, and it outlasts any single connection, MOQT session, or modality change. The dialog-id stays the same through a dropped connection, a switch from voice to text, and new agents joining halfway through.

Do I need MOQT to use PACE?

No. The dialog management protocol is transport-independent, and the MOQT binding is one way to carry it.

The draft defines the dialog context and the control operations without reference to any transport, then adds the MOQT binding as a separate part. Another transport could carry the same dialog context, though MOQT is the only binding the draft defines.

What happens to a PACE dialog when the connection drops?

Nothing happens to the dialog itself. An interruption does not change the dialog state, and the dialog persists with no transport connection at all. The participant reconnects using the existing dialog-id, fetches the current context with a STATE_REQUEST, and resumes.

Relay caches let it pick up content it missed. If the controller is unreachable, participants must suspend context-dependent actions and must not create a replacement dialog.