Vom Topic-Baum zum Skill
Wenn du zwei Jahre Arbeit in Topics stecken hast, ist der neue Harness in Copilot Studio erst mal eine schlechte Nachricht. Nicht weil er schlechter wäre. Sondern weil sich das, was du gebaut hast, nicht mitnehmen lässt.
Diese Depesche ist der Leitfaden, den ich mir gewünscht hätte. Sie ist ein Nachschlagewerk, oben steht das Datum der letzten Prüfung.
Inhalt
Die eine Regel vorweg
Agents lassen sich zwischen den Harnesses nicht umziehen. Was im klassischen Erlebnis gebaut wurde, bleibt dort. Es gibt keinen Export, keinen Konverter und keinen Migrationsassistenten.
Das heißt nicht, dass du etwas tun musst. Bestehende Agents auf dem Standard harness laufen weiter, es gibt keinen angekündigten Abschalttermin. Es heißt aber, dass jede Entscheidung für den neuen Harness eine Neubau-Entscheidung ist, und die willst du bewusst treffen und nicht nebenbei.
Der Denkfehler, den ich zuerst gemacht habe
Mein erster Reflex war, Topics eins zu eins in Skills zu übersetzen. Ein Topic, ein Skill. Das funktioniert nicht, und zwar aus einem strukturellen Grund.
Ein Topic ist ein Ablauf: Trigger, Knoten, Verzweigungen, Variablen. Du hast ihn gezeichnet, also läuft er so. Ein Skill ist eine Anleitung: Name, Beschreibung, Anweisungen in Markdown. Die Orchestrierungs-Runtime lädt ihn, wenn die Anfrage zu seiner Beschreibung passt, und entscheidet dann selbst, wie sie ihn befolgt.
Wer einen Topic-Baum in Skills überführt, übersetzt eine Ablaufbeschreibung in eine Absichtsbeschreibung. Das ist keine Konvertierung, das ist eine Neuformulierung des Problems.
Die Sortierung, mit der ich anfange
Bevor irgendetwas geschrieben wird, sortiere ich jedes vorhandene Topic in einen von drei Töpfen.
Topf 1: Das muss deterministisch bleiben. Alles, wo der Ablauf selbst die Anforderung ist. Freigegebene Beratungssequenzen, regulierte Auskunftspflichten, alles mit vorgeschriebenem Wortlaut. Das gehört nicht in einen Skill, das gehört in einen Workflow oder bleibt auf dem Standard harness. Wenn der Satz "der Orchestrator hält sich meistens daran" bei euch nicht durchgeht, ist das Topic hier richtig.
Topf 2: Das ist eigentlich eine Aufgabe. Alles, wo der Ablauf nur die Krücke war, um eine Absicht abzubilden. Bestellstatus prüfen, Rechnung nachvollziehen, Urlaubsantrag einreichen. Diese Topics werden Skills, und meistens werden aus fünf Topics ein Skill, nicht fünf.
Topf 3: Das war ein Missverständnis. Topics, die es nur gibt, weil das Modell damals zu schwach war. Klassiker: dreißig Varianten von "das habe ich nicht verstanden", handgebaute Entitätserkennung, Umformulierungsketten. Die löschst du und ersetzt sie durch nichts.
Nach dieser Sortierung ist der Migrationsaufwand meist deutlich kleiner als befürchtet. Topf 3 ist bei jedem gewachsenen Bot der größte.
Wie aus Topf 2 ein Skill wird
Ein Skill besteht aus einem YAML front matter mit Name und Beschreibung und darunter aus Markdown-Anweisungen. Meine Reihenfolge beim Schreiben:
- Die Beschreibung zuerst. Sie ist keine Dokumentation, sie ist die Schnittstelle. Die Runtime entscheidet an ihr, ob der Skill geladen wird. Schreib hinein, wann der Skill greifen soll, in der Sprache, in der Nutzer ihr Anliegen formulieren. Nicht "Bestellprozess-Handler", sondern "Nutzen, wenn jemand nach dem Status, dem Verbleib oder der Änderung einer bestehenden Bestellung fragt."
- Das Vorgehen als nummerierte Schritte. Das ist die Stelle, an der dein Topic-Wissen tatsächlich wertvoll ist. Die Reihenfolge, die du dir mühsam erarbeitet hast, schreibst du jetzt als Prosa hin statt sie zu zeichnen.
- Die Abbruchbedingungen. Was der Skill nicht tun darf, wann er eskaliert, was passiert, wenn Daten fehlen. In Topics waren das Verzweigungen. Im Skill sind es Sätze, und sie müssen genauso explizit sein.
- Das Ausgabeformat. Wenn die Antwort eine bestimmte Struktur haben muss, beschreib sie. Sonst bekommst du bei jedem Lauf eine andere.
- Die Grenzen. Ein Absatz darüber, was der Skill ausdrücklich nicht bewertet und was im Zweifel gilt.
Was nicht in den Skill gehört: der Text der Antwort selbst. Wer feste Antworttexte in Skills schreibt, hat einen Topic-Baum in Markdown nachgebaut und alle Nachteile beider Welten.
Was mit den Bestandteilen passiert
| Im Topic-Modell | Im neuen Modell |
|---|---|
| Topic mit Trigger-Phrasen | Skill, gesteuert über die Beschreibung |
| Verzweigung nach Bedingung | Anweisung im Skill oder Bedingungsgruppe im Workflow |
| Variablen über den Dialog hinweg | Memory bzw. Kontext des Laufs |
| Aufruf einer Power-Automate-Flow-Aktion | Tool bzw. Workflow |
| Fest verdrahteter Antworttext | gehört in einen deterministischen Workflow, nicht in den Skill |
| Fallback-Topic | entfällt, der Orchestrator übernimmt |
| Wissensquelle | unverändert Knowledge, dazu Microsoft IQ |
Die Zeile, die am häufigsten unterschätzt wird, ist die mit den Variablen. Persistenter Kontext heißt in der neuen Welt Memory, wird pro Nutzer gespeichert und ist damit ein Governance-Thema, kein Implementierungsdetail. Kläre vor dem Einschalten, was gespeichert wird, wie lange, und wie eine Löschung funktioniert.
Die Migration in der Reihenfolge, die ich empfehle
- Inventur. Alle Agents, alle Topics, Besitzer, Nutzungszahlen. Ohne das arbeitest du im Dunkeln.
- Sortieren in die drei Töpfe. Das ist Kopfarbeit, keine Klickarbeit, und sie geht am besten zu zweit.
- Einen Kandidaten wählen, der weh tut, aber nicht kritisch ist. Nicht den einfachsten, sonst lernst du nichts, und nicht den kritischsten, sonst lernst du es teuer.
- Testfälle schreiben, bevor der erste Skill entsteht. Copilot Studio hat seit März GA-Werkzeuge für Evaluations, inklusive Multi-Turn-Tests. Aus den alten Topics lassen sich hervorragende Testfälle ableiten, denn jede Verzweigung war eine Erwartung.
- Skills schreiben, Beschreibung zuerst.
- Gegen die Testfälle laufen lassen. Der häufigste Befund ist nicht, dass der Skill schlecht ist, sondern dass er gar nicht erst geladen wird. Das ist immer ein Beschreibungsproblem.
- Parallelbetrieb. Alter Agent bleibt, neuer läuft auf einem Kanal oder für eine Nutzergruppe. Erst umschalten, wenn die Zahlen es hergeben.
- Erst dann den nächsten Kandidaten.
Zwei Dinge, die du einplanen musst
Kosten ab dem ersten Bauschritt. Der GitHub Copilot harness rechnet über Copilot Credits ab, sobald du anfängst zu bauen, nicht erst nach dem Publish. Eine Migration ist damit ein Kostenposten, kein Nebenprojekt. Setz Budgets pro Umgebung, bevor die Maker loslegen.
Doppelbetrieb über Monate. Du wirst eine Weile beide Welten pflegen. Das ist kein Zeichen schlechter Planung, das ist die Struktur der Sache. Plan es ein, statt es zu entdecken.
Der ehrliche Teil
Ich halte die Richtung für richtig. Topic-Bäume sind an derselben Stelle gescheitert wie regelbasierte Systeme immer scheitern: an der Vielfalt echter Anliegen. Ein Orchestrator, der ein Ziel selbst zerlegt, ist die bessere Antwort.
Was ich nicht weiß, ist die Instruction Adherence über lange Läufe unter Last. Das Preview-Fenster zwischen Juni und August war für eine Änderung dieser Größenordnung knapp, und Demos sind keine Produktion. Deshalb steht bei mir der Punkt mit den Testfällen vor dem Punkt mit den Skills, und deshalb bleibt Topf 1 vorerst da, wo er ist.
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
- What's new in Copilot Studio, Microsoft Learn, zu Memory, Bedingungsgruppen und Evaluations