Start / Seminare / Microsoft Copilot Studio in der Praxis
Modul
Werkzeuge und Agent Flows
Modul 6 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
Transkript
Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.
Werkzeuge und Agent Flows
0:00 Bis hierhin hat unser Agent geredet. Jetzt bekommt er Hände. Sobald er etwas tut statt sagt, ändern sich alle Fragen: Mit wessen Rechten handelt er? Was passiert, wenn das andere System nicht antwortet? Und wer bestätigt, bevor etwas angelegt wird? Das ist der Punkt, an dem ein Agentenprojekt aufhört, ein Experiment zu sein.
0:20 Schauen wir uns an, welche Wege nach draußen es gibt, wie ein Agent Flow angebunden wird — und wie man Lesen und Schreiben ganz unterschiedlich absichert.
Werkzeuge und Agent Flows
0:30 Vier Themen. Zuerst der Überblick über die Schnittstellen — sechs Wege nach draußen mit sehr unterschiedlichem Kontrollbedarf. Dann bauen wir einen Agent Flow und hängen ihn als Werkzeug an. Im dritten Kapitel geht es um die zwei Einstellungen, die über das Risiko entscheiden. Und zum Schluss um das, was niemand gern plant und jeder braucht: die Fehlerfälle.
Schnittstellen auswählen
0:51 Beginnen wir mit dem Überblick — und der Frage, wonach man eigentlich auswählt. Denn die Antwort lautet nicht: nach dem, was am schnellsten eingerichtet ist. Sondern nach dem Kontrollbedarf. Werkzeuge sind die Bausteine, über die ein Agent mit anderen Systemen arbeitet. Sechs Wege stehen zur Verfügung, und sie reichen von sehr bequem bis sehr grundsätzlich: vorgefertigte Konnektoren für bekannte Dienste, eigene Konnektoren, Agent Flows, Prompts, REST-Schnittstellen, die Anbindung eines MCP-Servers — und Computer Use für den Fall, dass es gar keine Schnittstelle gibt, sondern nur eine Oberfläche.
1:27 Der letzte Weg ist der bemerkenswerteste und zugleich der, den man sich am besten aufspart. Dazu am letzten Tag mehr. Lesen Sie die dritte Spalte als Preisschild. Jede Werkzeugart bringt etwas mit, das Sie später tragen: Ein vorgefertigter Konnektor kann von der Datenrichtlinie gesperrt sein, ein eigener braucht eine Freigabe für die Organisation, ein Agent Flow verbraucht Kapazität je Aktion.
1:52 Bei einem MCP-Server ist es besonders interessant — der Bestand an Werkzeugen wechselt mit dem Server, Sie haben ihn also nicht allein in der Hand. Und die Fußzeile gibt eine erstaunlich konkrete Empfehlung: technisch bis zu 128 Werkzeuge, empfohlen nicht mehr als 25 bis 30. Diese Empfehlung folgt direkt aus gestern. Je mehr Werkzeuge, desto schwerer die Auswahl — es ist exakt dasselbe Problem wie bei ähnlichen Beschreibungen, nur mit mehr Beteiligten.
2:19 Dazu kommt der Pflegeaufwand: Jedes Werkzeug ist eine Abhängigkeit, die irgendwann bricht, wenn sich das andere System ändert. Und der letzte Punkt ist ein nützlicher Ausweg für große Vorhaben: Untergeordnete Agents haben eine eigene Orchestrierung und eigene Werkzeuge. Statt eines Agenten mit sechzig Werkzeugen baut man dann besser drei mit je zwanzig.
2:41 Der erste Punkt ist die falsche Auswahlfrage: Man nimmt, was verfügbar ist, statt zu fragen, wie viel Kontrolle der Fall braucht. Der zweite fällt spät auf — der Konnektor funktioniert in der Entwicklung und wird in der Produktion von der Datenrichtlinie gesperrt. Der dritte ist ein echter Fehlgriff, den man regelmäßig sieht: Computer Use anstelle einer Schnittstelle, die es längst gibt.
3:02 Und der vierte ist die stille Ansammlung — Werkzeuge kommen dazu, keines geht je wieder weg, und die Auswahl wird von Monat zu Monat schlechter.
Agent Flow anbinden
3:11 Jetzt bauen wir die Verbindung zum Fachsystem. Der Agent Flow ist dafür das naheliegendste Mittel — und der Teil unseres Agenten, der sich am berechenbarsten verhält. Ein Agent Flow ist deterministisch — gleiche Eingabe, gleiche Ausgabe. Das ist die angenehme Gegenwelt zum Generativen: Hier gibt es keine Überraschungen.
3:30 Wichtig ist eine Kleinigkeit mit großer Wirkung: Nur ein Flow mit dem Auslöser für den Agentenaufruf lässt sich als Werkzeug anhängen. Ein Flow mit einem Zeitplan oder einem anderen Ereignis steht für sich. Und zum Bauen stehen vier Arten von Aktionen bereit — für KI-Aufgaben, für menschliche Freigaben, für die Ablaufsteuerung und für Konnektoren.
3:51 Worauf es hier ankommt, ist nicht das Format, sondern das letzte Feld. Die ersten vier Werte sind naheliegend: Vorgangsnummer, Status, Zuständigkeit, Änderungsdatum. Der fünfte trennt zwei Fälle, die sonst ununterscheidbar wären — „diesen Vorgang gibt es nicht" und „ich konnte gerade nicht nachsehen". Ohne dieses Feld sieht beides gleich aus, und der Agent formuliert im Zweifel die falsche Auskunft.
4:15 Nehmen Sie das als Faustregel mit: Jede Abfrage braucht eine Antwort auf die Frage, ob überhaupt gesucht werden konnte. Der rote Faden: erst den Vertrag, dann die Umsetzung. Eingaben und Rückgabewerte werden festgelegt, bevor Aktionen entstehen — einschließlich des Feldes für den Nichtfund. Dann der richtige Auslöser, dann das Anhängen mit sorgfältigem Namen und sorgfältiger Beschreibung; Sie wissen inzwischen, warum das zählt.
4:42 Und zum Schluss eine angenehme Nachricht aus der Fußzeile: Testläufe aus dem Flow-Designer und aus dem Testchat verbrauchen keine Kapazität. Sie können also ausgiebig probieren, ohne aufs Budget zu schauen. Der erste Punkt ist der fehlende Nichtfund, den wir gerade besprochen haben. Der zweite ist eine Feinheit mit spürbarer Wirkung: Rückgabewerte mit technischen Namen kann der Agent schlecht in eine Antwort einbetten — er formuliert dann umständlich oder gar nicht.
5:09 Der dritte ist eine Einbahnstraße im Wortsinn: Die Umwandlung eines Power-Automate-Flows in einen Agent Flow lässt sich nicht rückgängig machen, weil sich die Abrechnung ändert. Und der vierte ist die alte Regel für jede Automatisierung: Ein Flow, der zu viel auf einmal macht, ist nicht mehr einzeln zu testen.
Lesen und Schreiben absichern
5:26 Jetzt zu den zwei Einstellungen, an denen im Betrieb alles hängt. Beide sind schnell gesetzt, beide haben eine Voreinstellung — und eine davon ist nicht die, die Sie erwarten. Zwei Schalter, beide je Werkzeug: Mit wessen Zugangsdaten läuft es — denen der nutzenden Person oder denen des Makers? Und wird vor dem Ausführen gefragt?
5:47 Die Voreinstellungen sind bemerkenswert: Standardmäßig gelten die Zugangsdaten der nutzenden Person — das ist gut und sollte so bleiben. Die Rückfrage vor dem Ausführen dagegen steht auf Nein. Das heißt im Klartext: Ein schreibendes Werkzeug läuft ohne Rückfrage, solange Sie diesen Schalter nicht umlegen. Die vier Felder ergeben sich aus der Kombination beider Schalter — und die Steigerung von links oben nach rechts unten ist deutlich.
6:13 Lesen mit Nutzerrechten ist der Regelfall und braucht nichts weiter. Lesen mit Makerrechten sollte eine bewusste Ausnahme für geteilte Bestände sein. Schreiben mit Nutzerrechten verlangt die Rückfrage. Und Schreiben mit Makerrechten — das Feld unten rechts — braucht beides plus eine menschliche Freigabe im Flow. Wenn Sie sich in diesem Feld wiederfinden, prüfen Sie zuerst, ob es wirklich sein muss.
6:36 Hier steckt das größte Risiko dieses Moduls, und es ist leicht zu übersehen. Mit Makerrechten handelt der Agent für alle Nutzenden mit den Rechten einer einzigen Person. Und jetzt kommt der Satz, der in der Dokumentation als Warnung steht: Wird der Agent geteilt, handeln alle mit diesen Rechten. Wer zufällig weitreichende Berechtigungen hat, verleiht sie damit ungewollt weiter. Nutzerrechte begrenzen dagegen sauber auf das, was die jeweilige Person ohnehin sehen darf.
7:04 Und noch ein Hinweis: Werkzeuge brauchen eine aktive Authentifizierung, sonst laufen sie gar nicht. Der erste Punkt ist der Klassiker aus der Bauphase: Die Authentifizierung wird am Agenten abgeschaltet, weil das Anmelden im Test nervt — und damit brechen alle Werkzeuge mit Nutzerrechten weg. Der zweite ist die vergessene Voreinstellung bei der Rückfrage. Der dritte ist die Bequemlichkeit, die zur Dauerlösung wird: Makerrechte, weil der Test damit schneller geht.
7:31 Und der vierte ist die Frage, die niemand stellt — welche Rechte der Maker eigentlich selbst hat. Bei einem Administrator als Maker ist das eine unangenehme Antwort.
Fehlerfälle beherrschen
7:41 Zum Schluss das Thema, das man gern verschiebt: Was sagt der Agent, wenn das Fachsystem schweigt? Im Test tritt dieser Fall nie ein. Im Betrieb tritt er jede Woche ein. Vier Fälle, die sich für die nutzende Person völlig unterschiedlich anfühlen und im System leicht zusammenfallen: nichts gefunden, Zeitüberschreitung, Fehlerantwort, keine Berechtigung.
8:03 Wenn alle vier zur gleichen Meldung führen, zieht die Person dreimal den falschen Schluss — und ruft am Ende doch in der Fachabteilung an. Genau dann hat der Agent nichts gespart. Der Aufwand, diese Fälle zu trennen, ist überschaubar. Man muss nur daran denken, bevor man fertig ist. Achten Sie auf die dritte Spalte — dort steht, was danach passiert, und das ist der eigentliche Unterschied.
8:26 Beim Nichtfund wird die Angabe erneut erfragt, denn wahrscheinlich stimmt die Nummer nicht. Bei der Zeitüberschreitung lohnt ein zweiter Versuch. Bei einer Fehlerantwort lohnt er nicht — da geht es zur Personalentwicklung. Und bei fehlender Berechtigung braucht die Person keinen Trost, sondern den Weg zur Freischaltung.
8:45 Vier Fälle, vier Fortsetzungen. Das ist der ganze Trick. Der erste Punkt ist der logische: Eine Fehlerantwort bedeutet, dass das System geantwortet hat — es kann nur gerade nicht. Eine Wiederholung ändert daran nichts. Der zweite ist der gefährliche: Eine schreibende Aktion darf nicht blind wiederholt werden, sonst liegt der Vorgang am Ende doppelt vor.
9:06 Der dritte betrifft teilweise ausgeführte Folgen, die einen unklaren Zustand hinterlassen. Und der vierte ist eine Eigenheit der Abrechnung, die man kennen sollte: Ist die Kapazität aufgebraucht, werden Flow-Läufe blockiert — der Agent antwortet aber weiter, als wäre nichts. Der erste Punkt ist die Einheitsmeldung, über die wir gerade gesprochen haben. Der zweite ist die blinde Wiederholung bei schreibenden Aktionen.
9:31 Der dritte ist der unangenehmste: Der Agent verschweigt den Fehler und antwortet aus dem allgemeinen Wissen — die Auskunft klingt dann souverän und ist erfunden. Und der vierte erklärt, warum die anderen drei so häufig sind: Der Fehlerfall wird nie ausprobiert, weil es Mühe macht, ihn herbeizuführen. Genau das tun Sie gleich in der Übung.
Übung
9:50 Jetzt verbinden wir den Lernlotsen mit dem Fachsystem — lesend und schreibend, und zwar unterschiedlich abgesichert. Zwei Werkzeuge auf dieselbe Anwendung, mit ganz verschiedenen Ansprüchen an die Absicherung. Die Schulungsverwaltung der Ankerfeld GmbH heißt Kursbuch. Sie kennt zu jeder Anfrage eine Vorgangsnummer, einen Status und eine zuständige Rolle.
10:12 Der Lernlotse soll den Status lesen dürfen — das ist unkritisch und hilft sofort. Einen Entwurf für eine Folgeaufgabe darf er dagegen erst nach ausdrücklicher Bestätigung anlegen. Zwei Werkzeuge auf dasselbe System, zwei völlig verschiedene Absicherungen. Genau daran üben wir die Unterscheidung. Das Lernziel verbindet beide Kapitel: unterschiedlich absichern und die Fehlerfälle planen.
10:36 Im Erfolgskriterium stecken drei Prüfpunkte — der belegte Status, die sichtbare Bestätigung vor dem Schreiben und, besonders wichtig, unterschiedliche Antworten für Nichtfund und Zeitüberschreitung. Wer früh fertig ist, ergänzt eine menschliche Freigabe im schreibenden Flow. Das ist keine Spielerei: In vielen Unternehmen ist genau das die Bedingung dafür, dass so ein Agent überhaupt produktiv gehen darf.
11:00 Fünf Schritte in aufsteigender Schwierigkeit. Die ersten beiden bauen den lesenden Weg — mit dem Feld für den Nichtfund, das wir vorhin besprochen haben. Die Schritte drei und vier bauen den schreibenden und schalten die Rückfrage ein; achten Sie darauf, dass die Bestätigung die erfassten Angaben zeigt. Schritt fünf ist der, den man am liebsten weglässt: Nichtfund und Zeitüberschreitung gezielt herbeiführen.
11:23 Erfinden Sie eine Vorgangsnummer, die es nicht gibt — das ist schnell gemacht und zeigt sofort, ob Ihr Entwurf trägt. Der erste Punkt ist die Rechteentscheidung aus Bequemlichkeit, die dann stehen bleibt. Der zweite ist die inhaltsleere Bestätigung. Der dritte ist die Einheitsmeldung für Nichtfund und Systemfehler. Und der vierte schlägt den Bogen zu gestern: Wenn die Beschreibung des schreibenden Werkzeugs klingt wie die des lesenden, wählt die Orchestrierung irgendwann das falsche — und dann nützt Ihnen die schönste Absicherung nichts.
11:54 Morgen geht es um Identität, Rechte und Governance. Also genau um die Fragen, die Ihre IT stellen wird.
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