Consulting Briefing

16.07.2026 · boddenberg.de

Copilot Studio: Low-Code-Erweiterungen für Custom Agents

Executive Summary

Copilot Studio ist längst kein Chatbot-Baukasten mehr, mit dem die Marketing-Abteilung einen freundlichen FAQ-Popup zusammenklickt. Microsoft hat das Werkzeug 2026 in eine vollwertige Low-Code-Plattform für autonome KI-Agents verwandelt: mehrstufige Workflows, Anbindung an über 1.400 Konnektoren, MCP-Server, Agent-zu-Agent-Kommunikation und Agents, die notfalls per Maus und Tastatur durch fremde Portale klicken. Die gute Nachricht: Du automatisierst interne Prozesse in Tagen statt Monaten. Die schlechte: Genau deshalb baut gerade jeder Fachbereich heimlich seinen eigenen Agent — mit Zugriff auf SharePoint, Dataverse und im Zweifel dein halbes Firmengeheimnis.

Die zentrale Management-Botschaft dieses Briefings lautet deshalb nicht „baut mehr Agents“, sondern „baut zuerst die Leitplanken“. Wer Governance, DLP-Richtlinien und ein sauberes Environment-Konzept erst nach dem ersten Datenleck einführt, zahlt den Aufpreis in Reputation und Nachtschichten. Wer es vorher tut, bekommt echte Produktivität fast geschenkt.

Abb. 1: Bausteine eines Custom Agent — die Orchestrierung im Zentrum, Wissen, Tools und Kanäle drumherum.

Worum geht es im Detail?

Ein Agent in Copilot Studio ist im Kern eine Orchestrierung: ein Sprachmodell, das anhand von Instruktionen, Kontext, Wissensquellen und Werkzeugen selbst entscheidet, welcher Schritt als Nächstes kommt. Früher musstest du jede Frage als „Topic“ mit Wenn-Dann-Knoten vormodellieren — heute übernimmt die generative Orchestrierung das Routing. Du beschreibst in natürlicher Sprache, was der Agent tun soll, hängst Wissensquellen wie SharePoint, Dataverse, Dateien oder das Web an, gibst ihm Tools — und der Rest passiert generativ. Das ist der eigentliche Low-Code-Sprung: nicht „weniger Klicks“, sondern „weniger vorgedachte Logik“.

Die spannenden Erweiterungen sitzen an den Rändern des Agents. Erstens Tools und Connectoren: über 1.400 vorgefertigte Konnektoren plus eigene Actions binden SAP, ServiceNow, Salesforce oder die hausinterne REST-API an. Zweitens Agent Flows und die neue Workflows-Experience — ein überarbeiteter visueller Designer, der deterministische Automatisierung und KI-native Blöcke auf einer Leinwand vereint. Du kannst einzelne Schritte mit Beispieldaten testen, bevor du live gehst, und ganze Agents als Knoten in einen Workflow einbetten, damit sie an definierter Stelle das Nachdenken übernehmen.

Drittens — und hier wird es interessant — die Anbindung an das Model Context Protocol (MCP) und die Agent-zu-Agent-Kommunikation, inzwischen allgemein verfügbar. Agents reichen Aufgaben untereinander weiter, delegieren Teilentscheidungen und greifen über MCP-Server auf externe Tools zu, ohne dass du jede Schnittstelle selbst verdrahtest. Viertens die Computer-Using Agents: Für Systeme ohne API bedient der Agent die Oberfläche wie ein Mensch — er klickt sich durch das Lieferantenportal, das seit 2009 kein Update gesehen hat. Klingt nach Magie, ist in der Praxis aber genau so robust wie das Portal, das es bedient. Sprich: bete mit.

Ein konkretes Bild dazu aus der Praxis: Ein mittelständischer Maschinenbauer wollte seinen Innendienst entlasten, der täglich Dutzende Male dieselbe Frage beantwortet — „Wo steht meine Bestellung?“. Der zuständige Teamleiter, kein Entwickler, sondern gelernter Industriekaufmann, baute in zwei Nachmittagen einen Agent: Instruktionen in Prosa, die Auftragslage aus dem ERP über einen Standard-Konnektor, die Versandinfos aus einer SharePoint-Liste. Nach einer Woche liefen 60 Prozent der Statusanfragen ohne menschliches Zutun. Der Haken kam im Review: Dieselbe SharePoint-Liste enthielt in einer Nachbarspalte die Einkaufskonditionen. Der Agent hätte sie auf Nachfrage bereitwillig vorgelesen. Nicht, weil jemand geschludert hat, sondern weil „schnell gebaut“ und „sauber berechtigt“ zwei verschiedene Projekte sind. Genau hier trennt sich der Bastel-Agent vom Produktions-Agent.

