Most of the calls inside a production .NET agent are not “write me a paragraph.” They are small, repeated judgments: which team owns this ticket, is this reply promising a refund, how severe is this incident, should the agent continue or hand off.

Those steps still get sent to a frontier chat model because that is the client everyone already wired up. It works. It is also slow, expensive, and a little awkward — you ask for JSON, then you parse prose that almost looks like JSON, then you invent a confidence score the model never actually returned.

Microsoft-Decision-1, now in public preview in the Foundry model catalog, is built for the other job. It does not draft an answer. It scores a fixed set of options and hands your code a typed decision plus probabilities.

This post is the C# version of that idea. The official quickstart is Python. The API is just HTTP, so a console app and HttpClient are enough.

Sources for the numbers below: the Foundry announcement (October 9, 2026), the Command Line deep dive, and the Foundry how-to.


What a decision model actually returns

A generative model produces text. Microsoft-Decision-1 produces a judgment about text or JSON you already have.

You send:

  • a state — the thing being judged (a string, or a JSON object)
  • one or more questions, each with a type and a closed set of options

You get back an answers object keyed by your question names. No rationale. No tool calls. No “here is my reasoning.” Your application is supposed to act on the numbers: route, gate, rank, or escalate.

Microsoft describes four places this shows up inside an app:

  • Classification — intents, themes, document types
  • Routing — which model, tool, team, or workflow
  • Evaluation — does this draft meet the rubric
  • Workflow control — continue, retry, stop, or send for review

The current model is post-trained from Qwen3.5-9B for single-pass decision scoring. Microsoft says later versions will be rebased on MAI and OpenAI models. Treat the weights as a preview, not a frozen contract.


Three question types, not a prompt template

The request is not a chat completion. It goes to the Microsoft provider route on your Foundry resource:

POST {resource-endpoint}/providers/microsoft/v1/systemone

The model field is your deployment name, not the catalog name. The response model field can still say microsoft-decision-1. That mismatch is expected.

Question JSON type What you get
Is this true? noul A probability from 0 to 1
Which option is it? choice One selected label, plus a probability for every label
How much? score A value on an ordered scale, plus a probability per level

criteria is a dictionary for choice and noul (optional on noul). For score it is an array ordered from lowest to highest. The score is a probability-weighted average of the level indexes, so a four-level scale (0 through 3) can land between levels. Use it for ordering and thresholds, not as a calibrated star rating.

Questions that share the same state can ride in one request. That is the pattern worth copying: route the ticket, score severity, and check “is this a repeat?” without three round trips.


The numbers worth arguing about

Microsoft published these from internal evals. They are not your workload. They are the reason to run your own labeled set before you swap a GPT deployment out.

Claim Source figure
Latency vs GPT-6 Sol About 35× faster (P50); also described as 35× quicker in the 36-benchmark timing run
Latency vs H2O-Lightning-4B v1.1 2.5× quicker than the runner-up
Held-out quality Highest accuracy in a 36-benchmark comparison, nearly 150,000 questions kept blind from training
Robustness Decision flips on 1.3% of perturbations on average; 0 flips when option text is paraphrased or options are reversed or shuffled
Safety screen 5,250 requests across 11 benchmarks (harmful content, jailbreaks, prompt injection)
Xbox Research labeling 10,000+ feedback items. Command Line: competitive with GPT-6 Sol, 14× faster, 200× cheaper. The Foundry blog states a different comparison: competitive with GPT-5, 80–100× faster. Do not collapse those into one number.
Copilot response grading Competitive with GPT-5.6 Luna, about 100× faster
Microsoft Discovery replanning 46× more consistent than the LLM score, 3× the scoring speed, nearly 4× end-to-end replanning speed
Price $0.042 / 1M input tokens. Output tokens are not billed. US and EU Datazone are both listed at that input rate.

Deployment types in docs are DataZoneStandard (inference stays in the data zone, where available) and GlobalStandard. Preview capacity and region list will move — check the catalog page before you promise a latency SLO.

Also available through OpenRouter. This post stays on the Foundry resource endpoint and Entra ID.


Where it fits in a .NET app

Use it when the next step is a closed choice:

  • Route a support ticket before a human or a bigger model ever sees it
  • Pick which tool or model an agent should call
  • Grade a draft against a rubric and accept, revise, or escalate
  • Gate a tool call (“does this touch production data?”)
  • Label feedback, scan code against a checklist, rank search hits

Do not use it when the product needs the words. Summaries, rewrites, explanations, and open-ended plans still belong on a generative model. The useful architecture is both: Decision-1 decides, the chat model writes.

Two constraints from the docs that should be in the design review, not the footnote:

  • It does not explain itself. If a regulator or a user asks “why,” you need a different model or a human.
  • Do not let it be the only decision-maker for credit, employment, housing, healthcare, or legal outcomes. Microsoft’s own guidance is decision support plus review. It can also reflect bias from the base model, and calibration is strongest on task types it has seen.

Low top-probability is your abstain signal. Add an explicit cannot tell option when a forced label would be worse than a queue.


Calling it from C#

There is no dedicated .NET SDK method in the quickstart. Azure.Identity plus HttpClient matches the documented contract: bearer token for https://cognitiveservices.azure.com/.default, JSON in, JSON out.

Deploy Microsoft-Decision-1 from the catalog first (GlobalStandard, or DataZoneStandard when you care which data zone runs the inference). The secret value must be the deployment name shown on the deployment page.

Output


What I would measure before production

The three-row sample in Microsoft’s quickstart is a smoke test, not an eval. Before this sits on a hot path:

  1. Build a labeled set from your own tickets, including the ambiguous ones.
  2. Report accuracy and the cases where the top probability was high and the label was wrong. Calibration matters more than the leaderboard once you threshold at 0.8.
  3. Time it from the same region as the app. Client plus network time is what users feel. Sequential calls do not tell you p99 under load.
  4. Shuffle option order on a copy of the set. Microsoft reports zero flips on shuffle for their suite; confirm that on yours.
  5. Put the abstain path in the same PR as the happy path. A classifier with no “not sure” bucket will invent confidence.

Cost is the easy part of the spreadsheet. At $0.042 per million input tokens and no output charge, the bill is dominated by how much state you stuff into every call. Keep the state to the fields the question needs. Do not paste the whole thread if the question is “which team.”


A practical split

If you already have a Foundry chat deployment for drafts and summaries, leave it there. Put Microsoft-Decision-1 in front of it for the closed questions: route, severity, policy gate, “is this draft good enough to send.”

That is the design the model is actually for. Not a smarter chatbot. A fast, cheap, typed branch in the application you already shipped.

Wrapping up

Most of what a .NET app does in a loop is not writing. It is choosing: which team, which tool, continue or stop, accept or revise. Microsoft-Decision-1 is built for those choices, and it returns numbers your code can act on.

I would not replace a chat model with it. I would put it in front of one. Run it on a labeled sample from your own workload first, look at the confident mistakes, and only then wire the threshold into production.

Resources

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. You can also subscribe for more posts.