MAI-Thinking-1 Is Now in Foundry — Here's What It Means If You Write C#

Microsoft's first reasoning model, MAI-Thinking-1, is now in public preview in Microsoft Foundry, and it is designed for multi-step reasoning tasks. The model integrates with Microsoft.Extensions.AI and the IChatClient interface, allowing C# developers to swap it in as a config change rather than a rewrite. A developer demonstrated its use in a contract risk triage service, highlighting its ability to reason step-by-step and produce structured summaries.

Every time Microsoft ships a new model into Foundry, I ask myself the same boring-but-important question: does this change anything for the way I actually write code? Most of the time the answer is "cool demo, doesn't affect my day job." This time it's different. MAI-Thinking-1 — Microsoft's first reasoning model — just went into public preview in Microsoft Foundry. It's not a chat model with a "think harder" flag bolted on. It's built from the ground up for multi-step reasoning: the kind of work where the model has to plan, reconsider, call tools, and stitch together a long chain of context before it gives you an answer worth trusting. If you've read anything else I've written, you know where this is going: no Python required, no notebook gymnastics, just Microsoft.Extensions.AI and a dotnet run . A few things worth knowing before you touch any code: None of that matters if you can't get it working in fifteen minutes, so let's do that. Most "reasoning model" content is written for people gluing together Python scripts and LangChain. That's not how most of us ship software. If you're building: MAI-Thinking-1 is aimed squarely at you, and it slots into the same IChatClient interface you're already using for GPT-4o or any other Foundry model. Swapping models is a config change, not a rewrite. dotnet new console -n MaiThinkingDemo cd MaiThinkingDemo dotnet add package Azure.AI.OpenAI dotnet add package Microsoft.Extensions.AI dotnet add package Azure.Identity dotnet user-secrets init dotnet user-secrets set "AZURE AI ENDPOINT" "https://your-resource.services.ai.azure.com" Deploy MAI-Thinking-1 from the Foundry Model Catalog to your Foundry project, same as you would any other model. Grab your endpoint and deployment name. Here's the thing about reasoning models: the interesting part isn't a single prompt/response, it's giving the model something that actually requires reasoning across steps. Let's build a small "contract risk triage" service — the kind of long-document, multi-step reasoning task MAI-Thinking-1 is designed for. using Azure.AI.OpenAI; using Azure.Identity; using Microsoft.Extensions.AI; using Microsoft.Extensions.Configuration; var config = new ConfigurationBuilder .AddUserSecrets<Program .AddEnvironmentVariables .Build ; var deploymentName = config "AZURE OPENAI DEPLOYMENT" ?? "mai-thinking-1"; var endpoint = new Uri config "AZURE AI ENDPOINT" ?? throw new InvalidOperationException "AZURE AI ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE AI ENDPOINT\" \"<your-endpoint \"" ; IChatClient chatClient = new AzureOpenAIClient endpoint, new DefaultAzureCredential .GetChatClient deploymentName .AsIChatClient ; var systemPrompt = """ You are a contract risk analyst. When given a contract excerpt, you must: 1. Identify every clause that creates financial or legal risk. 2. Reason step-by-step about why each clause is risky before concluding. 3. Rank the risks by severity High / Medium / Low . 4. Output a final structured summary — do not skip the reasoning steps. """; var contractExcerpt = """ Section 9.2: Client may terminate this Agreement for convenience with 5 days' written notice. Vendor shall be entitled to fees for Services rendered through the termination date only, with no early-termination compensation. Section 11.4: Vendor's total liability under this Agreement shall not exceed the total fees paid in the preceding twelve 12 months, except in cases of gross negligence, in which liability is uncapped. """; var messages = new List<ChatMessage { new ChatRole.System, systemPrompt , new ChatRole.User, $"Analyze this contract excerpt:\n\n{contractExcerpt}" }; var response = await chatClient.GetResponseAsync messages ; Console.WriteLine response.Text ; Notice what's not here: no special "reasoning mode" flag, no separate SDK, no different message format. It's the exact same IChatClient call you'd make against any Foundry model. The reasoning happens because of how the model was built, not because of extra plumbing you have to write. Contract Risk Analysis Based off of the provided excerpt, I have identified the following clauses that pose financial or legal risk. --- RISK 1: Section 9.2 - Termination for Convenience Reasoning Step By Step: 1. Short Notice Period - The client only has to provide 5 days' written notice prior to terminating the agreement. This is an extremely short window for the vendor to adjust their operations. 2. Unrecoverable Costs - The clause only allows for fees for services rendered up to the termination date, with no early termination compensation. This means any upfront costs i.e: staffing, software, third party vendors, onboarding, or materials that were procured for the remainder of the work will not be reimbursed. 3. Opportunity Cost - With such a short notice period, the vendor may be unable to reallocate their resources to another client in time. This leads to lost revenue outside of what was already performed. 4. Imbalance of Power - This is a unilateral right for the client with no reciprocal protections for the vendor, opening up the door for abuse of this clause. Risk Severity: HIGH --- RISK 2: Section 11.4 - Liability Cap Reasoning Step By Step: 1. Disproportionate Cap - By limiting the vendor's total liability to only the fees paid in the preceding 12 months, the damages awarded could be massively disproportionate to the harm caused. For example, if a breach causes millions of dollars worth of damages, however only a small amount of fees were paid within the last 12 months, the vendor's exposure would be negligible compared to the loss. 2. Uncertainty With The Exception - The only exception to this cap is "gross negligence", which is a very high and fact specific legal standard to prove. This creates litigation uncertainty for both parties, as disputes may arise over whether the conduct met this threshold as opposed to ordinary negligence. 3. Uncapped Exposure - While the uncapped liability for gross negligence may seem reasonable on the surface, it creates uninsurable or unpredictable exposure for the vendor. Depending on the claim, this can be catastrophic from a financial standpoint. 4. Jurisdictional Enforceability - Depending on the governing law, liability caps are not always enforceable for certain claims i.e: fraud, willful misconduct, statutory violations, or certain types of data breaches , which could render parts of this clause void, causing further unpredictability. Risk Severity: HIGH --- Final Summary | Risk | Clause | Key Concern | Severity | Recommended Mitigation | | :-- | :-- | :-- | :-- | :-- | | Termination For Convenience | 9.2 | 5 day notice with no early termination fee, leading to unrecoverable costs and opportunity loss. | High | Negotiate a longer notice period e.g: 15-30 days , a termination fee based off of work scheduled, or a wind down reimbursement for committed costs. | | Liability Cap | 11.4 | Cap to 12 months of fees is disproportionate, with an ambiguous "gross negligence" exception that can lead to uncapped, unpredictable exposure. | High | Expand the cap carveouts carefully, define "gross negligence", consider a higher liability cap or a mutually agreed upon amount , and confirm compatibility with insurance coverage. | The use case Microsoft calls out explicitly — connecting to CRM, ERP, and ticketing systems through native tool calling — is where reasoning models earn their keep. A non-reasoning model will happily call a tool with garbage arguments and move on. A reasoning model is far more likely to check its own work before it commits to a tool call. Here's a minimal tool-calling setup using Microsoft.Extensions.AI 's function tools, written as a .NET single-file app :package directives, no .csproj needed — just dotnet run app.cs : :package Azure.AI.OpenAI@2.9.0-beta.1 :package Azure.Identity@1.21.0 :package Microsoft.Extensions.AI@10.9.0 :package Microsoft.Extensions.AI.OpenAI@10.3.0 :package Microsoft.Extensions.Configuration@10.0.0 :package Microsoft.Extensions.Configuration.EnvironmentVariables@10.0.0 :package Microsoft.Extensions.Configuration.UserSecrets@10.0.0 :property UserSecretsId=f8d4253e-5e0c-4aac-b93b-4e8e1d5d7b25 using Azure.AI.OpenAI; using Azure.Identity; using Microsoft.Extensions.Configuration; using System.ComponentModel; using Microsoft.Extensions.AI; await FunctionSample.RunAsync ; public class FunctionSample { public static async Task RunAsync { var config = new ConfigurationBuilder .AddUserSecrets<FunctionSample .AddEnvironmentVariables .Build ; var deploymentName = config "AZURE OPENAI DEPLOYMENT" ?? "mai-thinking-1"; var endpoint = new Uri config "AZURE AI ENDPOINT" ?? throw new InvalidOperationException "AZURE AI ENDPOINT is not set. Run: dotnet user-secrets set \"AZURE AI ENDPOINT\" \"<your-endpoint \"" ; IChatClient chatClient = new AzureOpenAIClient endpoint, new DefaultAzureCredential .GetChatClient deploymentName .AsIChatClient .AsBuilder .UseFunctionInvocation .Build ; var chatOptions = new ChatOptions { Tools = AIFunctionFactory.Create GetTicketStatus }; var response = await chatClient.GetResponseAsync "Ticket TCK-4471 has been open a while — what's going on and what should we do?", chatOptions ; Console.WriteLine response.Text ; } // A stand-in for a real ticketing system lookup Description "Looks up the current status and priority of a support ticket by ID." public static string GetTicketStatus string ticketId { return ticketId switch { "TCK-4471" = "Status: Escalated. Priority: Critical. Opened 6 days ago, SLA breached.", = "Ticket not found." }; } } The model decides whether it needs to call GetTicketStatus based on its own reasoning about the request — not because you hardcoded "if the user mentions a ticket ID, call the tool." That's the actual value proposition here: less prompt-engineering gymnastics to force sensible tool use. Ticket TCK-4471 — Current Status - Status: Escalated - Priority: Critical - Opened: 6 days ago - SLA: Breached So: it's a critical issue, already escalated, and it's been open long enough that the committed response/resolve time has been missed. What's going on interpretation - Critical impact : This is likely affecting production, revenue, security, or a major customer. Treat as high urgency. - Escalated : Support has already bumped it up likely to Tier 2/3, engineering, management, or a partner team . It's no longer being handled at the frontline only. - SLA breached 6 days open : The agreed SLA clock has expired. Expect pressure from stakeholders and potential contractual/experience impact. What you should do now 1. Acknowledge & set comms : Update the customer/stakeholder that it's escalated and you're actively driving it. Share next check-in time. 2. Own the escalation : Identify the escalation owner engineer/lead and a single point of contact. Confirm who is driving resolution. 3. Find the blocker : Check internal notes linked incident, reproduction, affected env, logs, PRs . Is it waiting on engineering, a vendor, data fix, or release? 4. Mitigate : Is there a workaround feature flag, rollback, hotfix, config change ? If yes, document and apply/communicate. 5. Escalate to leadership if stalled : If no movement today, loop in the escalation manager/incident commander; also consider incident post if prod is impacted. 6. Track and document : Log actions, update the ticket with ETA and next steps, and record SLA breach reason per process for reporting/compliance . Quick questions to answer next - Is there a linked incident e.g., SEV-1/INC-… ? What's the customer impact users affected, downtime ? - Who is the current assignee and last update time? Any dependencies third-party/vendor ? - What's the target resolution path rollback vs. fix vs. workaround ? If you paste the latest internal note or assignee, I can suggest a tighter action plan who to ping, what to ask, and a message template . Be honest with yourself about when you need this: Reach for MAI-Thinking-1 when: Don't reach for it when: Structured output, defensive parsing, and resilience patterns all still apply here exactly like they do with any other Foundry model — if you've read the earlier chapters on that, nothing changes; you're not throwing away any of the patterns you already have. MAI-Thinking-1 is Microsoft's first real swing at a reasoning model, and the fact that it drops straight into the same IChatClient abstraction as every other Foundry model is, frankly, the best part. No new SDK to learn, no separate reasoning-specific message format — just a model that's better at the multi-step, tool-calling, long-context work that "just answer the prompt" models tend to fumble. If you've been holding off on agentic workloads because the reasoning quality wasn't there yet, this is worth a real evaluation — not just a demo. Source code can be found at: github.com/taswar/MaiThinkingDemo https://github.com/taswar/MaiThinkingDemo Building AI features in C ? I write about practical, no-hype prompt engineering and Azure AI patterns for .NET developers. Check out Prompt Engineering for .NET Developers — free, no Python required. Also subscribe to my mailing list for the latest blogs, tips and tricks I share.