Tanja gibt einen kompakten Rückblick auf die bisherigen vier Co-Pilot-Sessions und zeigt dir, was sich aktuell in Co-Pilot Studio verändert: neues Design für Agenten, ein moderner Workflow-Editor im Stil von n8n und spannende neue Skills wie „Skill Goal“ für autonomes Arbeiten im Hintergrund. Außerdem erfährst du, wie du eigene Skill-MDs (z. B. aus Claude) in Cowork überführst und worauf du beim Wechsel auf die neue Studio-Ansicht achten musst.

Rückblick: Was bisher in der Co-Pilot-Reihe passiert ist

Bevor es ans Bauen geht, ordnet Tanja die bisherige Reise ein. Der Ursprungsgedanke der Reihe ist, dass du deinen Agenten am Ende per App ansteuern kannst.

• Session 1 (Kick-Off in der KI-Masterclass): Überblick über die Agentenlandschaft bei Microsoft Co-Pilot und die einzelnen Entwicklungswellen. Aktuell bewegen wir uns in Welle 3.
• Session 2 (Deep Dive App-Agents): Die Agents, die direkt in Word, Excel oder PowerPoint laufen. Wichtig: Der Zugang zum Co-Piloten ändert sich laufend – aktuell findest du ihn nicht mehr im Startmenü, sondern als kleines Bubble-Icon unten.
• Session 3 (Automatisierung): Erste Schritte mit Cowork und Skills.
• Session 4 (Agenten bauen): SharePoint Agents, Agent Builder und Co-Pilot Studio im klassischen Design.

App-Agents und Notebooks im Schnelldurchlauf

In den App-Agents hast du zwei Modi: den klassischen Chat, bei dem der Co-Pilot nur in die Datei schaut, aber nicht arbeitet, und den Modus mit Bearbeitung zulassen, in dem der Co-Pilot in der Datei tatsächlich aktiv wird. Beispiel aus der Reihe: ein Master-Layout, in dem der Co-Pilot die Platzhalter befüllt.

Notebooks funktionieren ähnlich wie Notebook LM: Du lädst Informationen rein und erhältst Zusammenfassungen, Audio-Übersichten, Themenkarten oder Quizze. Tanjas Ausblick: Notebooks können künftig das Unternehmenswissen abbilden, ohne dass jeder Zugriff auf alle Daten braucht. Beispiel Onboarding – alle relevanten Unterlagen liegen in einem abgeschlossenen Notebook.

Cowork: Skills selbst bauen und Skill-MDs übernehmen

Skills sind in Cowork die sogenannten Qualifikationen. Es gibt eigene und installierte Qualifikationen, die Liste wächst stetig.

Wichtig für alle, die schon mit Claude arbeiten: Du kannst deine bestehenden Skill-MDs (z. B. einen eigenen PowerPoint-Skill oder den von TJ bereitgestellten Datei-Skill) in Cowork übernehmen. Der Ablauf:

1. Über den Skill „Skills“ deine bisherigen Skills aufrufen oder einen neuen erstellen.
2. Beschreiben, was der Skill können soll, oder direkt die Skill-MD als Anlage hochladen.
3. Cowork liest die Datei aus und baut sie so um, dass der Co-Pilot sie nutzen kann.

Tipp aus der Praxis: Benenne den Skill spezifisch (z. B. „Körting-Präsentationen“ statt generisch „Design Principles“). Sonst greift er auf zu viele Dokumente zu und alle deine Präsentationen sehen am Ende gleich aus.

Skill „Goal“: der Mini-Scout im Hintergrund

Besonders spannend findet Tanja den Skill Goal. Er funktioniert ähnlich wie der angekündigte Microsoft Scout – ein Assistent, der im Hintergrund eigenständig arbeitet (Open-Claw-Technologie ist mit drin).

Live-Beispiel: Tanja gibt dem Skill als Ziel:

Ich habe einen Ordner mit E-Mails, die auf eine Antwort warten. Beantworte alle Mails, speichere sie unter Entwürfe und leere den Ordner.

Mehr Input bekommt der Skill nicht. Das Ergebnis: Drei vorgefertigte Antworten landen sauber in den Entwürfen, der Pending-Ordner ist leer. Schiebst du eine neue Mail hinein, läuft der Prozess erneut. Über den Slash-Befehl bei Qualifikation kannst du dir alle verfügbaren Skills ansehen – darunter auch das Erstellen von HTML.

Co-Pilot Studio: das neue Design

Co-Pilot Studio hat eine neue, modernere Oberfläche bekommen. Im Vergleich zur alten Ansicht mit vielen Reitern und Bereichen ist die neue Version aufgeräumter.

Wo du sie findest: In Co-Pilot Studio oben rechts auf den Button „Jetzt ausprobieren“ klicken. Vorher die richtige Umgebung wählen (meist die Standardumgebung).

Was im neuen Design anders ist:
– Beim Erstellen eines Agenten siehst du keine überladene Reiter-Struktur mehr, sondern eine schlanke Seitenleiste für Wissen und Skills.
– Du kannst dem Agenten jetzt direkt Skill-MDs in den Bauch geben – nicht mehr nur Anweisungen.
– Aktionen (z. B. SharePoint-Zugriff) lassen sich weiterhin hinzufügen.
– Das Bauen ist insgesamt einfacher, ohne die starre Wenn-Dann-Logik der alten Prozessschritte.

Wichtige Einschränkungen:
– Du kannst aktuell keinen Agenten oder Workflow per Prompt erstellen, sondern musst zusammenklicken.
– Bestehende Agenten aus dem alten Design werden nicht automatisch ins neue übernommen. Empfehlung: Kopiere deine alten Agenten manuell rüber, bevor Microsoft hier nachzieht – falls überhaupt.
– Öffnest du einen alten Agenten, springt die Ansicht zurück ins alte Design.

Workflows im neuen Studio: endlich wie n8n

Auch der Workflow-Bereich wurde überarbeitet. Die alten Power-Automate-artigen Flows waren sehr statisch – ständiges Aufklappen, unübersichtliche Bedienung.

