Hello, Semantic Kernel!

In March 2023, Microsoft published a short but significant post on the devblogs site introducing Semantic Kernel, an open-source SDK meant to help developers mix regular programming languages like C# and Python with large language model prompts. At the time, GPT-4 had just released and every enterprise team was trying to figure out how to wire LLMs into existing applications without rebuilding everything from scratch. This post was Microsoft’s answer for the .NET and Python crowd, and it is worth revisiting because it set the vocabulary that a lot of Azure AI tooling still uses today.

What problem Semantic Kernel was solving

Before frameworks like this existed, calling an LLM from your app meant writing your own prompt management, your own retry logic, your own way of chaining one model call into the next, and your own glue code to let the model call into your existing services. Every team was reinventing the same plumbing. Semantic Kernel packaged that plumbing into a lightweight SDK so you could focus on what the AI feature should do rather than how to wire the API calls together.

The pitch was straightforward: treat the LLM as a component you can call from conventional code, not as a separate system you build a bespoke integration for each time. That is a reasonable position for an architect to take, because it keeps the AI feature inside your normal application lifecycle, your normal deployment pipeline, and your normal testing story, instead of turning into a special snowflake service that only the AI team understands.

The core building blocks: Skills, Memories, Connectors, and Planner

The original design centered on four ideas. Skills were the unit of reusable capability, and they could be semantic (a prompt template) or native (regular code), which meant you were not forced to solve every problem with a prompt when a plain function would do the job better and cheaper. Memories gave the kernel a way to hold context across calls, which is the piece most people underestimate until they build their first multi-turn feature and watch it forget everything after two exchanges. Connectors handled talking to live data sources and external actions, and the Planner was the part that took a user’s goal and worked out which Skills, Memories, and Connectors were needed to get there.

That diagram is a decent mental model even years later. An instruction goes in, the kernel figures out the steps, and a result comes out. Where teams get into trouble is assuming the Planner can reliably figure out the right steps for anything you throw at it. In practice, planner-driven orchestration works well for narrow, well-scoped tasks and gets unpredictable fast once you stack more than a handful of skills together. Most production systems built on this kind of framework end up writing explicit orchestration logic for anything business-critical and reserve the dynamic planner for exploratory or low-stakes paths.

Language and model support at launch

At launch, C# was the primary supported language, with Python support running in an experimental branch in parallel. That ordering is notable because most of the Python AI ecosystem, including LangChain, was already ahead in mindshare by early 2023. Microsoft’s decision to lead with C# made sense given their own developer base, but it also meant .NET teams got first-class support for a category of tooling that otherwise skewed heavily toward Python. If your organization was already invested in .NET and Azure, this was one of the few credible entry points into LLM orchestration without switching your primary stack.

On the model side, the SDK supported OpenAI directly and Azure OpenAI Service, including the newly released GPT-4. The framework was explicitly built around what GPT-4 class models could do, particularly around planning and reasoning about multi-step tasks rather than just producing single-shot text completions. That framing, building for outcomes instead of outputs, is a useful lens even outside Semantic Kernel. It is the difference between a chatbot that answers a question and an assistant that completes a task.

Why this mattered beyond the announcement

A launch post is marketing by nature, so it is worth separating the genuine technical contribution from the announcement tone. The real contribution was giving enterprise .NET teams a supported, documented pattern for LLM integration at a time when most of the tooling assumed you were working in a Python notebook. Skills as a unit of composition, and the separation between semantic and native functions, turned out to be a durable idea that shows up in one form or another across most orchestration frameworks that followed.

The weaker part, in hindsight, was how much weight got placed on the Planner as a general-purpose task decomposer. Early adopters who tried to let the Planner handle open-ended, high-stakes workflows ran into the same issue every team eventually hits with autonomous planning: the model is good at proposing a plan and bad at knowing when its own plan is wrong. Anyone evaluating Semantic Kernel or a similar framework today should budget real time for testing the planner against edge cases rather than trusting the demo path.

Where Semantic Kernel stands now

This is where the story has moved on quite a bit since 2023. In October 2025, Microsoft released Microsoft Agent Framework in public preview, combining Semantic Kernel’s production-oriented foundations with AutoGen’s multi-agent orchestration approach. Microsoft has described it as effectively Semantic Kernel’s next major version, built by the same team, rather than an unrelated replacement. As of early 2026 the framework moved into release candidate status with general availability targeted for the first quarter of the year, and Semantic Kernel 1.x itself is still supported, with critical fixes continuing even as most new feature work shifts to Agent Framework.

If you are starting a new project today, it is worth checking Microsoft’s current migration guidance before committing to Semantic Kernel’s original API surface, since the Skills, Planner, and Memories vocabulary from this 2023 post has partly been superseded by Agent Framework’s own agent and workflow abstractions. If you already have a Semantic Kernel 1.x codebase in production, there is no urgency to rip it out, but new orchestration work is a reasonable candidate for the newer framework.

Practical takeaway

Reading this announcement in hindsight is a useful exercise for anyone picking an AI orchestration framework today. The specific product names change, sometimes within a couple of years, but the underlying architecture questions do not: how do you compose reusable capability, how do you manage context across calls, how do you connect to live data safely, and how much autonomy do you actually want to give a planner. Semantic Kernel gave a clear, opinionated answer to those questions in 2023, and that answer shaped a good part of how Microsoft’s AI tooling looks today, even under its newer name.