Choose how much conversation logic and lifecycle you want to manage.
Voice Live is the runtime in all three paths. The difference is where your agent lives.
Start with a pattern. Then watch the enterprise request flow.
Real-time speech with an application-controlled session and optional custom agent.
Use when: custom orchestration and session control matter most.
Explore custom orchestration →Preserve the text agent's tools and knowledge; add a managed speech layer.
Use when: an existing Foundry agent already solves the business problem.
Explore the integration →A voice-native agent definition, with Voice Live inside the managed experience.
Use when: you want managed voice configuration, versions, and channels.
Explore a native voice agent →What the new agent experience adds beyond a manually assembled voice session.
Four capabilities to discuss before choosing an architecture. Quickstart [2]
Important: voice-agent preview is not a production SLA. Audio/transcript capture is opt-in, not automatic. Teams Phone connectivity is not the same as publishing a Teams app.
Select a pattern, play the request, or click a component to inspect its implementation.
Animation shows logical sequencing, not measured latency. On mobile, scroll the diagram sideways. Select nodes with a mouse or Tab + Enter. Compare the running-cost components →
Design sketch only, unless explicitly identified as API configuration. Not a deployable production template.
Each card opens an architecture and its implementation recipe.
Ground answers in approved content; speak naturally; keep source links visible.
Existing investmentVoice-enable a working agentKeep the agent's prompts and business tools. Add speech without a rewrite.
Cross-departmentHR + IT employee conciergeOne conversational front door, with separate policy and service specialists.
Global serviceMultilingual order supportEnglish, Spanish, French, or Hindi speech; one canonical order-service API.
Contact centerInbound phone self-serviceTeams-owned or Twilio numbers, account lookup, and a designed escalation path.
Capture pilotSurvey / interview captureBrain dump to validated draft, read-back, explicit confirmation, and approved save.
Field productivityCRM / time-entry draftsHands-free capture without unconfirmed writes or duplicate records.
Custom orchestrationSpecialist guided workflowsReuse code-owned state machines and backend logic behind a real-time voice interface.
Localize listening and speaking. Keep business identifiers, validation, and authorization stable.
Authored language examples, not live translation or audio. Model, recognizer, voice, code-switching, and region compatibility must be tested separately. Language support
Animate the multilingual architectureget_order_status({ "orderId": "1042" })
// Authenticated identity is supplied by the server.Language selection never changes who may access the order. Use an explicit language confirmation or fallback when detection is uncertain.
Three audio-processing paths, plus a bring-your-own-deployment option. The model and speech configuration change; the business tools can remain the same.
Direct audio reasoning and audio response. Evaluate naturalness and tool reliability.
Native audio understanding, with a separately selected compatible Azure output voice.
Separate recognition, text reasoning, and synthesis. Useful for existing text-agent workflows.
A deployment choice, not a fourth audio transformation. Use a compatible native or cascaded path.
No universal latency or accuracy ranking is implied. Compare the same language, noise, tools, prompt, and concurrency. BYOM support is model/provider/API specific, not catalog-wide. Configuration [4] Models [5] Speech combinations [6]
gpt-realtime familygpt-realtime-mini familyEvaluate natural dialogue, tool correctness, interruption handling, and cost.
Model / region listingSupported GPT text modelsCompatible BYOM deploymentsSTT → text model → TTS. Useful for existing agents and specialist reasoning.
Managed versus self-deployedazure-speechMAI Transcribe variantsTest vocabulary, accents, locale detection, noise, and streaming availability.
Compatibility guidanceAzure neural / HD voicesMAI-Voice-2.1-FlashFlash targets interactive speech. Verify voice, locale, consent, and latency.
MAI voice documentationEnterprise-ready design is not the same as production-approved preview. Native voice agents and some speech models remain preview: no preview SLA, and not recommended for production workloads. These diagrams are reference patterns, not tenant-validated deployments. Private networking and data locality must be checked for the exact combination.
Yes: users talking through a web app still produce native Foundry voice-session traces when the project's Application Insights connection is configured. No: that connection alone does not instrument the browser, your backend, or your business APIs. Voice observability [9] / Trace setup [23]
Instrument microphone permission, connection startup/close, playback start, interruption handling, and client errors explicitly. Page views and HTTP dependencies do not measure live audio or WebSocket messages automatically.
App-defined events, not built-in Foundry metrics. Follow consent requirements and avoid raw audio, transcripts, tokens, and user identifiers in browser telemetry.
Connect Application Insights to the Foundry project. Server-side tracing covers the voice session, turns, model/tool calls, and relevant VAD, recognition, and synthesis stages for the selected pipeline.
Use Traces > Trajectories for the waterfall and the voice monitoring dashboard for latency, usage, and errors. Native S2S does not imply separate STT/TTS stages.
Instrument your session relay, authorized APIs, retrieval, and downstream dependencies with supported Azure Monitor/OpenTelemetry tooling. Record duration, failure category, agent version, and an opaque correlation key.
Tool-call telemetry in Foundry does not replace tracing inside the API. A successful model response is not proof that a database or CRM commit succeeded.
Animate the web-app monitoring architecture →
Use Channels > Preview web app when the endpoint supports it. Grant intended organizational users access, connect the project's Application Insights, then generate a fresh conversation and verify a voice trace.
You do not own that managed frontend's source or assume it exposes an SDK injection point. Test microphone/playback separately. If you need custom browser events and application dashboards, build and instrument your own client.
Instrument the browser and backend separately. For HTTP paths you control, configure supported W3C trace-context propagation and allowed CORS origins. Never forward credentials or correlation headers indiscriminately.
Keep a server-side mapping from an opaque application conversation ID to the voice session ID returned by the supported API/SDK and any trace ID you can obtain. Media/WebSocket paths do not guarantee automatic parent-child correlation; use a verified mapping or trace links instead of claiming one continuous trace.
Collect durations, error categories, usage, and identifiers necessary for support. Configure telemetry sampling/retention and least-privilege access; ingestion and logs can incur costs.
Transcripts, prompts, tool data, and audio references are not captured by default. Enable content capture only with an approved privacy policy. Application Insights holds telemetry/audio references, not the audio recording itself.
store:true persists transcripts, events, and raw audio together in voice-agent-owned storage. store:false does not disable operational tracing or browser logging. Review recording and trace-content settings independently.
Trace readers need Log Analytics Reader and, for protected tables, Privileged Monitoring Data Reader at the applicable scope. Ingestion identity, trace viewing, evaluation, and annotations are separate permissions. Never log bearer tokens, cookies, API keys, or sensitive business payloads. Access and recording boundaries [9] / Sensitive content controls [26]
| Symptom | Inspect first | Then verify |
|---|---|---|
| No voice trace | Project Application Insights connection, recent traffic, ingestion delay, writer permissions | Correct project/version, time range, reader RBAC, sampling and protected-table access |
| Agent trace is fast, user hears a delay | Browser playback start, buffering, device permission and network timing | Compare client measurements with the precise service metric definition; browser speaker latency is not service TTFA |
| Slow turn or repeated answers | VAD boundary, model, retrieval and tool waterfall | Timeouts, retries, oversized context, throttling, and failed action recovery |
| Trace exists, no transcript/audio playback | Content-capture settings, available references, recording policy and playback access | Do not enable recording as a blanket fix; approve access and retention first |
| Browser/API spans are separate | HTTP trace context on owned endpoints and opaque conversation-to-session mapping | Do not assume WebSocket/media propagation; verify correlation with a known test call |
Release test: a non-builder user completes a web conversation, interrupts it, denies microphone permission, encounters a failed tool, reconnects, and ends the session. Verify the corresponding client events, server traces, authorized API result, and retention behavior. Define latency/error/task-success alert thresholds from a measured baseline. Metric start/end points differ: the overall latency chart measures from end of VAD; do not label every TTFA signal as the same measurement. Metric definitions [9]
Architecture review: all eight patterns were checked against the linked Microsoft documentation on October 16, 2026. Boxes are logical responsibilities, not proof of separate deployed resources or network isolation. Browser diagrams show an example customer-owned relay; the managed preview web app's internals are not asserted. Speech stages are conditional on the model path, and caller identity must be bound to tool authorization explicitly. These are reviewed reference designs, not tenant-tested deployments.
Start with the native kind: voice agent, not a standalone Voice Live invoice. Model hosting determines the billing boundary; specialists, tools, channels, and retention complete the budget. There is no universal all-in per-minute price. Foundry voice-agent pricing [21]
model_type: managed bills model usage through the voice agent. Budget the configured model/speech path; do not add a second standalone LLM bill for the same usage.
model_type: self_deployed bills inference to your compatible Foundry deployment. Speech/agent features remain additional. Existing PTUs are capacity to allocate, not free inference.
Specialist delegation adds model/tool work; hosted specialists can add compute. Phone channels, avatars, retrieval, and opt-in recording have their own costs. Subagents [13] / Channels [8]
| Model meter example | Input / 1M tokens | Output / 1M tokens | Model only / 1,000 conversations |
|---|---|---|---|
| GPT-4.1 nano | $0.10 | $0.40 | $1.00 |
| GPT-4.1 mini | $0.40 | $1.60 | $4.00 |
| GPT-4.1 | $2.00 | $8.00 | $20.00 |
The planner applies these rates only to its self-deployed token-billed text-model path. Confirm exact version, compatibility, capacity, deployment SKU, and regional/data-processing requirements. Cached, batch, fine-tuned, realtime/audio, and provisioned meters differ. More capable models may improve task completion; compare cost per successful task, not token price alone.
Cap max_output_tokens; keep instructions and tool schemas short. Prefer static_interim_response where suitable: an llm_interim_response adds a model call on each trigger.
Use end_conversation when the task is complete. Route only the calls needing a specialist; bound retries and tool loops. Long sessions and repeated context increase usage.
Inspect turn/session microsoft.foundry.voice.estimated_cost.* attributes: managed and self-deployed components, plus separate session avatar estimates. These are analysis estimates, not invoice records.
If conversations are stored, read the completed conversation's usage. Keep store:false unless retention is required; recording and trace-content capture need separate privacy decisions. Reconcile pilot estimates and all connected resources with Microsoft Cost Management. No zero platform fee or free preview is assumed here. Pricing and controls [21] / Tracing [9]
Use this comparison when choosing the direct API architecture. It is intentionally separate from the native Foundry voice-agent budget above; its meter bundles are not automatically native-agent tariffs.
| Meter family | Native audio in / out | Standard speech in / out | Base text in / out |
|---|---|---|---|
| Voice Live Pro | $32 / $64 per M tokens | $17 / $31 per M tokens | $4 / $16 per M tokens |
| Voice Live Standard | $11 / $22 per M tokens | $15 / $26 per M tokens | $0.66 / $2.64 per M tokens |
| Voice Live Lite | $4 / $12 per M tokens* | $15 / $25 per M tokens | $0.11 / $0.44 per M tokens |
| Voice Live BYO standard speech | Not covered by this row | $12.50 / $23 per M tokens | Own model deployment is additional |
*Meter availability is not model-capability proof: for example, the documented Phi path uses Azure speech output. Additional model-specific meters exist, including a Pro "LLM Text Output 2" meter at $24/M; use the meter mapping for the selected model rather than applying the base rate universally. Custom speech/voice, cached usage, avatars, and negotiated prices are not in this table.
Budget the chosen managed or self-deployed model/speech path, tools, and channels. Confirm native-agent billing separately; this direct Voice Live calculator is not a universal native-agent invoice.
Account for Voice Live and the existing text-agent model deployment plus tools. Confirm actual meter boundaries so a bundled or separate model charge is not counted twice.
Delegation adds model/tool calls; hosted code can add compute. Session length, verbose replies, retrieval context, concurrency, and retry storms can all change the total.
Azure Speech pricing Microsoft Foundry pricing Architecture billing comparison [3]
Voice Live is the real-time voice runtime and API. Microsoft Foundry Agent Service adds an agent lifecycle: instructions, tools, knowledge, versions, monitoring, and governance. A native Foundry voice agent brings these together in a voice-specific definition. [1] [3]
The environment for choosing models, building agents, connecting business tools and knowledge, and evaluating and operating the result. It is broader than a single voice API or model.
Provides real-time audio interaction, voice activity detection, interruption handling, speech integration, and model choice. You can use it directly or with an agent; native speech models are not exclusive to the new agent type.
An agent with kind: voice. Its versioned definition specifies the model, instructions, greeting, listening, speaking, and actions. Foundry manages the voice orchestration.
A useful customer explanation: Voice Live gives the conversation a real-time voice. Foundry gives that experience a managed agent identity and lifecycle. The preview reduces orchestration work; it does not remove the need for application security, authorized tools, a usable client, or release testing.
Preview is a release decision, not a footnote. The voice-agent documentation identifies preview functionality as having no preview SLA and not recommended for production workloads. Validate feature access, region, channel, network configuration, and model support in the customer's actual project before committing to a design. Do not apply the availability status of the overall Foundry platform to every voice feature. [2] [4]
There are three relevant patterns, not a binary choice between Voice Live and Foundry. The table distinguishes direct Voice Live from Voice Live connected to a text agent. [3]
| Decision | Direct Voice Live session | Voice Live + Foundry text agent | Native Foundry voice agent |
|---|---|---|---|
| Conversation engine | Supported realtime or text model, configured through the session. | Text model deployed for the connected Foundry agent; voice wraps that text experience. | Supported speech-to-speech or text model, configured as a voice-agent version. |
| Configuration ownership | Your application owns session setup, instructions, and tool execution. | Text instructions/tools in Foundry; voice/session settings are a separate integration surface. | Model, greeting, voice, turn detection, and tools are managed together. |
| Enterprise tools | Implement and authorize application-side integrations. | Reuse existing text-agent business logic, tools, and knowledge. | Configure voice tools/knowledge, or delegate to a supported specialist subagent. |
| Telephony | Build the provider/media integration or use a suitable accelerator. | The application manages the telephony integration. | Built-in provider connections and number bindings for Teams Phone extensibility and Twilio. |
| Diagnostics | Instrument the client and integration. | Text-agent tracing does not include the full voice pipeline. | Voice-pipeline spans, time-to-first-audio metrics, and optional conversation review. |
| Good fit | Custom real-time UX and fine session-level control. | Preserve a successful text-agent integration with minimal disruption. | Evaluate managed voice orchestration, integrated operations, and voice channels in a controlled preview pilot. |
Create a new voice agent alongside the current agent. A text agent's interaction mode cannot simply be flipped to voice. Reapply effective settings, including client overrides, tool connections, and permission boundaries; then compare both experiences on the same tests.
Do not confuse this with classic-agent migration. Moving from the classic Agent Service to the new Agent Service is a separate lifecycle task. [3]
A native voice agent can consult an existing prompt or hosted agent as a specialist. A hosted conversation engine is another option when custom code must own every turn, but it needs the required streaming bridge protocol, not just an ordinary text endpoint.
Constraint: voice subagents must be in the same project; they are not supported in VNet-isolated projects. [3] [13]
A useful voice agent is more than speech recognition plus a spoken answer. The conversational controls and business workflow must work together. These capabilities are configurable, not guarantees that every combination behaves identically.
Silence-based or supported semantic turn detection determines when the user has finished. Tune pauses and interruption behavior for open-ended answers, accents, and noise. Barge-in also requires the client to stop or truncate buffered playback correctly. [4] [6]
Noise reduction and echo cancellation help prevent background sound or the agent's own audio from becoming a new user turn. Test a headset, laptop speaker, and target phone path; a quiet playground test is not enough. [5] [6]
Use a fixed or model-generated opening. Interim responses can cover a slow tool call, so silence does not sound like a dropped session. A filler response does not reduce the actual tool's latency. [4]
Client-side functions require implementation in your app. MCP and versioned toolboxes support service-side execution; knowledge and tools such as Azure AI Search or OpenAPI can be attached through a toolbox. Validate supported authentication for each connection. [4]
Connect relevant knowledge instead of relying only on model memory. Retrieval must respect the user's authorization. Saying a document title aloud is not a substitute for showing provenance and validating source access in the application.
Choose supported voices and locales; add an avatar for compatible browser experiences if it has business value. A phone call is audio-only. Transcripts, visible status, and a text fallback should be designed into the target client. [2] [7]
Business behavior is still designed. Recognizing already-covered topics, asking only missing questions, producing a valid schema, and requiring confirmation are not automatic product promises. Implement instructions, explicit state, tool contracts, server-side validation, and scenario tests. Cross-session memory and session recovery also need an explicit design.
A realtime model, a transcription model, and a synthesis voice are different choices. A speech model does not automatically provide business reasoning. A model's presence in the Foundry catalog does not automatically make it available in every voice project.
Audio in → realtime model → audio out
Start here when fluid dialogue and conversational responsiveness are the primary goals. Voice Live can also combine compatible realtime models with Azure speech output for voice customization.
Evaluate: turn-taking, instruction adherence, tool correctness, accent handling, and whether the transcript reflects what was actually heard. Native audio does not remove governance needs. [3] [5]
Audio in → STT → text LLM → TTS → audio out
Start here when reusing a strong text agent, selecting a specialist reasoning model, or controlling speech recognition and synthesis separately is important. Foundry still manages the pipeline for a native voice agent.
Evaluate: recognition errors propagating into tools, model time to first token, synthesis startup, and total time to first audio. More reasoning is not always a better spoken experience. [4]
Representative choices from current Microsoft documentation, not an exhaustive catalog. Tiers below refer to the direct Voice Live managed-model listing, not a universal Foundry voice-agent price or compatibility guarantee. Verify the selected native agent's model picker and supported deployment path. [5]
| Family / examples | Role and pipeline | When to evaluate | Important qualification |
|---|---|---|---|
gpt-realtime-2.1gpt-realtime-1.5gpt-realtime | Native realtime conversation; listed in Voice Live Pro. | Open-ended, natural dialogue and tool-driven conversations. | Global, data-zone, and regional variants exist for selected models. Their inference scope and region availability differ. |
gpt-realtime-2.1-minigpt-realtime-mini | Smaller realtime family; listed in Voice Live Standard. | A cost-conscious comparison for high-volume or narrower conversations. | Measure quality and end-to-end latency. A smaller model is not automatically faster for every tool-heavy workflow. |
phi4-mm-realtime Preview | Multimodal audio input with Azure speech output; listed in Voice Live Lite. | Evaluate a lightweight alternative for constrained tasks. | Do not assume capability parity with GPT realtime models or universal native voice-agent support. |
azure-realtime | Listed in Voice Live Pro with dedicated azure-realtime-native voices. | Another documented realtime option when available to the resource. | Dedicated voice compatibility matters; do not apply another realtime model's voice configuration unchanged. |
gpt-4.1, gpt-4omini / nano variants where listed | Text reasoning with speech recognition and synthesis. Full models: Pro; listed mini variants: Standard; gpt-4.1-nano: Lite. | Reuse a text-agent workflow; establish a familiar baseline for extraction and tools. | Speech accuracy, text-model latency, tool time, and synthesis all contribute to responsiveness. |
GPT-5 familygpt-5, gpt-5.1, gpt-5.2, gpt-5.4 | Cascaded pipeline; these examples are listed in Voice Live Pro. gpt-5-mini: Standard; gpt-5-nano: Lite. | Complex instructions, multi-step business logic, and extraction scenarios needing stronger reasoning. | Reasoning latency can hurt turn-taking. Keep spoken answers brief; delegate deep work only when needed. |
gpt-5.6-terragpt-5.6-luna | Newer text-model entries in the current Voice Live list: Pro and Standard, respectively. | Include only if the actual resource exposes them and an A/B test justifies the change. | Current catalog examples, not claims about what was shown in the supplied video. |
| Compatible self-deployed models Azure OpenAI, supported Claude / Fireworks / managed-compute models | Foundry voice agents can use supported customer model deployments. The service still hosts the voice orchestration. | Reuse supported quota/PTUs, access more model choice, or use supported customization. | Compatibility is not catalog-wide. Check provider, API, deployment, filtering, region, capacity, and tool support. [4] |
gpt-5.5gpt-5.4-minigpt-5.4-nano | The Voice Live overview lists these as tested through BYOM, not pre-deployed managed choices. | Reuse a compatible deployment rather than assuming the model appears in the managed list. | Direct Voice Live BYOM support must still be checked separately from native voice-agent deployment support. [5] |
| Layer | Examples | What matters for this customer |
|---|---|---|
| Speech recognition | azure-speech; supported whisper-1, gpt-4o-transcribe, and gpt-4o-mini-transcribe combinations. | Evaluate names, business terms, accent coverage, noise, and corrections. Phrase lists and custom speech support depend on the selected recognizer and path. The compatibility matrix is not identical for all chat models. [6] |
| MAI transcription Preview | mai-transcribe currently aliases mai-transcribe-2; mai-transcribe-2-streaming is a separate streaming choice. | Streaming produces intermediate and final text while audio arrives. Test accuracy and turn latency separately. Voice Live's current guide documents the model IDs; native agent configuration exposure must be verified. Streaming has narrower regional availability than the non-streaming option. [6] [11] [12] |
| Azure speech output | Standard neural voices, HD voices, and eligible custom voices; compatible realtime models can use Azure TTS output. | Choose the locale, pronunciation, speed, persona, and latency appropriate to the workflow. Broad Speech coverage does not imply every HD or custom voice works in every configuration. [5] [6] |
| MAI synthesis Preview | MAI-Voice-2.1-FlashMAI-Voice-2.1 | Flash targets low-latency interactive speech; the non-Flash model emphasizes expressive, high-fidelity, long-form output. Current documentation lists 23 languages and gated, consented voice cloning. Voice Live integration is explicitly documented for Flash; verify the exact voice-agent surface. [10] |
managed uses a supported service-managed model name. self_deployed uses a compatible Foundry deployment name. This is separate from choosing native speech versus a cascaded pipeline.
Self-deployed does not mean the customer must host the voice agent. Reusing PTUs for the model also does not reserve the rest of the speech pipeline's capacity. [4]
Compare a supported full realtime model with a mini realtime option. Add a text-model pipeline using the customer's existing agent/model if it is already working well.
Keep prompts, tools, audio, scenario, and concurrency consistent. Score structured-record accuracy and confirmation behavior alongside time to first audio and cost per completed task.
These are logical patterns, not deployment templates or a statement that every component is supported in every network mode. Choose a pattern to discuss who owns the conversation and where enforcement belongs.
The native agent owns the managed voice orchestration. A client-side function still needs client implementation. Service-side tools use the supported MCP/toolbox path. Phone channels need provider setup, permissions, and a selected release version. [4] [8]
Useful when the demo already meets the business need. Instrument voice-specific stages separately; text-model traces alone do not explain audio and turn-detection delays. A native voice-agent evaluation can run alongside this path rather than replacing it immediately. [3]
Suitable for custom real-time interaction, but your application owns more lifecycle and integration work. Voice Live documents WebSocket and WebRTC paths; confirm the transport supported by the specific native agent or direct API surface rather than treating them as interchangeable. [6]
Enforcement boundary: the prompt guides behavior; the API and destination enforce identity, authorization, schema, confirmation, and irreversible writes. A spoken instruction such as "save this" must not bypass those controls.
Illustrative thin vertical slice: capture a natural response, understand which topics are already covered, ask only necessary questions, and produce an approved structured record. This is a design recommendation, not an out-of-the-box survey product.
No customer data or live model call is embedded in this guide. The dialogue is an authored test scenario.
Let users cover several themes before imposing a form-like sequence.
Track covered fields, unanswered questions, contradictions, and user corrections.
Validate fields, ranges, required values, and provenance at an API boundary.
Let the user correct the interpretation in voice or text. Do not infer approval from silence.
Bind confirmation to the current draft and authenticated user. Use an idempotency key to prevent duplicate saves.
{
"schemaVersion": "1.0",
"draftId": "example-draft-001",
"collaborationScore": 3,
"themes": [
"review delays",
"ownership",
"onboarding"
],
"recommendation": "One accountable final reviewer",
"status": "awaiting_user_confirmation"
}A schema-shaped model response is still untrusted input. The backend should verify score range, allowed fields, record ownership, and the confirmation state before writing.
Derive user identity and audit metadata from trusted server context, not from spoken names or model-supplied JSON. A failed write must remain a failure; the agent must not announce that the record was saved.
Next reuse targets: client-preparation notes, coaching feedback, knowledge lookup, and later CRM or time-entry drafts, once the core capture-and-confirm pattern is proven.
A playground success is not the same as a browser experience, phone channel, Teams app, or production release. Define the destination before diagnosing the blocker. The current voice-specific Channels experience is not identical to text-agent publishing. [7]
Build and test with a microphone, transcript, and optional avatar. Proves a conversational path, not end-user distribution or production readiness.
The voice Channels tab can expose a browser preview when the endpoint supports the Responses protocol. Grant intended organizational users access and test with their accounts. A link is not authorization.
Teams Phone extensibility uses Azure Communication Services; Twilio uses a provider connection. Number ownership, licensing, identity, and inbound/outbound configuration still matter.
Build the web/mobile UX, authentication, session lifecycle, error handling, and deployment wrapper. Verify the supported native voice media path rather than assuming generic Agent Application guidance applies.
Teams Phone is not Teams app publishing. Connecting a Teams-owned number routes a telephone call through the supported telephony integration. It does not publish a conversational voice app into Teams or Microsoft 365 Copilot. The standard Teams/M365 publishing card is intentionally absent from the current voice Channels layout. [7]
User-perceived latency includes end-of-turn detection, recognition where applicable, model inference, retrieval/tools, synthesis, networking, and playback. Some stages stream or overlap, so adding stage timings is only a diagnostic approximation. Time to first audio is the customer-facing metric. [4] [9]
Connect the project's Application Insights and inspect the conversation/turn waterfall: VAD, speech-to-text where used, model calls, tool calls, and speech output. Voice traces use the common Foundry observability stack.
Review median and tail time to first audio, interrupted turns, tool errors, throttling, and completed-task rates. A fast model cannot hide a slow CRM API. [9]
Conversation persistence is off by default. In the current voice definition, store: true persists the transcript, event timeline, and raw audio together; it is not a transcript-only switch.
Trace content capture is a separate setting. Apply notice, consent, retention, access, and download controls to both. Prefer approved structured records if raw audio is not needed. [4] [9]
Separate the caller's identity, agent identity, tool identity, and human trace-reader permissions. Authorize every data operation and verify whether a tool acts as a user or an application.
A resource region does not prove all processing stays there. LLM inference, recognition, and HD synthesis can have different scopes. [7] [12]
Safety versus latency is an explicit trade-off. Asynchronous output filtering can reduce text buffering in supported configurations, but speech may be heard before a delayed policy signal arrives. Spoken content cannot be retracted. Keep required controls enabled; choose synchronous moderation if policy requires checks before any content is heard. [4]
| Area | Test | Proposed evidence / gate |
|---|---|---|
| Natural capture | 20 scripted and paraphrased survey conversations, including long pauses and multiple themes. | At least 95% agreement with human-labeled required fields; report sample size and failure types. |
| Corrections | Change a rating, negate a recommendation, interrupt a read-back, and resume. | All correction cases update the draft; no stale values survive into the confirmed record. |
| Write safety | Refuse confirmation, repeat save requests, retry after a network failure, and attempt an unauthorized write. | Zero unconfirmed, duplicate, or unauthorized writes in the test pack; failures are explicitly reported. |
| Latency | Measure no-tool and tool-assisted turns independently at expected load. | Suggested starting goal: no-tool p50 time to first audio ≤1.5 s and p95 ≤3 s, measured from end of user speech. Negotiate by channel; no product SLA implied. |
| Interruption | Speak during agent playback on browser and selected phone path. | Measure time to stop audible playback; suggested p95 ≤500 ms. No overlapping stale answer resumes incorrectly. |
| Security / operations | Use a recipient identity, revoked access, failed tools, and opted-out recording. | Access denied where expected; no secrets in client; retention behavior verified; traces explain failures without unnecessary sensitive content. |
| Load / economics | Run at agreed concurrent-session load and record input, output, tools, and retries. | Report p95 latency, throttles, task success, and cost per approved record; choose a capacity and spend ceiling before expansion. |
Direct Voice Live's Pro / Standard / Lite classification follows the model choice. Native-agent managed versus self-deployed billing needs its own validation; do not assume every path has the same meter. [3] [5]
Regional pricing, agreements, model versions, talking ratios, output length, provider minutes, and tool calls change the total. Use actual pilot telemetry and the current pricing pages rather than a universal per-minute estimate.
Business metric: total measured pilot consumption divided by successfully approved records. Compare quality at that cost, not merely the price of one model token.
The supplied session, Voice Agents Upgraded: New Speech Models and Agent Experience In Foundry, is a useful conversation starter. The link begins at 56:48; that is the user-provided playback offset, not a verified chapter boundary.
The video's transcript could not be retrieved. YouTube page/caption access and alternate public transcript routes did not yield usable captions. No transcript quotes, guest-speaker attributions, or chapter timestamps have been invented. Product claims are independently grounded in Microsoft documentation.
The official Model Mondays repository lists an October 12, 2026 speech-model session, Season 4 / Episode 9, hosted by Gustavo Cordido. Its written overview covers speech capabilities and responsive voice agents; it is supporting context, not a replacement for the video's captions. [17]
Current documentation can describe capabilities added after a recording. Newer model entries in this guide are labeled as current catalog examples rather than attributed to the episode.
Explore the documented MAI transcription and synthesis families separately. Streaming transcription is not speech-to-speech reasoning; Flash synthesis is not an agent model. Verify availability at the intended integration surface. [10] [11]
The current quickstart covers voice interaction mode, model selection, audio settings, tools, knowledge, and browser testing. A saved voice agent can be developed through portal or supported SDK/CLI workflows. [2]
Follow up with native voice-pipeline tracing, the voice-specific Channels documentation, and migration guidance. These details decide whether a preview meets the customer's deployment needs. [3] [7] [9]
Suggested opening: Let us see what is working, identify precisely what is blocking sharing or release, and compare that with the new native voice-agent path. We should leave with one pilot, a clear architecture choice, and owners for the remaining validations.
Optional in-page meeting aid. Checkmarks stay only in this open page; no data is saved or sent.
0 of 8 decisions checked.
Official Microsoft documentation is the authority for product behavior. Recommendations, example dialogue, architecture sketches, and pilot targets are illustrative, independently authored guidance, not customer deployment evidence.
Research boundary: checked October 16, 2026 against the public pages linked above. No Azure tenant, subscription, model capacity, pricing agreement, or customer deployment was inspected. Availability and preview terms can change. Use this guide for the discussion, then validate the selected combination in the intended project.