Most AI training and most AI experts start from Python. That is a logical choice: the AI ecosystem (notebooks, libraries, community) grew up there. But after fifteen years delivering information systems in .NET and Angular, across contexts as different as private banking, offshore industry and the public sector, I keep running into a problem that “just use Python” does not solve: a company’s application estate is not written in Python. It is written in .NET, in Java, in SQL Server, in business applications that have been running for ten or fifteen years.

The problem I see at client sites

A company that wants to “do AI” ends up facing a badly framed choice: either hand the subject to Python specialists who do not know the existing IT estate, or let the .NET teams improvise without an AI culture. Either way, the outcome is the same: a prototype that stays a prototype, or a bolted-on integration sitting next to the information system instead of inside it.

Semantic Kernel: plug in, do not rewrite

That is the problem I set out to address when I earned the Microsoft Applied Skills AZ-2005 credential (“Develop generative AI apps with Azure OpenAI and Semantic Kernel”), a hands-on lab assessment that covers building generative AI solutions with Azure OpenAI and Semantic Kernel. What interests me about Semantic Kernel is not the technical novelty: it is that it does not require rewriting what already exists. The framework lets you plug language models, RAG (see RAG on an existing .NET estate) and agents directly into business logic that is already written, tested and audited in C#.

In practice, this means the business rules that protect an application (checks, validations, workflows) stay exactly where they are. AI gets added as a new capability, not as a chatbot sitting next to the system, disconnected from the rules that keep the application running day to day.

The pattern I apply on engagements

This is exactly the approach behind my AI integration for .NET applications service: automated document extraction (the document AI pipeline I put into production), a correction loop that learns from mistakes, business rules that can be reconfigured without redeploying, direct persistence into existing databases. This pattern (AI proposes, a deterministic layer validates, a human decides on ambiguous cases) is what makes an AI system hold up in production over time. I cover it in detail in AI proposes, deterministic logic disposes.

What is next

This Applied Skills credential is only one step: the roadmap continues with AI-103 (Azure AI Agent Developer). This blog documents these field notes as engagements progress, with a single thread running through all of them: AI that creates value for a business is AI that integrates into what already exists, not AI that ignores it.

Update, 30 September 2026. Microsoft shipped Agent Framework 1.0, the successor to Semantic Kernel, on 3 April 2026, and Semantic Kernel has moved to maintenance. The reasoning above holds: plug AI into the existing .NET estate rather than rewrite it. What changes in the code, and when to migrate, is covered in the guide Semantic Kernel or Microsoft Agent Framework.

Sources and references

Semantic Kernel.NETAzure OpenAICertification

Read next

Take it further

Rewrite, or wire AI into the .NET estate you already run?

For mid-caps and software vendors whose IT lives in .NET and SQL Server: AI developed inside your application (document extraction, agents, classification) with your business rules, your architecture, your code. Not another tool next to the IT system: a new capability inside it. I work in your repo, alongside your developers, to your team's standards.

Let's talk about your IT system →