Semantic Kernel Tutorial: Plugins, Function Calling, and Current Agent Boundaries

Direct answer: Semantic Kernel remains useful for exposing governed enterprise capabilities to models, but the current mainline is no longer “Skills plus Planner.” The more accurate architecture is Kernel + Plugins + function calling: wrap existing C#, Python, or Java services as plugin functions and let native model function calling choose the functions. The old Stepwise and Handlebars planner families were deprecated and removed from the primary SDK packages.

The previous article had a technology-generation problem rather than a formatting problem. It recommended SequentialPlanner, discussed FunctionCallingStepwisePlanner, and treated skprompt.txt, config.json, and the old Semantic Function vocabulary as if they represented the current 2026 path.

What Semantic Kernel is good at now

Semantic Kernel provides a governed integration point for AI services and existing application capabilities.

A Kernel can bring together:

• model and AI services;
• plugins;
• dependency injection;
• logging and telemetry;
• function schemas for model tool calling;
• application-owned services and infrastructure dependencies.

That is especially useful for an existing .NET application with domain services, repositories, HTTP clients, authorization and observability that wants to expose a small approved subset of those capabilities to a model.

Plugins are the core abstraction

A plugin is a collection of semantically described functions. The functions may retrieve data or perform tasks.

Current Microsoft documentation emphasizes that models need more than a callable method. They need usable metadata:

• plugin name;
• function name;
• function description;
• input parameters and schemas;
• return schema;
• side-effect semantics.

A native C# plugin can reuse the application’s existing service layer:

using System.ComponentModel;
using Microsoft.SemanticKernel;

public sealed class OrderPlugin
{
    private readonly IOrderService _orders;

    public OrderPlugin(IOrderService orders)
    {
        _orders = orders;
    }

    [KernelFunction("get_order_status")]
    [Description("Read an order status. This function never changes the order.")]
    public async Task<string> GetOrderStatusAsync(
        [Description("Internal order identifier")] string orderId)
    {
        return await _orders.GetStatusAsync(orderId);
    }
}

Register the service and plugin with the Kernel:

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
    deploymentName: deploymentName,
    endpoint: endpoint,
    apiKey: apiKey
);

builder.Services.AddSingleton<IOrderService, OrderService>();
builder.Plugins.AddFromType<OrderPlugin>("Orders");

Kernel kernel = builder.Build();

The value is not merely a short tool wrapper. The plugin can reuse dependency injection and business services without putting database connections or credentials into prompts.

Planning now uses function calling

Early Semantic Kernel releases introduced Planner classes that asked the model to generate an execution plan before invoking functions.

As modern providers adopted native function calling, Semantic Kernel moved its planning model to the function-calling loop: expose plugin functions and let the model choose which function to call and whether another call is needed after receiving a result.

Current Microsoft planning documentation explicitly says:

• function calling is the primary planning/execution mechanism;
• Stepwise planners were removed;
• Handlebars planners were removed;
• those planner families are no longer supported in Python, .NET, or Java;
• new agents should use function calling.

Do not recommend these as current defaults:

SequentialPlanner
FunctionCallingStepwisePlanner
HandlebarsPlanner

If a historical project still depends on them, treat that as a migration task.

The real boundary of automatic function calling

Automatic function calling can answer:

Which plugin function should handle this request, what arguments should be passed, and should another function be called after the result?

It does not answer:

• whether the user is authorized;
• whether a high-risk action was approved;
• whether an external write already succeeded;
• whether a timeout can be retried safely;
• whether payment, publishing or deletion satisfies business policy.

A safer production execution path is:

Model requests function
        │
        ▼
Schema validation
        │
        ▼
Authorization / policy gate
        │
        ├─ high risk ─► Human approval
        ▼
Idempotency check
        │
        ▼
Business service executes
        │
        ▼
Result returned to model

A strong plugin description does not replace authorization code.

Native code, OpenAPI, and MCP are plugin sources

Current Semantic Kernel plugin documentation supports several ways to expose capabilities:

1. Native code — best when the application already has services and dependency injection;
2. OpenAPI — useful for existing HTTP APIs and cross-team service contracts;
3. MCP Server — useful when capabilities already exist behind a Model Context Protocol boundary.

That is why Semantic Kernel and MCP are not simply competing frameworks. MCP can be an interoperability/tool source while Semantic Kernel manages the application Kernel, services and function-calling composition.

Plugin schema matters more than clever prompting

If two functions are named:

search_data
query_data

and both are described only as “query data,” the model has little signal for stable selection.

Production plugins should state:

• when to use the function;
• when not to use it;
• whether it is read-only;
• parameter constraints;
• whether the result is complete or partial;
• possible side effects;
• retryable versus non-retryable failures.

The higher the risk, the stronger both the schema and the application policy gate should be.

Dependency injection is a durable enterprise advantage

The Kernel acts as a composition root for services and plugins. In .NET this enables:

• HttpClientFactory reuse;
• repository and domain-service injection;
• common logging, telemetry and cancellation;
• secrets kept outside model-visible input;
• mock service replacement in tests.

Those boundaries are more valuable to a long-lived enterprise system than an old prompt-generated Planner path.

Semantic Kernel versus Microsoft Agent Framework

Microsoft now publishes a migration path from Semantic Kernel to Microsoft Agent Framework. Agent Framework focuses more directly on newer Agent and Workflow APIs and a unified multi-provider development model.

That does not make an existing Semantic Kernel plugin architecture invalid overnight. Ask:

• Is the application mainly model + enterprise plugins, or does it need a more explicit agent/workflow layer?
• Do Agent Framework session, workflow, handoff, or HITL capabilities materially simplify the system?
• Does migration reduce maintenance cost?
• Can the existing Kernel plugins remain stable business capabilities during migration?

If a production application only needs governed plugins plus function calling, rewriting it for a newer SDK name has no inherent value.

Legacy concepts that should now be migration-only context

Legacy concept	Current treatment
Skill	Prefer current Plugin/Function terminology for new code
Semantic Function vs Native Function as the primary taxonomy	Focus current examples on plugin functions and KernelFunction
SequentialPlanner	Do not recommend to new projects
FunctionCallingStepwisePlanner	Do not recommend to new projects
Handlebars Planner	Removed
skprompt.txt + config.json as the main plugin tutorial	Not representative of current native plugin development

FAQ

Semantic Kernel or LangChain?

There is no universal winner. Semantic Kernel is a natural fit when an enterprise .NET application already has dependency injection and Microsoft-platform assets. LangChain v1 is more direct for Python teams using create_agent, middleware and the LangGraph runtime. Choose by language, state, operations and authorization requirements rather than repository popularity.

Can Semantic Kernel use a local model?

Check the current connector/provider documentation for the exact deployed version. Do not make the old promise that a custom ITextCompletion automatically creates “100% privacy”; telemetry, plugin APIs, logging and the deployment architecture still affect the real data boundary.

More to Explore

• AI Agent Frameworks 2026
• MCP Resources vs Tools vs Prompts vs Roots
• AI Agent Tool Authorization Policy Gate
• Complete AI Agent Engineering Guide

Topic path / AI Agents

Continue from one agent pattern to the complete production system

The AI Agent hub organizes architecture, memory, tool use, evaluation, security, deployment and multi-agent coordination into a single learning path.

Open AI Agent hub → Review the architecture guide Subscribe