DIE AGENTINNICOLENDERS.COM
DEEN
← Depeschen

EinordnungDIE AGENTENFÜHRERINDIE TECHNIKERIN

Semantic Kernel und AutoGen sind jetzt eins

Veröffentlicht

Zwei unterschiedlich gefertigte Metallwellen sind in der Mitte zu einer einzigen durchgehenden Welle verbunden.KI-generiert
microsoft/agent-frameworkGitHub

Es gab eine Zeit, in der man sich bei Microsoft zwischen zwei Agent-Bibliotheken entscheiden musste, ohne dass jemand die Frage sauber beantworten konnte. Semantic Kernel war das Enterprise-Fundament, AutoGen die Spielwiese für Multi-Agent-Muster. Wer beides wollte, klebte.

Das ist vorbei. Das Microsoft Agent Framework führt beide zusammen, ist quelloffen und stabil für Python und .NET.

Was zusammengeführt wurde

Das Framework nimmt die Enterprise-Grundlagen von Semantic Kernel und die Multi-Agent-Orchestrierung von AutoGen und macht daraus ein SDK. Man muss sich nicht mehr entscheiden.

Für .NET-Leute ist das die relevantere Nachricht, als es klingt. Semantic Kernel war in .NET immer der ausgereiftere Weg, AutoGen war stark python-lastig. Die Multi-Agent-Muster, die in Python-Demos beeindruckten, waren in C# entweder nicht da oder nachgebaut. Diese Asymmetrie ist weg.

Seit Build 2026 sind stabil:

  • Der Agent Harness mit Skills, Memory und Middleware. Derselbe Skill-Begriff wie in Copilot Studio, dasselbe Markdown-Format.
  • Integrationen mit dem GitHub Copilot SDK und dem Claude Agent SDK. Ein Microsoft-Framework, das fremde Agent-SDKs als gleichrangig behandelt, war vor zwei Jahren nicht absehbar.
  • Multi-Agent-Orchestrierungsmuster einschließlich Magentic-One.

In Public Preview stehen File-System-Tools, Memory-Tools und ein Deep-Research-Agent.

Middleware ist der Teil, über den zu wenig geredet wird

Von den drei genannten Bausteinen ist Middleware der, den ich in Projekten am häufigsten brauche und in Vorträgen am seltensten sehe.

Middleware sitzt zwischen Agent und Modell beziehungsweise zwischen Agent und Tool. Genau dort gehört alles hin, was in Demos fehlt und in Produktion zwingend ist: Protokollierung dessen, was tatsächlich rausgegangen ist. Redaktion personenbezogener Daten vor dem Verlassen der Systemgrenze. Aufrufbegrenzung. Nachvollziehbarkeit von Modellversion und Prompt-Stand pro Aufruf.

Wer das nicht als Querschnittsschicht baut, baut es später in jeden Aufruf einzeln ein. Ich habe das mehr als einmal gesehen, und es ist jedes Mal teurer als die Version, in der man vorher zehn Minuten nachgedacht hat.

Nebenbei ist das auch die Antwort auf einen Teil der Nachweisführung, die der EU AI Act verlangt. Zeitstempel, Modell und Version, Prompt-Vorlage samt Version, Parameter, aufrufendes System: das entsteht in der Middleware als Nebenprodukt oder gar nicht.

Memory, mit einer Zahl dazu

Der Foundry Agent Service kennt drei Arten von Memory in Public Preview:

  • Session Memory hält Kontext innerhalb eines Gesprächsfadens.
  • User Memory merkt sich Vorlieben und Fakten über Sitzungen hinweg.
  • Procedural Memory ist der neue Teil und der interessante: Agents lernen, wie eine Arbeit gemacht wird, nicht nur, was gesagt wurde.

Microsoft nennt für Procedural Memory frühe Tau-bench-Ergebnisse von 7 bis 14 Prozentpunkten besserer Erfolgsrate bei annähernd gleichen Kosten. Das Beispiel im Microsoft-Blog: Ein PR-Review-Agent wird einmal angewiesen, zuerst die Testabdeckung zu prüfen, dann neue Dependencies zu markieren, dann nach Breaking Changes zu suchen. Wochen später bei einem anderen PR macht er dieselben drei Prüfungen in derselben Reihenfolge, ohne erneute Anweisung.

Ich finde die Idee überzeugend und die Zahl mit Vorsicht zu genießen. Tau-bench ist ein Benchmark, kein Kundenprojekt, und Angaben des Herstellers zum eigenen Feature sind kein unabhängiger Nachweis. Die Richtung ist trotzdem die richtige: Ein Agent, der die einmal erklärte Arbeitsweise behält, löst genau das Problem, an dem Instruktionen in der Praxis scheitern.

Und die Kehrseite gehört dazu: Persistentes Memory pro Nutzer ist ein Datenthema. Bevor du es einschaltest, solltest du beantworten können, was gespeichert wird, wie lange, und was bei einer Löschanfrage passiert.

Der Entwicklungsweg

Das Foundry Toolkit für VS Code ist GA. Agents aus Vorlagen oder mit GitHub Copilot erstellen, lokal ausführen und debuggen mit Trace-Visualisierung, Schritt für Schritt inspizieren, an Toolboxes anbinden und direkt in den Foundry Agent Service deployen, alles im Editor.

Das ist der Punkt, an dem sich Agent-Entwicklung endlich wie Softwareentwicklung anfühlt statt wie Konfiguration in einem Portal. Lokal debuggen zu können ist keine Bequemlichkeit, es ist die Voraussetzung dafür, dass jemand ein Problem versteht statt es wegzuraten.

Für den Betrieb kommt die andere Hälfte dazu: Tracing und Evaluation für hosted agents über eine OpenTelemetry-Pipeline, in der jeder Modellaufruf, jede Tool-Invocation und jeder Sub-Agent-Hop landet. Evaluationen verweisen zurück auf den Trace, der sie ausgelöst hat.

Wann ich Code nehme und wann nicht

Meine Linie ist einfach und hat nichts mit Vorlieben zu tun.

Code, wenn der Agent Teil eines Produkts ist, an eine bestehende Codebasis grenzt, eigene Orchestrierungsmuster braucht oder wenn Nachvollziehbarkeit auf Aufrufebene eine Anforderung ist und nicht ein Wunsch.

Low Code, wenn der Prozess einem Fachbereich gehört und sich häufig ändert. Ein C#-Projekt, das nur die IT ändern kann, ist für einen Prozess, der monatlich angepasst wird, die teurere Lösung, auch wenn es technisch die sauberere ist.

Und die unbequeme dritte Option: gar kein Agent. Wenn ein Vorgang jedes Mal identisch abläuft, braucht er keine Runtime, die jedes Mal neu darüber nachdenkt.

Warum hier kein Codebeispiel steht

Ich hätte gern eines eingebaut. Ich lasse es bewusst weg.

API-Signaturen im Agent Framework bewegen sich zwischen Paketversionen, und ein Beispiel, das jemand kopiert und das nicht kompiliert, ist schlimmer als keins. Ein Text mit Datumsstempel altert schlechter als Dokumentation, die gepflegt wird. Wer einsteigen will, fängt beim Repository und der Quickstart-Dokumentation an, prüft die aktuelle Paketversion und schreibt den ersten Agent lokal im Foundry Toolkit.

Wenn du magst, mache ich daraus später ein eigenes Nachschlagewerk mit geprüftem Stand. Ein Nachschlagewerk kann ich pflegen, eine Einordnung nicht.

Quellen

Microsoft Foundry · Development