Semantic Kernel to Microsoft Agent Framework: Production Patterns and Migration Guide

Consultancy Valorem Reply recently published a list of eight "production examples" of Semantic Kernel. The list is useful, but the label is generous. Two of the eight are backed by named customer stories that Microsoft published. The other six come from an official Azure Samples repository, which presents them as demonstrations, not documented customer deployments. This article keeps that line visible, because "a sample exists" and "a company runs it at scale" are different kinds of evidence.

The Quick Primer: What Semantic Kernel Actually Is​

Microsoft describes Semantic Kernel as a lightweight, open-source development kit for building AI agents and adding AI models to C#, Python and Java codebases. The core idea is simple:

• Plugins wrap your existing code, such as a function, an API or an OpenAPI spec, so a model can ask for it to be called.
• Function calling handles the round trip. The model asks for a function, Semantic Kernel turns that request into a real call in your application, and the result goes back to the model.
• Connectors let you change model providers without rewriting the app.

On GitHub, Microsoft still pitches it as a model-agnostic SDK that empowers developers to build, orchestrate, and deploy AI agents and multi-agent systems. In practice, it's middleware that stands between a model that sounds confident and a business system that does real things.

Section summary: Semantic Kernel is an orchestration layer for connecting models to code. Most of the patterns below are about control, not about the model.

The Two Customer-Backed Deployments​

1. Multi-agent sales proposals at Fujitsu​

This is the strongest example on the list. In a Microsoft customer story, Fujitsu describes an AI agent that automates sales proposals. At its core is Fujitsu Kozuchi Composite AI, which runs on Semantic Kernel and coordinates several specialized agents under an orchestrator agent. Those agents pull knowledge from scattered internal sources and combine it.

Hirotaka Ito, Fujitsu's lead AI engineer on the project, said conventional generative AI, conversational AI and RAG "alone didn't meet our needs." The Valorem piece leaves out the numbers, but Microsoft's story includes them: proposal creation became 67% more productive, and Fujitsu's AI tools, including this agent, reach about 38,000 users.

One caveat: the same story gives Azure AI Agent Service and Azure AI Search as much credit as Semantic Kernel. The 67% figure belongs to the whole stack, not to the SDK alone.

2. Enterprise chatbots at Suntory Global Spirits​

In a November 2024 case study on Microsoft's developer blog, Urko Benito of Suntory describes building chatbots that connect to systems like SAP and Salesforce and work in multiple languages. The lessons are practical:

• Plugins with semantic descriptions let the kernel work out what it could do. The team used a "directional planning" approach instead of fixed step-by-step workflows.
• Verification layers checked outputs against hallucinations. Depending on the case, they used parallel calls to compare results, a coherence-check plugin, or metadata analysis.
• Simpler functions worked better. Overloaded methods that did several jobs confused the planner. Cutting each function down to a single parameter with relevant context fixed it.

According to Suntory's own statistics, an ERP order-status bot turned a process that used to take a day into 18 seconds. Use grew from 10 test users to more than 500 employees. Benito also says the team can now deploy chatbots "in just a few hours." That's Suntory's own claim in a Microsoft-hosted post, not an independent benchmark, so read it that way.

Section summary: Both customer stories are real, and both are marketing-adjacent. The engineering details are the most useful part: tight plugin contracts, verification and a gradual rollout.

The Six Reference Patterns From Azure Samples​

The rest of the list comes from the Azure-Samples "semantic-kernel-advanced-usage" repository. Its README warns that examples are being updated for newer Semantic Kernel versions that introduced breaking changes. Check each sample's requirements.txt before assuming a version.

A few of these need a closer look.

Natural language to SQL: the state machine matters​

Valorem argues that a state machine is what separates "a demo that answers questions" from "a system that refuses to answer the wrong ones." That's the right design instinct. But the refusal behavior comes from the validation steps you build into the state machine, not from the architecture itself. If there's no step that checks the generated SQL against an allow-list or a read-only role, you still have a demo, just a better-organized one.

Filtered retrieval: learn the filter modes​

This is where Azure AI Search's documentation adds real value. Filters apply to filterable non-vector fields, such as category, region or created-by. You can't filter on the vector fields themselves. There are three filter modes:

• preFilter is the recommended default. It applies the filter while the search walks the index graph, and it guarantees k results if that many matches exist. The cost is more CPU and latency when the filter matches very few documents.
• postFilter filters each shard's results after the search. It's faster, but it can miss matches when the filter is selective or k is small.
• strictPostFilter is in preview. It filters only the global top-k, so it can return zero results even when matches exist. Microsoft warns against using it where missing results would have serious consequences.

