Choose the work before choosing an AI product
A useful Azure AI design starts with a verb: classify, extract, transcribe, summarize, generate, recognize, or take an action. That verb tells you more than a request to “add AI.” In the current Microsoft AI-901 skills guide, candidates must recognize common workloads and select suitable model capabilities. The point is not to memorize every name in Microsoft’s changing catalog. It is to know which kind of input a solution receives, what output is required, and whether success can be checked against a known reference.
Imagine three requests from the same company. Its customer-care team wants a summary of long messages. Its finance team wants totals and vendor names from invoices. Its warehouse team wants a worker to ask a spoken question and hear a reply. Summarization, document information extraction, and speech interaction are different workloads. A general chat model may participate in more than one, but that does not mean the same deployment, prompt or evaluation is suitable for all. A team should define measurable acceptance conditions first: factual fidelity for summaries, field precision for invoices, and transcription accuracy plus latency for the spoken workflow.
An AI-901 scenario often hides its key decision in the business need. “A manager wants to know whether a review is positive or negative” points toward sentiment analysis; “a team wants the amount and date from a scan” points toward structured extraction; “an editor wants a new product illustration” points toward image generation. Focus on the relationship between problem and capability, then consider service constraints such as region, permission, modality, language and operational risk.
Understand what a generative model does—and does not do
A generative language model produces outputs conditioned on input and patterns learned during training. At a basic level, text is represented as tokens and the model generates a response through predictions over possible continuations. This does not make its claims authoritative. The same model may produce a clear correct explanation in one setting and an invented reference in another. It can help draft, summarize, transform and reason over supplied material, but its usefulness depends on evidence, task framing, evaluation and boundaries.
The model is not the application. A real application decides what data a user may submit, which deployment is called, what context is provided, whether a tool is permitted, how errors are displayed and when a result can be acted upon. For example, a model can propose a draft purchase order, while a separate authorized workflow must validate the line items and decide whether to submit it. A prompt that asks the model to “never make a mistake” is not a control for financial authorization.
A foundation model may support text, image, audio or a combination of modalities, depending on the deployed capability. A text-only deployment should not be treated as a vision model. A visual model that explains an uploaded photograph is not necessarily the service that generates a new image. A model that drafts an invoice summary is not automatically the best option for exact column-level extraction. That distinction matters when selecting a capability rather than trying to force every task through the same chat interface.
Match workload families to outputs and evidence
For text workloads, consider what the caller expects to receive. Keyword extraction finds salient phrases, entity recognition identifies references such as organizations and dates, sentiment analysis categorizes expressed opinion, and summarization compresses a longer document. These may be powered by different service options or model workflows, but their outputs should not be conflated. A sentiment label is not a complete customer explanation. A summary can be fluent yet omit a mandatory condition. An entity can be identified correctly while its relationship to a date is misunderstood.
For speech workloads, distinguish recognition from synthesis. Speech to text transforms an audio recording into text; text to speech produces spoken audio from written content. A voice-enabled chat application may also use a multimodal model to respond to spoken input. When the requirement is a compliant transcript, you must assess recognition quality, timestamps, language and privacy—not just whether a chatbot seems conversational. For vision, image classification groups images, detection locates objects, OCR reads text, multimodal interpretation answers questions about image content, and image-generation models create new visuals. A requirement for an exact serial number in a picture is not interchangeable with one for a marketing illustration.
Information extraction spans multiple modalities. A scanned form may need labeled fields and their values, an audio interview may need speaker turns and structured facts, and a video may require events summarized over time. Azure Content Understanding in Foundry Tools provides analyzers for structured results from documents, images, audio and video. The system designer must still decide which fields are required, how uncertain values are represented and when a human verifies sensitive extracted information.
Select a model by capability, not just by size or popularity
A model-selection question includes capabilities, economics, risk and available infrastructure. First ask whether it accepts the required input and emits the required output. Then ask whether the available language and region are supported, what latency is tolerable, what context the task needs, and what mistakes would cost. A small focused text model may be sufficient to classify non-sensitive support tickets. A multimodal model may be required to interpret photographs. A generative image model is appropriate for creating artwork rather than validating exact values on a form.
Model capability also needs to be separated from the business workflow. Suppose one model produces excellent long explanations but tends to invent invoice totals. The decision is not necessarily to turn its sampling temperature down and trust it. Structured field extraction and deterministic validation may be better suited to the task. Conversely, an exact rules engine may not be appropriate for a creative brainstorming assistant whose outputs have no external side effect. Select the simplest capability that meets the evidence and user-experience requirements; sophistication is not itself a success metric.
When evaluating candidate models, define a representative test set before declaring a winner. For the support classifier, include terse messages, ambiguous topics, multiple languages and complaints mixed with requests. For a document extractor, vary scan quality, page layouts, currency notation and missing fields. Inspect the actual error types, not only aggregate percentages. A model can appear accurate when the test set contains easy examples but fail on the cases the user most needs help with.
Recognize deployment and configuration choices
A model needs to be available to an application through a deployment or appropriate hosted endpoint. The important distinctions for AI-901 are the model identity, deployment identity, endpoint, authentication and runtime configuration. A project and deployment are not the same object: a project organizes development resources and connections, while the deployment identifies a model-backed endpoint available for invocation. Published examples use the Foundry project endpoint or, for certain model APIs, an OpenAI-compatible endpoint. Which interface is appropriate depends on the scenario, model and SDK version.
Configuration parameters affect generated responses. Maximum output length sets an upper bound on how much the model may return. Sampling-related settings can change variation in generated text, but they do not turn a model into a verified database or make every answer factual. Tool configuration determines what external operations are available when the architecture supports tools; separate application permissions determine whether those operations may be executed. Increasing context size can help the model see more material, yet can also increase cost and introduce irrelevant or untrusted instructions.
Cloud choices have temporal boundaries. Model families, available regions, deployment tiers, quotas and prices change. A public article should explain the factors behind selecting a deployment without promising that one named model exists for all readers in all Azure subscriptions. Microsoft’s material on Foundry SDKs and endpoints distinguishes a project client for Foundry-specific functionality from an OpenAI-compatible client for certain model APIs. The detailed deployment and identity considerations belong to deeper engineering study, such as Foundry project security and deployment; AI-901 requires the basic decision model.
Know when a prompt, retrieval, or agent changes the task
Not every generated response needs an agent. If a caller asks for a two-paragraph explanation using a supplied policy document, a model call with a well-bounded instruction may be enough. If the system must fetch a current document from an authorized source before answering, retrieval adds an evidence-acquisition step. If it must decide which tool to use, request additional information, and execute a multi-step goal, an agent becomes more relevant. These are different interaction patterns, and each adds failure modes that do not disappear just because the model is capable.
Retrieval helps with access to current or task-specific facts but does not prove that the model interpreted those facts correctly. Good grounding keeps track of which source supports which claim, separates documents from instructions, and defines a response when no adequate evidence is found. Tool use adds another boundary: the agent may request an operation, while the application must check whether the user and agent are authorized to perform it. A planning document that says “send the customer a credit” does not give the model permission to trigger a payment.
For an entry-level design, sketch the flow. A direct model call receives a prompt and returns text. A retrieval-assisted call first locates authorized relevant material, then sends the prompt plus material. An agent loops through reasoning and tool outputs under defined limits. Use a different evaluation for each: factual quality for the direct answer, retrieval relevance and citation fidelity for grounded answers, and safe tool choices plus outcome correctness for agents. This makes “agentic AI” more than a fashionable synonym for a chatbot.
Practice choosing a solution under real constraints
Consider a nonprofit with three limited-budget projects. It wants to route volunteer email, extract donation amounts from scanned forms, and provide spoken directions at an event. The email router needs reliable categories and clear escalation for ambiguous requests; text analysis or a small classification workflow may be enough. The donation-form project needs document extraction with field validation and appropriate privacy controls. The directions app requires speech input and response synthesis, potentially using a text model for answering but still relying on audio-capable components. Choosing one giant chatbot for all three may increase complexity without improving results.
Now add constraints: the nonprofit works in several languages, cannot transmit certain donor data outside permitted environments, and must show staff why a donation was rejected. Those constraints change the ranking of candidate services. Language support, region availability, transparency, human review, model limits and access controls must be evaluated before declaring a model appropriate. A cheaper deployment that ignores the required data boundary is not acceptable; a highly capable model that cannot deliver a sufficiently reliable structured field may also be the wrong choice.
A useful self-test is to explain any recommendation in five parts: the problem, the input, the output, the selected capability and how an error will be detected. If you cannot say what would make the solution wrong, you have probably chosen a product name without enough understanding of the workload. AI-901’s concepts domain is preparation for exactly this kind of judgment; its practical Foundry domain then asks you to recognize how a small version of that solution is implemented.