1 Overview: Everything, Assembled

This is the capstone. Every tutorial from Azure OpenAI deployment through response-quality evaluation taught one piece — embeddings, RAG, agents, MCP, security, deployment, LLMOps, evaluation. This tutorial is not a new piece; it is the discipline of building one complete, real-world .NET application using all of them together, in the order and combination a real project actually demands: plan the scope, design the system, integrate the model, write and refine prompts, abstract the AI logic behind a clean service boundary, handle errors and secrets properly, build a usable UI, add guardrails and fallbacks, test and tune quality, deploy it safely, and govern it responsibly — while knowing, throughout, when AI is even the right tool for the job.

This is an advanced, comprehensive tutorial. Its thirteen subtopics are not a checklist of separate features; they are the phases a real GenAI .NET project moves through, each one a direct application of a specific earlier tutorial's teaching to the concrete decisions a real build requires. Four reference project ideas — an FAQ assistant, a resume analyzer, an internal knowledge bot, and a code-review assistant — anchor the discussion in concrete, buildable scopes rather than abstract principle, and the step-by-step section builds one of them end to end.

2 Learning Objectives

• Scope an AI feature through sprint planning and use-case definition before writing any code.
• Design a complete system — UI, API, AI service, configuration — for a real GenAI .NET application.
• Integrate Azure OpenAI in .NET behind a service abstraction, with refined prompts, proper error handling, and secure configuration.
• Build usable UI/UX with input handling, validation, guardrails, and fallback logic for AI-driven features.
• Test end to end and tune response quality before deploying, applying deployment best practices and enterprise governance.
• Judge when AI is the right tool versus traditional code, and apply this whole discipline to one of four reference project types.

3 Prerequisites

• Every prior tutorial in this course, at least at a conceptual level — this tutorial assumes familiarity with tutorials 10 through 26 and cites the specific tutorial behind each technique it uses.
• Working .NET and Azure OpenAI setup (tutorial 10) and comfort with the chat completion API (tutorial 11).
• A specific project idea in mind, ideally one of this tutorial's four reference projects, to ground the walkthrough in something concrete rather than abstract.
• Time and willingness to actually build something — this tutorial is best absorbed by doing the step-by-step walkthrough, not just reading it.

4 Key Concepts: A Real Project Has Phases, Not Just Topics

A real GenAI .NET project moves through recognizable phases, and this tutorial's thirteen subtopics map onto four of them. Phase one is deciding what to build and how it fits together: sprint planning and use-case scoping, system design, and the judgment of when to use AI versus traditional code. Phase two is building the AI capability itself: Azure OpenAI integration, prompt refinement, and service abstraction. Phase three is making it robust and safe: error handling and logging, secure configuration, and validation/guardrails/fallback logic. Phase four is making it usable and shippable: UI/UX and input handling, end-to-end testing and quality tuning, deployment best practices, and enterprise governance.

The fourteenth item — reference project ideas — is not a fifth phase; it's the concrete scope every other subtopic gets applied to. This tutorial builds one of the four (an internal knowledge bot) end to end in the step-by-step section, and discusses how the same four phases apply, with different emphasis, to the other three.

5 Deep Dive 1: Plan and Design — Scoping, System Design, and the AI-vs-Code Judgment

Sprint planning and use-case scoping for an AI feature starts with defining, precisely, what the feature will and won't do — use-case scoping — before any code exists. Unlike deterministic features, an AI feature's uncertainty isn't just 'will we finish the code in time' but 'will the model actually perform well enough on this task,' which argues for scoping down to an MVP (minimum viable product) that validates the core hypothesis (can the model answer these questions well?) before investing in the full feature surface (streaming, multi-turn memory, tool integration). Sprint planning for AI work should budget explicit time for prompt iteration and evaluation (tutorial 26), which a purely code-focused estimate omits.

System design lays out the application's layers before implementation: a UI (tutorial 14) that a user interacts with; an API layer exposing the feature over REST or streaming endpoints; an AI service (deep-dive 2) that owns all model interaction behind a clean boundary; and configuration (deep-dive 3) supplying credentials, prompts, and tunable parameters to that service. Drawing this out — even as a simple box diagram — before writing code prevents the common mistake of AI logic leaking directly into a controller or a view.