Im neuen Co-Pilot Studio funktionieren Workflows wie aus Langdog oder n8n gewohnt: Du arbeitest mit kleinen Tasten und Knoten. Beim Anlegen eines neuen Workflows bekommst du einen Start-Trigger, den du frei konfigurierst:

• Manuelle Ausführung
• Geplante Ausführung zu einem bestimmten Zeitpunkt
• Trigger über einen Connector

Ausblick

Tanjas große Hoffnung: Dass wir künftig nicht mehr Power Apps, Power Automate und weitere Einzeltools brauchen, sondern Cowork (bzw. ein kommender „Co-Pilot Code“) direkt das gewünschte Ziel umsetzt. Bis dahin lohnt es sich, das neue Studio-Design und den Goal-Skill aktiv auszuprobieren.

Tanja zeigt, wie sie ihren LinkedIn-Prozessmanager-Agenten nicht nur per Chat, sondern automatisch über einen SharePoint-Trigger ansteuert. Du siehst die Architektur dahinter: SharePoint als Kernsystem, ein Flow als Brücke und eine eigene App als Eingabe-Frontend für Briefings, Themen und Transkripte. Damit wird klar, warum bei Microsoft mehrere Tools zusammenspielen müssen — und wie sich daraus ein durchgängiger Workflow bauen lässt.

Vom Agent zum automatisierten Workflow

Im vorherigen Schritt hast du gesehen, wie ein Agent — der Prozessmanager-Agent aus dem letzten Call — manuell genutzt werden kann. In diesem Segment geht es einen Schritt weiter: Wie lässt sich derselbe Agent anderweitig antriggern, also nicht mehr nur durch direkte Chat-Eingabe, sondern automatisch aus einem anderen System heraus?

Tanja zeigt dafür den konkreten Aufbau hinter ihrem LinkedIn-Workflow und macht transparent, warum bei Microsoft mehrere Bausteine ineinandergreifen müssen.

Der Workflow-Trigger über SharePoint

Die Logik ist einfach formuliert:

Wenn in meinem SharePoint etwas erstellt wurde, soll der Prozessmanager-Agent antriggern, seine Aufgabe ausführen und das Ergebnis wieder in SharePoint zurückschreiben.

SharePoint ist also das Kernsystem. Es dient gleichzeitig als:

• Auslöser (Trigger) für den Agent
• Speicherort für die Eingaben
• Rückgabeort für die vom Agent erzeugten Inhalte

Damit entsteht ein geschlossener Kreislauf, in dem der Agent ohne manuelles Anstoßen seine Arbeit aufnimmt, sobald neue Daten vorliegen.

Die LinkedIn-Prozessmanager-App als Frontend

Damit die Daten überhaupt sauber in SharePoint landen, hat Tanja eine eigene LinkedIn-Prozessmanager-App gebaut. Sie ist optisch noch nicht final, hat aber bereits eine klare Funktionsstruktur:

• Briefings: Alle Briefings liegen zentral in der App.
• Aktueller Beitrag: Sichtbar ist, welcher Beitrag gerade in Arbeit bzw. erstellt ist.
• Input-Erfassung: Du kannst direkt ein Transkript einfügen oder ein Thema angeben.

Der Clou: Diese Eingaben werden automatisch weiterverarbeitet. Das Transkript bzw. das Thema läuft durch den Agent und kommt am Ende als fertiges Post-Briefing zurück in die App — angereichert und einsatzbereit.

Warum SharePoint als Brücke notwendig ist

Ein wichtiger Hinweis aus der Praxis: Anders als bei vielen anderen Tools, in denen du innerhalb derselben Oberfläche bleibst und Schritt für Schritt weiterarbeitest, zwingt dich Microsoft derzeit dazu, über mehrere Tools hinweg zu denken.

Die App ist die Eingabeschicht. SharePoint ist die Datenschicht. Der Flow ist die Verbindungsschicht. Der Agent ist die Verarbeitungsschicht. Damit das Zusammenspiel funktioniert, müssen die Eingaben aus der App zuerst in SharePoint gespeichert werden — denn nur darauf kann der Flow am Ende zugreifen, um den Agent anzustoßen.

Das ist kein Schönheitsfehler, sondern derzeit schlicht die Realität im Microsoft-Ökosystem. Wer diese Architektur einmal verstanden hat, kann sie sehr bewusst nutzen, um robuste Automatisierungen zu bauen.

Ausblick: So wird die App gebaut

Im nächsten Schritt zeigt Tanja konkret, wie sie diese App aufgesetzt hat — also den praktischen Bauplan für die Eingabeoberfläche, die SharePoint als Backend nutzt und damit den gesamten LinkedIn-Workflow in Gang setzt.

In diesem Segment lernst du, wie du mit Microsoft Power Apps eigene kleine Anwendungen baust – ganz ohne klassisches Entwicklerwissen. Tanja zeigt den neuen „Vibe“-Modus, mit dem du Apps per Prompt wie in Claude Code erstellen kannst, und nimmt dich Schritt für Schritt mit, wenn typische Microsoft-Stolpersteine wie fehlende Umgebungen oder Dataverse-Zugriffe auftauchen. Du verstehst danach, warum Solo-Selbstständige eine eigene Umgebung anlegen müssen und wie Unternehmens-Admins den Zugriff steuern.

Was sind Power Apps?

Microsoft Power Apps ist ein Baukasten, mit dem du dir kleine eigene Anwendungen zusammenstellst – zum Beispiel um Aktionen in SharePoint auszulösen oder dir eine Übersicht über bestimmte Daten zu bauen. Im Kurs wurde damit bereits eine Textbausteine-App nachgebaut, die ursprünglich im KI-Café entstanden ist.

Klassisch startest du in Power Apps mit einem leeren Entwurf, der wie ein Canvas funktioniert. Diese Oberfläche ist allerdings sehr technisch gehalten: Du musst wissen, was ein „Screen-Container“ ist und dich mit Entwickler-Logik anfreunden. Für viele Anwender ist das eine Hürde, die schnell Fahrstuhlmusik-Stimmung verbreitet.

