Start / Seminare / Microsoft Copilot Studio in der Praxis

Modul

Copilot Studio im Microsoft-Ökosystem

Modul 1 von 11 aus dem Seminar Microsoft Copilot Studio in der Praxis

5 Kapitel in diesem Modul-Video · Laufzeit

Für Teams

Die Videos zeigen, wie es geht. Die Schulung sorgt dafür, dass Ihr Team es danach tut.

Ein Video kann niemanden fragen, warum es ausgerechnet in Ihrem Repository nicht funktioniert. Es kann kein Team auf eine gemeinsame Konvention bringen. Und es setzt sich niemand freiwillig drei Tage hin. In der Schulung sind am Ende alle auf demselben Stand, gearbeitet wurde am eigenen Code, und die offenen Fragen sind entschieden — in ein paar Tagen statt irgendwann nebenbei.

Vorgespräch am Telefon · Programm nach Maß · ab 1 Tag (8 Unterrichtseinheiten) · Teilnahmezertifikat

Schulung anfragen So läuft eine Schulung ab

Vertonung mit synthetischer Stimme · Inhalte redaktionell verantwortet · © 2026 HECKER CONSULTING, alle Rechte vorbehalten

Transkript

Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.

Copilot Studio im Microsoft-Ökosystem

0:00 Agenten zu bauen ist heute erstaunlich einfach geworden. Man beschreibt in ein paar Sätzen, was das Ding können soll, hängt ein paar Dokumente dran — und es antwortet. Genau darin liegt die Falle. Denn die Fragen, die über Erfolg oder Ärger entscheiden, stellt einem niemand von selbst: Wer darf der Agent sein? Was sieht er? Was darf er verändern?

0:21 Und was kostet das am Monatsende? In diesem ersten Modul sortieren wir das Feld. Wir schauen uns an, was Copilot Studio überhaupt anbietet, und treffen die eine Entscheidung, die alles Weitere bestimmt — die Wahl der Laufzeitumgebung.

Copilot Studio im Microsoft-Ökosystem

0:36 Der erste Tag beginnt bewusst nicht im Werkzeug, sondern davor. Wir klären, was Agents, Workflows und Microsoft 365 Copilot voneinander unterscheidet, wie man die passende Laufzeitumgebung auswählt und was ein Anwendungsfall eigentlich verlangt — eine Auskunft, ein geführtes Gespräch oder eine echte Aktion im Fachsystem.

0:54 Zum Schluss sehen wir uns an, was im Microsoft-Tenant stehen muss, bevor die erste Übung überhaupt laufen kann. Danach ordnen Sie einen eigenen Anwendungsfall ein.

Agents, Workflows und Microsoft 365 Copilot

1:04 Beginnen wir mit den Begriffen. Das klingt nach Pflichtübung, ist aber der häufigste Grund für Missverständnisse in solchen Projekten: Drei Leute sagen Agent und meinen drei verschiedene Dinge. Stellen Sie sich einen Empfangstresen in einem großen Haus vor. Der Agent ist die Person dahinter: Sie kennt die Hausordnung, schlägt bei Bedarf nach und entscheidet, wen sie wohin schickt.

1:26 Der Workflow ist der festgelegte Geschäftsgang im Hintergrund — Antrag geht ein, wird geprüft, wird weitergereicht. Und der Agent Flow ist der einzelne Handgriff: einen Vorgang nachschlagen, einen Datensatz anlegen, immer gleich. Copilot Studio bringt alle drei mit, und sie dürfen sich gegenseitig aufrufen. Wichtig ist nur, dass Sie wissen, welcher Baustein gerade gemeint ist — denn sie verhalten sich grundverschieden.

1:52 Hinter dieser Aufstellung steckt ein einziges Unterscheidungsmerkmal: Entscheidet der Baustein, oder führt er aus? Der Agent entscheidet — er wählt aus, was er nutzt, und formuliert selbst. Der Agent Flow führt aus: gleiche Eingabe, gleiche Ausgabe, jedes Mal. Der Workflow liegt dazwischen, er automatisiert den Ablauf und darf einzelne Schritte an einen Agenten geben.

2:14 Merken Sie sich vor allem die letzte Zeile: Nur ein Flow mit dem Auslöser für den Agentenaufruf lässt sich später als Werkzeug anhängen. Ohne diesen Auslöser steht der Flow für sich allein. Warum lohnt sich diese Sortierarbeit? Weil die meisten misslungenen Projekte an genau einer Stelle kippen: Prozesslogik landet im Gespräch.

2:34 Dann steht in zwanzig Dialogschritten, was eigentlich ein Flow in fünf Aktionen erledigt — und jede Änderung wird zur Bastelei. Umgekehrt gilt dasselbe: Wer alles in Flows presst, verschenkt genau das, was diese Technik besonders macht, nämlich den Umgang mit natürlicher Sprache. Mein Rat: Trennen Sie früh, was entschieden wird, von dem, was ausgeführt wird. Diese Trennung hält später jede Erweiterung aus.

