Copilot Studio integration

What it does

Flows and agents call each other in both directions. A flow can be added to a Copilot Studio agent as a tool, so the agent's orchestrator invokes it at runtime to fetch data or take an action; and a flow can call an agent through an AI action, so a deterministic process can hand a step to something that reasons.

Key facts

To be usable as a tool, a flow needs the When an agent calls the flow trigger and a Respond to the agent action, and it must be published. Older flows use the Run a flow from Copilot trigger and Respond to Copilot action names.
Asynchronous response must be off, under Networking in the Respond action's settings. An async flow can't be a tool.
The flow has to respond inside the 100-second action limit. Anything slower goes after the Respond action, where it keeps running against the normal 30-day flow run duration limit while the agent gets its answer immediately.
Express mode (preview as at July 2026) exists to speed up agent flow execution where the 100-second window is tight.
Tools attach at two levels. Agent-level means the orchestrator can pick the flow at any point in a conversation; topic-level scopes it to a single topic.
The tool description is what the orchestrator reads to decide whether to call your flow. It's a functional configuration item, not documentation.
Agent flows bill against Copilot Studio capacity per action executed. Cloud flows called from an agent bill under Power Automate.

When to use / skip

Put the boundary where determinism matters. The agent should own intent, conversation and judgement; the flow should own anything that writes to a system of record, touches money, or has to happen exactly the same way every time. Skip building an agent front end at all if the process has no genuine ambiguity in it — a form and a flow is cheaper, faster and easier to support than an orchestrator that has to be talked into doing the right thing.

Configuration decisions

Where the boundary sits between reasoning and execution, agreed before build rather than discovered during testing.
Agent-level or topic-level tool registration for each flow.
Which identity the flow's connections run as. Connection references and the run-as context decide what the flow can reach, and that's your real permission boundary — the agent's own permissions don't constrain what a flow it calls can do.
Whether long-running work sits before or after the Respond action.
How you'll return failures to the agent so it says something sensible rather than falling over.

Gotchas

A flow that doesn't meet the criteria simply won't appear in the tool list. There's no error explaining why — check the trigger, the Respond action, the async toggle and whether it's published, in that order.
The 100-second limit is on the response, not the run. People restructure whole flows before spotting they can just move the slow part after Respond.
A vague tool description gets a flow called at the wrong moments. Treat the description as the interface contract with the orchestrator and write it deliberately.
Connections are the security hole nobody reviews. An agent available to the whole organisation calling a flow that runs as a privileged service account gives every user that account's reach.
Agent flows and Power Automate flows bill differently, and a solution that mixes both has two capacity stories to monitor.

Consultant notes

Get the client to name the systems of record that agents must never write to directly. That list defines your flow layer.
The connection identity question is the one that gets raised in security review. Have an answer ready with a diagram.
Recommend one flow per discrete action. Composite flows that do five things confuse the orchestrator and are miserable to debug when it picks wrong.
Copilot Studio and Power Automate are converging fast. Anything you write down about which portal owns what has a short shelf life — design for the boundary, not the UI.

Recheck when Workflows leaves preview or agent flow trigger and action names change again