.NET + FoundryBETTER TOGETHER
← All episodes

EPISODE 01

.NET + Foundry, Better Together: Decision Models in Action

With Bruno Capuano and Pablo Piovano

Watch on the .NET Channel ↗Watch on Microsoft Reactor ↗ Reactor event page ↗ View on GitHub ↗
Microsoft-Decision-1Decision modelsChoices in C#AI-powered games

Date: October 15, 2026, 12:00-1:00 PM EDT (16:00-17:00 UTC).

Event and registration: Microsoft Reactor

Hosts

Overview

Explore Microsoft-Decision-1 and the emerging category of decision models, then put decisions to work in .NET 10 and C#. Start with a bounded choice in Foundry, compare decision and generative model approaches, try decisions in review workflows, and finish by watching a model choose actions in games. The console space game is the main finale; a graphical platformer and MonoGame space game are optional extensions.

Decision flow illustration: a .NET application observes a game, support ticket, or answer; presents bounded choices; validates the selected action; and applies it.

Decision models return bounded, typed results for the choices your application defines; they don't write a free-form answer or explanation. In these examples, application code remains in control: it validates results and applies game actions. Model scores and probabilities are useful signals, not guarantees of correctness. The .NET decision samples use the community ElBruno.AI.Decisions SDK, not an official Microsoft SDK.

Official Microsoft resources

Recording

Both links are replays of the October 15, 2026 episode.

Guest demos and resources

Co-host Pablo Piovano shared demos from Foundry Field Notes labs, his independent educational repository of hands-on Microsoft Foundry labs in .NET. Explore its available labs:

  • Support Signal: turn a support request into a proposal, validate quoted evidence, and keep a person in control.
  • Bid Review Queue: ask bounded questions with Microsoft-Decision-1, interpret probabilities, and send uncertain answers for human review.

These labs have their own pinned SDK versions, prerequisites, live configuration, costs, and cleanup instructions. Follow their READMEs rather than this repository's demo setup. Their offline paths use explicitly labeled simulation or saved-response replay, not new model inference.

Demos and resources

Recommended learning order (folder numbers now match the walkthrough):

  1. Hello Decisions: one console app, one prompt, one decision using the community SDK.
  2. Hello Decisions with Ollama: the same prompt, labels, and output with a local native decision client.
  3. Same question, two models: MEAI chat versus native decision SDK, elapsed time and SDK-exposed usage.
  4. Support inbox triage: Choice, Score, Assess, and application-owned review policy for one synthetic ticket.
  5. Answer-quality review: model-assisted review, not automatic approval.
  6. Decision Lab: Blazor, parallel repeated questions, live usage totals, cancellation, and Aspire GenAI traces.
  7. Decision Space Game: apply decisions in a running simulation.
  8. Platformer decisions: optional graphical extension with live game-state observations, fixed-step movement/jump controls, and asynchronous Foundry or Ollama decisions.
  9. Decision Space Game: graphical finale: MonoGame welcome screen, generated spaceship art, manual play, and explicit Foundry/Ollama takeover using the console game's rules.
  10. Decision Space Game v02: the same rules and decisions, with a light/dark streaming layout, larger smooth ships, and a larger font. Demo 09 stays unchanged.

The original walkthrough remains demos 01 through 07. Demos 08, 09 and 10 are optional extensions, not replacements or renumberings of the existing game.

What we'll explore

  • Meet Microsoft-Decision-1: where decision models fit beside generative models, and when a C# application needs a bounded choice rather than generated prose.
  • Make native decisions: use the Foundry decision API with choice, score, and yes/no questions; compare its structured results with a generative model.
  • Put decisions to work: explore ticket triage, answer-quality review, confidence and probability signals, and application-owned human review.
  • Let decisions play: map bounded model choices to legal actions in a console space game, with optional graphical platformer and MonoGame extensions.
  • Keep software in control: the application owns game rules, movement, action validation, and whether a model suggestion is applied.

Existing project names and user-secrets IDs are unchanged; the new Ollama sample has its own ID. Update local working-directory shortcuts to the new paths. Each introductory console sample has one commented Program.cs, no command-line options, and runs with dotnet run. Change the prompt directly in source. The game has a similarly small entry point, with the simulation/rendering kept separately. The larger Blazor demo uses Aspire and has its own run instructions. Decision SDK 0.6.3 exposes provider-reported token usage in both comparison demos. Live native Foundry input/output counters work; omitted totals stay not reported, not inferred. The shipped feature is elbruno/ElBruno.AI.Decisions#4. All decision samples pin 0.6.3, whose GitHub release remains marked tentative early access. Foundry Choice/Score/Assess and local nimble usage were live-tested; provider/version-specific availability can still differ.

Configure all samples

Requires PowerShell 7 and the .NET 10 SDK. From this episode directory, before recording or screen sharing:

pwsh -File .\Setup-UserSecrets.ps1 -ValidateOnly
pwsh -File .\Setup-UserSecrets.ps1

Setup-UserSecrets.ps1 discovers runnable sample projects, prompts once for the Foundry resource root and deployment name, and imports configuration into the nine Foundry apps' separate user-secrets stores. Ten runnable apps are discovered in total, including local-only demo 02. The helper excludes Aspire AppHost/ServiceDefaults and test projects. It also asks for a generative deployment on that same resource for demos 03 and 06. Press Enter to accept gpt-6.1-sol, or type your actual deployment name. Choose Azure CLI identity (the default) or enter a key through hidden input. Identity mode removes any stored Foundry:ApiKey so a stale key cannot override identity authentication. Run az login separately and ensure your identity has deployment access.

Optional Ollama prompts configure demo 02 and the O modes in demos 07, 08, 09 and 10. Press Enter at the model prompt to accept nimble, or type another compatible installed decision model name. Demo 02 remains local-only, without Foundry values or keys. They do not install Ollama or download a model. Skipping Ollama leaves that project's existing settings unchanged. To run only demo 02, its README also provides direct local configuration commands without requiring Foundry access. Environment variables override user secrets, so remove conflicting Foundry__* variables when changing authentication mode.

The script does not display supplied values, pass keys as process arguments, write configuration into this repository, or run chargeable inference. Prompts for non-key values are visible while you type, so do setup off-stream. .NET user secrets are unencrypted local development storage, not a production vault. Imports replace the named keys but preserve unrelated secrets. If setup fails midway, earlier projects may already be updated; fix the reported prerequisite and rerun. Use dotnet user-secrets remove "<key>" --project "<project.csproj>" for each configured key when cleaning up. Never display user-secrets list on stream.

The setup script has non-writing tests:

pwsh -File .\tests\Setup-UserSecrets.Tests.ps1

Related resources

Back to the series