Semantic Kernel

The Semantic Kernel is an open source software development kit (SDK) developed by Microsoft to integrate large language models (LLMs) into legacy application code. The framework allows developers to mix AI prompts and native code in C#, Python, and Java so the LLM can invoke actual application logic instead of just generating text. It was initially released in 2023 and is maintained by Microsoft as a production stable piece of the Microsoft AI stack. 

It’s important to note that the Semantic Kernel isn’t the AI model but rather an orchestration framework. The AI model could be GPT models from OpenAI, Azure OpenAI, or even locally running models through Ollama.

Is Semantic Kernel Free and Open Source?

Semantic Kernel is open-source software. It has been licensed by the MIT License and published as open-source software on GitHub at microsoft/semantic-kernel. There are no license costs for SDK. You only have to pay for the services that you will be connecting to the SDK such as Azure OpenAI API and Vector database service.

Up to the middle of 2026, the repository has gained around 27,000-28,000 GitHub stars and over 500 contributors in monthly releases.

How Semantic Kernel Works: Core Architecture

In Semantic Kernel, an AI application is decomposed into five different parts which include the Kernel, Plugins, Memory, Planning, and Connectors, and each of these parts deals with a specific part of the pipeline from user request to completion of the task.

The Kernel

The kernel is the main component that is responsible for registering and coordinating other components. In essence, it acts like a dependency injection container where developers can register all their AI services, plugins, and memory stores, and then Kernel routes the request to the right component. On receipt of the request, Kernel chooses an appropriate AI service, constructs a prompt from a template, sends it to the model, and receives the result back. 

Plugins and Functions

A plugin is a group of functions that an AI model can call to perform a task. Semantic Kernel defines two function types:

Function Type	Written In	Purpose
Semantic function	Natural-language prompt template	Generates text-based responses using an LLM
Native function	C#, Python, or Java	Executes deterministic operations: calculations, database reads, API calls

This means one plugin can implement both types of functions. The model invokes the function by name after determining that the function is relevant to the request – what Microsoft refers to as function calling.

There are three ways of creating a plugin, namely native code, prompt templates, or importing an OpenAPI definition. Starting from 2025, Semantic Kernel plugins may also be exposed using the Model Context Protocol (MCP).

Memory

With memory, an agent can retain information between requests. Semantic Kernel provides three memory options:

• Key-value memory – stores individual variables, accessed through an exact key lookup.
• Local file memory – saves information to disk when the key-value memory becomes unmanageably large.
• Vector (semantic) memory – represents textual information using numeric vectors and is queried based on similarity rather than an exact match.

The vector memory can be implemented using external databases such as Azure AI Search, Elasticsearch, Chroma, Qdrant, and Redis.

Planning

Planning refers to the way that the Semantic Kernel decides on which functions to call and how to arrange them to fulfill a request. The planning procedure can be either defined manually, as a series of fixed steps, or automatically by an LLM as part of its response to the goal it is provided. 

Connectors

Connectors are the components in Semantic Kernel that connect the Kernel with external AI systems or storage for data. These include built-in connectors for OpenAI, Azure OpenAI, Hugging Face, NVIDIA endpoints, as well as local deployments through Ollama, LM Studio, and ONNX. 

Semantic Kernel Agents and the Agent Framework

An agent in Semantic Kernel is a Kernel-backed object that can converse, call plugin functions, and maintain a role across multiple turns. Semantic Kernel provides three built-in agent types: ChatCompletionAgent for standard chat-based models, OpenAIAssistantAgent for the OpenAI Assistants API, and AzureAIAgent for the Foundry Agent Service. Multiple agents can be coordinated into a multi-agent system, where each agent handles a defined subset of a task and hands off results to the next agent.

Semantic Kernel and Microsoft Agent Framework: What Changed in 2026

On April 3, 2026, Microsoft released Microsoft Agent Framework 1.0 as a production-ready, general-availability successor that unifies Semantic Kernel’s agent capabilities with AutoGen’s multi-agent orchestration patterns into one SDK. [8] Microsoft describes Agent Framework as combining “the enterprise-ready foundations of Semantic Kernel with the innovative orchestrations of AutoGen.”

Three facts define the current relationship between the two frameworks:

• Agent Framework replaces the Kernel object. Instead of building agents around a Kernel instance, Agent Framework uses a single ChatClientAgent type built on the IChatClient interface from Microsoft.Extensions.AI. 
• Semantic Kernel 1.x remains supported. Microsoft has committed to critical bug fixes and security patches for Semantic Kernel agent abstractions for at least one year past the Agent Framework GA date.
• New agent projects are directed to Agent Framework. Microsoft’s official guidance states that teams starting a new agent project should build on Agent Framework; teams with an existing, stable Semantic Kernel deployment can remain on it without an immediate migration.

