Copilot Harness in Foundry nimmt Ihnen den Agent-Loop ab

Bauen Sie auf dem Copilot Harness, wenn Ihr Agent vor allem Dateien, Shell, Web und Subagenten braucht und Sie Standardverhalten akzeptieren. Behalten Sie eigene Logik, wenn Sie Modellparameter, eigene Modelle oder Foundry Memory benötigen. Der Harness ist laut Microsoft Learn eine Preview und steuert Parameter wie temperature oder max_output_tokens selbst; eigene Modelle (BYOM) und Foundry Memory werden nicht unterstützt. Sie tauschen also Bauaufwand gegen Kontrolle, und dieser Tausch lohnt sich nur bei passendem Anwendungsfall.

Was Microsoft unter dem Harness versteht

Nach Angaben von Microsoft treibt der Copilot Harness Copilot Code, Copilot Studio, die GitHub-Copilot-App, die CLI, VS Code und weitere Produkte an. Am 28.10.2026 kündigte Microsoft in einem Blogbeitrag von Tina Schuchman (CVP Foundry) und Vladimir Fedorov (CTO GitHub) an, diesen Harness über Microsoft Foundry verfügbar zu machen.

Den Begriff erklären die beiden im Blog so: Wenn das Modell die Intelligenz liefert, ist der Harness alles um das Modell herum. Gemeint ist die Laufschleife, die Modellaufrufe, Werkzeugnutzung, Dateizugriffe und Zwischenergebnisse zu einem Ablauf verbindet. Genau diesen Teil bauen Teams bisher meist selbst, oft mit viel Fehlerbehandlung.

Zur Modellseite nennt Microsoft im Blog „20+ frontier models plus bring your own key“. Das ist eine Herstelleraussage und bedeutet, dass Sie mit eigenem Schlüssel (BYOK) auf Modelle zugreifen können. Es bedeutet nicht, dass Sie ein eigenes Modell mitbringen dürfen. Das ist BYOM, und dazu sagt die Dokumentation klar: nicht unterstützt. Die Dokumentation verlangt zudem Modelle, die Reasoning und Tool Calling beherrschen.

Als offene Standards nennt Microsoft MCP (Model Context Protocol, eine Schnittstelle, über die Agenten externe Werkzeuge ansprechen), Agent Skills sowie Agent Plugins. Wer bereits MCP-Server betreibt, muss sie also nicht neu schreiben. Außerdem berichtet Microsoft, die Runtime des Harness kürzlich nach Rust portiert zu haben. Microsoft spricht von geringerem Session-Overhead und kürzerer Zeit bis zum ersten Token, nennt aber keine Messwerte; den Nutzen können Sie deshalb nicht beziffern.

Wichtig für die Einordnung: Die Learn-Seite kennzeichnet den Harness mit „(preview)“. Preise und einen Termin für die allgemeine Verfügbarkeit nennt Microsoft bislang nicht, unabhängige Tests liegen ebenfalls nicht vor. Für Produktivsysteme mit festen Zusagen ist das eine dünne Grundlage, für Pilotprojekte reicht sie.

Wer lokale oder hybride Szenarien plant, findet im Beitrag zu Foundry Local und Azure Local für KI-Agenten eine andere Betriebsart. Der Harness läuft dagegen als Dienst in ausgewählten Azure-Regionen.

Welche Bausteine fertig mitkommen

Laut Microsoft Learn bringt der Harness fünf eingebaute Fähigkeiten mit: Datei lesen, Datei schreiben, Shell, Web und Subagenten. Sie sind standardmäßig aktiviert, unterliegen aber Dienst- und Organisationsrichtlinien. Ihre IT kann sie also über Richtlinien einschränken, statt Code anzupassen.

Für Aufgaben wie Recherche, Dokumentenaufbereitung oder Skriptausführung spart das Wochen an Vorarbeit. Jede dieser Fähigkeiten ist sonst eine eigene Baustelle mit Rechten, Timeouts und Protokollierung. Subagenten erlauben, Teilaufgaben an eigene Agenten abzugeben, etwa Recherche und Auswertung getrennt zu halten.

Skills sind wiederverwendbare Fähigkeitsbeschreibungen. Die Dokumentation erlaubt bis zu 50 Skill-Referenzen auf oberster Ebene. Für die meisten Fachagenten genügt das reichlich. Wer jedoch eine große Skill-Bibliothek zentral pflegen will, muss sie auf diese Grenze zuschneiden oder auf mehrere Agenten verteilen.

Ein hypothetisches Beispiel: Ein Agent soll eine Lieferantenliste prüfen. Er liest die Datei ein, startet über die Shell ein kleines Skript zur Bereinigung, holt über die Web-Fähigkeit aktuelle Angaben und schreibt das Ergebnis zurück. Die Gegenprüfung einzelner Einträge übernimmt ein Subagent. Alle fünf Built-ins greifen hier ineinander, und Sie müssten dafür keine eigene Werkzeuganbindung bauen.

