Semantic Kernel: Building AI Apps on the Microsoft Stack (A Practical Guide for FDEs)

First, a Status Check: Semantic Kernel and Microsoft Agent Framework

Microsoft's picture has moved. In a February 2026 post announcing a release candidate, Microsoft called Microsoft Agent Framework "the successor to Semantic Kernel and AutoGen" and encouraged Semantic Kernel users to move. In April 2026 Visual Studio Magazine reported the 1.0 release for .NET and Python, with stable APIs and a commitment to long-term support, and noted that Microsoft positions it as the successor for new agent-development work. The same report says Semantic Kernel remains active and was not described as deprecated, while AutoGen receives only bug fixes and critical security patches. The Semantic Kernel repository's README now announces that Semantic Kernel is "now Microsoft Agent Framework" and links a migration guide.

What this means in practice:

• Existing customer apps built on Semantic Kernel keep working, and you will need to read, debug and extend them.
• New agent projects should start by evaluating Agent Framework.
• The concepts transfer. Tools, connectors, middleware-style hooks and orchestration appear in both.
• Check current support terms before promising anything to a customer, because timelines and policies change.

The rest of this guide explains Semantic Kernel as it is found in real codebases, then covers how to plan the move.

What Is Semantic Kernel?

Microsoft describes Semantic Kernel as a lightweight, open-source development kit that lets you build AI agents and integrate AI models into your C#, Python or Java codebase, and as middleware for delivering enterprise-grade solutions. It reached 1.0 across all three languages with a commitment to non-breaking changes, according to Microsoft's introduction page.

Its core job is bridging models and your code. When a model asks to call a function, Semantic Kernel translates the request into a function call and passes the result back to the model. Microsoft also says you can swap in new models as they are released without rewriting your whole codebase.

Why FDEs Meet Semantic Kernel

• Microsoft-centred customers often prefer first-party tooling that fits Azure, .NET and their security review.
• Existing code becomes useful quickly. Plugins let you expose internal APIs to a model without a rewrite.
• It sits between low-code and bespoke. When Copilot Studio is too limiting but you do not want to hand-build everything, an SDK is the middle path. Our piece on whether Microsoft has forward deployed engineers explains the wider Microsoft context.

Core Concepts of Semantic Kernel

Microsoft's components documentation lists the main building blocks.

The repository README adds that Semantic Kernel connects to many model providers including OpenAI and Azure OpenAI, can be extended through native functions, prompt templates, OpenAPI specs or the Model Context Protocol, and integrates with vector databases such as Azure AI Search.

Plugins: Turning Existing Code Into Tools

Plugins are the feature FDEs use most. You wrap an existing function, describe it clearly and register it with the kernel; the model can then choose to call it. This example was run locally with Semantic Kernel 1.45.0 for Python, invoking the function directly with no model attached:

python

from typing import Annotated

from semantic_kernel import Kernel

from semantic_kernel.functions import kernel_function

‍

class OrdersPlugin:

    @kernel_function(

        name="get_order_status",

        description="Look up the status of one order by its order ID. Does not change the order.",

    )

    def get_order_status(

        self, order_id: Annotated[str, "The order ID, e.g. A-1042"]

    ) -> Annotated[str, "Status text"]:

        return {"A-1042": "Shipped"}.get(order_id, "Not found")

‍

kernel = Kernel()

kernel.add_plugin(OrdersPlugin(), plugin_name="orders")

Three habits make plugins reliable:

1. Write descriptions for the model. The name, description and parameter notes are what the model sees. State what the function does and what it does not do.
2. Keep functions narrow. One clear action each beats a multi-purpose function.
3. Separate reading from writing. Mark or design write actions so they require confirmation. Our guide to MCP for FDEs covers the same least-privilege thinking for tools exposed through a protocol.

For retrieval, expose search as a plugin or use the vector store connectors. How you retrieve depends on the problem; see fine-tuning vs RAG.

Filters: Control Points for Enterprise Apps

Enterprise customers care less about what the model can do and more about what it is allowed to do. Semantic Kernel's filters give you hooks for this. Microsoft's general-availability announcement (21 November 2024) describes three types:

