Copilot Studio Guide

Was ist Copilot Studio?

Microsoft Copilot Studio ist Microsofts Low-Code-Plattform zum Bauen von Custom Copilots und AI-Agents auf Basis der Power Platform. Du designst dort konversationelle und autonome Agenten – von einfachen FAQ-Bots bis zu Agenten, die selbständig Termine planen, Tickets verarbeiten oder Dokumente bearbeiten.

Technisch sitzt Studio im Power-Platform-Stack neben Power Apps und Power Automate. Es greift auf 1.400+ Konnektoren, Dataverse, Microsoft 365 Graph und seit 2025 auf MCP-Server zurück. Studio ist Microsofts direktes Pendant zu LangDock Workflows oder Zapier mit LLMs – nur tief in den Microsoft-Tenant integriert.

Auslieferung erfolgt in Teams, Microsoft 365 Copilot Chat, im Web, in Power Apps, in eigene Channels via Direct-Line-API oder als Voice-Agent in Dynamics 365 Contact Center.

Lizenzwege (Stand August 2026)

Microsoft hat im Sept 2025 das alte „Per-Message"-Modell durch ein Credit-Modell abgelöst:

Credits werden tenant-weit gepoolt – nicht pro User. Ein simpler scripted FAQ-Bot kostet ~1 Credit/Konversation ($0,01); ein Agent mit Generative Orchestration, Tenant-Grounding und Deep Reasoning kann $0,25–$2,00+ pro Konversation kosten.

Für Power Automate-Flows als Tools gilt: Klassische Cloud-Flows brauchen weiterhin Power-Automate-Lizenzen; Agent Flows (in Studio gebaute Flows) werden vollständig über Copilot-Credits abgerechnet – kein separater PA-User-Plan nötig.

Microsoft bietet seit April 2026 einen Agent Usage Estimator (microsoft.github.io/copilot-studio-estimator) für Credit-Forecasts nach Agent-Typ, Traffic, Orchestration, Knowledge und Tools an – nutze ihn vor jedem Pilot.

Plattformen / Channels

• Web Studio (copilotstudio.microsoft.com) – Authoring
• Microsoft Teams (Personal Chat, ab Toolkit auch Channels & Group Chats)
• Microsoft 365 Copilot Chat (M365 Copilot App)
• Web Chat / Custom Web (React Web Chat oder WebChat JS)
• Direct Line API für eigene Apps & Channels
• SharePoint (eingebettet auf Seiten)
• Power Apps (als Agent-Komponente)
• Power Pages (öffentliche Sites)
• Voice Channel in Dynamics 365 Contact Center (IVR, Real-time Voice Agents)
• Facebook, Slack und weitere via Azure Bot Service Adapter

Feature-Zeitstrahl 2025/2026

Wann lohnt sich Copilot Studio?

Lohnt sich, wenn:

