Start mit Copilot Studio

Copilot Studio baut auf drei Harnesses: der GitHub Copilot Harness für vielschichtige, urteilsbasierte Prozesse, der Standard Harness für regelbasierte, planbare Konversationen und der Copilot Chat Harness, der Microsoft 365 Copilot Chat um eigenes Wissen erweitert. Agents lassen sich über Teams, Web und Enterprise-Anwendungen verteilen und binden Connectors, REST APIs und MCP Server an.

Prompt Agent oder Hosted Agent

Microsoft Foundry bietet zwei Agent-Typen. Der Prompt Agent ist der schnellste Weg: Sie konfigurieren Instructions, Model und Tools, und Foundry betreibt den Agent ohne Code oder Infrastruktur. Der Hosted Agent gibt die volle Kontrolle: Sie bringen eigenen Code und ein eigenes Framework als Container mit, und Foundry liefert einen Managed Endpoint, Autoscaling und eine dedizierte Entra Identity.

Vom Prototyp zur Veröffentlichung

Der Foundry Development Lifecycle führt von Create über Test, Trace und Evaluate bis zu Optimize, Publish und Monitor, mit automatisch versionierten Snapshots und Rollback auf jede vorherige Version. Veröffentlicht wird nach Microsoft Teams und Microsoft 365 Copilot, mit dedizierter Entra Identity, Private Networking, rollenbasierter Zugriffskontrolle und Content Filtern pro Agent.
Team aktualisiert
das Business Team, dem der Copilot Studio Agent gehört, aktualisiert ihn direkt; jede Änderung bleibt in der Fachabteilung
Volle Code-Kontrolle
Ihr eigener Code und Framework laufen als Container; Foundry übernimmt Endpoint, Autoscaling und Entra Identity
Schnellster Weg
der Prompt Agent startet mit Instructions, Model und Tools; Foundry übernimmt Code und Infrastruktur

Von Copilot Studio zu Microsoft Foundry

Start mit Copilot Studio 2 Schritte
01

Drei Harnesses für drei Szenarien

Der GitHub Copilot Harness denkt vielschichtige Geschäftsprozesse durch und passt sich an, wenn sich Umstände ändern. Der Standard Harness folgt festgelegten Topics für planbare Antworten. Der Copilot Chat Harness erweitert Microsoft 365 Copilot Chat um eigenes Wissen.
02

Verteilen über Kanäle und Tools

Agents lassen sich über Microsoft Teams, Web und Enterprise-Anwendungen verteilen. Sie binden sich über Connectors, REST APIs und MCP Server an Ihre Systeme an, rufen Workflows auf und geben Aufgaben an andere Agents weiter, statt sie selbst zu Ende zu führen.
Prompt Agent oder Hosted Agent 2 Schritte
03

Prompt Agent: der schnellste Weg

Sie konfigurieren Instructions, ein Model und Tools, und Foundry betreibt den Agent ohne Code oder Infrastruktur. Portal-first entsteht der Agent interaktiv im Foundry Portal, code-first über SDK oder REST API in Ihrer Deployment Pipeline.
04

Hosted Agent: volle Kontrolle

Sie bringen eigenen Code mit, gebaut mit dem Microsoft Agent Framework, LangGraph, dem OpenAI Agents SDK oder eigenem Code. Foundry liefert einen Managed Endpoint, automatisches Scaling und eine dedizierte Entra Identity pro Agent.
Vom Prototyp zur Veröffentlichung 2 Schritte
05

Testen, Tracen, Evaluieren

Im Agents Playground chatten Sie mit dem Agent oder führen ihn lokal aus, mit MCP Servern direkt testbar. Jeder Model Call und Tool Call lässt sich per Tracing nachvollziehen, und Evaluations messen die Qualität und decken Regressionen auf.
06

Versionieren und Veröffentlichen

Jede Iteration wird automatisch als Version festgehalten, mit Rollback auf jede vorherige Version und einem Vergleich zwischen Versionen. Veröffentlichte Agents laufen über Microsoft Teams, Microsoft 365 Copilot und die Entra Agent Registry.

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.