Microsoft Agent Framework: Workflow-Graphen für .NET und Python

Microsoft entwickelt mit dem Agent Framework ein Open-Source-System für Agenten und graphbasierte Workflows. Das Repository dokumentiert SDKs für .NET und Python sowie gemeinsame Konzepte für Orchestrierung, Zustände und kontrollierte Eingriffe.

Der interessante Teil ist der Workflow-Graph. Er macht Übergaben und Wiederanlaufpunkte zu sichtbaren Bestandteilen der Architektur, statt sie über lose verkettete Prompts und Tool-Aufrufe zu verteilen.

Ein Graph für den Ablauf

Ein Support-Prozess zeigt den Unterschied. Ein Knoten liest ein Ticket ein, ein weiterer ordnet das Anliegen ein, danach folgt die Suche in einer Wissensbasis. Unsichere Fälle können an einen Menschen gehen, während der Workflow den erreichten Zustand behält.

Das ist der Kern.

Laut Microsoft-Repository verbindet das Framework Agenten und deterministische Funktionen über gerichtete Datenflüsse. Streaming kann Zwischenergebnisse früh weiterreichen; Checkpoints schaffen definierte Stellen, an denen ein abgebrochener oder korrigierter Lauf wieder aufgenommen werden kann.

Damit wird ein mehrstufiger Agentenprozess leichter überprüfbar. Plattformteams sehen, welcher Schritt einen Zustand verändert, wo eine Freigabe vorgesehen ist und an welcher Stelle ein Fehler erneut ausgeführt werden darf.

.NET und Python ohne falschen Gegensatz

Microsoft stellt das Framework für .NET und Python bereit. Das ist vor allem für Organisationen relevant, in denen beide Sprachen bereits eingesetzt werden und neue Agentenprojekte nach ähnlichen Architekturmustern entstehen sollen.

Semantic Kernel und AutoGen taugen dabei nicht als einfache Gegenfolie aus „.NET gegen Python“. Beide Projekte haben eine breitere Sprach- und Entwicklungsgeschichte. Der belastbare Vorteil des Agent Framework ist daher das gemeinsame Produktmodell, das Microsoft für neue Agenten- und Workflow-Projekte anbietet.

Eine wichtige Grenze bleibt: Zwei SDK-Sprachen bedeuten nicht automatisch, dass beliebige .NET- und Python-Komponenten ohne Integrationsarbeit in demselben Prozess laufen. Vor einer Architekturentscheidung sollte geprüft werden, welche Funktionen in beiden SDKs tatsächlich verfügbar sind und wie sprachübergreifende Übergaben umgesetzt werden.

Migration ist kein automatischer Umbau

Das Microsoft-Repository verweist auf Migrationshilfen für bestehende Projekte aus Semantic Kernel und AutoGen. Solche Leitfäden können Begriffe, Kontrollflüsse und Integrationen einander zuordnen. Sie ersetzen jedoch keine Prüfung der vorhandenen Architektur.

Besonders wichtig sind dabei Zustandsübergänge und Fehlerpfade. Ein bisher linearer Agent lässt sich meist einfacher übertragen als ein System, das eigene Speicherlogik, manuelle Freigaben und mehrere Werkzeugketten miteinander verbindet.

Migration bleibt Architekturarbeit.

Wann sich der Workflow-Graph lohnt

Nicht jeder Ablauf braucht einen Graphen. Für einen einzelnen Agenten mit zwei linearen Tool-Aufrufen erzeugt die zusätzliche Orchestrierung womöglich mehr Struktur als Nutzen.

Ich halte das Framework dort für überzeugend, wo ein Prozess verzweigt, nach einem Fehler kontrolliert fortgesetzt werden muss oder vor einer riskanten Aktion eine menschliche Freigabe verlangt. An diesen Stellen liefern sichtbare Knoten und Checkpoints einen konkreten betrieblichen Vorteil.

Vor der Einführung sollten Entwicklungsteams deshalb einen realen Ablauf modellieren und drei Fragen beantworten: Ist nach jedem kritischen Schritt der Zustand erkennbar? Kann der Prozess an einer definierten Stelle wieder anlaufen? Bleibt nachvollziehbar, welcher Agent oder welche Funktion eine Aktion ausgelöst hat?

Wenn der Graph darauf klare Antworten liefert, ist er Architektur und nicht bloß Diagramm.