Vibe Power Apps: Per Prompt zur App

Microsoft will, dass möglichst viele Menschen Apps bauen können – und bietet deshalb inzwischen einen Copilot-gestützten Weg an: die sogenannten Vibe Power Apps. Das Prinzip ist das gleiche, das du aus Tools wie Claude Code kennst: Du beschreibst in natürlicher Sprache, was du haben möchtest, und der Copilot übernimmt den technischen Aufbau.

Im Beispiel wurde der Auftrag formuliert: „Ich möchte eine App erstellen, die meine LinkedIn-Posts plant.“ Du kannst dazu zusätzliche Inhalte und Kontext hinzufügen und über die Funktion Plan zunächst skizzieren lassen, was alles in deiner App stehen soll – bevor tatsächlich gebaut wird.

Das Problem mit den Umgebungen

In der Live-Demo trat ein typisches Microsoft-Phänomen auf: Bei mehreren Teilnehmern erschien die Meldung „Deine Umgebung ist für diese Erfahrung nicht geeignet.“ Hintergrund:

• Das neue Vibe-Design braucht zwingend eine eigene Umgebung mit Dataverse-Tabelle im Hintergrund.
• Ohne diese Umgebung kann die App gar nicht arbeiten – auch nicht beim Veröffentlichen.

So legst du eine Umgebung an:

1. Gehe in Power Apps oben in den Bereich Umgebung (Farbe variiert je nach Tenant – blau, lila, grau …).
2. Wähle Apps mit Dataverse erstellen.
3. Wenn keine Umgebung vorhanden ist, fragt dich Microsoft, ob du eine eigene brauchst – bestätige mit Jetzt ausprobieren.
4. Setze die Region auf Europa und vergib einen Namen.

Solo-Selbstständige vs. Unternehmenskontext

Wenn du dein eigenes Microsoft-Konto nutzt, bist du auch dein eigener Admin und musst die Umgebung selbst anlegen. Im Unternehmenskontext ist das anders: Hier entscheidet die IT, welche Funktionen freigeschaltet sind. Deshalb sehen Teilnehmer aus Firmen oft schon vorgegebene Umgebungen – manchmal eine Dev- und eine Produktivumgebung (Sandbox).

Auch der allgemeine Zugriff hängt von Lizenzen ab: Funktionen wie Cowork oder Frontier werden im Adminbereich pro Unternehmen freigegeben. Ist Frontier nicht aktiv, kann es sein, dass die neue Vibe-Vorschau bei dir schlicht noch nicht verfügbar ist, weil Microsoft sie noch ausrollt.

Offene Baustelle: Test- in Live-Umgebung übertragen

Ein ehrlicher Hinweis aus der Praxis: Wer eine App in einer Testumgebung baut, steht aktuell vor dem Problem, dass es keinen sauberen Weg gibt, sie in die Live-Umgebung zu überführen. Die einzige bekannte Lösung ist bisher, die App im Live-System neu bauen zu lassen – was offensichtlich nicht der Königsweg sein kann. Hier lohnt es sich, regelmäßig nach Updates zu schauen.

Empfehlung

Auch wenn die Umgebung bei dir noch nicht funktioniert: Bleib dran und probier den Vibe-Weg in den Make Preview Power Apps weiter aus. Wähle vor dem Start aktiv deine neue Umgebung aus und gehe dann über Mit einem Plan beginnen → Vorschau / Neue Erfahrungen testen. Microsoft rollt die Funktion sukzessive aus – früher oder später landet sie auch in deinem Account.

In diesem Segment zeigt Tanja, wie du eine SharePoint-Liste als Wissensbasis für deine Copilot-Agenten und Power-Apps anlegst. Du siehst, wie der KI-Planungsmodus in Power Apps funktioniert, wie du Listenvorlagen wie „Inhaltsplanung mit Genehmigung“ nutzt und wie du deine App so verbindest, dass Eingaben automatisch in SharePoint landen. Außerdem geht es um Fehlersuche per Copilot-Chat und den Switch zwischen parallelen Aufgaben als neue Arbeitsweise.

Erst planen, dann bauen — der KI-Planungsmodus in Power Apps

Bevor Copilot direkt in die App-Erstellung geht, lohnt es sich, den Planungsmodus zu aktivieren. Genau das ist die Empfehlung in diesem Segment: erst mit der KI besprechen, was entstehen soll, statt direkt loszubauen. Sonst dauert es lange, bis du überhaupt etwas Sichtbares hast.

Im konkreten Beispiel schlägt Copilot — auf Basis eines deutlich ausführlicheren Input-Prompts — folgende Bestandteile für die App vor:

• ein Dashboard
• einen Content-Kalender
• einen Bereich für Ideen und Entwürfe
• einen Post-Editor
• Vorlagen
• eine Analyse-Sektion (manuell gepflegt, da Copilot nicht auf LinkedIn zugreifen kann — anders als z. B. Claude in bestimmten Setups)

Gefällt dir der Plan, akzeptierst du ihn. Falls nicht, kannst du ihn weiterverarbeiten und Änderungswünsche nachschieben. Erst danach baut Power Apps die App im Hintergrund.

Plan, Daten und Geduld während des Builds

Während der Build läuft, stehen dir in der Oberfläche mehrere Tasten zur Verfügung — unter anderem ein Blick auf den Plan und auf die genutzten Daten. Letzteres ist besonders spannend: Du siehst, welche Inhalte verarbeitet werden und wie sie miteinander verknüpft sind. Perspektivisch wird man diese Datenstrukturen vermutlich exportieren und in andere Umgebungen importieren können.

Der Build dauert eine gewisse Zeit. Theoretisch kannst du den Tab schließen — Copilot arbeitet im Hintergrund weiter und meldet sich, wenn die App fertig ist. In der Praxis empfiehlt sich aber, den Tab offen zu lassen, einfach um auf Nummer sicher zu gehen.

Warum eine SharePoint-Liste als Wissensbasis sinnvoll ist

