Vier Bausteine des Frameworks

Das Microsoft Agent Framework bringt vier Bausteine zusammen: Agents, die Tools und MCP Server aufrufen und mehrere Model Provider unterstützen, den Harness Agent mit Planning, Context Compaction, File Access und Tool Approval, Workflows als funktionale und graph-basierte Ausführungspfade, und Integrations zu Model Providern, Tools und UI Frameworks.

Fünf Orchestration Patterns

Das Microsoft Agent Framework bringt fünf Orchestration Patterns mit: Sequential, wo Agents nacheinander laufen, Concurrent, wo sie parallel arbeiten, Handoff, wo sie die Kontrolle je nach Kontext übergeben, Group Chat, wo sie sich in einer gemeinsamen Konversation abstimmen, und Magentic, wo ein Manager Agent spezialisierte Agents dynamisch koordiniert.

State und Human-in-the-Loop

Workflows checkpointen ihren Fortschritt an Superstep-Grenzen und unterstützen Fan-out- und Fan-in-Ausführung, über beide Workflow APIs hinweg, funktional und graph-basiert. Human-in-the-Loop läuft über Tool Approval und Request Info: Agents nutzen freigabepflichtige Tools, die den Workflow anhalten, bis ein Mensch sie vor der Ausführung prüft.
Fortschritt bleibt
ein Run läuft nach einer Pause genau dort weiter, wo er stand
Kosten live sichtbar
jede Pipeline Stage zeigt ihre Kosten, live während der Run noch läuft
API reicht schon
die REST API, die Sie heute schon einsetzen, wird zum Tool, das der Agent aufruft

Enterprise Multi-Agent System

Vier Bausteine des Frameworks 2 Schritte
01

Agents, Harness und Workflows

Agents rufen Tools und MCP Server auf und unterstützen mehrere Model Provider. Der Harness Agent bringt Planning, Todo Tracking, Context Compaction, File Access und Memory sowie Tool Approval mit. Workflows verbinden beide über funktionale und graph-basierte Ausführungspfade.
02

Model Clients, Sessions und Middleware

Model Clients für Chat Completions und Responses, eine Agent Session für State Management und Context Provider für Agent Memory ergänzen die vier Bausteine, verfügbar für .NET, Python und, in Preview, Go. Middleware fängt Agent-Aktionen ab, und MCP Clients binden Tools direkt an.
Fünf Orchestration Patterns 2 Schritte
03

Sequential, Concurrent und Handoff

Bei Sequential laufen Agents in fester Reihenfolge nacheinander. Bei Concurrent arbeiten sie parallel am selben Task. Bei Handoff übergeben sie die Kontrolle je nach Kontext an den nächsten Agent, ohne dass ein zentraler Manager jeden Schritt steuert.
04

Group Chat und Magentic

Bei Group Chat stimmen sich Agents in einer gemeinsamen Konversation ab. Bei Magentic koordiniert ein Manager Agent spezialisierte Agents dynamisch, statt einem festen Ablauf zu folgen. Beide Patterns unterstützen Human-in-the-Loop über Tool Approval.
State und Human-in-the-Loop 2 Schritte
05

Checkpoints an Superstep-Grenzen

Der graph-basierte Workflow Builder verbindet typisierte Executors über Edges und Conditions, unterstützt Fan-out- und Fan-in-Ausführung und checkpointet den Fortschritt an jeder Superstep-Grenze. Workflow- und Executor-Events machen jeden Schritt beobachtbar.
06

Freigabe über Tool Approval

Agents nutzen freigabepflichtige Tools, die den Workflow anhalten, bis ein Mensch sie vor der Ausführung prüft. Request Info holt zusätzlichen menschlichen Input mitten im Run, über RequestInfoExecutor im graph-basierten Workflow oder ctx.request_info() im funktionalen.

Häufige Fragen

