Semantic Kernel in Production: Plugins, Connectors, and Function Calling
Reviewed by Umar Abbas • Founder & Principal AI Architect
Last reviewed: 14 August 2026
Semantic Kernel is Microsoft's open source SDK for embedding large language model capabilities into C#, Python, and Java applications. It exposes native and prompt functions as plugins, invokes them through model driven automatic function calling, and connects to Azure OpenAI, OpenAI, and vector stores behind a single kernel abstraction.
What Semantic Kernel Solves in Production
Enterprise teams often need LLM capabilities inside existing .NET or JVM services rather than a separate Python stack, and they need model behavior that is auditable and permissioned. Hand rolled prompt code tends to scatter tool definitions, secrets, and retry logic across a codebase with no clean interception point. Semantic Kernel centralizes model connectors, tool definitions, and configuration behind a kernel, then lets the model select tools through automatic function calling. Filters give a single place to add logging, PII redaction, and validation. The result is agent behavior that fits into standard dependency injection, secret management, and observability practices already in use.
Anatomy of a Semantic Kernel Application
Anatomy ExplainerCore Component Component Parts:
Kernel
The central container that holds services, plugins, and configuration for a request.
Built via Kernel.CreateBuilder, it resolves IChatCompletionService and KernelFunction metadata through dependency injection at invocation time.
Text alternative for screen readers & search engines
- Part 1: Kernel - The central container that holds services, plugins, and configuration for a request. [Tech: Built via Kernel.CreateBuilder, it resolves IChatCompletionService and KernelFunction metadata through dependency injection at invocation time.]
- Part 2: Plugins and Functions - Groups of callable native methods and prompt templates the model is allowed to invoke. [Tech: A KernelFunction wraps a native method decorated with KernelFunction and Description attributes, or a prompt template rendered by the built in prompt engine.]
- Part 3: AI Service Connectors - Adapters to chat, embedding, and image models across multiple providers. [Tech: Connectors for Azure OpenAI, OpenAI, Mistral, and others implement IChatCompletionService and ITextEmbeddingGenerationService interfaces.]
- Part 4: Memory and Vector Stores - Abstractions for embeddings and semantic retrieval over external stores. [Tech: IVectorStore and VectorStoreRecordCollection back connectors for Qdrant, Azure AI Search, Redis, and Postgres pgvector.]
- Part 5: Automatic Function Calling - Model driven selection and invocation of the registered functions. [Tech: FunctionChoiceBehavior.Auto replaces the legacy SequentialPlanner and StepwisePlanner, delegating tool selection to the model tool calling loop.]
Architectural Strengths & Specific Production Limits
- Enterprise language coverage: First class C#, Python, and Java SDKs let teams embed agents directly inside existing .NET and JVM services without standing up a separate Python microservice.
- Azure and OpenAI alignment: Native connectors for Azure OpenAI, managed identity, and content filtering fit regulated Microsoft estates with minimal integration glue.
- Filter based observability: Function and prompt filters give a clean interception point for logging, PII redaction, and OpenTelemetry spans around every model call.
- Stable versioned core: The 1.x core packages follow semantic versioning with a documented non breaking policy, which makes pinning and upgrades predictable.
- Weaker explicit state model: Semantic Kernel favors automatic function calling over an explicit graph, so complex branching and resumable workflows need more manual plumbing than LangGraph.
- Connector maturity varies: Non Azure connectors and some vector store integrations lag the .NET flagship, and a number of them remain experimental behind preview packages.
- Framework churn: The agent and process abstractions have changed shape across minor versions, and Microsoft is consolidating them into the newer Microsoft Agent Framework.
- Legacy planners deprecated: SequentialPlanner and StepwisePlanner are deprecated in favor of function calling, so many older tutorials no longer reflect current guidance.
How We Deploy Semantic Kernel in Production
We treat a Semantic Kernel agent as a normal service component. Capabilities are modeled as tightly described KernelFunctions, connectors are wired with managed identity or vault backed secrets, and function calling runs with low temperature and bounded invoke rounds to control latency and cost. Every native and prompt call passes through invocation filters for validation, redaction, and audit logging, and telemetry flows to OpenTelemetry with package versions pinned in CI.
Our Semantic Kernel Delivery Pipeline
Interactive Flow DiagramWe model each capability as a KernelFunction with tight descriptions and typed parameters so the model selects tools reliably.
Text alternative for screen readers & search engines
| Step | Stage Name | Function & Detail | Metrics / SLA |
|---|---|---|---|
| 1 | 1. Plugin Design | We model each capability as a KernelFunction with tight descriptions and typed parameters so the model selects tools reliably. | Descriptions tuned for tool selection |
| 2 | 2. Connector Wiring | Azure OpenAI or OpenAI chat and embedding connectors are registered with managed identity or key vault backed secrets. | Managed identity, no inline keys |
| 3 | 3. Function Calling | FunctionChoiceBehavior.Auto drives tool selection with low temperature and capped auto invoke rounds to bound latency and cost. | Bounded invoke loops |
| 4 | 4. Filters and Guardrails | Function invocation filters add PII redaction, argument validation, and audit logging around every native and prompt call. | Per call audit trail |
| 5 | 5. Deploy and Observe | OpenTelemetry traces and metrics stream to Azure Monitor or the customer stack, with pinned package versions enforced in CI. | Version pinned CI builds |
// PackageReference Include=Microsoft.SemanticKernel Version=1.30.0
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;
using Microsoft.SemanticKernel.Connectors.OpenAI;
var builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion(
deploymentName: "gpt-4o",
endpoint: "https://your-resource.openai.azure.com/",
apiKey: Environment.GetEnvironmentVariable("AZURE_OPENAI_KEY")!);
builder.Plugins.AddFromType<TimePlugin>();
Kernel kernel = builder.Build();
var settings = new OpenAIPromptExecutionSettings
{
FunctionChoiceBehavior = FunctionChoiceBehavior.Auto(),
Temperature = 0.2,
MaxTokens = 800
};
var chat = kernel.GetRequiredService<IChatCompletionService>();
var history = new ChatHistory();
history.AddUserMessage("What time is it in UTC right now?");
var result = await chat.GetChatMessageContentAsync(history, settings, kernel);
Console.WriteLine(result.Content);Services Engineered with Semantic Kernel
Two engagements where we most often ship Semantic Kernel into production.
Semantic Kernel vs LangGraph and LangChain
How Semantic Kernel stacks up against two widely used agent frameworks on the criteria that decide production fit.
Framework Suitability Matrix
Benchmark Matrix| Evaluation Metric | Semantic Kernel | LangGraph | LangChain |
|---|---|---|---|
| First class .NET and Java support | Native C#, Python, and Java SDKs Winner | Python and JavaScript only | Python and JavaScript only |
| Stateful graph orchestration | Automatic function calling, less explicit state | Explicit graph, nodes, edges, and checkpointing Winner | Chains and agents, weaker state model |
| Integration and ecosystem breadth | Growing connector set, Azure centric | Focused agent runtime | Very large integration catalog Winner |
| Enterprise telemetry and filters | Built in filters plus OpenTelemetry Winner | LangSmith tracing | LangSmith tracing |
Text alternative for screen readers & search engines
- First class .NET and Java support: Semantic Kernel: Native C#, Python, and Java SDKs vs LangGraph: Python and JavaScript only vs LangChain: Python and JavaScript only (Winning option: Semantic Kernel).
- Stateful graph orchestration: Semantic Kernel: Automatic function calling, less explicit state vs LangGraph: Explicit graph, nodes, edges, and checkpointing vs LangChain: Chains and agents, weaker state model (Winning option: LangGraph).
- Integration and ecosystem breadth: Semantic Kernel: Growing connector set, Azure centric vs LangGraph: Focused agent runtime vs LangChain: Very large integration catalog (Winning option: LangChain).
- Enterprise telemetry and filters: Semantic Kernel: Built in filters plus OpenTelemetry vs LangGraph: LangSmith tracing vs LangChain: LangSmith tracing (Winning option: Semantic Kernel).
Semantic Kernel in a Reference Architecture
We used a Semantic Kernel agent to classify and extract fields from incoming financial documents inside a .NET service, exposing extraction and validation steps as native functions. Invocation filters gave the compliance team an auditable trail of every model call and redacted sensitive values before logging. Automatic function calling kept the orchestration in the model while human review stayed in the loop for low confidence cases.
Read Reference Architecture →Frequently Asked Questions
What is Semantic Kernel used for?↓
Semantic Kernel is a Microsoft SDK for adding LLM reasoning and tool use into conventional applications. Developers register capabilities as plugins, then let a model decide which functions to call to complete a task. It is commonly used to build copilots, retrieval augmented assistants, and task automation inside existing .NET, Python, or Java services.
Is Semantic Kernel free and what license does it use?↓
Yes. Semantic Kernel is open source and released under the MIT license on GitHub. You can use it commercially without fees, though the underlying model calls to Azure OpenAI or OpenAI are billed separately by the provider.
What languages does Semantic Kernel support?↓
Semantic Kernel ships first class SDKs for C# and .NET, Python, and Java. The .NET packages are the most mature and receive features first, while the Python and Java ports track behind on some connectors and abstractions.
How does Semantic Kernel compare to LangChain?↓
LangChain has a broader Python and JavaScript integration catalog and a larger community. Semantic Kernel is stronger for enterprise Microsoft estates, offering native C# and Java support, managed identity, and tight Azure OpenAI alignment. Teams building inside .NET or the JVM usually prefer Semantic Kernel.
What happened to Semantic Kernel planners?↓
The original SequentialPlanner and StepwisePlanner are deprecated. Microsoft moved orchestration to model native automatic function calling through FunctionChoiceBehavior. In current code the model itself selects and invokes functions in a tool calling loop instead of a separate planner object.
Does Semantic Kernel support the Model Context Protocol?↓
Yes. Semantic Kernel can consume MCP servers and expose their tools as kernel functions, so an MCP server becomes another plugin the model can call. This lets teams reuse existing MCP tool servers without rewriting them as native functions.
How does Semantic Kernel relate to the Microsoft Agent Framework?↓
Microsoft announced the Agent Framework in late 2025 to consolidate Semantic Kernel and AutoGen into one agent stack. Semantic Kernel remains supported and its concepts carry forward, but new multi agent work is increasingly targeted at the newer framework. Plan upgrades with that direction in mind.
Can Semantic Kernel use non Microsoft models?↓
Yes. Beyond Azure OpenAI and OpenAI, connectors exist for providers such as Mistral, Hugging Face, Google, and local runtimes through OpenAI compatible endpoints and Ollama. Connector maturity varies, so validate the specific provider and language SDK you intend to ship.
Is Semantic Kernel production ready?↓
The 1.x core packages are generally available and follow semantic versioning with a documented non breaking policy. The kernel, connectors, and filters are stable for production, while some agent and vector store abstractions still ship as preview and should be pinned and tested carefully.