Microsoft Semantic Kernel for .NET/Java Enterprise Stacks

Semantic Kernel is an open-source SDK from Microsoft that integrates Large Language Models into .NET, Python and Java applications via plugins, functions, planner, memory and connectors. It serves as an orchestration and foundation layer for enterprise AI and, since 2026, forms the basis of the Microsoft Agent Framework. For organisations with an existing Microsoft, Azure and .NET stack, it is the most natural entry point into agentic workloads.

• What it is: a model-agnostic enterprise SDK for LLM orchestration, primarily for C#/.NET, alongside Python and Java.
• Core building blocks: plugins/functions (tool calling), planner (step decomposition), memory (context/state) and connectors (models, vector stores, services).
• Strategic status in 2026: Semantic Kernel and AutoGen converge in the Microsoft Agent Framework 1.0 (GA since 3 April 2026, MIT licence); SK remains the foundation layer, while AutoGen moves into maintenance mode.

The four core building blocks of Semantic Kernel

Semantic Kernel structures AI integration around four abstractions, each of which can be mapped individually into enterprise code.

Plugins and functions. A plugin bundles functions that the kernel can call. There are two kinds: native functions are ordinary C#, Python or Java code (such as a database access or a REST call), while semantic functions are parameterised prompts. Both are offered to the model as callable tools. This corresponds to the tool/function-calling layer with error handling that defines an agent framework.

Planner. The planner decomposes a goal into a sequence of function calls. Instead of hard-wiring a workflow, you describe the available plugins, and the model assembles the execution plan dynamically. This is the bridge from a static workflow to a dynamically controlled agent. In the converged Microsoft Agent Framework, this logic is carried over into the concept of graph-based workflows and stateful agents.

Memory. Memory maintains context across multiple steps. SK abstracts both short-term context and persistent stores via embeddings and vector stores (for RAG scenarios). This makes state management possible across multiple calls without manually threading the store through the call chain.

Connectors. Connectors decouple the code from specific models and services. In the Microsoft Agent Framework, six providers can be swapped with a 1-line swap: Azure OpenAI, OpenAI, Anthropic, Amazon Bedrock, Google Gemini and Ollama (as of 2026). This noticeably reduces model lock-in — a key selection criterion for regulated industries.

Focus on .NET/Java: why enterprise stacks benefit

The essential difference from Python-centric frameworks such as CrewAI (Python-only) or Pydantic AI (Python-only) is the first-class .NET support. Anyone running an existing ASP.NET, Azure Functions or Service Fabric landscape can integrate AI agents within the same language and deployment stack — without a language switch and without a separate Python service.

This is relevant on the staffing side: the .NET talent pool in the DACH region is large, and contractor availability for the Microsoft Agent Framework is rated as very high in the research. Java is also supported by Semantic Kernel; in the newer Microsoft Agent Framework the focus is on .NET (C#) and Python, with Java in beta according to the roadmap as of 2026. Pure Java shops should therefore verify the current language support before starting a project.

In addition, there are enterprise characteristics that, in practice, determine production readiness:

• Native MCP support (Model Context Protocol) for standardised tool access, integrated for example via a configuration such as .WithMcpServer(...).
• Native A2A support (agent-to-agent, v1.0 GA since 9 April 2026), including Signed Agent Cards for agent-to-agent communication.
• Observability via Application Insights, OpenTelemetry and Foundry Monitoring — important for audit and traceability obligations.
• Sandbox code execution via CodeAct/Hyperlight (alpha status as of 2026).
• Azure EU hosting in Frankfurt, West Europe, Switzerland North and Sweden Central, plus the Microsoft EU Data Boundary.

Relationship to AutoGen: the announced convergence

Until 2025, Microsoft had two parallel strands: Semantic Kernel as a production-oriented SDK and AutoGen as a research/multi-agent framework. With the Microsoft Agent Framework, the two are being brought together.

The strategic shift is concrete. The Microsoft Agent Framework entered public preview on 1 October 2025 and reached general availability on 3 April 2026 — under an MIT licence and with an explicit LTS commitment. Before the merger, Semantic Kernel and AutoGen together had over 75,000 GitHub stars. The new framework cleanly separates agents (stateful execution units) from workflows (graph-based orchestration) and integrates AutoGen's multi-agent concepts into a graph workflow engine.

Crucial for existing customers: Semantic Kernel is not deprecated. Microsoft recommends a lazy migration — SK remains the foundation layer, and existing solutions continue to run. AutoGen, by contrast, moves into maintenance mode; new multi-agent projects should no longer be started there (as of 2026).

Comparison of migration paths

When the Microsoft Agent Framework is a fit for enterprise teams — and when it is not

Well suited if at least one of these points applies:

• .NET/C# is mandatory or the dominant stack.
• There is an Azure landscape with a requirement for EU data residency.
• The team is an existing Semantic Kernel or AutoGen customer.
• Regulated EU workloads with a need for logging, traceability and human oversight (relevant in the context of the EU AI Act; the Digital Omnibus compromise of 7 May 2026 to postpone the high-risk obligations has not yet been formally adopted as of 2026).

Less suitable if:

• The team works in a purely Python-based way and time-to-demo matters — in that case, CrewAI (fastest prototype) or Pydantic AI are often more direct.
• Strict vendor sovereignty without a US provider is required — here, the US vendor dependency and the CLOUD Act debate remain an open issue, despite the Azure EU regions.
• Maximum maturity is needed immediately: the GA is still young at 3 April 2026, and individual packages (such as agent_framework.orchestrations) remained in preview status for longer. Maturity claims should be verified.

Concrete example: a quotation assistant in the .NET stack

A mid-sized B2B mechanical engineering company (Vienna) wants to relieve its sales staff in preparing quotations. The existing stack: ASP.NET Core, SQL Server, Azure West Europe.

Setup with the Microsoft Agent Framework on a Semantic Kernel basis:

1. Plugin ProductCatalog (native function) reads prices and availability from SQL Server.
2. Plugin PricingRules (semantic function) applies discount logic as a parameterised prompt.
3. MCP server connects the CRM for customer history (.WithMcpServer(...)).
4. Agent orchestrates: understand the request, query the catalogue, calculate the price, generate the quotation text.
5. Connector points to Azure OpenAI in West Europe (EU data residency).

Pseudocode sketch:

```csharp
var agent = new AgentBuilder()
.WithAzureOpenAI("gpt-deployment", endpoint, key) // EU region
.WithPlugin<ProductCatalog>()
.WithPlugin<PricingRules>()
.WithMcpServer("crm-connector")
.Build();

var result = await agent.RunAsync(
"Create a quotation for customer 4711, 50 units of Type B");
```

Assumed outcome: instead of around 25 minutes of manual research and text creation per quotation, the assistant delivers a draft in under 60 seconds, which the salesperson only has to review (human-in-the-loop). At 40 quotations per week, this corresponds to a saving in the region of around 16 hours per week — the specific figures must be validated in each individual operation. Application Insights logs every step for the audit obligation.

For agencies and B2B decision-makers

For agencies, the Microsoft Agent Framework is the lever with clients that have a grown Microsoft landscape: they deliver AI agents within the existing .NET/Azure stack without setting up a parallel Python operation, and they can argue EU data residency cleanly to data protection and compliance via Azure EU regions. For B2B decision-makers, the convergence of Semantic Kernel and AutoGen is a signal of stability — a GA product with an LTS commitment instead of two parallel projects. Blck Alpaca supports DACH companies with framework selection, sovereignty assessment and the migration of existing Semantic Kernel solutions. Our recommendation: define the use case first, then choose the framework — never the other way round.