Microsoft Copilot Harness in Foundry erklärt (2026)

Ein Modellwechsel sollte nicht bedeuten, dass die komplette Orchestrierung neu gebaut werden muss. Genau solche Umbauten bringen Agent-Projekte jedoch schnell aus dem Zeitplan. Der Microsoft Copilot Harness in Microsoft Foundry soll dieses Problem lösen: Microsoft stellt dieselbe verwaltete Ausführungsschicht bereit, die hinter Copilot Code, Copilot Studio, der GitHub-Copilot-App, der CLI und Visual Studio Code steckt. Seit dem 28. Oktober 2026 ist sie als Public Preview verfügbar – bis zum 1. Dezember 2026 kostenlos (blogs.microsoft.com). Für Experimente ist jetzt ein guter Zeitpunkt. Produktionssysteme sollten aber vorerst auf dem bestehenden Stack bleiben, solange die weiter unten beschriebenen Preview-Einschränkungen bestehen.

Was der Microsoft Copilot Harness tatsächlich übernimmt

Der Microsoft Copilot Harness ist eine verwaltete Orchestrierungsschicht rund um das Modell. Er sorgt dafür, dass aus Überlegungen konkrete Arbeitsschritte und Ergebnisse werden. Microsoft übernimmt Agenten-Schleife, Sandbox, Governance und Optimierung. Entwickler liefern Anweisungen, Skills, Tools und die Auswahl des Modells.

Microsoft bringt es selbst ziemlich direkt auf den Punkt: „Wenn das Modell die Intelligenz liefert, ist der Harness alles um das Modell herum“ (blogs.microsoft.com). In der Praxis verwaltet der Harness den Arbeitskontext während sich Aufgaben weiterentwickeln, koordiniert Modell- und Tool-Aufrufe, führt Dateien und Code in einer Sandbox aus, delegiert klar abgegrenzte Teilaufgaben an integrierte Subagenten und setzt konfigurierte Grenzen sowie Richtlinien durch (devblogs.microsoft.com).

Multi-Modell-Routing für mehr als 20 Frontier-Modelle und BYOK

Der Microsoft Copilot Harness unterstützt mehr als 20 Frontier-Modelle aus verschiedenen Modellfamilien sowie Bring-your-own-key-Konfigurationen (BYOK). Je nach Aufgabe wird die Arbeit an das passende Modell oder an mehrere passende Modelle weitergeleitet (blogs.microsoft.com). Welche 20 Modelle genau gemeint sind, nennt Microsoft in der Ankündigung nicht. Wer ein Multi-Modell-Design plant, sollte daher zunächst die Verfügbarkeit in der eigenen Foundry-Region prüfen. Die zentrale Botschaft lautet: Kunden müssen keinen eigenen Router mehr pflegen. „Sie bringen die Anweisungen, Skills, Tools und die Modellauswahl mit.“

Ein früher Nutzer fasste den Vorteil so zusammen: Die Orchestrierungsschicht muss nicht jedes Mal neu geschrieben werden, wenn sich das Modell ändert – @ai_fengshou.

Rust-Laufzeit und die Produkte, die bereits darauf setzen

Die Laufzeit des Microsoft Copilot Harness wurde kürzlich auf Rust portiert. Laut Microsoft senkt das den Sitzungs-Overhead und verkürzt die Zeit bis zum ersten Token (blogs.microsoft.com). Konkrete Prozentwerte oder eine Latenztabelle gibt es nicht. Die Aussage sollte daher als grobe Richtung verstanden werden.

Microsoft zufolge läuft derselbe Harness bereits in Copilot Code, Copilot Studio, der GitHub-Copilot-App, der GitHub Copilot CLI, Visual Studio Code sowie weiteren Microsoft- und GitHub-Copilot-Oberflächen (blogs.microsoft.com). Diese gemeinsame Basis sei mit Millionen Nutzern und Hunderten realen Anwendungsfällen erprobt worden (blogs.microsoft.com).

Für Erweiterungen unterstützt der Harness unter anderem das Model Context Protocol (MCP), Agent Skills und Agent Plugins (blogs.microsoft.com).

Was sich am 28. Oktober 2026 geändert hat

Am 28. Oktober 2026 hat Microsoft zwei eng miteinander verbundene Neuerungen vorgestellt: Der Microsoft Copilot Harness ging im Foundry Agent Service in die Public Preview, während die Ausfallsicherheit für lang laufende gehostete Agenten allgemein verfügbar wurde (devblogs.microsoft.com).