The judgment of when to use AI versus traditional code belongs in this planning phase, not after the feature is built. AI is the right tool when a task requires interpreting unstructured natural language, handling open-ended variation a fixed rule set can't enumerate, or synthesizing across sources in a way that resists a deterministic algorithm. Traditional code is the right tool when the logic is fully specifiable in advance, needs perfect reliability, or where a simple lookup or rule already solves the problem — adding a model call to a task a dictionary lookup already handles adds cost, latency, and non-determinism for no benefit. A resume analyzer's field extraction from free-text resumes is a good AI fit; validating that a required field is non-empty afterward is not — that's a one-line traditional check.

6 Deep Dive 2: Build the AI Service — Integration, Prompt Refinement, Service Abstraction

Azure OpenAI integration in .NET (tutorial 11) is the mechanical foundation: an AzureOpenAIClient, a chat deployment, and the chat completion call. In a real project, this integration never stands alone — it is built once, inside the AI service, and never called directly from anywhere else in the application. Prompt refinement and optimization (tutorial 26) is not a one-time step during initial build; it's the ongoing practice of observing real outputs, identifying a specific failure pattern, and making one targeted change at a time, validated against a golden dataset before it ships.

public interface IKnowledgeBotService
{
    Task<BotAnswer> AskAsync(string question, CancellationToken ct = default);
}

public sealed record BotAnswer(string Text, IReadOnlyList<string> Sources, bool Truncated);

public sealed class KnowledgeBotService : IKnowledgeBotService
{
    private readonly ChatClient _chat;
    private readonly ISearchService _search;              // tutorial 15 retrieval
    private readonly ILogger<KnowledgeBotService> _logger;
    private readonly BotOptions _options;                  // deep-dive 3: bound configuration

    // Constructor takes everything via DI (tutorial 13) -- nothing constructed inline.
    public KnowledgeBotService(AzureOpenAIClient client, ISearchService search,
                               IOptions<BotOptions> options, ILogger<KnowledgeBotService> logger)
    {
        _chat = client.GetChatClient(options.Value.DeploymentName);
        _search = search;
        _options = options.Value;
        _logger = logger;
    }

    public async Task<BotAnswer> AskAsync(string question, CancellationToken ct = default)
    {
        var passages = await _search.RetrieveAsync(question, k: 5, ct);
        var messages = BuildGroundedPrompt(question, passages);   // refined prompt (deep-dive 2)
        var completion = await _chat.CompleteChatAsync(messages,
            new ChatCompletionOptions { Temperature = _options.Temperature }, ct);

        return new BotAnswer(
            completion.Value.Content[0].Text,
            passages.Select(p => p.Title).ToList(),
            completion.Value.FinishReason == ChatFinishReason.Length);
    }
}

Service abstraction for AI logic (tutorial 13) is what makes every downstream subtopic manageable: the interface (IKnowledgeBotService) is what the API layer, tests, and any future refactor depend on, while the concrete class is the only thing that knows Azure OpenAI exists. Swapping the SDK, moving to Semantic Kernel (tutorial 17), or adding a second model provider later touches this one class, not the rest of the application — the exact payoff the whole course has built toward since tutorial 13 first introduced it.

7 Deep Dive 3: Robustness and Safety — Errors, Secrets, Validation, and Guardrails

Error handling and logging (tutorial 13) inside the AI service means every call is wrapped in resilience (timeout, retry with backoff for 429s) and structured logging (latency, token counts, finish reason — never prompt bodies by default, per tutorial 24). Secure configuration management (tutorial 13) follows the same hierarchy every project in this course has used: Managed Identity first, Key Vault for what can't be eliminated, user secrets strictly for local development, and never a key in source control or appsettings.json.

public async Task<BotAnswer> AskSafelyAsync(string question, CancellationToken ct)
{
    // Input validation (tutorial 24): bound length, reject empty input.
    if (string.IsNullOrWhiteSpace(question) || question.Length > 1000)
        return new BotAnswer("Please ask a shorter, specific question.", [], false);

    try
    {
        var answer = await AskAsync(question, ct);

        // Guardrail: refuse to return an answer with zero supporting sources for a factual bot.
        if (answer.Sources.Count == 0)
            return new BotAnswer("I couldn't find anything relevant to answer that.", [], false);

        return answer;
    }
    catch (ClientResultException ex) when (ex.Status == 429 || ex.Status >= 500)
    {
        _logger.LogWarning("AI call failed after retries: {Status}", ex.Status);
        // Fallback logic: a safe, honest degraded response instead of an error page.
        return new BotAnswer("The assistant is temporarily busy. Please try again shortly.", [], false);
    }
}

