Dein Flow ist das Tool: Warum Agenten-Werkzeug in die Power Platform gehört und nicht ins Repo

Du hast einen Flow, der seit zwei Jahren zuverlässig läuft. Urlaubsantrag prüfen: Er holt den Resturlaub aus Dataverse, rechnet die Tage gegen den Anspruch, schreibt den Antrag weg und schickt eine Mail an die Führungskraft. Sieben Aktionen, deterministisch, mit geprüften Verbindungen und einer DLP-Richtlinie darüber.

Daneben steht dein Agent. Er bekommt dieselbe Aufgabe und löst sie zu Fuß: Er fragt Dataverse ab, bekommt Rohdaten, rechnet im Modell nach, formuliert eine Mail. Das Ergebnis stimmt meistens. Es kostet mehr Tokens, dauert länger und ist bei jedem Durchlauf ein bisschen anders.

Der Reflex in der Agenten-Welt lautet an dieser Stelle: Dann baue ich mir die deterministischen Schritte eben als Skill lokal ins Repo. Und die Frage, um die es in diesem Artikel geht, lautet: Warum eigentlich lokal? Du bist Power-Platform-Entwickler. Die Logik existiert schon, sie liegt in deiner Umgebung, sie ist abgesichert. Sie muss nicht neu erfunden werden — sie muss erreichbar werden.

Zwei Dinge, die ständig verwechselt werden

Vorher müssen wir zwei Fälle auseinanderhalten, sonst reden wir aneinander vorbei.

Beim Bauen hilft dir ein Agent, Flows zu erstellen, zu ändern und zu reparieren. Das gibt es, und das kannst du heute nutzen — das Power-Automate-Plugin im Power-Platform-Skills-Marketplace bringt Cloud Flows in die GitHub-Copilot-CLI und in Claude Code: anlegen, ändern, ausführen, fehlgeschlagene Läufe untersuchen, alles im Gespräch. Wie das in der Praxis aussieht, steht in Power Automate ohne Portal-Geklicke.

Im Betrieb wird der fertige Flow zum Werkzeug für einen Agenten. Nicht du rufst ihn auf, sondern der Agent entscheidet selbst, dass er ihn braucht.

Um den zweiten Fall geht es hier. Der erste kommt in diesem Artikel nicht mehr vor.

Die Richtung dreht sich um

So sah es bisher aus: Ein Flow läuft an, und irgendwo in seiner Mitte ruft er etwas Intelligentes auf — eine Prompt-Aktion, einen KI-Connector, ein Modell. Der Flow ist der Chef, die KI ist eine Aktion unter vielen.

vorher:   Trigger  →  Flow  →  [KI-Aktion]  →  Ergebnis
nachher:  Frage    →  Agent →  [Flow]       →  Ergebnis

Jetzt kehrt sich das um. Der Agent ist der Chef, und der Flow ist das Tool. Der Agent bekommt eine Liste verfügbarer Werkzeuge, liest deren Beschreibungen, und wenn eine davon zur Aufgabe passt, ruft er sie mit typisierten Parametern auf. Er bekommt ein sauberes, strukturiertes Ergebnis zurück, statt sich eines zusammenzureimen.

Der Gewinn liegt nicht im Neubau. Er liegt darin, dass Automatisierungslogik, Connector-Governance und DLP-Regeln, die längst stehen, für Agenten erreichbar werden, ohne dass du sie in ein Repo kopierst. Wie viel Umbau dafür trotzdem nötig ist, klärt der nächste Abschnitt.

Was heute geht — und wo es dokumentiert steht

Das ist kein Zukunftsversprechen. Microsoft beschreibt für Agenten auf dem GitHub-Copilot-Harness in Copilot Studio genau drei Sorten von Werkzeugen, die du anhängen kannst: Connectors, MCP-Server und Workflows.

Der Satz zu den Workflows ist der, auf den es ankommt. Sie lassen den Agenten mehrstufige Prozesse ausführen — Freigaben, Datentransformationen, Geschäftslogik — und sind laut Doku gedacht für wiederholbare, deterministische Prozesse, die dein Agent bei Bedarf ausführt. Das ist genau die These dieses Artikels, in Microsofts eigenen Worten.

Und jetzt der Teil, der in keiner Doku steht, nachgeprüft im September 2026 in einem frisch angelegten Power-Platform-Tenant: Einen bestehenden Cloud Flow kannst du nicht anhängen. Der Tool-Dialog sagt es selbst, im Bild weiter unten: „Es werden nur Workflows angezeigt, die den Auslöser ‚Wenn ein Agent den Workflow aufruft’ verwenden. Power-Automate-Cloud-Flows werden nicht unterstützt.” Und das gilt wörtlich — auch ein Cloud Flow, der exakt diesen Trigger trägt, taucht in der Liste nicht auf.

