Update blog 6.1 and API submodule for Microsoft.Extensions.AI

- Blog 6.1: reflect MEA IChatClient usage, GA status, OllamaSharp 5.x implementation
- API submodule: point to feature/mea-update with MEA-based OllamaAiService

Author: workcontrolgit

ApiResources/TalentManagement-API

@@ -1,6 +1,6 @@
 # Run a Local LLM in Your .NET 10 API with Ollama
 
-## How OllamaSharp and a Custom Service Interface Make Your .NET 10 API AI-Ready
+## How Microsoft.Extensions.AI, OllamaSharp, and a Custom Service Interface Make Your .NET 10 API AI-Ready
 
 Every developer wants AI in their app. The problem is getting started: API keys, cloud costs, rate limits, and the fear of betting your architecture on one vendor. What if you could add a working AI endpoint to your .NET 10 API in under an hour — for free, running entirely on your laptop?
 
@@ -16,11 +16,12 @@ This article is part of the **AngularNetTutorial** series. The full-stack tutori
 
 ## 🎓 What You'll Learn
 
-* **OllamaSharp streaming** — How `IOllamaApiClient` streams tokens from Ollama using `IAsyncEnumerable<>` so responses appear progressively, not all at once
+* **Microsoft.Extensions.AI (MEA)** — The GA abstraction layer shipping with .NET 10 that gives you a single `IChatClient` interface across all AI providers
+* **OllamaSharp + MEA** — How OllamaSharp 5.x natively implements `IChatClient`, making Ollama a drop-in MEA provider with no extra package
 * **Ollama integration** — Pull a free local model and connect it to your .NET API in minutes
-* **Feature flag gating** — Why `[FeatureGate("AiEnabled")]` is the safest way to ship AI without breaking existing users
+* **Feature flag gating** — Why per-method `IsEnabledAsync` checks return `503` instead of the misleading `404` from `[FeatureGate]`
 * **Clean Architecture placement** — Where AI interfaces, implementations, and controllers belong in the layer structure
-* **Custom `IAiChatService` interface** — How defining your own service interface in the Application layer hides OllamaSharp from callers and makes the implementation swappable
+* **Custom `IAiChatService` interface** — How defining your own service interface in the Application layer hides MEA/OllamaSharp from callers and makes the implementation swappable
 
 ---
 
@@ -54,18 +55,21 @@ Beyond getting started, there's an architectural risk: if your AI code reaches d
 
 ## 💡 The Solution
 