2:59 Diese vier Punkte begegnen einem in fast jedem Projekt. Besonders hartnäckig ist der erste: Agent Flow und Power-Automate-Cloud-Flow sehen sich ähnlich, sie rechnen aber unterschiedlich ab — und eine Umwandlung ist nicht umkehrbar. Der zweite Punkt klingt harmlos, kostet aber Wochen: Wenn der Begriff Agent für alles herhält, reden Fachbereich und IT aneinander vorbei, ohne es zu merken.

3:21 Und der letzte Punkt ist typisch für neue Technik — man probiert erst eine Variante aus und erwägt die Kombination erst, wenn es klemmt. Besser: gleich fragen, welcher Baustein die Aufgabe eigentlich trägt.

Harness auswählen

3:34 Jetzt zu der Entscheidung, die man später kaum noch korrigiert — und die trotzdem oft nebenbei fällt: auf welcher Laufzeitumgebung das Ganze läuft. Der Harness ist so etwas wie das Getriebe zwischen Ihnen und dem Sprachmodell. Sie entwerfen, das Modell formuliert — aber dazwischen entscheidet jemand, wann das Modell überhaupt gefragt wird, was es zu sehen bekommt und welches Werkzeug daraufhin anläuft.

3:57 Genau das macht der Harness. Copilot Studio bietet drei davon an, und sie unterscheiden sich nicht in Nuancen: Funktionsumfang, mögliche Kanäle und Abrechnung hängen daran. Das Seminar arbeitet praktisch mit dem Standard-Harness. Die anderen beiden ordnen wir ein, damit Sie wissen, wann sie die bessere Wahl wären. Die Schichtung zeigt, warum diese Entscheidung so weit trägt. Oben steht Ihr Entwurf — Anweisungen, Wissen, Topics, Werkzeuge.

4:24 Ganz unten steht das Modell, das Sprache versteht und erzeugt. Beides ist austauschbar. Die Schicht dazwischen aber bestimmt das tatsächliche Verhalten, und sie zieht die unterste Ebene gleich mit: Abrechnung und Kanäle hängen am Harness, nicht an Ihrem Entwurf. Deshalb lässt sich ein Agent später nicht einfach umhängen. Man baut ihn im Kern neu.

4:46 Lesen Sie diese Tabelle nicht als Bestenliste. Die erste Spalte ist die mächtigste, aber Mächtigkeit ist hier kein Ziel, sondern eine Eigenschaft mit Preis. Der GitHub-Copilot-Harness zerlegt ein Ziel selbstständig in Schritte, arbeitet mit Dateien und sucht bei Fehlern eigene Wege — großartig für einen Rechnungsprozess, unpassend für eine Auskunft, die jedes Mal gleich lauten soll.

5:08 Der Standard-Harness ist vorhersehbar, und genau das wollen Sie bei verbindlichen Vorgängen. Der Copilot-Chat-Harness bringt Unternehmenswissen dorthin, wo die Leute ohnehin arbeiten — veröffentlicht aber nur intern. Eine Warnung noch: Der GitHub-Copilot-Harness ist ein Framework in Copilot Studio, nicht der Dienst GitHub Copilot.

5:28 Diese fünf Schritte haben einen gemeinsamen Zweck: Sie sollen die Entscheidung aus der Anforderung heraus treffen, nicht aus dem Bauch. Deshalb steht am Anfang der Vorgang selbst, aufgeschrieben in normalen Sätzen. Dann kommen drei Prüffragen, die jeweils eine Spalte der Tabelle abfragen — Mehrstufigkeit, Dateien, Zielgruppe. Und erst danach fällt die Wahl.

5:48 Der letzte Schritt wirkt bürokratisch, ist aber der wichtigste: Schreiben Sie die Begründung auf. In sechs Monaten fragt jemand, warum das so gebaut wurde, und dann sollte die Antwort nicht lauten: weiß keiner mehr. Der erste Punkt ist der verbreitetste: Man wählt nach dem Namen. GitHub Copilot klingt vertraut, also nimmt man das — und wundert sich über die Rechnung.

6:10 Der zweite hängt direkt daran, die Verwechslung mit dem gleichnamigen Dienst. Besonders ärgerlich ist der dritte Punkt: Wer den Copilot-Chat-Harness für einen Agenten plant, den auch Kundschaft erreichen soll, merkt das erst beim Veröffentlichen. Denn der veröffentlicht nur intern. Prüfen Sie die Abrechnungsunterschiede vorher — nicht, weil sie kompliziert wären, sondern weil sie sonst niemand prüft.

