Platform Decisions

The Three-Platform Grammar

Copilot Studio passt zu einem Workload, bei dem eine Abteilung den Agent besitzt und kein Entwickler nötig sein soll, um ihn zu ändern. Microsoft Foundry passt dort, wo Governance, Evaluation Gates und Cost Attribution pro Run die entscheidenden Faktoren sind. Das Microsoft Agent Framework passt dort, wo mehrere Agents an Arbeit zusammenwirken müssen, die für einen zu groß ist. Das ist kein Spektrum zunehmender Raffinesse: es sind drei verschiedene Antworten auf drei verschiedene Fragen.

Die richtige Frage zu erkennen kommt vor der Wahl der Platform. Vier Fragen klären die meisten Entscheidungen, bevor überhaupt über Capabilities gesprochen wird: wo die Daten verarbeitet werden dürfen, welche Identity den Call regelt, was Monate später nachweisbar sein muss und wer den Agent ändern darf, sobald er läuft.

Ein Agent, den sein Business Owner ohne Entwickler nicht ändern kann, ist falsch eingeordnet, unabhängig davon, welche Platform gewählt wurde.

Entscheidungen an laufenden Systemen

Jede Entscheidung auf dieser Seite wurde an einem laufenden System getroffen, auch die, die zweimal getroffen wurden, weil die erste Antwort falsch war.

Magentic Teams scheitern an der Microsoft Foundry Responses API mit einem Manager Ledger Error. Die funktionierende Konfiguration ist stattdessen der OpenAI-kompatible Chat Completions Client. Das ist die Klasse von Fehlern, deren Diagnose Tage dauert und deren Behebung Minuten, und genau deshalb liegt sie in den Skills des Repositories statt im Gedächtnis einer Person. Das nächste Projekt startet bei der Antwort statt bei derselben Unbekannten.

Die Topology wird pro Workload entschieden, nicht pro Projekt, und der Lifecycle bestimmt den Split. Eine Content Pipeline läuft als zwei unabhängig gehostete Microsoft Foundry Agent Services, weil ein Optimize-and-Translate Router und ein Research-plus-Writing Team sich unterschiedlich schnell ändern. Jedes deployt, ohne auf das andere zu warten, und genau darum geht es beim Split.

Ein Decision Record, der Bestand hat

Die Architecture wird für die Last und die Compliance-Position gewählt, die die Organisation tatsächlich hat. Nicht für die, die in einem Briefing vor Projektstart beschrieben wurde.

Microsoft Foundry stellt sein eigenes Workflows Feature am 2026-12-01 ein und lenkt neue Arbeit auf das Microsoft Agent Framework. Eine Platform-Entscheidung aus dem Vorjahr kann heute die falsche sein. Ohne schriftlichen Grund kann eine Migration eine bewusste Wahl nicht von einem Default unterscheiden.

Der schriftliche Record benennt den Workload, die Antworten auf die vier Fragen, die gewählte Platform, den Grund zum Entscheidungszeitpunkt und die Bedingungen, unter denen die Antwort sich ändern würde. Eine Entscheidung, die im Repository liegt, reist mit dem Codebase, für den sie gilt. Wenn sich das Feld bewegt, macht der Grund die alte Entscheidung überprüfbar. Ohne ihn kann eine Migration nicht begründen, warum die ursprüngliche Wahl getroffen wurde.

4 Fragen

bevor eine Platform genannt wird: Data Residency, Identity, Nachweisbarkeit, Change Ownership

3 Platforms

Copilot Studio, Microsoft Foundry, Microsoft Agent Framework: drei verschiedene Antworten

2026-12-01

Foundry Workflow Retirement: eine Entscheidung ohne schriftlichen Grund kann sich nicht verteidigen

6 Provider

Microsoft Agent Framework in 1.0 GA, Anthropic Claude inklusive, Swap in einer Zeile

Vom Workload Profile zur schriftlichen Entscheidung

Qualifizieren 3 Schritte

Beschreiben Sie den Workload, bevor eine Platform genannt wird

Die erste Arbeit ist eine Beschreibung des Workloads, losgelöst von jeder Platform. Welche Daten berührt er, und wo dürfen diese Daten verarbeitet werden? Was passiert, wenn der Agent auf veraltetem State handelt? Was kostet ein falscher Output tatsächlich, an Zeit, an Geld oder in einem Audit Record? Diese Fragen brauchen keine technologische Antwort. Sie ergeben ein Profil des Workloads, an dem sich die Platform-Entscheidung messen lässt. Die Platform zu benennen, bevor dieses Profil existiert, ist die häufigste Ursache für Neuentscheidungen: das Tool wurde für einen Workload gewählt, den noch niemand verstanden hatte.

Die vier Fragen, die die meisten Entscheidungen klären

