1 Overview: One Place for the Whole AI Lifecycle

Over the last several tutorials you assembled AI capabilities one at a time: an Azure OpenAI deployment, embeddings, function calling, resilience and logging, a web integration, and a full RAG pipeline. Each was a separate piece you wired together in code. Azure AI Foundry is the platform that brings those pieces into one managed place — a single environment to discover models, test them, connect data, build and evaluate applications, deploy them, and watch them run. Where the earlier tutorials taught the building blocks, this one introduces the workshop they all live in.

This is a mostly conceptual tutorial, aimed from beginner to intermediate. You will learn what Azure AI Foundry is and the problem it solves; how it works, through its hub-and-project structure, model catalog, playgrounds, evaluations, and deployments; when reaching for Foundry pays off versus calling a bare API; how to find your way around the Foundry portal; and — importantly for everything you have already built — exactly where Foundry fits alongside Azure OpenAI, because they are complementary, not competing.

2 Learning Objectives

• Explain what Azure AI Foundry is and the end-to-end AI lifecycle problem it addresses.
• Describe how Azure AI Foundry works: hubs and projects, the model catalog, playgrounds, connections, evaluation, and deployments.
• Decide when to use Azure AI Foundry versus calling a model API directly from code.
• Navigate the Foundry portal to browse models, test in a playground, and manage a project's deployments.
• Explain where Foundry fits alongside Azure OpenAI, and how your existing deployments and code relate to a Foundry project.
• Connect a Foundry project to code with the Azure AI Foundry SDK at a conceptual level.

3 Prerequisites

• The earlier tutorials' concepts: what a model deployment, an embedding, function calling, and a RAG pipeline are.
• Familiarity with Azure OpenAI from tutorials 10–11 — endpoints, deployments, and the model catalog concept.
• Basic Azure portal navigation: subscriptions, resource groups, and creating a resource.
• C# at a reading level for this tutorial's illustrative SDK snippet; no new coding is required to follow along.

4 Key Concepts: The Unified AI Platform

Building a serious AI application touches many concerns: which model, tested how, connected to what data, deployed where, evaluated against what, monitored by whom. Handle each with a separate tool and you get a fragmented workflow and no single view of your app's health. Azure AI Foundry exists to unify that lifecycle — model discovery, prompt testing, data connections, application building, evaluation, deployment, content safety, and tracing — under one platform with one portal and matching SDKs.

Two structural ideas organize all of this. A hub is a top-level resource holding shared settings — security, connections, compute — that multiple projects inherit. A project is a workspace under a hub for one application, containing its models, data, deployments, and evaluations in isolation from other projects. This mirrors how teams actually work: a hub is the shared foundation an organization or team sets up once; projects are the individual apps built on it. Everything else — catalog, playground, evaluation, tracing — operates within that hub-and-project frame.

5 Deep Dive 1: What Azure AI Foundry Is

Azure AI Foundry is Azure's unified platform for building, evaluating, deploying, and managing AI applications. That single sentence carries three claims worth unpacking. First, unified: it deliberately spans the whole lifecycle rather than one slice, so discovery, testing, building, evaluation, deployment, and monitoring share one environment. Second, for applications, not just models: Foundry's unit of work is an AI app — a chatbot, a RAG assistant, an agent — with its models, data connections, and evaluations bundled together, not a bare model endpoint. Third, managed: security, connections, content safety, and observability are provided by the platform instead of assembled by hand.

Concretely, Foundry gives you: a model catalog spanning Azure OpenAI models plus a large selection of open and partner models; playgrounds for no-code experimentation; connections that securely link a project to data and services; prompt flow and app tooling to build multi-step workflows; an evaluation system to measure quality and safety; managed deployments; and responsible AI features like content safety and tracing. It is accessed through the Foundry portal (a web studio) and the Azure AI Foundry SDK (client libraries), so the same project is reachable by clicking or by code.

It helps to contrast Foundry with what you used before. In tutorials 10–11 you worked directly with Azure OpenAI: one service, its models, its deployments. Foundry is a layer above that scope: Azure OpenAI becomes one provider within Foundry's catalog, and around it Foundry adds the multi-model catalog, the lifecycle tooling, and the project structure. If Azure OpenAI is the engine, Foundry is the whole workshop where you choose engines, test builds, and ship vehicles.

6 Deep Dive 2: How Azure AI Foundry Works

