Copilot Studio ermöglicht tiefere KI-Anpassungen für Entwickler und Power User

Consulting Briefing · 29.07.2026 · boddenberg.de

Executive Summary

Copilot Studio ist nicht mehr der nette Chatbot-Baukasten, den du 2024 in der Mittagspause zusammengeklickt hast. Microsoft hat das Werkzeug in den vergangenen zwölf Monaten von innen heraus umgebaut, und zwar so gründlich, dass du 2026 im Grunde über ein anderes Produkt sprichst. Der Orchestrator führt inzwischen Python, Node.js und Shell-Befehle in einer eigenen Sitzungsumgebung aus. Agenten bedienen klassische Windows-Anwendungen über die Oberfläche, wenn es keine Schnittstelle gibt. Agenten reden über A2A miteinander. Und Werkzeuge werden nicht mehr einzeln verdrahtet, sondern über MCP-Server angebunden.

Für dich als Entwickler oder ambitionierten Power User heißt das: Du bekommst endlich echte Tiefe. Du wählst Modelle, beschreibst Verhalten in wiederverwendbaren Skills als Markdown, mischst deterministische Workflows mit generativer Reasoning-Logik und testest den ganzen Kram über eine Evaluate-Mechanik, die dir Testkonversationen automatisch erzeugt. Für deinen Auftraggeber heißt es vor allem: Die Rechnung wird spannender, Governance wird Pflicht, und der alte Bestand an Topics-basierten Agenten hat ein Ablaufdatum ohne Migrationspfad.

Worum geht es im Detail?

Fangen wir mit der unangenehmen Wahrheit an: Der Editor, den du kennst, ist Geschichte. Seit dem Juni-Release gibt es eine neu gebaute Oberfläche mit vier Reitern — Build, Preview, Evaluate und Monitor. Skills, Werkzeuge und Wissensquellen liegen gemeinsam im Build-Reiter statt verteilt über sieben Dialoge. Das klingt nach Kosmetik, ist aber die Konsequenz aus der größten inhaltlichen Änderung: Topics sind weg. Die klassische Steuerung von Gesprächsverläufen über Dialogbäume, das Herzstück des alten Power Virtual Agents, existiert im neuen Modell nicht mehr. An ihre Stelle treten Skills und Workflows.

Der Unterschied ist grundsätzlich, nicht graduell. Ein Skill ist eine wiederverwendbare, in Markdown formulierte Verhaltensbeschreibung. Du schreibst also auf, wie sich der Agent in einer Situation verhalten soll, statt einen Baum aus Bedingungen zusammenzuklicken. Ein Workflow ist der deterministische Teil: Reihenfolge, Verzweigungen, autonome Auslöser. Tools sind die Verbindung nach draußen, über Power-Automate-Konnektoren oder eben über MCP. Das eigentlich Neue ist die Kombination — du hängst bestehende Agenten direkt als Schritt in einen Workflow. Deterministische Logik dort, wo sie hingehört, generatives Denken dort, wo es wirklich hilft.

Zwölf Monate Produktumbau: von der MCP-Freigabe bis zum neuen Editor

Darunter arbeitet ein deutlich stärkerer Orchestrator. Microsoft hat den KI-Stack ausgetauscht und meldet rund zwanzig Prozent mehr Leistung bei etwa halbiertem Tokenverbrauch. Wichtiger als die Zahlen ist die neue Fähigkeit: Der Orchestrator setzt Shell-Befehle ab, führt Python- und Node.js-Skripte aus und verwaltet dabei einen Sitzungs-Workspace. Damit ist der Agent kein Antwortautomat mehr, sondern etwas, das mehrstufig arbeitet, Zwischenstände ablegt und selbst entscheidet, welches Werkzeug als nächstes dran ist. Das ist der Punkt, an dem die Diskussion aufhört, eine Chatbot-Diskussion zu sein.

Dazu kommen zwei Bausteine, die seit Mai allgemein verfügbar sind. Erstens Computer Use: Agenten bedienen Webseiten und Desktop-Anwendungen über die Oberfläche. Das ist die Antwort auf jedes Altsystem, das seit 2003 keine Schnittstelle bekommen hat und auch keine mehr bekommen wird. Zweitens Agent-to-Agent-Kommunikation, ebenfalls allgemein verfügbar, mit der Agenten Aufgaben an andere Agenten delegieren — auch über Systemgrenzen hinweg. Wer schon einmal eine verteilte Architektur ohne Ablaufverfolgung debuggt hat, ahnt, worauf das hinausläuft.