Wichtig für die Einordnung: Copilot Studio kennt zwei Betriebsmodi. Entweder du erweiterst Microsoft 365 Copilot mit einem Agent, der den vorhandenen Orchestrator nutzt — ideal, wenn der Agent im vertrauten Copilot-Chat leben soll. Oder du baust einen eigenständigen Agent mit voller Kontrolle über Branding, Modellwahl und Kanäle, den du auf Web, in Teams, als Voice-Agent oder über Direct Line ausrollst. Beide Wege führen über dieselbe Low-Code-Leinwand — der Unterschied liegt in Kontrolle und Reichweite. Und weil Microsoft die Orchestrierungsschicht 2026 überarbeitet hat, gibt es die Qualität obendrein günstiger: rund 20 Prozent bessere Bewertungsergebnisse bei etwa halbiertem Tokenverbrauch.

Was sind Chancen? Was sind Risiken?

Fangen wir mit dem an, was den Vorstand glücklich macht. Die Chance ist Geschwindigkeit ohne Entwicklerstau: Ein Fachbereich, der seinen Urlaubsantrags-Prozess kennt, baut den passenden Agent selbst — inklusive Anbindung an das HR-System — und muss nicht sechs Monate auf ein Ticket in der Entwicklungspipeline warten. Repetitive Vorgänge (Statusabfragen, Genehmigungen, Datenextraktion, Erstqualifizierung von Tickets) wandern an Agents, die rund um die Uhr arbeiten und nie „mach ich nach dem Mittag“ sagen. Für Systeme ohne saubere Schnittstelle springt der Computer-Using-Agent ein, für Contact-Center gibt es inzwischen echte Sprach-Agents in Echtzeit.

Jetzt die Kehrseite, und die ist deftig. Risiko Nummer eins heißt Wildwuchs. Weil das Bauen so einfach ist, entstehen Agents schneller, als die IT sie zählen kann — im Default-Environment, wo jeder Nutzer automatisch die Maker-Rolle hält. Das klassische Schatten-IT-Problem, nur diesmal mit Zugriff auf Firmendaten und der Fähigkeit, selbstständig zu handeln. Risiko Nummer zwei ist Datenabfluss über Wissensquellen: Hängt jemand eine SharePoint-Bibliothek an, deren Berechtigungen über Jahre verwildert sind, plaudert der Agent brav aus, was der Nutzer eigentlich nie hätte sehen sollen. Der Agent ist nicht böse — er ist nur gründlich.

Risiko Nummer drei ist die Governance-Lücke bei der Verteilung. Ein Agent, der über einen geteilten Teams-Link verbreitet wird, umgeht die Admin-Freigabe komplett — die Sichtbarkeit ist deutlich geringer als bei einem sauber freigegebenen App-Manifest. Und Viewer-Berechtigungen greifen eben nicht überall: Für SharePoint-Inhalte und unauthentifizierte Kanäle gelten sie schlicht nicht. Kurz: Die Technik ist reif, die Kontrolle hängt an deiner Organisation. Copilot Studio gibt dir eine geladene Waffe mit sehr bequemem Abzug — der Sicherheitsmechanismus heißt Governance, und den musst du selbst einbauen.

Ein zweites Praxisbeispiel zeigt, wie schnell aus Bequemlichkeit ein Vorfall wird. Eine Marketing-Abteilung wollte einen freundlichen Produkt-Assistenten auf der öffentlichen Website und schaltete dafür den anonymen Web-Kanal frei — verständlich, denn ein Login-Zwang vor dem Erstkontakt vergrault Interessenten. Angebunden wurde eine SharePoint-Site mit „allen Produktunterlagen“. In diesem „alle“ steckten auch Preiskalkulationen und ein internes Wettbewerbsdossier. Erst ein neugieriger Tester, der den Agent bat, „mal die interne Marge zusammenzufassen“, brachte es ans Licht. Kein Hack, keine Lücke im Produkt — nur ein Kanal ohne Authentifizierung, kombiniert mit einer Wissensquelle, die niemand auf ihre Berechtigungen geprüft hatte. Die Lehre: Der Agent ist immer nur so diskret wie die schwächste angebundene Quelle.

Abb. 2: Der Governance-Stack — jede Schicht ist Voraussetzung für die darüber. Ohne Fundament wackelt alles.

Was müssen wir jetzt schon vorbereiten?

Die Reihenfolge ist entscheidend, und sie ist unbequem: erst der langweilige Teil, dann der coole. Wer zuerst Agents baut und danach Governance nachrüstet, räumt hinterher auf — und das ist immer teurer. Beginne mit einem Environment-Konzept. Trenne die Agent-Entwicklung vom allgemeinen Power-Apps-Betrieb und richte dedizierte Environments ein. Auf das Default-Environment gehören restriktive Datenrichtlinien, damit der Blast-Radius der unvermeidlichen Bastel-Agents klein bleibt.