-[OllamaSharp](https://github.com/awaescher/OllamaSharp) is a .NET client for Ollama that exposes `IOllamaApiClient` and native token streaming via `IAsyncEnumerable<>`. We use it directly in `Infrastructure.Shared` — one package, no additional provider abstraction library needed.
+**[Microsoft.Extensions.AI](https://learn.microsoft.com/en-us/dotnet/ai/microsoft-extensions-ai)** (MEA) is the standard AI abstraction layer that ships GA with .NET 10. It defines `IChatClient` — a single interface for chat completions that works across OpenAI, Azure OpenAI, Ollama, and any other provider. You code against `IChatClient`; switching providers is a one-line DI change.
+
+**[OllamaSharp](https://github.com/awaescher/OllamaSharp) 5.x** natively implements `IChatClient` from MEA. The former `Microsoft.Extensions.AI.Ollama` provider package has been deprecated — OllamaSharp is now the recommended path. That means you need just two NuGet packages in `Infrastructure.Shared`: `Microsoft.Extensions.AI.Abstractions` for the interface and `OllamaSharp` for the implementation.
 
 [Ollama](https://ollama.com) runs open-weight models like `llama3.2` locally. No API key. No cloud. Works offline. Perfect for tutorials and development.
 
-Provider independence comes from our own `IAiChatService` interface defined in the Application layer. `OllamaAiService` implements it using OllamaSharp. To swap providers (e.g., Azure OpenAI in production), you write a new implementation of `IAiChatService` in Infrastructure.Shared and change the DI registration — the Application layer, handlers, and controller are untouched.
+Provider independence has two layers: MEA's `IChatClient` (standard .NET 10 interface) and our own `IAiChatService` (defined in the Application layer). `OllamaAiService` receives `IChatClient` from DI and wraps it in the Application-layer contract. To swap from Ollama to Azure OpenAI, you register a different `IChatClient` implementation — `OllamaAiService` itself is untouched, and the Application layer, handlers, and controller never change.
 
-We gate the entire `AiController` behind a `[FeatureGate("AiEnabled")]` attribute. When `"AiEnabled": false` (the default), the controller doesn't even respond to requests — no Ollama connection is attempted, the rest of the API is unaffected.
+We gate AI per-method with `IFeatureManagerSnapshot.IsEnabledAsync("AiEnabled")` rather than a class-level `[FeatureGate]` attribute. The attribute returns `404 Not Found` when disabled — confusing for a known endpoint. The per-method check returns `503 Service Unavailable` with a `detail` message that tells the developer exactly what to enable and where.
 
 **Key benefits:**
 
 * ✅ **Zero cost** — Ollama is free; no API key, no credit card, no rate limits
-* ✅ **Provider-independent Application layer** — `IAiChatService` hides OllamaSharp from all callers; swap the implementation without touching handlers or controllers
+* ✅ **Standard .NET 10 AI abstraction** — MEA's `IChatClient` is GA and built into the platform; no preview dependencies
+* ✅ **Provider swap in one line** — Register a different `IChatClient` to move from Ollama to Azure OpenAI; no service code changes
 * ✅ **Safe coexistence** — Feature flag default `false` means original tutorial (Series 0–5) works unchanged
 * ✅ **Clean Architecture** — Interface in Application, implementation in Infrastructure.Shared, controller in WebApi
 
@@ -92,15 +96,22 @@ curl http://localhost:11434/api/tags
 
 ### Step 2: Add NuGet Packages
 
-Add OllamaSharp to the Infrastructure.Shared project — this is the only AI package needed:
+Add two packages to the Infrastructure.Shared project — the MEA abstraction and the OllamaSharp implementation:
 
 **`TalentManagementAPI.Infrastructure.Shared.csproj`**:
 
 ```xml
+<PackageReference Include="Microsoft.Extensions.AI.Abstractions" Version="10.3.0" />
 <PackageReference Include="OllamaSharp" Version="5.3.4" />
 ```
 
-**Why OllamaSharp instead of `Microsoft.Extensions.AI`?** OllamaSharp provides native streaming support via `IAsyncEnumerable<>` (`await foreach`), so tokens stream out of Ollama as they are generated — important when local model responses take several seconds. `Microsoft.Extensions.AI` is the right abstraction when you need to swap between Azure OpenAI, OpenAI, and Ollama without touching service code. For this tutorial, OllamaSharp keeps the dependency footprint minimal: one package, only in Infrastructure.Shared, no provider registration boilerplate in Program.cs.
+**Why both packages?**
+
+`Microsoft.Extensions.AI.Abstractions` ships GA with .NET 10. It defines `IChatClient` — the standard interface for chat completions across all AI providers. Coding against `IChatClient` means your service code never changes when you switch from Ollama to Azure OpenAI or any other provider.
+
+`OllamaSharp` 5.x natively implements `IChatClient`. The former `Microsoft.Extensions.AI.Ollama` provider package has been **deprecated** — OllamaSharp is the recommended path for Ollama integration. This means you do not need a separate adapter package: `OllamaApiClient` from OllamaSharp implements both `IChatClient` (for chat) and `IOllamaApiClient` (for embeddings), and you register it once as a singleton.
+
+**No provider boilerplate in Program.cs.** All AI registration stays inside `AddSharedInfrastructure` — the WebApi project adds zero AI-specific setup.
 
 ### Step 3: Add Feature Flag and Ollama Config
 
@@ -151,60 +162,48 @@ namespace TalentManagementAPI.Application.Interfaces
 Create `TalentManagementAPI.Infrastructure.Shared/Services/OllamaAiService.cs`:
 
 ```csharp
+#nullable enable
+using Microsoft.Extensions.AI;
 using TalentManagementAPI.Application.Interfaces;
 
 namespace TalentManagementAPI.Infrastructure.Shared.Services
 {
     public class OllamaAiService : IAiChatService
     {
-        private readonly IOllamaApiClient _ollamaApiClient;
+        private readonly IChatClient _chatClient;
 
-        public OllamaAiService(IOllamaApiClient ollamaApiClient)
+        public OllamaAiService(IChatClient chatClient)
         {
-            _ollamaApiClient = ollamaApiClient;
+            _chatClient = chatClient;
         }
 
         public async Task<string> ChatAsync(string message, string? systemPrompt = null,
             CancellationToken cancellationToken = default)
         {
-            var messages = new List<Message>();
+            var messages = new List<ChatMessage>();
 
             if (!string.IsNullOrWhiteSpace(systemPrompt))
-                messages.Add(new Message(new ChatRole("system"), systemPrompt));
-
-            messages.Add(new Message(new ChatRole("user"), message));
-
-            var request = new ChatRequest
-            {
-                Model = _ollamaApiClient.SelectedModel,
-                Messages = messages,
-                Stream = true
-            };
-
-            var responseBuilder = new MessageBuilder();
+                messages.Add(new ChatMessage(Microsoft.Extensions.AI.ChatRole.System, systemPrompt));
 
-            await foreach (var response in _ollamaApiClient.ChatAsync(request, cancellationToken)
-                               .WithCancellation(cancellationToken))
-            {
-                if (response?.Message is not null)
-                    responseBuilder.Append(response);
-            }
+            messages.Add(new ChatMessage(Microsoft.Extensions.AI.ChatRole.User, message));
 
-            return responseBuilder.HasValue
-                ? responseBuilder.ToMessage().Content ?? string.Empty
-                : string.Empty;
+            var response = await _chatClient.GetResponseAsync(messages, cancellationToken: cancellationToken);
+            return response.Text ?? string.Empty;
         }
     }
 }
 ```
 
-**What this does:** `OllamaAiService` takes `IOllamaApiClient` from DI (registered in Step 6). OllamaSharp streams tokens back using `IAsyncEnumerable<>` — the `await foreach` loop accumulates each chunk into a `MessageBuilder`, then returns the fully assembled reply. An optional system prompt lets callers control the AI's persona or constraints without the service knowing anything about the caller's intent.
+**What this does:** `OllamaAiService` takes `IChatClient` (the MEA standard interface) from DI — registered in Step 6 as `OllamaApiClient`. It builds a message list, optionally prepending a system prompt that lets callers control the AI's persona or constraints. `GetResponseAsync` is the MEA 10.x API for a single-turn chat completion. `response.Text` returns the assistant's reply as a plain string.
+
+**Why `Microsoft.Extensions.AI.ChatRole.System` instead of just `ChatRole.System`?** Both OllamaSharp and MEA define a `ChatRole` type. Fully qualifying the namespace resolves the ambiguity cleanly without needing a using alias.
 
 ### Step 6: Register Services
 
-In `Infrastructure.Shared/ServiceRegistration.cs`, register `IOllamaApiClient` and wire `IAiChatService` to a caching decorator that wraps `OllamaAiService`:
+In `Infrastructure.Shared/ServiceRegistration.cs`, register `OllamaApiClient` as a concrete singleton and expose it as both `IChatClient` and `IOllamaApiClient` — so both interfaces resolve to the same instance:
 
 ```csharp
+using Microsoft.Extensions.AI;
 using TalentManagementAPI.Application.Interfaces;
 using TalentManagementAPI.Infrastructure.Shared.Services;
 
@@ -215,13 +214,16 @@ public static void AddSharedInfrastructure(this IServiceCollection services, ICo
     services.AddTransient<IEmailService, EmailService>();
     services.AddTransient<IMockService, MockService>();
 
-    // Register the Ollama client as a singleton — one connection reused across requests
-    services.AddSingleton<IOllamaApiClient>(_ =>
+    // OllamaApiClient implements both IChatClient (Microsoft.Extensions.AI) and IOllamaApiClient.
+    // Register as a singleton so both interfaces resolve to the same instance.
+    services.AddSingleton<OllamaApiClient>(_ =>
     {
         var baseUrl = config["Ollama:BaseUrl"] ?? "http://localhost:11434";
         var model   = config["Ollama:Model"]   ?? "llama3.2";
         return new OllamaApiClient(new Uri(baseUrl), model);
     });
+    services.AddSingleton<IChatClient>(sp => sp.GetRequiredService<OllamaApiClient>());
+    services.AddSingleton<IOllamaApiClient>(sp => sp.GetRequiredService<OllamaApiClient>());
 
     // Metadata scoped per-request so the controller can read cache hit/miss
     services.AddScoped<IAiResponseMetadata, AiResponseMetadata>();
@@ -243,9 +245,18 @@ In `WebApi/Program.cs`, the only AI-related line is the call to `AddSharedInfras
 ```csharp
 builder.Services.AddApplicationLayer();
 builder.Services.AddPersistenceInfrastructure(builder.Configuration);
-builder.Services.AddSharedInfrastructure(builder.Configuration);  // ← registers IOllamaApiClient + IAiChatService
+builder.Services.AddSharedInfrastructure(builder.Configuration);  // ← registers IChatClient + IAiChatService
 ```
 
+**Why three registrations for one object?** `OllamaApiClient` implements two interfaces from different libraries:
+
+* `IChatClient` (from `Microsoft.Extensions.AI`) — used by `OllamaAiService` for chat completions
+* `IOllamaApiClient` (from OllamaSharp) — used by `OllamaEmbeddingService` for embedding generation (introduced in Series 6.5)
+
+Registering the concrete type first as a singleton, then aliasing both interfaces to it, ensures both resolve to the same underlying instance — one HTTP connection, one model selection, shared across the app.
+
+**To swap Ollama for Azure OpenAI in production:** Replace the three `AddSingleton` calls with your Azure OpenAI `IChatClient` registration. `OllamaAiService`, the Application layer, MediatR handlers, and the controller require zero changes.
+
 **What the caching decorator does:** `CachingAiChatService` wraps `OllamaAiService`. On the first call for a given `(message, systemPrompt)` pair, it calls Ollama and stores the reply. On subsequent identical calls within the TTL window, it returns the cached reply — skipping the 1–4 second Ollama inference. The `IAiResponseMetadata` flag tells the controller whether the response was a cache hit, which is surfaced as the `X-AI-Cache: HIT/MISS` response header.
 
 ### Step 7: Create the AI Controller
@@ -362,7 +373,7 @@ curl -X POST https://localhost:44378/api/v1/ai/chat \
   -d '{"message": "Explain JWT tokens in one paragraph."}'
 ```
 
-**To verify the feature flag** — set `"AiEnabled": false`, restart the API, and try the same curl. You'll get a `404` — the controller is invisible.
+**To verify the feature flag** — set `"AiEnabled": false`, restart the API, and try the same curl. You'll get a `503 Service Unavailable` with a `detail` message explaining exactly what to enable.
 
 ---
 
@@ -384,18 +395,21 @@ curl -X POST https://localhost:44378/api/v1/ai/chat \
 
 ## 🌟 Why This Matters
 
-OllamaSharp's native `IAsyncEnumerable<>` streaming means tokens appear progressively as Ollama generates them — critical when a local model takes several seconds per response. Buffering the entire reply before returning it would feel broken to users.
+**Microsoft.Extensions.AI ships GA with .NET 10** — it is not a preview library. `IChatClient` is the platform-standard interface for chat completions, with first-party support from Microsoft and implementations across OpenAI, Azure OpenAI, Ollama (via OllamaSharp), and more. Building against `IChatClient` means your service layer is future-proof: new providers ship as NuGet packages, and switching is a one-line DI change.
+
+**OllamaSharp 5.x natively implements `IChatClient`.** The former `Microsoft.Extensions.AI.Ollama` adapter package has been deprecated in favor of OllamaSharp directly. That means one fewer dependency and no abstraction-over-an-abstraction: `OllamaApiClient` *is* the `IChatClient` — no adapter wrapper needed.
 
-The custom `IAiChatService` interface pattern is the key architectural decision. It places the Ollama dependency entirely inside `Infrastructure.Shared`. Application-layer code (handlers, queries) and the controller depend only on the interface — they are completely unaware of OllamaSharp. When you are ready to move to a cloud provider (Azure OpenAI, Anthropic), you add a new infrastructure implementation and update one DI registration. Nothing else changes.
+The custom `IAiChatService` interface adds a second layer of provider independence specific to this application's contract (`ChatAsync` with an optional system prompt). Application-layer code (handlers, queries) and the controller depend only on `IAiChatService` — they are completely unaware of MEA or OllamaSharp. When you are ready to move to a cloud provider, you register a different `IChatClient` (one line in ServiceRegistration.cs) and the rest of the codebase is untouched.
 
 For tutorial purposes, Ollama removes the biggest barrier to learning: access. Every developer on every OS can pull `llama3.2`, type `ollama serve`, and have a working LLM in their local environment. No billing, no configuration, no waiting for API access.
 
 The feature flag pattern ensures this is safe to ship: the codebase always builds, always runs, and the original Series 0–5 experience is completely unchanged. AI features activate on demand.
 
 **Transferable skills:**
 
+* **Microsoft.Extensions.AI** — `IChatClient` is the standard .NET 10 AI interface; the same pattern applies to OpenAI, Azure OpenAI, and any future MEA provider
 * **Custom service interface for AI** — The `IAiChatService` pattern applies to any AI provider; define the contract in Application, implement in Infrastructure
-* **Feature flag architecture** — The `[FeatureGate]` pattern applies to any experimental or optional feature
+* **Per-method feature flag checks** — `IsEnabledAsync` returning `503 Service Unavailable` is more developer-friendly than the `404` from `[FeatureGate]` on a class
 * **Clean Architecture for external services** — Interface in Application, implementation in Infrastructure, DI registration in WebApi
 
 ---