A multilingual service desk is a useful test of whether an AI application really works. A caller asks a question in Spanish, mentions a product code in English, and describes a delivery problem. The system must recognize the speech, identify the product, understand the complaint, consult a controlled knowledge source, produce a reliable response, and perhaps speak the answer aloud. Each step has a different failure mode. A flawless transcript can still lead to a wrong customer record; a good answer can become unusable through mistranslation or slow audio generation.

That is the practical meaning of the text analysis domain in Microsoft AI-103. Microsoft’s April 16, 2026 skills guide assigns 10–15% to text analysis and includes entity and topic extraction, sentiment and safety detection, structured outputs, translation, speech-to-text, text-to-speech, custom speech, and audio interaction with agents. The goal is not to memorize every endpoint. It is to choose the appropriate capability, join the stages safely, and measure whether the resulting application satisfies the real task.

Start with the output contract, not a model name

Before selecting a service, separate what the business needs into outputs that can be checked. The service-desk application might need a transcript, customer intent, order identifier, language, a short case summary, a recommended next action, and a spoken response. These should not be collapsed into one unstructured answer. A case-routing tool may require a JSON field named case_type with a defined set of values; the customer-facing reply can be natural language. Different output contracts deserve different validation.

For a structured extraction task, define the expected fields and how missing or ambiguous evidence should appear. A system should be able to say that an order identifier was not found rather than inventing an identifier to satisfy the schema. For sentiment, decide whether the label changes a business process or merely assists triage. A negative sentiment score should not automatically trigger an irreversible account action. For summarization, specify whether the output must cite or reference the underlying transcript, whether it may omit details, and which sensitive data may be exposed.

Specialized Foundry Tools and generative models solve different problems

Microsoft Foundry provides model-based workflows alongside specialized tools for language, translation and speech. The appropriate choice depends on the required behavior. If a workflow needs controlled text translation across known language pairs, a specialized Translator capability may reduce the need to engineer an entire prompt-based translation contract. A generative model may be useful when translation must occur as part of a broader reasoning task or when one response combines language understanding with retrieval and explanation. Neither choice eliminates testing for terminology, omissions and data-handling rules.

Entity extraction presents a similar distinction. A narrowly defined task with predictable inputs may benefit from a specialized extraction capability. A varied request that mixes intent classification, explanations and structured fields might be handled by a model instructed to return validated JSON. The critical engineering work lies outside the choice of tool: checking schema adherence, handling uncertain evidence, testing realistic inputs, and deciding what downstream systems are allowed to do with the result.

Compare architectures rather than assuming a larger model will always perform better. One pipeline may use speech recognition, a language-specific entity step and a compact text model for the answer. Another may send a transcript to a multimodal or generative model with explicit instructions and tools. The second pipeline can reduce the number of service calls, yet it might be harder to audit individual extraction errors or enforce deterministic field types. Pilot both with the same representative cases and measure correctness, latency, cost and safety before selecting the design.

Prepare the input before asking the model to interpret it

Real text includes typing errors, acronyms, timestamps, multilingual fragments, emoji, product identifiers and quoted messages. Over-aggressive cleanup destroys evidence. Normalize whitespace or encoding when required, but retain a copy or reference of the original message and preserve codes exactly. If the text comes from a scanned image, identify that upstream extraction step; a language model cannot recover a number that OCR silently dropped without additional evidence.

Language detection can help choose a translation or speech route, but very short utterances are ambiguous. “OK”, a surname and a product identifier may not provide enough language evidence. The system should consider the user’s selected locale, prior interaction context and confidence signals without pretending any one is certain. When the language cannot be determined reliably, ask a concise clarification or choose a safe fallback rather than forcing a possibly wrong transcript into a consequential workflow.

Keep provenance through the chain. For the service-desk case, store an authorized reference to the audio or transcript, the recognized language, the source spans supporting extracted fields, a transformation history and the model or tool version. Respect retention and privacy policies: preserving every raw audio file forever is not a default requirement. The retention choice must follow the application’s legal, security and operational need.

Speech-to-text: live conversation and recorded media need different paths

Speech recognition is not one universal operation. A live assistance interface values partial results and short response times. A recorded support call may instead prioritize batch throughput, accurate long-form transcription, timestamps and speaker separation where supported. A short voice command might benefit from a narrow vocabulary or contextual hints. Start by asking whether the experience is interactive, whether audio arrives continuously, which locales are expected, and how errors will be reviewed.

Azure Speech in Foundry Tools supports different recognition workflows, and Microsoft also documents batch and fast transcription through its current Speech-to-text REST API. The application should use a supported SDK or API for its actual workload and region rather than hard-coding an old endpoint seen in a course. Test with noisy audio, interruptions, accents, overlapping speakers and domain terms. An apparently high transcription score on clean studio recordings does not establish readiness for field recordings.

For the multilingual desk, a transcript should carry enough timing or speaker context to distinguish the caller’s statement from the agent’s reply. An extracted sentence such as “I will approve the refund” changes meaning entirely if attributed to the wrong speaker. If diarization or attribution is uncertain, make the uncertainty visible to the reviewer. A downstream ticketing tool must not treat ambiguous speech as confirmed approval.

Translate without destroying operational meaning

Translation quality is especially important for serial numbers, medication names, legal terms, dates and amounts. A practical application should maintain a protected vocabulary or post-validation rules for sensitive identifiers. If a translated amount changes currency, decimal notation or unit, the output may look linguistically fluent while becoming operationally wrong. Measure critical-field preservation as a separate metric from general naturalness.