Auch die Begrifflichkeit ändert sich. Was in der Copilot-Studio-Dokumentation teilweise noch als GitHub Copilot Harness bezeichnet wird, heißt in der Produktterminologie nun Microsoft Copilot Harness. Die einzelnen Seiten werden allerdings nicht gleichzeitig umgestellt (microsoft.com).

Der Foundry Agent Service bietet jetzt drei Abstraktionsebenen: Prompt Agents ohne Harness, Prompt Agents mit dem Microsoft Copilot Harness als Preview sowie Hosted Agents, bei denen Entwickler das Framework selbst kontrollieren (devblogs.microsoft.com). Die bereits allgemein verfügbare Neuerung ist die Resilienz für lang laufende Prozesse. Hosted Agents können sich bei Unterbrechungen in Workflows erholen, die Stunden oder Tage dauern.

So entsteht ein Harness-Agent in Foundry

Ein Foundry-Harness-Agent wird deklarativ definiert und zusammen mit dem Anwendungscode gespeichert (devblogs.microsoft.com). Entwickler erstellen und testen den Agenten in Foundry, legen seine Definitionen unter Versionskontrolle und führen das Deployment über die Azure Developer CLI (azd) oder das Foundry-Portal aus (devblogs.microsoft.com).

Wiederverwendbare Skills bündeln die Vorgehensweise

Wiederverwendbare Skills bündeln Anweisungen, Skripte, unterstützende Ressourcen und Abläufe, die Agenten in unterschiedlichen Aufgaben einsetzen können. Das dokumentierte Beispiel verwendet einen research-brief-Skill unter skills/research-brief/SKILL.md. Er zwingt den Agenten dazu, Frage, Zielgruppe, Umfang und Zeitraum zu klären, mit freigegebenen Tools Belege zu sammeln, Quellen und Daten zu nennen, Fakten von Interpretationen zu trennen und widersprüchliche Hinweise zu markieren.

Verbundene Tools bleiben unter Kontrolle

Über verbundene Tools können Agenten Microsoft-Foundry-Tools und MCP-Tools verwenden. Authentifizierung und Freigaben müssen dafür ausdrücklich konfiguriert werden. Diese Freigabe ist einerseits eine wichtige Governance-Kontrolle. Wie die weiter unten zitierten Reddit-Berichte zeigen, kann sie in der Praxis aber auch zum Bremsklotz werden, wenn Endnutzer immer wieder Zustimmungsdialoge bestätigen müssen.

Ausführung, Dateien und Delegation

Agenten arbeiten mit Dateien, führen Code aus und delegieren klar abgegrenzte Aufgaben an integrierte Subagenten. Der Hauptagent koordiniert anschließend die Ergebnisse. Der Vergleich des Harness in Copilot Studio ergänzt, dass der Harness aus der GitHub-Linie Word-, Excel-, PowerPoint- und PDF-Dateien nativ erstellen und bearbeiten kann und außerdem Skills sowie Memory unterstützt (learn.microsoft.com).

Definitionen unter Versionskontrolle, Aktivierung mit einer Zeile

Die Agenten-Definitionen liegen direkt neben dem Code. Im Foundry-Beispiel wird der Harness in azure.yaml aktiviert (devblogs.microsoft.com):

harness:
  type: microsoft_copilot_preview

Das Beispiel verbindet einen research-brief-Prompt-Agenten mit einem research-brief-skill-Skill, der Websuche (public-research) und den Code Interpreter (research-analysis) nutzt. Als Umgebungsvariablen kommen FOUNDRY_PROJECT_ENDPOINT und MODEL_DEPLOYMENT_NAME zum Einsatz (devblogs.microsoft.com). Deployment und Aufruf erfolgen über die Preview-CLI:

azd deploy --all
azd ai agent invoke research-brief \
  "Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."

Weitere Wege zur Erstellung führen über das Foundry-Portal, das Foundry Toolkit für Visual Studio Code und das Foundry-Plugin für die GitHub-Copilot-App (devblogs.microsoft.com).

Welcher Foundry-Agent passt zu Ihrer Aufgabe?