Wissensantwort, Dialog oder Aktion

6:34 Kommen wir zur Frage, die vor jedem Agentenprojekt steht und trotzdem meistens übersprungen wird: Was soll das Ding eigentlich tun? Drei Ansprüche, und sie unterscheiden sich stärker, als es zunächst aussieht. Eine Wissensantwort formuliert aus Dokumenten — sie sagt etwas. Ein geführter Dialog nimmt etwas auf, Schritt für Schritt, mit Prüfung. Und eine Aktion verändert etwas in einem anderen System.

6:58 Vom ersten zum dritten Fall steigt nicht nur der Bauaufwand, sondern vor allem der Aufwand danach: Berechtigungen, Bestätigungen, Fehlerfälle, Freigaben. Wer diese Frage überspringt, baut zuverlässig an der falschen Stelle — und merkt es erst, wenn die ersten echten Nutzer kommen. Die Kette macht sichtbar, was ich meine: Das ist keine Auswahl aus drei gleichwertigen Optionen, sondern eine Steigerung. Jede Stufe enthält die vorherige und legt etwas drauf.

7:26 Der geführte Dialog braucht alles, was die Wissensantwort braucht — und zusätzlich Eingabeprüfung und einen Weg zum Menschen. Die Aktion braucht beides und obendrein Rechte, Bestätigung und einen geplanten Fehlerfall. Deshalb lautet die ehrliche Projektfrage nicht: Was wäre schön? Sondern: Welche Stufe sind wir bereit zu tragen?

7:46 Der Aufwand wandert, je nachdem wie Sie die Frage beantworten. Bei einer Wissensantwort steckt die Arbeit in den Dokumenten — jemand muss sie pflegen, und das ist eine Daueraufgabe, keine Projektaufgabe. Beim Dialog steckt sie im Entwurf des Gesprächs. Bei der Aktion steckt sie in Rechten und Absicherung. Drei völlig verschiedene Baustellen mit drei verschiedenen Beteiligten.

8:08 Wer die Frage nicht am Anfang klärt, beschäftigt die falschen Leute und stellt die richtigen zu spät frei. Jetzt sind Sie dran. Nehmen Sie drei Anwendungsfälle und ordnen Sie jeden einer der drei Antwortarten zu. Es geht ausdrücklich nicht darum, die Lösung zu entwerfen — sondern darum, den Preis zu benennen: Welche Daten braucht der Fall, welche Rechte, welche Prüfung?

8:30 Und ein Hinweis aus der Praxis: Wenn sich ein Fall nicht eindeutig zuordnen lässt, sind es meistens zwei Fälle, die noch zusammenkleben. Das Trennen ist dann schon die halbe Lösung. Der erste Punkt ist menschlich: Ein Dialog wirkt greifbarer, man kann ihn vorführen. Also baut man einen, obwohl eine schlichte Auskunft gereicht hätte.

8:50 Der zweite ist der teuerste — eine schreibende Aktion wird eingeplant, bevor jemand geklärt hat, ob der Agent das überhaupt darf. Der dritte begegnet uns morgen noch ausführlich: Aktuelle Zahlen stehen nicht in Dokumenten, egal wie gut sie gepflegt sind. Und der vierte ist schleichend: Der Anspruch wächst im Projekt, aber niemand bewertet den Aufwand neu.

Umgebung, Rollen, Kanäle und Kosten

9:11 Bevor jemand den ersten Agenten anlegt, muss im Tenant einiges stehen. Das ist unspektakulär — und der häufigste Grund, warum ein Seminartag stockt. Ein Agent schwebt nicht frei, er lebt in einer Power-Platform-Umgebung. Diese Umgebung ist seine Heimat und zugleich seine Grenze: Sie bestimmt, wer welche Rolle hat, welche Datenrichtlinien gelten und ob Entwicklung, Test und Produktion sauber getrennt sind.

9:38 Für den Zugang genügt eine Copilot-Studio-Benutzerlizenz, die Rolle für Copilot-Studio-Autoren oder eine Microsoft-365-Copilot-Lizenz. Und gerechnet wird in Copilot Credits — einer gemeinsamen Recheneinheit, die wir am letzten Tag ausführlich anschauen. Behalten Sie den Begriff im Kopf, er taucht ab jetzt überall auf. Diese Liste hat einen einzigen Zweck: Sie soll verhindern, dass Sie mitten in einer Übung feststecken.

10:04 Jeder Punkt kann den Start blockieren, und keiner davon lässt sich in fünf Minuten nachholen — eine Umgebung wird beantragt, eine Datenrichtlinie ändert ein Administrator, Kapazität muss zugewiesen sein. Der letzte Punkt wird dabei am häufigsten vergessen, dabei ist er der wichtigste: Kanal und Authentifizierung entscheiden, ob überhaupt jemand den Agenten erreicht.

