Agent flows are now a first class execution target inside Copilot Studio (GA on the standard harness as of 2026-08-28). They look like flows, they can be wired into an agent as tools, and they run under different quotas and ownership rules than Power Automate cloud flows. Choosing the wrong one early bakes in billing and governance you may not want.

The argument here is simple: for agent flows vs cloud flows, use agent flows only when the logic must stay inside the conversation and you accept Copilot Studio capacity and limited sharing. Otherwise keep the logic in cloud flows for co ownership, DLP driven governance and desktop automation. Cost and control decide more than performance does.

Contents

What an agent flow actually is (and how it plugs into an agent)

Agent flows are created and managed inside Copilot Studio’s standard harness. They have a trigger and at least one action. One trigger is specific to agents: When an agent calls the flow. This makes the flow available as a tool on the agent so the planner can invoke it during a conversation.

The tool surface is explicit. You add the agent flow as a tool and pick authentication mode: end user or maker provided. That choice affects what the flow can see and do at runtime because the effective identity differs. End user authenticates as the caller. Maker provided authenticates as the connection owner. Pick the one that matches your data access model.

A minimal, reproducible setup looks like this.

  • Create a solution in the target Dataverse environment.
  • In Copilot Studio, create a flow using the trigger When an agent calls the flow.
  • Build actions, define inputs and outputs, then save.
  • Open the agent, go to Tools, choose Add tool, and select the agent flow.
  • Choose authentication mode, map inputs and outputs, and publish.

Agent flows can also run on a schedule or on events, but their distinctive use is inside the conversation loop. This stays inside the agent.

Environment boundaries apply to everything here. Copilot Studio capacity and quotas are scoped per Dataverse environment, and resources don’t cross environments. Quotas are GA on the standard harness as of 2026-08-28 (8,000 requests per minute for messages to an agent per environment), with separate rates for generative orchestration and actions based on prepaid packs or PAYG. Those limits sit alongside Power Automate request accounting when an agent triggers a cloud flow.

This is not the same product surface as a Power Automate cloud flow. The trigger model is different, the tool integration is first class, and Copilot Studio enforces quotas and capacity rather than per user or per flow entitlements.

Billing and licensing decide more than you think

Every action an agent flow executes consumes Copilot Studio capacity under the standard harness. Enforcement is strict. When an environment’s prepaid capacity is fully consumed, new agent flow runs are blocked until capacity is available again. Test runs from the flow designer or the agent Test chat don’t consume capacity. There is a documented exemption for Microsoft 365 Copilot licensed users when the invocation uses the When an agent calls the flow trigger.

Cloud flows are billed and throttled differently. Paid Premium users receive 40,000 Power Platform requests per 24 hours, with enforcement windows at five minutes and 24 hours. Per flow and Process plans grant 250,000 requests per 24 hours to the flow itself. When a Copilot Studio agent triggers a cloud flow, those requests count against the relevant Power Automate plan. Desktop flow executions are a separate surface that don’t consume Power Platform requests, though they still require RPA licensing and machine capacity.

Conversion changes how runs are charged. Converting a solution aware cloud flow into an agent flow switches it to Copilot Studio capacity and the operation is one way. There is no revert. That lock in matters more than any micro benchmark because it decides which meter runs for the lifetime of the automation.

License posture for makers also differs. Copilot Studio requires per user maker licensing and a tenant license that brings pooled capacity, which is then allocated per environment. End users of published agents don’t need a special license. Power Automate licensing attaches to makers and flows in the familiar way. These are separate meters.

A quick cost model helps avoid mistakes. Use variables and capacity reports rather than guesses.

inputs:
  agent_flow_actions_per_run: integer
  agent_flow_runs_per_day: integer
  exempt_invocation_share: 0.0 to 1.0  # share of runs by Microsoft 365 Copilot licensed users using the agent trigger
  copilot_credit_per_action: decimal    # from current licensing guide
  cloud_flow_actions_per_run: integer
  cloud_flow_runs_per_day: integer
  request_cost: decimal                 # if using per flow Process plan via PAYG