Aktiviere Managed Environments für die Agent-Workloads. Das gern gebrachte Kostenargument zieht hier nicht: Der Copilot-Credit-Verbrauch ändert sich dadurch nicht, aber du bekommst Sharing-Limits, Environment-Group-Regeln und bessere Laufzeitüberwachung frei Haus. Dann die DLP-Data-Policies — dein primäres Steuerungsinstrument. Sie regeln Authentifizierung, Kanäle, Wissensquellen und Konnektoren. Seit Anfang 2025 ist die DLP-Durchsetzung für Copilot Studio tenantweit standardmäßig aktiv; das alte PowerShell-Kommando zum Scharfschalten brauchst du nicht mehr. Pro-Agent-Ausnahmen gibt es nicht — alle Agents müssen sich fügen.

Auf der Identitätsebene gilt: In Produktion nur authentifizierte Agents. Verlange Microsoft-Entra-ID-Authentifizierung und blockiere unauthentifizierte Kanäle, damit überhaupt eine Identitätsspur für das Compliance-Monitoring existiert. Erzwinge außerdem, dass Tool-Aufrufe mit den Rechten des Endnutzers laufen und nicht mit denen des Erstellers — sonst schleicht sich über die Maker-Berechtigungen eine stille Rechteausweitung ein. Achtung: Genau das bricht rein autonome Agents, weil die keinen aktiven Nutzer haben. Das ist kein Bug, sondern eine Designentscheidung, die du bewusst treffen musst.

Organisatorisch ist Agent-Governance ein Mannschaftssport. Kein einzelnes Team hat den vollen Überblick: Der Power-Platform-Admin steuert Environments und DLP, das Compliance-Team besitzt die Purview-Werkzeuge (Communication Compliance, Insider Risk, DSPM), die Netzwerksicherheit verwaltet den abgesicherten Zugang. Definiere frühzeitig, wem welches Werkzeug gehört und welche Eskalationswege gelten, wenn ein Agent über Zuständigkeitsgrenzen hinweg Unsinn baut. Zur Inventarisierung kombinierst du die Bordmittel — die Inventory-Ansicht im Admin Center, die Agent-Registry in Agent 365 — mit Community-Werkzeugen wie dem Copilot Studio Monitor, der Details wie Computer-Use-Fähigkeit und anonyme Zugriffsmuster sichtbar macht, die die Standardtools schlicht verschweigen.

Häufig gestellte Fragen

Brauche ich zum Bauen eines Agents in Copilot Studio Programmierkenntnisse?

Nein. Copilot Studio ist eine Low-Code-Plattform: Du beschreibst Instruktionen, Wissensquellen und Werkzeuge in natürlicher Sprache auf einer visuellen Leinwand. Programmierkenntnisse helfen bei eigenen Actions, komplexen Workflows und API-Anbindungen, sind für den Einstieg aber nicht nötig.

Worin unterscheidet sich ein Copilot-Studio-Agent von einem klassischen Chatbot?

Ein klassischer Bot folgt vormodellierten Wenn-Dann-Pfaden. Ein Agent nutzt generative Orchestrierung: Er entscheidet anhand von Kontext und Zielen selbst, welche Wissensquelle er abfragt und welches Werkzeug er aufruft — und kann Aufgaben auch autonom oder per Trigger ausführen, statt nur zu antworten.

Wie verhindere ich, dass ein Agent auf Daten zugreift, die er nicht sehen soll?

Über DLP-Datenrichtlinien und ein sauberes Environment-Konzept steuerst du Konnektoren, Kanäle und Wissensquellen zentral. Entscheidend ist zusätzlich, die Berechtigungen der angebundenen SharePoint- oder Dataverse-Quellen zu prüfen, denn der Agent gibt nur das weiter, worauf er technisch Zugriff hat.

Ist die DLP-Durchsetzung für Copilot Studio automatisch aktiv?

Ja. Seit Anfang 2025 ist die DLP-Durchsetzung tenantweit standardmäßig aktiviert; das frühere PowerShell-Kommando zum Scharfschalten ist nicht mehr nötig. Pro-Agent-Ausnahmen gibt es nicht — alle Agents unterliegen den definierten Richtlinien.

Was kostet der Betrieb, und wie behalte ich den Verbrauch im Griff?

Der Betrieb wird über Copilot Credits abgerechnet, deren Verbrauch von Nutzung und Modellwahl abhängt. Nutze vor dem Skalieren den Agent-Usage-Estimator zur Prognose und beobachte den tatsächlichen Verbrauch über die Consumption-Reports im Admin Center.