• Du tief in M365 / Teams / SharePoint / Dataverse sitzt und Azure-AD-Login + Permissions „erben" willst.
• Du autonome Agents auf SharePoint/Outlook/Forms-Events brauchst (z. B. „Auto-Triage neuer Tickets").
• Du konversationelle UI in Teams willst (statt CLI / Custom Web-App).
• Du Compliance/Audit über Microsoft Purview brauchst (z. B. AZAV-, GoBD-, DSGVO-Kontext).
• Du Voice-IVR in einem Dynamics 365 Contact Center brauchst.
• Du bestehende Power-Automate-Flows als Tools weiterverwenden willst.

Lohnt sich NICHT als Ersatz für:

• Reines API-Orchestrieren ohne Konversation → da reicht Power Automate (Cloud Flow) oder Logic Apps.
• Maximale LLM-Kontrolle über Prompts, Modelle, Provider → da bist Du in Azure AI Foundry, LangDock oder direkt OpenAI/Anthropic besser aufgehoben.
• Self-hosted / On-Prem-LLMs → Studio ist Cloud-only.
• Vollwertige Customer-Service-Plattform → Studio ist nur das Bot-Frontend; den Human-Hand-off, das Ticketing & das Routing macht Dynamics 365 Customer Service (oder ein Drittsystem via Generic Handoff).
• Pixel-perfekte Web-UIs → Adaptive Cards sind das Limit; alles darüber ist Power Apps / Custom Web.

Das Konzept-Modell

Ein Studio-Agent ist die Top-Level-Einheit. Er besteht aus Persona + Instructions + Topics + Tools + Knowledge + Channels – und lebt in einer Power-Platform-Environment mit eigener DLP- und Audit-Konfiguration.

                ┌──────────────────────────────────────┐
                │           AGENT (= "Copilot")        │
                │                                      │
                │  ┌─────────────┐   ┌──────────────┐  │
                │  │ INSTRUCTIONS│   │ ORCHESTRATION│  │
                │  │  (System    │   │  (Classic vs │  │
                │  │   Prompt)   │   │  Generative) │  │
                │  └─────────────┘   └──────────────┘  │
                │                                      │
                │  ┌──────────┐ ┌──────────┐ ┌──────┐  │
                │  │  TOPICS  │ │  TOOLS / │ │KNOW- │  │
                │  │ (Dialog) │ │ ACTIONS  │ │LEDGE │  │
                │  └──────────┘ └──────────┘ └──────┘  │
                │       │           │           │      │
                │       ▼           ▼           ▼      │
                │   Nodes:      Connector    Web/SP/   │
                │   - Message   Action       Dataverse/│
                │   - Question  PA-Flow      Files/    │
                │   - Condition Agent-Flow   Graph/    │
                │   - Variable  Prompt       MCP/      │
                │   - Action    REST/HTTP    Azure AI  │
                │   - Adaptive  MCP-Tool      Search   │
                │     Card                             │
                │                                      │
                │  ┌──────────────┐  ┌──────────────┐  │
                │  │   TRIGGERS   │  │  CHANNELS    │  │
                │  │ user / event │  │ Teams / Web /│  │
                │  │ /schedule    │  │ Voice / ...  │  │
                │  └──────────────┘  └──────────────┘  │
                └──────────────────────────────────────┘
                              │
                              ▼
                    ┌────────────────────┐
                    │ POWER PLATFORM ENV │
                    │ (DLP, Solutions,   │
                    │  Audit via Purview)│
                    └────────────────────┘

Was Du in Copilot Studio baust

Microsoft hat die Produkt-Übersicht im September 2026 neu geschnitten und benennt seitdem ausdrücklich mehrere Bausteine, die Du einzeln nutzt oder zu einer durchgängigen Lösung kombinierst – ein Workflow darf zum Beispiel einen Agent für einen Schritt rufen. Für die Projektpraxis ist das mehr als Kosmetik: Wer „Copilot Studio“ im Kunden-Workshop weiterhin mit „Chatbot-Baukasten“ übersetzt, verkauft die Plattform seit diesem Schnitt unter Wert.

Apps als neuer Baustein (Public Preview seit September 2026)

Am 10. September 2026 hat Microsoft angekündigt, dass sich in Copilot Studio nicht mehr nur Agents und Workflows bauen lassen, sondern auch Apps. Du beschreibst das Geschäftsergebnis, die Nutzergruppe, die Daten und die gewünschten Aktionen in natürlicher Sprache, iterierst im Gespräch, siehst eine Vorschau und veröffentlichst erst dann. Wer tiefer eingreifen will, kann den erzeugten Code einsehen.

Technisch sind das laut Microsoft Full-Stack-Apps auf offenen Standards – nicht Canvas-Apps im klassischen Power-Apps-Sinn. Sie unterstützen Git-basierte Versionskontrolle, Deployment-Stages und Version Isolation, damit Teams an der nächsten Version weiterbauen können, ohne die laufende zu stören. Identität über Microsoft Entra sowie Organisations- und Connector-Richtlinien gelten standardmäßig. Unternehmensdaten werden über Konnektoren und Work IQ angebunden.

Für die IT-Seite: Veröffentlichte Apps erscheinen als Inventar mit Betriebs-Steuerung im Microsoft 365 Admin Center; Nutzerinnen und Nutzer finden freigegebene, unternehmenstaugliche Apps unter managedapps.cloud.microsoft.com.

Copilot Managed Runtime: wo die Apps laufen (Public Preview seit 25. September 2026)

Seit dem 25. September 2026 hat die Infrastruktur unter den Apps einen Namen: Copilot Managed Runtime (im Licensing Guide vormals »Microsoft-managed host«). Sie ist als Public Preview gestartet und hostet Apps aus Copilot Studio, Copilot Cowork und der CLI; über das Copilot Managed Runtime SDK lassen sich auch Apps aus Drittwerkzeugen wie GitHub Copilot oder Claude Code im eigenen Tenant betreiben. Jede App bekommt Entra-Authentifizierung, Zugriff auf über 1.500 Konnektoren und ein Git-Repository und erbt Conditional Access, DLP, Advanced Connector Policies und Freigabe-Limits automatisch. Der Datenzugriff läuft immer mit der Identität der angemeldeten Person.

Für Admins: Die App-Erstellung in Copilot Studio ist standardmäßig an. Gesteuert wird sie im Microsoft 365 Admin Center unter Apps > Overview > Set up app creation spaces (oder per PowerShell über die Tenant-Einstellung enableManagedAppsMcsPreview), und sie lässt sich per Sicherheitsgruppe auf ausgewählte Maker eingrenzen. Der CLI-Pfad ist standardmäßig aus, Cowork hängt am Frontier-Onboarding. Verwalten dürfen das Global Admins und Power Platform Admins.

Begriffsraster

Ein Studio-Agent kann auf zwei grundsätzlich unterschiedliche Arten loslegen:

• (a) Ein User stellt eine Frage / sendet eine Nachricht – der Agent matched ein Topic.
• (b) Ein Event passiert irgendwo – der Agent startet autonom (kein User im Loop).

User-initiierte Trigger

Autonome / Event-Trigger (seit 2025 GA)

Voraussetzung: Generative Orchestration muss am Agent aktiviert sein. Sonst zeigt das UI die Event-Trigger nicht.

Was Event-Trigger kosten, brauchen und stillschweigend mitbringen

Microsoft hat die Trigger-Doku im September 2026 deutlich ausgebaut. Vier Punkte daraus entscheiden in Projekten häufiger über Erfolg oder Ärger als die Frage, welchen Konnektor Du nimmst:

• Jede Payload ist eine Message. Microsoft zählt jede Trigger-Payload als Nachricht an den Agent – auch wenn niemand mit ihm spricht. Das Doku-Beispiel ist unmissverständlich: Ein Recurrence-Trigger im 10-Minuten-Takt schickt alle 10 Minuten eine Payload und verbraucht entsprechend. Ein autonomer Agent, der im Leerlauf „nur mal schaut, ob was da ist“, wird so schnell zum teuersten Agent im Tenant.
• Weniger als 15 Actions oder Topics am Stück. Microsoft empfiehlt ausdrücklich, weniger als 15 Actions oder Topics hintereinander aufzurufen: Komplexe Agents, die viele Schritte als eine einzige Sequenz fahren, laufen unzuverlässig. Liegt Dein Blueprint darüber, zerlege ihn in Agent Flows oder Child Agents, statt an den Instructions zu feilen.
• Trigger laufen immer auf Maker-Credentials. Event-Trigger können ausschließlich die Anmeldedaten des Agent-Autors nutzen, und für einen autonomen Lauf muss auch jede authentifizierte Action darüber laufen. Nutzer eines veröffentlichten Agents können damit auf Daten und Systeme zugreifen, die mit den Rechten des Makers geöffnet werden. Copilot Studio zeigt vor dem Publish einen Warnhinweis dazu – das ist kein Formfehler, sondern die Kernfrage der Freigabe.
• Ohne Solution-aware cloud flow sharing gibt es gar keine Trigger. Maker können Event-Trigger nur in Environments anlegen, in denen diese Einstellung aktiv ist. Wenn sich kein Trigger hinzufügen lässt und die Data Policies Trigger eigentlich erlauben, ist fast immer das der Grund. Unabhängig davon können Admins Event-Trigger per Data Policy für eine Environment vollständig blocken.

Topics

Ein Topic ist die kleinste sinnvolle „Konversationsschleife". Es hat (1) einen Trigger, (2) eine Sequenz von Nodes, (3) optional Input/Output-Variablen.

Topic-Typen:

• Custom Topics – selbst gebaut.
• System Topics – Microsoft-Default (Greeting, Goodbye, Escalate, Confused, Reset Conversation, On Error, Multiple Topics Matched, ...).
• Generative Answer Topic – Fallback, der bei keinem Match Knowledge Sources durchsucht.

Nodes innerhalb eines Topics

Actions / Tools

Eine Action ist ein „Werkzeug", das der Agent aufruft. Seit 2025 nennt Microsoft das primär Tools.

Knowledge Sources

Knowledge ist „was der Agent weiß", nicht „was der Agent tut".

Wichtig zu wissen: Files, die Sensitivity Labels confidential oder highly confidential tragen, werden zwar als „ready" angezeigt, liefern aber keine Antworten. Sensitivity-Labels (MIP) sind seit Juli 2025 sichtbar in Connectors, Test Chat, Teams und M365 Copilot.

Seitengenaue Zitate für PDFs

Antwortet der Agent aus einem PDF, verweist das Zitat normalerweise auf das ganze Dokument – bei einer 200-seitigen Betriebsvereinbarung hilft das niemandem. Für einen Pfad geht es genauer: PDFs, die über Dateien hochladen → SharePoint eingebunden sind (also in Dataverse gespeichert und indexiert werden), liefern seitengenaue Zitate. Ein Klick auf die Quellenangabe öffnet das PDF in einem neuen Tab direkt auf der zitierten Seite, und der Nutzer kann die Antwort prüfen, ohne das Dokument zu durchsuchen.

Die Grenzen dazu, weil sie in Projekten regelmäßig für Verwirrung sorgen: Es gilt nur für PDFs, alle anderen Dateitypen fallen auf Zitate in Dokument-Ebene zurück. Es gilt nur für diesen einen Einbindungspfad – die vollintegrierte SharePoint-Knowledge-Source und einzeln hochgeladene Dateien zitieren weiterhin auf Dokument-Ebene. Und die Datei muss die Indexierungsschwelle von ungefähr 4 KB erreichen, kleinere PDFs fallen ebenfalls zurück. Wenn seitengenaue Nachvollziehbarkeit ein Compliance-Argument in Deinem Projekt ist, entscheidet also die Wahl des Einbindungspfads darüber, ob Du sie bekommst.

Attachments und erzeugte Dateien (Preview seit Juli 2026)

Seit Juli 2026 können Nutzer Dateien an eine Nachricht anhängen, und der Agent kann im Gespräch selbst Dateien erzeugen. Beides gilt für Agents auf der GitHub-Copilot-Harness und läuft über Copilot Credits – also auch beim Testen im Preview-Tab.

Der wichtigste Punkt zuerst, weil er in Projekten regelmäßig verwechselt wird: Ein Attachment ist keine Knowledge Source.

Was angehängt werden darf: Bilder (.png, .jpg, .gif, .webp; der Agent nutzt vision-fähige Modelle), PDFs (Text wird extrahiert), Textdokumente (.txt, .csv, .html, .md) und URLs. Bei einer URL lädt der Agent die Datei für diesen Turn herunter; der Download muss innerhalb von 30 Sekunden durch sein, und die URL muss öffentlich erreichbar sein. Links hinter Login oder Firewall funktionieren nicht. Scheitert ein Anhang, überspringt der Agent ihn und verarbeitet den Rest der Nachricht weiter – die Nachricht geht trotzdem raus.

Erzeugte Dateien konfigurierst Du nicht, sie entstehen, wenn die Aufgabe eine Datei verlangt: ein Report, eine Tabelle, ein Diagramm, ein Code-Schnipsel oder die überarbeitete Version einer angehängten Datei. Der Agent hängt eine Created-File-Card mit Dateiname, Vorschau und Download-Aktion unter die Antwort. Nutzer können sich in einem Folgeturn darauf beziehen („mach das Diagramm höher“), der Agent liest die Datei zurück und erzeugt eine neue Version.

Anhänge leben also nicht nur für einen Turn: Innerhalb der Aufbewahrungsfrist kann der Agent auf eine früher geschickte Datei zurückgreifen („vergleiche das mit der Datei von vorhin“). Verfügbar sind beide Funktionen überall dort, wo der Agent läuft – Preview-Tab, Microsoft Teams, Microsoft 365 Copilot, Web-Chat – sofern der Kanal Anhänge unterstützt.

Variables / Slots

• Topic Variable – nur in dem Topic sichtbar. Default für User.Name-style Var.
• Global Variable – überall im Agent, persistent über Topic-Wechsel hinweg.
• System Variable – von Studio gemanaged (z. B. System.User.Id, System.Conversation.Id, System.LastMessage, System.Activity.Channel).
• Environment Variable – Solution-Level, ALM-freundlich, z. B. API-URLs pro Env.

Slot Filling: Wenn der User die Frage des Agents „proaktiv" beantwortet (z. B. der User sagt direkt „Buche Frankfurt → Berlin am Freitag" – der Agent extrahiert City, City, Date in einem Rutsch), spricht Microsoft von Slot Filling. Entities (prebuilt oder custom) sind die Voraussetzung.

Authentifizierungs-Bausteine

• No Authentication – anonym; nur sinnvoll für Public Web Chat / Power Pages.
• Authenticate manually mit Microsoft Entra ID v2 – Standard für Enterprise. Federated Credentials bevorzugt (kein gespeichertes Client-Secret).
• Authenticate with Microsoft (SSO) – User-Token wird durchgereicht; Tools/Knowledge laufen im Kontext des Users (Permissions erben!).
• Microsoft Entra External ID – für B2C-Szenarien (Kunden-Login).
• Generic OAuth 2.0 – für eigene Identity Provider.

Wie fließen Daten?

Daten werden über Variablen zwischen Nodes & Topics gereicht. Power Fx ist die Formelsprache.

Ask Question ─► Topic.Name (string)
                │
                ▼
Set Variable   ─► Global.Customer = Topic.Name
                │
                ▼
Condition      ─► If Global.Customer in adminList
                │
                ▼
Call Action    ─► Input: Global.Customer, Output: Action.Result
                │
                ▼
Send Message   ─► "Status: {Action.Result.status}"

Variable-Scopes

Power Fx in Studio

Power Fx ist die Excel-ähnliche Formelsprache der Power Platform. In Studio nutzt Du sie für Set-Variable, Condition-Expressions, String-Manipulation und Datums-/Zahlen-Logik.

// Set Variable: Brutto-Betrag berechnen
Set(Topic.Brutto, Topic.Netto * 1.19)

// Condition: User ist Admin UND Betrag > 1000
Topic.IsAdmin = true And Topic.Amount > 1000

// String-Manipulation: Mail-Domain extrahieren
Last(Split(System.User.Email, "@"))

// Datum: 7 Tage in der Zukunft
DateAdd(Now(), 7, Days)

