Die Kurzfassung
Microsoft vermietet jetzt die Agenten-Laufzeitumgebung, auf der GitHub Copilot läuft. Seit dem 28. Oktober 2026 ist die Copilot-Harness als Public Preview im Foundry Agent Service verfügbar: Microsoft betreibt Agentenschleife und Sandbox, Entwickler wählen das Modell und schreiben Anweisungen, Skills und Tools. Für Teams, die KI-Agenten entwickeln lassen oder selbst bauen, spart das Wochen an Infrastrukturarbeit – bindet die Laufzeit aber an Microsofts Regeln und Preise.
Was hat Microsoft angekündigt?
Eine Harness ist alles rund um das Modell, was einen Agenten eine Aufgabe zu Ende bringen lässt: Anweisungen, Kontext, Tools, eine Ausführungsumgebung und Kontrollen. In einem Beitrag, den Foundry-CVP Tina Schuchman und GitHub-CTO Vladimir Fedorov gemeinsam gezeichnet haben, kündigte Microsoft an, die von GitHub für Copilot gebaute Harness für externe Entwickler zu öffnen – als herunterladbares SDK oder als vollständig verwalteten Dienst in Foundry, in dem Microsoft Agentenschleife und Sandbox mit integrierter Governance betreibt. Nach Angaben von Microsoft wurde die Laufzeit der Harness kürzlich nach Rust portiert, um Session-Overhead und Zeit bis zum ersten Token zu senken.
Laut The New Stack verwaltet die Harness Modell- und Tool-Aufrufe, behält den Kontext im Blick und hält Agenten innerhalb der konfigurierten Richtlinien. Skills bündeln Anweisungen, Skripte und Ressourcen; Agenten können mit Dateien arbeiten, Code ausführen und Aufgaben an Subagenten übergeben, deren Ergebnisse der Hauptagent zusammenführt. Definiert werden Agenten in einer azure.yaml-Datei, ausgerollt mit azd deploy --all über die Azure Developer CLI; die Konfiguration kann neben dem Anwendungscode in der Versionsverwaltung liegen. Für Teams, die bereits auf Azure arbeiten, ist das eine naheliegende Option.
Welche Kompromisse gibt es?
Der wichtigste betrifft die Kontrolle über die Laufzeit. Der Harness-Typ muss beim Anlegen eines Prompt-Agenten gewählt werden und lässt sich später nicht ändern, auch nicht in einer neuen Version. Microsoft legt außerdem fest, wie viel CPU und Arbeitsspeicher der Agent erhält und wie lange er untätig bleiben darf. Entwickler bestimmen, was der Agent tut – nicht, in welcher Umgebung er läuft.
Auch das Multi-Modell-Versprechen hat Grenzen. Microsoft nennt mehr als 20 Frontier-Modelle plus Bring-your-own-Key, doch in der verwalteten Foundry-Version nutzen Agenten kompatible, über Foundry bereitgestellte Modelle, und laut The New Stack werden eigene Custom-Modelle nicht unterstützt. Teams, die eigene Frameworks oder Modelle brauchen, können stattdessen Foundry Hosted Agents nutzen, bei denen Microsoft nur das Hosting übernimmt; am selben Tag wurde für diese Agenten die Ausfallsicherheit bei Langläufern allgemein verfügbar, sodass Aufgaben über Stunden oder Tage nach Unterbrechungen wieder aufsetzen können.
Was wird es kosten?
Im Foundry Agent Service ist die Harness bis zum 1. Dezember 2026 kostenlos; Modell-Inferenz sowie einige Tools und verbundene Dienste werden jedoch separat berechnet. Danach verlangt Microsoft 0,0994 US-Dollar pro vCPU-Stunde und 0,0118 US-Dollar pro GiB-Stunde Arbeitsspeicher, wobei die Sätze je nach Region und Vertrag abweichen können. Für die meisten Agenten sind die Laufzeitkosten damit gering im Vergleich zu den Token-Kosten, doch untätige Sessions, lange Aufgaben und parallele Subagenten summieren sich – Kosten sollten daher pro abgeschlossener Aufgabe gemessen werden, nicht pro Monat.
Was bedeutet das für Softwareteams in den USA und der EU?
Die eigentliche Schwierigkeit bei Agenten verschiebt sich von der Modellwahl zum Laufzeit-Engineering: Sandboxing, Tool-Berechtigungen, Wiederholversuche, Kontextverwaltung und Audit-Trails. Eine verwaltete Harness, die nach Microsofts Angaben bereits Millionen von Copilot-Nutzern bedient, nimmt Teams einen großen Teil davon ab. Für US-Teams auf Azure kann das einen Piloten von Wochen auf Tage verkürzen und Sicherheitsprüfern eine bekannte Laufzeit statt Eigenentwicklung zur Bewertung geben.
Für EU-Teams hilft eine regelkonforme Laufzeit mit freigabepflichtigen MCP-Verbindungen und Richtlinienkontrollen bei den Protokollierungs- und Aufsichtspflichten, nach denen regulierte Kunden fragen – sie klärt aber nicht, wo Daten verarbeitet werden. Prüfen Sie, in welchen Regionen Agent und Modell laufen, und dokumentieren Sie Tool-Zugriffe und Freigaben für DSGVO-, DORA- und EU-AI-Act-Prüfungen. Überall gilt dieselbe strategische Frage: Je mehr Ihres Agenten in der Harness eines Anbieters lebt, desto schwerer ist später ein Anbieterwechsel.
Was bedeutet das für den DACH-Markt?
Im deutschsprachigen Raum ist Microsoft 365 und Azure in Mittelstand, Banken und Verwaltung tief verankert – viele Unternehmen haben bereits Rahmenverträge und Azure-Landing-Zones. Die Copilot-Harness senkt hier die Einstiegshürde für eigene Agenten deutlich, weil Einkauf, Identitäten und Governance oft schon vorhanden sind. Die erste Frage von Datenschutzbeauftragten wird trotzdem lauten, in welcher Region Agent und Modell laufen: Azure betreibt Rechenzentrumsregionen in Deutschland und der Schweiz, aber ob die Preview und das gewählte Modell dort verfügbar sind, muss im Einzelfall geprüft und im Verzeichnis von Verarbeitungstätigkeiten nach DSGVO festgehalten werden.
Für Unternehmen mit Betriebsrat kommt ein DACH-typischer Punkt hinzu: Agenten, die auf Mitarbeiterdaten, Tickets oder E-Mails zugreifen, können mitbestimmungspflichtig sein – Freigabe-Gates und Protokolle der Harness erleichtern die Dokumentation, ersetzen aber keine Betriebsvereinbarung. Finanzdienstleister sollten den Agenten zudem in ihr DORA-Register für IKT-Drittdienstleister aufnehmen. Praktisch empfehlen wir, in der kostenlosen Phase einen klar abgegrenzten internen Anwendungsfall zu pilotieren und Skills sowie Evaluierungen im eigenen Git-Repository zu halten, damit ein späterer Wechsel zu einer selbst betriebenen Laufzeit möglich bleibt.
Was sollten Teams jetzt tun?
- Im kostenlosen Zeitfenster pilotieren. Bauen Sie vor dem 1. Dezember einen echten Agenten und messen Sie Erfolgsquote, Token und Laufzeitstunden pro Aufgabe.
- Agentenlogik im eigenen Repository halten. Legen Sie Skills, Anweisungen, Tool-Definitionen und Evaluierungen in Git ab, damit sie auf eine andere Laufzeit umziehen können.
- Die Harness vorab festlegen. Da sie nach dem Anlegen nicht mehr änderbar ist, entscheiden Sie je Anwendungsfall vor dem Bau zwischen Copilot-Harness und Hosted Agents.
- Tools absichern. Nutzen Sie MCP-Authentifizierung und Freigaben, Zugangsdaten nach dem Least-Privilege-Prinzip und getrennte Sandboxes für Produktivdaten.
- Budgets und Alarme setzen. Erfassen Sie vCPU-Stunden, Arbeitsspeicher und Modellkosten pro Agent und begrenzen Sie Leerlaufzeit und parallele Subagenten.
- Datenstandort bestätigen. Dokumentieren Sie Regionen, Modelle und Datenflüsse für Kunden- und Aufsichtsprüfungen.
Häufig gestellte Fragen
Was ist die Microsoft Copilot-Harness?
Die Orchestrierungsschicht, die GitHub für die eigenen Copilot-Produkte gebaut hat: der Teil rund um das Modell, der Anweisungen, Kontext, Tool-Aufrufe, die Ausführungs-Sandbox und Richtlinienkontrollen verwaltet. Laut Microsoft betreibt dieselbe Harness inzwischen Copilot Code, Copilot Studio, die GitHub-Copilot-App, die CLI und VS Code. Seit dem 28. Oktober 2026 können Entwickler sie für eigene Agenten über den Foundry Agent Service in der Public Preview nutzen oder ein SDK von GitHub herunterladen.
Was kostet die Copilot-Harness?
Im Foundry Agent Service ist die Harness bis zum 1. Dezember 2026 kostenlos; Modell-Inferenz sowie einige Tools und verbundene Dienste werden separat berechnet. Danach berechnet Microsoft laut The New Stack 0,0994 US-Dollar pro vCPU-Stunde für Rechenleistung und 0,0118 US-Dollar pro GiB-Stunde für Arbeitsspeicher; die Sätze können je nach Region und Kundenvertrag variieren.
Welche Modelle können Agenten auf der Copilot-Harness nutzen?
Laut Microsoft funktioniert die Harness mit mehr als 20 Frontier-Modellen plus Bring-your-own-Key. In der verwalteten Foundry-Version nutzen Agenten kompatible, über Foundry bereitgestellte Modelle; eigene Custom-Modelle werden dort laut The New Stack nicht unterstützt. Teams, die eigene Modelle oder Frameworks brauchen, können stattdessen Foundry Hosted Agents verwenden.
Welche Lock-in-Risiken gibt es?
Der Harness-Typ wird beim Anlegen eines Prompt-Agenten gewählt und lässt sich später nicht ändern, auch nicht in einer neuen Version; CPU-, Speicher- und Leerlaufgrenzen bestimmt Microsoft. Wer Skills, Anweisungen, Tool-Definitionen und Evaluierungen im eigenen Repository und hinter einer schlanken internen Schnittstelle hält, kann später mit vertretbarem Aufwand auf eine andere Laufzeit wechseln.
Sollten wir jetzt Agenten auf der Copilot-Harness bauen?
Sie eignet sich gut für Piloten, interne Tools und Azure-zentrierte Teams, die schnell eine regelkonforme Agenten-Laufzeit wollen. Für langlebige Produkte: in der kostenlosen Preview testen, Kosten pro abgeschlossener Aufgabe messen und mit einem selbst betriebenen Framework vergleichen, bevor Produktiv-Workloads festgelegt werden.
Quellen
The Official Microsoft Blog — Introducing the Microsoft Copilot harness (Primärquelle, 28. Oktober 2026)
The New Stack — Microsoft’s new Copilot harness makes agents easy, until you want to switch (Oktober 2026)
Visual Studio Magazine — Microsoft Opens GitHub-Built Copilot Harness to Developers Through Foundry (28. Oktober 2026)