# Semantic Kernel: Microsoft's Orchestration SDK, Now in Maintenance Mode Behind Agent Framework

> Semantic Kernel is a model-agnostic SDK in C#, Python and Java for agents, plugins and multi-agent workflows. The README now points to Microsoft Agent Framework as its successor, which changes who should start a new build on it.

**microsoft/semantic-kernel** — Semantic Kernel connects application code with language models, prompts, tools, memory, and agent workflows.

- Repository: https://github.com/microsoft/semantic-kernel
- Website: https://aka.ms/semantic-kernel
- Stars: 28,607 · Forks: 4,796
- Language: C#
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-semantic-kernel

## What Semantic Kernel Is For, and Why the README Starts With a Warning

The first thing a reader sees in the repository is a notice that Semantic Kernel is now Microsoft Agent Framework. The README calls MAF the enterprise-ready successor and says it is available at version 1.0 with stable APIs and a commitment to long-term support, and it links a migration guide for moving off Semantic Kernel. That notice is the single most important fact about the project, and it reframes everything below it.

The SDK itself is a model-agnostic layer that connects application code to language models, prompts, tools, memory and agent workflows. The README lists built-in support for OpenAI, Azure OpenAI, Hugging Face and NVidia, plus local runtimes through Ollama, LMStudio and ONNX. The audience is developers building assistants or multi-agent systems in an existing application stack, particularly in .NET shops where the NuGet packages drop into a service that already has dependency injection and configuration wiring.

The repository is not archived, and the last push was on 2026-08-18, which is the same day as the dotnet-1.80.0 release. Releases are still shipping. What the notice changes is not whether the code works, but whether you should write new code against it. A successor framework with a migration guide is a signal about where the maintainers expect effort to go. That is a different situation from a deprecated project with no path forward, and also different from a project with no successor at all.

## How the Kernel, Connectors and Plugins Fit Together

The architecture visible in the README is a three-layer arrangement. At the bottom sit connectors, which wrap a model provider behind a common chat completion interface. In Python that is `AzureChatCompletion` or `OpenAIChatCompletion` from `semantic_kernel.connectors.ai.open_ai`; in .NET it is a builder call such as `AddAzureOpenAIChatCompletion` that takes a deployment name, an endpoint and a key. Because the connector is the only provider-specific piece, swapping OpenAI for Azure OpenAI is a change at construction time rather than across the call sites.

Above the connectors sits the kernel, a container that holds services and plugins. The README's .NET example builds one with `Kernel.CreateBuilder()`, registers a chat completion service, calls `Build()`, and then attaches plugins with `kernel.Plugins.Add(KernelPluginFactory.CreateFromType<MenuPlugin>())`. The kernel is what gets handed to an agent, which is why the agent constructor in the same example takes a `Kernel` property rather than a raw client.

Plugins are the extension surface. A plugin can be native code, a prompt template, an OpenAPI specification, or a Model Context Protocol server. In Python, the `@kernel_function` decorator with a description string marks a method as callable by the model, and the docstring-style annotation supplies the return description the model sees. That description text is not decoration: it is the schema the model uses to decide when to call the function. A vague description produces a model that calls the wrong tool, which is the most common failure in this layer and one the framework cannot fix for you.

Agents sit on top. `ChatCompletionAgent` combines a service, a name and instructions, and `get_response` returns a result whose `content` holds the text. Multi-agent setups instantiate several agents with different instructions, as the README does with a billing agent and a refund agent, and the orchestration layer decides which one handles a turn. The README shows `ChatHistoryAgentThread` as the object carrying conversation state across those agents.

## Installing Semantic Kernel and Running a First Agent

The README gives two installation paths and a Java pointer. Python needs 3.10 or later, .NET needs .NET 10.0 or later, Java needs JDK 17 or later, and all three run on Windows, macOS and Linux. The Java binding lives in a separate repository, microsoft/semantic-kernel-java, and its BUILD.md is where the README sends you for instructions.

Before any code runs, the README sets an API key as an environment variable. For Azure OpenAI the variable is `AZURE_OPENAI_API_KEY`; for OpenAI directly it is `OPENAI_API_KEY`. The Python example below uses Azure, so the Azure variable is the one that matters.

```bash
export AZURE_OPENAI_API_KEY=AAA....
```

With the key in place, install the Python package from PyPI.

```bash
pip install semantic-kernel
```

The .NET path pulls two packages, the core SDK and the agents package.

```bash
dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Agents.Core
```

