In December 2023, the Semantic Kernel team shipped V1.0.1 for C#, the first release that developers can treat as a stable base for production AI agents. This closes a fast arc for the framework. It went from an experimental SDK announced in March 2023 to a version with a real semantic versioning promise inside the same year. If you build .NET applications on top of Azure OpenAI or OpenAI directly, this release is worth understanding properly, not just skimming the changelog.
This article walks through what actually changed, how the new package tiers work, and what you need to know before you wire Semantic Kernel into a real project. I am writing this from the perspective of someone who has taken early SDKs into production before and gotten burned by breaking changes, so I want to flag the parts that matter for that decision.
Why a stable release matters here
Semantic Kernel spent most of 2023 changing its public API on a near weekly basis. That is normal for a framework finding its shape, but it is painful if you already had it running in a customer facing app. The team ran two weeks of release candidates before V1.0.1, and the community reported enough bugs and API friction during that window that the final cut is meaningfully more settled than the preview builds most people have tried.
The practical upshot is that from V1.0.1 onward, the core namespaces will not break under you without a major version bump. That is the single biggest reason to re-evaluate Semantic Kernel now if you tried it six months ago and walked away frustrated.
The three building blocks docs now walk you through
Alongside the release, Microsoft refreshed the Semantic Kernel documentation on learn.microsoft.com. The updated docs still cover the basics, prompts and the kernel object itself, but they now also walk through the three concepts you actually need to build an agent rather than a simple prompt wrapper: plugins, planners, and personas.
Plugins are the functions your kernel can call, whether that is a native C# method or a semantic function backed by a prompt. Planners are the piece that decides which plugin to call and in what order, either through an explicit planner object or through automatic function calling on models that support it. Personas are how you give the agent a consistent voice and behavior across a conversation instead of restating instructions on every call.
None of these three ideas is new by itself. What is useful is that the docs finally treat them as a single connected story instead of three separate how-to pages you have to stitch together yourself.
Where your agent sits on the spectrum
One diagram from the release post is worth keeping in mind whenever someone asks you to add AI to a product. Semantic Kernel positions agents on a spectrum, and where you land on it should drive your architecture decisions far more than which SDK you pick.
A simple chatbot only needs back and forth conversation handling, so a thin wrapper over the chat completion API is often enough and you do not need planners at all. A RAG style assistant needs retrieval grounded in your own data, which means you will lean on Semantic Kernel’s memory connectors and vector search integration. A copilot that works alongside a user on a task needs plugins and some planning, but a human stays in the loop to approve actions. A fully autonomous agent removes that human checkpoint, which is where you should be the most conservative, because a bad plan executed without review can do real damage, not just produce a bad chat reply.
In my own client work, most requests that start as “build us an AI agent” actually turn out to need a copilot, not a fully autonomous agent. It is worth having this conversation with stakeholders early, because the engineering effort and the testing burden go up sharply as you move right on that spectrum.
How the NuGet packages are now tiered
This is the part of the release that affects your project file directly. Semantic Kernel’s NuGet packages are now split into three stability tiers, and knowing which tier a package sits in tells you how much churn to expect from an upgrade.
- V1.0.1 stable: Microsoft.SemanticKernel, Microsoft.SemanticKernel.Abstractions, Microsoft.SemanticKernel.Core, Microsoft.SemanticKernel.Connectors.OpenAI, Microsoft.SemanticKernel.PromptTemplates.Handlebars, and Microsoft.SemanticKernel.Yaml. No breaking changes here unless a specific API is explicitly marked experimental.
- V1.0.1-preview: packages such as the Hugging Face connector and the Handlebars and OpenAI function calling planners. These are expected to land in V1.1 with only minor breaking changes.
- V1.0.1-alpha: every memory connector (Qdrant, Redis, Postgres, Chroma, Pinecone, and others), the plugin packages, and the experimental OpenAI Assistants based agents package. Expect real breaking changes here through 2024 as the team standardizes the memory connector interface.
If you are choosing what to depend on for a production system today, stay on the stable tier for your core kernel setup and treat anything from preview or alpha as something you pin a specific version of and test carefully before upgrading. Do not casually bump alpha packages in a CI pipeline that auto-updates NuGet references.
Installing the stable packages
Adding the core stable packages to a .NET project uses the regular dotnet CLI, nothing special here. This is the minimum you need to instantiate a kernel and start calling a chat completion model.
dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Connectors.OpenAIThe first package is the meta package that pulls in the abstractions and core runtime. The second is the connector for OpenAI and Azure OpenAI chat models specifically. If you plan to use Handlebars based prompt templates or YAML serialized prompts, add Microsoft.SemanticKernel.PromptTemplates.Handlebars or Microsoft.SemanticKernel.Yaml on top of these two. A restore after this should give you a clean build with no experimental warnings, since none of these six packages carry that marker.
Working with experimental APIs without drowning in warnings
The moment you touch a preview or alpha package, for example a memory connector or a planner, the compiler will throw an experimental API warning at you. This is intentional. The team is telling you the API shape can still change and you are opting into that risk. You have two ways to acknowledge it depending on whether you want the suppression at the project level or at a specific call site.
<PropertyGroup>
<NoWarn>$(NoWarn);SKEXP0001</NoWarn>
</PropertyGroup>That goes in your .csproj and suppresses a specific experiment code across the whole project. Replace SKEXP0001 with the actual experiment number tied to the API you are using, which you can find in the Semantic Kernel experimental features documentation. Suppressing it project wide is convenient but it also means you will not get a fresh warning if you add a second unrelated experimental API later, so use it when you are deliberately committing to one experimental surface, like a specific memory connector.
#pragma warning disable SKEXP0001
var memory = new MemoryBuilder()
.WithMemoryStore(new QdrantMemoryStore("http://localhost:6333", 1536))
.Build();
#pragma warning restore SKEXP0001The pragma pair scopes the suppression to just that block of code, which is the safer default in a larger codebase because you still get warned if experimental usage creeps in somewhere else. Pick whichever suits your team, but be consistent about it, since a codebase mixing both styles gets confusing to audit later.
The alpha agents package deserves a specific mention
Of everything sitting in the alpha tier, Microsoft.SemanticKernel.Experimental.Agents is the one most teams will actually want to look at soon, because it lets you build agents directly on top of OpenAI’s Assistants API rather than hand rolling your own planner and thread management. That said, it is genuinely alpha. OpenAI itself has changed the Assistants API surface more than once since launch, so expect this package to move under you through 2024. Do not build a customer facing feature on it without a fallback plan, and pin the exact version in your lock file rather than floating on a range.
Where the memory connector story is headed
Every memory connector, covering Redis, Postgres, Qdrant, Milvus, MongoDB, and the rest, currently implements its own slightly different interface. The team has said plainly that 2024 work will unify these connectors around the same interface OpenAI’s ChatGPT retrieval plugin uses, aiming for more interoperability across vector stores. If you are picking a vector database today, this is a reasonable signal that the connector API you write against now may need a small adapter later, but the underlying vector store choice itself should hold up fine since that is a separate decision from the SDK interface.
What to actually do with this release
If your team paused on Semantic Kernel earlier in 2023 because the API kept moving, V1.0.1 is a reasonable point to reconsider it for new work, provided you stay disciplined about which tier each package you depend on sits in. Build your core kernel setup, prompt templates, and OpenAI connector work on the stable tier. Treat memory and the experimental agents package as things you evaluate in a spike first, not something you wire into a production release without a version pin and a rollback plan.
The team is also explicitly asking the community to help build out AI connectors for models beyond OpenAI, things like Llama, Mistral, and local Hugging Face models, ahead of memory and agent abstraction work in January 2024. If your organization already has a Semantic Kernel dependency and spare engineering time, contributing a connector is a fairly approachable way to get a feature you need merged upstream instead of maintaining a fork.
Leave a Reply