Was stattdessen funktioniert, sind drei Schritte:

1. Hülle anlegen. In Copilot Studio unter Arbeitsabläufe → Neuer Workflow als Triggertyp „Wenn ein Agent den Workflow aufruft” wählen. Der Designer setzt daraufhin automatisch die beiden Knoten When an agent calls the flow und Respond to the agent — dieselbe Form, die ein Cloud Flow mit Skills-Trigger auch hat.
2. Eingaben definieren und veröffentlichen. Das Veröffentlichen ist nicht optional und nicht bloß Kosmetik: Solange der Workflow Entwurf ist, existiert er für die Web-API nicht. Abfragen auf die workflow-Tabelle liefern ihn nicht zurück, ein Zugriff über seine ID endet mit „Does Not Exist”. Erst das Veröffentlichen legt die Zeile wirklich an.
3. Logik einspielen. Danach ist der Workflow ein ganz normaler Flow und taucht auch in Power Automate auf. Seine Definition lässt sich über die reguläre Flow-API schreiben — du legst also genau die Aktionen hinein, die du schon hast, statt sie zu klicken.

Die These hält, sie wird nur genauer: Die Logik bleibt in der Power Platform und wandert nicht ins Repo. Geschenkt bekommst du sie trotzdem nicht — einmal anfassen musst du sie. Was du sparst, ist das Nachbauen der Logik. Was du zahlst, ist eine neue Hülle darum.

So hängst du es an:

Weg 1 — der Workflow als Tool. Im Agenten auf Tools → Tool hinzufügen → Arbeitsabläufe, dann den Workflow auswählen. Der Agent sieht Name, Beschreibung und Parameter und ruft ihn auf, wenn die Aufgabe passt. Kein eigener Endpunkt, kein MCP nötig. Nach dem eben Gesagten mit einer Einschränkung: Es muss ein Copilot-Studio-Workflow sein, kein Cloud Flow.

Weg 2 — ein MCP-Server als Tool. Derselbe Ort, Tool hinzufügen → Model Context Protocol, dann den Server auswählen. Copilot Studio übernimmt Name, Beschreibung, Ein- und Ausgaben direkt vom Server und zieht Änderungen nach, wenn sich dort etwas ändert. Einzelne Tools eines Servers kannst du im Agenten gezielt abschalten — standardmäßig sind alle an. Eigene MCP-Server kannst du bei Microsoft zur Zertifizierung einreichen.

Beide enden am selben Punkt: Der Agent entdeckt das Werkzeug selbst und entscheidet selbst, wann er es benutzt.

Der unsichtbare Star: die Beschreibung

Das Feld, an dem die ganze Sache hängt, ist nicht der Flow. Es ist seine Beschreibung.

Der Agent sieht deinen Flow nicht. Er sieht einen Namen, eine Beschreibung und ein Parameterschema — mehr nicht. Genau daraus entscheidet er, ob dieses Werkzeug zur Frage passt. Eine Beschreibung wie „Prüft Anträge” führt dazu, dass er das Tool entweder gar nicht oder ständig falsch aufruft.

Wie wörtlich das zu nehmen ist, sieht man im Bild oben: Im Tool-Dialog steht unter dem Namen nichts als die Beschreibung. Sie ist alles, was zwischen deinem Flow und der Entscheidung des Agenten steht.

Was funktioniert:

• Ein Satz, was der Flow tut — in der Sprache der Aufgabe, nicht in der Sprache der Implementierung. Nicht „liest Dataverse und sendet Mail”, sondern „prüft einen Urlaubsantrag gegen den Resturlaub und benachrichtigt die Führungskraft”.
• Wann er zuständig ist — und, fast wichtiger, wann nicht. „Nur für Urlaubsanträge, nicht für Krankmeldungen.”
• Sprechende Parameternamen. mitarbeiterEmail statt param1. Der Agent füllt die Felder aus dem Gespräch — er kann nur befüllen, was er versteht.

Das ist keine Kosmetik. Das ist der Schritt, der entscheidet, ob die Sache funktioniert. Was der Agent darüber hinaus an verlässlichem Kontext braucht, ist ein eigenes Thema — nachzulesen in Copilot Agents richtig erden.

Das Werkzeug liefert

Und damit zu dem, worauf es ankommt: dem Ergebnis.