A first agent is short. The README's Python quickstart imports `ChatCompletionAgent` and `AzureChatCompletion`, constructs the agent with a name and instructions, and awaits `get_response` with a single message. The printed output is the model's answer, which the README illustrates with the opening lines of a haiku about Semantic Kernel.

```python
import asyncio
from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion

async def main():
    agent = ChatCompletionAgent(
        service=AzureChatCompletion(),
        name="SK-Assistant",
        instructions="You are a helpful assistant.",
    )
    response = await agent.get_response(messages="Write a haiku about Semantic Kernel.")
    print(response.content)

asyncio.run(main())
```

The .NET equivalent is longer because it wires configuration explicitly. The builder reads the deployment, endpoint and key from environment variables, the kernel is built, and the agent is constructed with that kernel.

```csharp
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;

var builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion(
    Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT"),
    Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT"),
    Environment.GetEnvironmentVariable("AZURE_OPENAI_API_KEY")
);
var kernel = builder.Build();

ChatCompletionAgent agent = new()
{
    Name = "SK-Agent",
    Instructions = "You are a helpful assistant.",
    Kernel = kernel,
};
```

The first real step beyond the quickstart is adding a plugin, because an agent that can only talk is not much of an agent. In Python that means a class with methods decorated by `@kernel_function`, each carrying a description, and the class registered so the model can see it. The README's MenuPlugin returns a list of specials and is the smallest complete example of the pattern. If your first agent works but never calls the plugin, the description string is the first thing to check.

## Where Semantic Kernel Stops Being the Right Tool

The successor notice is the limitation that matters most, and it is not a bug. Anyone starting a new project has to decide whether to build on a framework whose own README points elsewhere. The README does not say Semantic Kernel is unmaintained, and releases through 2026-08-18 show it is not, but a migration guide to a successor is a commitment about the future that a release cadence cannot offset.

A second constraint is version fragmentation across languages. The recent releases include dotnet-1.80.0 and python-1.44.1, which are separate version lines with separate release dates. Feature parity between the C# and Python bindings is not something the README promises, and the Java binding is a different repository entirely. If your team spans .NET services and Python notebooks, expect to verify each capability in each binding rather than assuming one implies the other.

The third is the plugin description problem, which is a design constraint rather than a defect. Function calling depends on the model reading your descriptions correctly. Long plugin surfaces with overlapping descriptions degrade quickly, and nothing in the SDK prevents you from registering forty functions that all sound similar. Frameworks that generate schemas from typed signatures reduce the authoring burden; here the burden sits with whoever writes the description strings.

Finally, this is not a good fit for simple prompt-and-response work. If you are calling one model with one prompt and no tools, the kernel, the plugin registry and the agent abstraction are overhead. A direct client call is shorter and has fewer moving parts. The framework earns its place when you have multiple providers, multiple tools, or multiple agents that need to coordinate.

## Semantic Kernel Against LangChain, AutoGen and LangGraph

The comparison people search for most is Semantic Kernel versus LangChain. The difference in approach is language and integration posture. LangChain is a Python and JavaScript ecosystem built around composable chains and a very large integration catalog. Semantic Kernel is built with first-class C# support alongside Python and Java, and its abstractions map onto .NET conventions such as dependency injection and builder patterns. For a .NET service, Semantic Kernel is the shorter path; for a Python data pipeline, LangChain has the wider integration surface.

Against AutoGen, the split is about what is being orchestrated. AutoGen centers on conversational agents that talk to each other, with the conversation as the primary artifact. Semantic Kernel centers on the kernel and plugins, with agents as one consumer of those services. The README's multi-agent example, a billing agent and a refund agent with distinct instructions, is a routing pattern rather than a free-form agent conversation.

LangGraph takes a graph-first view: you define nodes and edges and the state that flows between them. Semantic Kernel's Process Framework is the nearest analogue in the README's feature list, described as a structured workflow approach for modeling business processes. The difference is emphasis. LangGraph makes the graph the central object; Semantic Kernel makes the kernel and its plugins central and treats process modeling as one capability among several.

Against Microsoft Agent Framework, the comparison is not really a comparison. The README presents MAF as the successor, with stable APIs at version 1.0, multi-agent orchestration, multi-provider model support, and cross-runtime interoperability through A2A and MCP. Choosing between them is choosing between the current repository and the one the README tells you to migrate to.

## Maintenance, Licensing and the Cost of Staying

The repository is not archived, and the last push was on 2026-08-18. The most recent releases are dotnet-1.80.0 on 2026-08-18, python-1.44.1 on 2026-08-06 and dotnet-1.79.0 on 2026-08-06. That is a live release train, not a frozen one.

