Agent flow vs cloud flow

What it does

Decides where a piece of automation should live: in Power Automate as a cloud flow on Power Automate licensing, or in Copilot Studio as an agent flow that an agent's orchestrator can call and that bills against Copilot Studio capacity. The flow logic looks nearly identical either way. Ownership, billing and who decides when it runs do not.

Key facts

Agent flows are deterministic. Same inputs, same path, same output. The reasoning about whether and when to run sits in the agent; the flow only knows how.
Agent flows consume Copilot Studio capacity per action executed. When an environment's prepaid capacity runs out, new agent flow runs are blocked until capacity frees up or pay-as-you-go is enabled. With pay-as-you-go, overage bills to the Azure subscription instead of blocking.
Testing an agent flow from the flow designer or the agent's test chat doesn't consume Copilot Studio capacity. Everything looks free right up until go-live.
Cloud flows bill against Power Platform request allocations from the owning user's licence, or from a Process licence allocated to the flow.
You can convert an existing cloud flow to an agent flow by switching its plan to Copilot Studio. The flow has to be in a solution and in an environment with Copilot Studio capacity, and the conversion can't be reversed.
An agent flow can be exposed at agent level, where the orchestrator may call it at any time, or scoped to a single topic.
Both flow types can call the same connectors, control actions and child flows. Agent flows additionally expose AI capability actions and human-in-the-loop actions such as approvals.

When to use / skip

Ask who decides that this runs. If the answer is a trigger — a record was created, a file landed, it's Monday — build a cloud flow and leave it on Power Automate licensing. If the answer is "an agent decides, based on what a user asked for", build an agent flow. That's the whole test, and it's more reliable than any feature comparison because it maps to where the non-determinism sits.

The mistake worth pre-empting is putting judgement inside the flow. If you find yourself writing conditions that try to interpret user intent, you're building a bad agent inside a good automation engine. Push the interpretation up into the agent and keep the flow boring. The opposite mistake is letting the agent handle steps that must be exact — money, records of account, anything auditable. Those belong in the flow where the same input always produces the same result and you can point at the run history afterwards.

Configuration decisions

Where does the reasoning live? Agent chooses, flow executes. If a flow is making judgement calls, redesign the boundary before you argue about licensing.
Prepaid Copilot Studio capacity, pay-as-you-go, or both — and who watches the meter. Blocking and overage are both defensible; being surprised by either isn't.
Agent-level or topic-level exposure. Agent level is more useful and gives the orchestrator more chances to pick the wrong tool.
Which existing flows genuinely need converting. Conversion is one-way, so clone first if there's any doubt.
Whether high-volume background automation should stay on Power Automate billing even though an agent occasionally touches it. Often it should, with a thin agent flow wrapper.
The fallback when capacity blocks a run: surface it to the user, queue it, or fail over to a scheduled cloud flow.

Gotchas

The cost model changes silently on conversion. A flow that ran thousands of times a day under a Process licence lands on Copilot Studio capacity and nobody re-ran the numbers.
Capacity exhaustion looks like nothing from the maker's seat. The flow isn't broken and doesn't error visibly; it just doesn't start. Monitor agent flow action counts in the admin centre.
Free test runs make build-phase estimates worthless. The real consumption profile only appears once an orchestrator is choosing when to call.
Large multi-purpose flows are hard for an orchestrator to select correctly. A wrong selection on a big flow costs more than a wrong selection on a small one.
Descriptions matter far more than in a cloud flow. The orchestrator picks tools partly on their descriptions, so a vague name and no description is an availability problem, not a documentation one.

Consultant notes

Say early and clearly that agent flows don't reason. Clients hear "agent" and assume intelligence inside the flow; the value is precisely that there isn't any.
Do the capacity arithmetic in the design workshop — actions per run times expected runs per day. It's a five-minute calculation that prevents a very awkward conversation after UAT.
Resist wholesale conversion of an existing estate. Convert what the agent actually calls and leave the rest where it is.
Keep a written boundary in the solution design: what the agent is allowed to decide, and what must be deterministic. That document is what you'll reach for the first time an agent does something unexpected.

Recheck before any agent goes into production, and again the next time Copilot Studio capacity rules move