Der Workflow ist angelegt, veröffentlicht, hängt als Tool am Agenten — und er läuft. Aufgerufen mit drei typisierten Parametern:

mitarbeiterEmail:  alex.beispiel@contoso.com
startDatum:        2026-10-05
endDatum:          2026-10-09

Elf Sekunden, jede Aktion erfolgreich. Und das Ergebnis steht danach nicht in einer Modellantwort, die man nachprüfen müsste, sondern in Dataverse:

	vorher	nachher
Urlaubsantrag	keiner	05.–09.10.2026, 5 Tage, Status genehmigt
Resturlaub Alex Beispiel	12	7

Fünf Tage, nicht „ungefähr eine Woche”. Sieben Resttage, nicht „noch ein paar übrig”. Beim nächsten Aufruf kommt dasselbe heraus, und beim übernächsten auch — das ist der ganze Unterschied zwischen einem Werkzeug und einem Sprachmodell, das gut rät.

Dazu kommt, was auf dem Bild nur nebenbei zu sehen ist: Der Lauf steht in der Historie. Mit Zeitstempel, mit den Eingaben, mit dem Ergebnis jeder einzelnen Aktion. Ein Skill im lokalen Repo hätte an dieser Stelle nichts vorzuweisen.

Was hier noch offen ist, gehört dazu: Ein Token-Vergleich zwischen dem freien Weg und dem Tool-Aufruf steht aus. Beide Wege laufen inzwischen, der Vergleich braucht aber zwei Durchläufe unter gleichen Bedingungen — und die sind nicht gemessen. Geschätzte Werte kommen hier nicht hin.

Die Hürde, über die niemand schreibt

Bis hierhin klingt das nach einem Nachmittag Arbeit. Ist es nicht, und der Grund hat nichts mit Technik zu tun.

Den Workflow anzulegen, zu veröffentlichen, über die API mit Logik zu füllen und laufen zu lassen, geht in einem Power-Platform-Trial-Tenant ohne Weiteres — wie du an einen solchen Tenant kommst, steht in Welche Trial über welches Postfach?. Alles, was du bis hier gesehen hast, ist darin entstanden.

Einen Agenten anzulegen geht nicht. Copilot Studio bricht ab mit „You don’t have permission to create agents … Benutzerlizenz nicht gefunden”. Die Meldung führt in die Irre. Es fehlt keine Arbeitsplatzlizenz, sondern ein Abrechnungsplan. Das Power Platform Admin Center sagt es unter Lizenzierung → Copilot Studio unmissverständlich: „Um die von Ihnen erstellten Agents zu verwenden und ihre Nutzung nachzuverfolgen, müssen Sie einen Abrechnungsplan einrichten.” Das neue Copilot Studio rechnet über Guthaben ab und will dafür ein hinterlegtes Azure-Abonnement sehen.

Die Abkürzung über einen Lizenzkauf gibt es nicht. Die SKU, die im Produktkatalog „Microsoft Copilot Studio” heißt und dort als lizenzbasiert geführt wird, gilt in Wahrheit für den ganzen Mandanten: Alle ihre Dienstpläne sind vom Typ Company. Sie lässt sich keinem Benutzer zuweisen — weder im Admin Center, wo sie unter „Lizenzen und Apps” gar nicht erst auftaucht, noch über Graph, das sie mit „cannot be assigned to a user” ablehnt. Sie kauft Nachrichtenkontingent, keinen Zugang.

Die Grenze verläuft also klar: Das Werkzeug ist kostenlos. Der Agent in Copilot Studio ist es nicht. Wer das nachbaut, sollte es vorher wissen — und sollte nicht den Fehler machen, die irreführende Lizenzmeldung für bare Münze zu nehmen und Lizenzen zu kaufen, die nichts freischalten.

Der Beweis braucht Copilot Studio nicht

Der Agent dort scheitert am Abrechnungsplan. Die These dieses Artikels scheitert daran nicht, denn sie hängt nicht an einem bestimmten Agenten.

Was ein Agent braucht, um deinen Flow zu benutzen, sind vier Dinge: ein Name, eine Beschreibung, ein Parameterschema und ein Aufruf. Das liefert ein MCP-Server in rund hundert Zeilen. Er meldet ein einziges Werkzeug an, urlaubsantrag_pruefen, mit genau der Beschreibung aus dem Abschnitt oben — wörtlich, nicht sinngemäß — und drei Pflichtfeldern. Ruft der Agent das Werkzeug, schickt der Server einen POST an die Callback-URL des Flows und reicht dessen Antwort zurück.

