Newsletter
Join the Community
Subscribe to our newsletter for the latest news and updates
The expensive part of an agent is not always writing code or prose. Sometimes it is asking a big model to answer a small, repeatable question: does this ticket need escalation, did the tool call cross a policy boundary, or which route should the next step take? Microsoft Decision-1 is interesting because it is built for that narrower job. The practical case is a controlled trial at one gate in an existing workflow—not a swap for the model that does the thinking.
Microsoft Decision-1 is a decision-scoring model released on October 9, 2026 for applications that need a bounded choice rather than generated prose. Microsoft's launch post says it is available through Microsoft Foundry and OpenRouter for routing, classification, prioritization, verification, and workflow control. The Foundry documentation describes a request that supplies text or JSON plus typed questions, then returns a numerical decision that software can threshold or rank. An independent launch report confirms the release facts while noting that its performance claims have not yet been independently evaluated. The useful mental model is a gate, not a brain: give it a constrained decision with an explicit fallback path. That makes it potentially useful for agent routing and safety checks, but it does not remove the need to validate errors, thresholds, and escalation rules against your own labeled examples.
The public evidence supports a narrow conclusion. Microsoft has released a deployable decision API with documented input and output shapes, while independent coverage confirms the launch and explicitly separates it from a third-party result. That is enough to evaluate whether a typed gate fits a real workflow. It is not enough to declare the model accurate for every routing, policy, or safety judgment.
This article therefore treats Microsoft’s product description and API documentation as confirmed release facts. It treats the recommendation to try one reversible gate as an inference from that documented shape. It does not use vendor performance assertions as a purchasing claim, and it does not pretend that a launch report replaces an evaluation on a team's own labeled data.
Microsoft announced Decision-1 on October 9 as a new decision-scoring model in Microsoft Foundry, with a separate deployment guide and an API built around typed questions. The differentiator is not a better chat response. It is a response shape designed to be consumed by software: a probability for a yes-or-no choice, one selected option from a bounded list, or a value on an ordered scale.
Source: Microsoft's Decision-1 launch post. The official launch card identifies the product announcement; it does not prove accuracy, latency, or production reliability.
Microsoft's documentation frames the input as a state value—text or JSON—plus one or more typed questions. A binary question returns a probability from zero to one; a choice question returns one selected option and a probability for each option; a score question returns a value on an ordered scale. This is useful when an application needs a predictable object rather than a paragraph it must parse.
That constraint is also the catch. A model can only make a defensible choice when the options and criteria are defined well. If the decision is ambiguous, high-impact, or missing context, a clean JSON response can still be wrong. Treat the probability as an input to policy, not policy itself.
Start with one reversible decision. A support-ticket classifier is the obvious example because the Foundry quickstart already shows that shape. Build a labeled holdout set, choose a confidence band that sends uncertain cases to a human or existing rule, and log both the raw state and the eventual outcome.
The useful question is not “can this replace our agent?” It is “does this improve one gate without making the failure harder to see?” Keep a general model, deterministic rules, and human review where they already earn their place. Then compare the new gate with the baseline on false accepts, false rejects, fallback rate, and recovery cost.
Decision models make agent architecture easier to talk about. A conversational model is good at producing an answer; a bounded decision model is designed to choose from an answer space you specify. That split may help an app feel less random, particularly when each downstream action has a clear owner and an escape hatch.
It is not a consumer feature to turn on in a chat window. It is infrastructure for a product team that can define what “yes,” “no,” “needs review,” or “route B” actually mean. If your workflow has no measurable decision boundary, this release gives you little to deploy.
My take: Decision-1 is most interesting when it replaces a vague “ask the agent what to do next” prompt with a small, inspectable decision. That is a better reason to test it than any headline about raw model performance.
What is Microsoft Decision-1?
Microsoft Decision-1 is a Microsoft Foundry model for structured decisions such as routing, classification, prioritization, verification, and scoring. Rather than writing a free-form answer, its documented API returns typed numerical results for a supplied state and bounded questions. It is intended for application workflows, not as a general chat replacement.
Is Microsoft Decision-1 available now?
Microsoft announced Decision-1 on October 9, 2026 and says it is available through Microsoft Foundry and OpenRouter. The Foundry guide lists an Azure subscription, Foundry access, a project, deployment permission, and authentication as prerequisites. Confirm current regional availability and account requirements before committing a team to an integration.
How is Decision-1 different from a general language model?
A general language model normally produces text or a multi-step explanation. Decision-1 is documented to return a probability, selected option, or ordered value for a state and typed question. That can make an application response easier to threshold and audit, but it does not eliminate ambiguity in the input or guarantee a correct decision.
What should developers test before using Decision-1?
Test a narrow, labeled task alongside the current baseline. Measure false accepts, false rejects, uncertain-case fallback, latency, and the cost of each recovery path. Set a conservative threshold, preserve deterministic or human review for uncertain cases, and inspect errors before the model controls an irreversible action.
What is still unverified about Decision-1?
The release and documentation establish the product and API contract, but public launch materials are not a third-party evaluation of a team's own workflow. Teams should verify accuracy on representative data, threshold calibration, availability, pricing, licensing, and how the model behaves when options or input context are incomplete.
Discover practical AI products and emerging tools at AIToolHunt.
