Zurück zum Katalog
Microsoft Copilot Studio
Ausgabe 2026. Ein technischer Deep Dive in Microsoft Copilot Studio, der Generative Orchestration, Agent Flows, Tools, Enterprise Grounding und mehr abdeckt (2026).
Aktuelle Wiedergabe
Click play to start
0:00
0:00
1
Generative Orchestration
Entdecken Sie den Paradigmenwechsel von klassischen Trigger-Phrasen zur Generative Orchestration in Microsoft Copilot Studio. Erfahren Sie, wie die KI Topics und Tools basierend auf Beschreibungen dynamisch auswählt und so die Notwendigkeit eines starren Conversational Mappings komplett eliminiert. Diese Episode erklärt, wie intelligentes Routing mühelos Multi-Intent-Anfragen verarbeitet.
2
KI-basiertes Agent Authoring
Lernen Sie, wie Sie natürliche Sprache nutzen können, um Ihren Bot-Building-Prozess zu beschleunigen. Wir untersuchen das KI-basierte Agent Authoring, mit dem Sie komplexe Topics, Prompts und Flows generieren können, indem Sie diese einfach beschreiben. Verstehen Sie, wie LLMs zur Build-Time eingesetzt werden, um schnell Prototypen für Agents zu erstellen.
3
Topics und Nodes
Tauchen Sie in die strukturelle Anatomie eines Agents ein. Diese Episode schlüsselt System Topics gegenüber Custom Topics auf sowie die deterministische Node-Logik, die für spezifische Geschäftsregeln erforderlich ist. Erfahren Sie, wie Sie präzise Conversational Paths mithilfe von Variablen und Bedingungen abbilden.
4
State und Variablen
Geben Sie Ihrem Agent ein Gedächtnis. Entdecken Sie, wie Sie mit Variablen in Copilot Studio arbeiten, um Kontext zwischen Topics zu übergeben und wiederholte Fragen zu vermeiden. Wir untersuchen außerdem die Verwendung von Environment Variables zur sicheren Speicherung von Azure Key Vault Secrets.
5
Entities und Slot Filling
Extrahieren Sie strukturierte Daten aus unstrukturierter natürlicher Sprache. Diese Episode erklärt Prebuilt Entities, Custom Closed Lists, Regex Entities und die Magie des Proactive Slot Filling, das es der KI ermöglicht, Fragen zu überspringen, wenn der Nutzer Informationen bereits im Voraus bereitstellt.
6
Enterprise Knowledge Grounding
Machen Sie Ihre vorhandenen Unternehmensdaten zu einem Conversational Expert. Erfahren Sie, wie Sie SharePoint, Dataverse und öffentliche Websites als Knowledge Sources für Generative Answers anbinden. Entdecken Sie die Grenzen und Möglichkeiten beim Grounding Ihrer KI.
7
Tenant Graph Grounding
Entfesseln Sie die volle Leistung von Microsoft Graph und Semantic Search für hochpräzises Retrieval. Diese Episode untersucht das Tenant Graph Grounding und nutzt Microsoft 365 Copilot-Lizenzen, um riesige Unternehmensdokumente mit tiefem semantischem Verständnis zu durchsuchen.
8
Prompt Tools
Befähigen Sie Ihren Agent, spezifische Datenverarbeitungs- oder Zusammenfassungsaufgaben on the fly auszuführen. Erfahren Sie, wie Sie Prompt Tools erstellen, Templates definieren, Inputs festlegen und Response-Formate direkt in Copilot Studio konfigurieren.
9
Agent Flows
Verbinden Sie Copilot Studio über Agent Flows mit komplexen, mehrstufigen Backend-Automatisierungen. Diese Episode beschreibt detailliert, wie Sie Power Automate Flows als Tools hinzufügen, und betont das kritische Ausführungslimit von 100 Sekunden sowie die Anforderungen an synchrone Responses.
10
Power Platform Connectors
Greifen Sie auf Tausende bestehender APIs im Microsoft- und Drittanbieter-Ökosystem zu. Entdecken Sie, wie Sie Power Platform Connectors als aktive Tools in Ihren Copilot Studio Agents nutzen können, um mühelos mit externen Services zu interagieren.
11
Das Computer Use Tool
Automatisieren Sie Legacy-Systeme ohne APIs mithilfe von Vision-based Automation. Entdecken Sie das Computer Use Tool (in der Preview), das Modelle wie Claude Sonnet 4.5 nutzt, um über eine virtuelle Maus und Tastatur mit grafischen Benutzeroberflächen zu interagieren – komplett mit Enterprise Security Guardrails.
12
User Authentication
Sichern Sie Ihren Agent und schalten Sie personalisierte Erlebnisse frei. Tauchen Sie tief in die User Authentication in Copilot Studio ein und vergleichen Sie 'Authenticate with Microsoft' mit manuellen OAuth2-Setups. Erfahren Sie, wie Sie Scopes konfigurieren und Least Privilege Access sicherstellen.
13
Voice und IVR
Holen Sie Ihren Agent von der Tastatur ans Telefon. Entdecken Sie die Interactive Voice Response (IVR)-Funktionen von Copilot Studio. Erfahren Sie mehr über Speech Recognition, DTMF (Tastatureingaben), Barge-in und die Anpassung von Agent-Stimmen mit SSML.
14
Agent Analytics
Man kann nicht verbessern, was man nicht misst. Diese Episode schlüsselt das Analytics-Dashboard in Copilot Studio auf und erklärt die Hybrid-Ansicht für Conversational vs. Autonomous Sessions sowie den Export von Transkripten für tiefgehende Analysen.
15
Model Context Protocol
Machen Sie Ihre Agents zukunftssicher mit dem offenen Standard für KI-Kontext. Erfahren Sie, wie Sie Copilot Studio in externe Model Context Protocol (MCP)-Server integrieren, um Resources, Tools und Prompts dynamisch einzubinden.
Episoden
1
Generative Orchestration
4m 22sEntdecken Sie den Paradigmenwechsel von klassischen Trigger-Phrasen zur Generative Orchestration in Microsoft Copilot Studio. Erfahren Sie, wie die KI Topics und Tools basierend auf Beschreibungen dynamisch auswählt und so die Notwendigkeit eines starren Conversational Mappings komplett eliminiert. Diese Episode erklärt, wie intelligentes Routing mühelos Multi-Intent-Anfragen verarbeitet.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 1 von 15. Die meisten Bot-Builder verbringen Stunden damit, jede mögliche Phrase vorherzusagen und zu mappen, die ein User tippen könnte. Du fügst fünfzig Variationen eines Support-Requests hinzu, und das System schlägt trotzdem fehl, wenn jemand eine Phrase tippt, die du nicht erwartet hast. Generative Orchestration macht das durch dynamisches Description Matching komplett überflüssig.
Wenn Leute in diesem Kontext das Wort generativ hören, gehen sie oft davon aus, dass es um das Generieren von Conversational Text geht. Das ist hier nicht der Fall. Bei Generative Orchestration geht es strikt um dynamisches Routing und Tool Selection. Es ist die Intelligenz, die entscheidet, welche Action ausgeführt wird, anstatt einfach nur eine Response zu schreiben.
Bei klassischer Orchestration baust du ein Topic und definierst manuell eine Liste von Trigger Phrases. Die Natural Language Understanding Engine verlässt sich auf genau diese Phrases, um den User zu routen. Generative Orchestration entfernt Trigger Phrases komplett. Stattdessen schreibst du eine klare Plain-Text Description für jedes Topic und Tool in deinem Agent. Das zugrundeliegende Large Language Model liest die User Query, evaluiert all deine verfügbaren Descriptions und ermittelt dynamisch den besten Match. Du mappst keine Inputs mehr auf Triggers. Du beschreibst einfach, was deine Tools machen.
Das ändert komplett, wie ein Agent komplexe Inputs verarbeitet. Stell dir einen User vor, der fragt: Wie ist das Wetter in Seattle und wann öffnet der Store?
In einem klassischen Setup crasht das Ganze. Das System erkennt zwei widersprüchliche Intents und rät entweder einen, oder es wirft einen Fallback Error. Generative Orchestration meistert das mühelos. Das Model parst den kompletten Satz und erkennt zwei unterschiedliche Goals. Es scannt deine Descriptions. Zuerst findet es ein Weather Tool. Es extrahiert Seattle aus der User Query, übergibt es als Input Parameter an das Weather Tool und führt es aus. Dann erinnert es sich an die zweite Hälfte vom User Prompt. Es scannt deine Topics erneut, findet dasjenige, das für die Store Business Hours beschrieben ist, und triggert es.
Hier ist die wichtigste Erkenntnis. Der Agent chaint diese Actions automatisch zusammen. Er bearbeitet den Weather Request, geht dann nahtlos in das Store Hours Topic über und kombiniert die Outcomes. Du schreibst keine Routing Logic oder Transition Code, damit das passiert.
Dieser Shift bedeutet, dass die Qualität deines Agents jetzt komplett von der Qualität deiner Descriptions abhängt. Wenn deine Weather Tool Description einfach nur Weather sagt, könnte das Model Schwierigkeiten haben, akkurat zu routen. Wenn die Description sagt, ruft aktuelle Wetterbedingungen für einen bestimmten Stadtnamen ab, wird das Routing exakt. Außerdem, wenn ein User dieses Weather Tool triggert, aber vergisst, die Stadt anzugeben, merkt die Generative Engine automatisch, dass ein Required Parameter fehlt. Sie wird dynamisch eine Frage generieren, um den User nach der Stadt zu fragen, bevor das Tool ausgeführt wird.
Dein Core Takeaway ist folgendes. Generative Orchestration verwandelt Routing von einer fragilen Phrase-Matching-Übung in eine intelligente Capability Search. Das befreit dich, sodass du dich darauf fokussieren kannst, was dein Agent tun kann, anstatt zu raten, wie der User danach fragen wird.
Wenn du die Show unterstützen willst, findest du uns, indem du auf Patreon nach DevStoriesEU suchst. Das war's für diese Folge. Danke fürs Zuhören und keep building!
2
KI-basiertes Agent Authoring
3m 33sLernen Sie, wie Sie natürliche Sprache nutzen können, um Ihren Bot-Building-Prozess zu beschleunigen. Wir untersuchen das KI-basierte Agent Authoring, mit dem Sie komplexe Topics, Prompts und Flows generieren können, indem Sie diese einfach beschreiben. Verstehen Sie, wie LLMs zur Build-Time eingesetzt werden, um schnell Prototypen für Agents zu erstellen.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 2 von 15. Normalerweise bedeutet das Bauen eines Conversational Flows, Nodes auf ein Canvas zu ziehen, Logic Trees manuell zu verknüpfen und alle möglichen Trigger Phrases zu erraten, die dein User tippen könnte. Was aber, wenn du einer AI einfach genau sagen könntest, was du bauen willst, und sie die strukturelle Logik für dich generieren lässt? Dieser Mechanismus nennt sich AI-based Agent Authoring.
Es ist extrem wichtig, das vom AI-Verhalten zur Runtime zu unterscheiden. Developer verwechseln oft Generative AI zur Build Time mit Generative AI zur Runtime. Runtime ist, wenn ein Live-User eine Frage stellt und der Agent dynamisch eine Antwort über eine externe Knowledge Base generiert. Build-Time Authoring ist etwas völlig anderes. Das ist der Fall, wenn du einen AI Assistant im Studio nutzt, um das statische Framework des Agenten selbst zu bauen.
Du startest im Authoring Canvas. Anstatt einzelne Elemente per Klick hinzuzufügen, interagierst du mit der Copilot Authoring Pane. Angenommen, du brauchst einen Flow für Hardware-Rückgaben. Du tippst eine Beschreibung in einfachem Englisch ein und verlangst ein Topic, das den User nach seiner Bestellnummer fragt, checkt, ob das Gerät ein Laptop oder ein Mobile Device ist, und dann basierend auf dem Gerätetyp die richtige Rücksendeadresse liefert.
Wenn du diesen Prompt abschickst, verarbeitet das Natural Language Understanding Model deine Anweisungen und mappt sie direkt auf das interne Node Schema von Copilot Studio. Es generiert automatisch ein Set an verschiedenen Trigger Phrases, die ein echter User sagen könnte, um genau diesen Flow zu initiieren. Es platziert eine Question Node auf dem Canvas, um die Bestellnummer zu erfassen, und weist ihr eine Variable zu. Es erstellt eine Condition Node, um die Logik zwischen einem Laptop und einem Mobile Device zu verzweigen. Dann befüllt es die finalen Message Nodes mit Platzhalter-Rücksendeadressen. Das komplette Grundgerüst des Topics erscheint sofort auf deinem Screen.
Hier ist der entscheidende Punkt: Dieser Authoring-Prozess ist streng iterativ. Du bist nicht gezwungen, die erste Generierung als finales Produkt zu akzeptieren. Wenn du dir den generierten Flow ansiehst und merkst, dass du das Kaufdatum erfassen musst, musst du die Connections nicht manuell trennen und eine neue Node einfügen. Du sagst dem Authoring Copilot einfach, dass er eine Frage nach dem Kaufdatum einfügen soll, und zwar direkt bevor er nach der Bestellnummer fragt. Das zugrundeliegende Model analysiert den aktuellen State deines Canvas, versteht den sequenziellen Einfügepunkt und modifiziert den Flow sicher.
Weil die AI natürliche Sprache direkt in Standard-Components von Copilot Studio übersetzt, behältst du die komplette architektonische Kontrolle. Die generierten Nodes sind keine Black Boxes. Es sind exakt dieselben Elemente, die du auch manuell erstellt hättest. Du kannst in die Condition Branches klicken, die Variablen-Typen anpassen oder den Prompt-Text von Hand umschreiben. Das Language Model übernimmt lediglich das mechanische Zusammenbauen des Canvas.
Die wahre Stärke von AI-based Authoring liegt nicht darin, dass es auf Anhieb fehlerfreie Conversational Flows schreibt, sondern dass es den langsamen, mechanischen Prozess des Node Wirings in einen schnellen Dialog über den Business Intent verwandelt. Danke, dass du dabei warst. Ich hoffe, du konntest etwas Neues mitnehmen.
3
Topics und Nodes
4m 13sTauchen Sie in die strukturelle Anatomie eines Agents ein. Diese Episode schlüsselt System Topics gegenüber Custom Topics auf sowie die deterministische Node-Logik, die für spezifische Geschäftsregeln erforderlich ist. Erfahren Sie, wie Sie präzise Conversational Paths mithilfe von Variablen und Bedingungen abbilden.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 3 von 15. Selbst die fortschrittlichsten KI-Agenten brauchen letztendlich deterministische Logik für spezifische Business Rules. Wenn ein Kunde nach deinen Rückgabebedingungen oder Öffnungszeiten fragt, kannst du dir keine probabilistische Schätzung von einem Language Model leisten. Du brauchst eine strikte, garantierte Antwort. Topics und Nodes geben dir genau diese strukturelle Kontrolle.
Stell dir ein Topic als einen klar definierten Gesprächspfad vor. Es ist ein vordefinierter Dialogbaum, der genau vorgibt, wie dein Agent einen bestimmten Intent behandelt. Dein gesamter Agent ist im Grunde eine Sammlung dieser Topics, die zusammenarbeiten, um den User zu routen. Ein häufiger Punkt für Verwirrung ist die Unterscheidung zwischen System Topics und Custom Topics. Es ist einfacher, als es scheint. System Topics steuern grundlegende Agent-Verhaltensweisen. Sie regeln Core Events wie die Begrüßung eines Users, das Beenden einer Konversation, die Eskalation an einen Menschen oder das Abfangen eines Errors, wenn der Agent den Input nicht versteht. Du kannst ihren Text an deine Brand Voice anpassen, aber du kannst sie nicht löschen. Sie sind fester Bestandteil der Systemarchitektur. Custom Topics sind die Pfade, die du selbst baust, komplett unter deiner Kontrolle, um deine spezifischen Business-Szenarien abzuwickeln.
Innerhalb jedes Topics läuft die Konversation von oben nach unten durch einzelne Schritte, die Nodes genannt werden. Nodes sind die funktionalen Bausteine des Pfads. Um zu verstehen, wie sie interagieren, stell dir ein Custom Topic vor, das für Anfragen zu Öffnungszeiten gedacht ist.
Wenn der User dieses Topic triggert, könnte der erste Schritt in deinem Flow ein Question Node sein. Ein Question Node fordert den User zur Eingabe von Informationen auf und wartet auf eine bestimmte Art von Response. In diesem Fall fragt der Agent, welche Stadt der User besuchen möchte. Sobald der User antwortet, erfasst der Node diese Antwort.
Hier kommt das Variablen-Management ins Spiel. Der Question Node speichert die Antwort des Users automatisch in einer Variable. Du hältst nun einen bestimmten State im Memory, wodurch du die Konversation dynamisch routen kannst, basierend auf dem, was der User gerade gesagt hat.
Hier wird es interessant. Anstatt eine generische Antwort zu liefern, fügst du einen Condition Node hinzu, um diese Variable auszuwerten. Ein Condition Node fungiert als logische Verzweigung. Er prüft den aktuellen State deiner Variable gegen Regeln, die du definierst. Wenn die gespeicherte Stadt New York ist, leitet der Node den Flow in einen Branch. Wenn die Stadt London ist, leitet er den Flow in einen anderen. Du kannst so viele Branches hinzufügen, wie du für verschiedene States brauchst, plus einen Fallback Branch, falls die Variable zu keiner bekannten Stadt passt.
Schließlich platzierst du am Ende jedes Conditional Branches einen Message Node. Ein Message Node gibt einfach Text oder Medien an den User zurück. Der New York Branch trifft auf einen Message Node, der besagt, dass der Store um neun Uhr morgens öffnet. Der London Branch trifft auf einen anderen Message Node, der besagt, dass der Store um zehn Uhr öffnet.
Indem du Question, Variable, Condition und Message Nodes verkettest, gibst du genau vor, wie die Logik abläuft. Das Wichtigste, was du hier mitnehmen solltest, ist, dass Topics deine deterministischen Business Rules in vorhersehbare Pfade isolieren. Das stellt sicher, dass dein Agent zuverlässig antwortet, wenn Präzision wichtiger ist als Generierung.
Danke fürs Einschalten. Bis zum nächsten Mal!
4
State und Variablen
3m 41sGeben Sie Ihrem Agent ein Gedächtnis. Entdecken Sie, wie Sie mit Variablen in Copilot Studio arbeiten, um Kontext zwischen Topics zu übergeben und wiederholte Fragen zu vermeiden. Wir untersuchen außerdem die Verwendung von Environment Variables zur sicheren Speicherung von Azure Key Vault Secrets.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 4 von 15. Am schnellsten frustrierst du einen User, wenn du ihn Infos wiederholen lässt, die er dir gerade erst gegeben hat. Wenn dein Bot nach einem Namen fragt, einen neuen Workflow triggert und dann nochmal nach dem Namen fragt, bricht die User Experience komplett zusammen. Der Mechanismus, der diese Amnesie verhindert, sind State und Variables.
Eine Variable in Copilot Studio speichert Daten, die vom User extrahiert oder von einem Backend-System abgerufen werden. Die wichtigste Entscheidung, die du beim Erstellen einer Variable triffst, ist die Definition ihres Scopes. Zuhörer verwechseln oft Topic-Level Variables mit Global Variables. Eine Topic-Level Variable ist streng lokal. Sie existiert nur, solange ihr Parent Topic aktiv ist. In dem Moment, in dem das Topic endet, wird die Variable aus dem Memory gelöscht. Eine Global Variable hingegen bleibt für die gesamte Dauer der Conversation erhalten. Jedes Topic kann sie lesen und jedes Topic kann sie überschreiben.
Es ist verlockend, alle geteilten Daten zu einer Global Variable zu machen. Mach das nicht. Die übermäßige Nutzung von Global Variables führt zu unvorhersehbaren State-Änderungen, wenn Topics sich gegenseitig unterbrechen. Übergib stattdessen Local Variables direkt zwischen Topics. Stell dir ein Topic namens Greeting vor. Es fragt den User nach seinem Namen und speichert ihn in einer Local Variable. Das Greeting endet und der Flow macht einen Redirect zu einem neuen Topic namens Talk to Customer. Um den Namen zu übergeben, konfigurierst du das Talk to Customer Topic so, dass es Values von anderen Topics empfängt. Du definierst eine Input Variable in diesem Destination Topic. Zurück in deinem Greeting Topic fordert dich die Redirect Node dann automatisch auf, dieser Input Variable einen Value zu mappen. Du übergibst die Local Variable für den Namen durch die Node. Das Destination Topic fängt sie auf, der Bot setzt die Conversation mit dem richtigen Namen fort, und dein Global State bleibt aufgeräumt. Wenn dieses Destination Topic seine Arbeit beendet hat, kann es über Output Variables auch Values an das ursprüngliche Calling Topic zurückgeben.
Damit haben wir die Daten abgedeckt, die während eines Chats generiert werden. Der zweite Teil davon betrifft Daten, die dein Agent braucht, bevor ein Chat überhaupt beginnt. Wenn dein Agent sich mit externen Systemen verbindet, braucht er Credentials. Du speicherst API Keys oder Connection Strings absolut niemals in Conversation Variables. Dafür nutzt du Environment Variables. Environment Variables leben komplett außerhalb der User Session. Sie speichern Konfigurationsdaten, die für den Agenten selbst gelten. So kannst du deinen Bot von einer Development Environment ins Testing und schließlich in die Production verschieben, ohne Values zu hardcoden.
Pass an dieser Stelle gut auf. Wenn du mit hochsensiblen Daten arbeitest, integrieren sich Environment Variables direkt mit Azure Key Vault. Anstatt ein Passwort in Copilot Studio einzufügen, erstellst du eine Environment Variable, die als Secret markiert ist. Diese Variable speichert eine Referenz auf einen bestimmten Key in deinem Azure Key Vault. Während der Runtime ruft der Agent das Secret sicher ab, um den Backend Request zu authentifizieren. Das Secret wird niemals im Authoring Canvas angezeigt, es wird niemals in die Chat Logs geschrieben und es ist von deinen Source Control Exports ausgeschlossen.
Der sicherste State ist ein Scoped State. Halte Conversation Variables also wann immer möglich lokal, übergib sie explizit über Topic-Grenzen hinweg und delegiere System Credentials immer an sichere Environment Variables. Danke fürs Zuhören, Happy Coding zusammen!
5
Entities und Slot Filling
4m 31sExtrahieren Sie strukturierte Daten aus unstrukturierter natürlicher Sprache. Diese Episode erklärt Prebuilt Entities, Custom Closed Lists, Regex Entities und die Magie des Proactive Slot Filling, das es der KI ermöglicht, Fragen zu überspringen, wenn der Nutzer Informationen bereits im Voraus bereitstellt.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 5 von 15. Du baust einen Bot, um Bestellungen anzunehmen, aber er zwingt die User durch fünf nervige Fragen. Der User hat dir bereits alle Details in seiner ersten Message gegeben, doch dein Bot ignoriert diesen Kontext und fragt sie trotzdem einzeln ab. Dieses starre Verhalten frustriert die User, und genau dieses Problem wird durch Entities und Slot Filling gelöst.
Über Entities erkennt Copilot Studio reale Dinge aus unstrukturierter natürlicher Sprache. Stell dir eine Entity wie einen spezifischen Data Type vor, auf den dein Bot trainiert ist, ihn in einem Satz zu erkennen. Anstatt die ganze Phrase "Ich möchte zwanzig Euro ausgeben" zu analysieren, sucht die AI einfach nach der Money Entity und extrahiert den Value zwanzig.
Copilot Studio bringt eine große Auswahl an Prebuilt Entities mit. Diese verarbeiten Standard-Datenkonzepte out of the box. Prebuilt Entities erkennen Alter, Datum, Farben, Zahlen, Namen und Geld. Sie normalisieren die Daten automatisch. Egal ob der User zwanzig Dollar, das Dollarzeichen gefolgt von 20 oder zwanzig Bucks eintippt – die Prebuilt Money Entity extrahiert den exakten numerischen Value und die Währung.
Aber dein Business nutzt eine spezifische Terminologie. Um diese zu erfassen, baust du Custom Entities. Es gibt zwei Haupttypen von Custom Entities, die du nutzen wirst. Der erste ist eine Closed List Entity. Du definierst eine strikte Liste von erlaubten Items und hängst dann Synonyme an jedes Item an. Wenn du Outdoor-Ausrüstung verkaufst, erstellst du vielleicht eine Product Category Entity mit einem Primary Item namens Wandern. Dann fügst du Synonyme wie Trekking, Backpacking und Trail Walking hinzu. Wenn der User eines dieser Synonyme eintippt, mappt die AI seinen Input direkt auf den Primary Value Wandern.
Der zweite Custom Type ist die Regular Expression, oder Regex Entity. Du nutzt Regex Entities, wenn User formatierte Strings anstelle von bestimmten Wörtern eingeben müssen. Ein typischer Use Case ist ein Support Ticket oder eine Order ID. Wenn dein System Tracking Numbers nutzt, die immer mit den Buchstaben TRK gefolgt von fünf Ziffern beginnen, definierst du dieses Pattern mit Regex. Die AI scannt die Message des Users und extrahiert sauber genau diesen String, wobei jeglicher umgebende Text ignoriert wird.
Die Entity zu identifizieren, ist nur der erste Schritt. Du musst diese Daten speichern, um sie zu nutzen. Diese Action nennt man Slot Filling. Du mappst eine extrahierte Entity auf eine Variable und füllst den Slot mit den Daten des Users.
Hier wird es interessant. Copilot Studio nutzt ein Feature namens Proactive Slot Filling. Standardmäßig evaluiert die Natural Language Understanding Engine jede User Message gegen alle Variablen, die dein Conversation Topic benötigt. Wenn die AI die benötigten Entities im initialen Input des Users erkennt, füllt sie diese Slots sofort.
Stell dir einen User vor, der dein Purchasing Topic mit dem Satz triggert: "Ich möchte Wanderschuhe unter 100 Dollar kaufen". Du hast eine Custom Closed List Entity für die Product Category und nutzt die Prebuilt Money Entity für das Budget. Dank Proactive Slot Filling verarbeitet die AI diesen gesamten Satz auf einmal. Sie isoliert Wandern, mappt es auf deine Category Variable und speichert es. Sie isoliert 100 Dollar, mappt sie auf deine Budget Variable und speichert das.
Weil diese Slots bereits gefüllt sind, überspringt der Bot die Question Nodes "Welche Kategorie suchst du?" und "Wie hoch ist dein Budget?" komplett. Der Conversation Flow springt direkt darüber hinweg und geht direkt zur nächsten fehlenden Information.
Indem du strikte Entities definierst und darauf vertraust, dass Proactive Slot Filling die Extraction übernimmt, hörst du auf, starre Decision Trees zu schreiben, und fängst an, Conversational Agents zu bauen, die die Zeit des Users respektieren.
Das war's für diese Folge. Danke fürs Zuhören und keep building!
6
Enterprise Knowledge Grounding
4m 15sMachen Sie Ihre vorhandenen Unternehmensdaten zu einem Conversational Expert. Erfahren Sie, wie Sie SharePoint, Dataverse und öffentliche Websites als Knowledge Sources für Generative Answers anbinden. Entdecken Sie die Grenzen und Möglichkeiten beim Grounding Ihrer KI.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 6 von 15. Die größte Herausforderung beim Bauen eines Conversational Agents war früher, jede User-Frage vorherzusagen und die Antworten manuell zu verfassen. Du hast Wochen damit verbracht, Dialogue Trees zu mappen, nur damit die User dann etwas fragen, das leicht vom Skript abweicht, und in einer Sackgasse landen. Enterprise Knowledge Grounding stellt dieses Modell komplett auf den Kopf. Anstatt Antworten zu schreiben, übernehmen deine bestehenden Enterprise-Daten die ganze harte Arbeit.
Ein generisches Large Language Model ist zwar sehr redegewandt, weiß aber absolut nichts über dein spezifisches Unternehmen. Enterprise Knowledge Grounding schließt diese Lücke, indem es den Copilot direkt mit deinen tatsächlichen Geschäftsdaten verbindet, wie zum Beispiel öffentlichen Websites, SharePoint-Verzeichnissen, hochgeladenen Files und Dataverse-Tabellen.
Nehmen wir mal ein Customer-Support-Szenario. Du brauchst einen Agent, der Fragen zu deiner Hardware beantwortet. Anstatt hunderte von Custom Topics zu bauen, lädst du deine PDF-Produkthandbücher in den Copilot hoch und fügst die URL deiner öffentlichen Dokumentationsseite ein. Wenn ein User fragt, wie man ein bestimmtes Router-Modell zurücksetzt, durchsucht der Copilot diese angebundenen Sources, holt sich den relevanten Text und synthetisiert eine direkte Antwort. Er liefert auch einen Citation-Link zurück zum spezifischen Handbuch oder zur Webseite, damit der User die Infos verifizieren kann.
Ein häufiger Verwirrungspunkt ist, wo genau dieses Wissen innerhalb der Architektur liegt. Du kannst Wissen an zwei verschiedenen Stellen anhängen: auf Agent-Level oder auf Topic-Level.
Agent-Level-Wissen ist global. Es funktioniert wie ein Sicherheitsnetz für den gesamten Copilot. Wenn ein User eine Frage stellt und kein manuell erstelltes Topic getriggert wird, macht das System einen Fallback auf diesen globalen Wissenspool. Es durchsucht all deine angebundenen Agent-Level-Sources, um eine Response zu generieren. Das heißt, du bekommst sofortigen Mehrwert, ohne irgendwelche Custom Conversation Flows schreiben zu müssen.
Hier ist der entscheidende Punkt. Manchmal brauchst du strikte Kontrolle darüber, welche Daten die AI nutzt, und genau da kommt das Topic-Level-Wissen ins Spiel. Du konfigurierst das, indem du eine Generative Answers Node direkt in den Authoring Canvas eines bestimmten Custom Topics ziehst.
Wenn ein User ein Custom Topic für die Bearbeitung eines Garantieanspruchs triggert, willst du nicht, dass die AI Antworten von deiner allgemeinen Marketing-Website zieht. Indem du eine Generative Answers Node innerhalb dieses spezifischen Topics nutzt, kannst du die Data Source exklusiv auf einen SharePoint-Ordner mit rechtlichen Garantiedokumenten beschränken. Die AI ist exakt auf den Kontext dieses Conversation-Steps gescoped.
Wenn du diese Enterprise-Sources anbindest, handhabt das System den Zugriff intelligent. Bei öffentlichen Websites indexiert der Copilot einfach die öffentlichen Pages. Bei internen Quellen wie SharePoint nutzt der Copilot die Entra ID Credentials der Person, die mit dem Bot interagiert. Er respektiert strikt die bestehenden File-Permissions. Wenn ein Mitarbeiter keinen Zugriff auf ein bestimmtes internes Dokument in SharePoint hat, wird der Copilot dieses Dokument nicht lesen und es nicht verwenden, um seine Frage zu beantworten.
Für strukturierte Daten kannst du dich direkt mit Dataverse-Tabellen verbinden, wodurch der Copilot seine Antworten auf den Live-Records deiner Business-Applications grounden kann.
Eine Generative Answers Node innerhalb eines Custom Topics zu nutzen, erlaubt es dir, die genauen Grenzen des AI-Wissens an bestimmten Punkten in einer Conversation strikt zu kontrollieren. Das verhindert, dass breite, globale Daten hochspezifische Workflows verwässern. Das war's für diese Folge. Danke fürs Zuhören und keep building!
7
Tenant Graph Grounding
3m 56sEntfesseln Sie die volle Leistung von Microsoft Graph und Semantic Search für hochpräzises Retrieval. Diese Episode untersucht das Tenant Graph Grounding und nutzt Microsoft 365 Copilot-Lizenzen, um riesige Unternehmensdokumente mit tiefem semantischem Verständnis zu durchsuchen.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 7 von 15. Die Standard-Keyword-Suche stößt an ihre Grenzen, sobald ein User eine differenzierte Frage zu einer internen Richtlinie stellt. Du brauchst keine besseren Keywords. Du brauchst ein System, das die tatsächliche Bedeutung der Frage über riesige Datensätze hinweg versteht. Genau hier setzt Tenant Graph Grounding an.
Tenant Graph Grounding bringt ein tiefes semantisches Verständnis direkt in deine Unternehmensdaten. Lass uns zuerst ein häufiges Missverständnis ausräumen. Das ist keine Standard-Dataverse-Suche, und es hat auch nichts mit dem Scraping öffentlicher Websites zu tun. Das ist eine fortschrittliche Enterprise-Retrieval-Funktion, die deinen Copilot direkt mit Microsoft Graph verbindet. Sie wurde speziell dafür entwickelt, komplexes internes Wissen zu verarbeiten, das in deinem Tenant gespeichert ist.
Um dieses Feature zu nutzen, muss deine Umgebung ein paar strikte Voraussetzungen erfüllen. Du brauchst eine Microsoft 365 Copilot-Lizenz. Deine Daten müssen vom Semantic Index für Copilot indexiert sein. Und ganz wichtig: Dein Copilot muss mit Microsoft Entra ID Authentication konfiguriert sein. Das ist nicht optional. Der Copilot muss die Identität der fragenden Person sicher an Microsoft Graph übergeben.
Stell dir einen internen HR-Copilot vor, der dafür entwickelt wurde, riesige Mitarbeiterhandbücher zu durchsuchen. Diese Handbücher liegen oft als riesige Dokumente in SharePoint oder OneDrive. Standard-Retrieval-Tools scheitern oft an großen Dateien, aber Tenant Graph Grounding unterstützt Dateigrößen von bis zu 512 Megabyte. Wenn ein Mitarbeiter nach einem sehr spezifischen Szenario fragt, wie zum Beispiel der Elternzeitregelung für eine in Teilzeit arbeitende zweite Betreuungsperson, sucht eine herkömmliche Search Engine nach genau diesen Wörtern. Wenn das Handbuch eine andere Formulierung verwendet, schlägt die Suche fehl.
Hier ist der entscheidende Punkt: Weil dieses Feature den Semantic Index nutzt, mappt es die konzeptionellen Beziehungen zwischen der User Query und den Unternehmensdaten. Es versteht, dass die Query zur Elternzeit konzeptionell auf einen Abschnitt namens Familienauszeit gemappt wird, selbst wenn die Keywords nicht perfekt übereinstimmen.
Der Logic Flow läuft komplett innerhalb deiner sicheren Tenant-Grenzen ab. Ein User sendet einen Prompt an den Copilot. Der Copilot nutzt das Entra ID Token dieses spezifischen Users, um Microsoft Graph abzufragen. Microsoft Graph durchsucht dann den Semantic Index, schaut sich aber nur Dateien an, für die dieser spezifische User bereits Leserechte hat. Wenn ein Dokument zugangsbeschränkt ist, ignoriert der Graph es für diesen User einfach.
Der Graph ruft die hochrelevanten semantischen Matches ab und gibt sie an den Copilot zurück. Der Copilot nutzt dann genau diese Data Chunks, um eine präzise, grounded Antwort zu generieren. Die gesamte Transaktion passiert mit nahezu sofortiger Präzision und umgeht die Latenz und Ungenauigkeit, die entstehen, wenn man versucht, eigene Custom Search Indexes über SharePoint-Daten zu bauen.
Tenant Graph Grounding verlagert die gesamte Retrieval-Last von deiner Custom Logic direkt auf die semantische Infrastruktur von Microsoft 365. Das garantiert, dass dein Copilot bestehende Enterprise-Datengrenzen respektiert und gleichzeitig unübertroffene kontextuelle Genauigkeit liefert. Wenn du die Show unterstützen möchtest, findest du DevStoriesEU auf Patreon. Das war's für diese Folge. Danke fürs Zuhören und keep building!
8
Prompt Tools
4m 10sBefähigen Sie Ihren Agent, spezifische Datenverarbeitungs- oder Zusammenfassungsaufgaben on the fly auszuführen. Erfahren Sie, wie Sie Prompt Tools erstellen, Templates definieren, Inputs festlegen und Response-Formate direkt in Copilot Studio konfigurieren.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 8 von 15. Manchmal musst du keine komplexe API bauen oder einen externen Parsing-Service integrieren, um eingehende Daten zu verarbeiten. Du brauchst einfach nur ein Large Language Model, das sich einen unstrukturierten String ansieht und ihn genau so verarbeitet, wie du es willst. Genau da kommen Prompt Tools ins Spiel.
Zuerst müssen wir ein häufiges Missverständnis ausräumen. Prompt Tools sind komplett anders als Generative Answers. Generative Answers scannen eine externe Knowledge Base oder eine Website, um User-Fragen dynamisch zu beantworten. Prompt Tools suchen nicht nach Antworten. Es sind spezifische, stark optimierte Instructions, die einem Large Language Model sagen, dass es einen strikt definierten Task auf den Daten ausführen soll, die du bereitstellst.
Stell dir ein Prompt Tool als eine wiederverwendbare Function vor, bei der die zugrundeliegende Logik in natürlicher Sprache statt in Code geschrieben ist. Du baust es, indem du ein Prompt Template definierst, Input-Variablen festlegst und strikte Kontextregeln vorgibst.
Stell dir ein typisches Szenario vor. Du erhältst einen Block aus unstrukturiertem, ausschweifendem Kunden-Feedback. Du willst das zugrundeliegende Sentiment extrahieren und eine saubere Liste mit spezifischen Action Items generieren. Anstatt komplexe Regular Expressions oder ein Custom Parsing Script zu schreiben, erstellst du ein Prompt Tool.
Du fängst damit an, die Inputs zu definieren. In Copilot Studio erstellst du eine Input-Variable namens feedback text und legst ihren Datentyp fest. Dieser einfache Schritt sagt dem Tool, dass es bei jedem Aufruf durch das System einen dynamischen String erwarten soll.
Als Nächstes schreibst du das Prompt Template. Das ist das Core Instruction Set, das an das Language Model gesendet wird. Du schreibst präzise auf, was das Model tun muss. Du weist es an, die feedback text Variable zu lesen, zu bestimmen, ob der Ton positiv, negativ oder neutral ist, und alle Tasks zu identifizieren, die das Customer Support Team basierend auf dem Text bearbeiten muss.
Hier ist die wichtigste Erkenntnis. Das Template ist ohne strikten Kontext praktisch nutzlos. Du fragst das Model nicht einfach nach dem Sentiment und hoffst, dass es nett antwortet. Du definierst die exakte Output-Struktur innerhalb des Prompt-Kontexts. Du weist das Model explizit an, das Ergebnis als striktes JSON Object formatiert zurückzugeben, das einen sentiment Key und ein action items Array enthält. Du verbietest Conversational Filler. Dieser Kontext verwandelt eine generische, gesprächige Language Model Response in einen vorhersehbaren, strukturierten Data Payload, den deine Downstream-Systeme auch wirklich parsen können.
Wenn dein Agent dieses Tool während einer Live Conversation triggert, ist der Execution Flow komplett automatisiert. Der Agent nimmt die Live-Kundenantwort und übergibt sie an deinen feedback text Input. Das Tool injiziert diesen String dynamisch in dein Template, sendet das komplette Instruction-Paket an das Model und gibt das strukturierte JSON zurück. Der Agent kann diese extrahierten Action Items dann nutzen, um automatisch eine Database zu updaten oder den User an eine spezialisierte Support Queue weiterzuleiten.
Du definierst das Tool einmal, und der Agent ruft es automatisch auf, wann immer er erkennt, dass unstrukturierter Text verarbeitet werden muss. Ein gut durchdachtes Prompt Tool verlagert die Last der komplexen Textverarbeitung von deinem Application Code auf das Language Model, sodass du perfekt strukturierte Daten aus dem kompletten Chaos extrahieren kannst – und das mit nichts weiter als ein paar Zeilen einfachem Englisch. Das war's für diese Folge. Danke fürs Zuhören und keep building!
9
Agent Flows
3m 47sVerbinden Sie Copilot Studio über Agent Flows mit komplexen, mehrstufigen Backend-Automatisierungen. Diese Episode beschreibt detailliert, wie Sie Power Automate Flows als Tools hinzufügen, und betont das kritische Ausführungslimit von 100 Sekunden sowie die Anforderungen an synchrone Responses.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 9 von 15. Dein Agent muss einen komplexen Backend-Workflow ausführen, der mehrere Systeme umfasst. Vielleicht muss er eine isolierte Datenbank abfragen, die Daten filtern und gleichzeitig ein Inventarsystem aktualisieren. Ein einzelner API Call kann diese Orchestrierung nicht bewältigen. Die Lösung ist ein Agent Flow.
Agent Flows verbinden Copilot Studio mit Power Automate. Sie ermöglichen es dir, eine mehrstufige Automation als eigenständiges Tool zu verpacken, das dein Agent selbstständig triggern kann. Der Agent verlässt sich dabei komplett auf den Namen und die Beschreibung, die du für den Flow angibst. Basierend auf diesem Text entscheidet der Agent, ob der Flow den aktuellen User Request lösen kann. Wenn er einen Match findet, extrahiert der Agent die nötigen Parameter aus der Unterhaltung, übergibt sie an den Flow, wartet auf die Execution und nutzt den finalen Output, um eine Antwort zu generieren.
Die Struktur eines Agent Flows ist strikt. Er muss mit einem spezifischen, für Copilot designten Trigger starten, der die Text- oder Number-Inputs explizit definiert. Er muss mit einer spezifischen Action enden, die an Copilot zurückmeldet und die Text- oder Number-Outputs definiert. Alles zwischen diesen beiden Nodes ist Standard-Power-Automate-Logik. Du kannst durch Arrays loopen, Custom Connectors aufrufen oder Files parsen.
Stell dir ein Szenario vor, in dem dein Agent die Bestellhistorie aus einer Legacy-SQL-Datenbank abrufen muss. Der User fragt nach seinen letzten Bestellungen. Der Agent triggert den Flow und übergibt den Customer-ID-String als Input. Innerhalb des Flows baust du die Logik, um dich mit der SQL-Datenbank zu verbinden, die Query auszuführen und die rohen Datenbank-Rows in einen sauberen JSON-String zu formatieren. Der Flow gibt diesen formatierten String dann über den Response Node an den Agenten zurück. Der Agent liest den String, extrahiert die Order-Details und antwortet dem User in natürlicher Sprache.
Hier ist der entscheidende Punkt. Die Execution muss komplett synchron ablaufen. Der Agent initiiert den Flow und hält die Connection offen, während er auf die Response wartet. Wenn du einen asynchronen Flow baust, wird er nicht als Agent Tool funktionieren. Du darfst keine Steps einbauen, die die Logik pausieren. Wenn dein Flow eine Approval-E-Mail sendet und darauf wartet, dass ein Mensch einen Button klickt, wird der Agent abbrechen. Das Tool Pattern erfordert einen sofortigen Return der Daten.
Das bringt uns zu einem harten System Limit. Du hast exakt einhundert Sekunden. Ab dem Moment, in dem der Agent den Flow triggert, hat die Logik einhundert Sekunden Zeit, jeden Step auszuführen, die Datenbank abzufragen, den Output zu formatieren und die Response zurückzusenden. Wenn der Legacy-SQL-Server unter Last steht oder dein Flow durch zu viele Records iteriert, wird die Execution das Timeout Limit überschreiten. Wenn das passiert, droppt der Agent die Connection komplett und gibt eine Error Message an den User zurück.
Um dieses Limit zu handhaben, musst du den Scope der Automation eng fassen. Wenn ein Backend-Prozess fünf Minuten dauert, lass ihn nicht innerhalb des Agent Flows laufen. Nutze den Flow stattdessen, um einen externen Background Job anzustoßen und dem Agenten sofort eine Tracking-ID zurückzugeben.
Deine Automation-Architektur muss das Timeout-Fenster respektieren. Designe deine Flows so, dass sie schnell ausführen, exakt das abrufen, was benötigt wird, und die Control an den Agenten zurückgeben. So stellst du sicher, dass der User niemals mit einer hängenden Connection spricht.
Das war's für diese Folge. Danke fürs Zuhören und keep building!
10
Power Platform Connectors
4m 24sGreifen Sie auf Tausende bestehender APIs im Microsoft- und Drittanbieter-Ökosystem zu. Entdecken Sie, wie Sie Power Platform Connectors als aktive Tools in Ihren Copilot Studio Agents nutzen können, um mühelos mit externen Services zu interagieren.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 10 von 15. Du verbringst Tage damit, Custom API-Integrationen zu schreiben und zu pflegen, nur damit dein Agent mit der Außenwelt kommunizieren kann. Dabei warten in deiner Environment schon Tausende vorgefertigte Wrapper nur darauf, ausgeführt zu werden. Heute schauen wir uns Power Platform Connectors an.
Connectors sind standardisierte API-Wrapper. Sie bieten Microsoft Copilot Studio einen verlässlichen Weg, um mit externen Services zu kommunizieren. Bevor wir uns anschauen, wie sie funktionieren, müssen wir ein häufiges Missverständnis klären. User verwechseln oft die Nutzung eines externen Systems als Knowledge Source mit der Nutzung als Tool. Wenn dein Agent eine Datenbank abfragt, nur um Fakten abzurufen und seine Antworten in der Konversation zu untermauern, ist das passives Wissen. Einen Connector als Tool zu nutzen, ist etwas anderes. Das ist eine aktive Operation. Du gibst dem Agenten die Berechtigung, im Namen des Users Actions auszuführen, Records zu erstellen oder externe Prozesse zu triggern.
Es gibt drei Kategorien von Connectors. Standard Connectors decken grundlegende Microsoft Services und gängige öffentliche Endpoints ab. Premium Connectors erfordern spezielle Lizenzen und verbinden sich mit Enterprise-Systemen wie Salesforce oder ServiceNow. Wenn das System, das du erreichen musst, eine interne proprietäre API ist, kannst du einen Custom Connector bauen. Ein Custom Connector ist einfach nur ein OpenAPI-Wrapper, den du selbst definierst. Sobald er in deiner Environment registriert ist, verhält er sich genau wie die Standard und Premium Connectors. Dem Agenten ist es egal, wer ihn gebaut hat.
Schauen wir uns an, wie diese Logik in einem konkreten Szenario abläuft. Du möchtest, dass dein Agent eine Projektzusammenfassung erstellt und sie per E-Mail an dein Engineering-Team schickt. Anstatt manuell einen HTTP Request zusammenzubauen, fügst du den Office 365 Outlook Connector direkt als Action in deinen Copilot ein. Jeder Connector stellt spezifische Operations bereit. In diesem Fall wählst du die Action zum Senden einer E-Mail aus.
Das ist der entscheidende Teil. Du schreibst keinen prozeduralen Code, um genau vorzugeben, wann diese E-Mail verschickt wird. Stattdessen definierst du die Parameter, die der Connector braucht, um zu funktionieren. Der Outlook Connector braucht eine Zieladresse, eine Betreffzeile und den Body-Text. Du konfigurierst diese Inputs und lieferst eine klare Beschreibung in natürlicher Sprache, was die Action macht.
Copilot verlässt sich komplett auf diese Beschreibung, um zu entscheiden, wann das Tool getriggert wird. Wenn ein User dem Agenten sagt, er soll das wöchentliche Status-Update an das Engineering-Team schicken, evaluiert der Agent seine verfügbaren Tools. Er gleicht den User Request mit der Beschreibung deines Outlook Connectors ab. Der Agent extrahiert dann dynamisch den Namen des Empfängers und den Text der Zusammenfassung aus der laufenden Konversation. Er mappt diese extrahierten Werte auf die Connector Inputs und feuert die Action ab.
Sobald die externe API den Request verarbeitet hat, gibt der Connector eine Response an den Agenten zurück. Das kann ein einfacher Success Code sein oder ein Payload mit spezifischen Details zur Transaktion. Der Agent empfängt diese Daten, verifiziert, dass die Action abgeschlossen wurde, und generiert eine Response in natürlicher Sprache, die dem User mitteilt, dass die E-Mail verschickt wurde.
Durch die Standardisierung des Interfaces nehmen dir diese Wrapper die Notwendigkeit ab, Authentication Tokens, Headers und Error Handling für jeden einzelnen Service zu verwalten. Du konfigurierst die Connection einmal, und der Agent orchestriert die Ausführung. Connectors verwandeln deinen Agenten von einem statischen Conversational Interface in ein operatives Tool, das tatsächlich den State in deiner Infrastruktur verändert. Das war's für diese Folge. Danke fürs Zuhören und keep building!
11
Das Computer Use Tool
3m 25sAutomatisieren Sie Legacy-Systeme ohne APIs mithilfe von Vision-based Automation. Entdecken Sie das Computer Use Tool (in der Preview), das Modelle wie Claude Sonnet 4.5 nutzt, um über eine virtuelle Maus und Tastatur mit grafischen Benutzeroberflächen zu interagieren – komplett mit Enterprise Security Guardrails.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 11 von 15. Wenn eine Anwendung keine API hat, stößt traditionelle Automatisierung an ihre Grenzen. Entweder schreibst du fehleranfällige Skripte, die kaputtgehen, sobald sich ein Button verschiebt, oder du akzeptierst manuelle Dateneingabe. Das Computer Use Tool löst dieses Problem, indem es deiner AI buchstäblich erlaubt, den Bildschirm zu sehen und die Maschine selbst zu bedienen.
Dieses Feature ist als Preview verfügbar und erlaubt es deinem Agenten, über eine virtuelle Maus und Tastatur mit einem Graphical User Interface zu interagieren. Es basiert auf Computer-Using Agents, die von Vision-fähigen Modellen wie Anthropics Claude 3.5 Sonnet angetrieben werden. Es ist wichtig klarzustellen, was das nicht ist. Das ist keine traditionelle Robotic Process Automation. Standard-RPA verlässt sich auf zugrundeliegende strukturelle Hooks, wie DOM-Tags oder UI-Element-IDs. Das Computer Use Tool arbeitet ausschließlich mit Pixeln.
Der Logic Flow ist eine kontinuierliche Schleife. Das Tool macht einen Screenshot der Desktop-Umgebung und übergibt ihn an das Model. Das Model analysiert das visuelle Layout, interpretiert den User Request und berechnet präzise Koordinaten für seinen nächsten Move. Es gibt Instructions an das System zurück. Das System übersetzt diese, indem es den virtuellen Cursor an eine bestimmte X- und Y-Position bewegt, einen Mouse-Button klickt oder einen String von Keystrokes sendet. Nach der Ausführung der Action macht das Tool einen weiteren Screenshot, um den neuen State des Bildschirms zu bewerten. Es verifiziert, ob sich ein Fenster geöffnet hat oder Text erschienen ist, bevor es über den nächsten Schritt entscheidet.
Stell dir ein Szenario vor, in dem du Daten aus einer Legacy-Windows-Desktop-App extrahieren und in ein modernes Web-Formular eingeben musst. Der Agent schaut sich den Screenshot der Legacy-App an, lokalisiert visuell die Rechnungsnummer und speichert diese Information. Anschließend gibt er Instructions aus, um die Maus zum Browserfenster zu bewegen, in das Ziel-Feld des Web-Formulars zu klicken und die Ziffern einzutippen. Er navigiert das Interface genau wie ein menschlicher Operator, komplett gesteuert vom visuellen Kontext auf dem Display.
Einem AI-Model die physische Kontrolle über einen Desktop zu geben, erfordert strenge Security Controls. Hier ist der entscheidende Punkt: Du deployest das niemals auf einem Production-Server oder der primären Workstation eines Users. Der Agent muss innerhalb einer dedizierten, isolierten Virtual Machine oder eines Containers operieren. Du gewährst dieser Umgebung die absoluten Minimum-Privileges, die nötig sind, um den spezifischen Task abzuschließen. Da das Model selbstständig in Webbrowsern navigieren kann, musst du strenge Network Controls erzwingen. Du wendest eine URL-Allowlist an, damit der Agent nur auf genehmigte Domains zugreifen kann. Das verhindert, dass er mit nicht vertrauenswürdigen Websites oder externen Services interagiert. Du stellst außerdem sicher, dass die Virtual Machine keine sensiblen Daten außerhalb des unmittelbaren Workloads enthält.
Indem du das Graphical User Interface einfach als einen weiteren visuellen Input-Stream behandelst, schließt du die Lücke zwischen intelligentem Reasoning und unzugänglicher Legacy-Software, ohne eine einzige Zeile Integration-Code zu schreiben. Das war's für dieses Mal. Danke fürs Zuhören und keep building!
12
User Authentication
3m 42sSichern Sie Ihren Agent und schalten Sie personalisierte Erlebnisse frei. Tauchen Sie tief in die User Authentication in Copilot Studio ein und vergleichen Sie 'Authenticate with Microsoft' mit manuellen OAuth2-Setups. Erfahren Sie, wie Sie Scopes konfigurieren und Least Privilege Access sicherstellen.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 12 von 15. Ein Agent ist nur so leistungsfähig wie die Daten, auf die er zugreifen kann. Aber wenn dein Agent ein privates System abfragt und versehentlich deinen persönlichen Kalender einem völlig anderen Mitarbeiter ausliefert, hast du eine massive Sicherheitslücke. Um das zu verhindern, musst du die User Authentication korrekt konfigurieren.
Der häufigste Fehler, den Entwickler hier machen, ist das Vermischen von Maker-Credentials mit End-User-Credentials. Wenn du deine eigenen API Keys oder Service Principal Credentials in eine Agent Action einbettest, führt der Bot diese Actions in deinem Namen aus. Jeder, der mit dem Agenten chattet, umgeht seine eigenen Sicherheitslimits und greift mit deinen Permissions auf Daten zu. Die User Authentication zwingt den Agenten, Queries genau als die Person auszuführen, die den Prompt eingibt, und verlässt sich dabei komplett auf deren eindeutige Identität.
In Copilot Studio wählst du primär zwischen zwei Authentifizierungs-Status: Authenticate with Microsoft und Authenticate manually. Authenticate with Microsoft ist der optimierte Weg für interne Tools. Wenn dein Agent ausschließlich in Microsoft Teams oder Power Apps läuft, verwendet diese Einstellung automatisch das Microsoft Entra ID Token der Person, die gerade in der Applikation angemeldet ist. Es gibt keinen separaten Login Prompt. Der User Context fließt einfach zum Agenten durch.
Du wechselst zu Authenticate manually, wenn dein Agent auf einer externen Custom Website lebt, oder wenn du strikte, granulare Kontrolle über Permissions brauchst. Diese Methode basiert auf dem Setup einer OAuth2 Connection zu einem Identity Provider, was typischerweise eine App Registration in Microsoft Entra ID ist.
Nehmen wir ein konkretes Szenario. Du baust einen Agenten, der den persönlichen Kalender eines Mitarbeiters checkt. Du konfigurierst Authenticate manually und verlinkst es mit deiner Entra ID App Registration. Hier ist die entscheidende Erkenntnis. Der Agent bekommt keinen pauschalen Access auf das gesamte Microsoft-Konto des Users. Stattdessen definierst du in deiner Config strikte Scopes. Du konfigurierst die Authentication Node so, dass sie einen spezifischen Scope namens Calendars dot Read anfordert.
Wenn ein User den Agenten nach seinem Kalender fragt, pausiert der Agent seine Logik und zeigt eine Sign-in Card im Chat an. Der User klickt auf den Link, authentifiziert sich über seinen Browser und sieht einen Screen, der ihn auffordert, dem Agenten Read Access auf seinen Kalender zu gewähren. Sobald er zustimmt, generiert Microsoft Entra ID ein Access Token und gibt es sicher an den Agenten zurück.
Dieses Access Token ist strikt an diesen individuellen User gebunden und ausschließlich auf den Calendar Scope beschränkt. Wenn der Agent den eigentlichen HTTP Request macht, um den Kalender abzurufen, fügt er dieses Token bei. Die Backend API inspiziert das Token, bestätigt die User Identity und gibt sicher nur dessen spezifische Kalender-Events zurück. Die User Authentication richtig hinzubekommen, ist das, was einen generischen Chatbot in einen personalisierten Assistenten verwandelt. Es beweist deinen Backend-Systemen genau, wer nach Daten fragt, sodass du niemals private Informationen über Sessions hinweg leakst.
Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.
13
Voice und IVR
4m 23sHolen Sie Ihren Agent von der Tastatur ans Telefon. Entdecken Sie die Interactive Voice Response (IVR)-Funktionen von Copilot Studio. Erfahren Sie mehr über Speech Recognition, DTMF (Tastatureingaben), Barge-in und die Anpassung von Agent-Stimmen mit SSML.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 13 von 15. Die Zukunft des Kundenservice besteht nicht nur aus Text auf einem Bildschirm. Leute rufen immer noch Support-Hotlines an, und wenn sie das tun, erwarten sie eine sofortige, intelligente Antwort statt eines endlosen Menübaums. Um diese Lücke zu schließen, musst du deine KI direkt mit Telefonnetzen verbinden. Genau darum geht es heute: Voice und IVR.
Einen in Copilot Studio gebauten Agent ans Telefon zu bringen, bedeutet, ihn für einen Telephony Channel zu konfigurieren, meistens über Dynamics 365 oder Azure Communication Services. Das verwandelt deine Logik in ein Interactive Voice Response System, das auf native Speech Recognition setzt, um das Audio des Anrufers in Text umzuwandeln, und auf Text-to-Speech Engines, um zu antworten. Aber Chat-Logik in Voice-Logik zu übersetzen, bedeutet auch, mit den physischen Gegebenheiten eines Telefonanrufs umzugehen.
Stell dir einen Kunden vor, der eine Support-Hotline anruft. Der Bot geht ran und fängt an, eine vorgeschriebene rechtliche Begrüßung oder eine Liste von Optionen vorzulesen. Der Anrufer weiß aber schon, dass er zur Rechnungsabteilung muss. Wäre das ein Text-Chat, würde er seine Frage einfach eintippen. Am Telefon spricht er einfach über den Bot drüber. Dafür brauchst du ein Feature namens Barge-in. Wenn Barge-in nicht enabled ist, ignoriert das System eingehendes Audio, bis der Bot sein Playback komplett beendet hat. Ist Barge-in aktiv, hört der Speech Recognizer gleichzeitig zu. In dem Moment, in dem er erkennt, dass der User spricht, stoppt er sofort den Text-to-Speech Output des Bots und verarbeitet das eingehende Audio. Das bildet den natürlichen Fluss einer menschlichen Unterhaltung nach und verhindert, dass sich Anrufer von einer Maschine gefangen fühlen.
Nachdem der Anrufer den Bot unterbrochen hat, wird er nach einer Account-Nummer gefragt. Er könnte die Zahlen laut aussprechen, aber vielleicht ist er in einem vollen Raum. Stattdessen tippt er die Zahlen auf seinem Display ein. Das bringt uns zu DTMF, oder Dual-Tone Multi-Frequency. Leute verwechseln DTMF Handling oft mit Standard-Text-Inputs, aber das sind völlig unterschiedliche Mechanismen. DTMF verarbeitet Interaktionen über das Telefon-Keypad global im gesamten Telephony Network. Wenn ein Anrufer eine Taste drückt, sendet das Netzwerk einen spezifischen Frequenzton. Copilot Studio fängt diese Töne direkt ab. Du konfigurierst Input Nodes so, dass sie auf DTMF-Sequenzen lauschen, die resultierenden Ziffern extrahieren und sie als Variablen speichern. Du kannst eine maximale Anzahl an Ziffern erzwingen, Timeouts setzen und einen Termination Character definieren – zum Beispiel, indem du den User anweist, die Rautetaste zu drücken, wenn er mit der Eingabe fertig ist.
Hier ist der entscheidende Punkt. Nur den Input zu erfassen, reicht nicht aus. Die Art und Weise, wie dein Agent antwortet, entscheidet darüber, ob der Anrufer auflegt. Default Text-to-Speech kann ziemlich flach klingen. Um das zu fixen, nutzt du SSML, oder Speech Synthesis Markup Language. Anstatt Plain Text an die Voice Engine zu senden, packst du deine Responses in Markup Tags. Mit SSML kannst du den Pitch steuern, die Speaking Rate anpassen und bestimmte Aussprachen erzwingen. Wenn dein Firmenname ein Akronym ist, kannst du die Engine per SSML zwingen, ihn Buchstabe für Buchstabe vorzulesen, anstatt zu raten, wie er als Wort klingt. Du kannst präzise Pausen einfügen, zum Beispiel eine halbe Sekunde nach einer komplexen Anweisung, damit der Anrufer die Information verarbeiten kann.
Für Voice zu entwickeln bedeutet, die Telefonleitung als einzigartiges Interface zu behandeln und Unterbrechungen, Keypad-Töne und Audio Pacing zu berücksichtigen. Die effektivsten Voice Agents zwingen User nicht in starre Audio-Menüs. Sie kombinieren nahtloses Barge-in und präzises DTMF Handling, um dem Anrufer einfach aus dem Weg zu gehen. Danke fürs Zuhören. Bis zum nächsten Mal!
14
Agent Analytics
3m 33sMan kann nicht verbessern, was man nicht misst. Diese Episode schlüsselt das Analytics-Dashboard in Copilot Studio auf und erklärt die Hybrid-Ansicht für Conversational vs. Autonomous Sessions sowie den Export von Transkripten für tiefgehende Analysen.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 14 von 15. Du deployst deinen Agenten endlich, testest ihn selbst, und alles sieht perfekt aus. Eine Woche später sinkt die User-Zufriedenheit und Background-Prozesse schlagen unbemerkt fehl. Das Problem ist nicht dein initialer Build, sondern dein fehlender Einblick in das Production-Verhalten. Das Tool, um das zu fixen, ist Agent Analytics.
Agent Analytics bietet eine Unified View darauf, wie dein Agent performt, sobald er echte Workloads verarbeitet. Als Erstes siehst du die Summary-Page. Diese dient als Command Center. Sie aggregiert Key Performance Indicators wie Total Sessions, Engagement Rate, Resolution Rate und Escalation Rate. Anstatt zu raten, ob dein Agent den Usern hilft, analysieren die Summary AI Insights den User Intent und zeigen dir genau, welche Topics zu erfolgreichen Resolutions führen und welche die User dazu bringen, die Session abzubrechen oder nach einem Menschen zu fragen.
Hier ist das Key Insight: Copilot Studio trackt zwei grundlegend verschiedene Arten von Sessions, und das Dashboard präsentiert sie in einer Hybrid View. Erstens hast du Conversational Sessions. Die sind genau das, wonach sie klingen. Ein User öffnet ein Chatfenster und chattet mit dem Agenten hin und her. Die Analytics tracken die Dialogue Turns, das User Sentiment und das Topic Triggering. Zweitens hast du Autonomous Sessions. Diese laufen komplett im Background. Sie werden durch externe Events getriggert, wie zum Beispiel einen neuen Record, der in einer Datenbank erstellt wird, oder eine eingehende E-Mail, und nicht durch einen User, der eine Message tippt. Es gibt kein Chat-Interface. Die Analytics tracken, ob der Agent seine Background-Logic erfolgreich abgeschlossen hat oder ob er auf einen Error gestoßen ist.
Du brauchst beide Views, um einen Agenten healthy zu halten. Stell dir ein Szenario vor, in dem du dieses Hybrid-Dashboard reviewst. Deine Conversational Metrics sehen gut aus, aber du bemerkst einen plötzlichen Spike bei den Failure Rates. Das Filtern nach Session Type zeigt, dass die Errors alle in Autonomous Sessions passieren. Ein eventgetriggerter Prozess, der Order-Status updaten soll, schlägt im Background fehl. Das Summary-Dashboard sagt dir, dass es einen Failure gibt, aber es sagt dir nicht die genaue Zeile der Logik, die ihn verursacht hat.
An diesem Punkt wechselst du vom Dashboard zu den Rohdaten. Copilot Studio speichert detaillierte Execution Logs als Transcripts in Microsoft Dataverse. Du lädst das spezifische Transcript für die fehlgeschlagene Autonomous Session herunter. Wenn du das Transcript liest, bekommst du den Step-by-Step Trace der Execution. Du kannst die genaue Variable sehen, die einen ungültigen Value übergeben hat, den fehlerhaften Node genau lokalisieren und die Logik fixen, ohne den Error blind reproduzieren zu müssen.
Das Dashboard sagt dir, wo du suchen musst, aber das Transcript sagt dir, was du fixen musst. Wenn du dabei helfen willst, dass es weiterhin solche technischen Breakdowns gibt, kannst du die Show supporten, indem du auf Patreon nach DevStoriesEU suchst. Das war’s für diese Folge. Danke fürs Zuhören und keep building!
15
Model Context Protocol
3m 47sMachen Sie Ihre Agents zukunftssicher mit dem offenen Standard für KI-Kontext. Erfahren Sie, wie Sie Copilot Studio in externe Model Context Protocol (MCP)-Server integrieren, um Resources, Tools und Prompts dynamisch einzubinden.
Hallo, hier ist Alex von DEV STORIES DOT EU. Microsoft Copilot Studio, Folge 15 von 15. Du verbringst Wochen damit, Custom Plugins zu bauen, damit dein Agent deine internen Datenbanken abfragen und Actions triggern kann. Dann launcht eine neue Plattform, und du musst genau dieselben Integrationen wieder von Grund auf neu schreiben. Die Lösung für diesen endlosen Kreislauf redundanter Arbeit ist das Model Context Protocol.
Das Model Context Protocol, oder MCP, ist ein offener Standard, der AI-Modelle mit externen Datenquellen und Tools verbindet. Indem du einen offenen Standard nutzt, machst du deine Agenten effektiv zukunftssicher. Du schreibst die Integrationslogik genau einmal, hostest sie auf einem MCP-Server, und jeder kompatible AI-Client kann sie sofort nutzen. Copilot Studio fungiert als einer dieser Clients.
Stell dir ein Szenario vor, in dem dein Engineering-Team auf 50 verschiedene interne Diagnose-Scripts und Echtzeit-Logfiles angewiesen ist. Du willst nicht manuell 50 separate Actions in Copilot Studio erstellen und mappen. Stattdessen konfigurierst du deinen Agenten so, dass er sich direkt mit deinem proprietären internen MCP-Server verbindet. Wenn der Agent initialisiert wird, fragt er den Server, was er tun kann. Der Server antwortet mit einer Liste von Capabilities und gibt dem Agenten sofort Zugriff auf alle 50 Engineering-Tools und Live-File-Resources.
Ein MCP-Server stellt deinem Agenten drei Hauptkomponenten bereit. Das sind Resources, Tools und Prompts. Resources sind Read-only-Datenquellen. Wenn dein Agent ein Live-Config-File oder einen Database-Record checken muss, stellt der MCP-Server diese Daten als Resource bereit und lädt sie direkt in den Context des Modells. Tools sind ausführbare Funktionen. Wenn der Agent entscheidet, dass er eine Virtual Machine restarten oder ein Engineering-Ticket updaten muss, ruft er das entsprechende MCP-Tool auf, und der externe Server führt die Action aus. Prompts sind vordefinierte Instruction-Templates, die vom Server bereitgestellt werden. Sie geben dem Agenten genau vor, wie er Queries formatieren oder die spezifischen Daten dieses externen Systems interpretieren soll.
Hier ist der entscheidende Punkt. Leute nehmen oft an, dass Copilot Studio, wenn du einen MCP-Server connectest, permanente Kopien dieser Tools in sein eigenes User Interface importiert und speichert. Aber so funktioniert das nicht. Die Tools und Resources werden komplett extern gehostet. Copilot Studio liest dynamisch, was der Server zur Runtime exposed. Wenn dein Engineering-Team ein einundfünfzigstes Diagnose-Tool hinzufügt oder die Parameter eines bestehenden Scripts modifiziert, updaten sie einfach den externen MCP-Server. Copilot Studio übernimmt diese Änderungen automatisch. Du musst dich nie ins Studio-Interface einloggen, um die Action neu zu publishen oder zu updaten.
Weil die Logic komplett auf dem Server liegt, behältst du eine Single Source of Truth für deine Organisationsdaten und Actions. Der Agent bleibt lightweight und fungiert lediglich als Reasoning Engine, die entscheidet, wann sie mit dem Server kommuniziert.
Indem du deine Tools von der spezifischen Agent-Plattform trennst, zentralisierst du deine Integrationen und garantierst, dass deine AI immer die neuesten Capabilities hat, unabhängig davon, welches Client-Interface du deployst. Ich empfehle dir wärmstens, die offizielle Documentation zu lesen, hands-on auszuprobieren, einen MCP-Server zu connecten, oder devstories dot eu zu besuchen, um Themen vorzuschlagen, die du in einer zukünftigen Serie sehen möchtest. Das war's für diese Folge. Danke fürs Zuhören und keep building!