Gotcha: Power Fx verwendet US-Formatierung – Komma als Parameter-Trenner, Punkt als Dezimalpunkt. Wer aus dem deutschen Excel kommt, stolpert hier regelmäßig.

LangDock-Modi gemappt

In LangDock kannst Du Felder als auto, manual oder AI prompt befüllen. Studio mappt das so:

Das wichtigste Architektur-Switch in Studio: Wählt Du Topics per fest verdrahteten Trigger-Phrasen (Classic) oder lässt Du das LLM anhand von Topic-Descriptions auswählen (Generative)?

Vergleichstabelle

Primärmodell wählen – seit September 2026 zwei getrennte Listen: Welche Modelle Du überhaupt siehst, hängt inzwischen an der Harness, nicht mehr am Produkt. Microsoft pflegt seit September 2026 zwei eigene Verfügbarkeits-Seiten: eine für die Standard-Harness und eine für die GitHub-Copilot-Harness. Die beiden Rosters überschneiden sich nur teilweise, und ein Default-Modell weist Microsoft ausschließlich für die Standard-Harness aus. Die wichtigste Änderung im September: GPT-5.5 Chat hat GPT-4.1 als Default abgelöst, in allen Regionen gleichzeitig (Doku-Stand 18. September 2026).

Ein abgekündigtes Modell bleibt nach dem Retirement noch bis zu einem Monat nutzbar. Externe Modelle lassen sich nach Admin-Freigabe als Primärmodell hinzufügen, und hier weichen die beiden Doku-Seiten voneinander ab: Die Standard-Harness-Seite nennt Anthropic, xAI und Mistral, die Seite der GitHub-Copilot-Harness führt im Fließtext nur noch Anthropic und Mistral und erwähnt xAI ausschließlich in den Admin-Controls. Wer Grok für die neue Erfahrung eingeplant hat, sollte das vor einer Zusage im eigenen Tenant gegenprüfen.

Historie der Modellwahl: Seit Okt 2025 wählst Du in den Agent-Settings das Generative-Orchestration-Modell; die Kategorie Auto (dynamisches Routing pro Konversationsschritt zwischen schnellen und tiefen Modellen) kam im Frühjahr 2026 dazu. GPT-4o wurde im Oktober 2025 abgekündigt, Claude Sonnet 4.5 nach Ablauf der Migrationsfrist am 30.06.2026.

Harnesses: die Runtime-Ebene zwischen Agent und Modell

Seit Ende Juli 2026 dokumentiert Microsoft eine Ebene, die vorher implizit war: die Harness. Du baust den Agent, das Modell liefert Reasoning und Text, und dazwischen sitzt die Harness als Laufzeit. Sie entscheidet, wann das Modell gerufen wird, welche Komponenten mitgeschickt werden, wie die Antwort interpretiert wird und welche Tools laufen. Für die Praxis heißt das: Die Harness bestimmt, welche Features Du überhaupt bekommst und wie abgerechnet wird. Das ist inzwischen die wichtigere Weichenstellung als die alte Frage „Classic oder Generative Orchestration“.

Die „neue Erfahrung“ auf der Copilot-Studio-Startseite ist genau der Umschalter zwischen GitHub-Copilot-Harness und Standard-Harness. Über den Toggle New experience auf der Homepage (bzw. Other ways to build) kommst Du zurück zu klassischen Agents und Agent Flows. Beide Welten bleiben nebeneinander bestehen.

GitHub-Copilot-Harness: seit September 2026 allgemein verfügbar

Am 2. September 2026 hat Microsoft die GitHub-Copilot-Harness für allgemein verfügbar erklärt. Die Runtime selbst ist damit aus der Preview raus und laut Microsoft die empfohlene Basis für Agents und Workflows, die mehrstufig arbeiten, Dateien erzeugen und einen Prozess von Anfang bis Ende automatisieren sollen. Für die Projektpraxis ändert das vor allem die Argumentationslage: Ein GA-Feature lässt sich im Gespräch mit Betriebsrat, Datenschutz und Einkauf anders vertreten als eine Preview.

Lösungen in natürlicher Sprache beschreiben (Preview)

Die Produkt-Übersicht führt seit dem 9. September 2026 einen eigenen Abschnitt Build with natural language als Preview: Du beschreibst das Geschäftsziel, und Copilot Studio entscheidet selbst, welche Kombination aus Agents und Workflows das löst. Verfeinert wird per Rückfrage und Korrektur im selben Gespräch, und es können mehrere Assets in einer Sitzung entstehen – ohne dass Du vorab den Typ festlegst oder zwischen Designern wechselst.

Für Workshops ist das ein echter Gewinn: Die Frage „Brauchen wir hier einen Agent oder einen Flow?“ darf am Anfang offen bleiben, statt die Diskussion zu blockieren. Für die Kostenplanung gilt das Gegenteil – genau dieses Erzeugen per Prompt ist auf der GitHub-Copilot-Harness credit-pflichtig, und zwar ab dem ersten Versuch (siehe Kapitel 10).

Skills: wiederverwendbare Instruktions-Bausteine

Ein Skill ist eine eigenständige Fähigkeit aus Name, Beschreibung und Instruktionen in Markdown. Er ist damit klar abgegrenzt von den anderen Bausteinen: Instructions beschreiben das generelle Verhalten, Knowledge ist Wissen, Tools sind Aktionen über externe Dienste, und ein Skill ist eine aufgabenspezifische Arbeitsweise, die die Orchestration bei Bedarf aktiviert. Die Beschreibung ist der Auslöser, an ihr entscheidet die Runtime, ob der Skill greift, deshalb lohnt sich Sorgfalt genau dort.

Das Format ist bewusst portabel: eine Datei SKILL.md mit YAML-Frontmatter (Name, Beschreibung) plus Markdown-Instruktionen. Als Skill-Paket kommt das Ganze als ZIP mit optionalen Begleitdateien wie Skripten, Templates und Referenzdokumenten. Du kannst Skills in Copilot Studio schreiben, in einem beliebigen Editor bauen und hochladen oder vorhandene GitHub-Copilot- und Claude-Code-Skills übernehmen. Ein Skill wird einmal gebaut und in mehreren Agents verwendet.

Memory: persistenter Kontext pro Nutzer

Memory ist eine produktionsreife Preview und läuft nur auf der GitHub-Copilot-Harness. Der Agent hält für jeden Nutzer einen eigenen Speicher in Microsoft-verwaltetem Storage: Er erfasst Präferenzen und relevanten Kontext (Capture), legt sie als Dateien im nutzereigenen Ordner ab (Store) und liest sie bei späteren Interaktionen wieder ein (Apply). Ein- und ausgeschaltet wird Memory pro Agent über den Toggle im Build-Tab.

Für Datenschutz-Gespräche in der DACH-Region sind vor allem diese Punkte relevant:

• Die Erinnerungen eines Nutzers sind privat. Weder der Maker noch andere Nutzer können sie einsehen.
• Nach 28 Tagen ohne Interaktion löscht das System die Erinnerungen dieses Nutzers zu diesem Agent automatisch.
• In Gruppenchats und Teams-Kanälen ist Memory deaktiviert.
• Jeder Nutzer kann im Memory-Portal alles Gespeicherte ansehen und komplett löschen, oder den Agent im Chat bitten, etwas zu ändern oder zu vergessen. Beim ersten Kontakt in einem neuen Kanal blendet der Agent den Portal-Link selbst ein.

Wann was?

Classic Orchestration ist Dein Default für:

• Hochregulierte Customer-Facing-Bots, bei denen jede Antwort vorhersagbar sein muss
• FAQ- und Routing-Szenarien mit klar definierten Intents
• Bots, die Custom Data Sources oder Bing Custom Search brauchen
• Compliance-Cases, bei denen die Audit-Story „der User hat X gesagt → das Topic ist getriggert" entscheidend ist

Generative Orchestration ist Dein Default für:

• Interne Produktivitäts-Agents mit vielen Tools (10+)
• Autonome Agents auf Event-Trigger (Voraussetzung!)
• Multi-Tool-Chaining, bei dem ein Tool die Eingabe für das nächste liefert
• Szenarien, in denen Topics ähnlich klingen, aber im Detail unterschiedliche Aktionen brauchen

AI-Builder-Prompts als Sub-Prompt

Innerhalb beider Modi kannst Du gezielte LLM-Sub-Prompts als AI-Builder-Actions einbinden – etwa für „Klassifiziere Mail" oder „Extrahiere Datum aus diesem Text". Das gibt Dir den punktuellen LLM-Einsatz, ohne den Agent in den vollen Generative-Modus zu zwingen.

DLP-Policies (Data Loss Prevention)

DLP-Policies kommen aus der Power Platform und gelten auch für Copilot Studio. Du kategorisierst Konnektoren in drei Klassen:

Tenant-weite Policies haben Vorrang vor Env-Policies und sind nicht überschreibbar. Seit Anfang 2025 ist die DLP-Enforcement für alle Agents aktiv – frühere Ausnahmen (Exemption) wurden abgeschafft.

Zusätzlich kannst Du via Policy steuern:

• Welche Tools/Actions zulässig sind (z. B. „Kein HTTP-Request").
• Welche Knowledge Sources zulässig sind (z. B. „Kein public Web").
• Welche Channels veröffentlicht werden dürfen.
• Ob Agenten No Authentication verwenden dürfen.

Das Steuern läuft in der Praxis über Konnektor-Namen, und die heißen im Power Platform Admin Center anders, als man sie sucht. Deshalb hier die Übersetzungstabelle:

Zwei Mechanismen, die Projekte oft übersehen: Statt einen Konnektor komplett zu blocken, kannst Du für SharePoint, öffentliche Websites und HTTP Endpoint-Filtering nutzen und einzelne Ziele erlauben oder verbieten. Und bei einem Verstoß wird der Publish-Button deaktiviert; über Details → Download auf der Channels-Seite bekommt der Maker eine Datei mit einer Zeile pro Verstoß, die er direkt an den Admin weiterreichen kann. Mit Set-PowerAppDlpErrorSettings hinterlegst Du in diesen Fehlermeldungen tenantweit eine Admin-Mailadresse und einen „Learn more“-Link – eine der wirksamsten Kleinigkeiten gegen Ticket-Pingpong.

Environment-Strategie

Empfohlen sind mindestens 3 Power-Platform-Environments:

Optional: Personal-Dev-Envs pro Entwickler. Jede Env hat eigene DLP-Policies, eigene Konnektoren, eigene Audit-Trails. Entra-Security-Groups beschränken den Zugang.

Authentifizierung (recap)

• No Authentication – Vorsicht: Externe Channels (Direct Line) brechen, wenn intern „No Auth" gesetzt ist.
• Entra ID v2 mit Federated Credentials ist der empfohlene Default – kein Client-Secret-Rotations-Stress.
• SSO mit Entra in Teams – User-Identität wird automatisch durchgereicht.
• Entra External ID – für Kunden-/Partner-Logins (B2C).
• Teams und Microsoft 365 vertragen nur eine Option. Die Kanäle Teams + Microsoft 365 unterstützen ausschließlich Authenticate with Microsoft. Wählst Du irgendeine andere Option, gehen diese Kanäle in den Blocked status. Umgekehrt ist Authenticate with Microsoft nicht verfügbar für Agents, die mit Dynamics 365 Customer Service integriert sind. Wer beides braucht, braucht zwei Agents.
• Der Variablen-Unterschied kostet Dich den Publish. Unter Authenticate with Microsoft gibt es nur User.ID und User.DisplayName; User.AccessToken und User.IsLoggedIn fehlen. Schaltest Du von manueller Auth auf Microsoft um, erscheinen diese Variablen in allen Topics als Unknown und müssen vor dem Veröffentlichen korrigiert werden. Für ein Access-Token brauchst Du Authenticate manually. Die Provider-Liste dort umfasst inzwischen fünf Einträge: Entra ID V2 mit Federated Credentials, mit Zertifikaten oder mit Client Secrets, dazu Entra ID (V1) und Generic OAuth 2.
• Neu dokumentiert (Stand 17.09.2026): Power BI und Entra-Auth schließen sich aus. Agents mit Microsoft-Authentifizierung lassen sich nicht in Power-BI-Berichte über iframe-basierte Visuals einbetten. Und bei Generic OAuth2 kann jeder, der sich anmeldet, mit dem Agent sprechen – einzelne Nutzer lassen sich über Agent Sharing dann nicht mehr steuern. Beides fällt erst im Rollout auf, wenn es niemand vorher geprüft hat.

Microsoft Entra Agent ID (Pflicht, Rollout Mai bis Juli 2026)

Copilot Studio integriert mit Microsoft Entra Agent ID: Pro Agent wird automatisch eine eigene Identity in Entra angelegt – ähnlich Service-Principals, aber mit eigener Audit-Story und Lifecycle. Vorteile:

• Audit-Log in Microsoft Entra (Sign-In-Events pro Agent).
• Connector-Permissions tauchen als API Permissions auf der Agent-Identität auf – Entra-/M365-Admins sehen ohne Power-Platform-Login, was ein Agent kann.
• Conditional Access für Connector-Scopes (Network-Location, Device-Compliance, Risk-Conditions).
• Integration mit Entra ID Governance.

Was das im Tenant konkret auslöst: Mit dem ersten Agent nach dem Rollout legt Copilot Studio ein Blueprint namens Microsoft Copilot Studio agent identity blueprint samt zugehörigem Blueprint Principal im Tenant an (Blueprint-ID 25664c89-cea5-4ab6-b924-a54fd8a19ae0). Jede einzelne Agent-Identität hängt als Kind unter diesem globalen Blueprint. Erschrick also nicht, wenn in Entra plötzlich ein Principal auftaucht, den niemand bewusst angelegt hat – das ist der erwartete Weg, nicht der Befund eines Audits.

Bestandsagents: Agents, die vor dem Rollout entstanden sind, laufen weiter über App Registrations. Microsoft migriert sie zu einem späteren Zeitpunkt auf Agent IDs. In der Übergangszeit funktionieren die Governance-Funktionen für beide Varianten – Du musst also nicht selbst migrieren, aber Deine Inventarliste enthält für eine Weile zwei Identitätstypen nebeneinander. Wer nicht warten will, kann Bestandsagents auch selbst umstellen: über das Power Platform Admin Center, per PowerShell-Skript oder über die Power-Platform-APIs. Beim Löschen eines Agents löscht Copilot Studio die zugehörige Entra Agent ID mit.

Wie die Connector-Scopes wirklich funktionieren: Beim Publish hängt Copilot Studio für jeden konfigurierten Power-Platform-Konnektor API-Permissions an die Agent-Identität. Diese Scopes werden ausschließlich von der Power-Platform-Connector-Runtime honoriert und zur Laufzeit erneut gegen Advanced Connector Policies (ACP) und DLP geprüft. Sie sind also ein Sichtbarkeits- und Conditional-Access-Werkzeug, kein Weg, an Deinen Governance-Policies vorbeizukommen – und umgekehrt ersetzt ihre Anwesenheit auch keine DLP-Policy.

GUID nachschlagen: In Copilot Studio unter Settings → Advanced → Metadata steht die GUID der Agent-Identität als Entra Agent ID. Damit lässt sich im Entra Admin Center prüfen, ob die Identitäten tatsächlich befüllt sind.

Microsoft Agent 365 (GA 1. Mai 2026)

Seit dem 1. Mai 2026 ist Microsoft Agent 365 für das Commercial-Segment allgemein verfügbar (per-User-Lizenzierung, Microsoft E5 als empfohlene Voraussetzung). Es ist die zentrale Governance- & Control-Plane für Enterprise-Agents tenant-weit – nicht nur für Copilot-Studio-Agents, sondern auch M365-, Foundry- und Partner-Agents. Du siehst Inventory, Permissions, Verhalten und Aktivität an einer Stelle und kannst geteilte Policies, Security-Controls und Lifecycle-Oversight anwenden. In Copilot Studio surface'n Admin-Statusinfos jetzt direkt im Authoring (Security-Posture pro Agent, Auth-Gaps, Policy-Impact).

Was Du im Tenant konkret prüfen solltest

• Advanced Hunting: Die Tabelle AIAgentsInfo wird durch die neue Tabelle AgentsInfo abgelöst (Agent 365 ist jetzt Single Source of Truth für das Agent-Inventar). AIAgentsInfo ist abgekündigt, aber noch nicht entfernt. Gespeicherte Queries, Custom Detections und Workbooks müssen migriert werden.
• Block-Regeln: Tenants, die auf den alten Agent-365-Regeln auf Block standen, blocken seit dem 1. Juli 2026 nicht mehr. Regeln neu definieren unter Settings → Security for AI → Policies & rules → Real-time protection. Das betrifft ausschließlich Agent-365-Real-time-Protection, nicht den Defender-for-Cloud-Apps-Pfad.
• Defender-Portal: Der Unterreiter AI Agents unter Cloud Assets wurde für alle Kunden entfernt, unabhängig von der Lizenz. Alle Security-for-AI-Funktionen liegen jetzt unter dem gemeinsamen Schalter Security for AI Agents.
• Drittanbieter-Agents sind nicht mehr über Defender-for-Cloud-Connectors auffindbar; stattdessen Registry Sync in der Microsoft-365-Agent-Registry nutzen (Preview).
• Customer Lockbox deckt die Governance-, Telemetrie- und Audit-Events nicht ab, die über Agent 365 laufen – ebenso wenig wie das Security-Audit-Logging von Copilot Studio selbst (Details weiter unten).

MCP-Zertifizierung (Preview seit Juli 2026)

Ein MCP-Server ist aus Governance-Sicht ein fremder Dienst, dem Du Tool-Aufrufe und damit oft Daten anvertraust. Seit Juli 2026 gibt es dafür ein offizielles Prüfsiegel: die Microsoft MCP server certification. Microsoft validiert Paket und Laufzeitverhalten eines eingereichten Servers, bevor er breit verfügbar wird, und der Publisher bleibt danach für die Pflege des zertifizierten Erlebnisses verantwortlich.

Eingereicht wird über den Partner-Center-Angebotstyp Apps and Agents for M365 and Copilot. Der alte Einreichungspfad war nur noch bis Ende Juli 2026 nutzbar; bereits zertifizierte MCP-Server müssen wegen der Umstellung nichts tun, Microsoft überführt sie selbst. Voraussetzung ist ein verified publisher mit abgeschlossener Business-Verifizierung im Partner Center, Enrollment im Microsoft-365-und-Copilot-Programm und Eigentum bzw. Kontrolle über den eingereichten Endpunkt. Independent Publisher ohne eigenen Dienst dürfen nicht einreichen.

Was Du als Kunde davon hast: Die Liste der zertifizierten MCP-Server steht in der Connector-Referenz und taugt als Whitelist-Grundlage. Für die Bewertung eines nicht zertifizierten Servers ändert sich nichts: Er bleibt erlaubt, aber Du trägst die Prüfung selbst. Ein sinnvoller Governance-Satz lautet deshalb nicht „nur zertifizierte MCP-Server“, sondern „zertifiziert oder eigene dokumentierte Freigabe“. Nebenbei: Microsoft unterstützt in Manifest- und Tool-Dateien nur ASCII-Header-Namen und -Werte; Umlaute im Manifest lassen die Validierung scheitern.

Knowledge-Source-Permissions

Wenn SSO aktiv ist und Du SharePoint/Graph/Dataverse als Knowledge anbindest, erbt der Agent die Permissions des Users. Das ist eines der wichtigsten Sicherheits-Features: Ein Mitarbeiter sieht nur Wissen, das er sowieso sehen darf.

Ohne SSO läuft alles im Kontext eines Maker- bzw. Service-Accounts – das ist meistens NICHT das, was Du willst, sondern Quelle vieler Datenlecks.

Protection Status: die Sicherheitsampel pro Agent

Governance scheitert selten an fehlenden Policies, sondern daran, dass niemand sieht, welcher Agent gerade dagegen verstößt. Genau dafür gibt es auf der Agents-Seite in Copilot Studio die Spalte Protection status. Sie zeigt für jeden veröffentlichten Agent einen von drei Zuständen: Protected (grünes Schild, kein Handlungsbedarf laut erkannter Signale), Needs review (Policy-Verstoß oder unzureichende Authentifizierung) oder Unknown. Der Clou für Maker-Enablement: Die Ampel steht dort, wo der Maker ohnehin arbeitet, nicht im Admin Center.

Ein Klick auf den Status öffnet eine Zusammenfassung, die das Sicherheitsprofil in drei Kategorien zerlegt, jede wieder mit Protected, Needs review oder Unknown:

Steht Authentication oder Policies auf Needs review, schlägt das auf den Gesamtstatus in der Agents-Liste durch. Content Moderation tut das bewusst nicht.

Security Analytics: was tatsächlich geblockt wurde

Über See details kommst Du in den Dialog Security analytics mit Statistiken und Trends über die letzten 7, 14 oder 30 Tage (Zeiträume ohne Daten erscheinen gar nicht erst im Picker). Zwei Darstellungen sind dort praxisrelevant: Das gestapelte Balkendiagramm Reason for block zerlegt alle geblockten Nachrichten nach Blockierungsgrund – potenzielle Bedrohungen, Policy-Verstöße, Content-Moderation. Der Graph Session block rate trend zeigt pro Kategorie den Anteil der Sessions mit einer geblockten Anfrage über die Zeit, also ob ein Ausschlag ein Einzelfall oder ein Muster ist.

Automatischer Security-Scan vor dem Publish

Agents sind im Auslieferungszustand sicher konfiguriert. Weil Maker diese Defaults aus nachvollziehbaren Gründen aufweichen, ohne das Risiko zu kennen, läuft vor dem Veröffentlichen ein automatischer Security-Scan und warnt den Maker. Drei Abweichungen lösen die Warnung aus:

• Authentifizierung auf No authentication gesetzt. Default ist Authenticate with Microsoft; mit No Auth kann jeder mit dem Link mit dem Agent sprechen.
• Bei Konnektoren und Flows auf Maker-provided credentials umgestellt. Default sind End user credentials, also die Rechte des jeweiligen Nutzers. Der Wechsel bedeutet: Alle sehen, was der Maker sehen darf.
• Agent mit allen in der Organisation geteilt. Default ist „mit niemandem geteilt“.

Der Scan ist eine Warnung, kein Gate: Er blockiert das Veröffentlichen nicht, sondern erzwingt eine bewusste Entscheidung. Für ein Governance-Konzept heißt das, dass Du diese drei Punkte trotzdem hart über Data Policies absichern solltest, wenn sie in Deiner Organisation nicht verhandelbar sind. Ergänzend bewertet Copilot Studio Knowledge, Tools und Actions schon während der Konfiguration laufend auf mögliche Datenabfluss- und Sicherheitsrisiken, sodass Befunde vor dem Publish sichtbar werden statt danach.

Audit-Logs via Microsoft Purview

Studio-Agents loggen in den Purview Audit Log. Das Logging passiert auf der SDK-Ebene, deshalb löst eine einzelne Aktion oft mehrere Events aus. Grob drei Klassen:

• Admin- und Maker-Aktionen auf dem Agent selbst: BotCreate, BotDelete, BotDeleteCleanup sowie die BotUpdateOperation-Varianten für Namen, Icon, Authentifizierung, Publish und Share.
• Komponenten-Änderungen: BotComponentCreate / -Update / -Delete für Topics, Skills und Entities, dazu Component Collections, AIPluginOperation* für AI Plugins, EnvironmentVariable* für Umgebungsvariablen und BotAppInsightsUpdate für Änderungen an der Application-Insights-Konfiguration.
• Nutzung: CopilotInteraction für jede Interaktion eines Nutzers mit einem Agent.

Compliance-Admins arbeiten im Purview-Portal unter Solutions → Audit. Entwickler kommen über die Office-365-Management-API an dieselben Daten.

Abschalten geht nur halb. Die Erfassung der administrativen Aktivitäten ist auf allen Tenants standardmäßig aktiv und lässt sich nicht deaktivieren. Was Du tun kannst: das Audit-Log in Purview tenantweit abschalten und über eine Data-Lifecycle-Management-Richtlinie mit Aufbewahrung 0 Tage für „Copilot Experiences“ verhindern, dass Nutzer- und Antworttexte aufbewahrt werden. Zwei Voraussetzungen sind leicht zu übersehen: Nutzer brauchen eine zugewiesene Microsoft-365-Lizenz, damit Events und Transkripte überhaupt geschrieben werden, und in FedRAMP-Tenants greift das Ganze nicht.

Zwei weitere Details für die Praxis: Bei Agents mit Entra Agent ID landet die Authentifizierungs-Aktivität zusätzlich in Microsoft Entra ID und ist im Entra Admin Center sichtbar – die Governance-Story liegt also auf zwei Portalen. Und einzelne Kanäle sind vom Logging ausgenommen. Welcher Kanal ein Event erzeugt hat, steht in der Audit-Lösung im JSON-Feld CopilotEventData als AppHost, in DSPM for AI als App accessed in. Wenn Events fehlen, ist der Kanal der erste Verdächtige, nicht die Policy.

Weitere Governance-Controls im Überblick

Microsoft führt in der Governance-Übersicht eine Reihe von Controls, die in Projekten selten alle bekannt sind. Die relevantesten neben DLP, Entra Agent ID und Purview:

MIP-Labels & Sensitivity (Preview seit Juli 2025)

Microsoft Information Protection (MIP)-Sensitivity-Labels werden seit Juli 2025 in Copilot Studio durchgereicht: Connectors, Test Chat, Teams und M365 Copilot zeigen das Label des Quell-Dokuments an. Files mit Label confidential oder highly confidential liefern in Generative Answers keine Inhalte – gut für Oversharing-Prevention, kann aber Knowledge-Lücken erzeugen. Purview-Integration mit Dataverse klassifiziert sensible Daten automatisch.

Responsible-AI-Guardrails

• Topics deaktivieren – Single-Click, ohne löschen zu müssen.
• Allowed/Disallowed Topics definieren – was der Agent grundsätzlich (nicht) beantworten darf.
• Content Moderation auf Generative-Answers – Standard-Toxizitäts- / PII-Filter.
• Restrict to defined topics Toggle – generative Antworten nur, wenn Topic gematched wurde.
• Conversation Boosting Off – kein freier LLM-Plausch außerhalb der Topics.
• Citations verpflichtend für Generative Answers – User sieht Quelle.

Studio bietet vier Wege, einen Menschen in den Workflow zu holen – plus seit Nov 2025 Approval-Gates pro Toolschritt für autonome Agents.

1. Adaptive Card mit Approval-Button

Du sendest mit „Ask with Adaptive Card" eine Card („Approve / Reject"). Der Agent wartet auf den Submit, parsed die Antwort in eine Variable, fährt fort.

• Eignet sich für: Schnelle Inline-Bestätigungen im Chat.
• Limit: Nur im aktiven Chat-Kontext.

2. Power-Automate „Approvals" Action

Klassische PA-Approval-Action (Teams- oder Outlook-Approval-Card) – der Agent ruft einen Flow auf, der die Approval blockt und auf Antwort wartet.

• Eignet sich für: Asynchrone Genehmigungen (über Stunden/Tage).
• Limit: PA-Lizenz kostet extra.

3. Agent-Flow „Request for Information"

Im Agent-Flow gibt es seit 2025 eine dedizierte HITL-Action: Der Flow pausiert, schickt eine strukturierte Mail (per Outlook) mit Eingabefeldern, sammelt die Antwort direkt aus der Mail und fährt fort.

• Eignet sich für: Strukturierte Off-System-Reviews.
• Limit: Aktuell nur Outlook als Kanal.

4. Hand-off zu Live-Agent

Bei Hand-off geht der gesamte Konversations-Kontext (Variables + Transcript) mit – der menschliche Agent muss nicht „von vorne" anfangen.

Approval-Gates pro Toolschritt (Nov 2025)

Seit Nov 2025 kannst Du in autonomen Agents pro Tool/Action ein Approval-Gate setzen – der Agent macht den Schritt erst, wenn ein definierter Approver zustimmt.

Wichtig für: Cost-Thresholds, Policy-Validation, sensible Datenoperationen.

Human Supervision für Computer Use

Computer-Use-Tools haben ein eigenes Human-Supervision-Feld: Bei erkannten „potenziell schädlichen Instructions" (z. B. Prompt-Injection auf einer Website) wird ein definierter Reviewer per Outlook benachrichtigt. Wichtig zu wissen: Der Reviewer sieht den Run-Kontext nur, wenn er ihn selbst initiiert hat – sonst fehlt ihm die Sicht aufs Geschehen. Eine Response-Time-Limit-Konfiguration entscheidet, ob der Run wartet oder abbricht.

Smart Approval mit Conditions

Kombiniere Conditions mit HITL, um Genehmigung nur bei Bedarf einzufordern:

Agent-Flow: Rechnungsbetrag extrahieren

Condition: Betrag > 1.000 €?
├─ Ja → Request for Information (Manager-Approval per Mail)
│       → SAP-Connector: Zahlung buchen
└─ Nein → SAP-Connector: Zahlung direkt buchen

So hast Du Automatisierung für Routine-Fälle und Kontrolle für Ausnahmen.

Draft vs. Published

• Draft – die in Studio editierbare Version. Tests im Test-Pane laufen gegen Draft.
• Published – die live ausgespielte Version, die User auf Channels sehen.
• Jeder „Publish"-Klick erzeugt eine neue published Version. Studio behält History (Restore möglich).

Solutions (ALM-Container)

Best Practice: Immer in Solution arbeiten mit eigenem Publisher und Prefix. Eine Solution kann enthalten:

• Agents
• Topics
• Agent Flows / Cloud Flows
• Connection References (statt fester Verbindungen)
• Environment Variables (statt fester Werte)
• Dataverse-Tabellen, AI-Prompts, Custom Connectors

Dev → Test → Prod

Vier Deploy-Mechanismen:

Component Collections (Nov 2025): Quick-Export/-Import von Topic-/Tool-/Knowledge-Bundles über die Sidebar – auch für Child-Agents und MCP-Connector-Types. Hilfreich für Reuse über mehrere Agents hinweg.

Agent Evaluations als CI/CD-Gate (GA März 2026, REST API als Preview April 2026): Pflicht-Test-Sets vor Prod-Deploy, Custom Graders für domänenspezifische Pass/Fail-Kriterien, Multi-Turn-Konversations-Tests. Test-Ergebnisse 89 Tage in Studio sichtbar; via CSV exportierbar.

Ausbau der Evaluations im September 2026: Microsoft rollt über das Message Center (RM569607) eine erweiterte Evaluations-Erfahrung als allgemein verfügbar aus. Neu sind ausführlichere Begründungen zu jedem Ergebnis, Reasoning-Traces des Agents, die zitierten Knowledge Sources pro Testfall, der Vergleich zweier Evaluations-Läufe, Unterstützung größerer Datensätze, konfigurierbare Testfall-Generierung und die Generierung von Testdaten direkt aus Knowledge Sources. Dazu kommt eine Vorab-Validierung, die Konfigurationsfehler meldet, bevor ein Lauf startet.

Zwei Details aus der Evaluations-Doku, die in Projekten regelmäßig gesucht werden: Copilot Studio misst pro Interaktion die Response Time in Sekunden, Ende zu Ende inklusive Reasoning, Tool-, Connector- und Workflow-Schritten – eine reine Messgröße ohne Pass/Fail-Wirkung, gut geeignet für Vorher-Nachher-Vergleiche. Und es gibt eine eigene Freigabe-Rolle Agent Viewer: Wer sie bekommt, darf Test-Sets anderer Maker sehen, starten, umbenennen, abbrechen und löschen, aber den Agent selbst nicht ändern, nicht veröffentlichen und keine Freigaben verwalten. Status und Kennzahlen eines Laufs sehen alle Maker, die Agent-Antworten und Ergebnis-Begründungen nur diejenige Person, die den Lauf gestartet hat.

Best Practices:

• Managed Solution in Test & Prod, Unmanaged nur in Dev.
• Environment Variables für API-URLs, Konnektor-Endpunkte etc.
• Connection References für Konnektor-Verbindungen (Solution kann ohne hartverdrahtete Credentials wandern).
• Nach Deploy: Post-Deploy-Config für Application-Insights-Anbindung und manuelle Auth-Settings (sind env-spezifisch).

Modell-Lifecycle: der Deploy-Fall, den fast alle vergessen

Microsoft hat im August 2026 eine eigene Guidance-Reihe zum Modell-Lifecycle veröffentlicht, und die schließt eine Lücke, die in fast jedem Projekt existiert: Ein Modellwechsel wird wie eine Dropdown-Änderung behandelt, verhält sich aber wie eine Migration. Ein neueres Modell interpretiert Instruktionen wörtlicher, wählt Tools anders, antwortet in anderer Länge und Formatierung und bringt andere Latenz mit. Der Leitsatz der Doku: flexibel bauen, konservativ betreiben, jedes Upgrade über eine Evaluation absichern.

Der dokumentierte Zyklus für Produktiv-Agents hat sieben Schritte: Discover (neue, geänderte, neue Default- und auslaufende Modelle finden), Inventory (welche Agents, Environments, Owner und Geschäftsprozesse hängen daran), Evaluate (Kandidat gegen eine etablierte Baseline messen), Approve (nach dokumentierten Qualitäts- und Betriebskriterien), Deploy (über den normalen ALM-Weg), Monitor (Produktion beobachten, neu entdeckte Fälle in die Regressions-Suite aufnehmen) und Repeat. Einen Review stößt Du außerdem an, wenn ein Modell in Deiner Region verfügbar wird, wenn sich der Default ändert, wenn eine Abkündigung oder ein automatisches Upgrade angekündigt wird oder wenn das Monitoring Qualitäts-, Latenz- oder Verbrauchsprobleme zeigt.

Was Du pro Agent festhalten solltest, damit eine angekündigte Abkündigung kein Feuerwehreinsatz wird: Name, Agent-ID, Environment und Environment-Typ, Business-Kritikalität, fachlicher und technischer Owner plus Tester und Freigeber, das konfigurierte Modell samt Release-Tag, ob der Agent am Default hängt oder ein festes Modell nutzt, Cross-Geo-Bedarf und regionale Auflagen, die verwendete Harness (sie entscheidet, welche Evaluations-Methoden überhaupt zur Verfügung stehen), der Ablageort des Regressions-Test-Sets mit dem Datum des letzten Baseline-Laufs sowie die Frage, ob das Retired-Model-Fenster genutzt wird, wann es abläuft und wer es freigegeben hat.

Die Inventarisierung musst Du nicht von Hand machen. Im Power Platform Admin Center zeigt Manage → Copilot Studio eine Spalte Model über alle Agents des Tenants, filter- und exportierbar; unter Licensing → Copilot Studio → Environment → Message consumption details gibt es zusätzlich die Spalte LLM Model samt Verbrauch. Programmatisch liefert die Inventory API Name, Anzeigename, Environment und Modell in einer einzigen tenantweiten Abfrage – Voraussetzung sind die Rolle Power-Platform- oder Dynamics-365-Administrator, ein Access Token für https://api.powerplatform.com/ und ein für den Tenant aktiviertes Agent Inventory.

POST https://api.powerplatform.com/resourcequery/resources/query?api-version=2024-10-01
Authorization: Bearer <access-token>
Content-Type: application/json

{
  "TableName": "PowerPlatformResources",
  "Clauses": [
    { "$type": "where", "FieldName": "type", "Operator": "in~",
      "Values": ["'microsoft.copilotstudio/agents'"] },
    { "$type": "project", "FieldList": [
        "name",
        "properties.displayName",
        "properties.model",
        "environmentId = tostring(properties.environmentId)"
      ] }
  ],
  "Options": { "Top": 200 }
}

// Antwort: properties.model kommt als properties_model zurück.
// Bei mehr Treffern als Top: skipToken aus der Antwort als
// Options.SkipToken zurücksenden und wiederholen.

Gruppierst Du das Ergebnis nach properties_model, siehst Du auf einen Blick, wo welches Modell im Tenant steckt; bei einer Abkündigung filterst Du dieselbe Liste auf das auslaufende Modell und hast die betroffenen Agents mit Environment-ID für die Owner-Ansprache. Für eine einzelne Umgebung reicht pac copilot list --environment <id> aus dem Power Platform CLI – das Kommando liefert allerdings kein Modell, dafür brauchst Du die Inventory API.

Channel-Publishing

Pro Channel separate Publish-Pipeline:

• Teams / M365 Copilot – Studio generiert App-Manifest; muss durch Teams-Admin genehmigt werden, bevor User es installieren können. Personal-Scope zuerst, dann Team/Channel-Scope optional via Manifest-Tweak.
• Web – Embed-Code für eigene Sites.
• Custom (Direct Line) – Geheimer Direct-Line-Token; in eigener App nutzen.
• Voice – D365-Contact-Center-Provisionierung.
• Teams Phone Agent (Preview seit Juni 2026) – der Copilot-Studio-Voice-Agent hängt sich an einen Teams Phone Agent und übernimmt spezialisierte Anliegen wie Abrechnung, Bestellstatus oder Rezeptnachbestellung. Übergabe und Rückgabe laufen nahtlos, Transfer-Ziele kommen als Tags aus einem Tag-Template im Teams Admin Center, statt im Agent hartcodiert zu sein. Der Kanal ist gated: Der Tenant muss über den Microsoft-Support freigeschaltet werden, sonst taucht die Option gar nicht auf.
• SharePoint / Power Pages – Embed-Web-Part.

Environment-Level-Telemetrie mit Application Insights (Preview seit Juli 2026, überarbeitet im September)

Bis Juli 2026 musstest Du Application Insights pro Agent verdrahten. Seit Juli 2026 lässt sich der Export im Power Platform Admin Center für eine ganze Managed Environment einschalten – ein Export-Package mit dem Typ Copilot Studio, und alle Agents der Umgebung liefern Traces. Für den Betrieb ist das der eigentliche Sprung: Du siehst Agent-Läufe, Node- und Tool-Ausführungen, kannst Alerts bauen und eigene Dashboards und Abfragen schreiben, ohne dass jeder Maker daran denken muss. Seit dem Doku-Stand vom 17. September 2026 gilt das ausdrücklich für Agents beider Harnesses, der Standard- wie der GitHub-Copilot-Harness.

Zwei Details, die Bestands-Dashboards brechen: Nach dem Ende der Private Preview emittiert Microsoft die Root-Aufrufe eines Agents (invoke_agent) als dependencies statt wie früher als requests. Ältere Root-Traces können deshalb weiterhin in der requests-Tabelle auftauchen – wer über beide Zeiträume auswertet, muss das in der Abfrage abfangen. Und die Auslieferung braucht bei einer neu eingerichteten Konfiguration bis zu 24 Stunden: Wenn nach dem Einschalten nichts ankommt, ist das zuerst eine Geduldsfrage und erst danach ein Fehlerbild. Wer ausschließlich auf Environment-Ebene auswerten will, kann die Agent-Level-Telemetrie in der Doku-Anleitung gezielt abschalten.

Rollback / Restore

Studio behält published Versionen – Du kannst zu einer früheren zurückkehren. Aber: Solution-Deployments sind „forward-only" – Rollback zwischen Envs läuft via Re-Deploy einer früheren Solution-Version.

Pricing-Modelle im Detail

Seit Sept 2025 ist die Einheit Copilot Credit, nicht mehr „Message".

Credits werden tenant-weit gepoolt. Microsoft veröffentlicht seit März 2026 offizielle Billing Rates:

Reasoning-Modelle werden doppelt billed: Feature-Rate + AI-Tools-Premium-Rate (z. B. Generative Answer mit Deep-Modell = 2 Credits + 100 Credits / 10 Responses).

Voice-Abrechnung pro Minute: Classic Voice (klassische Orchestration) 10 Credits/Min, GenAI Voice 35 Credits/Min, Premium GenAI Voice 75 Credits/Min. Die Kern-Agent-Aktivität (Classic- bzw. Generative-Answer, Agent Action) ist in der Minuten-Rate bereits inkludiert.

Faustregel: Ein konversationeller Sales-Lead-Qualifier kostet $0,15–$0,80 pro Konversation; ein autonomer Mail-Triage-Agent $0,30–$2,00 pro Mail; ein Computer-Use-Run mit 10 Schritten ~$0,50 (Standard) bis $1,50 (Premium).

Usage-based Billing der GitHub-Copilot-Harness

Alles bisher Genannte gilt für die Standard-Harness: feste Billing Rates pro Feature, Abrechnung ab Veröffentlichung. Agents, Workflows und Apps auf der GitHub-Copilot-Harness rechnen anders ab, und das ist der derzeit teuerste Denkfehler in Projekten.

Die Billing-Doku (Stand 27. August 2026) nennt als Geltungsbereich wörtlich agents, workflows, and apps. Mit dem Start des App-Buildings im September 2026 fällt damit auch jede generierte App unter dieses Modell – rechne sie in Piloten von Anfang an mit ein, statt sie als kostenloses Nebenprodukt zu behandeln.

Was im September dazukommt: Microsoft hat am 15. September 2026 drei Roadmap-Einträge zur Kostentransparenz veröffentlicht, alle mit GA-Ziel September 2026 und Status In development: RM571194 zeigt die Kosten künftig direkt im Preview-Chat und im Agent-Verlauf, RM571195 schlüsselt sie in den Agent Evaluations nach Eval-Generierung, Test-Läufen und Model-Grading auf, und RM571196 bringt sie in den Monitor-Tab pro Agent, samt geschätzter Verteilung über den Lebenszyklus von Authoring über Testing und Evaluations bis zur Produktion. Genau das fehlt heute: Das Bau-Budget ist zwar verbraucht, aber niemand kann sagen, wofür. Bis das ausgerollt ist, bleibt die einzige belastbare Sicht die Verbrauchsansicht im Power Platform Admin Center.

Enforcement ist hier härter als die 125-Prozent-Regel: Hat eine Environment keine zugewiesenen Credits mehr oder sind alle verbraucht, stoppt jede Funktion, die Credits braucht. Endnutzer bekommen keine Antworten mehr, Maker können nicht mehr per natürlicher Sprache autoren, nicht mehr im Preview testen und keine Evaluationen mehr erzeugen. Beide Gruppen sehen dieselbe Meldung, dass Credits fehlen. Microsoft lässt eine gewisse Overage als Kulanzpuffer zu, damit Geschäftsprozesse nicht abrupt abreißen, garantiert aber keinen Betrag. Die drei Auswege: Kapazität aus Tenant oder anderer Environment umverteilen, Kapazität nachkaufen, oder einen PAYG-Meter für die Overage einrichten.

Credit-Governance: das Environment ist die Einheit

Seit dem 17. September 2026 gibt es dazu einen eigenen Guidance-Artikel. Die Kernaussage: Weil die GitHub-Copilot-Harness schon beim Bauen, Testen und Evaluieren Credits verbraucht, reicht es nicht, nur veröffentlichte Agents zu steuern. Gesteuert wird ab dem ersten Tag auf Environment-Ebene. Wichtig dabei: Developer- und Trial-Environments laufen seit dem 1. September 2026 im Usage-based Billing. Verbrauchsdaten von davor sind nur ein Richtwert, keine Kostenprognose.

Microsoft empfiehlt, jedes Environment einer von drei Klassen zuzuordnen: Exploration und Prototyping (feste Grenze, Entwicklungslimit pro Agent, dokumentierter Weg zu mehr Kapazität), Test und Validierung (zeitlich begrenzte Kapazität für repräsentative Evaluationen) und finanzierte Produktion (klarer Kostenverantwortlicher, Limits nach Kritikalität). Für eine harte Prepaid-Grenze weist Du eine feste Menge zu, schaltest Draw from the available capacity in my tenant aus und hängst kein PAYG an. Die betroffenen Agents findest Du über das Power Platform Inventory: Das Feld properties.harness mit dem Wert GitHub Copilot filtert sie heraus.

Overage Enforcement der Standard-Harness (125 %-Regel)

Wenn der Tenant 125 % seiner prepaid Capacity erreicht, deaktiviert Microsoft alle Custom Agents (Conversation-End wird abgewartet). Notification an Admin per Mail + Power-Platform-Admin-Center. Workaround: PAYG-Meter aktivieren oder Capacity reallokieren. Agent Flow Enforcement ist separat: bei voller Capacity werden neue Flow-Runs blockiert, andere Agent-Features laufen weiter. Tipp: Monthly Spend Limit pro Agent im Admin Center setzen, bevor's eskaliert.

Bekannte Limits (Stand August 2026)

Rate Provisioning: Durchsatz ist nicht Lizenz

Seit Juni 2026 trennt Microsoft in der Architektur-Guidance zwei Dinge sauber, die in Projekten oft verwechselt werden. License Provisioning ist die kommerzielle Frage: Lizenzen, Credits, prepaid Kapazität, PAYG. Rate Provisioning ist die technische Frage: wie schnell Anfragen ankommen dürfen, bevor Throttling greift. Du kannst genügend Credits haben und trotzdem gedrosselt werden.

Die Limits in der Tabelle oben gelten je nach Dienst auf Agent-, Environment-, Tool-, Connector- oder Kanal-Ebene, und das niedrigste Limit im Laufzeitpfad bestimmt das Nutzererlebnis. Der Agent kann innerhalb seiner Grenzen bleiben, während ein Flow, ein Connector, ein Dataverse-Aufruf oder eine nachgelagerte API bereits drosselt. Messages an einen Agent zum Beispiel werden pro Dataverse-Environment gezählt, also inklusive aller anderen Agents und autonomen Workloads darin.

Rechne deshalb nicht in Monatsvolumen, sondern in Spitzenfenstern: Anfragen pro Minute und pro Stunde. Ein Kampagnen-Peak von einer Stunde kippt ein Setup, das im Wochenschnitt harmlos aussieht. Als erste Reaktion sind Design-Optimierungen fällig, nicht ein Limit-Antrag: externe Aufrufe bewusst setzen, Agents mit hohem Volumen auf eigene Environments verteilen, autonome Läufe über Queues, Batches und Trigger-Filter entzerren, Reporting und Telemetrie aus dem interaktiven Pfad ziehen. Erst wenn das steht, lohnt der Support-Antrag im Power Platform Admin Center. Ihn braucht es vor UAT und Lasttest, nicht nach dem ersten Produktionsfehler, und eine Erhöhung ist nie garantiert.

Neu seit September 2026: Die Guidance beschreibt jetzt, wie Du einen Erhöhungsantrag belegst: eine repräsentative Pilotphase fahren, die Spitzenlast messen, auf die volle Nutzerzahl hochrechnen und genau diese Zahlen dem Antrag beilegen. Ohne Pilotdaten bleibt der Antrag eine Schätzung.

Kostentreiber

1. Generative Orchestration – jeder Userturn = mind. 1 LLM-Aufruf zum Topic/Tool-Picking.
2. Knowledge Querying – jede Generative Answer = Embedding + Retrieve + Synthesis = mehrere Credits.
3. Autonome Agents mit hohem Eventvolumen – z. B. Mail-Triage auf 10.000 Mails/Tag = vierstellige Credits/Tag.
4. Deep Reasoning – Multi-Step Planning ist deutlich teurer als Single-Shot.
5. Tool-Chaining – jeder Tool-Call kann erneut LLM-Reasoning auslösen.

Faustregel: Schätze Credits = (Konversationen/Monat × durchschnittliche User-Turns × ~5 Credits/Turn) plus Knowledge-Hits.

1. Starte mit Classic Orchestration für regulierte Use-Cases. Generative ist mächtig, aber weniger vorhersagbar – Compliance liebt deterministische Pfade.
2. Jeder Agent in einer eigenen Solution. Sonst gibt's bei ALM-Deploy Sammelchaos und unbeabsichtigte Co-Deployments.
3. Environment Variables für alles Env-spezifische. API-Endpoints, Group-IDs, SP-URLs – Solution wandert sauber zwischen Envs.
4. SSO aktivieren, sobald Du Knowledge mit SharePoint/Graph/Dataverse anbindest. Sonst läuft alles im Maker-Kontext und User sehen Dinge, die sie nicht dürfen.
5. Topic-Descriptions sind in Generative Orchestration so wichtig wie ihre Inhalte. Beschreibe genau, wann ein Topic gewählt werden soll, nicht was es tut.
6. Pro Tool maximal 1 klare Aufgabe. „Helfer-Tool, das auch noch X kann" → Generative Orchestration verwechselt sie. Splitte.
7. HITL ab dem ersten Schritt einbauen, wenn der Agent autonom ist. Lieber zu viele Approval-Gates am Anfang; rausbauen ist einfacher als Pannen nachträglich abfangen.
8. Conversation-Boosting Off + Generative Answers nur aus konfigurierten Knowledge Sources. Sonst halluziniert der Agent „kreativ" über Themen, die Du nicht kontrollierst.
9. Power Fx ist Dein Freund für Logik – aber überstrapazier es nicht. Komplexere Logik in Agent Flow auslagern (besser testbar).
10. Test in Multi-Channel-Modus, nicht nur im Studio-Pane. Adaptive Cards, SSO, Auth-Tokens verhalten sich in Teams/Web/Direct Line anders als im Test-Bot.

Top-5-Fehlerbilder

Häufige Stolperfallen

Stolperfalle 1: „Topic gefunden, aber nichts passiert"

Meist Konnektor-Auth: Connection References mit kaputter Credential = stille Fails. Erst die Connection prüfen, dann das Topic.

Stolperfalle 2: Adaptive Card sieht in Studio gut aus, in Teams kaputt

Teams hat ältere Card-Schema-Version + 28-KB-Limit. Immer in Teams testen, nicht nur in Studio.

Stolperfalle 3: Generative Orchestration „verliert" Topics

Wenn Du 50+ Topics hast, ähneln sich die Descriptions zu sehr und der LLM picked die falsche. Lösung: schärfere Descriptions oder zurück auf Classic.

Stolperfalle 4: SharePoint-Knowledge zeigt nur Schnipsel – keine ganze Datei

Wenn Du nur M365-E3-Lizenz hast (kein M365 Copilot), gilt 7-MB-Limit. Größere Files? Aufsplitten oder Lizenz upgraden.

Stolperfalle 5: „Why is my agent answering things it shouldn't?"

Conversation Boosting steht auf On (Default). Toggle aus + „Restrict to defined topics" an.

Stolperfalle 6: Veröffentlichung in Teams hängt wochenlang

Teams-Admin muss App-Catalog-Eintrag genehmigen. Häufig nicht eingerichteter Approval-Prozess. Erst Process klären, dann deployen.

Stolperfalle 7: Power-Automate-Flow tut nichts im Run-Log

Wenn Du einen alten PA-Cloud-Flow als Tool nutzt, läuft er unter einem anderen Service-Account – Permissions können fehlen, wo sie in Deinem eigenen Test funktioniert haben.

Stolperfalle 8: MCP über SSE bricht nach August 2025

SSE wurde im August 2025 abgekündigt – Streamable HTTP ist jetzt Pflicht für MCP-Server-Anbindung.

Stolperfalle 9: „Mein autonomer Agent feuert nicht."

Generative Orchestration muss an sein, sonst sind Event-Trigger im UI nicht sichtbar.

Stolperfalle 10: „Agent disabled, billing issue"

Du hast 125 % der prepaid Capacity überschritten → Overage Enforcement greift. Bestätige im Power Platform Admin Center, ob Du Capacity reallokieren oder PAYG aktivieren willst. Bei Agent Flows: separates Enforcement, blockiert nur neue Runs.

Stolperfalle 11: Real-time Voice geht nicht in EU-Tenant

Real-time Agents sind nur in Nordamerika (GPT-Realtime) und seit Juni 2026 in Australien (GPT-Realtime-Mini) gehostet. EU-Data-Boundary-Tenants können das Feature nicht nutzen, weil das dafür nötige Cross-Geo-Processing in der EU verboten ist. Außerhalb NA/Australien muss Cross-Geo-Processing explizit erlaubt sein.

Stolperfalle 12: „Generative Answer liefert keine Antwort obwohl SP-File existiert"

Wahrscheinliche Ursache: Das Dokument trägt ein MIP-Sensitivity-Label confidential oder highly confidential. Diese Files werden zwar als „ready" angezeigt, liefern aber keine Inhalte.

Stolperfalle 13: Generative Orchestration ignoriert Conversational-Boosting-System-Topic

Bekannte Limitation: In Generative Orchestration werden Modifikationen am Conversational-Boosting-System-Topic nicht berücksichtigt. Custom-Data-Sources und Bing Custom Search ebenfalls nur via Classic data-Option im Generative-Answers-Node.

Stolperfalle 14: Multiple-Topics-Matched System-Topic disambiguiert nicht

Generative Orchestration ruft das Multiple-Topics-Matched-System-Topic aktuell nicht auf. Beim Testen Topic abschalten; wieder einschalten, wenn Microsoft die Disambiguation-Fix nachliefert.

Stolperfalle 15: Der Agent antwortet doppelt – oder gar nicht

Microsoft hat Ende August 2026 dokumentiert, warum das passiert, und die Ursache ist strukturell, kein Bug. Die Standard-Harness verteilt den Kontext über die beteiligten Komponenten. Jede Komponente arbeitet aus ihrem eigenen Kontext, und die Orchestration-Ebene gleicht den Kontext nicht auf oberster Ebene ab. Solange eine Komponente läuft, sieht die Orchestration-Ebene deren Nachrichten an den Nutzer nicht. Ergebnis: Eine Anfrage wirkt unbeantwortet, also beantwortet sie jemand ein zweites Mal.

Kontext fließt auf zwei Wegen hin (explizite Inputs plus implizit mitgereichter Konversationskontext) und auf zwei Wegen zurück (explizite Outputs plus impliziter Kontext). Was eine Komponente nur dem Nutzer zeigt oder nur in eigenen Variablen behält, erreicht die Orchestration-Ebene nie. Laut Microsoft geht rund die Hälfte der Fälle mit doppelten oder fehlenden Antworten auf dieses implizite Weiterreichen zurück.

Adaptive Cards sind der häufigste Auslöser. Aus Topics kommt nur Klartext implizit zurück (Message-Nodes, Question-Nodes, Card-Inhalte, getippte Nutzerantworten) – und ohne die Information, ob der Nutzer ihn gesehen hat. Action-Buttons einer Adaptive Card und die Klicks darauf erreichen den Kontext der Standard-Harness gar nicht. Verlasse Dich deshalb nie auf Card-Inhalte als Kontext: Gib alles, was ein späterer Schritt braucht, als Topic-Output zurück und setze zusätzlich einen Output, der den Beantwortet-Status festhält.

Sub-Agents sind der zweite Auslöser. Ein Child Agent läuft im Parent und bekommt dessen Konversationskontext immer, ohne Möglichkeit, das abzuschalten. Beim Connected Agent steuerst Du das über eine Einstellung. Steht im übergebenen Kontext eine Anfrage, die unbeantwortet aussieht, versucht der Sub-Agent, sie zu kompensieren – und antwortet ein zweites Mal.

Stolperfalle 16: Activity.Text ist leer, obwohl der Nutzer etwas geschrieben hat

Wer Activity.Text zum Protokollieren nutzt, bekommt im Betrieb Lücken, und die Ursache ist kein Bug. Ruft der Agent mangels Kontext eine Knowledge Source auf, bleibt Activity.Text für diesen Turn leer: Der Agent formuliert keine eigene Antwort, weil er die Entscheidung an die Wissensquelle abgibt. Dasselbe passiert bei Tools, die technisch als Activity umgesetzt sind. Die Variable greift eben jede Activity ab, die beim Agent ankommt, nicht die vorherige Nutzernachricht. Die dokumentierte Lösung ist schlicht: Nimm LastMessage.Text, wenn Du die letzte Nutzernachricht brauchst, und Activity.Text nur dort, wo Du wirklich die Activity meinst.

Zwei Verschärfungen dazu: Der Trigger OnPlanComplete läuft erst, wenn das Tool fertig ist. Wurde eine Knowledge Source genutzt, schreibt deren Ausgabe direkt in die Activity – und weil Activity.Text vorher leer war, steht am Ende die Tool-Nutzung darin statt einer Gesprächsnachricht. Bei intent- oder sprachbasierten Triggern passiert das nicht, weil die früher feuern und die Activity da schon eine Nachricht enthält. Und: In Teams fällt das stärker auf als in Copilot Studio, weil Teams Activity-Objekte direkt durchreicht, während Copilot Studio sie normalisiert. Derselbe Agent verhält sich also je nach Kanal sichtbar anders, ohne dass sich an seiner Logik etwas geändert hat.