Editorial illustration.
Originally published 21 June 2023; rewritten and reviewed on 15 October 2026.
A request to “add AI” leaves an important question unanswered: what should the application do better? A classifier, a document assistant and a recommendation feature have different data, evaluation and runtime needs. I would begin by writing the expected result in ordinary product language.
Choose the approach after defining the task
For structured machine-learning work in a .NET application, ML.NET is one option to investigate. An external model API may fit a different requirement, while a simple deterministic rule may be sufficient for a narrowly defined case. The libraries listed in the original 2023 article are a historical starting point, not an assertion that every package remains maintained.
Describe the input, expected output and failure cost. For example, routing support messages requires categories and examples of ambiguous cases; generating a customer response also requires a policy for checking the text before it is sent.
Keep evaluation separate from training
Use representative data that you are authorised to process. Keep a held-out evaluation set and compare the proposed feature against a straightforward baseline. A model that recognises examples it has already seen has not established that it will work on new cases.
Inspect the mistakes, not only an aggregate score. A rare but expensive error may matter more than a small improvement on common examples.
Design the application boundary
Validate the model’s output before allowing it to change records or trigger an external action. Define timeouts, fallback behaviour and observability. Record the model and configuration version so a changed result can be investigated.
A useful first delivery is a small feature with an evaluation report, a known limitation and a recovery route. That makes the AI component part of the application’s engineering discipline rather than an impressive result that nobody can reproduce.