There's also a legacy catch: preFilter is the default only for indexes created after about October 15, 2023. Older indexes default to postFilter and must be recreated to use preFilter. And a security filter on a user or group string is a filtering pattern, not authentication. Enforce entitlements in your identity layer, then use filters to narrow what the search returns.

Authentication context: keep identity in application code​

Sample 7 carries information like "this user is authenticated" through a conversation without showing it to the model as ordinary chat text. That's the right idea. The broader principle, from general industry practice rather than the sample: authorization decisions belong in application code and your identity provider, such as Entra ID. They shouldn't live in anything the model can read, paraphrase or be tricked into changing.

Per-task routing: service, not just model​

The Fujitsu material supports a narrower claim than the Valorem framing. A November 2024 Microsoft post on the Kozuchi AI Agent says Semantic Kernel lets the agent choose the best AI service for each task. That menu includes Fujitsu's Takane language model, Fujitsu AutoML and a conversational optimization tool. It isn't just a set of chatbots. That earlier agent was built for profitability discussions and negotiations, a different product from the proposal agent. Valorem calls model routing "a cost and continuity control." That's plausible, but no cited source measures it.

Section summary: Treat the six samples as reference designs. Their security properties depend entirely on your implementation, and the documentation for the underlying services often matters more than the sample.

What Ties the Eight Together​

Valorem's best observation holds up. None of these is a general-purpose assistant. Each one is scoped to a defined workflow, a known data boundary and a clear owner. Plugins, state machines, filters and hidden context are all ways to limit what an agent is allowed to do.

That fits McKinsey's November 2025 State of AI survey. It found 62% of respondents' organizations at least experimenting with AI agents. Only 23% reported scaling an agentic system anywhere in the enterprise, and no more than 10% reported scaling agents in any single business function. The last figure is per function, not overall. It doesn't mean only 10% of companies have scaled agents at all.

Is the missing boundary really the thing holding back most pilots? That's Valorem's interpretation, not McKinsey's finding. It's a reasonable hypothesis, but it isn't proven.

Should You Still Build on Semantic Kernel?​

Microsoft's own wording is pretty direct here. The Agent Framework 1.0 announcement tells Semantic Kernel and AutoGen users that "now is the time to migrate." Agent Framework is described as combining Semantic Kernel's enterprise foundations with AutoGen's orchestration patterns. Here's a sensible way to decide:

1. New project, no existing code: start on Agent Framework. Its 1.0 release covers stable agents, middleware hooks, pluggable memory, graph-based workflows with checkpointing, and multi-agent patterns with human-in-the-loop approvals.
2. Existing Semantic Kernel system in production: migrate in stages, not all at once. Microsoft's migration guide says existing Semantic Kernel code with KernelFunction instances (either from prompts or from methods), you can convert them to Agent Framework tools using the .as_agent_framework_tool method. The guide adds that this feature requires semantic-kernel version 1.38 or higher.
3. A pilot that hasn't proven its value: settle the value question first. Porting a pilot that was never going to ship just gives you two problems instead of one.

Expect structural changes along the way. In Semantic Kernel, every agent depends on a Kernel instance and has an empty Kernel if not provided. In .NET, Agent Framework namespaces are under Microsoft.Agents.AI. On the Python side, it has a core package agent-framework-core that contains the core functionality, and then there are multiple packages that rely on that core package, such as agent-framework-openai, agent-framework-foundry, agent-framework-mem0, agent-framework-copilotstudio.

A practical migration checklist​

• Inventory every plugin function. Each one is either a direct port or a candidate for the compatibility bridge.
• Keep tool contracts stable. Function names, argument schemas and error behavior should stay the same while only the registration layer changes. One community migration guide sums it up well: plugins should move as stable tool boundaries, not as copied implementation folders.
• Check server-side threads. One developer's .NET walkthrough warns that if you use OpenAIAssistantAgent or AzureAIAgent, Agent Framework has no thread.DeleteAsync(); you clean up via the provider SDK.
• Re-test your filters and verification steps. Those are the controls that got your workload into production. They shouldn't get lost in the move.

The Bottom Line​

Valorem Reply's list is a helpful map, and its main point holds: the rules and limits around an agent matter more than which SDK you pick. The "production" label only fully applies to Fujitsu and Suntory, though. The other six entries are well-built reference samples that come with conditions.

For Windows and Azure development teams, the path is fairly clear. Study these patterns, build new work on Agent Framework, and migrate existing Semantic Kernel systems in stages, one tool contract at a time. The framework can be swapped out. Your data boundaries and access controls are the part you'll carry forward.