Microsoft Semantic Kernel für .NET/Java-Enterprise-Stacks

Semantic Kernel ist ein Open-Source-SDK von Microsoft, das Large Language Models über Plugins, Functions, Function Calling, Vector Stores und Konnektoren in .NET-, Python- und Java-Anwendungen integriert. Microsoft bezeichnet das Microsoft Agent Framework, das Semantic Kernel und AutoGen zusammenführt, als direkten Nachfolger beider Projekte. Für Unternehmen mit bestehendem Microsoft-, Azure- und .NET-Stack ist das Agent Framework der naheliegendste Einstieg in neue agentische Workloads; bestehende Semantic-Kernel-Lösungen laufen weiter.

• Was es ist: ein modell-agnostisches Enterprise-SDK zur LLM-Orchestrierung, primär für C#/.NET, daneben Python und Java.
• Kernbausteine: Plugins/Functions (aufrufbare Tools), automatisches Function Calling (Schritt-Planung), Vector Stores (Memory, Kontext) und Konnektoren (Modelle, Dienste).
• Strategischer Stand 2026: Semantic Kernel und AutoGen konvergieren im Microsoft Agent Framework 1.0 (GA seit 3. April 2026, MIT-Lizenz); SK 1.x wird weiter gepflegt, neue Funktionen entstehen im Agent Framework, AutoGen geht in den Maintenance-Modus.

Die vier Kernbausteine von Semantic Kernel

Semantic Kernel strukturiert KI-Integration über vier Abstraktionen, die jede für sich in Enterprise-Code abbildbar sind.

Plugins und Functions. Ein Plugin bündelt Funktionen, die der Kernel aufrufen kann. Es gibt zwei Arten: Native Functions sind normaler C#-, Python- oder Java-Code (etwa ein Datenbankzugriff oder ein REST-Call), Prompt Functions sind parametrisierte Prompts (früher Semantic Functions genannt). Beide werden dem Modell als aufrufbare Tools angeboten. Das entspricht dem Tool-/Function-Calling-Layer mit Fehlerbehandlung, der ein Agent-Framework ausmacht.

Planung über Function Calling. Die früheren Planner (Stepwise, Handlebars) hat Microsoft abgekündigt und aus dem Paket entfernt. Heute entscheidet das Modell per automatischem Function Calling selbst, welche Plugin-Funktionen es in welcher Reihenfolge aufruft: Es ruft eine Funktion auf, prüft das Ergebnis und wählt den nächsten Schritt. Statt einen Workflow hart zu verdrahten, beschreibt man die verfügbaren Plugins. Das ist die Brücke vom statischen Workflow zum dynamisch gesteuerten Agenten. Im Microsoft Agent Framework plant der Agent auf dieselbe Weise, graph-basierte Workflows ergänzen das um fest definierte Ausführungspfade.

Vector Stores (Memory). Memory hält Kontext über mehrere Schritte. Den Gesprächsverlauf führt SK als Chat History, persistentes Wissen speichert es als Embeddings in Vektordatenbanken (für RAG-Szenarien). Dafür nutzt SK heute die Vector-Store-Abstraktionen, die die früheren Memory Stores abgelöst haben. Damit ist State-Management über mehrere Aufrufe hinweg möglich, ohne den Speicher manuell durch die Aufrufkette zu reichen.

Konnektoren. Konnektoren entkoppeln den Code von konkreten Modellen und Diensten. Im Microsoft Agent Framework lassen sich sechs Provider per 1-Line-Swap tauschen: Azure OpenAI, OpenAI, Anthropic, Amazon Bedrock, Google Gemini und Ollama (Stand 2026). Das reduziert Modell-Lock-in spürbar, ein zentrales Auswahlkriterium für regulierte Branchen.

Fokus .NET/Java: warum Enterprise-Stacks profitieren

Der wesentliche Unterschied zu Python-zentrischen Frameworks wie CrewAI (Python-only) oder Pydantic AI (Python-only) ist der erstklassige .NET-Support. Wer eine bestehende ASP.NET-, Azure-Functions- oder Service-Fabric-Landschaft betreibt, integriert KI-Agenten im selben Sprach- und Deployment-Stack, ohne Sprachbruch, ohne separaten Python-Service.