Bei den Modellen ist im Juli Bewegung gekommen. Mit GPT-5.6 von OpenAI und Claude Sonnet 5 von Anthropic stehen zwei neue Frontier-Modelle bereit. Das ist mehr als eine Fußnote, denn die Modellwahl ist einer der wenigen Hebel, mit denen du Qualität und Kosten gleichzeitig bewegst. Nur ist ein Modellwechsel eben kein Konfigurationsschalter. Deine Anweisungen, deine Skills und deine Werkzeugbeschreibungen sind auf ein bestimmtes Verhalten hin optimiert. Wer blind umschaltet, hat am Montag eine Agentenflotte mit neuer Persönlichkeit und ein Ticketaufkommen, das sich niemand erklären kann.

Und dann ist da die Ebenenfrage, die in fast jedem Projekt falsch beantwortet wird. Es gibt drei Wege, einen Agenten zu bauen. Der deklarative Agent aus dem Agent Builder nutzt Orchestrator und Modell von Microsoft 365 Copilot — du lieferst Anweisungen, Wissen und Aktionen, sonst nichts. Copilot Studio gibt dir Modellauswahl, Skills, Workflows, MCP und Codeausführung. Der Custom Engine Agent auf Basis des Microsoft 365 Agents SDK gibt dir alles: eigenes Modell, eigener Orchestrator über Semantic Kernel oder LangChain, eigener Sicherheits-Stack. Er gibt dir allerdings auch die komplette Betriebsverantwortung zurück, inklusive der Frage, wer nachts um drei die Bereitschaft hat.

Entscheidungsmatrix: Was du auf welcher Ebene tatsächlich steuerst

Was sind Chancen? Was sind Risiken?

Die Chance ist real und größer, als die üblichen Marketingfolien vermuten lassen. Zum ersten Mal automatisierst du Prozesse, die bisher an der Schnittstellenfrage gescheitert sind. Ein Beispiel, das Microsoft selbst anführt: Graebel, ein Anbieter für Mitarbeiterumzüge, lässt einen Service-Order-Agent unstrukturierte E-Mails auslesen, Geschäftsregeln prüfen und Aufträge anlegen — über eine Kombination aus Computer Use und Workflow-Orchestrierung. Genau das war bis vor kurzem der klassische Fall für eine Werkstudentenstelle mit hoher Fluktuation und einem Wissensstand, der jeden September auf null fiel.

Die zweite Chance ist Testbarkeit. Der Evaluate-Modus erzeugt dir auf Basis deiner Agentenanweisungen automatisch zehn, fünfundzwanzig oder fünfzig Testkonversationen. Das ist noch keine vollwertige Regressionssuite, aber es ist der Unterschied zwischen 'wir haben es dreimal ausprobiert und es lief' und einer belastbaren Aussage. Wer schon einmal einem Betriebsrat erklären musste, warum ein Agent eine bestimmte Antwort gegeben hat, weiß, wie viel dieser Unterschied wert ist.

Damit sind wir bei den Risiken, und das erste ist finanzieller Natur. Copilot Studio wird nach Verbrauch abgerechnet, nicht nach Nutzern. Ein Kapazitätspaket mit 25.000 Copilot Credits liegt bei rund 200 US-Dollar pro Tenant und Monat im Jahresabo, per Pay-as-you-go über einen Azure-Meter bei etwa einem Cent je Credit. Die Credits sind auf Tenant-Ebene gepoolt. Und jetzt der Teil, der in Projekten regelmäßig für lange Gesichter sorgt: Der Verbrauch je Interaktion schwankt drastisch. Eine klassische Antwort kostet ungefähr einen Credit, eine generative rund zwei, eine mit Grounding im Tenant Graph etwa zehn — und eine autonome Agentenaktion fünfundzwanzig oder mehr. Seit der Umstellung von Messages auf Credits im September 2025 ist derselbe Topf einfach deutlich differenzierter verteilt.

Verbrauchsprofil und Hochrechnung: warum autonome Agenten ein eigenes Limit brauchen

Das zweite Risiko ist Schatten-IT in neuer Kleidung. Natural-Language-First bedeutet, dass jemand aus dem Vertrieb in zehn Minuten einen Agenten mit Zugriff auf Geschäftsdaten baut, ohne einen einzigen Dialog zu öffnen. Das ist genau der Punkt, an dem die Advanced Connector Policies aufhören, ein Governance-Thema zu sein, und anfangen, ein Sicherheitsthema zu werden. Ein MCP-Server ist aus Sicht der Plattform ein Konnektor — was gut ist, weil deine Richtlinien greifen, und unangenehm, wenn du nie welche definiert hast.

Das dritte Risiko ist Nachvollziehbarkeit. Ein Agent, der Shell-Befehle ausführt, Aufgaben an andere Agenten delegiert und nebenbei eine Desktop-Anwendung fernsteuert, erzeugt eine Wirkungskette, die du im Zweifel rekonstruieren musst. Nicht weil es akademisch interessant wäre, sondern weil irgendwann jemand fragt, warum eine Bestellung über einen sechsstelligen Betrag ausgelöst wurde. Wer hier keine Protokollierung, keine Genehmigungsschritte und keine klaren Berechtigungsgrenzen hat, betreibt kein System, sondern eine Hoffnung.

