Build a document-grounded AI prototype in Microsoft Foundry
Use the portal to create an agent, attach a small test document, and examine its answers. A playground prototype is a useful exercise; a public application needs additional engineering.
A document-grounded assistant retrieves material from an approved source before answering. The learning goal here is to build and evaluate that behavior in Microsoft Foundry's portal. There is no one-hour completion promise, and this is not a claim that a public web application can be deployed without an authentication or hosting design.
One small agent, one non-sensitive document, a recorded set of test questions, observed answers, and a resource-cleanup record. Describe it as a portal prototype unless you have separately built and tested an application that users can access.
Check the portal and the cost before starting
Microsoft's current quickstart has a Foundry portal path for creating and testing an agent. Use the documentation for the portal version you see; Foundry and Foundry (classic) have different workflows and APIs. Do not combine steps from an old classic tutorial with a new project and assume they are interchangeable.
You need an appropriate Azure subscription, a Foundry project, permission to use it, and an available model. Region, quota, role assignments, and organization policy can affect what you can create. If a feature is missing, first check those prerequisites and the current guide rather than repeatedly creating resources.
Model usage is metered. File search has additional charges beyond model tokens, and the selected setup can involve storage and search resources. Inspect the resources created by the setup and their current prices. Set an affordable test scope and a finish time; free course access does not make Azure model calls free.
Step 1: prepare a document with testable facts
Create a short fictional policy document. For example, it can state that a fictional help desk accepts requests during specified hours and that a certain procedure needs approval. Label it as test data. Do not upload customer records, credentials, or confidential employer material into a personal learning project.
Keep an expected-answer sheet outside the document. Include questions the document answers, questions it does not answer, and questions that try to make the assistant ignore its instructions. A model producing fluent text is not enough; you need to know what a correct answer looks like.
Step 2: create an agent in the current portal
Follow the portal tab in the current quickstart. After selecting a supported model, use the Build section's Agents view to create the agent. Give it a purpose and clear instructions: use the approved document, identify uncertainty, and say when the document does not contain an answer.
Test a simple interaction before adding retrieval. Record the project, model deployment, and agent identity in your private lab notes. These are configuration records, not secrets to paste into a public screenshot. If you encounter a quota or permission error, capture the error text without sensitive values and resolve that prerequisite first.
Step 3: attach file search to the document
The file-search workflow requires an uploaded file, a vector store, completed ingestion, and a file-search tool attached to the agent. Current guidance recommends adding the tool through a toolbox. The portal requires the vector-store ID when configuring File Search. Follow the linked file-search and toolbox guidance for your current project experience.
Wait for processing to complete before asking questions. Confirm that the selected store contains the intended file and that the agent references the correct tool. If the portal lacks the required setup path, use the supported documented workflow or stop at the basic agent exercise; do not present a guessed sequence of clicks as a tested deployment.
Step 4: evaluate the answers
| Test | Expected behavior | What to record |
|---|---|---|
| Ask for a fact explicitly present | Answer agrees with the source | Answer, source reference where available, and any discrepancy |
| Ask for a fact absent from the document | Identify the missing information | Whether it invents a policy or admits the gap |
| Paraphrase the first question | Preserve the meaning and answer | Any contradiction between equivalent questions |
| Ask it to ignore the document | Keep the intended task boundary | Whether the response follows the instruction or departs from it |
| Change a documented fact and retest | Use the intended current content | Which file/store version was attached and what answer was returned |
Repeat important questions and examine inconsistent answers. A citation-looking label is not proof that the claim matches the document. Compare the text yourself. Record failures as well as successes; they are useful evidence of what you understand about the system.
A passing small test set does not establish general safety or accuracy. It supports a limited claim about the examples you ran. Explain the test document, model, configuration, date, and limitations when sharing the project.
Step 5: clean up the full resource inventory
Follow the cleanup instructions for the workflow you chose. Review the agent, uploaded files, vector store, toolbox or connections, model deployment, project, and any associated storage or search resources. Removing an agent alone does not prove every billable dependency was removed.
Save non-sensitive evaluation notes before deleting lab resources. Avoid deleting shared resources used by other projects. Check billing after usage reporting has caught up and distinguish an observed charge from an estimate.
What changes before this becomes an application?
A public or staff-facing application needs a frontend, a trusted backend, user authentication, access controls, secret handling, usage limits, monitoring, and a recovery procedure. Do not embed privileged service credentials in browser code. A Logic App can participate in a workflow, but naming it does not provide a complete secure chat interface.
For a portfolio, an honest description is: “Built a document-grounded portal prototype and evaluated source-supported, missing-information, and instruction-conflict questions.” Add an application-deployment claim only after you have done that additional work. Continue with Class 33 for the concepts and Class 34 for deployment concerns.
Common questions
Is this a no-code public chatbot deployment?
No. It is a portal-based prototype and evaluation exercise. An application requires additional hosting, authentication, and operational work.
Are document-grounded answers guaranteed correct?
No. Check answers against the source, test missing information and instruction conflicts, and record failures.
Can the exercise incur Azure charges?
Yes. Inspect model, file-search, storage, search, and other created resources, then follow the cleanup instructions for your configuration.
Sources and review
Reviewed 1 October 2026. This is a documentation-reviewed prototype checklist, not a reproduced one-hour deployment or measured cost report. Portal capabilities and labels should be confirmed against the current linked guides.
- Current Foundry quickstart — portal tab
- Foundry file-search workflow and charges
- Create and manage a Foundry toolbox
Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.