Guided channel selection¶
Status: Draft | Last reviewed: 2026-10-20
Use this design when adding organization-controlled channel discovery, queue admission, diversion, or callbacks. One versioned channel policy should govern the website, Voice/Chat agents, IVR and queue flows, and Copilot guidance. This is a proposed extension: the existing counterparty detector and telephony transports provide building blocks, but the shared policy service, queue adapters, and OpenMuse voice adapter are not implemented by this document.
The implemented Alder Homeworks Scenes demonstrate channel discovery, spoken web diversion for an assistant without SMS, a generated human-inspection sequence, and explicit owner confirmation before purchases. These authored presentations do not implement the proposed production policy service or telephony adapters. The storyboard records narrative requirements.
Existing capabilities and gaps¶
| Area | Available in this checkout | Addition required |
|---|---|---|
| Counterparty assessment | Continuous transcript assessment, protected live variables, Voice/Chat action, persistent Copilot card | Typed queue declarations and independent acoustic evidence |
| Identity and rules | Customer Authentication, Agent Logic, tool gates, scripted subagents | Shared channel eligibility and admission decisions |
| Messaging and outbound calls | Start Conversation supports SMS and outbound voice | Transactional diversion and durable callback scheduling |
| Queue operations | Provider-specific integrations and customer-owned flows | Capability-checked priority, admission, removal and re-entry adapters |
| OpenMuse evaluation | Real OpenMuse agent loop over public HTTPS chat | Caller audio input/output, remote-audio recognition and DTMF |
| Preview Mock Caller | Adaptive caller speech over internal VoiceAgent gRPC | External IVR listening and telephony transport integration |
| Telephony Preview | Direct WebRTC, Connect WebRTC flow entry, Genesys SIP entry | Connect these transports to the OpenMuse caller loop |
The implementation boundaries are documented in counterparty detection, Customer Authentication, Agent Logic, scripted subagents, and Start Conversation. Reuse those mechanisms; do not introduce another expression evaluator or duplicate authentication state.
One policy, several entry points¶
Author a tenant-owned, versioned policy through a visual eligibility table. Inputs include intent, identity assurance, delegated authority, channel availability, opening hours, service capacity, completed triage steps, and explicit organization exceptions. Identifying a customer, authenticating that customer, and authorizing an assistant to act for them are separate facts.
Models can extract intent and estimate whether the other party is AI. Deterministic policy decides which channels the organization supports for that case and which prerequisites apply. Provider adapters perform the actual transition and return receipts. Neither a model answer nor a policy decision establishes that a call joined a queue or a callback was booked.
| Entry point | Policy-controlled behavior |
|---|---|
| Website before contact | Collect the minimum identity and issue details, then reveal eligible chat, callback, or phone options |
| Direct inbound call or chat | Evaluate the same admission prerequisites even when the visitor bypasses the website |
| IVR before a human queue | Collect required intent/authentication; admit, offer a callback, or divert |
| Caller already waiting | Reassess signals, offer triage/SMS alternatives, and change queue state through the provider |
| Voice/Chat agent | Read current guidance, explain requirements, and request permitted transitions |
| Copilot | Show a persistent guidance card and permitted actions using the same policy snapshot |
Channel obfuscation is a discovery experience, not an admission control. Hiding a number cannot stop someone dialing a saved or shared copy. Enforce prerequisites at the server/contact flow as well as in the website. For callback-only service, the inbound route should explain that policy and offer booking or triage instead of admitting callers to the unsupported queue.
When carrying a web decision into chat or calling, use a short-lived server-issued admission token bound to the tenant, session, intent, assurance level, and allowed channel. Validate expiry, replay rules, and the current decision server-side. Browser fields, ANI attributes, and client-side detector events do not authenticate the visitor.
Publish policy revisions and bind them to base agent identities and provider entry points. Record the policy version on each decision; make in-flight revision adoption explicit. Preserve the existing CCaaS publication allow-list: channel eligibility does not authorize an unpublished agent/integration pair.
Signals and continuous state¶
Keep these signals distinct:
| Signal | Meaning | Does not establish |
|---|---|---|
counterparty_ai_likelihood |
Existing model score from customer transcript evidence | Calibrated population probability or identity |
| AI self-declaration | Caller says they are an assistant, or selects the active declaration option | Verified agent provenance or delegated authority |
| Synthetic voice score | Acoustic detector finds evidence of generated speech | An autonomous controller |
| Early human request | Caller says “agent” or presses 0 before completing defined triage | That the caller is AI |
| Browser automation verdict | Browser detector reports automated interaction | That a particular LLM controls the session |
| Engagement progress | Required issue details, authentication, or useful self-service steps completed | Engagement based only on elapsed time or turn count |
The existing counterparty_ai_* variables remain detector-owned. Retain their availability, pending and assessed-through fields so policy can distinguish fresh evidence from an old score. Do not let a model overwrite them through ordinary variable assignments.
The following runtime contract is proposed, not an existing API:
| Proposed state | Purpose |
|---|---|
channel_policy_id, channel_policy_version, channel_decision_revision |
Identify the exact policy and coherent decision snapshot |
channel_allowed, channel_recommended, channel_requirements |
Supported choices and missing prerequisites |
channel_decision_reason, channel_decision_updated_at |
Explain the decision and its freshness |
human_queue_class, human_queue_membership |
Separate desired priority class from confirmed queue membership |
diversion_status, callback_status |
Track requested, pending, confirmed, failed and completed operations |
counterparty_self_declaration |
Typed claim with source, prompt ID, participant and timestamp |
counterparty_voice_synthetic_score, counterparty_voice_available |
Independent acoustic evidence, with source-window metadata |
Publish decision variables atomically and emit a revision event when relevant inputs change. Use existing live prompt bindings and Agent Logic triggers. A persistent ChannelGuidanceCard should update in place with intent, identity prerequisites, AI assessment freshness, current channel options, and confirmed queue/callback state. It can coexist with the existing CounterpartyAssessmentCard.
Proposed actions are get_channel_guidance, prepare_channel_handoff, commit_channel_handoff, cancel_channel_handoff, and schedule_callback. Separate reading a decision from changing a provider state. Use server-issued operation IDs, idempotency keys and state preconditions; return a receipt or an explicit pending/error result.
Agent/0 and queue diversion¶
Configure “early human request” using completed triage steps, not just a low turn count. A caller who already attempted self-service on the website should carry that progress into the phone session.
A policy can place untriaged Agent/0 requests or detected assistants in its lowest priority class and explain how to receive more appropriate service. Keep those conditions independently configurable. Completing the required triage should cause a fresh priority decision; a previous detector flag should not permanently lock the caller into a penalty.
Define wait aging, a maximum triage duration, and exceptions for urgent issues, inaccessible alternatives, and failed AI service. A repeated request after the AI failed differs from immediately skipping useful triage. Detection errors must not produce an indefinite wait.
Example hold wording:
To help route your request, press 1 for a text link where you can describe your issue and see available support options. You can stay on this call while you complete it.
Only promise a faster response when the destination's service commitment supports that claim. Offer an on-call triage option when the caller cannot receive SMS or use a browser.
Treat call connectivity and queue membership as separate states. The desired diversion may be call=connected, human_queue=none, destination=ivr_triage. Removing a caller from an agent queue need not disconnect the call, but the provider flow must actually support that transition.
Use a durable transition with these stages:
- Offered: explain the alternative and its effect on the current queue position.
- Accepted: capture the caller's choice and the required messaging permission.
- Prepared: create the triage session/link and make the destination usable.
- Committed: the provider confirms removal or transfer from the current queue.
- Active: keep the call in triage or continue through the linked channel.
- Completed or recovered: resolve, book a callback, or re-enter an eligible queue.
An SMS API accepting a message does not prove the caller received it. Before removing queue access, establish delivery/receipt or keep an immediately usable on-call fallback. Handle failed SMS, expired links, repeated keypresses and a human agent answering during the transition. If agent assignment wins the race, cancel the diversion unless the active owner explicitly transfers the call.
Provider adapters must declare supported operations. Do not emulate an unsupported “pause queue position” by silently removing and re-enrolling the contact. Record actual provider contact/queue IDs, acknowledgments, and the policy for preserving or resetting waiting age.
Declarations while waiting¶
Attach prompts to the active IVR/queue menu or chat interaction:
If you are a virtual assistant contacting us on behalf of a user, press 9 now.
Virtual assistants contacting us on behalf of users must identify themselves so we can apply the appropriate support process.
Record DTMF 9 as a declaration only while that prompt's mapping is active. DTMF 9 in an unrelated menu has no such meaning. A timeout or no response is unknown, not evidence of a human. A claim to be human does not erase other evidence.
Add a capability-owned declaration event with provenance rather than fabricating a customer transcript quote. Scope it to the participant and handle a subsequent handoff from assistant to human. Keep authentication and delegated authority requirements unchanged.
The current transcript detector observes a running TrueServe session. Detection while the caller is still in a provider queue requires a provider flow or media subscription active at that earlier stage. Enabling a capability only after transfer to the Voice agent cannot analyze speech that occurred before it joined.
Scheduled callbacks¶
Distinguish a virtual-queue callback, which may retain a service position, from a scheduled callback with a reserved time window. The organization chooses which it offers.
A scheduled callback needs durable booking state, capacity reservation, the customer's time zone, cancellation/rescheduling, deduplication, and retry/no-answer rules. Return a confirmed booking receipt before saying that it is scheduled. Use the existing outbound voice adapters for dispatch, not as a substitute for the scheduler.
Start Conversation already describes Genesys BYOC origination and Amazon Connect StartOutboundVoiceContact. The Connect path requires the configured outbound flow and its transfer into TrueServe. Demo callback-request tools are not evidence of a general scheduling or virtual-queue implementation.
Resemble acoustic and browser detection¶
The Resemble streaming documentation describes a server-to-server audio WebSocket. Its machine-readable page, retrieved on 2026-10-19, specifies approximately four-second analysis windows and skipped results when there is insufficient speech. This is a window size, not an end-to-end latency guarantee.
For an acoustic adapter:
- Tap the caller's isolated audio before mixing with business speech or hold music. A mixed call can label the organization's own TTS.
- Follow the documented WAV-header/PCM streaming protocol; the recommended input is mono 16 kHz PCM16. Preserve original codec and sample rate in evaluation records. Upsampling telephone audio does not restore lost information.
- Keep the API key server-side, wait for
ready, consume results while sending audio, then sendendand drainfinal. - Store source-window timestamps, provider/model metadata, score availability and result freshness. Errors, silence and skipped windows remain unavailable rather than “human.”
- Top-level chunk scores are cumulative aggregates; nested
chunk_infoscores describe the current window. Do not repeatedly average cumulative values as independent evidence. - Treat stream lifetime limits, reconnects, metered usage and retained audio/evidence as explicit integration settings.
The existing Connect KVS connector distinguishes customer and agent tracks. It is a possible passive source when the flow streams audio at the required stage. Its current reader requires both directions enabled; extract the customer track before acoustic detection. KVS observation does not provide caller audio injection.
Keep the acoustic score separate from the behavioral AI score until multimodal fusion is evaluated. Human-operated TTS is a necessary negative control for autonomous-agent detection. Synthetic speech may also be a separate organization policy input.
Resemble additionally documents website Agent Detection, distinct from its audio detector. It returns human, agent, or review from browser interaction signals and stops collecting after a verdict for that visit. Its documentation explicitly describes the browser signals as advisory and spoofable. Validate server-side session results before using them in policy; do not trust a DOM event as authorization.
The current OpenMuse HTTPS connector does not exercise browser pointer/keyboard behavior. Testing website detection and hidden channel options requires a browser-driven run, separate from the existing chat benchmark. Neither vendor capability has been integrated or benchmarked here.
OpenMuse voice feasibility¶
The checked-in OpenMuse runner imports the pinned OpenMuse agent engine and provides only contact_business({message}). It has no voice or DTMF path. Upstream OpenMuse also lists voice on its roadmap in its README retrieved on 2026-10-19; preserve the benchmark's pinned revision rather than assuming current main has the same integration shape.
| Route | Existing entry point | What a voice pilot validates |
|---|---|---|
| Direct WebRTC | Authenticated offer/DTMF/hangup proxy to media-proxy | Caller audio, barge-in, transcription and detector behavior |
| Amazon Connect WebRTC | StartWebRTCContact, chosen contact flow, Chime audio and DTMF |
Actual Connect IVR, queue, hold and diversion behavior |
| Genesys Telephony Preview | Janus → Asterisk → configured BYOC trunk → dialed IVR | Genesys IVR and carrier/trunk routing, DTMF and transfers |
| Existing outbound workflows | Genesys origination or Connect outbound API | Callback dispatch after a reservation is confirmed |
See Telephony Preview for transport ownership and exact call paths. Connect WebRTC caller attributes are not verified PSTN identity. Direct WebRTC does not pass through provider IVR/queue flows. Genesys external IVR calls must retain the existing telephony path without injected pipeline/draft headers that bypass the IVR. A code path's existence does not verify that a tenant's credentials and test destination are currently reachable.
Preview Mock Caller already generates adaptive speech and paced PCM, but it uses internal gRPC and the business transcript feed. It explicitly disables Telephony/IVR mode. Reuse its audio pacing and cleanup where appropriate; it does not currently make OpenMuse a phone caller.
The missing caller adapter should expose bounded start_call, listen, speak, press_dtmf, wait and hang_up operations to OpenMuse. It must:
- Receive and recognize the actual remote audio, including IVR prompts and hold announcements. A TrueServe transcript feed alone misses provider speech.
- Convert caller utterances into a live audio track, preserving pacing, silence, interruption and cancellation. A fixed fake-microphone recording is not an adaptive caller.
- Send real transport DTMF and observe connection, transfer and disconnect events.
- Own call duration limits, tenant-authorized destinations and credentials server-side.
- Preserve separate audio tracks, timestamped caller decisions, keypresses and provider IDs for evaluation without exposing detector scores or test labels to the caller.
Reuse the telephony transports and keep OpenMuse as the caller decision engine. Creating an outbound call alone does not connect that engine to its media.
Pilot and acceptance tests¶
Start with direct WebRTC to verify the new audio adapter. Then run the same caller scenarios through an isolated Connect WebRTC test flow; use Genesys Telephony Preview for the corresponding IVR/trunk tests. Complete a PSTN run separately when carrier audio and phone identity handling matter.
Freeze prompts and thresholds before each holdout set. Test disclosed and concealment-prompted OpenMuse callers separately, alongside human-authored/recorded controls. A successful declaration challenge is not evidence that covert detection works.
| Test family | Required cases |
|---|---|
| Channel eligibility | Intent/channel matrix; identity vs authentication; known-number and direct-URL bypass; unsupported inbound voice |
| Agent/0 | Immediate bypass; human request after failed AI; prior web triage; aging; accessible alternatives |
| Declarations | Active DTMF 9; unrelated menu 9; silence; covert denial; assistant-to-human handoff |
| Audio | Human speech; AI speech; human-operated TTS; noise; hold music; 8/16 kHz sources and negotiated codecs |
| Diversion | DTMF 1; SMS failure; no browser; expired link; duplicate requests; agent-answer race; queue re-entry |
| Callbacks | Capacity full; time zones; duplicate booking; cancellation; dispatch failure and no answer |
| Browser | Human and browser-agent visits; direct endpoint calls; insufficient telemetry; forged client verdict |
| Runtime | Model/provider timeout; stale assessment; reconnect; policy revision; complete cleanup on hangup |
Report AI precision, recall and F1 separately for disclosed and covert callers, human false positives, time to first correct flag, transient flags, unavailable/pending results and transport failures. The previous chat benchmark does not establish voice accuracy. F1 ≥ 0.90 and AI recall ≥ 0.90 are different targets; require both if the goal is to detect at least 90% of AI callers.
Also measure policy correctness, completed diversions, abandoned transitions, duplicate queue entries, wait aging, callback fulfillment and recovery after delivery failure. A high detector score cannot compensate for a caller stranded between channels.
Begin policy evaluation in shadow mode against the test flows, then exercise the mutations with explicit expected provider receipts. Before claiming end-to-end completion, retain the audio, decision timeline and provider events proving queue removal, continued call connectivity, triage completion and the resulting queue or callback outcome.