What is Semantic Kernel? Microsoft’s SDK for AI orchestration

If you build software on the Microsoft stack and want to add AI without bolting a Python service onto the side, Semantic Kernel is the SDK Microsoft built for you. It’s an open-source kit that connects your existing code and APIs to large language models, and it runs in C#, Python, and Java. This guide explains what it is, how the kernel and plugins fit together, and how its OpenAPI specification support turns any REST API into something a model can call.

What Semantic Kernel actually is

Semantic Kernel (SK) is a lightweight, open-source development kit from Microsoft for building AI agents and integrating models into your codebase. Microsoft describes it as middleware: it sits between your application and the model, translates the model’s requests into real function calls, runs them, and passes the results back. You write normal code. The model decides when to call it.

Three things make SK stand out from the crowd of agent libraries.

First, it’s genuinely multi-language. SK ships official SDKs for C#/.NET, Python, and Java, with version 1.0+ stability commitments across all three. Most agent frameworks are Python-first and treat other languages as an afterthought. If your backend is .NET, SK is one of the few mature options that feels native.

Second, it’s model-agnostic. SK connects to OpenAI, Azure OpenAI, and other providers through a set of connectors. When you want to swap models, you change configuration, not your whole application.

Third, it’s built with enterprise concerns in mind. Telemetry, hooks, and filters are first-class, so you can log, audit, and intercept what the AI does. That focus is why Microsoft and a number of Fortune 500 teams adopted it.

The kernel, plugins, and functions

The core object is the kernel. Think of it as a dependency-injection container for AI. You register your model connectors and your plugins on the kernel, then ask it to run things. The kernel handles the orchestration: prompt, model call, function call, result, repeat.

A plugin is a named group of functions you expose to the model. A function is a single capability the model can invoke. Functions come in two flavors:

