AI Agent Built My Power Automate Flow: 80 Actions Down to 17

Sharing my experience from the past two days using an AI Agent + MCP to build a Power Automate flow for a client.

The client's request

The client needed document processing automation. When someone uploads a Word report to a SharePoint list, Power Automate converts it to PDF, saves it to the right document library, sends a Teams message, and sends an email. Different document types go to different locations and different channels.

They already had a working flow for 3 document types, using Switch blocks to route each type. I needed to build a new one for another team, this time with 6 document types.

So I thought: why not just have the AI agent build it for me.

Letting the agent read the existing flow

I was using Claude (running inside VS Code), connected to the client's Power Automate environment through Flow Studio MCP. MCP lets the agent directly read flow definitions, deploy changes, trigger test runs, and check run history, all without opening Power Automate designer.

First step was having the agent read the existing flow:

agent → list_live_flows → find the existing flow
agent → get_live_flow → read the full flow definition

The agent immediately understood the structure: trigger is SharePoint list item created, Apply to Each loops through attachments, two Switch blocks inside route by document type. One handles PDF conversion and file storage, the other handles Teams messages and email.

Version 1: Copy and expand

The agent copied the existing logic and expanded from 3 types to 6. Six Switch cases, each with a full set of duplicated actions. Deployed it. 80+ actions.

It worked, technically. The old flow was built the same way. But maintaining it inside a Switch is painful. Fix one bug, fix it 6 times. Easy to miss one.

The old Switch flow looked like this:

3 cases expanded, each with a full set of duplicated actions: Compose, HTTP Graph, Send email, Post Teams message. The new version would need 6 cases. Fix one bug, fix it 6 times.

Version 2: Dictionary lookup

Then I gave the agent a blog post by my husband John Liu about the split twice pattern, a technique for using config to replace Switch blocks.

The agent read it and suggested a dictionary lookup approach:

1. One Compose action holds a JSON config. 6 document types as keys, with values for library ID, Teams channel ID, and mailing list field name.
2. All downstream actions use outputs('Compose_Config')?[triggerBody()?['Type/Value']] to look up the right values.
3. Both Switch blocks, gone.

80+ actions down to 17.

Left side is the Compose Config JSON: 6 document types as keys, each with its library ID, channel ID, and mailing list field. Right side is a clean Apply to Each with one shared set of actions for all document types. Adding a new type means adding one JSON key.

Deploying is where the real debugging starts

The new version deployed and ran for the first time. It broke.

SharePoint connectors have quirks that aren't well documented. Path formats don't work the way you'd expect. A stray single quote in a composed JSON string breaks everything. Field update logic can overwrite itself if sequencing is off.

Each time it was the same loop:

agent → update_live_flow (deploy changes)
agent → trigger_live_flow (run it)
agent → get_live_flow_runs (check run history)
agent → get_live_flow_run_error (find which action failed)
agent → get_live_flow_run_action_outputs (inspect input/output to confirm the issue)
→ fix → redeploy

About 7 rounds. Also cancelled 11 broken runs along the way.

The key point: I never opened Power Automate designer during any of those 7 rounds.

The agent deployed, ran, found errors, and fixed them on its own. I just watched and occasionally pointed it in the right direction (like sharing John's blog post).

Why MCP makes the difference

Without MCP, the agent can still deploy flows. But when things break, it can't see the run history details, the per-action errors, or the actual input/output values. You have to open Power Automate designer yourself, read the error, and forward it back to the agent. You become the human middleware in the loop.

With MCP, the agent can directly:

• Read existing flows (get_live_flow)
• Deploy changes (update_live_flow)
• Trigger test runs (trigger_live_flow)
• Check run history and action-level errors (get_live_flow_runs, get_live_flow_run_error)
• Inspect each action's input/output (get_live_flow_run_action_outputs)

The difference is whether the agent can run the full deploy → test → debug loop on its own. If it can, you're done in an afternoon. If it can't, you're the middleware.

Want to try it? Flow Studio MCP free plan includes 100 API calls, no credit card required.

Works with Copilot, Claude, and any MCP-compatible agent.

John's split twice pattern: johnliu.net

Catherine Han, Flow Studio