| Internet-Draft | Contact Center Agent Use Cases | October 2026 |
| Howe | Expires 28 April 2027 | [Page] |
Contact centers bring people, AI agents, and business systems into the same voice session. Consumer-controlled agents are also beginning to call agents operated by businesses. This document describes five contact center use cases for the agentic dialog management protocol: a consumer agent calling a business agent, escalation from an AI agent to a human representative, a call that resumes on another channel, a voice dialog passing through speech recognition and synthesis, and a dialog crossing an existing SIP or PSTN network. It derives numbered requirements that can be incorporated into the working group's use cases and requirements document. It also explains how a dialog identifier relates to the conversation records that contact centers already keep.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-howe-agentproto-contact-center-usecases/.¶
Discussion of this document takes place on the agentproto Working Group mailing list (mailto:agentproto@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/agentproto/. Subscribe at https://www.ietf.org/mailman/listinfo/agentproto/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The agentproto charter names voice as one modality, calls out interactive voice as needing very low latency, and requires dialog context to stay coherent across intermediaries and trust boundaries. Contact centers put all three into one call. A single customer conversation can pass through a carrier, a session border controller, a speech recognizer, an AI agent, a queue, and a human representative in a different company, and can drop and resume on a different device the next day.¶
The use cases in [I-D.agentic-ai-usecases-requirements] describe interaction patterns but do not include a contact center voice scenario. [I-D.rosenberg-agentproto-usecases] describes contact center transfer topologies (blind, supervised, sidebar, conference and passthrough) and notes that the user to agent leg often runs over a phone call. This document addresses both, and does not repeat the common requirements of [I-D.agentic-ai-usecases-requirements] (CMN-1 to CMN-12), which should apply here unchanged.¶
Each requirement carries a CC prefix and one or more protocol-area tags defined in [I-D.agentic-ai-usecases-requirements]: Dialog, Transport, Security, and Authentication. The table identifies each requirement being extended.¶
This document follows the charter's line between dialog context and task context. Dialog context includes the identifiers and lifecycle state needed to correlate and maintain a dialog. Transcripts, recordings, customer records and agent memory are task context and are not carried by the protocol. Several requirements in this document let a participant use the dialog identifier to find its own task context or records, described in Section 2.1 of [I-D.agentic-ai-usecases-requirements].¶
This document uses the terms Dialog, Dialog Context, Task Context, Participant, Modality and Delegation as defined in [I-D.agentic-ai-usecases-requirements]. In addition:¶
The business that operates a contact center and the agents and representatives that answer for it.¶
A person who contacts a brand, or on whose behalf a consumer agent contacts a brand.¶
A brand agent that identifies and routes inbound communications. The name echoes the admission-control and address-translation role of an H.323 gatekeeper [H323].¶
An AI agent acting for a consumer, outside the brand's administrative domain.¶
An AI agent operated by or for the brand that handles contacts.¶
A person who handles contacts for a brand. Contact centers traditionally call these people "agents". This document avoids that usage to keep "agent" for AI agents.¶
The system that routes, queues, records and reports on contacts for a brand, and that presents contacts to human representatives.¶
A participant that receives media and dialog context in order to keep a record of the dialog and does not take part in it, such as a SIPREC Session Recording Server [RFC7866].¶
An intermediary that converts content from one modality to another, such as speech recognition (audio to text), speech synthesis (text to audio) or live translation.¶
As an unfortunate consequence of a limited operational vocabulary, three uses of "dialog" overlap in a contact center:¶
An agentic dialog, in the sense of the agentproto charter, is the correlated sequence of interactions over the course of a task.¶
A SIP dialog [RFC3261] is a peer-to-peer signaling relationship between two user agents. A transfer, a callback or a reconnection each creates a new SIP dialog. A single agentic dialog can span several SIP dialogs, and in a conference several SIP dialogs exist at the same time.¶
The dialog array in a vCon [I-D.ietf-vcon-vcon-core] holds the media segments of a recorded conversation (recordings, text messages, transfers). A record of one agentic dialog can hold many vCon dialog objects.¶
In this document "dialog" alone means an agentic dialog.¶
A consumer asks their own agent to cancel a car rental, dispute a charge or rebook a flight. The consumer agent connects to the brand's published contact point by placing a call over the PSTN or opening a real-time Internet channel such as chat or WebSocket. The brand answers with its own brand agent. Neither agent has a prior relationship with the other. The consumer agent knows only a contact address, such as a phone number or URL. The brand agent knows only what arrives with the contact.¶
The agents may begin in synthesized speech because the brand publishes a phone number built for people. After they identify each other as agents, they may move to structured messages while keeping audio open for a human participant. The consumer may also join the call and speak for themselves.¶
If the consumer later disputes the outcome, the brand's record shows what its agent did and the consumer agent's record shows its instructions. Comparing those records depends on both sides recording the same dialog identifier.¶
Consumer domain Brand domain ..................... ............................. . . . . . +----------+ . dialog . +---------+ +--------+ . . | Consumer | . context . | Brand |--| Tools | . . | Agent |<----.--------------.->| Agent | +--------+ . . +----+-----+ . voice, then . +---------+ . . | . structured . . . +----+-----+ . messages . . . | Consumer | . . . . +----------+ . . . ..................... .............................¶
| REQ-ID | Description | Tag |
|---|---|---|
| CC1-1 | The protocol is required to support establishing a dialog between participants in different administrative domains that share no prior relationship, where the initiator holds only a contact address such as a telephone number or URL. | Dialog, Authentication |
| CC1-2 | Each participant is required to be able to present an agent identity distinct from the telephone number it calls from and from the identity of the user on whose behalf it acts. | Authentication |
| CC1-3 | The protocol is required to allow each participant to learn whether the peer participant is an AI agent or a human. | Dialog, Authentication |
| CC1-4 | The protocol is required to support changing the active modalities of an established dialog, including moving from audio to structured messages while audio stays available, without establishing a new dialog. Extends A1-5 and CMN-11. | Dialog, Transport |
| CC1-5 | The protocol is required to support signaling that a human user has joined a dialog or taken over from the agent acting for them, without terminating the dialog. | Dialog |
| CC1-6 | Each authorized participant in a dialog is required to receive the same dialog identifier, so that records kept independently in each domain can later be associated with the same dialog. | Dialog |
| CC1-7 | A consumer agent is required to be able to present the scope of authority the consumer granted it, and the brand agent is required to be able to verify that scope before taking an action with effect, such as a cancellation or refund. See B2-6 and B3-1 to B3-4. | Security, Authentication |
For economic and performance reasons, a brand may use a doorman to identify and route inbound communications to the appropriate resource. The doorman handles a call until it reaches something it is not permitted or able to do: a policy exception, a complaint, a vulnerable customer, or a consumer who asks for a person. The brand agent hands the dialog to a human representative using one of the topologies in [I-D.rosenberg-agentproto-usecases], most often a supervised transfer, in which the brand agent introduces the call and then drops.¶
The dialog may sit in a queue for minutes or longer, with only hold audio flowing, before a representative is available. The representative may work for the brand, or for an outsourcer in a different administrative domain and a different country. The representative works in a contact center application, not an agent runtime, and needs to see the history of the call on arrival so the customer does not repeat themselves.¶
If no representative is available, or the target rejects the transfer, the dialog returns to the brand agent rather than dropping.¶
Brand domain Outsourcer domain
................... .......................
. . . .
+----------+ . +-----------+ . . +---------------+ .
| Consumer |--.--| Brand |--.-------.->| Human | .
| | . | Agent | . same . | Representative| .
+----------+ . +-----+-----+ . dialog. +-------+-------+ .
. | . ID . | .
. +-----+-----+ . . +-------+-------+ .
. | Queue | . . | Contact Center| .
. +-----------+ . . | Application | .
................... . +---------------+ .
.......................
¶
| REQ-ID | Description | Tag |
|---|---|---|
| CC2-1 | The protocol is required to support replacing a participant, including replacing an AI agent with a human representative, as a modification of an existing dialog that keeps its dialog identifier. This applies to blind, supervised and conference transfer. Extends CMN-11. | Dialog |
| CC2-2 | The protocol is required to allow dialog context to be delivered to a participant that is a human working through an application, not an AI agent. | Dialog |
| CC2-3 | When a dialog crosses into another administrative domain, the receiving domain is required to receive the dialog context without receiving the sending domain's task context. The receiving participant is required to be able to use the dialog identifier to request task context through a separate, authorized exchange. | Dialog, Security |
| CC2-4 | When a participant leaves a dialog, the protocol is required to end that participant's authority to act in the dialog while the dialog continues. | Security |
| CC2-5 | The protocol is required to support a lifecycle state in which a dialog is waiting, such as queued or on hold, for a potentially long period with no participant actively exchanging content, subject to the dialog lifetime and local policy. | Dialog |
| CC2-6 | When a transfer fails and the transferring participant remains available, the protocol is required to return control of the dialog to that participant with the dialog intact. The protocol is required to signal the reason, distinguishing at minimum rejection by the target from no target available. | Dialog |
Many inbound calls originate on mobile phones, where coverage changes as the caller moves. A consumer may be on a call with a brand agent that has started an operation with effect, such as a payment or an order change, when the call drops. The consumer calls back from a different phone or moves to the brand's chat or messaging channel. The consumer does not hold the dialog identifier and cannot be asked for it. The brand authenticates the consumer and uses local policy to match the new contact to an interrupted, unterminated dialog. The protocol then resumes the selected dialog.¶
Alternatively, after a disconnection, the brand agent calls the consumer back at the number the consumer gave, or sends a message, carrying the original dialog identifier through the brand's outbound dialing system.¶
On resumption, the brand agent may not know whether the payment went through. As [I-D.agentic-ai-usecases-requirements] Section 4.2 notes, resuming the dialog does not settle an operation that was in flight. The application checks the operation before retrying it.¶
t0 Consumer ==voice==> Brand Agent (dialog D established)
t1 Consumer ==voice=X Brand Agent (media lost; D interrupted,
payment operation in flight)
t2 Consumer ==chat===> Brand Agent (new channel; consumer
authenticated; re-associated
with D)
t3 Brand Agent -> Payment tool
(outcome of operation queried
by dialog D and operation ID)
¶
| REQ-ID | Description | Tag |
|---|---|---|
| CC3-1 | The protocol is required to support resuming a dialog through a different channel, device or network attachment from the one on which it was interrupted. Extends B1-6. | Dialog |
| CC3-2 | After a serving participant has authenticated a returning user and used local policy to select an interrupted dialog, the protocol is required to support resumption when the user does not hold the dialog identifier. The checks in B1-7 are required before the dialog resumes. | Dialog, Security |
| CC3-3 | The protocol is required to support resumption initiated by the serving participant toward the user, such as a callback, carrying the original dialog identifier. | Dialog |
| CC3-4 | The protocol is required to distinguish an interrupted dialog from a terminated one, and to signal a distinct reason when resumption is refused because the dialog's lifetime has expired. Extends CMN-11. | Dialog |
| CC3-5 | The protocol is required to allow an application protocol to associate an operation-status request and response with a dialog identifier and an operation identifier. The application response needs to distinguish completed, not completed, and unknown. The agentic dialog management protocol does not define operation semantics. | Dialog |
It is common, and in some cases required, for contact center calls to be transcribed. A consumer speaks on a phone call, and a speech recognizer turns the audio into text. The brand agent reads the text and writes a reply. A text-to-speech synthesizer turns the reply into audio. Each function may be a separate service run by a different provider. Other services may also participate:¶
A live translator may sit between the consumer and the agent.¶
A supervisor may watch a live transcript and step in.¶
A recorder may keep the audio and the transcript for quality review and regulatory retention.¶
A quality-scoring service may read the transcript in real time.¶
The consumer interrupts the agent mid-sentence. The synthesizer stops, the agent abandons the rest of its reply, and the recognizer starts on the new utterance. This is a real-time requirement because it has to happen quickly enough to preserve an interactive conversation. [G114] provides guidance for one-way transmission delay. It does not set an end-to-end budget for speech recognition, agent processing, and speech synthesis, but it shows why each added processing stage has to control its delay.¶
[I-D.agentic-ai-usecases-requirements] requirement A1-10 already requires dialog context to survive a change of modality. This use case adds a chain of transformers, passive participants, and the need to tie an output to the input it came from.¶
+----------+ audio +-----+ text +-------+ text +-----+ audio
| Consumer |------>| ASR |----->| Brand |----->| TTS |------> Consumer
+----------+ +-----+ | Agent | +-----+
+---+---+
| dialog context and
+---------------+---------------+
| | |
+-----+-----+ +-----+----+ +------+-----+
| Supervisor| | Recorder | | Quality |
| (human) | | | | scoring |
+-----------+ +----------+ +------------+
¶
| REQ-ID | Description | Tag |
|---|---|---|
| CC4-1 | Each transformer is required to preserve the dialog identifier and the integrity of the dialog context it receives while carrying authorized context changes to its output. Each transformer is required to be identifiable as an intermediary in the dialog. Extends A1-10. | Dialog |
| CC4-2 | The protocol is required to support identifiers for individual exchanges within a dialog, such as a single utterance or turn, so that a transformer's output can be associated with the input it was derived from. | Dialog |
| CC4-3 | The protocol is required to support a participant signaling that an exchange in progress is abandoned, such as when a user interrupts synthesized speech, with bounded latency suitable for interactive voice. | Transport, Dialog |
| CC4-4 | The protocol is required to support receive-only participants, such as a recorder, a monitoring supervisor, or an analytics service. These participants receive authorized dialog context and lifecycle events but are not authorized to modify the dialog. | Dialog, Security |
| CC4-5 | The protocol is required to support a receive-only participant becoming an active one, such as a supervisor who barges in, as a modification of the dialog that is authorized under CMN-12. | Dialog, Security |
| CC4-6 | The protocol is required to carry dialog context and lifecycle changes reliably while allowing real-time media in the same dialog to be carried without reliability, consistent with Section 3.1 of [I-D.agentic-ai-usecases-requirements]. | Transport |
SIP trunks carry contact center voice traffic between carriers, and some of it starts on the PSTN. A consumer agent that places a phone call hands its audio to a carrier. Between the two agents sit session border controllers, back-to-back user agents, carrier interconnects, and sometimes a TDM segment. These systems do not necessarily understand agentic dialogs, and deployed back-to-back user agents may remove header fields they do not recognize. Inside the brand, the contact center platform transfers calls with REFER [RFC3515] [RFC5589], each transfer creating a new SIP dialog, and forks media to a recorder using SIPREC [RFC7866].¶
SIP has addressed a related correlation problem. The Session-ID header field [RFC7989] identifies a communication session across SIP intermediaries, including back-to-back user agents. The User-to-User header field [RFC7433] carries application data between endpoints across intermediaries. Neither field carries agentic dialog context, but both provide useful design and deployment experience.¶
Number attestation with STIR [RFC8224] tells the called party that the caller is authorized to use the calling number. It says nothing about whether an AI agent is on the call or who operates that agent.¶
+----------+ SIP +---------+ SIP +--------+ TDM +--------+ SIP
| Consumer |------>| Carrier |------>| B2BUA/ |----->| Brand |----->
| Agent | | A | | SBC | | SBC |
+----------+ +---------+ +--------+ +---+----+
|
+-------------------+------------------+------+
| | |
+-----+-----+ +------+-----+ +------+------+
| Brand | | Human | | SIPREC |
| Agent |----->| Rep. | | Recorder |
+-----------+ REFER+------------+ +-------------+
¶
| REQ-ID | Description | Tag |
|---|---|---|
| CC5-1 | The working group's evaluation criteria for transport bindings are required to consider SIP because it is widely deployed for contact center voice traffic. | Transport |
| CC5-2 | A SIP binding, if specified, is required to preserve dialog-context continuity across back-to-back user agents and session border controllers that support the binding, taking the Session-ID header field [RFC7989] as prior art. | Transport |
| CC5-3 | The protocol is required to treat an agentic dialog as independent of any single SIP dialog or call, so that one dialog can span the several SIP dialogs created by transfer, callback and reconnection. | Dialog |
| CC5-4 | When dialog continuity is expected and a path segment cannot carry dialog context, such as a TDM segment, the binding is required to expose the continuity failure to participants or gateways that support the binding rather than silently treating the call as a new dialog. | Dialog |
| CC5-5 | The protocol is required to allow an agent identity to be conveyed with a call independently of telephone number attestation. | Authentication |
| CC5-6 | A recorder receiving media through SIPREC is required to be able to receive the dialog identifier, for example in recording metadata [RFC7865], so that recordings can be associated with the dialog. | Dialog |
Contact centers keep conversation records for quality review, dispute resolution, training, and regulatory retention. Depending on the jurisdiction and purpose, they may also need evidence of notice, consent, or another lawful basis for recording and processing. When agents take part in those conversations, the records grow to include what each agent was told, what it did and on whose authority. The use cases above show that records about one dialog are kept in several places: the consumer agent's domain, the brand, an outsourcer, a recorder.¶
The agentic dialog management protocol does not carry these records and this document asks for no record format. Audit data structures are out of scope for agentproto. The protocol's contribution is the dialog identifier: a value each participant holds and can write into its own records, so that records kept separately can later be associated. Requirements CC1-6, CC2-3, CC4-4 and CC5-6 exist for this purpose.¶
The vCon format [I-D.ietf-vcon-vcon-core], developed in the IETF vCon working group, is one representation of such a record. It holds the parties to a conversation, its media and transcripts, analysis, and attachments such as a record of the lawful basis for processing [I-D.howe-vcon-lawful-basis]. The agentproto charter lists vCon under coordination, on conversation representation and its relationship to dialog context. A system that indexes vCons by dialog identifier can find a record from that identifier. A party that reads the identifier from a vCon can use it, subject to authorization, to request related records held by other participants. Defining how a vCon carries a dialog identifier is work for the vCon working group.¶
For [I-D.agentic-ai-usecases-requirements], the author suggests the following text to resolve the editor's note in its Section 6:¶
Audit and provenance representation is addressed by existing work, including W3C provenance (PROV), Trace Context, and, for conversations among users, agents and human representatives, the IETF vCon format [I-D.ietf-vcon-vcon-core]. Dialog identifiers can be used to correlate these records across the participants in a dialog, including across administrative domains. This document does not define a record format.¶
The security considerations of [I-D.agentic-ai-usecases-requirements] apply. Contact center deployments add the following.¶
Resuming a dialog on a new channel (CC3-1, CC3-2) is a takeover risk. An attacker who can re-associate with an interrupted dialog inherits whatever authority the consumer had established on it, which may include a half-completed payment. Re-association needs to rest on authentication at least as strong as the dialog required before the interruption.¶
Participant replacement (CC2-1) and passive-to-active promotion (CC4-5) let a party gain the ability to act in a dialog. Each needs to be authorized at the time it happens, as CMN-12 requires, and the departing participant's authority needs to end (CC2-4).¶
Passive participants (CC4-4) receive dialog context and usually sensitive media. Their presence in a dialog is itself information the consumer may be entitled to know, and many jurisdictions require notice before a call is recorded.¶
Learning whether the peer is an AI agent (CC1-3) depends on the peer telling the truth. The protocol can authenticate a declaration and bind it to a participant identity. It cannot, by itself, prove how the peer is implemented or force a dishonest peer to declare itself.¶
Operation-status checks under CC3-5 need replay protection and idempotency at the application layer. Resuming a dialog must not cause an operation with external effect to run a second time.¶
Carrying a dialog identifier over a SIP or PSTN path can expose a correlation handle to intermediaries. A binding needs to provide the confidentiality and integrity required by CMN-3 where the path supports it, limit disclosure where it does not, and prevent an intermediary from substituting an identifier without detection.¶
A dialog identifier written into a brand's recordings, an outsourcer's records and a consumer agent's logs links those records by design. The same property lets anyone holding two of those records link them. Dialog identifiers need to be unpredictable, scoped to one dialog, and free of any encoding of a telephone number, customer account or agent identity.¶
A consumer agent that calls many brands for one consumer can let those brands correlate the consumer if it reuses identifiers, agent credentials or delegation tokens across dialogs. The mapping that lets a brand re-associate a returning consumer with an interrupted dialog (CC3-2) belongs to the brand alone and needs no counterpart in the dialog context.¶
Requirement CC2-3 keeps task context, which carries the personal data, out of the dialog context when a dialog crosses into another domain. The receiving domain fetches only what it is authorized to see.¶
This document has no IANA actions.¶
AI tools were used to research source material, criticize drafts, and check grammar. The author reviewed the resulting text and takes responsibility for the document's technical content, claims, and references.¶
The table maps each requirement in this document to the requirement it extends in [I-D.agentic-ai-usecases-requirements].¶
| This document | Relationship to the agentproto use cases document |
|---|---|
| CC1-4 | Extends A1-5 and CMN-11 to mid-dialog modality change |
| CC1-7 | Instance of B2-6 and B3-1 to B3-4 across a domain boundary |
| CC2-1 | Extends CMN-11 to participant replacement |
| CC2-5 | Applies the CMN-11 dialog lifetime to a waiting state |
| CC2-6 | Specializes CMN-5 for a failed transfer |
| CC3-1 | Extends B1-6 to a change of channel |
| CC3-2 | Applies B1-7 when the user does not hold the identifier |
| CC3-4 | Applies B1-8 and extends CMN-11 with an interrupted state |
| CC3-5 | Correlates an application-layer outcome check with the dialog; operation semantics remain out of scope |
| CC4-1 | Extends A1-10 to chained transformers |
| CC4-5 | Instance of CMN-12 |
| CC4-6 | Consistent with Section 3.1 |
| All others | New |