10:24 Dazu kommt die Fußnote, die uns gleich noch beschäftigt — die Testlizenz hat eine unangenehme Grenze. Diese Einschränkung ist sauber dokumentiert und wird trotzdem regelmäßig übersehen. Mit der Trial-Lizenz können Sie einen Agenten anlegen, ihn ausstatten und im Testchat ausprobieren. Veröffentlichen können Sie ihn nicht.

10:43 Und ohne Veröffentlichung gibt es keinen Kanal, keine echte Anmeldung und damit keinen realistischen Test. Das ist keine Kleinigkeit: Der Unterschied zwischen Testchat und Zielkanal ist einer der roten Fäden dieser Woche. Prüfen Sie den Lizenzstand also heute — nicht am Freitag, wenn der Agent in Teams laufen soll. Der erste Punkt ist der klassische Seminarfehler und zugleich ein Unternehmensfehler: Alle bauen in derselben Umgebung, weil das keine Beantragung braucht.

11:11 Dann liegen Versuche neben Produktivem, und niemand traut sich mehr, etwas zu löschen. Punkt zwei und drei fallen immer im ungünstigsten Moment auf — mitten in der Übung. Und der vierte ist eine Frage der Reihenfolge: Wer den Agenten baut, bevor der Kanal feststeht, entwirft Gespräche für eine Bühne, die er noch nicht kennt.

Übung

11:30 Damit haben Sie alles beisammen, um den ersten eigenen Fall einzuordnen. Lernen Sie kurz das Unternehmen kennen, das uns die ganze Woche begleitet. Die Ankerfeld GmbH stellt industrielle Messtechnik her, rund 1.800 Menschen arbeiten dort. Unser Anlass ist so unspektakulär wie verbreitet: Fragen zur Weiterbildung landen als Mail bei der Personalentwicklung.

11:52 Welche Formate gibt es, was sind die Voraussetzungen, wie melde ich mich an? Dieselben Fragen, immer wieder, mit Wartezeiten dazwischen. Das ist ein guter Kandidat für einen Agenten — aber eben nur ein Kandidat. Genau das prüfen Sie jetzt, und zwar an drei Fällen, von denen Sie einen auswählen. Das Lernziel ist die Beurteilung, nicht der Entwurf.

12:14 Sie sollen einen Fall nach vier Maßstäben bewerten — Nutzen, Risiko, Datenbedarf, Automatisierungsgrad — und daraus einen Steckbrief machen, der auch die Harness-Wahl begründet. Entscheidend ist der zweite Teil des Erfolgskriteriums: Auch die beiden verworfenen Fälle brauchen eine Begründung. Denn eine Entscheidung, die nur die gewählte Option kennt, ist keine Entscheidung.

12:36 Und wer früh fertig ist, benennt den Fall, für den Copilot Studio ausdrücklich nicht das Richtige wäre. Der Ablauf ist bewusst eng getaktet, damit Sie nicht ins Entwerfen geraten. Erst beschreiben, kurz und in ganzen Sätzen. Dann Nutzen und Risiko — und zwar beides, das ist der Punkt, an dem die meisten abkürzen. Danach der Datenbedarf, mit der unbequemen Zusatzfrage, wem diese Daten eigentlich gehören. Dann die Einordnung nach Anspruch, die wir eben geübt haben.

13:04 Und zum Schluss die Entscheidung samt Begründung. Fünfundvierzig Minuten klingen knapp, reichen aber — wenn Sie der Versuchung widerstehen, schon Topics zu planen. Vier Muster, die in dieser Übung immer wieder auftauchen. Der erste ist sympathisch und trotzdem gefährlich: Man wählt den spannendsten Fall, nicht den mit dem klarsten Nutzen.

13:25 Beim zweiten bleibt das Risiko eine Floskel — schreiben Sie stattdessen auf, was konkret passiert, wenn es schiefgeht. Der dritte ist eine Abkürzung, die sich rächt: Datenbedarf schätzen, ohne den Eigentümer zu fragen. Und der vierte betrifft die Begründung der Harness-Wahl. Fehlt sie, ist die Entscheidung später nicht überprüfbar — und damit auch nicht korrigierbar. Im nächsten Modul machen wir aus dem gewählten Fall einen abgegrenzten Auftrag.

Dieses Modul als Schulung für Ihr Team

Das Video zeigt den Stoff. In der Schulung arbeitet Ihr Team damit — an Ihrem eigenen Code, mit Übungen und mit den Fragen, die ein Video nicht beantwortet. Sie wählen die Module aus Microsoft Copilot Studio in der Praxis, wir bauen daraus ein Programm.

5 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung

Als Team-Schulung anfragenWie eine Schulung abläuft →