Weil die Built-ins nur „vorbehaltlich Dienst- und Organisationsrichtlinien“ aktiv sind, ist ihre Verfügbarkeit keine Gewissheit. Meine Einordnung: Klären Sie vorab mit Ihrer IT, welche Fähigkeiten freigegeben sind, und testen Sie den Agenten auch mit eingeschränkter Shell oder ohne Web. Bei Skills gelten feste Regeln. Namen müssen eindeutig sein, dürfen nur Kleinbuchstaben, Ziffern und Bindestriche enthalten und höchstens 64 Zeichen lang sein. Jede Referenz zeigt auf eine feste, unveränderliche Version. Das schafft Nachvollziehbarkeit, verlangt aber ein bewusstes Versionieren, wenn ein Skill angepasst wird.

Der Arbeitsbereich ist pro Konversation getrennt. Der Zustand überlebt laut Dokumentation normale Leerlaufphasen der Sandbox, Wiederaufnahme und Austausch. Wichtige Ergebnisse sollen Sie dennoch in Foundry Files oder einem anderen dauerhaften Dienst ablegen. Als Ablage über Konversationen hinweg taugt der Workspace also nicht.

Die Ausführungs-Sandbox ist servicegemanagt: Foundry übernimmt Zuteilung, Ruhezustand, Wiederaufnahme und Austausch, ohne dass die Konversation unterbrochen wird. CPU, Arbeitsspeicher und Lebenszyklus sind nicht konfigurierbar. Das entlastet den Betrieb, nimmt aber die Möglichkeit, rechenintensive Aufträge gezielt auszustatten oder Laufzeiten zu begrenzen.

Für die Praxis heißt das: Der Harness deckt die Infrastruktur eines typischen Agenten ab, der mit Dateien und Befehlen arbeitet. Er deckt nicht ab, was Ihr Unternehmen eigentlich unterscheidet, nämlich Ihre Fachlogik, Ihre Skills und Ihre Anbindungen. Prüfen Sie vor dem Start, welcher Anteil Ihres bisherigen Codes reine Schleifen-Mechanik ist. Nur dieser Anteil entfällt.

Bei der Berechtigungsfrage lohnt ein Blick auf Governance für Agent-Konten in Copilot Studio, denn auch ein Harness-Agent braucht eine klare Identität und begrenzte Rechte, sobald er Shell und Web nutzt.

Wo die Kontrolle beim Dienst liegt

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptAbstract visualization of a circular agent loop: glowing nodes connected in a ring around a central core, tools as small icons-like shapes, dark blue background, clean tech illustration style. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Die gewichtigste Einschränkung steht in den Dokumentationsabschnitten zu harness-managed Einstellungen. In der Agent-Definition sollen Sie temperature, top_p, tool_choice, text.format und text.verbosity nicht angeben. Bei einzelnen Anfragen gilt dasselbe für max_output_tokens, max_tool_calls, parallel_tool_calls, truncation, context_management, service_tier und user. Hinzu kommen weitere Felder wie top_logprobs, safety_identifier, prompt_cache_key und prompt_cache_retention.

Nicht setzbar heißt hier: Der Dienst entscheidet. Ein Agent, der bisher mit niedriger temperature für reproduzierbare Antworten lief, lässt sich also nicht einfach übertragen. Ebenso entfällt eine harte Obergrenze für Werkzeugaufrufe pro Anfrage über max_tool_calls, die viele Teams als Kostenbremse nutzen.

Das ist keine Kleinigkeit. Wer Ausgabelängen, Werkzeugschleifen und Kontextkürzung selbst begrenzt, hat damit auch Kosten und Laufzeit im Griff. Beim Harness müssen Sie diese Grenzen an anderer Stelle ziehen, etwa über Budgetwächter außerhalb des Agenten. Ob und wie der Dienst intern Grenzen setzt, dokumentiert Microsoft nicht.

Bei Function-Tools akzeptiert der Harness nur nicht strikte Schemas; strict: true wird nicht unterstützt. Strikte Schemas erzwingen, dass Modellaufrufe exakt zu Ihrer Funktionssignatur passen. Ohne sie müssen Sie Parameter selbst validieren, bevor ein Aufruf in ein Fachsystem läuft. Das ist machbar, gehört aber in Ihre Aufwandsschätzung.

Zwei weitere Grenzen betreffen Ihre Architektur. Eigene Modelle (BYOM) sind nicht unterstützt, wer ein feinabgestimmtes Hausmodell einsetzt, scheidet aus. Und Foundry Memory ist nicht verfügbar: Weder Speicher noch Memory-Werkzeuge stehen bereit. Laut Dokumentation bleiben Konversationsverlauf und Dateien im Harness-Workspace davon unberührt. Langzeitgedächtnis über Sitzungen hinweg müssen Sie also selbst lösen.