• Function invocation filter. Runs each time a function is invoked. It can inspect arguments, handle exceptions, override the result and retry, for example by switching to another model.
• Prompt render filter. Runs before prompt rendering. It can view and modify the prompt, or override the result so the prompt never reaches the model.
• Auto function invocation filter. Runs within automatic function calling, with chat history and iteration counters, and can end the process early.

Microsoft gives two example uses: removing personally identifiable information before data is sent to a model, and semantic caching built on the prompt render filter. Practitioners also use filters for logging, approvals and policy checks, though those are our examples rather than ones Microsoft lists in that post.

Filters are where the ideas in LLM guardrails and human-in-the-loop design become code, and where the accountability points in AI governance for forward deployed engineers get enforced. Microsoft's documentation also cites telemetry support and hooks and filters as the basis for delivering responsible AI at scale.

Anatomy of an Enterprise AI App

A typical Semantic Kernel application looks like this:

1. Entry point. A web app, a Teams bot or an API receives the user's request.
2. Kernel. Configured with a chat model connector, plugins and filters.
3. Plugins. Wrap internal APIs, databases and search, each with least-privilege credentials.
4. Retrieval. A vector store connector or search plugin supplies grounded context.
5. Filters. Redact sensitive data, check policy, log calls and require approval for risky actions.
6. Observability. Telemetry for latency, tool calls, errors and cost.
7. Evaluation. A test set of real questions run on every change.

The surrounding platform decisions are covered in how FDEs build enterprise AI platforms, and customer data typically arrives through pipelines such as those in Azure Databricks setups.

Semantic Kernel vs Copilot Studio vs Agent Framework

Our agent concepts guide, AI agent orchestration for forward deployed engineers, applies to all three. Microsoft's own migration material for Agent Framework describes agents built around a model client, instructions and tools, typed graph-based workflows with human-input pauses and checkpointing, and middleware for cross-cutting concerns such as logging, security and error handling.

Planning a Migration

If a customer already runs Semantic Kernel:

1. Inventory what exists. Plugins, prompts, filters, vector stores, model connectors.
2. Read the official migration guide and note unsupported features. Microsoft's AutoGen guide, for instance, lists items still planned.
3. Keep tests as the safety net. Run the same questions before and after to compare behaviour.
4. Migrate in slices. Move one agent or flow at a time.
5. Map filters to middleware. Preserve every control that auditors rely on.
6. Agree timing with the customer. There is rarely a reason to rush a working system, but new development should avoid deepening the old dependency.

A Worked Scenario: A Procurement Assistant

This is a hypothetical example to show the approach; the company and details are invented.

A manufacturer's internal tools team built a .NET procurement assistant on Semantic Kernel. It answers questions about purchase orders and suppliers and can raise a purchase requisition.

Review. The FDE finds a clean set of plugins but vague descriptions, so the model sometimes picks the wrong one. The write-action plugin has no approval step.

Fixes. The FDE rewrites descriptions to say what each function does and does not do, splits a large plugin into narrow ones and adds a function invocation filter that requires user confirmation before any requisition is created. A prompt render filter removes bank details from supplier records before the model sees them.

Evaluation. The team builds a set of real procurement questions with expected tool calls, and runs it on every change.

Roadmap. Because Microsoft names Agent Framework as the successor, the FDE proposes migrating one low-risk flow first, keeping the test set to compare behaviour, and leaving the rest until value is proven.

Common Mistakes

• Treating the SDK as the architecture. Decide the use case, data access and controls first.
• Vague plugin descriptions. The model cannot choose well from unclear tools.
• Giving plugins broad credentials. Use least privilege per tool.
• No approval on write actions. Require confirmation for anything consequential.
• Ignoring the roadmap. Check Microsoft's current guidance before starting a long project.
• Skipping evaluation. Without tests, migrations and prompt changes are guesses.
• Underestimating change management. See FDE tech stack for the broader toolkit, and involve the customer's engineers early.

Skills to Build

C# or Python, API design, prompt and tool-description writing, retrieval basics, identity and secrets, evaluation and clear communication with customer engineers.

TL;DR: Semantic Kernel is Microsoft's open-source SDK for building AI applications and agents in C#, Python or Java. It connects models, turns your existing code into plugins the model can call, and exposes filters for logging, validation and approvals. Microsoft now calls Microsoft Agent Framework the successor for new agent work, so FDEs should learn Semantic Kernel's concepts (customers still run it) while planning new builds and migrations on Agent Framework.

‍