AI-901 lesson 6: Foundry first steps

Microsoft Foundry is Microsoft’s platform for building AI applications and agents, and everything in the implementation domain of AI-901 starts here. Work is organised in projects. A project gives access to a catalog of models, and a model only becomes usable after it is deployed, which creates a named endpoint that both the portal playground and application code can call. Older material calls the same platform Azure AI Foundry or Azure AI Studio, and “Azure AI services” became Foundry Tools, so expect those names in search results.

Projects, the catalog and deployments

The figure above shows the objects in the order they are met. A project is the working space for one solution: it holds the agents, files and evaluations for that app, works with the model deployments and connections of its resource, and has its own project endpoint, a web address that client code connects to. Projects live under a Foundry resource, the top-level Azure resource where governance such as networking, security and model deployments is managed. Those settings are therefore managed once for all projects inside it.

The model catalog is the browsable list of models, from Microsoft, OpenAI, Meta and other providers, and a very large number of entries. It answers “which model fits?” by capability, such as text only or multimodal, size and cost.

A deployment is what makes a catalog model callable. Deploying creates an endpoint with a name, a deployment type and capacity settings. The name matters because client code asks for the deployment name rather than the abstract model.

Choosing a deployment type

Deployment types decide where data is processed and how it is billed. Global types may process prompts in any Azure region, data zone types keep processing inside the US, EU or Asia Pacific zone, and standard types stay inside one Azure geography. Standard pay-per-token billing suits uneven traffic, provisioned types reserve throughput for steady high volume, and batch types handle large jobs that can wait up to a day at a discount. The documentation suggests Global Standard as the default starting point and moving to another type only for a specific reason such as residency or guaranteed throughput. Not every model supports every type.

Worked example: a help assistant for a small firm

A 200-person engineering firm wants an internal assistant that answers questions about its travel policy. An admin follows this order:

1. Create a project in Foundry, or use an existing one, so the work has its own endpoint and access rules.
2. Open the model catalog and pick a text-capable chat model. A small model is enough because the task is simple.
3. Deploy it. The admin accepts the default Global Standard type, because the firm has no residency rule and traffic is light.
4. Land in the playground for that deployment, write a system prompt (“answer only about travel policy, in plain language”), and chat. Parameters such as temperature can be adjusted here, and the playground can compare up to three models side by side.
5. When the behaviour is right, build the chat client. The playground can show equivalent code for the deployment.

Nothing was coded until step 5: the portal is the cheap place to experiment.

What the lightweight chat client does

Learn the sequence, not the syntax. The application creates a client for the project endpoint and signs in with a Microsoft Entra identity, the recommended route, although API keys are also supported on some endpoints. From that connection it obtains a client for calling models. For each turn it sends a list of messages, usually a system message first and then the user message, and names the deployment to use. The reply contains generated text that the app reads and shows. In Python the whole sequence is only a few lines, shown here as an illustration (the endpoint and deployment name are placeholders):

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(endpoint="<project-endpoint>", credential=DefaultAzureCredential())
openai = project.get_openai_client()
response = openai.responses.create(model="<deployment-name>", input="Summarise our travel policy.")
print(response.output_text)

SDK method names change between versions, and the exam tests the steps, not the exact names. To keep a conversation going, the app sends the earlier messages again, because the model itself does not remember anything between calls.

Easy to confuse

• Model vs deployment. The model is the catalog entry. The deployment is the callable instance with a name and settings. Applications call deployments.
• Catalog vs playground. The catalog is for choosing, the playground for trying a deployed model.
• Project vs resource. The project is the workspace for one solution. The resource is the Azure object that hosts projects and holds shared governance.

Key points

• Foundry organises work in projects, each with an endpoint, under a Foundry resource.
• The model catalog is for choosing, and a deployment is what a playground or app actually calls.
• Deployment type sets data processing location and billing, with Global Standard as the usual default.
• Deploy, try it in the playground, refine the system prompt, then build the client.
• A chat client connects to the project endpoint, sends system and user messages to a named deployment, and reads the reply.

Check yourself

This lesson opens the implementation domain, which carries 55-60% of AI-901, and builds on the Foundry implementation recap. The topic page Copilot vs Copilot Studio vs Foundry shows where Foundry sits among Microsoft’s AI products.