Für die Migration bestehender Agenten ergibt sich daraus eine konkrete Aufgabenliste. Zuerst entfernen Sie aus Agent-Definition und Anfragen alle Felder, die der Dienst selbst steuert. Danach setzen Sie strict-Schemas in Function-Tools auf nicht strikt um und verlagern die Prüfung der Parameter in den Funktionscode. Schließlich ersetzen Sie Foundry Memory durch eine externe Ablage, etwa Foundry Files oder einen anderen dauerhaften Dienst. dm-Einordnung: Planen Sie für jeden dieser Schritte eigene Tests ein, besonders für Antworten, die bisher von einer festen temperature abhingen.

Als Gegenstück zu den fehlenden Stellschrauben gibt es Netzwerk-Egress-Kontrollen, derzeit in der Preview. Mit ihnen lenken Sie den Datenverkehr der Ausführungsumgebung des Harness. Dazu hängen Sie eine RAI-Policy mit Network rules an. So begrenzen Sie, wohin Shell und Web-Fähigkeit überhaupt Verbindungen aufbauen dürfen.

dm-Einordnung: Für Unternehmen ist das der wichtigere Hebel als ein Token-Limit. Ein Agent mit Shell und Web kann Daten nur dorthin senden, wohin das Netz ihn lässt. Da die Funktion noch Preview ist, sollten Sie sie in einer Testumgebung prüfen, bevor Sie sich in der Produktion darauf verlassen.

Meine Einordnung: Diese Liste ist kein Mangel an sich, sondern der Preis eines verwalteten Dienstes. Kritisch wird sie, wenn Ihre Anforderungen Reproduzierbarkeit, Kostendeckel oder Hausmodelle enthalten. Dann ist die Frage nicht, ob der Harness gut ist, sondern ob er überhaupt zulässig ist. Prüfen Sie diese drei Punkte, bevor Sie einen Prototyp bauen.

Regionen und Entscheidung

Der Harness ist laut Microsoft Learn nur in einem Teil der Regionen verfügbar, die Prompt-Agenten unterstützen. Gelistet sind neun: Australia East, Canada Central, Central US, Germany West Central, Japan East, Sweden Central, UK South, West Europe und West US. Für europäische Unternehmen sind Germany West Central (Frankfurt), West Europe und Sweden Central relevant.

Wenn Ihre Daten in Deutschland verarbeitet werden sollen, gibt es mit Germany West Central eine Option. Ob Dateien, Sandbox und Konversationsdaten dort vollständig verbleiben, geht aus der Dokumentation nicht hervor. Klären Sie das mit Ihrer Datenschutzstelle, bevor Sie personenbezogene Daten einsetzen.

Daraus ergibt sich eine pragmatische Entscheidungshilfe, die meine Einschätzung ist und kein Herstellerbeleg. Der Harness passt, wenn der Agent hauptsächlich Dateien bearbeitet, Befehle ausführt, im Web recherchiert oder Teilaufgaben delegiert, wenn Standardparameter genügen und Sie ohnehin ein Modell aus dem angebotenen Katalog nutzen. Dann sparen Sie die Schleife, die Sandbox und deren Betrieb.

Eigene Logik behalten Sie besser, wenn mindestens eines davon zutrifft: Sie brauchen feste Sampling-Parameter oder harte Aufrufgrenzen, ein eigenes Modell, strikte Funktionsschemas oder Foundry Memory. Auch wer Sandbox-Ressourcen festlegen muss, stößt an die Grenze, denn CPU, Arbeitsspeicher und Lebenszyklus sind nicht konfigurierbar.

Ein dritter Weg ist ein begrenzter Pilot. Wählen Sie einen Anwendungsfall mit geringem Risiko, etwa interne Recherche oder Dokumentenaufbereitung, und messen Sie Aufwand, Laufzeit und Ergebnisqualität gegen Ihre bestehende Lösung. Solange die Learn-Seite „preview“ ausweist und keine Preise oder Verfügbarkeitstermine vorliegen, taugt das als belastbare Methode, ohne Ihre Architektur festzulegen.

Halten Sie Ihre Fachlogik dabei sauber getrennt: Skills, MCP-Anbindungen und Funktionsschemas sollten sich auch außerhalb des Harness nutzen lassen. Wenn sich Bedingungen ändern, wechseln Sie dann den Unterbau statt den ganzen Agenten. Genau darin liegt der Wert der offenen Standards, die Microsoft nennt, sofern Sie sie konsequent einsetzen.

Dokumentieren Sie schließlich, welche der gesperrten Parameter Ihre Compliance-Regeln berühren. Wenn ein Prüfer reproduzierbares Verhalten verlangt und der Dienst die temperature selbst festlegt, sollte das vor dem Produktivbetrieb auffallen und nicht danach.