When it comes to AI applied to software, the discussion almost always ends up on Python. It's normal: training, data science and research have been gravitating around that ecosystem for years, on the other hand the AI ecosystem was born mainly in Python, moreover those who develop AI models are normally not enterprise backend developers, but come from mathematics / physics / data science / machine learning.
Python is much easier to learn than C# or Java and has become the de facto standard.
When a new technique or model comes out, the first implementation is almost always in Python.
But integrating AI capabilities into an enterprise application is a different problem. So perhaps the question to ask is: Do you really need Python to develop AI applications? In this article, we look at the tools available in .NET
If your stack is already based on ASP.NET Core, C#, and well-structured backend services, you can now develop AI applications while maintaining the same architectural approach. Dependency injection, logging, configuration, middleware, and application services remain the same. The components you connect to the system change.
In this scenario, Microsoft.Extensions.AI is particularly interesting, because it introduces common abstractions to interact with different models and providers without disclosing proprietary details in the application code.
To do AI you don't need to change stacks
This doesn't mean that .NET replaces every other tool. However, it means that for many typical use cases of software houses — business assistants, semantic search, classification, guided generation, RAG, tool calling — the Microsoft ecosystem is now sufficiently mature.
- you can keep the application domain in C#;
- you can isolate the provider behind interfaces and services;
- you can use ASP.NET Core's native dependency injection;
- you can integrate logging, retry, metrics, and caching;
- you can link the model to .NET functions without having it touch the database directly.
The key point
To integrate AI into an enterprise application, the problem is not just calling a model. The problem is to do it in a way that is consistent with the security, architecture, permissions and maintainability of the system.
What is Microsoft.Extensions.AI
Microsoft.Extensions.AI is a collection of shared abstractions for generative AI components. The goal is to allow a .NET application to work with different providers through common contracts.
In practice, it means being able to model application code around interfaces such as IChatClient and IEmbeddingGenerator, instead of depending directly on a specific SDK.
public sealed class DocumentAssistant
{
private readonly IChatClient _chatClient;
public DocumentAssistant(IChatClient chatClient)
{
_chatClient = chatClient;
}
public async Task<string> SummarizeAsync(
string content,
CancellationToken cancellationToken)
{
var response = await _chatClient.GetResponseAsync(
$"Summarize the following text:\n\n{content}",
cancellationToken: cancellationToken);
return response.Text;
}
}This setting helps above all to keep the boundary between the application domain and inference technology clear.
Tool calling: Exposing .NET functions as tools
One of the most useful scenarios is tool calling: the model can select a tool, propose parameters, and receive the result returned by a .NET function.
The advantage is not the automation itself, but the control. The available functions remain explicit, parameters can be validated, and the application continues to manage permissions, rules, and audits.
- the model interprets the request;
- The application exposes a limited set of tools;
- the backend validates the parameters;
- the .NET function performs the authorized operation;
- the result is part of the conversational flow.
This is an important difference from the much riskier idea of allowing a model to interact freely with the database or uncontrolled APIs.
Embeddings, vector stores and semantic search
When the goal is to retrieve content that is similar in meaning, embeddings come into play. Abstraction helps IEmbeddingGenerator generate vector representations that can be reused across multiple components of the application.
From here the next step is the vector store. With Microsoft.Extensions.VectorData , Microsoft provides an abstraction layer for reading, writing, and querying vector data without tying the entire project to a single database or service.
The practical result is a cleaner foundation for building features such as:
- semantic search on documents;
- retrieval of content for RAG systems;
- meaning-based recommendations;
- Connecting natural language queries and the enterprise knowledge base.
Data ingestion: preparing content for RAG
Retrieving relevant documents is only useful if the content has been prepared correctly. The quality of a RAG system depends a lot on the ingestion pipeline: extraction, cleaning, chunking, metadata, and indexing.
In this area, Microsoft provides components and concepts that are described in the .NET's Data Ingestion documentation. It is a less spectacular theme than prompt engineering, but often much more decisive for the final result.
Common Mistake
Attribute problems to the model that actually result from cluttered documents, chunks that are too large, missing metadata, or outdated sources.
Evaluation: the part that is often missing
Another interesting element is the evaluation area. With the libraries described in the Microsoft.Extensions.AI.Evaluation documentation, you can set up more repeatable checks on the quality of your responses.
This is important because a convincing demo is not enough. In production, it is worth measuring:
- adherence of the response to the sources;
- completeness;
- relevance of retrieval;
- correctness of the format;
- correct rejection rate when the data is not sufficient;
- latency and cost.
When updating a model, prompt, or recovery pipeline, a repeatable test base helps you understand if your system is really improving.
When to use Semantic Kernel
Then there is the Semantic Kernel in the Microsoft landscape, which ranks higher than the fundamental abstractions of Microsoft.Extensions.AI.
While Microsoft.Extensions.AI helps build a clean, provider-independent foundation, Semantic Kernel adds plugins, orchestration, memory, and patterns that are better suited to agentic or more advanced scenarios.
You don't always need to start from there. In many cases, a well-designed application service, with IChatClient, embeddings, and a controlled retrieval, is more than enough. Semantic Kernel becomes interesting when orchestration needs begin to grow.
A concrete example: the AI assistant I developed for SmartestTour
A concrete example of the use of AI in a ASP.NET Core application is SmartestTour, a multitenant platform that I designed and developed to help small Tour Operators and local guides publish their catalog and collect requests for quotes.
Within the platform, I have integrated an AI assistant that uses as context the information actually present in the catalog of the individual operator: descriptions, itineraries, destinations, characteristics and available details.
Architecturally, ASP.NET Core continues to manage tenants, catalog, users, and application rules. The AI component, on the other hand, is responsible for interpreting the question, retrieving the available context and generating an answer within limits defined by the application.
Why this example is relevant
To build the chatbot, I didn't have to introduce a separate application stack. I integrated the AI capabilities directly into my existing .NET architecture, maintaining control over the data provided to the model, the limits of the responses, and the behavior of the assistant.
You can learn more about the project in the SmartestTour portfolio page or visit the platform directly.
What these tools don't solve automatically
The ecosystem is mature, but it's not magical. Libraries are not a substitute for some design decisions that remain fundamental:
- what data can be sent to the model;
- how to apply permissions;
- how to avoid prompt injection and hostile input;
- how to validate outputs and proposed actions;
- when to stop and declare that the information is not enough;
- which metrics to use to evaluate quality.
In other words: the tools facilitate integration, but the architecture and governance of the system remain the responsibility of the application.
When does it make sense to use these tools
| Requirement | Tool | Practical value |
|---|---|---|
| Call a chat model | Microsoft.Extensions.AI | Common abstraction and cleaner code |
| Generate embedding | IEmbeddingGenerator | Semantic search and RAG |
| Exposing C# functions to the template | Tool calling | Controlled integration with the backend |
| Abstract a vector store | Microsoft.Extensions.VectorData | Less Provider Coupling |
| Prepare documents for retrieval | Data Ingestion | Stronger RAG pipeline |
| Evaluating responses | AI Evaluation | Repeatable testing and continuous improvement |
| Manage Plugins and Agent Scenarios | Semantic Kernel | Higher Level Orchestration |
FAQ
Do I have to leave C# to use AI in .NET?
No. For many application scenarios, you can integrate generative, embedding, and retrieval models directly into C#, while maintaining your existing .NET stack.
Microsoft.Extensions.AI replaces Semantic Kernel?
No. The two instruments are on different levels. Microsoft.Extensions.AI provides fundamental abstractions, while Semantic Kernel adds more advanced plugins and patterns.
Can I build a RAG system with these tools?
Yes, but quality also depends on ingestion, metadata, retrieval, authorizations and evaluation. The libraries help, but they do not replace design work.
Microsoft.Extensions.AI avoid lock-in?
It reduces the coupling with the provider, but it does not eliminate all the differences between models and services. The goal is to make the application code more stable and maintainable.
Why mention SmartestTour in this context?
Because it is a real example of AI integration carried out in ASP.NET Core, useful for showing that these concepts can be applied in a product developed and managed in the first person.
In summary
With .NET, you can build AI applications without sacrificing your architecture.
Microsoft.Extensions.AI and related libraries do not replace design work, but make it much more concrete to integrate chat, embeddings, tool calling, vector stores and evaluation into a modern .NET application.
Related Guides
Want to integrate AI capabilities into an existing .NET project?
I can support software houses and development teams in the design of the architecture, in the choice of the most suitable Microsoft tools and in the controlled integration of AI, RAG, API models and workflows within .NET applications.