Copilot Studio hat den Motor getauscht
This article is not available in English yet.
Wenn du gerade copilotstudio.microsoft.com öffnest, landest du in einer Oberfläche, die du so wahrscheinlich nicht kennst. Ein anderes linkes Menü, ein anderer Aufbau, Workflows statt Flows. Das ist nicht kosmetisch. Darunter läuft eine andere Runtime, und seit dem 3. August 2026 ist sie generally available.
Inhalt
Was ein Harness ist
Der Begriff ist neu in Copilot Studio, und Microsoft definiert ihn ungewöhnlich präzise. Ein Harness ist die Runtime zwischen dem, was du entwirfst, und dem Modell, das die Reasoning-Arbeit macht. Er entscheidet, wann das Modell aufgerufen wird, welche Komponenten dabei mitgeschickt werden, wie die Antwort interpretiert wird und welches Tool als nächstes dran ist.
Das ist der Teil, den man in Demos nie sieht und der trotzdem darüber entscheidet, ob ein Agent einen mehrstufigen Prozess durchhält oder nach dem dritten Schritt aus der Spur läuft.
Copilot Studio hat davon jetzt drei.
Drei Harnesses, drei Abrechnungen
| GitHub Copilot harness | Standard harness | Copilot chat harness | |
|---|---|---|---|
| Gedacht für | komplexe, mehrstufige Geschäftsprozesse | regelbasierte Agents, strukturierte Dialoge | Erweiterung von Microsoft 365 Copilot Chat |
| Arbeitsweise | zerlegt ein Ziel selbst in Schritte | folgt den Topics und Regeln, die du definierst | verbindet Unternehmenswissen mit M365 Copilot Chat |
| Fehlerfall | versucht es erneut, sucht alternative Wege | folgt den Pfaden, die du gebaut hast | kein Schwerpunkt |
| Dateien | erstellt und bearbeitet Word, Excel, PowerPoint, PDF | kein Schwerpunkt | kein Schwerpunkt |
| Skills und Memory | ja | kein Schwerpunkt | kein Schwerpunkt |
| Abrechnung | Copilot Credits, verbrauchsbasiert | Lizenzmodell wie bisher | Verbrauch oder in der M365-Copilot-Lizenz enthalten |
Der interessante Teil steht in der letzten Zeile. Beim Standard harness beginnt die Abrechnung nach dem Publish. Beim GitHub Copilot harness ab dem Moment, in dem du anfängst zu bauen. Prototyping, Testen im Preview-Panel, das Generieren von Evaluations: alles verbraucht Credits. Dazu schreibe ich eine eigene Depesche, weil eine Tabelle dafür nicht reicht.
Skills lösen Topics ab
Die zweite große Änderung betrifft die Art, wie du einem Agent beibringst, was er tun soll.
Ein Skill ist eine Fähigkeit aus Name, Beschreibung und einem Satz Anweisungen in Markdown. Die Orchestrierungs-Runtime lädt den Skill, wenn die Anfrage zu seiner Beschreibung passt. Skills sind wiederverwendbar über mehrere Agents hinweg und lassen sich als Markdown-Datei oder als ZIP-Paket exportieren.
Wer bisher Topics gebaut hat, muss umdenken. Ein Topic ist ein Ablauf, den du gezeichnet hast: Trigger, Verzweigungen, Knoten, deterministisch. Ein Skill ist eine Anleitung, die der Orchestrator liest und dann selbst entscheidet, wie er sie befolgt.
Für die meisten Szenarien ist das ein Gewinn. Der Unterschied zwischen "Wo ist meine Bestellung" und "Warum ist meine Bestellung von letzter Woche immer noch nicht da, ich hatte doch Express gebucht" hat Topic-Bäume jahrelang zerlegt. Genau daran ist ein Orchestrator besser.
Für streng regulierte Dialogpfade ist es ein Risiko. Wenn eine Beratungssequenz aus rechtlichen Gründen exakt so ablaufen muss, wie sie freigegeben wurde, dann ist "der Orchestrator hält sich meistens an die Anweisung" keine akzeptable Aussage. Hier gehört der Standard harness hin, oder ein deterministischer Workflow neben dem Agent.
Das ist die Linie, die du ziehen musst: Der Agent übernimmt das Urteil, der Workflow übernimmt das, was jedes Mal identisch ablaufen muss. Wo genau die Linie liegt, entscheidest du. Dass sie existieren muss, entscheidet nicht mehr das Produkt für dich.
Der Haken, über den kaum jemand spricht
Agents lassen sich zwischen den Harnesses nicht umziehen. Was im klassischen Erlebnis gebaut wurde, bleibt dort. Was du im neuen baust, bleibt dort.
Das klingt nach einem Detail und ist der wichtigste Satz für deine Planung. Wenn du eine gewachsene Copilot-Studio-Landschaft hast, mit Topics, autonomen Triggern und Publishing auf Kanäle jenseits von Teams, dann ist der Wechsel kein Umschalten, sondern ein Neubau. Bestehende Agents laufen weiter, es gibt keinen Stichtag, an dem etwas abgeschaltet wird. Aber jede neue Fähigkeit der Plattform, Skills, Memory, das native Arbeiten mit Dateien, hängt am neuen Harness.
Praktisch heißt das: Du wirst eine Weile beide Welten betreiben. Plane das ein, statt es zu entdecken.
Was noch dazugehört
Zwei Dinge, die im selben Zeitraum gelandet sind und die Entscheidung beeinflussen.
Microsoft IQ verbindet Agents im neuen Erlebnis mit Organisationsdaten: E-Mails, Kalendereinträge, Dateien, Teams-Nachrichten, Personeninformationen. Das ist der Kontext, dessen Fehlen bisher der häufigste Grund war, warum ein Agent im Test überzeugte und im Alltag enttäuschte.
Memory gibt dem Agent persistenten Kontext über Interaktionen hinweg, gespeichert pro Nutzer. Das ist mächtig und governance-relevant. Bevor du es einschaltest, solltest du beantworten können, was dort gespeichert wird, wie lange, und was passiert, wenn jemand die Löschung seiner Daten verlangt.
Dazu kommt die Modellauswahl: Claude Sonnet 5 und GPT-5.5 Chat sind als primäre Modelle generally available. Dass die Modellwahl inzwischen ein Konfigurationsfeld ist, war vor zwei Jahren undenkbar.
Meine Einschätzung
Die Richtung stimmt. Ein Orchestrator, der ein Ziel selbst zerlegt, löst genau die Probleme, an denen Topic-basierte Bots seit Jahren scheitern. Und dass Microsoft die Copilot-Studio-Agents auf dieselbe Harness-Linie stellt wie den GitHub-Copilot-Coding-Agent, ist strategisch konsequent.
Zwei Vorbehalte behalte ich.
Der erste ist die Instruction Adherence über lange Läufe. Genau dort driften Agents ab, und das Preview-Fenster zwischen Juni und August war für eine Änderung dieser Größenordnung kurz. Wenn du auf den neuen Harness gehst, investiere die gesparte Bauzeit in Evaluations. Copilot Studio hat dafür seit März GA-Werkzeuge, inklusive Multi-Turn-Tests. Nutze sie, bevor du in Produktion gehst, nicht danach.
Der zweite ist kommerziell. Die Umstellung auf Copilot Credits ab dem ersten Bauschritt verändert, wie sich Experimentieren anfühlt. Ein Maker, der drei Nachmittage lang Varianten ausprobiert, erzeugt jetzt eine Rechnung. Das ist verkraftbar, wenn es jemand vorher weiß. Es ist ein Vertrauensbruch, wenn es die Fachabteilung im Nachhinein aus dem Power Platform Admin Center erfährt.
Was ich empfehlen würde
- Bestandsagents nicht anfassen. Sie laufen, sie sind bezahlt, sie machen ihren Job.
- Für den nächsten Neubau mit echtem Prozesscharakter den GitHub Copilot harness wählen. Rechnungseingang, Vertragsprüfung, alles mit mehreren Systemen und Ausnahmen.
- Vor dem ersten Maker-Zugang das Kostenmodell verstanden haben und Budgets im Power Platform Admin Center gesetzt haben.
- Streng geskriptete Dialoge auf dem Standard harness lassen und die Entscheidung dokumentieren, damit sie in einem Jahr niemand für Bequemlichkeit hält.
- Eine Inventur machen. Welche Agents laufen auf welchem Harness, wer besitzt sie, was kosten sie. Diese Tabelle brauchst du spätestens beim nächsten Audit.
Quellen
- Choose a harness, Microsoft Learn, Stand 3. August 2026
- Skills overview for agents, Microsoft Learn, Stand 3. August 2026
- Overview of billing for agents powered by the GitHub Copilot harness, Microsoft Learn, Stand 3. August 2026
- What's new in Copilot Studio, Microsoft Learn
- Copilot Studio Harnesses: Understanding the GitHub Copilot Harness, Rajeev Pentyala, 5. August 2026