Die eine richtige Abstraktionsebene gibt es nicht. Microsoft empfiehlt selbst, die Variante mit dem geringsten Infrastrukturaufwand zu wählen, die den Anforderungen der Anwendung genügt (devblogs.microsoft.com). Während der Preview wird diese Entscheidung beim Erstellen des Agenten festgelegt. Sie sollte also vor dem Klick auf „Erstellen“ fallen.

Zu den von Microsoft genannten frühen Kunden zählen Confluence Technologies, die sich innerhalb von weniger als einer Woche auf die Entwicklung konzentrieren und eine Lösung ausliefern konnten, sowie Fashable. Das Unternehmen nutzt den Harness für kontrollierte Beschaffungs-Workflows, behält wirtschaftlich bindende Entscheidungen aber in menschlicher Hand (devblogs.microsoft.com).

Was der Harness ab dem 1. Dezember 2026 kostet

Die Abrechnung der Microsoft-Copilot-Harness-Laufzeit beginnt am 1. Dezember 2026 und erfolgt verbrauchsabhängig. Die Laufzeitnutzung bleibt bis zu diesem Datum kostenlos. Modell-Inferenz, separat abgerechnete Tools und verbundene Dienste kosten jedoch auch während der Preview weiterhin extra.

Die Preise können je nach Region und Kundenvertrag abweichen (devblogs.microsoft.com). Während der Preview verwaltet Foundry CPU, Arbeitsspeicher und Leerlaufeinstellungen der Ausführungsumgebung (devblogs.microsoft.com) und verweist für unterstützte Regionen, Modelle, Tools und Preview-Limits auf separate Dokumentationen.

In Copilot Studio werden Agenten mit dem Harness aus der GitHub-Linie über Copilot Credits verbrauchsabhängig abgerechnet. Das ist eine separate Abrechnung von der Sandbox-Messung in Foundry (learn.microsoft.com). Für eine erste Kostenschätzung multiplizieren Sie die beobachteten vCPU- und GiB-Stunden der Sandbox mit den oben genannten Preisen und addieren anschließend Modell-Token sowie Tool-Kosten.

Diese Preview-Limits sollten Sie vor dem Start prüfen

Ob ein Preview-Pilot den Kontakt mit der Produktion übersteht, entscheidet oft das Kleingedruckte. Die folgenden Einschränkungen stammen von Microsoft, sofern sie nicht ausdrücklich als Nutzerbeobachtung gekennzeichnet sind.

• Die Harness-Wahl ist vorerst endgültig. Sie wählen den Harness beim Erstellen des Agenten. Bestehende Agenten bleiben unverändert, und ein nachträglicher Wechsel wird derzeit nicht unterstützt. Ein früher Leser wies genau darauf hin: „Sie wählen den Copilot Harness, wenn Sie den Agenten erstellen. Bestehende Agenten bleiben unverändert, und der Wechsel des Harness nach der Erstellung wird derzeit noch nicht unterstützt“ – @navaneethan_es.
• Regionen und Modelle sind eingeschränkt. Für die vollständige Liste verweist Foundry auf die Dokumentation zu unterstützten Regionen, Modellen, Tools und Preview-Limits. Einer Nutzerzusammenfassung zufolge gibt es ungefähr neun Regionen, keine Abdeckung des Nahen Ostens und noch kein vollständiges Bring-your-own-model — @HeshamSaadZaki. Das ist als Nutzerbeobachtung zu verstehen und sollte anhand der Dokumentation geprüft werden, nicht als offizielle Regionentabelle.
• Die Wiederherstellung lang laufender Prozesse bleibt Ihre Aufgabe. Foundry startet unterbrochene Hosted-Arbeiten neu und stellt die ursprüngliche Eingabe erneut bereit. Die Anwendung muss jedoch den Fortschritt speichern, von Checkpoints aus fortsetzen und doppelte Aktionen verhindern – etwa das zweimalige Erstellen desselben externen Berichts. Der Gesprächsverlauf allein stellt Arbeit, die gerade ausgeführt wurde, nicht wieder her.
• Zum Start gibt es keine Benchmark- oder SLA-Werte. Rechnen Sie mit qualitativen Aussagen wie „branchenführender Performance“, aber nicht mit Tabellen zu Latenz, Durchsatz oder Genauigkeit.

Was frühe Copilot-Harness-Nutzer in der Produktion erleben