Was müssen wir jetzt schon vorbereiten?

Die gute Nachricht: Das meiste davon ist Handwerk und kostet vor allem Entschlossenheit, nicht Budget. Die schlechte: Es wirkt nur, wenn du es machst, bevor die erste Fachabteilung produktiv geht.

Bestandsaufnahme erzwingen. Zähle jeden Agenten im Tenant, notiere Besitzer, Status und aktive Auslöser. Alles ohne benannten Besitzer wird deaktiviert und nicht diskutiert.

Umgebungsstrategie festlegen. Getrennte Umgebungen für Entwicklung, Test und Produktion, mit Advanced Connector Policies je Umgebungsgruppe. Das Allowlist-Modell ist seit Juni verfügbar, nutze es, statt Verbote einzeln nachzupflegen.

Credit-Budget und Alarmierung aufsetzen. Lege fest, welches Team welchen Anteil verbraucht, und richte Schwellenwerte ein. Autonome Agenten bekommen ein eigenes, hartes Limit.

Entscheidungsraster für die Bauebene dokumentieren. Deklarativ, Copilot Studio oder Custom Engine, mit klaren Kriterien statt dem Bauchgefühl des jeweils lautesten Entwicklers.

MCP-Server wie Produkte behandeln. Versionierung, Besitzer, Testfälle, Freigabeprozess. Ein MCP-Server ist eine Schnittstelle, kein Wochenendskript.

Keine Fachlogik im Agenten vergraben. Alles, was Geschäftsregel ist, gehört in einen Workflow, eine Schnittstelle oder einen MCP-Server — also dorthin, wo es den nächsten Plattformumbau übersteht.

Modellwechsel als Änderung behandeln. Neue Frontier-Modelle bekommen einen Testlauf über die Evaluate-Konversationen, bevor sie produktiv gehen.

Informationsquelle umstellen. Seit dem 2. Juli 2026 laufen die Feature-Updates für Copilot Studio über die Microsoft-365-Roadmap. Der Release Planner ist für diese Produkte keine Quelle mehr, wer dort weiter nachsieht, plant mit Vergangenheit.

Häufig gestellte Fragen

Lohnt sich Copilot Studio auch ohne Microsoft-365-Copilot-Lizenzen?

Ja, technisch läuft Copilot Studio eigenständig und wird über Copilot Credits abgerechnet, die auf Tenant-Ebene gepoolt sind. Wirtschaftlich sieht es anders aus, denn interne Interaktionen von Anwendern mit voller Microsoft-365-Copilot-Lizenz verbrauchen keine Credits — je nach Nutzerzahl kippt die Rechnung dadurch erheblich.

Was passiert mit meinen bestehenden Agenten, die auf Topics basieren?

Sie laufen weiter, sind aber eine Sackgasse: Die neue Copilot-Studio-Generation kennt keine Topics mehr, und zwischen den Versionen gibt es zum jetzigen Stand keinen Migrationspfad. Plane für umfangreiche Bestände einen Neubau ein und verlagere Geschäftslogik schon heute in Workflows und Schnittstellen, damit der Neubau am Ende nur die Oberfläche betrifft.

Wann brauche ich einen Custom Engine Agent statt Copilot Studio?

Wenn du ein eigenes Sprachmodell, eine eigene Orchestrierungslogik oder einen eigenen Sicherheits-Stack zwingend brauchst, etwa wegen regulatorischer Vorgaben oder weil dein Anwendungsfall mehrstufige Entscheidungen erfordert, die der Plattform-Orchestrator nicht abbildet. In allen anderen Fällen bezahlst du mit dem Custom Engine Agent vor allem Betriebsaufwand für Freiheiten, die du nie nutzt.

Wie halte ich die Kosten autonomer Agenten unter Kontrolle?

Setze ein hartes Credit-Limit je Umgebung, begrenze die Auslösefrequenz autonomer Agenten und miss den tatsächlichen Verbrauch im Monitor-Bereich, bevor du in die Breite gehst. Der teuerste Fehler ist ein nächtlicher Auslöser, der wochenlang läuft, ohne dass jemand die Zahl der ausgeführten Aktionen kennt.

Sind MCP-Server ein Sicherheitsrisiko im Tenant?

Nicht grundsätzlich, denn der Zugriff läuft über Power-Platform-Konnektoren und unterliegt damit denselben Datenrichtlinien wie jeder andere Konnektor. Kritisch wird es erst, wenn gar keine Richtlinien definiert sind — dann bindet jeder Ersteller beliebige externe Werkzeuge an, und die Advanced Connector Policies mit ihrem Allowlist-Modell sind genau dafür der richtige Hebel.