Semantic Kernel Agent Framework: Microsoft's AI Agents SDK

Created by Microsoft - https://github.com/microsoft/semantic-kernel

Overview

The Semantic Kernel Agent Framework is Microsoft's toolkit for building AI agents on top of the open-source Semantic Kernel SDK. Microsoft Learn describes it as a platform within the Semantic Kernel ecosystem for creating agents and adding agentic patterns to any application, using the same patterns and features as the core framework. In Microsoft's own framing, an agent has three core elements: a system prompt or persona, plugins, and the ability to reason and create plans that address a user's goal. Agents built this way use LLMs to interpret natural-language commands, combine them with predefined programming logic, and execute complex actions such as completing chats, running calculations and searching files.

Semantic Kernel came before its agents. Microsoft introduced it on March 17, 2023, in Hello, Semantic Kernel!, calling it a lightweight SDK that mixes conventional languages like C# and Python with LLM prompts, prompt templating, chaining and planning. First-class agents arrived on August 1, 2024, when Microsoft announced enterprise multi-agent support in Semantic Kernel, adding a standardized agent abstraction with Assistant API agents and chat-completion agents out of the box in the Python 1.6.0 and .NET 1.18 (source).0 RC1 releases, and marking the framework experimental. It reached Release Candidate 1 on February 28, 2025, with Semantic Kernel 1.40 for .NET and 1.22.0 for Python, then became generally available on April 4, 2025 in Semantic Kernel 1.45 (.NET) and 1.27 (source) (Python). Microsoft then added a multi-agent orchestration framework for building, managing and scaling complex agent workflows.

flowchart LR
  A[Semantic Kernel SDK launch] --> B[Agent abstraction, experimental]
  B --> C[Release Candidate 1]
  C --> D[General availability]
  D --> E[Multi-agent orchestration]
  E --> F[Microsoft Agent Framework successor]

The story has a next chapter. The Semantic Kernel GitHub repository now announces that Semantic Kernel is now Microsoft Agent Framework, the enterprise-ready successor, available at version 1.0 (source) with stable APIs, a commitment to long-term support, multi-agent orchestration, multi-provider model support, and interoperability through A2A and MCP. Microsoft publishes a migration guide from Semantic Kernel for existing projects. The core vocabulary of kernels, plugins, function calling and a common agent abstraction carries over, so the concepts on this page remain useful, but a new project should decide early which package line it depends on.

At runtime, the kernel is the hub. In Microsoft's Agents SDK integration, the kernel references the configured AI services, manages and publishes plugins, and provides execution context, while developers create a ChatHistory record and pass turn state into it so the kernel can use channel information during orchestration. Tool use then runs through automatic function calling: register plugins, enable automatic invocation in execution settings, and call the chat service with the history and the kernel. Persistence and long-term memory are covered in adding memory and context to agents.