Der entscheidende Architektur-Gedanke: Was du in der App eingibst, soll an SharePoint übergeben werden. Der Grund liegt in der Agenten-Welt von Copilot.

• Du kannst einem Agenten SharePoint-Dateien als Wissen mitgeben.
• Du kannst ihm aber auch erlauben, direkt auf SharePoint-Daten zuzugreifen.
• Am einfachsten funktioniert das, wenn du dem Agenten eine SharePoint-Liste zur Verfügung stellst.

Damit wird die Liste zum sauberen, strukturierten Wissensspeicher, auf den dein Agent — und parallel auch dein Workflow — zugreifen kann.

Eine SharePoint-Liste praktisch anlegen

So gehst du vor:

1. Öffne den SharePoint, in dem dein Agent später arbeiten soll (z. B. eine bestehende Copilot-Demo-Umgebung oder ein neu angelegter SharePoint).
2. Klicke auf der Startseite auf Neu. Du kannst dort Listen, Formulare, Dokumentenbibliotheken und weitere Elemente anlegen.
3. Wähle Liste und nutze eine der vorgefertigten Vorlagen — im Beispiel die Vorlage „Inhaltsplanung mit Genehmigung“.
4. Vergib einen Namen (im Demo: „Test-Demo“) und erstelle die Liste.
5. Kopiere den Link zur Liste — diesen Link gibst du deiner App als Ziel mit.

Anschließend kannst du deiner App sagen: „Das, was bei dir in der Oberfläche eingegeben wird, sollst du in dieser Liste wegspeichern.“ Damit hast du die Grundlage für das Agenten-Wissen.

Live-Test: Eingabe → Datensatz vorbereiten → an SharePoint übergeben

Im Live-Test wird in der App eine Idee eingetragen („Testen ist toll“ als LinkedIn-Post), die SharePoint-Seite und die Ziel-Liste sind hinterlegt. Der Ablauf:

1. Idee in der App eingeben.
2. Datensatz vorbereiten klicken.
3. An SharePoint übergeben auslösen.

Im Demo klappt die Übergabe nicht beim ersten Versuch — der Datensatz erscheint nicht in der Liste, Copilot meldet, eine Element-ID sei nicht zurückgekommen. Genau hier wird ein wichtiger Praxis-Reflex gezeigt.

Fehlersuche per Copilot-Chat

Statt selbst zu suchen, öffnest du den Chat-Bereich (über das Chat-Icon, falls nicht ohnehin offen) und beschreibst das Problem schlicht in natürlicher Sprache: „Ist nicht in der SharePoint-Liste gelandet.“ Copilot durchläuft dann Schritte zur Analyse — das braucht Geduld, ist aber der pragmatische Weg zur Fehlerursache.

Sobald die Daten zuverlässig in SharePoint landen, hast du zwei Anschlussoptionen:

• den Agenten auf diesen SharePoint beziehen
• den Workflow / Prozess mit dem SharePoint verbinden

Parallel arbeiten als neue Fähigkeit

Ein Nebengedanke, der in diesem Segment besonders ehrlich formuliert wird: Diese KI-Tools laufen oft länger im Hintergrund. Du stößt etwas an, wechselst zu einer anderen Aufgabe und kommst später zurück. Dieser Context-Switch ist eine Fähigkeit, die wir alle erst lernen — denn beim Zurückkommen muss man sich oft erst wieder erinnern: „Moment, was war das nochmal?“ Es ist tolles Gehirnjogging, aber es braucht Übung.

Vom Postplaner zur veröffentlichten App

Parallel zum SharePoint-Beispiel wird noch der bereits gebaute LinkedIn-Postplaner gezeigt — visuell etwas hübscher, mit einem fertigen Redaktions-Stack. Wichtig zu wissen:

• Die angezeigten Inhalte sind Testdaten, keine echten Daten aus deinem Account.
• Copilot generiert diese Testdaten passend zu deinem Business, weil er über Work IQ weiß, womit du dich beschäftigst. Das fühlt sich am Anfang oft an wie echte Daten — ist es aber nicht.

Wenn dir das Setup gefällt, klickst du auf Veröffentlichen, wählst deine Datenumgebung — und die App geht live. Ab dann kannst du SharePoint-Listen befüllen oder andere Aktionen auslösen.

Wenn die App es nicht direkt kann: Power Automate

Funktioniert eine Aktion nicht direkt aus der App heraus, übernimmt Power Automate als Workflow-Schicht. Microsoft stellt dafür zwei Varianten zur Verfügung:

• das klassische Power Automate, wie man es aus anderen Bereichen kennt
• für Copilot-Nutzer zusätzlich die Möglichkeit, sich auch im Power Automate per Copilot einen ersten Entwurf des Workflows generieren zu lassen

Damit schließt sich der Kreis: App-Eingabe → SharePoint-Liste → Agent-Wissen → optional ergänzt durch automatisierte Workflows.

In diesem Segment vergleicht Tanja die Workflow-Erstellung in Power Automate mit der in Copilot Studio – am konkreten Beispiel eines SharePoint-getriggerten LinkedIn-Agenten. Du siehst, wie Power Automate per KI einen ersten Flow-Entwurf generiert, wo die Tücken liegen und warum die Copilot-Studio-Variante für Endanwender deutlich einfacher ist. Ein ehrlicher Praxiseinblick mit Stolpersteinen und einem klaren Ausblick darauf, wohin die Reise geht.

Ausgangslage: Ein Flow für den LinkedIn-Agenten

Das Ziel des gezeigten Workflows ist klar umrissen: Eine SharePoint-Liste enthält Themen, aus denen ein LinkedIn-Agent Beiträge verfassen soll. Sobald in der Liste der Status „bereit für Agent“ auftaucht, soll der Flow automatisch anspringen, den Agenten triggern, den entstandenen Beitrag zurück in die Liste schreiben und den Status entsprechend weiterschalten – von „bereit für Agent“ über „in Bearbeitung“ bis „fertig“.

An genau diesem Use Case wird der direkte Vergleich zwischen Power Automate und Copilot Studio Workflows gezogen.