Foundry's mechanics follow the lifecycle. You start by creating a hub (the shared foundation) and a project within it (your application's workspace). Inside the project you browse the model catalog and pick a model, deploy it to get a deployment your code and the playground can call, and try it in a playground. You add connections to bring in data — a search index for RAG, a storage account, another service — as secured, reusable links. You build the application logic, optionally with prompt flow for multi-step orchestration. You run evaluations against a test dataset to score quality and safety. And you monitor the running app with tracing.

The hub-and-project split is what makes this work for teams. Set up once at the hub: security and access, shared connections, content safety policy, compute. Then spin up projects under it that inherit those settings, each isolated so one team's app cannot disturb another's. A connection defined at the hub can be shared across projects; models deployed in a project are scoped to it. This is governance built into the structure — a platform team configures the hub, application teams work in projects, and the boundaries are enforced rather than hoped for.

using Azure.AI.Projects;
using Azure.Identity;

// A project has an endpoint/connection string; auth via Managed Identity.
var projectClient = new AIProjectClient(
    new Uri(projectEndpoint),
    new DefaultAzureCredential());

// Resolve a connection (e.g. the project's Azure OpenAI) and call a deployment.
// The point: code uses the PROJECT's configured connections and deployments,
// so endpoints and keys are managed centrally, not scattered in appsettings.
ChatClient chat = projectClient
    .GetAzureOpenAIChatClient(deploymentName: "gpt-4o-mini");

ChatCompletion reply = await chat.CompleteChatAsync(
    new UserChatMessage("Summarize what Azure AI Foundry provides."));
Console.WriteLine(reply.Content[0].Text);

7 Deep Dive 3: When to Use Azure AI Foundry

Foundry is not always the right level of tool, and knowing when it pays off is part of using it well. It shines when your work spans the lifecycle: comparing multiple models before committing, needing no-code playgrounds so non-developers can experiment, requiring evaluation of quality and safety as a gate before release, wiring several data connections, collaborating as a team that needs shared governance, or operating apps that must be traced and monitored. In short, the more of the build-evaluate-deploy-operate cycle you need — and the more people involved — the stronger the case for Foundry.

Conversely, if you only need to send a prompt to one known model from one service in a small script, calling the Azure OpenAI API directly (tutorial 11) is simpler and entirely sufficient; wrapping a one-line call in a full platform is overkill. The honest framing is a spectrum, not a binary: a quick experiment or a single-model production call can stay bare-API; a multi-model, evaluated, team-owned, monitored application benefits from Foundry's structure. Many projects even start bare and adopt Foundry as they grow into evaluation and operations needs.

8 Deep Dive 4: Exploring the Foundry Portal & Fit with Azure OpenAI

The Foundry portal is the web studio that makes all of this tangible. Landmarks you will use most: the model catalog, where you browse and compare models and open a model card; a Deploy action that turns a chosen model into a deployment; the playground (often a chat playground), where you test prompts, set a system message, and chat with a deployment before writing code; a connections area for linking data and services; an evaluations area to run and review scored test runs; and a tracing/monitoring view for a deployed app. All of it sits inside a selected project, with the hub's shared settings behind it.

Now the question that matters most for everything you have already built: where does Foundry fit alongside Azure OpenAI? They are complementary layers, not alternatives. Azure OpenAI is a service that provides specific models (GPT-4o, embeddings) and the deployments you call. Foundry is the platform around and above it: Azure OpenAI appears as one provider in Foundry's catalog, its models are among those you can deploy, and Foundry adds the multi-model catalog, lifecycle tooling, project governance, evaluation, and monitoring on top. You can absolutely keep using Azure OpenAI directly — as tutorials 11–15 did — and reach for Foundry when you want the platform features around it.

9 Ecosystem and Tools

Everything here connects back to earlier tutorials. The model catalog and deployments generalize the Azure OpenAI deployment you created in tutorial 10. Connections are how a project reaches the Azure AI Search index from tutorial 15. Evaluations and tracing are the managed forms of the structured logging and quality concerns from tutorials 13 and 25. Foundry does not introduce a new mental model so much as gather the ones you already have into a coherent, governed platform — which is exactly why the next tutorials on Semantic Kernel and agents sit comfortably on top of it.

10 Use Cases

