Ihre Copilot Studio Agents im neuen Microsoft Copilot Harness
Microsoft Ignite bringt neue Features und einmal mehr ein neues UI und Setup für Copilot Studio. Was wird jetzt aus unseren Agents und aus all der Arbeit, die wir in sie gesteckt haben?
So fragen Teams, die ihre Agents in Microsoft Copilot Studio Stück für Stück gebaut haben. In diesen Agents stecken Topics, festgelegte Gesprächsabläufe mit Fragen und Bedingungen, dazu Agent Flows, die Daten aus anderen Systemen holen, Knowledge aus den eigenen Dokumenten und die Testfragen, an denen das Team jede Änderung prüft. Im Programm der Microsoft Ignite steht der neue Microsoft Copilot Harness in mehreren Sessions. Eine davon heißt „Pick the right harness to build your agents with using Copilot Studio“.
Auf die Frage, was mit bestehenden Agents in Produktion geschehen soll, antwortet Microsoft in der FAQ zum neuen Harness mit einem Wort: „Nothing.“ Standard Agents laufen weiter wie bisher, und der Standard Harness bleibt laut derselben FAQ voll unterstützt, einen erzwungenen Wechsel gibt es nicht. Microsofts Guidance zur Wahl des Harness hält fest, dass ein weiterer Harness für einen funktionierenden Standard Agent kein Grund zum Umzug ist.
Meine Erfahrung aus 30 Jahren in dieser Branche, mit Zertifizierungen in allen großen Microsoft Tech Stacks, ergänzt diese Guidance um einen Punkt: Microsoft wird das alte UI abschalten, zu einem Zeitpunkt, den es selbst festlegt. Oft kommt er für Kunden ungelegen, daher ist es besser, proaktiv zu handeln.
Der Aufbau des Microsoft Copilot Harness
Ein Harness ist die Runtime zwischen dem, was das Team in Copilot Studio gestaltet, und dem Modell, das es dafür wählt. Er entscheidet, wann das Modell gerufen wird, was es bekommt, wie seine Antwort gelesen wird und welche Tools laufen.
Öffnet das Team einen Agent im Microsoft Copilot Harness, sucht es dort zuerst seine Topics. Topics, die dem Agent einen Pfad vorgeben, den er Node für Node geht, gibt es im neuen Harness keine. Der Agent arbeitet im Agent Loop: Er plant, ruft Tools, prüft das Ergebnis und plant neu. Ein Run, ein Arbeitsgang des Agents, startet aus einer Chat Message, aus einem Trigger oder aus dem Agent Node eines Workflows, dem Schritt, mit dem ein fester Ablauf den Agent aufruft. Er endet in einer Antwort, einer erzeugten Datei oder einer Aktion, die der Agent über ein Tool ausgeführt hat.
Im Build Tab, der Arbeitsfläche des Agents, liegen Instructions, Knowledge, Tools, Skills, das Model, Connected Agents und Memory. Dort setzt das Team seine Instructions ein, die Anweisungen an den Agent, und fügt Websites, Dateien, SharePoint, Dataverse Tables und Graph Connectors als Knowledge hinzu, dieselben Arten von Quellen wie im Standard Agent. Als Tools bindet es Connectors, MCP Server und Workflows an, und unter Model wählt es das Modell des Agents. Know-how, das der Agent anwendet, legt das Team in Skills ab. Weitere Agents, die der Agent aufruft, verbindet es als Connected Agents. Memory hält fest, was eine Session überdauern soll.
Drei Teile liegen außerhalb des Build Tab. Hooks lassen Workflows an sechs festen Punkten des Agent Loops laufen, jedes Mal, wenn ihr Event eintritt. Triggers, in Preview, starten den Agent, wenn in einem verbundenen Dienst etwas geschieht, etwa wenn eine Mail eingeht. In der Agent Sandbox, einem gesicherten Container, den Copilot Studio verwaltet, führt der Agent Code aus. In diesen Teilen findet die Arbeit, die in den Topics und Agent Flows des Teams steckt, ihren neuen Platz.
Die Bausteine eines Standard Agents im Microsoft Copilot Harness
In einem Standard Agent stecken acht Arten von Bausteinen: Topics, dazu Entities und Variables, die Werte aus dem Gespräch erfassen und weitertragen, Power Fx, die Formelsprache für die Logik mit diesen Werten, Adaptive Cards als Formulare im Chat, Prompts für einzelne Aufgaben eines Modells, Agent Flows und Child Agents, die Subagents innerhalb eines Agents. Keiner dieser Bausteine zieht unter seinem Namen in den Microsoft Copilot Harness um. Was das Team dort für seine Topics, Agent Flows und Prompts findet, folgt aus dem Zweck jedes Bausteins.
Für die Topics lautet die Regel: Trägt ein Topic Know-how, das der Agent anwendet, wird es ein Skill. Führt es feste Schritte aus, wird es ein Workflow Tool: ein Workflow, den der Agent über seinen Namen und seine Description wählt. Muss es bei jedem Turn, also jeder Runde im Gespräch, oder bei jedem Tool Call geschehen, wird es ein Hook. System Topics wie Conversation Start und On Error werden Hooks auf Start (pre-loop) und Error.
Die Tabelle zeigt für alle acht Bausteine, was im Microsoft Copilot Harness an ihre Stelle tritt.
| Standard Agent | Microsoft Copilot Harness |
|---|---|
| Topics | Skill, Workflow Tool oder Hook |
| Entities | Workflow Inputs, die der Agent im Gespräch abfragt |
| Variables | Workflow Inputs und Outputs, Metadata eines Hooks, Memory |
| Power Fx | Branching und Data Steps im Workflow, Code Interpreter |
| Adaptive Cards | Kein Card Designer, der Agent bleibt Standard |
| Prompts | Skills und der Code Interpreter |
| Agent Flows | Workflows |
| Child Agents | Skills oder ein Connected Agent |
Seine Agent Flows baut das Team als Workflows neu, weil Agent Flows nicht konvertiert werden. Ein solcher Workflow beginnt mit When an agent calls the flow und endet mit Respond to the agent. Die Werte, die im Standard Agent Entities erfassen, erfragt der Agent im Gespräch und gibt sie als Workflow Inputs weiter. Custom Entities, die ein Team selbst definiert hat, unterstützt der neue Harness nicht. Die Logik aus Power Fx zieht in Branching und Data Steps eines Workflows oder in den Code Interpreter, mit dem der Agent in der Agent Sandbox exakt rechnet.
Für Adaptive Cards gibt es keinen Card Designer. Der Agent fragt Eingaben im Gespräch ab und zeigt Ergebnisse als formatierten Text oder als erzeugte Datei. In einem Workflow fragt der Schritt Request for information eine Person außerhalb des Chats. Ein Agent, der seine Adaptive Cards braucht, bleibt Standard. Deshalb betreibt ein Team oft beide Arten von Agents nebeneinander.
Für die Adaptive Card Lücke gibt es einen offenen Standard: Mit der MCP Apps Extension zeigt ein MCP Server sein eigenes UI direkt im Chat, und in Claude läuft damit seit kurzem eine ganze App im Gespräch . Ich wünsche mir, dass Microsoft die Extension bald in den Microsoft Copilot Harness übernimmt.
Der Migrationspfad für Standard Agents
Für die Migration eines Agents gibt es drei Routen. Alle drei lassen den Standard Agent des Teams unverändert und legen daneben einen neuen Agent an.
Das Upgrade, in Preview, beginnt auf der Home Page von Copilot Studio mit einer Anfrage wie upgrade my HR Agent und legt den neuen Agent als Card an, deren Name auf (Upgraded) endet. Es nimmt Instructions, Tools und die Suggested Prompts mit, die der Agent seinen Usern vorschlägt. Die Knowledge Sources fügt das Team im neuen Agent wieder hinzu, weil sie nie zum Upgrade gehören.
Beim Rebuild von Hand legt das Team einen neuen Agent mit dem Badge GitHub Copilot an und fügt jede Capability selbst hinzu. Diese Route kostet mehr Zeit und ist die Route, die Microsofts Guidance beschreibt. Das Team entscheidet dabei je Journey, also je Ablauf vom ersten Satz eines Users bis zum Ergebnis, was der neue Agent braucht.
Die dritte Route läuft im Terminal, aus Claude Code oder der GitHub Copilot CLI. Der Command /mcs-assistant:migrate legt den neuen Agent an, beschreibt den Standard Agent und legt einen Migrationsplan zur Freigabe vor; nach dem Approve baut er den neuen Agent und pusht ihn nach Copilot Studio. Das Plugin mcs-assistant kommt vom Microsoft Copilot Studio CAT Team und trägt den Status Work in Progress.
Am Ende laufen dieselben Journeys auf beiden Agents: in der Preview, der Testumgebung des neuen Agents, und im Test Pane des Standard Agents. Die Migration ist fertig, wenn der neue Agent seine Core Journeys besteht, die wichtigsten Journeys des Originals, belegt mit einem Test Set. Im Test Set stehen die Testfragen, an denen das Team jede Änderung prüft. Bis dahin bleibt der Standard Agent in Betrieb und beantwortet die Fragen der User wie gewohnt. Danach folgt der Cutover, der Wechsel der User auf den neuen Agent.
Der Migrationscheck für Copilot Studio Agents
Den Weg müssen Sie nicht allein gehen. Der Migrationscheck von integrations.at nimmt jeden Ihrer Agents auf und legt fest, ob er jetzt umzieht, wartet oder Standard bleibt, und welche Credits sein Betrieb im neuen Harness braucht. Grundlage ist die Purpose Map jedes Agents, mit seinen Aufgaben, dem Zweck seiner Topics und Flows und den Testfragen, an denen er sich messen lässt. Für jeden Agent, der umzieht, liegen Route und Test Set fest, bevor ein Credit in einen Rebuild fließt.
Begleitet wird der Check von Alexander Kastil. Er arbeitet mit Copilot Studio, seit es Copilot Studio gibt, und hat alle drei Routen selbst durchlaufen, vom Upgrade auf der Startseite bis zur Terminal-Route. Microsoft hat ihn als Agentic AI Business Solutions Architect und als AI Transformation Leader zertifiziert. Dazu kommen die Microsoft Applied Skills „Create agents in Microsoft Copilot Studio“ und „Enhance agents with autonomous capabilities“, alle nachprüfbar in seinem öffentlichen Transcript bei Microsoft Learn . Der Check beginnt mit einem kostenlosen Erstgespräch, das Sie auf der Seite Copilot Studio anfragen.
Der erste Schritt mit dem Microsoft Copilot Harness
Drei Schritte passen in diese Woche:
- Listen Sie Ihre Agents in Copilot Studio auf und notieren Sie zu jedem die Art. Ein Agent mit Seiten wie Topics in seiner Navigation ist ein Standard Agent; ein Agent im Microsoft Copilot Harness öffnet mit den Tabs Build, Preview, Evaluate und Monitor.
- Schreiben Sie zu jedem Agent eine Zeile: wofür er da ist und mit welchen Testfragen Ihr Team ihn prüft.
- Klären Sie mit Ihrer Administration, welches Environment (der Bereich der Power Platform, in dem Ihre Agents liegen) einen Billing Plan hat, über den Copilot Credits abgerechnet werden, und ob Stop usage für Ihre Agents eingeschaltet ist.
Mit diesen drei Listen beginnt der Migrationscheck. Für Teams, die ihre Agents selbst migrieren, gibt es die Schulung Business Processes mit Copilot Studio & Copilot Cowork automatisieren .
Entstehung des Artikels
Alexander Kastil hat diesen Artikel beauftragt und den Text abgenommen. Agents in Claude Code haben ihn aus seinem Material zu Copilot Studio geschrieben. Der Text entstand mit AI-Unterstützung.