Was ist ein Agentic Business Process?
Ein Prozess, in dem der Agent liest, zuordnet und entwirft, und ein Mensch die Freigabe verantwortet. Ein ausgeliefertes Beispiel nimmt die monatliche Excel-Arbeitsliste, die das Büro ohnehin erstellt, ordnet die Gebäude zu und schlägt einen ganzen Monat an Technikerrouten vor, nach Standort gruppiert, mit echten Fahrzeiten aus Google Maps. Kein einziger Datensatz wird gespeichert, bevor jemand den Vorschlag geprüft hat, und jeder Run legt einen History-Eintrag an, der das Ergebnis später erklärt.
Was macht einen Agentic Process betriebsfähig statt zu einer Demo?
Ein Agentic Process in Production braucht drei Dinge, die eine Demo meist auslässt: ein gemeinsames Ledger, das den State hält, wenn ein Run länger dauert als eine Session; eine Kostenerfassung pro Stage, damit die Ausgaben zurechenbar bleiben; und einen aufgeschriebenen Failure Mode für jedes Plattformverhalten, das der eigenen Dokumentation widerspricht. Das Ledger liefert Microsoft Agent Framework 1.0. Microsoft Foundry Hosted Agents liefern Isolation pro Session und Scale-to-Zero, damit lange Runs keine Infrastruktur warm halten. Das Agent Harness bringt automatische Context Compaction und OpenTelemetry Tracing nach Application Insights mit, damit der Fehlerpfad, der beim dritten Run auftaucht, beim vierten nicht wiederkommt.
Wie kommen Agents an Unternehmensdaten, ohne das System neu zu bauen?
Über Model Context Protocol auf der API, die es ohnehin schon gibt. Eine Planungsplattform stellt sieben Schedule Tools auf ihrer laufenden Datenbank bereit, mit Tool-Beschreibungen im deutschen Vokabular des Büros, sodass unscharfe Mitarbeiter- und Gebäudenamen richtig aufgelöst werden, als Custom Connector an Claude angebunden. Mitarbeiter fragen, wer an einem bestimmten Tag einen Termin hat, statt den Planer zu öffnen. Der Connector läuft gegen den Staging Slot, bevor er auf Production zeigt.
Was hindert einen Agent daran, etwas Falsches in ein System of Record zu schreiben?
Das Modell bekommt den Schreibpfad nicht. Im ausgelieferten Pattern erzeugt es einen Entwurf und gibt ein interaktives Formular zurück, das im Chat Client gerendert wird, und dieses Formular ruft das eine Save Tool dahinter auf. Die Dokumentenannahme funktioniert genauso: Ein extrahierter Datensatz trägt ein Review Flag, und das Quelldokument bleibt im Blob Storage archiviert, bis ein Mensch ihn bestätigt. Die Freigabe ist ein Schritt im System, keine Gewohnheit, um die man Menschen bittet.
Wer entscheidet, welches Modell läuft, und was kostet ein Run?
Ein Administrator, in einer Model Registry mit einem Default pro Use Case und AI Credits pro Benutzer. Die Wirkung ist messbar: Bei einem Feature für Antwortentwürfe machte ein Modellwechsel die Vorschläge rund zehnmal schneller und viermal günstiger, ohne dass am Feature etwas geändert wurde. Auch auf Run-Ebene bleiben die Kosten sichtbar, denn jede Pipeline Stage schreibt eine JSON-Zeile mit ihren Token-Kosten, und derselbe Trace läuft als Live-Anzeige auf den Bildschirm.
Was passiert, wenn sich die Plattform anders verhält, als die Dokumentation sagt?
Sie wird einmal diagnostiziert und festgehalten. Magentic Teams auf Microsoft Foundry scheitern an der Responses API mit einem Manager-Ledger-Fehler; die funktionierende Konfiguration ist der Chat Completions Client. Dieser Befund liegt jetzt im Harness, das mit der Codebase mitreist, neben dem Deployment Run-Book und den Conventions. Die Failure Modes einer Plattform zu kennen ist ein großer Teil dessen, was ein zweites Projekt darauf schneller macht als das erste.