Zwei Türen, eine Runtime

Die Frage kommt in jedem zweiten Workshop, und sie kommt fast immer falsch formuliert: Was ist besser, Copilot Studio oder Microsoft Foundry?

Die Antwort ist unbefriedigend und trotzdem die richtige: Das sind keine Konkurrenten. Es sind zwei Eingänge zu derselben Sache, und die Wahl hat weniger mit Technik zu tun als damit, wer das Ding in zwei Jahren pflegt.

Was Microsoft gebaut hat

Seit Build 2026 ist die Struktur klarer als vorher. Microsoft beschreibt eine Agent-Plattform in drei Schichten: bauen, deployen, betreiben.

Unten liegt das Microsoft Agent Framework, quelloffen, stabil für Python und .NET. Es führt die Enterprise-Grundlagen von Semantic Kernel mit der Multi-Agent-Orchestrierung von AutoGen zusammen. Die Entscheidung zwischen beiden entfällt damit, und das war überfällig.

Darüber liegt der Foundry Agent Service mit hosted agents als gemanagter Runtime. Jede Session läuft in einer eigenen Sandbox mit eigener Compute-, Memory- und Dateisystem-Isolation. Bemerkenswert daran ist, dass die Runtime framework-agnostisch ist: Agents aus dem Microsoft Agent Framework, dem GitHub Copilot SDK, LangGraph oder anderen SDKs laufen dort ohne Umschreiben.

Und Copilot Studio ist die Low-Code-Tür in dieselbe Welt, inzwischen mit dem GitHub Copilot harness als Runtime darunter.

Was das praktisch bedeutet: Die Frage ist nicht mehr, welche Plattform mehr kann. Die Frage ist, welche Oberfläche zu deinem Team passt.

Die Entscheidungskriterien, die tatsächlich tragen

Wer pflegt es in zwei Jahren? Das ist bei mir die erste Frage, nicht die letzte. Ein Agent, den die Fachabteilung gebaut hat und den nur die IT ändern kann, ist tot, sobald sich der Prozess ändert. Umgekehrt: Ein Agent, der an einem Kernprozess hängt und den niemand reviewen kann, weil er in einem Designer lebt, ist ein Betriebsrisiko.

Gibt es ein Repository? Wenn dein Team ohnehin in git arbeitet, Pull Requests reviewt und eine Pipeline hat, dann ist Foundry der geringere Bruch. Wenn nicht, wird Foundry nicht dazu führen, dass diese Praktiken entstehen. Es wird dazu führen, dass niemand den Agent anfasst.

Wie sieht der Weg zum Nutzer aus? Hier hat sich etwas Wichtiges verschoben. Foundry-Agents lassen sich seit Juni 2026 direkt nach Microsoft Teams und Microsoft 365 Copilot veröffentlichen, mit durchgereichter Identität, Berechtigung und Policy. Der alte Reflex "wenn es in Teams landen soll, muss es Copilot Studio sein" stimmt nicht mehr.

Wie tief geht die Anforderung? Wenn du eigene Evaluationsschleifen, feingranulare Observability über OpenTelemetry oder eigene Orchestrierungsmuster brauchst, ist Copilot Studio die falsche Tür. Wenn ein Fachbereichsprozess in drei Wochen laufen soll und danach von den Leuten gepflegt wird, die ihn verstehen, ist Foundry die falsche Tür.

Wie wird abgerechnet? Copilot Studio auf dem GitHub Copilot harness rechnet über Copilot Credits ab, ab dem ersten Bauschritt. Foundry rechnet über Azure ab, mit den Mechanismen, die deine Cloud-Kostenstelle ohnehin kennt. Das ist kein Detail, sondern oft der Punkt, an dem eine Entscheidung tatsächlich kippt.

Meine Faustregeln

Ich benutze inzwischen vier Sätze, um die Entscheidung in einem Meeting zu treffen:

Copilot Studio, wenn der Prozess einem Fachbereich gehört, die Änderungshäufigkeit hoch ist und die Anforderung sich in Sprache beschreiben lässt. Rechnungseingang, Onboarding-Assistent, interner Helpdesk. Der GitHub Copilot harness kann mehrstufige Prozesse mit Dateien, Tools und Ausnahmen, das reicht für die allermeisten dieser Fälle.

Foundry, wenn der Agent Teil eines Produkts ist, an eine Codebasis grenzt oder eigene Orchestrierung braucht. Alles, was in einer Pipeline gebaut, getestet und deployed werden soll.

Beides, wenn du ehrlich bist. Der häufigste tragfähige Aufbau in größeren Häusern: Foundry für die Fähigkeiten, die schwer und geteilt sind, Copilot Studio für die Oberflächen, die nah am Fachbereich sitzen und diese Fähigkeiten aufrufen. Über A2A und MCP geht das inzwischen sauber.

Keins von beiden, wenn ein Workflow reicht. Das ist die Empfehlung, die am seltensten ausgesprochen wird und am häufigsten richtig wäre. Wenn ein Vorgang jedes Mal identisch abläuft, braucht er keinen Orchestrator, der jedes Mal neu darüber nachdenkt. Er braucht eine Automatisierung.

Der Punkt, den ich für den wichtigsten halte

Microsoft behandelt den Agent-Harness ausdrücklich als Flexpunkt und nicht als Bindung. Investitionen in LangGraph, das GitHub Copilot SDK oder das Claude Agent SDK werden mitgenommen, die hosted agents nehmen sie ohne Umschreiben an.

Das ist strategisch relevant. Die letzten Jahre bestanden darin, dass jede Plattform ihr eigenes Agent-Modell hatte und ein Wechsel einen Neubau bedeutete. Wenn die Runtime framework-agnostisch ist und Skills als Markdown zwischen Systemen wandern, dann verschiebt sich das Lock-in von der Anwendungsschicht auf Identität, Governance und Daten. Dort war es ohnehin immer.

Für Architekturentscheidungen heißt das: Die Wahl der Bauoberfläche ist reversibler geworden. Die Wahl, wo Identität, Kontext und Protokollierung liegen, ist es nicht. Kümmere dich um die zweite Frage mit der Sorgfalt, die du früher in die erste gesteckt hast.

Was ich noch nicht beurteilen kann

Wie gut die Grenze zwischen den beiden Türen im Alltag hält. Auf dem Papier ist es eine Runtime mit zwei Oberflächen. In der Praxis hat Copilot Studio ein eigenes Solution- und ALM-Modell über Dataverse, Foundry eines über Azure-Ressourcen und Repositories. Wer beides betreibt, betreibt zwei Betriebsmodelle, und das steht in keinem Architekturdiagramm.

Und ein Hinweis in eigener Sache: Ich beziehe mich hier bewusst nicht auf konkrete API-Signaturen des Agent Framework. Die ändern sich zwischen Paketversionen, und eine falsche Signatur in einem Text, den jemand kopiert, ist schlimmer als keine. Wer einsteigen will, fängt beim Repository und der Quickstart-Dokumentation an, nicht bei einem Blogbeitrag.

Quellen

• Build and run agents at scale with Microsoft Foundry at Build 2026, Microsoft Foundry Blog, 2. Juni 2026
• Choose a harness, Microsoft Learn
• Publish Foundry agents to Microsoft 365 Copilot and Teams, Microsoft Learn
• microsoft/agent-framework auf GitHub