Dafür muss vorne der Trigger getauscht werden. Ein Flow mit Skills-Trigger gibt seine Callback-URL nicht heraus (ListCallbackUrlOperationBlocked), ein Flow mit HTTP-Trigger schon. Dieselben Aktionen dahinter, dieselbe Umgebung, dieselben Connection References — nur eine andere Tür.

Im Video ist die ganze Kette zu sehen. Die Frage nennt keine E-Mail-Adresse, also fragt der Agent nach — nicht aus Höflichkeit, sondern weil er aus der Beschreibung liest, dass der Aufruf den Antrag wirklich anlegt. Ein reines „Geht das überhaupt?” ohne Nebenwirkung gibt dieses Werkzeug nicht her. Nach der Antwort füllt er das Schema aus dem Gespräch, ruft den Flow, und was zurückkommt, sind getippte Felder statt einer Formulierung:

Feld	Wert
Entscheidung	genehmigt
Zeitraum	02.–04.11.2026
Beantragte Tage	3
Resturlaub danach	9

Elf ausgeführte Aktionen, eine übersprungene Zweigaktion, gut eine Sekunde — das steht rechts im Bild in der Lauf-Historie, mit Dauer und Status. (Die Demodaten werden vor jedem Durchlauf zurückgesetzt, deshalb startet Alex auch hier wieder bei zwölf Tagen.)

Damit steht die These nicht mehr als Behauptung da: Der Agent hat nichts gerechnet. Er hat ein Werkzeug benutzt, das in der Power Platform liegt.

Erst die Begriffe, sonst wird es peinlich

Drei Sachen, die in fast jedem Beitrag zu diesem Thema durcheinandergehen.

MCP ist kein Microsoft-Protokoll. Das Model Context Protocol ist ein offener Standard von Anthropic — der Anschluss, über den ein Agent fremde Systeme erreicht. Microsoft liefert dazu MCP-Server: Dataverse, Power Apps, Process Mining. Das ist ein Unterschied wie zwischen HTTP und einem Webserver. Wer von „Microsofts MCP” spricht, hat es nicht verstanden. Wie so ein Server von innen aussieht — Tools, Resources, Rückkanal — steht ausführlicher in UI-Komponenten im Chat.

Power Apps MCP ist nicht Power Automate MCP. Der Power-Apps-MCP-Server ist seit dem 11. Februar 2026 in Public Preview, zunächst nur in US-Early-Release-Umgebungen, mit schrittweisem Rollout. Er lässt Agenten wiederkehrende App-Aufgaben erledigen, etwa Formulare befüllen, mit menschlicher Freigabe im Agent Feed. Mit Cloud Flows hat er nichts zu tun.

Und der Power-Automate-MCP-Server? Hier wird es interessant. Es gibt einen — aber er macht etwas anderes, als der Name vermuten lässt. Der Process-Mining-MCP-Server ist der MCP-Server unter dem Dach von Power Automate: ein vorgefertigter Power-Platform-Connector, in allen Regionen gelistet, in Preview und damit nicht für Produktivlasten freigegeben. Seine neun Tools heißen get_processes, get_bottleneck_analysis, get_variants_with_metrics und ähnlich. Er öffnet also Prozessanalytik für Agenten — nicht deine Cloud Flows.

Wenn dir irgendwo ein Datum oder ein Preview-Status begegnet: Prüf zuerst, auf welchen dieser Server sich die Quelle bezieht.

Der Stolperstein bei der Recherche

Ein Hinweis, der dir Zeit spart. Suchst du nach „Power Automate MCP Server”, landest du zu großen Teilen bei FlowStudio — einem Server eines Drittanbieters, der Flows anlegen, debuggen und dokumentieren kann. Das ist ein ordentliches Produkt, aber es ist nicht Microsoft, es hilft beim Bauen, und es fällt nicht unter dieselben Zusagen. Mehrere Blogbeiträge behandeln es, als wäre es ein Plattformfeature.

Prüf bei jeder Quelle drei Dinge: Wer betreibt den Server? Hilft er beim Bauen, oder ruft der Agent ihn im Betrieb? Und bezieht sich das genannte Datum überhaupt auf diesen Server?

Die Pointe steht in der Governance

Der Einwand, der an dieser Stelle immer kommt: Und was ist mit der Kontrolle?

Genau hier liegt der Vorteil gegenüber dem Skill im lokalen Repo. Ein Flow, der als Tool hängt, läuft weiter als Flow. Er benutzt dieselben Verbindungen unter einer kontrollierten Identität — mit allem, was daran hängt, siehe Connection References von Dev bis Prod —, er fällt unter dieselben DLP-Richtlinien, und er landet in derselben Lauf-Historie. Das ist keine Theorie: Der Lauf weiter oben steht genau dort, mit Eingaben, Dauer und Ergebnis jeder Aktion.

