Python: [Feature]: Support Microsoft-Decision-1 (Microsoft Foundry) through the TypeSafe connector #9489

Problem

Microsoft released Microsoft-Decision-1 in Microsoft Foundry on 9 October 2026, a decision model for routing, classification, validation and workflow control. Foundry serves it on the System One protocol, the same contract that agent-framework-typesafe already implements: POST <resource endpoint>/providers/microsoft/v1/systemone, with the key sent as a bearer token and the deployment name as model.

Agent Framework users who want a first-party decision model at agent decision points (judge, routing, tool gating) have no documented way to call it from Python today.

Use Case and Evidence

TypeSafeChatClient already accepts a base_url and appends /v1/systemone, so pointing it at https://<resource>.services.ai.azure.com/providers/microsoft may already work with an API key. This is not documented or tested, and there is no Microsoft Entra ID authentication path, which most enterprise Foundry deployments require.

Example scenario: an agent routes incoming support tickets with a Choice question (billing / engineering / sales) and hands off to a human when the top probability is below a threshold. The same Questions / SystemOneResponse code should work against Jev or a Foundry deployment of Microsoft-Decision-1.

Desired Outcome

Python users can call a Microsoft Foundry deployment of Microsoft-Decision-1 from Agent Framework, with either an API key or Microsoft Entra ID, using a documented and tested configuration and a sample.

Alternatives Considered

• Pointing the existing connector at the Foundry endpoint through base_url: may work with an API key, but it is undocumented, untested and has no Entra ID option.
• Calling the REST endpoint directly outside the framework: loses the chat client integration (agent loop judge, tool planning, structured SystemOneResponse).

Proposed Direction

1. Document and test calling a Foundry deployment of Microsoft-Decision-1 with the existing connector (base_url, deployment name as model, API key).
2. Accept an async token credential (azure.identity) as an alternative to api_key, sending the Entra token as the bearer.
3. Add a sample (for example, ticket routing with a Choice question and a confidence threshold that hands off to a human).

Question for maintainers: should this live in the TypeSafe package (shared protocol), or in a separate foundry decision client aligned with the .NET IDecisionClient work in #8562 / #8563?

I don't have a Foundry deployment to run a live test, so the PR would include offline tests based on the documented request and response contract. Validation by someone with access would be welcome.

Scope and Non-Goals

• No change to the TypeSafe (Jev) behaviour or defaults.
• Text input only: Microsoft-Decision-1 does not accept images, so the image and Box support from Python: TypeSafe connector should support image inputs and Box questions (Jev 1.14) #9410 does not apply to it.
• .NET is out of scope here (see Python: .NET: [Feature]: Add IDecisionClient (reference of dotnet/extensions#7764), DecisionLoopEvaluator, and a TypeSafe (Jev) provider package #8562 / .NET: Add IDecisionClient (experimental), DecisionLoopEvaluator, and the Microsoft.Agents.AI.TypeSafe (Jev) provider #8563).

Language

Python

Contribution Intent

I am willing to implement this

Acknowledgements

• I searched existing issues and did not find a duplicate.
• I will wait for explicit maintainer agreement before starting implementation of a non-trivial change.