Type one sentence into Claude Code or GitHub Copilot CLI: build a flow that posts a Teams message when a SharePoint item is created.
What comes back is a real cloud flow in your Power Automate environment, with the trigger and the action already wired. Not a code snippet you still have to paste into the designer. No portal, no drag and drop canvas, no manually connecting the SharePoint trigger to the Teams action by hand.
That is FlowAgent, the MCP server behind the power-automate plugin in Microsoft's open source power-platform-skills repository. This is not a wrapper that asks a language model to guess what Power Automate YAML might look like. It is a Model Context Protocol server with authenticated API access to the Power Platform environments available to the signed-in Azure identity, so every flow, run, and connection it touches is real.
Why This Is Not Just Another AI Coding Assistant Prompt
Ask a general purpose coding assistant to write a Power Automate flow and it will produce something plausible from training data. It cannot see your environments, cannot read the actual failure reason from a run that failed last night, and cannot publish anything, because it has no connection to your tenant at all.
FlowAgent closes that gap by giving the assistant real tools that call the Power Automate and Dataverse APIs directly, authenticated through your own Azure login. When it edits a flow, it is editing the flow. When it diagnoses a failed run, it is reading the actual run history, action by action.
This distinction between an assistant that talks about Power Automate and one that operates on it is the same shift covered in a broader look at building and governing Copilot agents at scale, where the value comes from an agent actually holding tool access, not just holding an opinion.
The Architecture in Short
The Engine
FlowAgent ships as a single self-contained ESM bundle at server/mcp.mjs, generated from a TypeScript source in a separate monorepo and packaged into the plugin. That one file carries the stdio transport, all 50+ tools, and every dependency inlined.
There is no npm install, no Docker container, and no remote host to stand up. The only runtime requirement is Node.js 18 or later.
Authentication
Authentication runs through your local az login session, plus MSAL for the connectivity endpoints Power Automate uses under the hood. There is no separate installer for a service account or app registration built into the plugin itself.
Whatever identity is already signed in through Azure CLI is the identity FlowAgent operates as. That same reliance on real, authenticated tooling rather than a sandboxed preview is also what the Microsoft 365 Agents Toolkit covers for agent development more broadly across Microsoft 365.
Installing FlowAgent
FlowAgent installs as a plugin inside a Claude Code or GitHub Copilot CLI session, through the same plugin marketplace mechanism used by the rest of the power-platform-skills repository.
Manual Install
/plugin marketplace add microsoft/power-platform-skills
/plugin install power-automate@power-platform-skills
Both commands run from inside an active session, not from a plain shell. This is the more targeted option if you only want the Power Automate plugin.
Quick Install
The repository also ships a one line installer for setting up the whole toolkit at once: iwr ... | node install.js on Windows, or curl -fsSL ... | node on Mac, Linux, or cmd.
That script detects whether you have Claude Code or GitHub Copilot CLI, installs the Power Platform CLI (pac) if it is not already present, registers the marketplace, and installs every plugin in the repository with auto update enabled, not just power-automate.
The plugin marketplace here is the same one covered when looking at Skills for Copilot Studio and the GitHub Copilot SDK, worth a look if your team is standardising on plugin based tooling across both assistants rather than picking one per project.
The plugin and its engine are open source, and the full source sits in the power-platform-skills repository on GitHub, which is also where issues and version history live.
What FlowAgent Can Actually Do
The official capability list breaks into five groups.
| Area | What it covers |
| Flows | List, get, create, edit with surgical action level changes, copy within or across environments, update, publish or disable, delete |
| Runs | History, run details, per action detail, loop iteration drill down, cancel, cancel all, resubmit, diagnose |
| Connections | Full lifecycle including create, share, and fix, plus auto discovery and dynamic value resolution |
| Authoring | Templates and scaffolding, batch deploy, preflight validation, expression help |
| Desktop and environments | Desktop (RPA) flow operations, environment routing |
The edit capability is worth pausing on. It is scoped to individual actions inside a flow's definition rather than requiring a full rebuild, a meaningfully different operation than regenerating a flow from scratch every time a requirement changes.
The Nine Skills
Underneath those capabilities, the plugin exposes nine guided skills that map to how a developer actually works through a flow, from first setup to production debugging.
| Skill | Purpose |
| setup | First time prerequisite checks |
| browse-flows | Explore environments and flows interactively |
| create-flow | Guided, step by step flow creation |
| build-flow | Generate a complete flow autonomously from a natural language description |
| debug-flow | Interactive debugging session against a failed run |
| diagnose-flow | Autonomous deep diagnosis of a failed run, no back and forth required |
| manage-flows | Publish, test, batch operate, and inventory flows across an environment |
| manage-desktop-flows | List and run desktop (RPA) flows |
| route-environments | Resolve which environment a command should target |
build-flow and debug-flow cover opposite ends of the same job: one turns a plain sentence into a flow definition, the other turns a failed run into an explanation of what broke.
In practice, most developers will spend most of their time in build‑flow, debug‑flow, and diagnose‑flow, with the other skills used for setup, inventory, and environment management.
A Practical Example
Building a Flow
A build request looks like this from inside a Claude Code or GitHub Copilot CLI session.
|Build a flow that sends a Teams message when a SharePoint item is created.|
This maps to the build-flow skill, backed by the authoring capabilities (templates and scaffolding, preflight validation) and the environment routing skill that resolves which tenant and environment the flow should target.
Because FlowAgent operates on the same flow definition the Power Automate designer reads and writes, the result is expected to open and edit normally in the portal, the same as anything built by hand.
Diagnosing a Failed Run
The same pattern applies in reverse for a run that already failed. An illustrative request might look like this.
|A flow failed last night. Find out why.|
That request maps to diagnose-flow, documented as autonomous deep diagnosis of a failed run. It draws on the run history, per action detail, and loop iteration drill down capabilities, rather than requiring you to manually step through the run history yourself.
For how a flow's own instructions should be phrased so the agent parses intent correctly, the same prompting and instruction techniques used for Copilot agents apply just as directly to how you phrase a build-flow request.
Where This Needs Governance, Not Just Adoption
Two things about FlowAgent deserve attention from whoever owns Power Platform governance, not just from the developer running it.
Identity and Permissions
Authentication runs on az login, and the documentation does not describe a separate, scoped down identity for the agent itself. In practice, that means FlowAgent operates with whatever permissions the signed-in identity already has in that tenant.
Anyone rolling this out should evaluate it with that in mind, closer to handing a developer direct API access than to installing a limited purpose app. The official Azure CLI login documentation is worth reviewing alongside this, particularly around service principal-based sign in for anything running unattended.
Environment Promotion
The copy capability moves flows within or across environments, including from development into production, on request, through the CLI. The official capability list does not describe an approval gate as part of that operation.
Whether one exists depends on how the environment itself is configured, not on FlowAgent. This is the same territory covered in a broader look at Power Automate governance risks.
Treat any FlowAgent generated or copied flow the way you would treat a pull request: reviewed before it reaches production, especially for flows touching finance, HR, or customer data. The same logic already applies to how organisations are wiring custom built agents into enterprise identity and control frameworks, and Power Automate flows built through an agent are not an exception.
Where to Go From Here
FlowAgent is early, open source, and moving quickly, which is exactly why the identity and environment promotion questions above deserve a real answer before it touches a production tenant.
If your team is weighing how a tool like this fits into an existing Power Platform governance model, that is a rollout question worth working through with a partner who has already been through it.
Work with Precio Fishbone Talk to our team about what a Power Automate or Power Platform AI rollout would look like in your environment.
Talk to our consultants
Frequently Asked Questions
Does FlowAgent require the Power Platform CLI (pac)?
Not directly. The power-automate plugin's own stack is listed as Node.js 18+, Azure CLI, and the self contained MCP bundle, with no mention of pac. The Quick Install script does install pac, but that is because other plugins in the repository depend on it, not FlowAgent itself.
Can FlowAgent run without an internet connection to a Microsoft hosted service?
The MCP engine itself is fully self contained and needs no remote host to start, but flow operations still require live calls to your Power Automate environment, so a working connection to your tenant is necessary for anything beyond local setup.
Does FlowAgent work with both Claude Code and GitHub Copilot CLI?
Yes. Both are supported through the same plugin, installed with the same two marketplace commands.
What happens to a flow FlowAgent generates? Does it look different from a normal flow?
It should not. FlowAgent writes to the same flow definition format the Power Automate designer reads, so a generated flow is expected to open, edit, and display normally in the portal.
Is desktop flow (RPA) support the same as cloud flow support?
Not entirely. Desktop flows are covered through manage-desktop-flows for listing and running them, narrower than the full create, edit, and diagnose set available for cloud flows.
Share this on
Pär Johansson
Pär works with international business at Precio Fishbone, project delivery & digital services, helping turn complexity into progress and strategy into long-term value. With many years of experience in international business, He is known for building strong relationships and turning plans into meaningful progress. Driven by people, trust and sustainable growth.