Konzepte · Ein Grundlagen-Guide
Copilot Studio: 30 Konzepte, eine mentale Landkarte
Copilot Studio ist kein Chatbot-Baukasten, sondern eine Plattform für Agenten, die wissen, entscheiden und handeln. Wer die Bausteine und ihr Zusammenspiel versteht, baut Lösungen statt Prototypen.
Wer Copilot Studio Grundlagen wirklich verstehen will, braucht keine 30 Definitionen. Er braucht eine Landkarte, die zeigt, wie die Bausteine zusammenspielen.
In meinen Projekten sehe ich immer wieder dasselbe Muster: Ein Team baut in einer Woche einen beeindruckenden Agenten-Prototyp. Danach stockt das Projekt monatelang. Nicht am Prompt, sondern an Berechtigungen, Wissen, Prozessen und Governance. Genau deshalb lohnt sich ein strukturierter Blick auf die Copilot Studio Grundlagen — die Konzepte hinter Microsoft Copilot Studio.
Dieser Beitrag ist mein Grundlagen-Guide: 30 zentrale Konzepte, gruppiert in sechs Stationen — vom Agenten selbst über den Gesprächsablauf, Wissen und Aktionen bis zu Orchestrierung und Enterprise-Betrieb. Jede Aussage ist mit der offiziellen Microsoft-Dokumentation verlinkt. Als roten Faden nutze ich drei Beispiele: einen HR-Agenten für Elternzeit-Fragen, einen IT-Support-Agenten für Ticket-Erstellung und einen Vertriebs-Agenten für Angebotsprozesse.
Copilot Studio in einem Satz
Copilot Studio ist Microsofts grafisches Low-Code-Studio, um KI-Agenten zu erstellen, zu steuern und zu betreiben — Agenten, die Unternehmenswissen nutzen, über Tools und Flows echte Aktionen ausführen und dabei innerhalb definierter Sicherheits- und Governance-Regeln arbeiten (offizielle Übersicht).
Warum sich der Blick auf die Copilot Studio Grundlagen lohnt
Ein Chatbot beantwortet Fragen. Ein Agent erledigt Aufgaben. Das ist der entscheidende Unterschied, und Copilot Studio ist konsequent auf den zweiten Fall ausgelegt. Der HR-Agent aus meinem Beispiel beantwortet nicht nur die Frage „Wie beantrage ich Elternzeit?“. Er prüft die Identität der Person, liest die passende Richtlinie aus SharePoint, startet den Antragsprozess und bestätigt das Ergebnis im Chat.
Damit das funktioniert, greifen viele Bausteine ineinander. Wer nur „einen Agenten anlegen“ lernt, sieht die Spitze des Eisbergs. Wer die Konzepte dahinter kennt, kann Aufwände realistisch schätzen, Risiken früh erkennen und mit Architekten, Fachbereich und Security auf Augenhöhe sprechen. Genau dafür ist diese Landkarte gedacht.
Station 1 — Das Fundament: Agent, Instructions, Modell und Harness
1. Agents
Der Agent ist die zentrale Einheit in Copilot Studio: ein KI-gestützter Assistent mit eigenem Auftrag, eigenem Wissen und eigenen Fähigkeiten. Er kann im Dialog arbeiten oder — über Event Trigger — komplett autonom im Hintergrund. Mein Rat: Denk bei „Agent“ nicht an ein Chatfenster, sondern an einen digitalen Sachbearbeiter mit klar umrissener Stellenbeschreibung.
2. Agent Instructions
Die Instructions sind diese Stellenbeschreibung: Sie legen fest, wie sich der Agent verhält, welchen Ton er trifft und welche Ressourcen er wofür einsetzt. Über Schrägstrich-Referenzen verknüpfst du Tools, Topics und Variablen direkt im Text. Gute Instructions sind konkret: „Beantworte Elternzeit-Fragen ausschließlich auf Basis der HR-Richtlinien und starte bei einem Antrag den Genehmigungs-Flow“ schlägt jede generische Rollenbeschreibung.
3. Models
Unter der Haube arbeitet ein Sprachmodell, und du kannst es pro Agent auswählen. Aktuell ist GPT-4.1 das Standardmodell; GPT-5 Chat und GPT-5.5 Chat sind allgemein verfügbar. Mit Zustimmung der Administration lassen sich sogar externe Modelle wie Anthropic Claude nutzen. Wichtig für die Praxis: Das Modell bestimmt Sprachverständnis und Antwortqualität — aber erst die übrigen Bausteine machen daraus eine Unternehmenslösung.
4. Harness
Der Harness ist die Laufzeitumgebung zwischen deinem Agent-Design und dem Modell: Er entscheidet, wann das Modell aufgerufen wird, welche Komponenten es sieht, und führt die passenden Tools aus. Copilot Studio kennt drei Harnesses: den GitHub Copilot Harness für reasoning-lastige, mehrstufige Aufgaben, den Standard Harness für regelbasierte Agenten mit Topics und Agent Flows sowie den Copilot Chat Harness, der Microsoft 365 Copilot Chat erweitert. Dieses noch junge Konzept erklärt viele Unterschiede in der Dokumentation.
Station 2 — Der Gesprächsfaden: Topics, Trigger, Nodes, Variablen, Verzweigungen
5. Topics
Ein Topic bildet einen abgegrenzten Gesprächsabschnitt ab — im IT-Support-Agenten etwa „Passwort zurücksetzen“ oder „Ticket-Status abfragen“. Du gestaltest Topics grafisch auf dem Authoring Canvas. System-Topics decken Standardsituationen wie Gesprächsstart oder Eskalation ab, Custom Topics deine Fachfälle. Topics geben dem Gespräch Struktur und machen Verhalten testbar.
6. Trigger Phrases
Trigger bestimmen, wann ein Topic startet. In der klassischen Orchestrierung hinterlegst du dafür Trigger Phrases — Microsoft empfiehlt fünf bis zehn Beispielsätze pro Topic. In der generativen Orchestrierung wählt der Agent das Topic dagegen selbst, auf Basis von Name und Beschreibung. Das verschiebt deine Arbeit: weg vom Sammeln von Formulierungen, hin zu präzisen Beschreibungen.
7. Nodes
Innerhalb eines Topics arbeitest du mit Nodes — den einzelnen Bausteinen des Ablaufs: Nachricht senden, Frage stellen, Adaptive Card anzeigen, Bedingung prüfen, Variable setzen, Tool aufrufen. Ein Topic ist damit nichts anderes als eine Kette von Nodes. Wer Flussdiagramme kennt, fühlt sich hier sofort zu Hause.
8. Variables
Variablen sind das Gedächtnis innerhalb eines Gesprächs: Sie speichern Namen, Ticketnummern oder Auswahlentscheidungen. Topic-Variablen gelten im aktuellen Abschnitt, globale Variablen im ganzen Gespräch. Mit der Formelsprache Power Fx transformierst du Werte, und Environment-Variablen binden sogar Secrets aus Azure Key Vault an. Im Vertriebs-Agenten hält eine Variable zum Beispiel die Kundennummer fest, damit niemand sie dreimal eintippen muss.
9. Conditions & Branching
Mit Condition-Nodes verzweigt sich das Gespräch: Ist die anfragende Person Führungskraft, zeigt der HR-Agent zusätzliche Genehmigungsschritte; sonst geht es direkt zum Antrag. Jede Bedingung erhält einen eigenen Zweig, „All Other Conditions“ fängt den Rest ab. Für komplexe Logik stehen wieder Power-Fx-Formeln bereit.
Station 3 — Wissen und Kontext: Woher der Agent seine Antworten nimmt
10. Knowledge Sources
Knowledge Sources verankern den Agenten im Unternehmenswissen: öffentliche Websites, hochgeladene Dokumente, SharePoint, Dataverse oder Unternehmensdaten über Connectors. Die Limits unterscheiden sich je nach Orchestrierung — generativ sind etwa 25 Website-Quellen möglich, klassisch nur vier. Meine Erfahrung: Die Qualität der Wissensquellen entscheidet stärker über die Antwortqualität als jedes Modell-Upgrade.
11. Generative Answers
Der Generative-Answers-Node durchsucht deine Wissensquellen und formuliert daraus eine Antwort mit Quellenangabe. Er arbeitet zugleich als Fallback: Findet kein Topic eine Antwort, springt das System-Topic „Conversational boosting“ ein. Über Einstellungen wie „Search only selected sources“ und die Content-Moderation steuerst du, wie streng der Agent bei unsicheren Antworten bleibt.
12. Prompts
Mit dem Prompt Builder definierst du wiederverwendbare KI-Aufgaben: „Fasse dieses Ticket in drei Sätzen zusammen“ oder „Extrahiere Produktname und Menge aus der Anfrage“. Ein Prompt läuft als Tool auf Agent-Ebene, als Node im Topic oder als Aktion in einem Agent Flow. So kapselst du KI-Logik einmal sauber und nutzt sie an mehreren Stellen.
13. Entities
Entities geben Nutzereingaben Struktur: Datum, E-Mail-Adresse, Bestellnummer oder eine eigene Liste gültiger Produktnamen. Beim Slot Filling erkennt der Agent solche Informationen automatisch im Satz und legt sie in Variablen ab. Sagt jemand „Ich brauche Elternzeit ab dem 1. Oktober“, muss der HR-Agent nicht mehr nach dem Datum fragen — es ist schon da.
Station 4 — Vom Antworten zum Handeln: Tools, Connectors und Flows
14. Tools
Tools — bis 2025 hießen sie „Actions“ — sind die Fähigkeiten, mit denen dein Agent handelt: Connectors, Agent Flows, Prompts, REST-APIs (Programmierschnittstellen), Server nach dem Model Context Protocol (MCP), sogar Computer Use. Bei generativer Orchestrierung sind bis zu 128 Tools pro Agent möglich; Microsoft empfiehlt 25 bis 30. Mein Rat: Weniger, dafür präzise beschriebene Tools schlagen jede lange Liste.
15. Skills
Azure Bot Service Skills binden professionell entwickelte Bot-Bausteine ein — für Teams, die bereits eigene Bots im Azure Bot Service betreiben. Nicht verwechseln: Im GitHub Copilot Harness gibt es zusätzlich ein neueres „Skills“-Konzept im Stil von Coding-Agents. Für den Einstieg reicht es zu wissen, dass Skills der Pro-Code-Anschluss für Entwicklerteams sind.
16. Connectors
Connectors sind vorgefertigte Brücken zu anderen Systemen — die Dokumentation nennt sie treffend „Wrapper um APIs“. Über tausend Standard- und Premium-Connectors der Power Platform stehen bereit, von SharePoint über Salesforce bis ServiceNow; eigene Custom Connectors ergänzen den Rest. Der Vertriebs-Agent legt damit zum Beispiel direkt eine Opportunity im CRM-System an.
17. Connections
Ein Connector braucht eine Connection: die konkrete, autorisierte Verbindung mit Anmeldedaten. Copilot Studio zeigt ihren Status — Connected, Expired, Stale — und regelt, ob der Agent mit den Rechten der Endnutzer oder mit hinterlegten Konten arbeitet. Klingt unspektakulär, entscheidet aber in der Praxis darüber, ob dein Agent nur das sieht, was die fragende Person sehen darf.
18. Agent Flows
Agent Flows sind deterministische Abläufe direkt in Copilot Studio: ein Trigger, dann definierte Aktionen — jedes Mal exakt gleich. Das ist ideal für Genehmigungen, Benachrichtigungen und Systemupdates, bei denen du keine kreative KI, sondern verlässliche Wiederholbarkeit willst. Mein Grundsatz: Die KI entscheidet, was zu tun ist; der Flow erledigt es zuverlässig.
19. Power-Automate-Integration
Copilot Studio und Power Automate sind eng verzahnt: Bestehende Cloud Flows lassen sich in Agent Flows überführen und als Tools in den Agenten einhängen. Wer bereits Automatisierungen in Power Automate betreibt, verliert also nichts — die Investition wandert mit in die Agenten-Welt.
20. Trigger (Event Trigger)
Event Trigger machen Agenten autonom: eine neue E-Mail, ein geänderter Dataverse-Datensatz oder ein Zeitplan startet den Agenten — ganz ohne Chat. Der IT-Support-Agent kann so eingehende Störungsmeldungen nachts vorqualifizieren. Voraussetzung ist die generative Orchestrierung; außerdem laufen Trigger mit den Berechtigungen der erstellenden Person, was du in der Governance berücksichtigen solltest.
Station 5 — Die Regie: Orchestrierung, Connected Agents und Memory
21. Generative Orchestration
Bei der generativen Orchestrierung — dem Standard für neue Agenten — entscheidet der Agent selbst, welches Wissen, welches Tool, welches Topic oder welcher verbundene Agent zur Aufgabe passt. Er plant mehrstufig, füllt fehlende Eingaben nach und kombiniert Bausteine, die du nie explizit verdrahtet hast. Deine Steuerung verlagert sich auf Instructions und saubere Beschreibungen.
22. Topic-Based (Classic) Orchestration
Die klassische Orchestrierung arbeitet dagegen streng nach Drehbuch: Trigger Phrases starten Topics, der Ablauf folgt exakt deinen Nodes. Das gibt maximale Kontrolle und Vorhersagbarkeit — wertvoll in regulierten Prozessen, bei denen jede Formulierung abgestimmt ist. Der Preis: Alles, was du nicht vorhergesehen hast, endet im Fallback.
Generativ
Der Agent plant selbst, kombiniert Wissen, Tools und Topics je nach Aufgabe. Flexibel, aber weniger vorhersagbar — Qualität hängt an Beschreibungen.
Klassisch
Trigger Phrases starten fest definierte Abläufe. Maximale Kontrolle und Compliance-Sicherheit, aber jede Abweichung endet im Fallback.
23. Connected Agents
Ab einer gewissen Größe lohnt sich Arbeitsteilung: Connected Agents lassen einen Hauptagenten Aufgaben an spezialisierte Agenten delegieren — als Child Agents innerhalb desselben Agenten, als eigenständige Copilot-Studio-Agenten oder sogar als externe Agenten über das Agent-to-Agent-Protokoll (A2A). Microsofts Faustregel: Ab etwa 30 bis 40 Aktionen leidet die Qualität eines Einzelagenten — dann wird aufgeteilt. Genau so entsteht aus dem einen „Alleskönner“ ein Team aus HR-, IT- und Vertriebs-Spezialisten.
24. Memory
Memory (aktuell Preview, nur im GitHub Copilot Harness) gibt Agenten ein Gedächtnis über das einzelne Gespräch hinaus: Präferenzen und Kontext einer Person werden erfasst, gespeichert und in künftigen Antworten angewendet. Wichtig für den Datenschutz: Nutzer kontrollieren ihre Memories selbst, Maker können sie nicht einsehen, und nach 28 Tagen Inaktivität werden sie gelöscht. Zusammen mit Connected Agents zeigt Memory, wohin die Reise geht — spezialisierte Agenten, die sich an dich erinnern und zusammenarbeiten.
Station 6 — Enterprise-Reife: Sicherheit, Lifecycle und Betrieb
25. Authentication
Die Authentifizierung klärt, wer vor dem Agenten sitzt. Drei Optionen stehen bereit: keine Authentifizierung, „Authenticate with Microsoft“ über Microsoft Entra ID (Standard im Teams-Kanal) oder manuelle Konfiguration inklusive generischem OAuth2. Erst mit Authentifizierung kann der HR-Agent personenbezogen antworten — und nur das preisgeben, was die angemeldete Person sehen darf.
26. Security & Governance
Die Sicherheits- und Governance-Ebene umfasst Richtlinien zur Data Loss Prevention (DLP, Schutz vor Datenabfluss), Audit-Protokolle in Microsoft Purview, Kundenschlüssel, Sensitivity Labels und Umgebungs-Routing. Bemerkenswert: Mit Microsoft Agent 365 bekommen Agenten eine eigene Kontrollebene mit Entra-Identitäten und Conditional Access — Agenten werden also wie Mitarbeitende verwaltet. Für mich ist das der Punkt, an dem sich ernsthafte Agenten-Strategien von Experimenten trennen.
27. Environments & Solutions
Jeder Agent lebt in einer Power-Platform-Umgebung und liegt technisch in einer Dataverse-Solution. Über eigene Solutions und Pipelines transportierst du Agenten sauber von Entwicklung über Test nach Produktion — klassisches Application Lifecycle Management (ALM, die geordnete Verwaltung des Anwendungs-Lebenszyklus). Wer das von Anfang an einplant, erspart sich später schmerzhafte Umzüge von „mal eben gebauten“ Agenten.
28. Testing & Evaluations
Das Test-Panel zeigt live, welche Topics greifen, welche Tools laufen und was in Variablen steht — bei generativer Orchestrierung sogar als Activity Map des Plans. Dazu kommen Evaluations (Preview): benannte Test-Sets aus Konversationen, die die Antwortqualität wiederholbar bewerten — manuell erstellt, KI-generiert oder per CSV-Import. Damit wird Agent-Qualität endlich messbar statt gefühlt.
29. Publishing & Channels
Mit dem Publishing bringst du den Agenten zu den Menschen: Microsoft Teams und Microsoft 365 Copilot, SharePoint, eigene Websites, mobile Apps, WhatsApp oder Azure-Bot-Service-Kanäle wie Slack. Ein Publish aktualisiert alle verbundenen Kanäle gleichzeitig. Meine Empfehlung: Starte dort, wo deine Zielgruppe ohnehin arbeitet — meistens ist das Teams.
30. Analytics & Monitor
Nach dem Go-live beginnt die eigentliche Arbeit: Die Monitor-Seite (früher „Analytics“) zeigt Sessions, Eskalationen und Antwortqualität — mit bis zu 360 Tagen Datenhistorie. Im GitHub Copilot Harness ergänzt ein eigener Monitor-Tab (Preview) Details zu Aufgaben, genutzten Dateien und verbrauchten Copilot Credits. Ohne diese Zahlen bleibt jede Aussage über den Nutzen deines Agenten eine Vermutung.
Das Zusammenspiel: Eine Anfrage, einmal quer durch die Landkarte
Wie greifen die Bausteine nun ineinander? Verfolgen wir eine einzige Anfrage an den HR-Agenten: „Ich möchte ab Oktober Elternzeit nehmen.“
Der Weg einer Anfrage
- Instructions geben dem Agenten Auftrag und Grenzen vor.
- Die Authentifizierung stellt sicher, dass die Person angemeldet ist.
- Die generative Orchestrierung erkennt die Absicht und plant die Schritte.
- Entities ziehen das Datum „Oktober“ direkt aus dem Satz in eine Variable.
- Generative Answers beantworten Richtlinien-Fragen aus der SharePoint-Knowledge Source.
- Ein Connector-Tool legt über die autorisierte Connection den Antrag im HR-System an.
- Ein Agent Flow startet deterministisch die Genehmigung bei der Führungskraft.
- Der Agent bestätigt das Ergebnis im Chat — und der Monitor zeichnet alles für die Auswertung auf.
Kein einzelner Baustein ist hier spektakulär. Die Stärke liegt im Zusammenspiel — und genau deshalb ist die mentale Landkarte wichtiger als jede Einzeldefinition.
Meine persönliche Einschätzung
Copilot Studio hat sich in kurzer Zeit vom Chatbot-Designer zur Agenten-Plattform entwickelt. Drei Beobachtungen aus meinen Projekten. Erstens: Die generative Orchestrierung verändert das Berufsbild des Makers — statt Dialogbäume zu pflegen, schreibst du präzise Beschreibungen und Instructions. Das ist anspruchsvoller, als es klingt. Zweitens: Die Enterprise-Bausteine — Authentifizierung, DLP, Environments, Evaluations — sind kein lästiger Anhang, sondern der eigentliche Unterschied zwischen Demo und Betrieb. Ein guter Prompt erzeugt einen Prototyp; Identitäten, Berechtigungen, Lifecycle und Monitoring erzeugen eine Lösung.
Drittens: Die Plattform bewegt sich schnell. Actions heißen inzwischen Tools, Analytics heißt Monitor, mit dem Harness-Konzept sortiert Microsoft gerade die gesamte Architektur neu, und Features wie Memory oder Evaluations sind noch Preview. Wer heute einsteigt, sollte Konzepte lernen statt Menüpfade auswendig — die Menüs ändern sich, die Landkarte bleibt.
Ein guter Prompt macht einen Prototyp. Identitäten, Wissen, Governance und Monitoring machen eine Unternehmenslösung.
Meine Empfehlungen für deinen Einstieg
Dein 5-Schritte-Plan
- Starte mit einem echten, kleinen Anwendungsfall. Ein Prozess, ein Team, messbarer Nutzen — nicht der Alleskönner-Agent.
- Investiere zuerst in Wissen und Beschreibungen. Saubere Knowledge Sources und präzise Tool-/Topic-Beschreibungen bringen mehr als jedes Modell-Experiment.
- Kläre Authentifizierung und Berechtigungen vor dem Piloten. Ein Agent, der mehr sieht als seine Nutzer, ist ein Sicherheitsvorfall mit Ansage.
- Plane ALM von Anfang an. Eigene Solution, getrennte Environments, definierter Weg nach Produktion.
- Miss die Qualität. Evaluations als Test-Sets aufbauen und den Monitor wöchentlich lesen — sonst optimierst du blind.
Fazit: Nicht die Bausteine entscheiden, sondern ihr Zusammenspiel
Copilot Studio ist eine Plattform mit vielen beweglichen Teilen — und genau das ist ihre Stärke. Die 30 Konzepte dieser Landkarte sind keine Prüfungsfragen, sondern Orientierungspunkte: Grundlagen, Gesprächsablauf, Wissen, Aktionen, Orchestrierung und Betrieb. Wer sie einordnen kann, erkennt schneller, wo ein Projekt wirklich steht — und was ihm noch zur Unternehmenslösung fehlt.
Jetzt interessiert mich deine Sicht: Welche dieser Konzepte sind aus deiner Erfahrung für den produktiven Einsatz von Copilot Studio am wichtigsten — und woran sind deine Agenten-Projekte bisher gescheitert oder gewachsen? Schreib es mir in die Kommentare oder auf LinkedIn.