A voice-agent demo can answer a question. A production service must also handle interruptions, tools, latency, evaluation, and failed calls. Microsoft’s new Foundry voice agents target that second problem.
The September 24 announcement
Microsoft introduced voice agents in Foundry Agent Service as a voice-native application path. It combines real-time speech with agent instructions, knowledge, tools, deployment workflows, traces and evaluations. Microsoft says developers can choose speech models from Microsoft, Azure, and other providers, rather than being locked into a single text-to-speech and speech-to-text pairing.
Microsoft describes sub-second latency and multilingual support, but those are platform claims, not a guarantee for every deployment. A call’s actual delay also includes network conditions, model choice, retrieval, and tool execution. Teams should measure full turn-taking time in their own target channel, not only the first audio token in a playground.
Three paths, different ownership
The announcement distinguishes a real-time voice runtime, speech attached to an existing agent, and the new voice-native Foundry agent. The third path puts more of the development-to-operations lifecycle in Foundry. That is useful if a support team wants one place to inspect a transcript, a tool call, and a failed evaluation. It is less compelling if the organization already has a mature custom audio stack and only needs speech input and output. The Foundry A2A guide covers a separate, text-only agent-to-agent route that should not be mistaken for a voice channel.
Microsoft also describes out-of-the-box talking-head avatars and paths to custom voices and avatars. These are optional presentation layers. For a customer-support pilot, reliable interruption handling and the correct business action should take priority over a face on screen.
What to measure before a launch
Voice changes an agent’s failure modes. Recognition can miss a name or date; a caller can interrupt mid-answer; a tool can finish after the conversation has moved on. Foundry records conversations as traces and applies its evaluation framework. Microsoft says rubric evaluators can score task-specific criteria, such as whether a reservation agent confirmed the date and party size or refused an oversized booking.
A useful pilot therefore needs at least four measures: end-to-end response time, speech-recognition corrections, task completion under interruptions, and rule violations. Review failed traces with access controls in place. Microsoft warns that traces can include sensitive prompt, response, and tool content; do not turn on rich logging without a retention and access decision.
How developers can start
Microsoft’s documented path is to create a new agent in the Foundry portal, select Voice, choose a voice-optimized model, connect knowledge and tools, test in the voice playground, then deploy and monitor. The announcement also describes an AZD AI workflow for source-controlled definitions and deployment. Microsoft says Foundry Toolkit support in Visual Studio Code is coming soon, so it isn’t generally available today.
Where it fits
Foundry voice agents make the most sense when a team needs a repeatable operating loop, not merely a talking interface. Start with a narrow, read-only task and a clear escalation to a person. Add actions such as bookings or account changes only after the team has evidence that the agent hears correctly, follows the rules, and leaves an inspectable trace when it does not. The agent cost-controls guide provides a separate budget test for the model and tool calls behind each completed conversation.
