Operators and Escalation
Plan human escalation and supported API-based intervention, including phone takeover, handback, and transfer fallbacks.
Human operators handle work that needs their judgment or authority. The platform supplies controls for inspecting and intervening in eligible interactions; the organization defines staffing, handoff criteria, and the destination for unresolved work. Operating Model explains that division.
The Developer Console's operator pages, takeover controls, and Runs > Live tab are retired. Runs retains All runs and Overview, including a Live status filter. To provide intervention controls, build an integration with the Platform operator and run-control APIs. Confirm runtime support and operator access before designing that integration.
Distinguish live takeover, transfer to an external phone destination, and approval of a proposed write. Each addresses a different problem and has its own lifecycle. The sections below cover live operation and transfer; Review Queue covers the separately enabled connector approval workflow.
On a supported voice path, an operator joins the same conference as the caller and agent. Listen mode does not transfer or reconnect the call. An integration should request listen mode explicitly and require confirmation before switching to takeover, which unmutes the operator and suppresses the agent's voice.
For eligible text, SMS, email, and web runs, takeover pauses the agent while the operator authors replies, then resumes it when the operator hands control back.
How Escalation Policy Works
Escalation behavior is authored in the agent's context graph and instructions. Teams define which user requests, safety boundaries, unavailable tools, or uncertain situations require a transfer, callback, refusal, or operator involvement. The current runtime does not provide a separate monitor-concept system that can replace those instructions.
An integration can use the Runs and operator APIs to locate eligible active work and request intervention. Check channel, live status, and runtime support before joining; a listed realtime-provider call does not necessarily support takeover. Supported join paths emit escalation and operator-attribution events.
Define a fallback for times when no operator is available. Depending on the workflow, that can mean a configured external transfer target, a callback task, emergency instructions, or a bounded response that does not continue beyond the agent's authority.
Build an Intervention Workflow
An intervention client needs to find eligible work, connect the operator, and verify each change of control.
Find Active Runs
Use the Live status filter in All runs to inspect running and paused conversation records. Old Live-tab bookmarks fall back to All runs. This is a browse filter, not an urgency-ranked operator queue, and no takeover drawer opens from a row.
Live visibility and retained records are best-effort. Framework history normally becomes available at terminal completion and is not authoritative real-time dispatch state. An intervention integration needs its own queue, staffing, and eligibility checks using the Runs API.
Operator Modes
Voice operators work in one of two modes:
Listen mode - The operator hears the conversation but is muted at the telephony level, and the agent continues handling the call. The platform does not add operator speech or an audible join announcement; organizations remain responsible for any monitoring disclosures required by policy or law.
Takeover mode - The operator is unmuted and speaks directly with the caller. Agent speech and turn processing are suspended; caller and operator speech can be captured for handback context. When the operator switches back to listen mode or leaves, the agent resumes in the existing session. The client must provide any confirmation step before requesting this mode.
During takeover, the operator's speech is transcribed separately and recorded as operator turns when transcription succeeds. The retained call record can therefore include the human segment alongside agent and caller turns.
Text-Channel Takeover
For eligible live text, SMS, email, and web runs, the integration pauses the agent, stages an operator reply, and hands control back explicitly. Only one pending reply is retained; staging another replaces it, and downstream delivery can still fail. See Author a Non-Voice Turn.
Phone Connection
Voice operators connect over the phone network. The platform dials the phone number on the operator's profile and adds them to the conference when they answer. The integration provides controls and displays available transcripts; the operator's phone carries the audio. Carrier conditions affect the additional media leg.
Browser microphone and headset joining through WebRTC is no longer supported. Configure a reachable operator phone number before testing listen mode or takeover.
Only one operator can be active on a call at a time. If a second operator attempts to join the same call, they receive a conflict error. The same operator joining the same call again receives the cached response (the join is idempotent).
Run Context
Run detail provides the available channel-specific record. Retain the selected workspace and run identifiers, resolve the supported call, and display its caller and service context before requesting control.
Guidance Injection
Operators in listen mode can send text guidance to the agent without taking over the call. When delivery reaches the active session, the current voice runtime interrupts agent speech and frames the guidance for the agent's next response. The API can also report queued or failed delivery, so clients should inspect the returned status rather than assume the instruction was applied.
This is useful when an operator sees the conversation going in the wrong direction and wants to steer the agent without adding operator audio to the call. For example, an operator monitoring a scheduling call could send "Ask for their insurance ID before confirming the appointment" for the agent to incorporate into its next response.
Guidance messages are distinct from external events. External events carry factual information ("The appointment has been confirmed") and queue behind the agent's current speech. Guidance carries instructions ("Ask about their insurance") and interrupts because instructions are time-sensitive.
Both event types use the active voice-session delivery path, which routes the event to the session handling the call.
Silence Management
Silence handling is a dedicated voice-runtime behavior. It does not depend on a composite risk score or a separate conversation-monitoring service.
If the caller stops speaking, the silence monitor manages this with exponential backoff:
After 10 seconds of silence, the agent generates a short check-in.
If there is still no response, the next threshold is 20 seconds.
At the third unanswered threshold, capped at 40 seconds, the agent generates a brief goodbye and ends the call.
Check-in utterances have a 5-second staleness window. If the caller speaks during the check-in filler, the filler is discarded and the conversation continues normally. This prevents awkward overlaps where the agent says "Are you still there?" just as the caller starts talking.
Caller speech resets the silence sequence. Safety and escalation behavior remains governed by the authored agent policy and explicit operator or forwarding workflows.
Speaker Resolution
With three participants in a conference (caller, agent, operator), the system resolves who is speaking at any given moment using a priority chain:
Operator in takeover mode - Highest priority. Agent audio is suppressed.
Caller - Barge-in detection applies. If the caller speaks during agent output, the agent stops.
Agent - Speaks when neither the operator nor the caller is active.
Operator takeover suppresses the agent. Caller interruptions depend on the active barge-in policy and recognized speech, so background noise or speech below the configured threshold does not necessarily stop playback.
Warm Hand-Off
Warm forwarding is a service-level call-forwarding mode, separate from an operator joining through the run-control API. When the agent invokes forward_call and the resolved forwarding configuration uses warm_transfer: true, the runtime keeps the caller in the conference, dials the configured destination, and gives the agent a brief hand-off turn before connecting the caller to the person who answered. Cold forwarding remains available when a briefing is inappropriate, such as an IVR, voicemail, or emergency destination.
Phase 1: Normal
The agent and caller are in conversation as usual. Authored instructions decide when the agent should invoke forward_call; the runtime then resolves the destination from the supported forwarding inputs and service configuration.
Phase 2: Briefing
After the agent's current speech drains, the runtime holds the caller and dials the forwarding target. The caller remains on hold during the briefing and cannot hear or be heard by the agent and destination. The runtime waits for a human-answer classification before beginning the briefing; an answered call alone is insufficient. The hand-off is intentionally brief and does not guarantee transfer of the full transcript, patient record, risk assessment, or recommended actions.
Barge-in is disabled during the briefing phase so speech from the caller or forwarding target does not interrupt the agent's introduction.
Phase 3: Connected
After the briefing speech drains, the runtime takes the caller off hold before removing the agent. If unholding fails, it retains the agent rather than deliberately leaving the caller stranded. Voicemail, fax, a failed dial, or an answer timeout returns the caller to the agent. Answer classification is provider-dependent and is not a guarantee that a destination is a suitable human operator.
A service forwarding configuration explicitly selects warm or cold transfer and either a fixed destination or a dynamic number supplied by the agent. Without that configuration, the forwarding tool is unavailable. State policy can further restrict forwarding. Destination selection does not inherit a fallback number from workspace settings.
Deferred Transfer
When the agent initiates a call transfer (for example, forwarding to a clinic's front desk), the transfer is deferred until the agent's goodbye message finishes playing. This prevents the caller from being redirected mid-sentence. If the caller speaks during the goodbye (barge-in), the transfer is cancelled and the conversation continues. If an operator joins the call during this window, the transfer is also cancelled.
Operations Views
Operators register with a profile that includes their name, skills, phone number, and role. Their status is tracked as online, busy, or offline.
The Developer Console retains run browsing. Operator-specific views require an API integration:
Runs > All runs - Filterable conversation and framework history, including the Live status filter.
Runs > Overview - Workspace totals and status distributions.
Operator analytics and audit APIs - Escalation, response-time, handle-time, and attributed operator-action records for your integration.
Escalation as Collaboration
The agent handles the routine part, and the operator handles the part that needs human judgment. Both contribute to the same run record. After a voice takeover, the agent can resume with the captured caller and operator turns as handback context.
Use escalation rates, response times, handle times, and fallback outcomes to plan staffing. Assign people to the authored escalation paths and maintain a fallback for times when they are unavailable.
Last updated
Was this helpful?