8 Deep Dive 4: Ship and Govern — UI/UX, Testing, Deployment, Governance

UI/UX and input handling (tutorial 14) for an AI feature needs the five states tutorial 14 established — idle, loading, success, error, cancelled — plus, for streaming, visible progress rather than a silent wait. End-to-end testing and response-quality tuning combines tutorial 22's golden-dataset regression testing with tutorial 26's relevance/groundedness/consistency checks, run before every release, not just once at launch. Deployment best practices (tutorial 23) mean infrastructure as code, Managed-Identity-based model access, canary rollout for prompt changes, and the monitoring dashboards (tutorial 25) that make the deployed system's health visible.

Enterprise governance for GenAI ties every prior subtopic into an organizational practice: a production readiness checklist (secrets secured, guardrails tested, evaluation passing, dashboard owned) that a feature must satisfy before shipping; a defined review process for new AI features, especially ones touching sensitive data or consequential actions; and a recurring cadence (tutorial 25's monthly review pattern) revisiting cost, quality, and security as the system and its usage evolve. Governance is what makes 'we followed every tutorial's best practice on this one feature' scale into 'our organization reliably builds safe AI features.'

9 Ecosystem and Tools

Every row here is a specific tutorial's tool, reused rather than reintroduced. This tutorial's contribution is the integration: choosing which of these a specific reference project actually needs, and in what order to build them.

10 Use Cases: The Four Reference Projects

Four reference project ideas anchor this course's techniques in concrete, buildable scopes. Each applies the same four-phase discipline from this tutorial's deep dives, with different emphasis.

• FAQ assistant: the simplest RAG-shaped project (tutorial 15) — a knowledge base of Q&A pairs or short documents, retrieval, and a grounded, cited answer. Best first project; minimal tool use, straightforward evaluation (does it answer known FAQs correctly).
• Resume analyzer: extracts structured fields (skills, experience, education) from unstructured resume text and optionally scores fit against a job description. Emphasizes prompt design for structured extraction, output validation (does the extracted JSON parse correctly), and a clear AI-vs-code line (extraction is AI; downstream business rules on the extracted fields are traditional code).
• Internal knowledge bot: a RAG system (tutorial 15) over internal documentation, often extended with tools (tutorial 12/17) to check live systems (ticket status, policy lookups). This tutorial's step-by-step builds this one. Emphasizes retrieval quality, tool governance (tutorial 20), and enterprise rollout (tutorial 23).
• Code-review assistant: analyzes a code diff and generates review comments, often combining traditional static analysis (a linter, a security scanner) with AI-generated commentary on style, clarity, or design — a clean example of AI augmenting rather than replacing deterministic tooling. Emphasizes the build-vs-buy-vs-augment decision and careful prompt design to avoid noisy, low-value comments.

All four share the system design from deep-dive 1 (UI, API, AI service, configuration) and the robustness practices from deep-dive 3. What differs is scope (deep-dive 1's judgment call), the specific tools and data sources integrated (deep-dive 2), and the evaluation criteria that matter most (deep-dive 4) — a resume analyzer cares most about extraction accuracy, a code-review assistant cares most about comment usefulness and low false-positive rate.

11 Code Examples: Assembling the Layers

These examples show the API layer and DI registration tying together everything from deep-dives 1-3 into one runnable composition.

var builder = WebApplication.CreateBuilder(args);

// Secure configuration (deep-dive 3 / tutorial 13): bind and validate at startup.
builder.Services.AddOptions<BotOptions>()
    .Bind(builder.Configuration.GetSection("KnowledgeBot"))
    .ValidateDataAnnotations().ValidateOnStart();

// AI service registration: singleton client, Managed Identity in production.
builder.Services.AddSingleton(sp =>
{
    var opts = sp.GetRequiredService<IOptions<BotOptions>>().Value;
    return new AzureOpenAIClient(new Uri(opts.Endpoint), new DefaultAzureCredential());
});
builder.Services.AddSingleton<ISearchService, AzureSearchService>();   // tutorial 15
builder.Services.AddSingleton<IKnowledgeBotService, KnowledgeBotService>();  // deep-dive 2

// Observability (tutorial 23/25).
builder.Services.AddApplicationInsightsTelemetry();
builder.Services.AddHealthChecks().AddCheck<AzureOpenAIHealthCheck>("azure-openai");

var app = builder.Build();

app.MapPost("/api/ask", async (AskRequest req, IKnowledgeBotService bot, CancellationToken ct) =>
{
    // Guardrail + validation live inside the service (deep-dive 3); the endpoint stays thin.
    var answer = await bot.AskSafelyAsync(req.Question, ct);
    return Results.Ok(new AskResponse(answer.Text, answer.Sources, answer.Truncated));
});

public record AskRequest(string Question);
public record AskResponse(string Answer, IReadOnlyList<string> Sources, bool Truncated);

// tutorial 22/26 evaluation, run in CI before a canary rollout (tutorial 23).
var goldenSet = LoadGoldenDataset("knowledge-bot-golden.json");
var results = await RunQualityEvaluationAsync(goldenSet, botService, ct);

double avgGroundedness = results.Average(r => r.Groundedness);
if (avgGroundedness < 4.0)
    throw new InvalidOperationException("Groundedness regression detected; blocking deployment.");

12 Step by Step: Building the Internal Knowledge Bot End to End

This walkthrough builds the internal knowledge bot reference project from scratch, applying all thirteen subtopics in the order a real project would.

1. Sprint planning and scoping: define the MVP — answer questions from a fixed set of 20-30 internal policy documents, no tools yet, no multi-turn memory. Write down explicitly what's out of scope for v1 (live ticket lookups, multi-turn conversation) to prevent scope creep.
2. System design: sketch the four layers (deep-dive 1) — a minimal web UI, a single /api/ask endpoint, a KnowledgeBotService, and configuration for the Azure OpenAI and Azure AI Search connections.
3. Decide AI vs. traditional code: confirm the core Q&A task genuinely needs a model (open-ended natural-language questions over unstructured documents) while noting that document ingestion/chunking (tutorial 15) is traditional deterministic code, not an AI call.
4. Build Azure OpenAI integration and the service abstraction together (deep-dive 2): implement IKnowledgeBotService and KnowledgeBotService with the RAG retrieval and grounded prompt from tutorial 15.
5. Refine the prompt: run 10 real questions, evaluate relevance and groundedness (tutorial 26), and make one targeted refinement to the grounding instruction based on the most common failure observed.
6. Add error handling, logging, and secure configuration (deep-dive 3): wrap the service call with tutorial 13's resilience, structured logging, and bind configuration via Managed Identity, never a hardcoded key.
7. Add validation, guardrails, and fallback logic: bound input length, add the 'no sources found' guardrail from Example in deep-dive 3, and confirm the fallback message is honest and clear.
8. Build the UI: a simple page with the five states from tutorial 14 (idle, loading, success, error, cancelled), streaming the answer if time allows.
9. Run end-to-end testing: build a 15-20 question golden dataset, run the full relevance/groundedness/consistency evaluation from tutorial 26, and fix any failures found before proceeding.
10. Deploy following tutorial 23's practices: infrastructure as code, a health check, and a dashboard (tutorial 25) with token spend and latency visible from day one.
11. Apply enterprise governance: run through the production readiness checklist from deep-dive 4, and document the project's scope, evaluation results, and known limitations for whoever operates it next.
12. Reflect and plan the next iteration: identify the single most valuable next capability (perhaps a tool for live ticket status) and repeat this same thirteen-subtopic cycle for that increment, rather than building everything in one pass.

13 Limitations and Caveats

• This tutorial's code is illustrative of shape and integration, not a complete, production-ready codebase — every SDK signature caveat from tutorials 11-21 still applies to the specific pieces shown here.
• The four reference projects are starting scopes, not fixed specifications; real requirements will push each in directions this tutorial doesn't anticipate.
• Applying all thirteen subtopics fully to a genuinely trivial internal tool may be disproportionate; scale rigor to actual stakes, as tutorial 20 and this tutorial's governance section both note.
• The step-by-step walkthrough compresses what a real team might spend weeks on into a linear list; real projects iterate, backtrack, and revisit earlier phases as later phases reveal new information.
• This tutorial cannot substitute for the depth of its 26 predecessors; where a technique feels underexplained here, that's intentional — the full treatment is in the tutorial cited alongside it.
• Enterprise governance requirements vary enormously by organization and industry; this tutorial's checklist is a reasonable baseline, not a substitute for organization-specific policy or legal/compliance review.
• Reference project choice should reflect genuine organizational need, not novelty; building a code-review assistant when no one asked for one wastes the scoping discipline deep-dive 1 argues for.
• Skipping evaluation, leaving tool access unscoped, or shipping an unrefined prompt to save time creates technical debt that costs more to fix once real users depend on the feature than it would have cost to do right initially.
• AI capability and model behavior continue to evolve; specific prompt patterns and workarounds in this tutorial (and its predecessors) may need revisiting as models improve or change.

14 Best Practices

• Scope to an MVP that validates the core AI hypothesis before building the full feature surface — sprint planning should budget explicit time for prompt iteration and evaluation.
• Design the four-layer system (UI, API, AI service, configuration) before writing implementation code, so AI logic never leaks into a controller or view.
• Build the service abstraction from day one, even for a small project — retrofitting it later is real work every subsequent subtopic makes harder to skip.
• Treat prompt refinement as ongoing practice tied to evaluation evidence, never a one-time step completed at launch.
• Apply tutorial 13's error handling/logging and secrets discipline and tutorial 24's validation/guardrail discipline together — robustness and safety are one integrated practice, not two separate checklists.
• Design all five UI states and test the fallback path deliberately, not just the happy path.
• Run end-to-end evaluation before every release, gating deployment on it, exactly as tutorial 22's regression testing and tutorial 23's canary rollout intend.
• Revisit the AI-vs-traditional-code judgment at every iteration — a capability that seemed to need a model may prove to have a simpler, more reliable non-AI solution once real usage patterns are understood.

20 Summary

• A real GenAI .NET project moves through four phases — Plan & Design, Build the AI Service, Robustness & Safety, Ship & Govern — each a direct application of specific earlier tutorials, not a new technique.
• System design (UI, API, AI service, configuration) and the AI-vs-traditional-code judgment belong in the planning phase, before implementation begins.
• Azure OpenAI integration, prompt refinement, and service abstraction are built together, since the abstraction is what all downstream error handling, testing, and deployment attach to.
• Robustness and safety layer input validation, resilient error handling, secure configuration, guardrails, and honest fallback logic together — none sufficient alone.
• Shipping responsibly means UI/UX with real state handling, evaluation before every release, deployment best practices, and enterprise governance scaled to actual stakes.
• The four reference projects — FAQ assistant, resume analyzer, internal knowledge bot, code-review assistant — share this same discipline, differing in scope, integrations, and evaluation focus; and the whole thirteen-subtopic cycle repeats for every future increment, never finishing after one pass.

You have now completed the full arc of this course: from a single Azure OpenAI chat completion call in tutorial 11 to a complete, planned, built, hardened, tested, deployed, and governed real-world application in this tutorial. Every technique — embeddings, RAG, agents, MCP, security, deployment, LLMOps, evaluation — has a place in the discipline this final tutorial assembled. What you carry forward is not a list of APIs, but the judgment to scope well, design cleanly, build safely, ship responsibly, and keep improving — the actual, durable skill of building AI-powered .NET applications that work in the real world, not just in a demo.

21 Next Steps

This is the final tutorial in the GenAI-Powered .NET course. There is no next tutorial in this series — the path forward is applying this course's discipline to a real project of your own, using this tutorial's four reference project ideas as concrete starting points if you don't already have one in mind.

• Practice: pick one of the four reference projects and complete the full step-by-step walkthrough from this tutorial end to end, building a genuinely deployed, evaluated, monitored application.
• Practice: apply the production readiness checklist from deep-dive 4 to a project you've built earlier in this course, and close any gaps it reveals.
• Practice: run the AI-vs-traditional-code judgment (deep-dive 1) against a real backlog item at your organization, and document the reasoning either way.
• Practice: after your first version ships, deliberately run the 'reflect and plan the next iteration' step and complete one more full cycle, experiencing the repeating discipline this tutorial insists on.
• Revisit: any earlier tutorial (10 through 26) whose techniques you haven't yet applied hands-on — this capstone assumes familiarity, but real fluency comes from building, and every earlier tutorial's step-by-step walkthrough is still there to practice with.