compute:
  agent_capacity_needed_per_day = agent_flow_actions_per_run * agent_flow_runs_per_day * (1 - exempt_invocation_share)
  agent_credits_per_day = agent_capacity_needed_per_day * copilot_credit_per_action
  cloud_requests_per_day = cloud_flow_actions_per_run * cloud_flow_runs_per_day
  check_limits = cloud_requests_per_day within 24 hour and 5 minute windows

Two operational implications follow. First, by choosing agent flows you move usage to a pooled Copilot Studio meter with environment allocation and hard enforcement. Second, by choosing cloud flows you stay on per user or per flow meters with run history, owner controls and predictable throttling semantics across products. The wrong choice shows up later as either unexpected blocking in chat or unexpected request throttling during peak usage.

Note: Capacity is pooled at tenant level and allocated per environment. Manage it in the Power Platform admin center under Licensing, then Copilot Studio. Use the official estimator to forecast before you convert.

Sharing, ownership and runtime permissions diverge sharply

Agent flow sharing is constrained. There is no co owner model, no run only access, and no send a copy. Sharing an agent doesn’t share the cloud flows it calls. Users without access may still exercise actions through the Test panel during authoring, which can mask missing permissions until publish time.

Cloud flows support team ownership. Add owners, grant run only users for instant triggers, or send a copy. Owners can view run history and manage properties and connections. This is the standard Power Automate model and it scales for support handover, audits and break glass.

Governance applies in different planes. Copilot Studio enforces data policy controls in real time across actions, connectors, skills and channels. Since early 2025, enforcement is on for all tenants and exemptions are not supported. Power Platform DLP classifies connectors as Business, Non Business or Blocked, and scopes policies at tenant or environment levels. These planes meet if an agent uses a cloud flow and the flow’s connector mix violates policy.

Sensitivity labels are starting to surface in Copilot Studio for supported knowledge sources. The highest label applied to content used in a response is shown, with per citation labels. This feature is in preview as of 2026-08-28, and coverage is limited. Treat it as a signal, not an access control.

If your agent uses generative orchestration and dynamic tool selection, align tool exposure with your DLP and sharing stance. For a deeper look at orchestration choices, see Copilot Studio orchestration: generative vs classic on this site.

Check runtime identity explicitly. The end user vs maker provided choice on the tool determines access. Test with a non owner identity before you publish.

Desktop automation forces a cloud-hop today (and brings its own limits)

As of 2026-08-28, an agent flow can’t call a desktop flow directly. Plan the hop. The supported pattern is agent to cloud flow to desktop flow.

Triggering a desktop flow from a cloud flow requires the correct license on the connection and a machine that’s registered to the environment. Unattended runs require Process capacity. Each machine can run desktop flows from the cloud in one environment at a time. The maximum queue time is 12 hours. Desktop flow executions don’t consume Power Platform requests, but the cloud flow that orchestrates them does.

  • Agent receives a user utterance and selects the tool.
  • Agent calls an agent flow via the agent trigger.
  • Agent flow invokes a cloud flow, passing inputs.
  • Cloud flow triggers a desktop flow on a machine, then returns a status.
  • Agent flow maps the result back into the conversation.

Important: Gateways for desktop flows are deprecated in favor of direct connectivity. Plan machines and environments accordingly, and remember a machine is tied to one environment at a time.

Set up the cloud to desktop handoff methodically.

  • Register machines or machine groups in the target environment and verify health.
  • Create a desktop flow connection in the cloud flow and confirm the right license is on the connection owner.
  • Run a small attended test first, then switch to unattended with Process capacity if needed.
  • Monitor queue time and concurrency, and keep an eye on the 12 hour maximum queue window.

Roadmap text for the current release wave mentions enabling agents to call desktop flows directly from Copilot Studio. That is forward looking. Validate availability in your tenant before assuming it exists, because the current FAQ still states that direct calls aren’t supported.

If you’re integrating with Business Central over MCP in the same agent, see Configure Business Central MCP Server for Copilot Studio for harness and cost guidance.

Decision matrix: pick agent flows vs cloud flows

The choice is reproducible if it’s framed in requirements rather than tooling preferences. Start with the coupling to the conversation and the governance you need, then apply desktop automation needs. Do not mix patterns.

