Semantic Kernel
Microsoft's open-source, multi-language SDK for building and orchestrating AI agents and multi-agent systems.
- Source repo
- microsoft/semantic-kernel
- Stars
- ★ 29k
- Last updated
- today
- License
- MIT
- Primary language
- C#
- FA score
- 51/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Backend teams adding an assistant to an existing .NET or Python service that must call internal business functions
- Not a fit if
- Teams planning long-term investment: Microsoft positions Agent Framework as the successor, so migration work is likely
- End users who want a ready-made app rather than an SDK to code against
- Source review
- 51/100 · Major gaps
What does this agent do, and when should you use it?
Semantic Kernel is a model-agnostic, MIT-licensed SDK from Microsoft for embedding LLM capabilities into your own applications and composing AI agents. It ships for Python, .NET and Java, with core building blocks such as the Kernel, ChatCompletionAgent, kernel functions/plugins, and multi-agent orchestration. Agents can be extended with native code functions, prompt templates, OpenAPI specs or Model Context Protocol servers, and paired with vector stores like Azure AI Search, Elasticsearch and Chroma for memory. It handles text, vision and audio inputs and can run against local runtimes such as Ollama, LMStudio or ONNX. Important context for adopters: the README states Semantic Kernel has been succeeded by Microsoft Agent Framework, now at 1.0, with a published migration guide.
You build an agent either through Kernel.CreateBuilder() or by instantiating ChatCompletionAgent and attaching a connector such as AzureChatCompletion or OpenAIChatCompletion to pick the underlying model. Agents load plugins: Python methods decorated with @kernel_function or .NET methods marked [KernelFunction] expose local capabilities to the model, which then decides which function to call, guided by FunctionChoiceBehavior.Auto() in PromptExecutionSettings. For multi-agent setups, specialist agents like BillingAgent or RefundAgent are passed as plugins to a TriageAgent that evaluates the request and hands it off. Output arrives as ChatMessageContent from agent.get_response() or InvokeAsync(), and ChatHistoryAgentThread preserves conversation context across turns. The library runs inside your process; model calls go out to whichever cloud or local endpoint you configured.
- Backend teams adding an assistant to an existing .NET or Python service that must call internal business functions
- Customer-support systems that route requests to specialist agents such as billing and refund handlers
- Applications that need agent memory and retrieval backed by a vector store like Azure AI Search, Elasticsearch or Chroma
- Projects requiring text, vision and audio inputs in one agent pipeline
- Teams with compliance constraints that run models locally via Ollama, LMStudio or ONNX
- Existing Semantic Kernel users planning the move to Microsoft Agent Framework via the official migration guide
How do you install or deploy this agent?
Set the environment variable for your model service. Azure OpenAI:
export AZURE_OPENAI_API_KEY=AAA....Or OpenAI directly:
export OPENAI_API_KEY=sk-...Python (requires Python 3.10+):
pip install semantic-kernel.NET (requires .NET 10.0+):
dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Agents.CoreJava builds follow BUILD.md in the semantic-kernel-java repository and require JDK 17+. Windows, macOS and Linux are supported.
How do you use this agent?
A minimal working chat agent in 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())Adding a plugin so the agent can call your own code:
from semantic_kernel.functions import kernel_function, KernelArguments
from semantic_kernel.connectors.ai.open_ai import OpenAIChatPromptExecutionSettings
class MenuPlugin:
@kernel_function(description="Provides a list of specials from the menu.")
def get_specials(self) -> str:
return "Special Soup: Clam Chowder"
agent = ChatCompletionAgent(
service=AzureChatCompletion(),
name="SK-Assistant",
instructions="You are a helpful assistant.",
plugins=[MenuPlugin()],
arguments=KernelArguments(OpenAIChatPromptExecutionSettings()),
)When something fails, verify the API key environment variables are set and that your Azure OpenAI deployment or OpenAI model access is valid.
What are this agent's strengths and limitations?
- Model flexibility: built-in connectors for OpenAI, Azure OpenAI, Hugging Face and NVidia, plus local runtimes Ollama, LMStudio and ONNX
- Mature plugin system spanning native code functions, prompt templates, OpenAPI specs and Model Context Protocol
- Multi-agent orchestration is first-class: specialist agents can be mounted directly as plugins on a coordinating agent
- SDKs for Python, .NET and Java, with dedicated C# and Python API reference docs
- MIT license, usable in commercial projects
- Microsoft positions Agent Framework as the successor, so long-term projects should budget for migration
- Cloud model usage requires your own Azure OpenAI or OpenAI key and is billed per use
- The three language SDKs differ in API surface, so examples and docs must be consulted per language
- Multi-agent handoffs and automatic function calling mean extra model round-trips, raising latency and cost
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Semantic Kernel This agent | 51 · Major gaps | Library / SDKFree + model costs | ★ 29k | today | C# | OpenAI API |
| MassGen | 51 · Major gaps | CLIFree + model costs | ★ 1.1k | 4mo ago | Python | Codex · Claude Code · OpenAI API · Claude API |
| Polter Terminal Agent Supervisor | 80 · Good | Desktop appFree + model costs | ★ 20 | today | Zig | Claude Code |
| Spring AI Alibaba | 53 · Major gaps | FrameworkFree + model costs | ★ 11k | 13d ago | Java | — |
How does FollowAgents rate this agent?
Why each dimension lost points
Trust evidence is limited. least_privilege scores 2: CI workflows scope GitHub App tokens by permission profile (issues/pull-requests/team-check), and tests show unknown profiles are rejected before signing, demonstrating least-privilege design; however this governs the repo's own CI, not the Agent product's runtime permissions over user data. user_confirmation scores 1: README examples auto-invoke plugins (FunctionChoiceBehavior.Auto) with no described confirmation step for tool calls. data_flow_transparency scores 1: README only names OpenAI/Azure connectors, with no description of data flows, logging, or telemetry. sensitive_data_handling scores 1: only guidance to store API keys in environment variables; no masking, storage, or retention policy. dependency_security scores 1: no dependency manifest or vulnerability scanning evidence; SECURITY.md only provides a reporting channel. external_effects scores 1: plugins can execute local code and call external APIs, but no side-effect boundary is documented. rollback scores 1: no rollback or undo mechanism described. source_attribution scores 2: MIT license and Microsoft copyright are clear, with SECURITY.md and code of conduct present.
self_consistency scores 2: Python/.NET examples are structurally consistent and the ADR analyzes API trade-offs. dependency_availability scores 2: PyPI/NuGet package names and install commands are given, with Java pointing to a separate repo's build docs. failure_messages scores 2: README troubleshooting lists auth and model-availability issues, and CI tests show explicit errors for 403/404, empty signatures, and empty tokens; runtime error handling detail is not expanded in the evidence.
audience_and_scenarios scores 2: developer-facing, covering single-agent, multi-agent, plugins, vector DBs, and multimodal scenarios. capability_boundaries scores 2: README states system requirements (Python 3.10+, .NET 10+, JDK 17+) and supported models/local deployment options. trigger_precision scores 1: agent triggering relies on LLM function selection with no precise trigger-condition control described. environment_fit scores 2: supports Windows/macOS/Linux and local deployment via Ollama/LMStudio/ONNX.
information_architecture scores 2: README is well structured with install, quickstart, troubleshooting, community, and license sections. install_notes scores 2: pip/dotnet install and env var setup given; Java points to external build docs. naming_stability scores 1: README banner states the project is superseded by Microsoft Agent Framework, creating migration and naming-evolution risk, with stability commitments pointing to the successor. examples_and_faq scores 2: multi-language examples plus FAQS.md (nightly builds). known_limitations scores 1: only auth and model-availability issues mentioned; limitations not systematically listed. license scores 3: full MIT text in LICENSE with clear copyright. versioning_changelog scores 1: no CHANGELOG; only package version badges and nightly version format in FAQ. maintenance_responsibility scores 2: maintained by the official Microsoft org with SECURITY.md and contribution guidance, though in transition to MAF.
output_usability scores 2: examples are copy-runnable with expected outputs. marginal_value scores 2: as a model-agnostic agent orchestration SDK it offers plugins, multi-agent, and vector DB integrations. cost_benefit scores 1: no token consumption, latency, or cost guidance; the ADR discusses token-usage data structures, not cost control.
claim_traceability scores 1: claims like 'enterprise-grade reliability' lack in-repo verifiable support and mostly link to external docs. cross_source_corroboration scores 1: README, ADR, FAQ, and SECURITY are topically related but do not corroborate specific claims. fact_inference_separation scores 1: README mixes marketing language with factual statements without distinguishing verified from inferred content.
- README states the project is superseded by Microsoft Agent Framework; long-term maintenance and API stability may shift to the successor, so migration cost should be assessed before adoption.
- Examples auto-invoke plugins (FunctionChoiceBehavior.Auto) with no described confirmation or permission boundary; add your own confirmation layer for sensitive operations.
- No dependency manifest or vulnerability scanning evidence is provided; SECURITY.md is only a reporting channel, so dependencies must be audited independently.
- No cost, token-consumption, or latency guidance; evaluate cost independently before production use.
- This is a static source review with low confidence; no code or tests were executed.