• Model selection: a team compares several catalog models in playgrounds and evaluations to pick the best quality-per-cost before committing code.
• RAG application lifecycle: build the RAG assistant from tutorial 15 in a project, connect the search index, evaluate groundedness, deploy, and trace it — all in one place.
• Cross-functional experimentation: product managers and analysts test prompts in no-code playgrounds while developers build against the same project.
• Safety gating: run evaluations for groundedness and content safety as a release gate, so an app cannot ship until it clears thresholds.
• Governed enterprise rollout: a platform team configures a hub with security, shared connections, and content safety; app teams build isolated projects under it.
• Multi-model apps: a workflow that uses different models for different steps, orchestrated with prompt flow and monitored together.
• Managed fine-tuning: adapt a base model on curated examples through Foundry's workflow when behavior tuning is genuinely needed.

The pattern across these is coordination at scale: many models, many people, many lifecycle stages, real governance and monitoring. Wherever an AI effort outgrows a single script and a single developer, Foundry's structure earns its place — and the more of the lifecycle you need managed, the more it returns.

11 Code Examples

Foundry is primarily a portal experience, so the 'code' here is mostly the conceptual flow plus one illustrative SDK snippet. The key idea: code targets a project and uses its managed connections and deployments, rather than hardcoding endpoints and keys.

using Azure.AI.Projects;
using Azure.Identity;

// The project endpoint comes from the Foundry portal; auth via Managed Identity.
var project = new AIProjectClient(
    new Uri(projectEndpoint),
    new DefaultAzureCredential());

// Use a deployment the project defines — no endpoint/key scattered in config.
ChatClient chat = project.GetAzureOpenAIChatClient(deploymentName: "gpt-4o-mini");
ChatCompletion reply = await chat.CompleteChatAsync(
    new UserChatMessage("Give me three benefits of a unified AI platform."));
Console.WriteLine(reply.Content[0].Text);

// Nothing above the service layer changes. The Foundry-connected client
// is just another way to construct the ChatClient inside ChatService —
// endpoints, keys, and model choice become project-managed instead of
// options-bound. IChatService, the web endpoints, RAG, and streaming
// from tutorials 13-15 stay exactly as they are.
//
// Direct (tutorials 11-15):
//   new AzureOpenAIClient(endpoint, credential).GetChatClient(deployment)
// Foundry-managed (this tutorial):
//   projectClient.GetAzureOpenAIChatClient(deployment)
//
// Same ChatClient type downstream => the service layer is unchanged.

12 Step by Step: Your First Foundry Project

This walkthrough is a portal exercise: create a project, deploy a model, test it, and connect your RAG data — establishing the environment the rest of the course's platform features build on. No new code is required.

1. Open the Foundry portal and sign in with your Azure account; note the project selector at the top.
2. Create a hub if you do not have one (choosing subscription, resource group, and region), then create a project under it — the workspace for this app.
3. Open the model catalog, filter for a chat model (for example a GPT-4o family model), and open its model card to review capabilities and cost.
4. Choose Deploy to create a deployment; give it a clear name — this is the same deployment concept your code already calls.
5. Open the chat playground, set a system message ('You are a concise .NET assistant'), and send a few prompts to confirm the deployment behaves as expected — all with no code.
6. Add a connection to your Azure AI Search index from tutorial 15, so a Foundry-built RAG app (or your existing one) can reach the same data through the project.
7. Explore the evaluations area: create a small test dataset of question/expected-answer pairs and run an evaluation to see groundedness and relevance scored.
8. Find the tracing/monitoring view and note what it captures — prompts, tokens, latency — the managed form of tutorial 13's structured logging.
9. Optionally, point a copy of your tutorial-15 app at the project: swap the direct AzureOpenAIClient construction for the project-managed client inside ChatService, leaving everything above it untouched.
10. Reflect on fit: your Azure OpenAI deployment, your search index, and your code are all now organized inside one governed project — nothing was rewritten, and you gained catalog, evaluation, and monitoring.

13 Limitations and Caveats

