Multi-Agent-Orchestrierung in Microsoft Foundry: Deep Dive

Thema dieser Seite: Multi-Agent-Orchestrierung in Microsoft Foundry: Deep Dive

Ein Agent allein löst selten einen echten Geschäftsprozess. Sobald Sie etwas Ernstes aufbauen, benötigen Sie einen Triage-Agenten, einen Spezialisten für Ihre Wissensdatenbank, vielleicht jemanden, der Tickets erstellt – und etwas, das diese koordiniert. In diesem Blogbeitrag beschäftige ich mich intensiv mit der Multi-Agent-Orchestrierung in Microsoft Foundry. Ich erkläre, wie sich die Geschichte innerhalb eines Jahres dreimal verändert hat, wie die Microsoft Agent Framework-Muster funktionieren und welches Muster ich für welches Szenario wählen würde. Am Ende wissen Sie genau, wo Sie Ihre Orchestrierung heute aufbauen müssen, damit sie nächstes Jahr nicht veraltet ist.

Ich habe bereits über den Aufbau Ihres ersten Agenten in Microsoft Foundry geschrieben. Dieser Beitrag ist der nächste Schritt: die Zusammenarbeit mehrerer Agenten.

Warum hat sich die Multi-Agent-Geschichte dreimal geändert?

Dies ist der Teil, der die meisten Menschen verwirrt. Lassen Sie uns ihn also zunächst klären. Microsoft hat in etwa einem Jahr drei verschiedene Multi-Agent-Mechanismen ausgeliefert:

1. Verbundene Agenten (klassisch). Die ursprüngliche Funktion im klassischen Foundry Agent Service. Ein Hauptagent delegiert über natürliches Sprachrouting an Unteragenten. Dies gibt es nur in der alten 2025-05-15-preview-API und der gesamten klassischen Agentenplattform wird am 31. März 2027 eingestellt.
2. Portal-Workflows (Vorschau). Angekündigt auf der Ignite 2025 – ein visueller Designer im Foundry-Portal für deklarative Agentensequenzen. Es erreichte nie die allgemeine Verfügbarkeit und Microsoft stellt den Workflow-Designer am 1. Dezember 2026 ein.
3. Microsoft Agent Framework. Das Open-Source-SDK, das Semantic Kernel und AutoGen auf einer Plattform zusammenführt. Es erreichte am 2. April 2026 Version 1.0 GA und es ist der Ort, an dem Microsoft von nun an Orchestrierung aufbauen möchte.

Die Arbeitsteilung ist nun klar: Das Agent Framework ist das SDK, in dem sich die Orchestrierungslogik befindet, und Foundry stellt das Produktionshosting, die Skalierung und das Observability drumherum bereit. Wenn Sie sich aus diesem Beitrag nur an eines erinnern, denken Sie an diesen Satz.

Hinweis: Wenn Sie noch über verbundene Agenten oder Portal-Workflows verfügen, müssen Sie nicht in Panik geraten. Exportierte Workflow-YAML läuft weiter, wenn sie als gehosteter Agent bereitgestellt wird, und die Migration zu deklarativen Agent Framework-Workflows ist normalerweise gering. Aber beginnen Sie nichts Neues mit den alten Mechanismen.

Was ist Microsoft Agent Framework?

Der Agent Framework ist der offizielle Nachfolger von Semantic Kernel und AutoGen, die von denselben Teams entwickelt wurden. Es kombiniert die einfachen Abstraktionen von AutoGen mit den Unternehmensfunktionen von Semantic Kernel: Zustandsverwaltung, Typsicherheit, Filter und Telemetrie. Es ist für Python und .NET, mit Go in der Vorschau verfügbar.

Die Installation besteht aus einer Zeile:

pip install agent-framework

Auch der Anschluss an Microsoft Foundry ist einfach. Sie erstellen einen Chat-Client für Ihr Foundry-Projekt und verwandeln ihn in einen Agenten:

from agent_framework.foundry import FoundryChatClient
from azure.identity import DefaultAzureCredential

# each agent is a Foundry model deployment + instructions
client = FoundryChatClient(
    project_endpoint="https://<your-project>.services.ai.azure.com/api/projects/<name>",
    model="gpt-5-mini",
    credential=DefaultAzureCredential())

writer = client.as_agent(name="writer", instructions="Write a first draft.")
reviewer = client.as_agent(name="reviewer", instructions="Review and improve the draft.")

Welche Orchestrierungsmuster sind integriert?

Das Framework wird mit fünf vorgefertigten Orchestrierungsmustern geliefert. Das ist der Kern des Themas, also lassen Sie uns sie einzeln durchgehen.

1. Sequentiell – die Pipeline

Jeder Agent verbraucht die Ausgabe des vorherigen. Perfekt, wenn die Aufgabe eine natürliche Reihenfolge hat: Entwurf, Überprüfung, Fertigstellung.