• Native functions are regular methods in your code (a C# method, a Python function) that you annotate so the kernel can describe them to the model.
• Prompt functions are templated prompts that call the model itself, useful for summarizing, classifying, or rewriting text.

Here’s the shape of it in C#. You build a kernel, register a chat model, add a plugin, and let the model call functions when it needs them.

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", apiKey);
builder.Plugins.AddFromType<LightsPlugin>("Lights");
Kernel kernel = builder.Build();

// The model can now invoke LightsPlugin functions during a chat
var result = await kernel.InvokePromptAsync("Turn the kitchen light blue");

When the model returns and the kernel sees it wants to call change_light_state, the kernel runs your code, captures the result, and feeds it back to the model. That loop is the heart of SK.

The OpenAPI-to-plugin pattern

This is the feature most worth knowing about, and it’s the cleanest bridge to your existing services. SK can import an OpenAPI specification and turn every operation into a callable function automatically. You don’t write wrapper code. You point SK at a spec, and each path/operation becomes a function the model can invoke.

In C# the call is ImportPluginFromOpenApiAsync. In Python it’s add_plugin_from_openapi. Java has an equivalent importer. Here’s the C# version loading a spec from a URL:

await kernel.ImportPluginFromOpenApiAsync(
    pluginName: "lights",
    uri: new Uri("https://example.com/v1/swagger.json"),
    executionParameters: new OpenApiFunctionExecutionParameters()
    {
        EnablePayloadNamespacing = true
    }
);

Under the hood, SK parses the spec, extracts the name, description, type, and schema for every parameter, and hands that metadata to the model. The model reasons about which operation to call and what arguments to pass. SK then builds the HTTP request, applies your authentication callback, sends it, and reads the response back. SK supports OpenAPI 2.0 and 3.0, and downgrades 3.1 specs to 3.0 where it can.

The catch is that specs written for humans aren’t always clear to a model. Microsoft’s own guidance is to add descriptive operation IDs, write helpful parameter descriptions, keep the endpoint count low, and prefer enums and typed parameters over loose strings. The quality of your spec directly shapes how well the agent calls your API. That makes the spec itself a thing worth designing and testing carefully, not an afterthought.

Agents and planning

SK started with explicit planners that decomposed a goal into steps. The framework has since shifted toward function calling, where the model itself decides which functions to invoke and in what order, which is more reliable with modern models. On top of that, SK added an Agent Framework layer for building agents and multi-agent patterns, with session-based state, agentic loops, and Model Context Protocol (MCP) support for connecting external tools.

If you’re comparing approaches, here’s how SK lines up against other agent SDKs covered on this blog.

None of these is strictly better. The right pick depends on your language, your model provider, and how much explicit control over execution you want.

Where Semantic Kernel fits with Microsoft Agent Framework

This part moves fast, so here’s the honest state of things. Microsoft introduced the Microsoft Agent Framework (MAF), and the docs describe it as the direct successor to both Semantic Kernel and AutoGen, built by the same teams. MAF combines AutoGen’s agent abstractions with SK’s enterprise features and adds graph-based workflows for multi-agent orchestration.

What that means in practice:

• Semantic Kernel is stable and still supported. Existing SK applications keep working, and the 1.0+ non-breaking-change commitment stands.
• For brand-new agent projects, Microsoft points you toward the Agent Framework, and publishes a migration guide for moving SK code over.
• The OpenAPI-to-plugin idea carries forward. Giving an agent access to your REST APIs through a spec is a pattern both frameworks share.

So treat SK as a solid, production-proven choice that’s still maintained, while knowing the newest investment is going into MAF. If you’re deciding today and your code is already in SK, there’s no fire drill. If you’re starting fresh and want the latest direction, read the MAF docs before you commit.

When to use Semantic Kernel

Reach for SK when:

• Your stack is .NET or Java and you want AI orchestration that feels native instead of a Python sidecar.
• You have a portfolio of existing REST APIs and want a model to call them through their OpenAPI specs.
• You need enterprise plumbing: telemetry, filters, hooks, and the ability to audit what the AI did.
• You want to stay model-agnostic and swap providers without rewriting your app.

Look elsewhere when your team is Python-only and you want the absolute newest multi-agent features, in which case MAF or a graph-first library may suit you better.

Testing the APIs behind your Semantic Kernel agent

Here’s where API tooling matters, and where Apidog fits cleanly. SK doesn’t build or replace your APIs. It calls them. An SK agent depends on two kinds of endpoints: the LLM endpoint it talks to, and the REST APIs you import as OpenAPI plugins. Both need to be correct, well-described, and reliable, or the agent makes bad calls.

A few practical jobs:

• Design and test the OpenAPI spec before you import it. Since SK turns each operation into a function and feeds the model your parameter descriptions, a sloppy spec produces sloppy tool calls. Validate the spec, exercise every endpoint, and confirm responses match the schema. Clean contract, better agent.
• Mock the dependencies during development. You can stand up a mock API for an endpoint that isn’t built yet, or mock the LLM endpoint to avoid burning tokens and hitting rate limits while you debug the orchestration loop. See how to mock API calls for the pattern.
• Assert response shapes. Use API assertions to verify that the tool endpoints your agent calls return exactly the structure the model expects, so a backend change doesn’t silently break agent behavior.
• Manage keys per environment. Keep your LLM and API credentials separated across dev, staging, and prod environments rather than hardcoding them.

This is ordinary API work, done before and around the agent, not instead of it. If you want a deeper walkthrough, testing an agent’s tool calls with Apidog covers the harness in detail.

Frequently asked questions

Is Semantic Kernel free and open source?

Yes. Semantic Kernel is open-source and published by Microsoft on GitHub under a permissive license, with SDKs for C#/.NET, Python, and Java. You pay for the model usage (OpenAI, Azure OpenAI, and so on), not for SK itself.

What languages does Semantic Kernel support?

C#/.NET, Python, and Java, all with version 1.0+ stability commitments. The C# SDK is the most mature, but the Python and Java SDKs cover the core kernel, plugins, and OpenAPI import features.

How does Semantic Kernel use OpenAPI specs?

You import a spec with ImportPluginFromOpenApiAsync (C#) or add_plugin_from_openapi (Python). SK parses the spec, turns each operation into a callable function with its parameter metadata, and lets the model invoke those operations. Because the model relies on your descriptions, it pays to validate the spec first. You can do that, and test the live endpoints, with Apidog.

Should I use Semantic Kernel or the Microsoft Agent Framework?

If you already have an SK application, keep using it; it’s supported and stable. For new projects, Microsoft positions the Agent Framework as the successor and provides a migration guide. Check the current MAF docs before starting fresh, since this area is changing quickly. To test the APIs either one calls, see how to test the ChatGPT API with Apidog.

Wrapping up

Semantic Kernel gives Microsoft-stack teams a clean way to orchestrate AI: a kernel that connects models to your code, plugins and functions the model can call, and an OpenAPI import path that exposes your existing REST APIs as agent tools. It’s stable and production-proven, with the Agent Framework now carrying the newest direction forward. Whichever you pick, the APIs underneath still need to be solid. To design, mock, and test the specs and endpoints your agent depends on, download Apidog and build the contract before the agent ever calls it.