A voice translation experience adds more stages: recognition in the source language, translation or multilingual generation, then speech synthesis in the target language. Latency accumulates across stages. You can reduce it by streaming supported partials, routing simpler requests through specialized tools, caching authorized static content and avoiding unnecessary repeated calls. But streaming partial translations can also revise previously inferred meaning; do not immediately commit irreversible actions based on an incomplete utterance.

Consider a caller who begins “Do not cancel…” and pauses before completing the sentence. If a system acts on a partial transcription as though “cancel” were a final command, speed has beaten safety. Tool actions should operate on validated intent, not raw recognized keywords. This is a fundamental distinction between conversational assistance and business automation.

Text-to-speech: the voice is part of the interface

Text-to-speech is useful for hands-free support, accessibility, spoken navigation and agent replies. Choose a voice and output format compatible with the intended device, language, accessibility expectations and latency budget. Short status feedback should not wait for a long, decorative generated response. Longer passages may benefit from an appropriate batch synthesis approach when they do not need to be interactive.

Pronunciation can be critical. Product identifiers, acronyms and personal names often need explicit handling. Microsoft’s Speech documentation describes options such as supported voices and speech synthesis markup for controlling aspects of pronunciation and delivery. The team should test representative terminology rather than assume that natural-sounding general speech preserves every domain-specific name.

Voice customization also brings consent and governance considerations. Do not create a voice resembling a real individual without an appropriate authorization and policy basis. An agent should identify its automated nature when the interaction context requires it, and downstream consumers should not be led to believe an AI-produced voice recording is an independently verified human statement.

Attach speech to an agent without granting the transcript authority

In a Foundry agent workflow, speech can be one input modality and one output modality. The agent may retrieve policy information, summarize a case or call an authorized ticketing function. The transcript is still user-supplied content and may contain malicious or mistaken instructions. Separate conversational intent from permission to use tools: the fact that a caller says “delete the account” does not mean the agent may perform an account deletion.

Define each tool’s allowed parameters, the identity that executes it, the resource scope and the operations that require confirmation. Keep the retrieved answer grounded in approved knowledge; evaluate whether it is relevant and current. If the agent cannot determine which customer record is intended, it should request a disambiguating fact rather than guessing a record identifier from a similar name.

An audio-enabled agent also needs sensible interruption behavior. A caller may correct an earlier request while the system is still speaking. The application must decide whether to stop synthesis, discard pending tool requests, preserve a resumable context or restart after a confirmed correction. Those decisions are application state management, not merely speech recognition settings.

A worked example: from support call to validated ticket

Imagine a logistics company supporting callers in English and Spanish. A caller explains that a shipment was delivered to the wrong location and gives an order number. The application needs to create a support ticket but may not authorize a refund. The engineered workflow begins with the permitted audio channel and the caller’s language preference, not with an unqualified request to “summarize this.”

1. Recognize the utterance using a supported speech workflow and capture the source reference, transcript and recognition uncertainty needed for review.
2. Extract the order identifier, delivery problem and requested next action into a validated schema; retain exact identifiers and mark ambiguous evidence as unknown.
3. Translate or normalize the human-facing issue description where necessary while preserving the original message and avoiding changes to coded fields.
4. Use a narrow lookup tool to verify that the referenced order belongs to the authorized caller and retrieve only the minimum information needed for the case.
5. Create the proposed ticket after validation. A refund or address change requires a separate authorization path rather than being inferred from conversational language.
6. Produce a concise customer reply in the chosen language and optionally synthesize it as speech. Record the ticket reference without making unsupported promises.

Now break the workflow safely. Provide a recording where the order number is partly masked by noise; test a code that resembles an ordinary word; ask for an unsupported language; introduce contradictory statements; and submit a transcript containing instructions intended to override the agent’s tool policy. A reliable system should expose uncertainty, ask for missing details, route to a human, or refuse an unauthorized action as appropriate.

Evaluate the entire interaction, not just the transcript

Write acceptance tests for each boundary: recognition accuracy for task-critical terms, field extraction correctness, language selection, translation fidelity, grounded answer quality, safe tool use, end-to-end latency, and a clear user outcome. These measures may disagree. A speech system can produce excellent word-level accuracy while still missing the one identifier needed to complete the task. Conversely, a minor spelling error may be harmless when the business action is unaffected.

Measure failures by language and acoustic condition, not only an average score. If a system works well for English in a quiet office but consistently fails for Spanish in a busy warehouse, the overall metric hides an important reliability and fairness issue. Include speech privacy, consent and retention requirements in the test plan. Track costs by step so a cheaper speech model that causes frequent manual corrections is not incorrectly credited as a better design.

For exam practice, use the existing AI-103 Text Analysis and Translation practice test and AI-103 Speech Interaction practice test after you can explain the service and safety choices. The agent orchestration guide explores the tool boundary, and GenAIOps monitoring extends the evaluation into production. Microsoft’s speech translation and text-to-speech guidance remain the reference for supported features and implementation steps.

The exam-ready skill is to make a defensible end-to-end decision: what input should be trusted, what output must be structured, which capabilities to select, where translation or audio belongs, what the agent is allowed to do, and what evidence proves the user task was completed safely. That is how text and speech stop being feature lists and become reliable Azure AI applications.