from agent_framework.orchestrations import SequentialBuilder

workflow = SequentialBuilder(participants=[writer, reviewer]).build()
result = await workflow.run("Write a summary of our Intune rollout plan.")

2. Gleichzeitig – das Fan-Out

Alle Agenten arbeiten parallel an derselben Aufgabe und die Ergebnisse werden aggregiert. Ich verwende dies, wenn ich unabhängige Perspektiven möchte, zum Beispiel drei Agenten, die gleichzeitig eine Richtlinienänderung auf Sicherheit, Lizenzierung und Auswirkungen auf die Benutzer überprüfen.

3. Gruppenchat – die moderierte Diskussion

Eine Sterntopologie, bei der ein Orchestrator entscheidet, wer als nächstes spricht. Die Auswahl kann Round-Robin, eine benutzerdefinierte Funktion oder sogar ein anderes LLM sein. Ein Detail, das Sie wissen sollten: Die Agenten teilen sich keine Sitzung. Der Orchestrator sendet jede Antwort an alle Teilnehmer, um den Kontext synchron zu halten – was bedeutet, dass die Token-Nutzung mit jeder Runde zunimmt.

4. Übergabe – Übergeben Sie die gesamte Aufgabe

Ein Agent übergibt die komplette Kontrolle an einen Spezialisten und nimmt sie nicht zurück. Dabei handelt es sich um die klassische Support-Triage: Der Triage-Agent entscheidet, ob der Besteller oder der Retouren-Agent übernimmt. Wichtiger Unterschied zu verbundenen Agenten: Eine Übergabe überträgt den Besitz der Aufgabe, während das alte Agent-as-Tools-Modell die Kontrolle immer an den Hauptagenten zurückgab.

5. Magentic – der Manager

Ein Manager-Agent plant die Aufgabe, führt ein Aufgabenbuch, delegiert die Aufgaben an Spezialisten, verfolgt den Fortschritt und plant neu, wenn etwas ins Stocken gerät. Es basiert auf der Magentic-One-Forschung von AutoGen. Dies ist das leistungsfähigste Muster und auch die am wenigsten vorhersehbaren Kosten, da der Manager iteriert, bis es erfüllt ist.

from agent_framework.orchestrations import MagenticBuilder

workflow = MagenticBuilder(
    participants=[researcher_agent, coder_agent],
    manager_agent=manager_agent,
    max_round_count=10, max_stall_count=3,
).build()

Hinweis: Alle fünf Muster unterstützen Human-in-the-Loop. Sie können ein Tool mit approval_mode="always_require" markieren und der Workflow wird angehalten, bis ein Mensch die Genehmigung erteilt. Für alles, was Produktionssysteme verändert, schalte ich dies immer ein.

Spickzettel: Welches Muster für welchen Job?

Muster	Verwenden Sie wann	Kosten, die Sie zahlen
Sequentielle	Die Aufgabe hat eine feste Reihenfolge	Die Latenz summiert sich pro Schritt
Gleichzeitig	Sie wollen parallel unabhängige Antworten	Tokens multiplizieren sich mit der Anzahl der Agenten
Gruppenchat	Agenten müssen aufeinander reagieren	Kontextübertragung auf Schritt und Tritt
Übergabe	Ein Spezialist sollte die Aufgabe übernehmen	Die Routingqualität hängt von den Beschreibungen ab
Magentisch	Offene, komplexe Probleme	Am wenigsten vorhersehbare Token-Kosten

Wie bringe ich das in die Produktion? Gehostete Agenten

Der Orchestrierungscode auf Ihrem Laptop ist nett, aber das Produktionsheim dafür ist gehostete Agenten in Foundry Agent Service. Gehostete Agents wurden Anfang Juli 2026 allgemein verfügbar und sind Framework-unabhängig: Agent Framework, LangGraph, Semantic Kernel oder einfacher benutzerdefinierter Code – Sie übertragen ein Container-Image an Azure Container Registry und Foundry führt es aus.

Was Sie kostenlos bekommen, ist einiges:

– Eine VM-isolierte Sandbox pro Sitzung mit einem dauerhaften Home-Verzeichnis, Skalierung auf Null nach 15 Minuten Leerlauf. – Eine automatische Microsoft Entra-Agentenidentität und ein dedizierter Endpunkt pro Agent. – Gewichtete Versions-Rollouts, damit Sie eine neue Agentenversion erstellen können. – OpenTelemetry Tracing in Application Insights, automatisch eingefügt.

Eines hat mich überrascht: Sie können Tools nicht direkt an eine gehostete Agentendefinition anhängen. Gehostete Agenten nutzen Foundry Tools – Code Interpreter, Azure AI Search, OpenAPI, MCP-Server – über einen einzelnen Toolbox MCP-Endpunkt. Ihr Agentencode spricht also Standard-MCP, und Foundry bedient sein gesamtes Tool-Ökosystem hinter diesem einen Endpunkt.