Power Automate mit Copilot-Entwurf

In Power Automate gibt es die Möglichkeit, sich von Copilot einen ersten Flow-Entwurf per Sprache bzw. Textbeschreibung generieren zu lassen. Du beschreibst, was du brauchst – etwa: „Ich habe eine SharePoint-Tabelle mit Themen, die an meinen LinkedIn-Agent übergeben werden sollen, sobald der Status auf ‚bereit für Agent‘ steht.“ – und Power Automate schlägt dir die nötigen Bausteine vor:

• einen Trigger auf SharePoint
• eine Wenn-Dann-Bedingung, die den Statuswert prüft
• die nötigen Berechtigungen (z. B. SharePoint-Verbindung)

Aus der Runde berichtet ein Teilnehmer, dass ein eher KI-skeptischer Programmierer-Kollege diese Copilot-Unterstützung in Power Automate als „schon gut“ einschätzt – also durchaus brauchbar im Alltag.

Wo Power Automate hakt

So weit, so charmant – aber die eigentliche Arbeit beginnt erst nach dem KI-Entwurf. Im Beispiel zeigt sich:

• Die von Copilot vorgeschlagenen Werte für Site, Liste und Statusfeld sind nicht automatisch korrekt. Sie müssen manuell ausgewählt und gegen die echten Bezeichnungen abgeglichen werden.
• Der Status hieß im Entwurf z. B. ready for agent, in der echten Liste aber bereit für Agent – solche Sprach-Mismatches sind klassische Fehlerquellen.
• Jede Node muss geöffnet, durchgeklickt und über Formulare konfiguriert werden (Site-Adresse, Liste, Bedingungsfelder, Agent-Anmeldung, Workflow-Name etc.).
• Die Oberfläche ist sperrig: An einer Stelle gibt es zwei sehr ähnliche Buttons – einer führt zu den bereits vorhandenen Agents, der andere zwingt dich, alles neu einzutragen. Wer den falschen erwischt, sitzt im Konfigurations-Dickicht.

Die ehrliche Einordnung dazu:

Wenn die Entwickler wüssten, was sie uns im Alltag zumuten …

Power Automate ist mächtig, aber für Nicht-Techies in der jetzigen Form mühsam. Es bleibt klar erkennbar Entwickler-Werkzeug.

Copilot Studio Workflows als Gegenentwurf

Deutlich angenehmer fällt der Vergleich mit den Workflows direkt im Copilot Studio aus. Hier wird derselbe Use Case in wenigen, klaren Schritten gebaut:

1. Trigger wählen: Über die Connector-Liste z. B. SharePoint → „Element erstellt oder geändert“ auswählen.
2. Setup ausfüllen: Drei Felder – Site, Liste, Triggerart – und der Auslöser steht.
3. Bedingung definieren: Aus der bereits verbundenen SharePoint-Liste werden alle Spalten direkt angeboten. Du wählst das Feld Status und den Wert bereit für Agent – fertig.
4. Status aktualisieren: Eine weitere Aktion setzt den Status auf in Bearbeitung, damit klar ist, dass der Datensatz übernommen wurde.
5. Agent triggern: Über die Aktion „Agent“ wählst du aus deiner bestehenden Agent-Liste den gewünschten Agenten aus und übergibst ihm einen Prompt mit den relevanten Werten aus der Liste.
6. Ergebnis zurückschreiben: Am Ende aktualisiert der Flow die SharePoint-Zeile erneut, schreibt das Ergebnis zurück und setzt den Status auf fertig, damit eine angebundene App weiß, dass der Beitrag bereitsteht.

Entscheidender Unterschied: Die SharePoint-Verbindung ist nur einmal nötig. Danach kennt der Workflow alle Spalten und Werte und bietet sie automatisch in den folgenden Schritten an – kein doppeltes Konfigurieren, kein erneutes „in welche Liste gucken wir gleich nochmal?“.

Prompt-Erstellung mit KI

Für den Prompt, der an den Agenten übergeben wird, kommt erneut KI ins Spiel: Statt selbst zu tüfteln, welche Variablen wie eingebunden werden müssen, lässt sich der Prompt direkt von einer KI generieren – inklusive der korrekten Platzhalter für die SharePoint-Werte. Ein kleiner Schritt, der den Bau eines solchen Workflows zusätzlich beschleunigt.

Fazit: Wohin der Weg geht

Der Vergleich macht das größere Bild sichtbar:

• Power Automate liefert mit Copilot zwar einen Entwurfs-Boost, bleibt in der Detailarbeit aber ein Entwickler-Tool mit vielen manuellen Schritten und unsauberen Auto-Vorschlägen.
• Copilot Studio Workflows kommen dem deutlich näher, was sich Endanwender wünschen: Klick-basiert, mit smarter Wiederverwendung bestehender Verbindungen, ähnlich angenehm wie vergleichbare Schritte in Langdoc oder anderen modernen Tools.

Die klare Empfehlung an dieser Stelle: Wer als Nicht-Techie mit Microsoft-Mitteln Prozesse automatisieren will, sollte zuerst prüfen, ob sich der Use Case in Copilot Studio Workflows abbilden lässt – und Power Automate erst dann anfassen, wenn es wirklich nötig ist. Sobald diese Workflow-Welt breit verfügbar ist, bringt sie eine spürbare Erleichterung beim Bauen genau solcher Agent-getriebenen Prozesse.

In diesem Q&A-Segment geht es um die Abgrenzung von Microsoft Copilot Studio zu Tools wie Langdock, die neue tokenbasierte Abrechnung bei Workflows mit eingebauten Agenten sowie um die Anforderungen, um Microsoft Scout überhaupt nutzen zu können. Du erfährst, warum GitHub-Anbindung und Prepaid-Credits ins Spiel kommen und wann Claude in Comet ein praktischerer Weg sein kann.

Microsoft-Ökosystem vs. Langdock: Wo liegen die echten Unterschiede?

Die erste Frage aus der Gruppe zielt auf den Vergleich zwischen Microsoft und Langdock. Die Antwort ist differenziert:

• Wenn du ohnehin im Microsoft-Ökosystem unterwegs bist, brauchst du nichts mehr zu verknüpfen. Deine Work-IQ wird permanent aktualisiert und in die Systeme zurückgespielt — alles greift ineinander.
• Die Erstellung von Workflows, Prozessen und Apps wirkt bei Microsoft auf den ersten Blick komplizierter. Bei Langdock läuft vieles mit Point-and-Click und einer KI, die direkt zur Hand ist.
• Im Unternehmenskontext dreht sich das Bild: Microsoft bietet deutlich mehr Sicherheits- und Steuerungsmöglichkeiten. IT und Entwickler können fein granular festlegen, wer was darf, wer wo reinschreiben darf, wie Freigaben gestoppt werden. Das ist ein Projekt — Berechtigungsstufen und Rollen müssen sauber vergeben werden — aber genau dort spielt Microsoft seine Stärke aus.
• Wenn du gar nicht im Microsoft-Umfeld bist, lohnt der Wechsel allein wegen dieser Funktion nicht. Dann sind die anderen Lösungen die bessere Wahl.

Die Kernaussage: Microsoft ist „abgefahren integriert“ — du kannst auf alles zugreifen. Manche Dinge sind zugleich „gestachsig“ und ändern sich von einem Tag auf den anderen, weil Microsoft permanent nachschraubt.

Regionale Umgebungen: Warum manche Funktionen erst in US-Umgebungen laufen

Ein Hinweis aus der Gruppe macht ein Hindernis sichtbar: Bestimmte neue Microsoft-Funktionen sind aktuell nur für US, Australien, Asien und Indien freigeschaltet. Läuft dein Account über die Telekom oder einen vergleichbaren europäischen Anbieter, funktioniert es nicht.

Der Workaround: eine neue Umgebung erstellen und z. B. US auswählen — dann läuft es. Wichtig dabei:

• Daten landen dann nicht mehr auf europäischen Servern.
• Nur zum Ausprobieren mit unkritischen Daten nutzen, solange Europa nicht ausgerollt ist.
• Sobald die europäische Freigabe kommt, kehrt man in die heimische Umgebung zurück.

Comet plus Claude als pragmatische Alternative

Aus der Runde kommt zusätzlich der Tipp, Claude in Comet zu aktivieren — nicht für das gesamte Unternehmen, sondern personenbezogen. Damit lassen sich Flows aufbauen, indem man Claude einfach sagt: „Bau mir das.“

Stand heute ist dieser Weg in vielen Fällen einfacher als der Bau über die KI in Power Apps. Der Unterschied: Bei Comet entscheidet am Ende immer die KI, welche Schritte sie geht. Man kann das per Prompt steuern, aber nicht zu 100 % festzurren — läuft der Flow später erneut, kann ein anderer Weg eingeschlagen werden.

Tokenbasierte Abrechnung: Wann zusätzliche Kosten ins Spiel kommen

Ein zentraler Punkt für die Praxis: Microsoft bewegt sich Richtung tokenbasierter Abrechnung, sobald du tiefer in Workflows mit Agenten einsteigst.

So sieht das konkret aus:

• Ein Agent, den du eigenständig nutzt (z. B. ein LinkedIn-Prozessmanager als Standalone-Agent), läuft ganz normal über dein Copilot-Kontingent. Es wird nichts zusätzlich abgezogen.
• Sobald du denselben Agenten in einen Workflow einbaust, springt ein Prepaid-Kapazitätsmodell an. Das aktivierst du über GitHub.
• Ein Workflow, der gestern noch wunderbar lief, kann von heute auf morgen aussteigen — genau weil der eingebaute Agent jetzt ein eigenes Budget braucht.

Auch der neue Microsoft Scout braucht dieses Zusatzkontingent. Über die 20–30 Euro im Standard-Plan wäre der Betrieb schlichtweg zu teuer. Es gibt sogenannte Credits, im Einstieg sind rund 1000 Credits enthalten.

Empfehlung aus dem Call: Geh diesen Aktivierungspfad nicht allein durch. Entweder holst du dir jemanden mit Erfahrung dazu — oder du arbeitest die Schritte gemeinsam mit einer KI durch. Im Beispiel wurde der Setup-Pfad mit Claude geklärt, nicht mit Copilot direkt.

Microsoft Scout: GitHub als zwingende Voraussetzung

Für Microsoft Scout sind mehrere Vorarbeiten nötig:

1. Copilot Business bei GitHub muss eingerichtet sein.
2. Es sind mehrere Anmeldeformulare durchzulaufen, damit Scout am Ende Zugriff auf deine Daten hat.
3. Das ist nötig, weil Scout Sicherheitskopien bzw. Sicherheitsspeicherungen anlegt — diese landen im GitHub.

Im Live-Call war die Freischaltung noch nicht erfolgt, daher konnte Scout nicht praktisch gezeigt werden.

Ausblick: Comet könnte vieles ersetzen

Die abschließende Einschätzung: Vermutlich wirst du den umständlichen Scout-Pfad gar nicht in voller Tiefe brauchen. Comet deckt bereits den größten Teil dessen ab, was man sich sonst mühsam über Workflow-Prozesse zusammenbauen müsste. Für viele Anwendungsfälle ist das der pragmatischere Weg — schnell, einfach, ohne den Sicherheits- und Berechtigungs-Overhead, der bei Microsoft im Unternehmenskontext sonst dazugehört.

Im Abschluss-Segment der Copilot-Reihe gibt Tanja einen Ausblick auf den App Builder, den Workflows-Agent, Microsoft Scout sowie das kommende Copilot Tuning. Du erfährst, warum unterschiedliche Lizenzen und Berechtigungen die Live-Demo bremsen, wie ein einfacher Mail-Workflow per Prompt entsteht und wohin die Reise mit autonomen Agenten und Computer Use geht. Ein ehrlicher Praxis-Ausblick mit konkreten Tipps für Einsteiger und Nicht-Techies.

Warum die Live-Demo nicht wie geplant lief