Ein lokaler Skill im Repo hat davon nichts. Er hat die Zugangsdaten, die der Entwickler ihm gegeben hat, und er hinterlässt die Spuren, die der Entwickler vorgesehen hat.

Eines muss man dazusagen: Eine Identität ist noch keine Berechtigung. Dass ein Agent eine eigene Entra-Identität hat, heißt nicht, dass darüber schon gesteuert wäre, was er darf — das steht ausführlich in Entra Agent ID. Was der Flow-als-Tool-Weg dir gibt, ist die Connector- und DLP-Ebene. Die ist viel wert, aber sie ist nicht alles.

Und eine zweite Einschränkung gehört zum MCP-Weg dazu: Der HTTP-Trigger macht den Flow über eine signierte URL erreichbar. Wer sie hat, kann den Flow starten. Sie gehört deshalb in einen Secret Store und nicht ins Repo — und wer sie weiter absichern will, setzt eine Authentifizierung davor, statt sich auf die Signatur zu verlassen.

Der ehrliche Stand

Was	Stand
Workflow als Tool für Agenten (GitHub-Copilot-Harness)	dokumentiert
MCP-Server als Tool in Copilot Studio	dokumentiert, Zertifizierung möglich
Bestehenden Cloud Flow als Workflow-Tool anhängen	nicht möglich — der Tool-Dialog schließt Cloud Flows ausdrücklich aus
Workflow in Copilot Studio anlegen und per Flow-API mit Logik füllen	funktioniert — Veröffentlichen ist Pflicht, vorher ist er für die API unsichtbar
Workflow ausführen und deterministisches Ergebnis erhalten	funktioniert — Lauf erfolgreich, Ergebnis in Dataverse geprüft
Agent in Copilot Studio anlegen	braucht einen Abrechnungsplan mit nutzungsbasierter Bezahlung; ohne ihn Abbruch mit irreführender Lizenzmeldung
Flow als Tool an einem Agenten, ohne Copilot Studio — eigener MCP-Server auf dem HTTP-Trigger	funktioniert — im Video oben, Ergebnis in Dataverse geprüft
Skills-Flow von außen per API mit Parametern starten	gesperrt (ListCallbackUrlOperationBlocked); über den Designer und über einen HTTP-Trigger dagegen möglich
Process-Mining-MCP-Server (Power Automate)	Preview, alle Regionen, nicht für Produktivlasten — Analytik, keine Flows
Power-Apps-MCP-Server	Public Preview seit 11.02.2026, zuerst US Early Release
Power-Automate-Plugin (CLI, hilft beim Bauen)	verfügbar, kein MCP-Server
MCP-Server, der deine Cloud Flows publiziert	von Microsoft so nicht belegt; Drittanbieter wie FlowStudio besetzen die Lücke

Wenn du das ausprobierst: Prüf die Verfügbarkeit live in deinem Tenant, nicht in der Doku. Preview-Features rollen regional gestaffelt aus, und die Doku läuft dem Tenant regelmäßig voraus oder hinterher.

Was du jetzt tun kannst

1. Such dir einen bestehenden Flow, der eine klar umrissene Aufgabe erledigt und deterministisch ist. Je schlanker, desto besser.
2. Schreib seine Beschreibung neu — nach den drei Punkten oben. Das ist die eigentliche Arbeit.
3. Entscheide dich für eine Tür. Copilot Studio: Workflow mit dem Agenten-Trigger anlegen, veröffentlichen, Definition per API hineinspielen — und einen Abrechnungsplan einrichten. Ohne Copilot Studio: eine Kopie des Flows mit HTTP-Trigger und ein MCP-Server davor.
4. Lass ihn einmal laufen und sieh dir an, was zurückkommt. Wenn dort eine Zahl steht statt einer Formulierung, hast du ein Werkzeug gebaut.
5. Häng ihn als Tool an deinen Agenten und stell ihm eine Frage, ohne den Flow zu erwähnen. Ruft er ihn? Wenn nicht, liegt es an der Beschreibung, nicht am Agenten.

Der Punkt ist nicht, dass MCP neu ist. Der Punkt ist, dass die Logik, die dein Agent braucht, bei dir längst herumliegt — abgesichert, getestet, im Betrieb. Sie gehört nicht ins Repo kopiert. Sie gehört freigeschaltet. Drei Tage Urlaub, neun Tage Rest: Das hat kein Modell ausgerechnet, das hat dein Flow geliefert.