Vier Fragen klären die meisten Platform-Entscheidungen, bevor überhaupt über Capabilities gesprochen wird. Wo dürfen die Daten verarbeitet werden: im Tenant, im Europäischen Wirtschaftsraum, überall? Welche Identity regelt den Call: ein Service Principal, ein delegiertes User Token, eine Managed Identity? Was muss Monate später nachweisbar sein: welches Model verwendet wurde, was der Input enthielt, was der Output sagte? Und wer darf den Agent ändern, sobald er läuft: ein Entwickler, ein Business Analyst, die Abteilung, der er gehört? Ein Agent, den sein Business Owner ohne Entwickler nicht ändern kann, ist falsch eingeordnet, unabhängig davon, welche Platform gewählt wurde.

Der Lifecycle bestimmt den Topology Split

Die Topology wird pro Workload entschieden, nicht pro Projekt. Die Frage ist nicht, wie komplex der Workload ist, sondern in welchem Tempo er sich ändert und wem diese Änderungen gehören. Ein Workload, den eine Fachabteilung monatlich ohne Entwickler anpasst, gehört in einen anderen Host als einer, dessen Logik sich nur ändert, wenn das Engineering Team released. Die Unterscheidung gilt auch feiner: Eine einzelne Pipeline kann sich zu Recht in zwei Services teilen, weil ihre Routing-Logik und ihre Writing-Logik sich unterschiedlich schnell ändern und ein gemeinsames Deployment zwei unabhängige Release Cadences koppeln würde.

Auswählen 3 Schritte

Copilot Studio, Microsoft Foundry oder das Agent Framework

Copilot Studio passt dort, wo eine Fachabteilung den Agent besitzt und der Scope innerhalb von Microsoft 365 bleibt. Kein Entwickler soll nötig sein, um zu ändern, was der Agent tut. Microsoft Foundry passt dort, wo Governance Gates, Evaluation Runs und Cost Attribution pro Run nicht verhandelbar sind. Agent Harness GA bringt automatische Context Compaction und OpenTelemetry Tracing nach Application Insights. Foundry Hosted Agents GA ergänzt Scale-to-Zero und VM-Isolation pro Session. Das Microsoft Agent Framework passt dort, wo mehrere Agents an Arbeit zusammenwirken müssen, die für einen zu groß ist, mit durable State über lang laufende Steps und eingebauten Human Approval Gates.

Wenn Foundry sein Workflow Feature einstellt

Microsoft Foundry stellt sein eigenes Workflows Feature am 2026-12-01 ein und lenkt alle neue Arbeit auf das Microsoft Agent Framework. Das Microsoft Agent Framework 1.0 erreichte am 2026-04-03 General Availability, in .NET und Python, MIT-lizenziert, vereint AutoGen und Semantic Kernel unter einer Surface, mit sechs Model Providern und einem Swap in einer Zeile zwischen ihnen, inklusive Anthropic Claude. Eine Platform-Entscheidung, die vor April 2026 getroffen wurde und von Foundrys Workflow Engine abhing, steht jetzt auf der falschen Platform. Das ist das stärkste Argument auf dieser Seite dafür, die Entscheidung samt Grund zum Zeitpunkt der Entscheidung schriftlich festzuhalten.

Weisen Sie die riskanteste Konfiguration gegen die echte Platform nach

Die riskanteste Konfiguration wird gegen die echte Platform nachgewiesen, bevor irgendetwas darauf aufgebaut wird. Magentic Teams scheitern an der Microsoft Foundry Responses API mit einem Manager Ledger Error. Die funktionierende Konfiguration ist der OpenAI-kompatible Chat Completions Client. Das ist die Klasse von Fehlern, deren Diagnose Tage dauert und deren Behebung Minuten. Die Diagnose liegt in den Skills des Repositories, damit das nächste Projekt bei der Antwort startet. Keine Phase beginnt, bevor die vorige sich bewiesen hat. Die teure Unbekannte wird geklärt, solange ein Irrtum noch billig ist.

Festhalten 3 Schritte

Streamen Sie den Run und tracen Sie jede Stage

Streaming ist eine Architecture Decision, kein UI-Detail, und gehört in die schriftliche Entscheidung. Ergebnisse streamen über die API als Server-Sent Events mit deaktiviertem Response Buffering auf der .NET-Seite, damit ein langer Run schon sichtbar ist, während er noch läuft. Jede Pipeline Stage schreibt eine strukturierte JSON-Zeile mit einer AsyncLocal Correlation Id. Damit werden Kosten pro Run und der Fehlerpfad eines stehen gebliebenen Runs im Nachhinein lesbar, ohne Business Code zu instrumentieren. Beide Entscheidungen stehen im Decision Record, weil beide zu den Entscheidungen gehören, die ein neuer Mitarbeiter verstehen muss, bevor er die Pipeline anfasst.

Was die schriftliche Entscheidung enthält