• Fast-moving product and shifting names: Azure AI Foundry unifies and renames earlier experiences (Azure AI Studio, parts of Azure Machine Learning studio), and portal labels and SDK surfaces change frequently. Treat specific names in this tutorial as current-at-writing; the concepts outlast the UI.
• SDK signature caveat: the Azure.AI.Projects client (AIProjectClient, GetAzureOpenAIChatClient, connection resolution) is illustrative here and evolving across preview/GA — verify exact types and methods against the installed package before relying on the snippets.
• Not a replacement for fundamentals: Foundry organizes and augments; it does not remove the need to understand deployments, prompts, RAG, and resilience from earlier tutorials. It is a workshop, not a substitute for knowing the tools.
• Overkill for tiny tasks: a single prompt to a single known model is better served by the direct Azure OpenAI API; wrapping it in a full platform adds setup without payoff.
• Cost and quota still apply: models deployed via Foundry consume the same token-based billing and rate limits as elsewhere; the platform organizes them but does not make them free.
• Governance is configured, not automatic: hubs give you the structure for security, content safety, and access control, but someone must actually set the policies — an empty hub governs nothing.
• Evaluation is a tool, not a guarantee: Foundry's metrics (groundedness, relevance, safety) are valuable signals but depend on good test datasets and thresholds you define; they inform judgment rather than replace it.
• Regional and model availability varies: not every catalog model or feature is available in every region or subscription, so plan around what your subscription actually offers.

14 Best Practices

• Structure with hubs and projects deliberately: one hub as the governed shared foundation, a project per application, so isolation and shared settings both come for free.
• Experiment in playgrounds before coding: settle the model, system message, and prompt shape with no code, then build — it is faster and cheaper than iterating in a compiler.
• Use the model catalog to compare, not just to grab the default: evaluate a few models on your task for quality and cost before committing.
• Gate releases with evaluations: define test datasets and thresholds for groundedness, relevance, and safety, and treat passing them as a ship requirement.
• Prefer project-managed connections and Managed Identity over scattered endpoints and keys, so credentials and data links are centralized and governed.
• Turn on tracing for deployed apps from the start; observability after an incident is too late.
• Match the tool to the scope: stay on the direct API for one-model scripts, adopt Foundry as lifecycle stages and collaborators accumulate.
• Keep your service-layer abstraction: because model access lives behind IChatService, moving to Foundry-managed clients is a one-place change, not a rewrite.

20 Summary

• Azure AI Foundry is Azure's unified platform for building, evaluating, deploying, and managing AI applications — the workshop the course's building blocks live in, not a new model or API.
• It works through a hub-and-project structure: a hub holds shared, governed settings; projects are isolated per-application workspaces that inherit them, with the catalog, playgrounds, connections, evaluations, and tracing all operating inside a project.
• Use it when the work spans the lifecycle and involves several models or people — model comparison, no-code experimentation, evaluation gates, data connections, governance, monitoring; stay on the direct Azure OpenAI API for one-model scripts.
• The Foundry portal is the no-code face — catalog, Deploy, playground, connections, evaluations, tracing — and the Foundry SDK reaches the same project from code so endpoints and keys are project-managed.
• Foundry and Azure OpenAI are complementary: Azure OpenAI is a service providing specific models and deployments; Foundry is the platform that surfaces it as one provider and adds catalog, lifecycle tooling, governance, evaluation, and monitoring.
• Adopting Foundry is additive: existing deployments and the search index become connections, and because model access sits behind IChatService, moving to a project-managed client is a one-place change — you gain the platform without a rewrite.

You now have the map of the platform your earlier work fits into. Deployments, embeddings, RAG, resilience, and web integration are the parts; Foundry is where they are organized, compared, evaluated, deployed, and watched, under governance a team can trust. Nothing you built is obsolete — it becomes better organized and better observed. With that platform in view, the course turns to more powerful ways of assembling these parts, beginning with the Semantic Kernel framework, which orchestrates models, memory, and tools into applications that sit naturally on top of everything introduced here.

21 Next Steps

Next tutorial: Semantic Kernel Framework (semantic-kernel-framework). You have built AI features by hand and seen the platform that organizes them. Semantic Kernel is a .NET framework that orchestrates models, prompts, memory, and tools (plugins) into applications — automating much of the boilerplate you wrote manually, like the function-calling loop from tutorial 12, and sitting comfortably on the Foundry deployments and connections introduced here.

• Practice: complete the no-code portal path — create a project, deploy a model, and test it in a playground — to internalize the lifecycle before any code.
• Practice: add your tutorial-15 Azure AI Search index as a project connection and note how the same data is now reachable under project governance.
• Practice: build a small evaluation dataset and run it, reading the groundedness and relevance scores as a release-gate signal.
• Practice: (optional) point a copy of your RAG app at the project by swapping the client construction inside ChatService, confirming everything above the service layer is untouched.
• Read: the official documentation for 'Azure AI Foundry', 'Azure AI Foundry hubs and projects', 'Model catalog', 'Evaluation of generative AI applications', and the Azure AI Foundry SDK for .NET.