Wo passen A2A und MCP zusammen?

Die beiden Protokolle beantworten zwei unterschiedliche Fragen, und ihre Verwechslung sorgt für große Verwirrung:

• MCP (Model Context Protocol) verbindet einen Agent mit Tools. In Foundry hängen Sie einen MCPTool an einen Prompt-Agenten an, idealerweise mit einer allowed_tools-Liste und einem Genehmigungsablauf.
• A2A (Agent2Agent) verbindet einen Agenten mit anderen Agenten – auch über Plattformen und Clouds hinweg. Foundry unterstützt beide Richtungen: Ihr Agent kann einen Remote-A2A-Endpunkt über den A2A-Tool anrufen, und Sie können einen Foundry-Agenten als A2A-Endpunkt verfügbar machen mit einer veröffentlichten Agentenkarte. Eingehendes A2A ist immer noch in der Vorschau und nur für Entra verfügbar – keine API-Schlüssel, der Anrufer benötigt die Rolle Foundry Agent Consumer.

Meine einfache Regel: MCP für Tools, A2A für die Delegation über Team- oder Plattformgrenzen hinweg, Agent Framework-Muster für die Orchestrierung innerhalb einer Lösung.

Der Ansatz, den ich tatsächlich verwende

Wenn ich heute eine Multi-Agenten-Lösung plane, gehe ich diese Liste durch:

1. Kann ein Agent mit gutem Tools das schaffen? Dann baue ich überhaupt keinen Multiagenten. Jeder zusätzliche Agent fügt Latenz-, Kosten- und Fehlermodi hinzu.
2. Fester Prozess? Sequentielle Arbeitsabläufe in Agent Framework, bereitgestellt als gehosteter Agent.
3. Weiterleitung an Spezialisten? Übergabemuster mit klaren Ein-Satz-Beschreibungen pro Spezialist – die Weiterleitungsqualität ist nur so gut wie diese Beschreibungen.
4. Offene Recherche oder Analyse? Magentic, mit max_round_count-Einstellung und aktivierter menschlicher Planüberprüfung, da die Token-Rechnung Sie überraschen kann.
5. Der andere Agent gehört zu einem anderen Team oder einer anderen Plattform? A2A, kein gemeinsamer Workflow.

Fallstricke, die ich jetzt vermeide

• Entwicklung neuer Lösungen für verbundene Agenten oder den Portal-Workflow-Designer. Beide befinden sich auf einem veröffentlichten Ruhestandspfad. Ich baue Orchestrierung jetzt nur noch in Agent Framework auf.
• Magentic ohne Grenzen. Der Manager plant auf Ständen neu, und ohne max_round_count und max_stall_count zahlen Sie für seine Geduld. Stellen Sie immer beides ein.
• Gruppenchat für große Agentenzahlen. Da jede Antwort an alle Teilnehmer gesendet wird, bedeuten zehn Agenten zehn Kontextkopien pro Runde. Ab drei oder vier Agenten wechsle ich zu Handoff oder Magentic.
• Vergessen, dass durch das Veröffentlichen die Identität geändert wird. Wenn Sie einen Agenten veröffentlichen, erhält dieser seine eigene Entra-Agentenidentität – und bestehende Rollenzuweisungen werden nicht übernommen. Planen Sie die RBAC-Neuzuweisung in Ihrem Release-Schritt.
• Angenommen, Zitate fließen über die Delegation. Es wurde nie garantiert, dass Unteragentenzitate den Benutzer im Connected-Agents-Modell erreichen. In meinen Arbeitsabläufen ist der Agent, der mit dem Benutzer spricht, derjenige, der die Erdung vornimmt.

Wohin das führt

Die Richtung ist klar: Die Orchestrierungslogik geht in Open Source (Agent Framework), die Laufzeit geht in Foundry gehostete Agenten über und das Bindegewebe wird zu Standardprotokollen – MCP für Tools, A2A für Agent-zu-Agent. Die Einstellung des eigenen Portal-Designers durch Microsoft zugunsten des SDK verrät Ihnen alles darüber, wo sie die Zukunft sehen. Wenn Sie zunächst tiefer in die Grundlagen der Plattform einsteigen möchten, beginnen Sie mit meiner Komplettlösung für den ersten Agenten und dem Vergleich von Microsoft Foundry vs. Copilot Studio und behalten Sie die Agent Framework-Dokumente als Lesezeichen bei.

Ich hoffe, dieser tiefe Einblick hilft Ihnen dabei, Ihre Orchestrierungswette auf der richtigen Plattform zu platzieren.

Bleiben Sie gesund,

Prost Jannik