Microsoft Copilot ist ein bewegliches Ziel: Lizenzmodelle, Berechtigungen und verfügbare Features unterscheiden sich heute teils stark zwischen den Teilnehmenden. Für Microsoft Scout reicht beispielsweise nicht mehr das klassische Microsoft Business Standard – es braucht zusätzlich eine höhere Einstellstufe, die sich Intune nennt. Erst darüber lassen sich bestimmte Einstellungen überhaupt vornehmen.

Tipp aus der Praxis: Wer noch ein altes Microsoft-Abo mit einem alten Copilot hat (z.B. zu 30 statt 60 Euro im Monat), kann inzwischen upgraden und sich damit die Zugänge zu den neueren Funktionen sichern. Genau dieser Schritt war auch hier nötig, um überhaupt an die neuen Features zu kommen.

Weil nicht alle Teilnehmenden dieselben Zugriffe hatten, blieb die geplante Demo – eine App, die über SharePoint und Power Automate mit dem LinkedIn-Agent kommuniziert – stecken. Diese Übergabepunkte zwischen Tools werden später nachgeholt, sobald die Zugänge stehen.

App Builder im Agent-Bereich als niedrigschwellige Alternative

Auch ohne Copilot Studio gibt es einen Weg, kleine Apps zu bauen: den App Builder im Agent-Bereich. Du findest ihn so:

1. Gehe in den Bereich Agents.
2. Suche nach „App“.
3. Aktiviere und öffne das App Builder-Programm (erkennbar an einem eigenen Icon).

Hier lassen sich Apps per Prompt erstellen – nicht ganz so detailliert wie in Copilot Studio, aber für den ersten Start absolut nutzbar. Das ist ein deutlicher Hinweis, wohin die Reise geht: Microsoft will diese Einstellungen zunehmend so vereinfachen, dass man als Anwender im Frontend bleibt und nicht ins Backend muss.

Workflows-Agent: Prozesse per Prompt automatisieren

Im Frontier gibt es zusätzlich den Workflows-Agent. Er ist nicht so kleinteilig konfigurierbar wie ein Backend-Workflow, reicht aber für die meisten Standardprozesse völlig aus.

Beispiel aus dem Call – ungelesene Mails als Teams-Nachricht:

• Prompt formulieren: ungelesene Mails aus dem Posteingang ziehen, die wichtigsten Punkte zusammenfassen, nur die wichtigsten Informationen, Ausgabe als Teams-Nachricht in Aufzählungszeichen.
• Empfänger und Details werden ausschließlich über den Chat gesteuert – einzelne Felder lassen sich (noch) nicht direkt anklicken und ändern.
• Nach dem Speichern läuft der Workflow automatisch, z.B. jeden Morgen.

Im Hintergrund passiert dasselbe wie bei einem Copilot-Studio-Workflow – das Icon ist sogar fast identisch. Es fehlen nur die feineren Detail-Einstellungen.

Praxisbeobachtung: Nachmittags, wenn die USA wach wird, werden Microsoft und Copilot spürbar langsamer. Wer kritische Workflows live demonstrieren oder bauen will, plant das besser in die Vormittagsstunden.

Microsoft Scout und der Blick auf Wave 3

Scout ist ein autonomer Agent: Du schickst ihm eine Aufgabe, und er arbeitet so lange daran, bis sie erfüllt ist – notfalls auch über drei Tage hinweg. Damit er nicht unkontrolliert Kosten produziert, lässt sich über GitHub mit einer Copilot-Business-Lizenz ein Budget deckeln: bis zu Betrag X darf er arbeiten, danach stoppt er.

Was Scout im Frontier-Bereich kann:

• Dateien lesen, schreiben, durchsuchen, aktivieren, aktualisieren
• Im Browser arbeiten
• Auf das gesamte M365-Umfeld zugreifen
• Autonom entscheiden, welches Tool er wann nutzt

Scout steht damit prototypisch für Wave 3 – die Richtung, in die Microsoft will: Du sagst nur noch dein Ziel („Ich brauche eine Präsentation für mein Gespräch mit Sabine“), und der Agent recherchiert eigenständig den Kontext, die gemeinsamen Themen und baut das Ergebnis.

Copilot Tuning: Agenten feiner individualisieren

Ein weiteres kommendes Feature ist das Copilot Tuning. Wenn du einen Agenten über den Agent Builder baust (nicht über Copilot Studio), wird es demnächst sogenannte Templates geben, die tunable sind. Über die Instructions lässt sich festlegen, dass ein Agent überhaupt tunable sein soll.

Im Tuning-Bereich kannst du dann unter anderem hinterlegen:

• Tonalität des Agents
• Gestaltung der Ausgaben
• Skills, mit denen er arbeitet
• Informationen und Datenquellen, auf die er zugreift
• Bereiche, die er bedienen darf

Wichtig: Dieses Tuning findet nicht im Agenten-Backend statt, sondern in einem eigenen Tuning-Interface. Das gibt Unternehmen und Anwendern deutlich mehr Möglichkeiten, Agenten passgenau zu individualisieren.

Computer Use für eigene Agenten

In Copilot Studio wird es zukünftig möglich sein, beim Erstellen eines Agents zu entscheiden, ob dieser Computer Use haben darf – also Zugriff auf einen virtuellen Computer. Damit kann der Agent, ähnlich wie der bereits gezeigte Researcher-Agent, Seiten aufrufen, klicken, in Details navigieren und so deutlich mehr Informationen bereitstellen. Aktuell steht das noch nicht jedem zur Verfügung, da es sich teils noch in Testphasen befindet.

Tipp für Nicht-Techies: Entwickler einbinden

Ein offener und ehrlicher Hinweis aus dem Call: Für jemanden ohne Entwickler-Hintergrund wirkt vieles davon komplizierter, als es eigentlich ist. Wer Zugang zu einem Entwickler hat, sollte das nutzen. Konkretes Beispiel: Ein befreundeter Entwickler hat über Nacht – eine Ansage am Abend, fertig am nächsten Morgen – einen Anfragen-Vorbau-Agent gebaut. Wer die IDs und Strukturen kennt, kommt offenbar deutlich schneller ans Ziel.

