Support Signal
Turn a support request into a proposal a person can inspect, correct, and approve.
- One code-defined agent in the live application
- Output contracts and exact quoted evidence
- Human edits that invalidate approval
MICROSOFT FOUNDRY / FOR .NET DEVELOPERS
Go beyond the model call. Build applications that validate answers, expose uncertainty, and keep people in control.
FOR DEVELOPERS WHO KNOW C# AND JSON
Start with a synthetic case. Follow it from input to output, through application checks, and into human review. Then open the C# and reproduce the behavior in your own checkout.
AVAILABLE NOW
Start with Lab 001 for validated proposals, then Lab 002 for probability-based decisions. Either guide can be followed independently.
Turn a support request into a proposal a person can inspect, correct, and approve.
Use bounded choices and probabilities to decide which bid items need a person.
The guides include the problem, responsibility boundary, one case, C# entry points, a presentation route, and evidence limits. The apps and their setup instructions live in the repository.
A REPEATABLE LEARNING PATH
Read one synthetic input before looking at the answer. Separate what was reported from what has been verified.
Simulation, replay, and live inference are different. Know which one produced the output before interpreting it.
Find the input contract, provider boundary, output checks, and business rule. Valid structure does not establish semantic correctness.
Change a quote, a threshold, or a reviewed answer. Observe what changes and what still requires human judgment.
The website itself needs only a browser. The .NET apps need Git, PowerShell 7, and the exact SDK in global.json: .NET 11 RC1. The Lab 001 Foundry connector and Lab 002 decision model are treated as preview in this snapshot.
.\scripts\Test-Prerequisites.ps1
.\Start-Demo.ps1 -Lab 1 -Offline
# Or, in a separate terminal:
.\Start-Demo.ps1 -Lab 2 -OfflineLab 001 opens at http://localhost:5187; Lab 002 at http://localhost:5190. Package restore can require internet even in offline mode. Stop each server with Ctrl+C.
COMING NEXT / NOT IMPLEMENTED
The proposed sequence adds one lesson at a time. These are planned labs, not available guides, release dates, or authorization to provision services.
003 / NEXT PLANNED LAB
Draft a clarification for a line that needs review. Keep a person in control, and send nothing.
004 / PLANNED
Explore the boundary between application code, an agent hosted in Foundry, and its tools.
005 / PLANNED
Explore scheduled review and how reviewer corrections could inform later work.
006 / PLANNED
Evaluate labeled cases, trace decisions, and investigate changes to agent instructions.
007 / PLANNED
Explore a voice interface for questions about a bid line, without hiding the review boundary.
008 / PLANNED
Explore a team-facing agent and the identity, access, and approval requirements around it.
This is our proposed teaching sequence, not a claim that these implementations exist. Capability prerequisites and preview labels are recorded in the repository roadmap and must be rechecked before each lab ships.
Read the learning roadmapBEFORE GOING LIVE
These pages do not call Azure. Live app runs require your selected deployment and explicit authorization for inference charges. Hosting is a separate choice.
A failed live call stays an error. A presenter can switch explicitly to an offline path, but must not call that a successful live retry.
Simulation is not AI-quality evidence. Replay is not current service availability. Synthetic evaluation is not an industry benchmark.
The labs teach local review, not durable audit trails. Use synthetic data and keep credentials and customer content out of demonstrations.
Each lab guide distinguishes documented capabilities, sample design choices, and dated observations. This is an independent educational project, not a Microsoft product or a production-ready application.
The model is one part.
Understand the whole decision.