Semantic Kernel itself continues to serve as the underlying orchestration layer — providing plugins, memory, and filters — that Agent Framework builds on top of. The two are not competing products; Agent Framework is positioned as Semantic Kernel’s successor for agent-specific workloads, while Semantic Kernel remains the recommended choice for plugin-based orchestration in existing production systems.

Semantic Kernel and MCP (Model Context Protocol)

The Model Context Protocol (MCP) is an open protocol that standardizes how applications provide context and tools to LLMs.Semantic Kernel supports MCP in two directions:

• As an MCP client, a Semantic Kernel agent can connect to any MCP server and call its exposed tools through the official ModelContextProtocol package for .NET and Python.
• As an MCP server, existing Semantic Kernel plugins can be exposed as MCP tools, making them callable from any MCP-compatible application — not only Semantic Kernel. 

MCP addresses a specific integration problem: without it, each AI framework requires custom connection code for every external tool or data source. MCP standardizes that connection into a single specification that multiple frameworks — including LangChain and AutoGen — can consume.

Getting Started with Semantic Kernel in Python

The following steps set up a minimal Semantic Kernel application that registers an AI service, defines a native function, and invokes it.

1. Install the package.

bash

  pip install semantic-kernel

2. Create a Kernel instance and add an AI service.

python

  from semantic_kernel import Kernel

   from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion

   kernel = Kernel()

   kernel.add_service(

       AzureChatCompletion(

           deployment_name="gpt-4o",

           endpoint="https://<your-resource>.openai.azure.com/",

           api_key="<your-api-key>",

       )

   )

3. Define a native function as a plugin.

python

  from semantic_kernel.functions import kernel_function

   class MathPlugin:

       @kernel_function(description="Adds two numbers together")

       def add(self, a: int, b: int) -> int:

           return a + b

   kernel.add_plugin(MathPlugin(), plugin_name="math")

4. Invoke the function through the Kernel.

python

  result = await kernel.invoke(

       function_name="add", plugin_name="math", a=4, b=7

   )

   print(result)  # 11

This sequence reflects the current 1.x package structure: semantic-kernel on PyPI, imported as semantic_kernel, with functions registered through the @kernel_function decorator rather than the pre-1.0 skill-configuration files used in earlier SDK versions.

Semantic Kernel vs. LangChain vs. AutoGen

Attribute	Semantic Kernel	LangChain	AutoGen
Maintained by	Microsoft	LangChain Inc.	Microsoft (now folded into Agent Framework)
Primary languages	C#, Python, Java	Python, JavaScript/TypeScript	Python
License	MIT	MIT	MIT
Core abstraction	Kernel + plugins + planners	Chains + LangGraph graphs	Conversable multi-agent groups
Native Azure integration	Deep (Azure OpenAI, Foundry, Azure AI Search)	Available via connectors	Available via connectors
Enterprise focus	Enterprise .NET and Java shops	Broad ecosystem, research and production	Multi-agent research, now maintenance-only
2026 status	Actively maintained; agent development directed to Agent Framework	Actively maintained; largest community by GitHub star count	Maintenance mode; superseded by Agent Framework

LangChain has a larger open-source community than Semantic Kernel, with GitHub star counts commonly cited in the 80,000+ range compared to Semantic Kernel’s roughly 27,000–28,000. The gap reflects LangChain’s Python-first, framework-agnostic design, which attracted broader early adoption outside the Microsoft ecosystem.

AutoGen is no longer the recommended starting point for new multi-agent projects. Microsoft has placed AutoGen in maintenance-only status: existing AutoGen projects continue to run, but new features are directed to Agent Framework instead.

When to Use Semantic Kernel

Semantic Kernel is a fit for teams building on the Microsoft or Azure stack that need plugin-based orchestration inside an existing production codebase, particularly in C# or Java where alternatives offer less mature support. It is also a fit for teams with a stable Semantic Kernel deployment that does not yet require multi-agent orchestration, checkpointing, or MCP-based handoff workflows.

Semantic Kernel is not the recommended starting point for a new project whose primary goal is multi-agent orchestration. Microsoft’s official guidance directs new agent projects to Microsoft Agent Framework instead, since Agent Framework provides built-in sequential and handoff workflow patterns and MCP integration that Semantic Kernel’s agent classes do not include natively.

Frequently Asked Questions