Auch beim Personal zählt das: Ein bestehendes .NET-Team arbeitet mit dem Agent Framework in seiner gewohnten Sprache weiter, statt zusätzlich Python-Spezialisten zu brauchen. Java wird von Semantic Kernel ebenfalls unterstützt. Das Microsoft Agent Framework gibt es laut Microsoft Learn dagegen für .NET (C#) und Python, dazu Go als Public Preview; Java führt Microsoft dort nicht auf. Reine Java-Häuser sollten den Sprachsupport daher vor Projektstart prüfen.

Hinzu kommen Enterprise-Eigenschaften, die in der Praxis über Produktionsreife entscheiden:

• Native MCP-Unterstützung (Model Context Protocol) für standardisierten Tool-Zugriff, eingebunden etwa über eine Konfiguration wie .WithMcpServer(...).
• Native A2A-Unterstützung (Agent-to-Agent, Protokoll v1.0) inklusive Signed Agent Cards für Agent-zu-Agent-Kommunikation.
• Observability über Application Insights, OpenTelemetry und Foundry Monitoring, wichtig für Audit- und Traceability-Pflichten.
• Sandbox-Code-Ausführung über CodeAct/Hyperlight (Alpha-Stand 2026).
• Azure-Hosting in Europa in den EU-Regionen Germany West Central (Frankfurt), West Europe und Sweden Central, dazu Switzerland North, plus Microsoft EU Data Boundary (EU und EFTA).

Verhältnis zu AutoGen: die angekündigte Konvergenz

Bis 2025 hatte Microsoft zwei parallele Stränge: Semantic Kernel als Production-orientiertes SDK und AutoGen als Forschungs-/Multi-Agent-Framework. Mit dem Microsoft Agent Framework werden beide zusammengeführt.

Der Strategiewechsel ist konkret. Das Microsoft Agent Framework startete am 1. Oktober 2025 in die Public Preview und erreichte am 3. April 2026 General Availability, und zwar unter MIT-Lizenz und mit explizitem LTS-Commitment. Vor dem Merger hatten Semantic Kernel und AutoGen zusammen über 75.000 GitHub-Stars. Das neue Framework trennt sauber zwischen Agents (stateful Execution Units) und Workflows (graph-basierte Orchestrierung) und integriert AutoGens Multi-Agent-Konzepte in eine Graph-Workflow-Engine.

Entscheidend für Bestandskunden: Semantic Kernel läuft weiter, die Weiterentwicklung liegt aber beim Agent Framework. Microsoft behebt in SK 1.x weiter kritische Fehler und Sicherheitslücken, zugesagt für mindestens ein Jahr nach dem Ende der Preview des Agent Framework, also mindestens bis April 2027. Die meisten neuen Funktionen entstehen im Agent Framework. Bestehende Lösungen laufen weiter und lassen sich schrittweise migrieren; mit der GA rät Microsoft aber ausdrücklich zum Umstieg. AutoGen wechselt hingegen in den Maintenance-Modus; neue Multi-Agent-Projekte sollten dort nicht mehr begonnen werden (Stand 2026).

Vergleich der Migrationspfade

Wann das Microsoft Agent Framework für Enterprise-Teams passt, und wann nicht

Gut geeignet, wenn mindestens einer dieser Punkte zutrifft:

• .NET/C# ist Pflicht oder dominierender Stack.
• Es besteht eine Azure-Landschaft mit Anforderung an EU-Datenresidenz.
• Das Team ist Semantic-Kernel- oder AutoGen-Bestandskunde.
• Regulierte EU-Workloads mit Bedarf an Logging, Traceability und Human Oversight (relevant im Kontext EU AI Act; der Digital Omnibus (Verordnung (EU) 2026/1744) ist seit 27. Juli 2026 in Kraft und verschiebt die Hochrisiko-Pflichten für Anhang-III-Systeme auf den 2. Dezember 2027).

Eher nicht geeignet, wenn:

• Das Team rein Python-basiert arbeitet und Time-to-Demo zählt, dann sind CrewAI (schnellster Prototyp) oder Pydantic AI oft direkter.
• Strikte Vendor-Souveränität ohne US-Anbieter gefordert ist, denn hier bleibt der US-Vendor-Bezug und die CLOUD-Act-Diskussion ein offener Punkt, trotz Azure-EU-Regionen.
• Maximale Reife sofort benötigt wird: Die GA ist mit dem 3. April 2026 noch jung, und einzelne Pakete (etwa agent_framework.orchestrations) blieben länger im Preview-Status. Reifeansprüche sind zu verifizieren.

Konkretes Beispiel: Angebots-Assistent im .NET-Stack

Ein mittelständischer B2B-Maschinenbauer (Wien) will Vertriebsmitarbeitende bei der Angebotserstellung entlasten. Der bestehende Stack: ASP.NET Core, SQL Server, Azure West Europe.

Aufbau mit dem Microsoft Agent Framework (Bausteine in Semantic-Kernel-Begriffen):

1. Plugin ProductCatalog (Native Function) liest Preise und Verfügbarkeiten aus dem SQL Server.
2. Plugin PricingRules (Prompt Function) wendet Rabattlogik als parametrisierten Prompt an.
3. MCP-Server bindet das CRM für Kundenhistorie an (.WithMcpServer(...)).
4. Agent orchestriert: Anfrage verstehen, Katalog abfragen, Preis kalkulieren, Angebotstext erzeugen.
5. Konnektor zeigt auf Azure OpenAI in West Europe (EU-Datenresidenz).

Pseudocode-Skizze:

```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(
"Erstelle ein Angebot für Kunde 4711, 50 Einheiten Typ B");
```

Ergebnis-Annahme: Statt rund 25 Minuten manueller Recherche und Texterstellung pro Angebot liefert der Assistent einen Entwurf in unter 60 Sekunden, den die Vertriebsperson nur noch prüft (Human-in-the-Loop). Bei 40 Angeboten pro Woche entspricht das einer Ersparnis im Bereich von etwa 16 Stunden wöchentlich, die konkreten Zahlen sind im jeweiligen Betrieb zu validieren. Application Insights protokolliert jeden Schritt für die Audit-Pflicht.

Für Agenturen und B2B-Entscheider

Für Agenturen ist das Microsoft Agent Framework der Hebel bei Kunden mit gewachsener Microsoft-Landschaft: Sie liefern KI-Agenten im vorhandenen .NET-/Azure-Stack, ohne einen parallelen Python-Betrieb aufzubauen, und argumentieren EU-Datenresidenz über Azure-EU-Regionen sauber gegenüber Datenschutz und Compliance. Für B2B-Entscheider ist die Konvergenz von Semantic Kernel und AutoGen ein Stabilitätssignal: ein GA-Produkt mit LTS-Commitment statt zweier paralleler Projekte. Blck Alpaca unterstützt DACH-Unternehmen bei Framework-Auswahl, Souveränitäts-Bewertung und der Migration bestehender Semantic-Kernel-Lösungen. Empfehlung: Use-Case zuerst definieren, dann das Framework wählen, nie umgekehrt.