Nutzer von Copilot Studio, die mit dem Harness aus der GitHub-Linie arbeiten, berichten wiederholt über die Abgrenzung zwischen Preview und Produktion. Diese Berichte beziehen sich auf die Copilot-Studio-Erfahrung mit dem GitHub Harness vor der Foundry-Preview. Sie sind hier als Schlussfolgerung aus der von Microsoft beschriebenen gemeinsamen Herkunft enthalten (blogs.microsoft.com), nicht als Messwerte für Foundry.

Die verdammten Konnektoren bleiben in der Produktion nicht einmal einen Tag verbunden. — u/roberts2727 in r/copilotstudio

Manchmal funktionieren die Flows, manchmal übergibt der Agent überhaupt nichts an sie. — u/donstazz in r/copilotstudio

Geschäftsanwender können diese App-Registrierungen und ähnliches nicht selbst erledigen. Dafür brauchen sie IT-Administratoren – für jeden einzelnen Agenten. — u/Teemu_St in r/copilotstudio

Aus diesen Threads wurden unter anderem folgende Probleme berichtet:

• Langsamere Antworten bei Agenten mit SharePoint als Wissensquelle. In r/copilotstudio werden sie als deutlich langsamer als bei Alternativen beschrieben.
• Agenten funktionieren im Testfenster von Studio, scheitern nach dem Deployment in Teams oder M365 Copilot aber mit allgemeinen Fehlermeldungen (r/copilotstudio).
• Instabile Konnektoren und Flows sowie wiederholte Authentifizierungs- und MCP-Freigaben (r/copilotstudio).
• Unklarheit bei der Abrechnung: Deckt eine M365-Copilot-Lizenz die Harness-Laufzeit ab, oder fallen weiterhin Copilot Credits an? (r/microsoft_365_copilot).

Das spricht nicht grundsätzlich gegen die Foundry-Preview. Es definiert aber die Checkliste für einen Pilotversuch: Testen Sie mit Ihrer tatsächlichen Wissensquelle, in Ihrem echten Kanal und mit dem realen Zustimmungsprozess für Endnutzer, bevor Sie Zeitpläne versprechen.

FAQ

Ist der Microsoft Copilot Harness dasselbe wie der GitHub Copilot Harness?

Ja. Es handelt sich um dieselbe von GitHub entwickelte technische Linie, die nun unter dem neuen Microsoft-Namen geführt wird. Einige Copilot-Studio-Dokumente verwenden während der Umstellung noch die alte Bezeichnung.

Welche Modelle unterstützt der Foundry Harness?

Mehr als 20 Frontier-Modelle sowie BYOK mit aufgabenbasierter Weiterleitung. Microsoft veröffentlicht die vollständige Liste nicht. Prüfen Sie daher die Foundry-Dokumentation für Ihre Region (siehe den Abschnitt zu Multi-Modell-Routing oben).

Kann ich einen bestehenden Foundry-Agenten auf den Harness umstellen?

Während der Preview ist kein Wechsel im laufenden Betrieb möglich. Führen Sie stattdessen eine parallele Bewertung durch: Erfassen Sie Prompts, Tools, Authentifizierung und Anforderungen an den Status, erstellen Sie den Agenten in einem Preview-Projekt mit microsoft_copilot_preview neu und vergleichen Sie Qualität, Latenz, Sandbox-Nutzung und Wiederherstellung, bevor Sie umstellen.

Deckt eine M365-Copilot-Lizenz die Harness-Nutzung ab?

Nicht automatisch. Foundry rechnet Sandbox-Compute und Speicher getrennt von der Modell-Inferenz ab, während Copilot Studio diese Harness-Familie über Copilot Credits abrechnet. Prüfen Sie, welcher Zähler für Ihre Oberfläche gilt.

Sollte ich den Harness oder einen Hosted Agent verwenden?

Nutzen Sie den Harness, wenn Sie eine verwaltete Agenten-Schleife, Sandbox, Skills und Subagenten benötigen, ohne die Orchestrierung selbst zu betreiben. Ein Hosted Agent ist die bessere Wahl, wenn Sie Framework oder Laufzeit kontrollieren müssen und Checkpointing sowie Idempotenz selbst verantworten können.

Starten Sie in der Preview mit dem research-brief-Skill-Muster. Messen Sie die Sandbox- und Token-Kosten im Vergleich zu einem Prompt-Agenten ohne Harness bei derselben Aufgabe. Für die Produktion sollten Sie bei Ihrem bewährten Ansatz bleiben, bis Migration, Regionen und das Zustimmungsverhalten für Ihren Tenant dokumentiert sind.