Für dich als Anwenderin oder Anwender heißt das: Du musst nicht jedes Detail selbst beherrschen. Es reicht, die Logik und die Möglichkeiten zu verstehen, damit du gezielt beauftragen kannst.

Fazit der Reihe

Auch wenn diese Session durch Lizenz- und Berechtigungsthemen weniger Hands-on war als geplant, zeigt der Ausblick klar, wohin sich Copilot bewegt:

• App Builder und Workflows-Agent machen Automatisierung im Frontend zugänglich.
• Scout und Wave 3 stehen für wirklich autonome, zielgesteuerte Agenten.
• Copilot Tuning und Computer Use geben dir feinere Kontrolle und mehr Reichweite pro Agent.

Die Richtung: weg von Detail-Konfiguration im Backend, hin zu Zielen, die du formulierst – und einem Copilot, der den Rest erledigt.

Zum Abschluss der fünfteiligen Co-Pilot-Reihe teilen die Teilnehmenden ihre Eindrücke: vom anfänglichen Microsoft-Frust hin zur Erkenntnis, dass Co-Pilot deutlich aufgeholt hat. Es geht um den Wert des Deep Dives, die zentrale Rolle von Co-Work, den Umgang mit Komplexität im Enterprise-Umfeld – und den klaren Wunsch nach einer Fortsetzung über die fünf Module hinaus.

Vom Microsoft-Frust zur neuen Wertschätzung

Ein roter Faden zieht sich durch alle Feedbacks: Am Anfang der Reihe war die Stimmung gegenüber Microsoft Co-Pilot durchwachsen bis enttäuscht. Viele hatten das Tool bereits „ad acta gelegt“. Eine Teilnehmerin bringt es auf den Punkt:

Am Anfang waren ja alle von Microsoft so enttäuscht, viele haben es schon ad acta gelegt – deshalb war es jetzt wichtig zu sehen, die holen auf und bemühen sich wirklich.

Ein Teilnehmer beschreibt sogar eine konkrete Kehrtwende in seiner eigenen Beratungspraxis: Wo er früher abgeraten hat, empfiehlt er heute in Vorträgen — wenn das Umfeld ohnehin Microsoft-lastig ist — beim Co-Pilot zu bleiben. Voraussetzung dafür: selbst sattelfest sein.

Warum der Deep Dive gebraucht wurde

Mehrfach wird betont, wie wichtig die Tiefe der Reihe war. Hätte man nicht bewusst einen extremen Deep Dive gemacht, wären zentrale Eventualitäten und Fallstricke unbesprochen geblieben.

Besondere Lerneffekte aus der Gruppe:

• Die Agents in den Apps und die Co-Work-Funktion werden als „echte Macht“ wahrgenommen, sobald sie breit nutzbar sind.
• Co-Work innerhalb der Programme ist für viele zum Haupt-Arbeitsmodus geworden — auch beim Überarbeiten von Präsentationen.
• Einzelne Features werden bewusst „durchbohrt“, um sie einmal gemacht zu haben, auch wenn man sie später nicht im Alltag nutzt.
• Es braucht Geduld und ein „Eingrooven“ — manche Dinge funktionieren nicht beim ersten Versuch und wollen nachjustiert werden.

Realismus zum Enterprise-Kontext

Ein wiederkehrender Punkt: Im Microsoft-Universum bleiben Dinge aufgrund des Enterprise-Denkens tendenziell komplizierter als in schlankeren Tools. Genau hier sehen sich mehrere Teilnehmende in einer Vermittlerrolle — zwischen IT-Verantwortlichen im Unternehmen und den eigentlichen Anwendern. Die IT komme oft nicht hinterher, welche Möglichkeiten es überhaupt gibt; umso wertvoller ist es, Wege aufzuzeigen und gemeinsam darüber zu sprechen.

Eine wichtige Entlastung kam aus dem Call selbst: Man muss nicht alles selbst bauen können. Es reicht, die Dimension zu verstehen, es einmal gesehen zu haben — und sich für die Umsetzung Entwickler-Freunde an Bord zu holen.

Didaktik und Atmosphäre

Mehrere Stimmen heben die didaktische Qualität der Reihe hervor — angenehm zuzuhören, klar aufgebaut, fokussierter Blick in Bereiche, in die man von allein nicht so tief geschaut hätte. Auch die Moderatorin selbst zieht ein positives Fazit: Die Reihe habe sie gezwungen, fokussierter in bestimmte Themen zu schauen, und sie wolle dranbleiben.

Wunsch nach Fortsetzung

Der deutlichste konkrete Wunsch aus der Gruppe: Nach den fünf Modulen nicht aufhören. Ein Teilnehmer formuliert es pointiert:

Ich fände es toll, wenn wir irgendwie ein Modul 6 bis 28 haben könnten.

Die Wende sei spürbar mit den neuen GPT-Modellen gekommen, und die Entwicklung gehe schnell weiter. Es lohne sich also, gemeinsam dranzubleiben — auch wenn das vielleicht nicht erneut als gebündelte Fünfer-Reihe stattfinden muss. Die Moderatorin nimmt den Impuls mit und kündigt an: Wenn sich Neues durchgearbeitet hat, wird sie zeigen, wie sie es „durchbrochen“ hat. Wer in der Zwischenzeit eigene Anwendungsfälle oder Ideen entwickelt, ist eingeladen, diese einzubringen.

Hier findest du die ungeschnittene Original-Aufzeichnung des kompletten Calls. Du kannst sie ansehen oder das vollständige Transkript herunterladen — der Link wird vom Team final gesetzt.

Diese Aufzeichnung enthält den gesamten Call ohne Schnitt — inklusive Begrüßung, Pausen, Q&A und Abschluss. Sie eignet sich als Backup oder zum Nachschlagen einzelner Stellen, die in den thematischen Segmenten oben nicht enthalten sind. Das vollständige Transkript ist als Textdatei verfügbar — Link wird vom Team final hinterlegt.