Independent evidence is mixed and not directly comparable. A 2026 empirical study of agentic frameworks that included Semantic Kernel found that frameworks completing all benchmarks averaged 44.35% accuracy on GSM8K, against 89.80% on BBH and 89.56% (source) on ARC, concluding that mathematical reasoning remains a weakness across every framework tested. A comparative thesis on multi-agent frameworks reported that the Semantic Kernel Chat framework used roughly 6 million tokens for its TS10 optimization case and around 28 (source) million for TS50, substantially more than the others. A simulated MCP and Semantic Kernel study reported better efficiency and robustness than rule-based systems but relied on artificial datasets. Maturity claims also conflict by date: a [2025 (source) practitioner review](https://dev.to/aakas/navigating-the-ai-agent-ecosystem-a-comprehensive-framework-analysis-5813) still called the Agent Framework experimental, while Microsoft had declared it generally available.

Among alternatives, a 2026 practitioner comparison credits Semantic Kernel with native .NET and Azure integration but warns Python-first teams that new community patterns may land elsewhere first.

Teams planning agent builds in Hamster Studio can keep the framework decision, test results and migration notes in one shared workspace.

Core Principles

An agent is persona plus plugins plus planning

Microsoft defines an agent by a persona, plugins, and the ability to plan toward a goal. The framework can send one prompt combining the user request, plugins and persona so the model plans how to reach the goal. Design all three together: a vague persona with sharp tools, or the reverse, produces erratic behavior. If an agent picks the wrong tool, check the persona and tool descriptions before blaming the model.

Plugins are the agent's only way to act

Everything an agent does beyond generating text goes through plugins, which the Semantic Kernel repository says can come from native code functions, prompt templates, OpenAPI specifications and MCP. Treat each plugin as a contract with clear names, typed inputs and structured outputs. Poorly named or loosely typed functions are hard for the model to select correctly. Details live in integrating plugins and tools into agents.

Function calling is configured, not assumed

Current guidance replaces the old planners with automatic function calling, which you switch on in execution settings. Agent types differ here: function calling must be explicitly enabled for ChatCompletionAgent, while an OpenAI Assistant agent always uses it. An agent that answers fluently but never touches its tools usually has this setting missing.

One abstraction, service-specific agents

The August 2024 release introduced a standardized agent abstraction with Assistant API and chat-completion agents as concrete types. The common interface lets you swap or combine agents, but each type still depends on a specific model service. Choose the type from the capabilities you need, not from familiarity, as shown in selecting and comparing agent architectures.

Orchestration is a separate layer from the agent

Single agents and coordination between agents are distinct concerns, and Microsoft shipped multi-agent orchestration as its own framework for building, managing and scaling agent workflows. Guest material shows orchestration combining with the Agent-to-Agent protocol for interoperable systems. Get one agent reliable before adding more, since coordination multiplies cost and failure points.

The framework supplies orchestration, not domain logic

Semantic Kernel gives you agents and agentic patterns, kernels and plugin wiring. Data sources, business rules, validation and scoring are yours to build. Teams that expect the framework to know their domain end up with agents that improvise answers. Budget most engineering time for the tools the agent calls.

Measure on your own workload

Published results vary widely: one 2026 benchmark study found sharp drops on mathematical reasoning across all frameworks, and a comparative analysis flagged high token use in Semantic Kernel Chat. Neither is a standardized ranking. Dataiku recommends running the same agent workflow on two to three candidate frameworks against your actual data and tools, which is the only comparison that predicts your costs.

Steps

1. Define the task and required capabilities Write down what the agent must accomplish, which tools it needs, what state it must keep, and which model service you can use. This description drives every later choice, including agent type. Keep it concrete: inputs the user provides, outputs they expect, and actions the agent may take. If you cannot list the tools, the agent is not ready to be built.

2. Choose the package line Decide between the Semantic Kernel packages and Microsoft Agent Framework before writing code. The Semantic Kernel repository now points to Microsoft Agent Framework as the successor, and a migration guide covers moving existing code. Early agent APIs were marked experimental, so verify the version and package status you pin. Record the decision so the whole team builds against the same APIs.

3. Build the kernel and add an AI service The quick start sequence is to import packages, add AI services, build the kernel, add plugins, configure planning, and invoke. Keep service configuration outside code so you can swap models. Register one reusable kernel with your application builder instead of rebuilding it per request. A working kernel that returns a plain chat answer is your first checkpoint.

4. Expose your code as plugins Wrap each operation as a function, decorate it with KernelFunction, and place it in a plugin that you add to the kernel passed to the agent. Plugins can be added before or after the agent is created, or passed to its constructor. Give functions descriptive names and structured inputs and outputs. Test each function directly before letting the model call it.

5. Create the agent and enable function calling Pick the agent type that matches your service, give it a persona and instructions, and attach the kernel. Enable automatic function calling in execution settings so the model can select and invoke registered functions until it produces a result. Avoid the deprecated Stepwise and Handlebars planners, which current guidance says have been removed. Confirm in logs that tools are actually being invoked.

6. Manage chat history Keep a ChatHistory record per conversation so the agent sees prior turns. In the Agents SDK integration, developers pass turn state into ChatHistory so the kernel can use channel information during orchestration. Decide early whether history must survive restarts, because sample in-memory storage will not. Watch history length, since long histories raise token cost on every call.

7. Evaluate against real tasks and alternatives Run the agent on a fixed set of representative tasks and inspect tool calls as well as final answers. Compare it with one or two alternative frameworks on the same tasks, as Dataiku suggests. Track accuracy, latency and token use, because published benchmarks show large variation by task type. Add orchestration or more agents only after a single agent passes.

When to Use

• Your application is built on .NET or runs in Azure, because practitioner comparisons rate native .NET and Azure integration as Semantic Kernel's main strength.
• You need an LLM to call existing business code, since the plugin model turns ordinary functions into tools with little glue.
• You are maintaining an existing Semantic Kernel codebase and need agents now, with a documented migration path to Microsoft Agent Framework later.
• You want both single agents and coordinated multi-agent workflows under one abstraction, so you can start small and add orchestration without switching libraries.
• Your enterprise requires plugin sources such as OpenAPI services or MCP tools, which the plugin ecosystem supports directly.

When Not to Use

• You are starting a greenfield project today, because Microsoft now presents Microsoft Agent Framework as the successor with stable, long-term-supported APIs, so starting on the older line adds a migration.
• Your team is Python-first and wants the newest community patterns immediately, since comparisons note those often appear in other ecosystems first.
• Your workflow is heavily conditional and cyclical and you need explicit control over every branch, where graph-based frameworks like LangGraph are described as the stronger fit.
• Token budget is tight and you plan chatty multi-agent conversations, since one comparative study measured substantially higher token use for Semantic Kernel Chat.