Requirement or constraint Choose agent flow Choose cloud flow
Logic must run inside the agent loop and benefit from planner tool selection Yes No
Need co ownership, run only access, or a supportable team flow model No Yes
Must orchestrate desktop automation on attended or unattended machines No Yes
Comfortable paying with Copilot Studio capacity and managing environment allocations Yes No
Strong DLP posture centered on connector classification and Power Automate policy scopes Maybe Yes
Tenant uses Microsoft 365 Copilot widely and can exploit the agent trigger exemption Yes Maybe

Turn the table into a checklist you can keep in a solution readme.

decision_rules:
  - if: logic_is_conversation_coupled
    then: agent_flow
  - if: requires_co_ownership or needs_run_only
    then: cloud_flow
  - if: needs_desktop_automation
    then: cloud_flow
  - if: dlp_policy_is_connector_centric
    then: cloud_flow
  - if: cost_model_fits_copilot_capacity and exempt_share_is_high
    then: agent_flow
fallback:
  keep_cloud_flow_in_solution: true
  do_not_convert_production_flow: true

Two final checks before committing the pattern help in practice. First, map every connector call to a DLP policy and channel rule, then verify both the Copilot Studio plane and the Power Automate plane pass. Second, model capacity and requests against a real forecast, including the five minute window for request bursts.

What to watch carefully

  • Billing enforcement and irreversibility. Agent flow capacity enforcement is hard. When prepaid capacity is exhausted, new runs are blocked, and conversion from cloud to agent flow is one way.
  • DLP and policy misalignment. Copilot Studio enforces data policy in real time and will block publication. Power Platform DLP may also block a flow or break it after a connector change. Model both.
  • Permission mismatches. Sharing an agent doesn’t share underlying cloud flows. The Test panel can mask gaps. Validate with a non owner identity before you publish.
  • Environment boundaries. Agents, flows, connections and machines are environment scoped, with capacity and quotas per environment. Cross environment calls aren’t supported.
  • Request limits and burst behavior. Cloud flow requests count against per user or per flow limits with five minute and 24 hour windows. Desktop flow executions avoid request counts but still queue and time out.
  • Instrumentation discipline. Use the Power Platform admin center to monitor Copilot Studio credits and environment allocation, and the request usage reports for Power Automate. Set PAYG caps where available to bound spend.
  • Fallback hygiene. If you choose agent flows, retain a functionally equivalent cloud flow in the solution until your usage data shows the capacity profile is stable.

[[AUTHOR: exact error text and where it surfaced when the agent called an unshared cloud flow]]

Scope for this guide is the standard harness in public cloud as of 2026-08-28. Validate behavior in sovereign clouds and with custom connectors before adopting at scale.

My take

Default to cloud flows for anything that needs co ownership, DLP centered on connectors, or desktop automation. The ownership model, run only access and request accounting are all mature and predictable. Support teams can work from run history and handovers are straightforward.

Reach for an agent flow when the tool must sit inside the conversation loop and the logic is better expressed as a tool than as an external workflow. Budget capacity explicitly, allocate it per environment, and keep a clear line of sight from agent actions to capacity usage. Publish narrowly at first.

A practical rollout sequence helps. Keep the existing cloud flow and expose it to the agent as a tool while you build the agent flow in the same solution. Model capacity using the estimator and PPAC reports, and set a hard stop if projected usage exceeds the environment allocation. Gate promotion on two checks: a DLP pass in both planes and a permission test with a non owner identity. Only convert a cloud flow after a change advisory agrees the Copilot Studio meter is the right one, because conversion is one way.

There are counter cases where an agent flow is the better choice from day one. If the logic must use the end user’s identity, is tightly coupled to the conversation plan, and the audience has a high share of Microsoft 365 Copilot licenses, the exemption plus the tool integration can make capacity both predictable and affordable. In that case, keep the tool surface small, publish to a narrow audience, and monitor capacity daily for the first week. If desktop automation appears on the roadmap for the scenario, hold conversion and orchestrate through a cloud flow until direct desktop calls are confirmed in your tenant.

Roll out in stages. Pilot in a non production environment, keep a cloud fallback in the same solution, and set explicit stop conditions tied to capacity and request usage. The meter you pick matters more than the trigger you prefer.

Sources

Categorizado en:

Copilot Studio,

Etiquetado en:

, , , , ,