Die schriftliche Entscheidung benennt sechs Dinge: den Workload, die Antworten auf die vier qualifizierenden Fragen, die gewählte Platform, den Grund zum Zeitpunkt der Entscheidung, die geprüften Alternativen samt Ausschlussgrund und die Bedingungen, unter denen die Antwort sich ändern würde. Der Grund wiegt schwerer als die Wahl. Wenn ein Hersteller ein Feature einstellt, kann ein Record, der nur die Wahl trägt, nicht sagen, ob das Feature beiläufig oder tragend war. Ein Record, der den Grund trägt, kann es. Die Entscheidung wird in dem Repository geschrieben, das das System hält, für das sie gilt, nicht in einem separaten Dokumentenspeicher.

Wie der Record seinen Autor überdauert

Eine Entscheidung, die im Repository liegt, reist mit dem Codebase, den sie dokumentiert. Ein Cold Clone, mit dem ein neuer Mitarbeiter startet, trägt auch die Entscheidungshistorie, die Antworten auf die qualifizierenden Fragen und die Bedingungen, die zu jeder Antwort gesetzt wurden. Wenn sich eine Platform rund um eine Entscheidung ändert, macht der Record das Review mechanisch: Vergleichen Sie die zum Entscheidungszeitpunkt genannten Bedingungen mit dem aktuellen Stand der Platform. Ohne Record startet jede Migration bei null, im Unklaren darüber, ob die ursprüngliche Wahl bewusst war oder nur ein Default, den das Projekt nie überprüft hat. Der Record ist das, was eine Entscheidung überlebensfähig macht und nicht bloß nachvollziehbar.

Häufige Fragen

Wann braucht ein Workload das Microsoft Agent Framework statt eines Hosted Agent Service?

Entscheidend sind Lifecycle und Koordination. Ein Hosted Agent Service auf Microsoft Foundry passt, wenn ein Team von Agents seine eigene Release Cadence hat und die Orchestration innerhalb eines abgegrenzten Service bleibt. Das Microsoft Agent Framework rechtfertigt seine Kosten, wenn mehrere Agents über einen lang laufenden Workflow koordinieren müssen, mit durable State zwischen den Steps und Human Approval Gates mitten im Run. Das GA vom 2026-04-03 hat AutoGen und Semantic Kernel zu einer Surface zusammengeführt: Code, der vor diesem Datum geschrieben wurde, sitzt auf einer API, die das Framework inzwischen absorbiert hat.

Was lässt Platform-Entscheidungen schiefgehen?

Die meisten Neuentscheidungen gehen auf dieselben zwei Ursachen zurück. Die erste ist, die Platform zu benennen, bevor das Workload Profile existiert: Data Residency, Identity Model und die Frage nach der Change Ownership beantwortet die Platform, bevor eine Zeile Code geschrieben ist, wer also die Platform zuerst wählt, akzeptiert die Antworten, die dabei herauskommen. Die zweite ist, zu wählen, ohne den Grund aufzuschreiben. Wenn ein Hersteller ein Feature einstellt oder sich eine Regulierung ändert, lässt sich eine nackte Wahl nicht gegen die Bedingungen prüfen, die zu ihr geführt haben.

Was stellt Microsoft Foundry ein, und warum ist das jetzt relevant?

Microsoft Foundry stellt sein eigenes Workflows Feature am 2026-12-01 ein und lenkt neue Arbeit auf das Microsoft Agent Framework. Für jeden agentic Workload, der heute auf Foundrys nativer Workflow Engine läuft, lautet die praktische Frage, ob die Migration auf das Agent Framework besser jetzt erfolgt oder von der Deadline erzwungen wird. Das Agent Framework erreichte am 2026-04-03 1.0 GA und ist MIT-lizenziert. Das ist ein stabiles Ziel. Eine mit Grund geschriebene Entscheidung macht die Migration rational; eine ohne Grund macht sie zur Erkundung.

Wie observable muss eine agentic Pipeline sein?

So observable, dass ein stehen gebliebener Run ohne Lesen der Business-Logik diagnostiziert werden kann. Ergebnisse streamen als Server-Sent Events mit deaktiviertem Response Buffering auf der .NET-Seite, damit der Run keine Blackbox ist, während er läuft. Jede Pipeline Stage schreibt eine strukturierte JSON-Zeile mit einer AsyncLocal Correlation Id, was Kosten pro Run und den vollständigen Fehlerpfad im Nachhinein lesbar macht. Beide Entscheidungen gehören in das Decision Record: die nächste Person, die eine neue Stage instrumentiert, muss wissen, welches Pattern die Pipeline bereits verwendet.

Wie sieht die schriftliche Entscheidung in der Praxis aus?

Eine Datei im Repository, kein separates Dokument. Sie benennt den Workload, die Antworten auf die vier qualifizierenden Fragen, die gewählte Platform, den Grund zum Zeitpunkt der Entscheidung, die geprüften und ausgeschlossenen Alternativen und die Bedingungen, die die Antwort ändern würden. Das Bedingungsset macht aus einem statischen Record einen lebenden: Wenn ein Hersteller eine Capability einstellt oder sich eine Data-Residency-Regel ändert, sagt der Record einem Reviewer genau, was zu prüfen ist. Eine Entscheidung, die im Repository liegt, reist mit jedem Clone des Codebase.