Semantic Kernel Review: Support, Plugins, Costs, and Migration

This Semantic Kernel review examines Microsoft's SDK for connecting AI models to application services and business functions. The central decision has changed: Microsoft now identifies Microsoft Agent Framework as its successor. Existing Semantic Kernel applications need a maintenance and migration assessment; new agent projects should evaluate the successor first.

That does not make every working Semantic Kernel application obsolete. Plugins, function calling, filters, and familiar application architecture still deserve attention. This documentation-based assessment was checked on November 3, 2026. It contains no firsthand performance tests, reliability scores, or claims that a framework alone makes an agent production ready.

Semantic Kernel Review: What Is Its Current Status?

The current Semantic Kernel repository points developers to Microsoft Agent Framework 1.0 and describes that successor as a production-ready release. Microsoft's support statement says Semantic Kernel v1.x will continue receiving attention for critical bugs and security issues, while most new features move to Agent Framework.

Read those statements together. Continued support and being the preferred starting point are different questions. A stable existing service may justify incremental migration, while a new service has less reason to adopt an older abstraction without a specific dependency.

Microsoft's transition also involves AutoGen, but the projects have distinct histories and current notices. SD's AutoGen review explains that project's archived status. Do not automatically apply an AutoGen repository notice to a Semantic Kernel deployment.

For an existing application, inventory the installed packages, connectors, experimental features, and operational dependencies. Base the schedule on concrete exposure and test coverage. Avoid treating a successor announcement as either an immediate rewrite order or a promise of indefinite compatibility.

Plugins and Function Calling: The Practical Appeal

The kernel brings AI services and plugins together. Microsoft's architecture guide describes it as a dependency injection container: a central place to provide the services an application needs. That can fit teams whose business logic already lives in ordinary services with database clients and authorization checks.

Plugins group functions that the model can use. Rather than rewriting an order system as prompts, a developer can expose a narrow operation that calls existing application code. Descriptions and parameter definitions help the model understand the available action.

Consider a support assistant that checks an order's delivery status. A small lookup function is easier to constrain than a general database tool. The function can accept an order reference while the application supplies the authenticated customer's identity separately. That design is a recommendation, not an automatic Semantic Kernel safeguard.

Function calling handles the exchange between a model's requested action and the corresponding code. Semantic Kernel describes functions, processes returned arguments, invokes the selected function when configured to do so, and returns its result to the conversation. Developers can also manage invocation manually.

Convenience does not establish permission. Valid arguments can still request an unauthorized operation. Keep business validation inside the service that performs the action, so another invocation path cannot bypass it.

Language Support and Feature Maturity

Semantic Kernel has C#, Python, and Java implementations, but language availability does not imply feature parity. Microsoft's feature matrix lists capabilities and connectors separately. Check the exact combination your project needs, including optional packages and the model's supported behavior.

This matters for teams adopting examples from another language. A working Python demonstration is useful evidence about that example, not proof that an equivalent Java application has the same instrumentation or integration support. Pin the dependencies used in your own validation.

Multi-agent orchestration needs additional scrutiny. Microsoft's Semantic Kernel orchestration guide marks those features experimental and says they may change significantly. It documents patterns such as sequential execution, concurrent work, handoffs, and group chat. The Java SDK does not currently offer that orchestration layer.

Start with the simplest design that solves the task. Adding agents can introduce more model calls, shared context, and failure paths. A deterministic sequence of ordinary functions may be easier to maintain when the process is already well defined.

Security Controls and Observability

Semantic Kernel filters provide interception points around function invocation, prompt rendering, and automatic function calling. They can support checks, logging, changes to results, or termination of an invocation process. Your application must register and implement the relevant behavior.

A refund assistant illustrates the boundary. Looking up a purchase may be permitted, while issuing a refund requires a separate authorization decision. Put that decision next to the actual write operation. Show the amount and recipient before approval, and require a fresh decision if either changes.

SD's AI agent security guide provides a broader framework for permissions and tool boundaries. Apply those principles to every exposed operation, including actions that appear harmless when demonstrated against sample data.

There are implementation details worth testing. Microsoft's filters guide notes that direct chat-completion service calls need the kernel passed in to trigger its filters. For C# dependency injection, it also warns that filter ordering is not guaranteed. A control is effective only when the executed path reaches it.

For diagnosis, Microsoft documents OpenTelemetry-compatible logs, metrics, and traces. Use them to connect a user request to model calls, function execution, and errors. Treat observability as evidence for investigation, rather than proof that the answer or action was correct.

Decide what telemetry may contain before enabling detailed capture. Record enough to investigate denied actions and failures while limiting unnecessary customer data. Validate both the successful request and the rejected request in your chosen language and deployment.

Semantic Kernel Pricing: Budget Beyond the SDK

Semantic Kernel's repository is MIT licensed. Using the SDK does not itself require a framework subscription, but the license does not include model inference, managed infrastructure, or storage. Those costs depend on the services connected to your application.

Build a budget around completed tasks. Include model input and output, retrieval, hosting, monitoring, and repeated attempts. A task that triggers several tool-and-model cycles can cost more than a simple chat response, even when both use the same SDK.

For a pilot, record spending alongside an acceptance criterion: for example, whether a delivery-status answer used the correct order and avoided exposing another customer's information. Count rejected and retried runs too. This is a proposed evaluation method, not a measured Semantic Kernel cost estimate.

Avoid a universal price-per-agent figure. It conceals the model, workload, traffic, and service configuration that determine the bill. Obtain current rates for your actual providers before approving a rollout.

Migration and Alternatives: Choose a Small Pilot

Microsoft's migration guide changes both agent construction and tool registration. In .NET, the successor uses Microsoft.Agents.AI and Microsoft.Extensions.AI abstractions. In Python, tools can be registered directly, and existing KernelFunction objects can be converted through as_agent_framework_tool with Semantic Kernel 1.38 or higher.

The guide also identifies session-cleanup differences. AgentSession does not offer a universal chat-history deletion API; applications may need to track sessions and delete hosted history through the provider's SDK where supported. Include this in retention testing rather than assuming a renamed session type preserves every lifecycle operation.

Migration should begin with one representative workflow. Keep the inputs and expected business outcomes fixed, then compare tool arguments, authorization behavior, streaming, failures, and cleanup. Separate the framework change from a simultaneous model upgrade when practical; otherwise, regressions become harder to attribute.

If your real requirement is explicit workflow recovery and approvals, SD's LangGraph review offers another comparison point. Evaluate alternatives against a written requirement, rather than assuming that switching ecosystems will solve an unclear application design.

A useful pilot should answer three questions: can the application complete its intended task, can it refuse an unauthorized one, and can an operator explain a failed run? Expand only after those results are repeatable with your actual services.

Conclusion

This Semantic Kernel review finds the SDK most relevant to teams maintaining existing integrations or evaluating their next architecture. Understand the plugin model, check language-specific maturity, enforce permissions in application services, and calculate the whole workload's cost. For new agents, begin by evaluating Microsoft's stated successor. For existing systems, use a small, measurable migration pilot to preserve the business behavior that already works.