Wiki · Concept · Last reviewed June 25, 2026

Semantic Kernel

Semantic Kernel is Microsoft's open-source development kit for building AI agents and model-connected applications by wrapping prompts, code, APIs, memory, and workflows into callable software components.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Semantic Kernel, Microsoft, AI Agents, Plugins, Tool Use, Agent Framework

Definition

Semantic Kernel is a Microsoft open-source SDK for building AI agents and integrating models into application code. Microsoft Learn describes it as a lightweight development kit for building agents and connecting current AI models to C#, Python, and Java codebases. The official GitHub repository describes it as a model-agnostic SDK for building, orchestrating, and deploying AI agents and multi-agent systems.

The name refers to a software layer, not a model. A Semantic Kernel application can call model services, expose native code as functions, organize those functions into plugins, maintain conversational or task state, and use an agent framework to combine model reasoning with callable capabilities. Its significance is that it helps move AI work from a prompt-only interface into ordinary application architecture.

Semantic Kernel should not be confused with LangChain, DSPy, Model Context Protocol, or Microsoft's newer Agent Framework. Microsoft Agent Framework documentation now describes Agent Framework as the next generation of both Semantic Kernel and AutoGen, with migration guidance for Semantic Kernel users.

Architecture

The kernel is the orchestration object. It wires together model connectors, prompts, functions, plugins, configuration, and execution services. In practical terms, it is where a developer decides which AI services and which application capabilities a run may use.

Plugins are the main bridge between model behavior and application code. Microsoft Learn describes plugins as collections that encapsulate existing APIs so an AI application can perform actions it could not perform from text alone. Those functions can represent internal business logic, database queries, search calls, document workflows, ticket updates, or other code-controlled actions.

Planning has changed over time. Microsoft Learn's planning page says early Semantic Kernel planners used prompts to ask an AI system which functions to invoke, while native function calling across models such as OpenAI, Gemini, Claude, and Mistral has become the preferred base for many tool-selection workflows. That history matters because "planner" can mean an older prompt-planning abstraction or a newer tool-calling pattern around model-native function calls.

Agent Context

The Semantic Kernel Agent Framework is documented as a platform inside the Semantic Kernel ecosystem for creating AI agents and incorporating agentic patterns into applications. A Semantic Kernel agent can use conversation state, model calls, tools, plugins, and orchestration code to pursue tasks that cross more than one model response.

For governance, the important boundary is not whether the system is called an agent. The important boundary is which functions are registered, what scopes they carry, which model can request them, what human approval is required, and what logs prove the action path after the fact. A harmless chat wrapper and an agent that can update customer records may use similar abstractions while carrying radically different risk.

Semantic Kernel also matters because it speaks the language of enterprise software teams. C#, Python, Java, dependency injection, service connectors, and plugin registration make it easier to put AI capability into existing applications.

Governance and Safety

Semantic Kernel deployments should be reviewed as application systems, not demos. The review record should name the model provider, model version where available, registered plugins, function descriptions, input schemas, output validators, memory stores, data classes exposed, credential sources, execution environment, approval rules, and trace-retention policy.

Plugins deserve special scrutiny. A model-facing function description is both interface documentation and behavioral steering. If a plugin description is vague, overbroad, stale, or prompt-injected through generated configuration, the model may select the wrong capability. If the underlying function lacks authorization checks, the host application may execute an action merely because the model produced a plausible call.

The Microsoft Agent Framework transition is also a governance signal. Migration should trigger change management: which abstractions are deprecated, which packages remain supported, which approval and logging patterns change, and whether existing evaluations still describe the new runtime.

Defense Pattern

Inventory plugins. Record every plugin, function, model connector, endpoint, scope, secret source, and data class available to the kernel.
Separate read and write. Keep read-only retrieval functions distinct from functions that create, update, delete, spend, message, deploy, or disclose.
Gate dangerous functions. Require explicit human or policy approval before irreversible or high-impact functions run.
Validate twice. Validate model-produced arguments against schemas and enforce authorization in the called code.
Log the action path. Preserve user intent, model response, selected plugin, function arguments, approval result, returned data, and side effect.
Version migrations. Treat movement from Semantic Kernel abstractions into Microsoft Agent Framework as an architecture change, not a mechanical package update.

Source Discipline

Claims about Semantic Kernel should cite Microsoft Learn for current documentation and the Microsoft GitHub repository for the open-source project. Claims about successor positioning should cite the Microsoft Agent Framework overview or migration guide rather than assuming that every Semantic Kernel pattern remains current.

Do not cite Semantic Kernel as proof that an agent is safe, authorized, or enterprise-ready. It is a development kit and orchestration layer. Safety depends on the surrounding application architecture, identity, authorization, sandboxing, logging, evaluation, and operational review.

Spiralist Reading

Spiralism reads Semantic Kernel as a loom between language and code. It takes the model's uncertain text and threads it through plugins, functions, memory, and workflow machinery.

That is useful because institutions run on code, not only conversation. It is dangerous for the same reason. Once model output can call institutional functions, the question is no longer "what did the machine say?" but "what did the machine-mediated system do, under whose authority, and with which record?"

Open Questions

Which existing Semantic Kernel deployments should migrate to Microsoft Agent Framework, and which should remain on stable SDK patterns?
How should teams audit plugin descriptions that become model-facing authority cues?
What trace fields are necessary to reconstruct a Semantic Kernel tool call after an incident?
How should model-native function calling, MCP servers, and Semantic Kernel plugins be governed together when all three expose tools?

Sources

Microsoft Learn, Introduction to Semantic Kernel, reviewed June 25, 2026.
GitHub, microsoft/semantic-kernel, official repository, reviewed June 25, 2026.
Microsoft Learn, Plugins in Semantic Kernel, reviewed June 25, 2026.
Microsoft Learn, What are planners in Semantic Kernel?, reviewed June 25, 2026.
Microsoft Learn, Semantic Kernel Agent Framework, reviewed June 25, 2026.
Microsoft Learn, Microsoft Agent Framework overview, reviewed June 25, 2026.
Microsoft Learn, Semantic Kernel to Microsoft Agent Framework Migration Guide, reviewed June 25, 2026.

Return to Wiki