A hands-on capstone connects the two Microsoft AI-901 domains: recognize appropriate AI capabilities, then build and evaluate a small implementation using Microsoft Foundry. It should remain simple enough for a beginner to understand every component. A fictional community center help desk provides a useful project because it has short text questions, optional voice notes, a sample flyer image and a mock membership form without requiring access to any real personal information.<\/p>\n
The outcome is not a production service. It is a reproducible demonstration of a selected model, a constrained prompt, a lightweight client, one appropriate modality feature and evidence of how the system behaves on normal and failing inputs. The AI-901 exam outline<\/a> maps this work to the two weighted domains and explains why the current test includes more practical Foundry work than legacy AI-900 preparations.<\/p>\n The community center wants to answer questions about public opening hours, explain registration requirements and help staff prefill a fictional form. It must not create real memberships, access private accounts or promise unavailable services. Define a question-answering test set with ten known answers and five cases where information is missing. For form extraction, define applicant name, selected class and preferred date, then require the user to confirm fields.<\/p>\n A completed lab should demonstrate a correct answer with source information, a clarification response for an ambiguous request, a refusal to invent an unsupported fact and a field-level check on a sample form. This is a better scope than attempting a multi-agent workflow that hides important decisions behind large abstractions.<\/p>\n Use a permitted Azure subscription or a preapproved training environment. Identify the project, selected model, deployment name, endpoint and identity required for the client. Review the model card for text capability and any necessary multimodal support. Remember that a deployed model, a chat application and an agent are separate concepts; an agent is not mandatory for every question-answering interaction.<\/p>\n Follow the current Foundry deployment lab<\/a> for the resource setup. A small proof of concept can begin with text inference only. If the available environment does not support image or audio input, document that limitation and test those modalities with an appropriate supported tool rather than pretending the same endpoint accepts everything.<\/p>\n A system instruction should explain the fictional community-center role, restrict factual claims to the supplied approved schedule, require concise responses and ask clarifying questions when the center branch or date is missing. A user message contains the actual question. Do not put live passwords, private member records or unrestricted administrative instructions into the model context.<\/p>\n The prompt design and evaluation<\/a> explains the testable difference between system instructions, user requests and retrieved content. Include a deliberate injection attempt inside a quoted flyer passage to confirm that the model is not granted authority to change the application rules. Since this is a demonstration without write tools, the attack should remain incapable of changing any real record.<\/p>\n Create a small Python client using the version of the Foundry SDK or inference API appropriate for the chosen resource. Put the endpoint, deployment and credentials in protected configuration, not directly in source code. Send one question, handle a response and show an intelligible error if a request fails. Record the package and API version used so the experiment can be reproduced after platform documentation changes.<\/p>\n Test a missing environment variable, invalid model deployment name and transient service error if the training environment permits it. Each failure should produce a different diagnosis. Avoid printing credentials or private prompt contents in logs. The Python client explanation<\/a> provides the conceptual call sequence without assuming one SDK syntax remains permanent.<\/p>\n The fictional center may receive a photographed flyer or a short recorded question. If the goal is to read event hours from a photo, choose a supported vision or extraction route. If the goal is to transcribe a voice note, speech recognition is appropriate. Do not add image generation merely because it is available; generating a poster is a separate creative task, not a method for reading the original flyer.<\/p>\n For forms, use a supported document extraction approach<\/a> to propose typed fields and permit correction. For audio, compare transcription with the original speaker’s expected words. For visual questions, ask only what can be seen and note where the image lacks the relevant evidence. The modality component should have its own test set rather than being evaluated only by the final chat answer.<\/p>\n A reusable community-center information agent could have durable instructions and an optional read-only schedule lookup. If the application simply sends a short prompt to a model, a direct client may be simpler. In either case, explain where the authoritative opening hours live and how the system deals with a missing record. A claim that a registration was created must never be based only on natural-language output.<\/p>\nDefine a narrow task and success criteria<\/h2>\n
Choose Foundry resources and model capabilities<\/h2>\n
Write a safe prompt with an uncertainty path<\/h2>\n
Build a lightweight client and check errors<\/h2>\n
Add one modality feature because the task needs it<\/h2>\n
Add an agent only when a bounded task warrants it<\/h2>\n