The upgrade cost is in the connector and agent layers rather than the plugin layer. Plugin code written as plain decorated functions with descriptions is largely portable, because the model-facing contract is the function signature and its description. Agent classes, thread objects and orchestration code are the parts tied to this SDK's types, and they are the parts the migration guide exists to address. If you are planning a move, the practical question is how much of your codebase sits in each bucket.

The licence is MIT, per the LICENSE file at the repository root and the badge in the README. MIT is permissive: it allows commercial use, modification and redistribution with the licence and copyright notice preserved. It does not grant patent rights in the way some other licences do, and it provides no warranty. Whether that matters for your product depends on your legal review, which is not something this article can settle.

One cost that is easy to overlook is the model provider relationship. Semantic Kernel is model-agnostic, which means it does not insulate you from provider pricing, rate limits or deprecations. Swapping connectors is cheap; revalidating prompts and tool descriptions against a different model is not.

## Frequently Confused Points About Agents, MCP and C#

The agent framework inside Semantic Kernel is the layer that turns a chat completion service into something that holds instructions, carries conversation state through a thread, and can be given tools. `ChatCompletionAgent` is the concrete class in both the Python and .NET quickstarts. It is not a separate product; it ships in the same packages, which is why the .NET install adds `Microsoft.SemanticKernel.Agents.Core` alongside the core SDK.

MCP support is listed in the README's plugin ecosystem, alongside native code functions, prompt templates and OpenAPI specs. That means an MCP server is treated as one more source of callable functions rather than as a distinct subsystem. If you already run MCP servers, they plug into the same registration path as a native plugin class.

For C# developers, the practical shape is a builder that registers services, a kernel that holds them, and agents constructed against that kernel. The README's examples read environment variables for the deployment name, endpoint and key rather than hardcoding them, which is the pattern to copy if you plan to run the same code across environments.

What the README does not document is rollback. There is no described procedure for reverting a migration or pinning back to an earlier Semantic Kernel version after moving to Agent Framework. Anyone planning a move should treat that as an open question to resolve before committing.

## Conclusion

Adopt Semantic Kernel if you already have working code on it, or you need a .NET-native agent layer today and can accept the migration path the README describes. Do not start a greenfield multi-agent platform on it if you have no existing investment; the README itself names Microsoft Agent Framework as the enterprise-ready successor and links a migration guide. Before committing, verify three things: which package version your language binding is on, whether the connectors you need (MCP, Azure AI Search, Chroma) are present in that version, and how much of your plugin code is plain kernel functions versus framework-specific agent classes. The plugin layer is the part most likely to survive a move; the orchestration layer is the part most likely to be rewritten.

## FAQ

### What is Semantic Kernel?

It is a model-agnostic SDK from Microsoft for building and orchestrating AI agents and multi-agent systems, connecting application code to language models, prompts, tools and memory. The README describes it as supporting OpenAI, Azure OpenAI, Hugging Face, NVidia and local runtimes through Ollama, LMStudio or ONNX.

### How do I install Semantic Kernel?

For Python, run pip install semantic-kernel, which requires Python 3.10 or later. For .NET, add the Microsoft.SemanticKernel and Microsoft.SemanticKernel.Agents.Core packages, which require .NET 10.0 or later. Java instructions are in the separate microsoft/semantic-kernel-java repository's BUILD.md.

### How do I use MCP with Semantic Kernel?

The README lists Model Context Protocol as one of the plugin sources, alongside native code functions, prompt templates and OpenAPI specs. That means an MCP server is registered as a plugin, the same way a native plugin class is.

### What is the Semantic Kernel agent framework?

It is the layer built on the kernel that lets you define agents with a name and instructions and give them tools. The README's examples use ChatCompletionAgent in both Python and .NET, and ChatHistoryAgentThread to carry conversation state in multi-agent setups.

### What is Semantic Kernel in C#?

It is the .NET binding of the SDK, requiring .NET 10.0 or later. You build a kernel with Kernel.CreateBuilder(), register a chat completion service such as AddAzureOpenAIChatCompletion, and attach plugins with kernel.Plugins.Add(KernelPluginFactory.CreateFromType<T>()).

## Sources

- [Official documentation](https://aka.ms/semantic-kernel)
- [Official README](https://github.com/microsoft/semantic-kernel#readme)
- [Project repository](https://github.com/microsoft/semantic-kernel)
- [Release notes](https://github.com/microsoft/semantic-kernel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-semantic-kernel