Agent Flows Explained: What Changed in Power Automate and Why It Matters

Scenario: From Classic Automations to an AI Agent

Imagine an internal support team:

• They use Dataverse for case management.
• They have classic cloud flows that:
  • Create and route cases from email.
  • Update SLA timestamps and status fields.
  • Notify owners in Teams when a case breaches SLA.
• Now leadership wants a Copilot-style agent that:
  • Answers common questions in Teams chat.
  • Can take actions (create/update cases) when asked.

The team quickly hits a wall:

• Copilot Studio talks about agents and skills, not triggers and actions.
• They see agent flows in Power Automate, but they don’t behave like their existing flows.
• They’re unsure how data moves between the agent and the flows, and what they can reuse safely.

This is exactly the gap agent flows are meant to fill: connecting conversational agents to structured automation in a predictable way.

What Agent Flows Are (and Are Not)

Plain-language definition

An agent flow is a Power Automate cloud flow that is:

• Invoked by a Copilot Studio agent via a dedicated trigger.
• Designed to run as a skill: it takes input parameters from the agent and returns structured output.
• Optimised for short, deterministic actions, not long-running orchestration.

In other words, it’s a standard Power Automate flow with a specific trigger and data contract so the agent can call it reliably.

Key differences from classic flows

Compared to the flows you already know:

• Trigger model

  • Classic flows start from connectors (e.g. “When an item is created” in SharePoint, “When an HTTP request is received”).
  • Agent flows start from an agent skill trigger exposed through Copilot Studio.

• Caller

  • Classic flows are triggered by systems or users.
  • Agent flows are triggered by the agent runtime in response to a user’s natural-language request.

• Inputs/outputs

  • Classic flows often read from the trigger body and don’t always return a response.
  • Agent flows receive explicit parameters from the agent and must return structured output that the agent can use in its reply.

• Usage context

  • Classic flows are general-purpose automation.
  • Agent flows are skills in an agent’s toolbox—each flow represents a single capability the agent can call.

Under the hood, they still use the same Power Automate engine and connectors. The change is mainly how they’re surfaced and how they interact with Copilot Studio.

How Agent Flows Plug Into Copilot Studio

Agent flows are part of the integration between Power Automate and Copilot Studio (the evolution of Power Virtual Agents and related capabilities). The basic pattern is:

1. You define an agent in Copilot Studio (for example, a “Support assistant”).
2. You add skills to that agent.
3. Some skills are agent flows—Power Automate flows that the agent can call.

The agent skill trigger

The core technical piece is the agent skill trigger (naming and UI can vary slightly depending on environment and region, but the behaviour is consistent):

• You create a new cloud flow and choose the trigger that corresponds to being called by an agent (listed under Copilot Studio/agent integration in current tenants).
• This trigger exposes input parameters that the agent will pass in.
• The flow returns outputs that the agent receives and can surface in the conversation.

At a high level:

• The agent runtime decides when to call the flow based on the user’s request and the skill definition.
• The flow executes with the connection references you configured (not the end user’s identity, unless you explicitly build that pattern with delegated auth or custom logic).
• The agent gets the flow’s response and incorporates it into its answer.

Data flow in our scenario

Back to the support team:

• The agent recognises “Create a high-priority case for customer X” as a request needing action.
• It calls an agent flow skill CreateSupportCase with parameters like:
  • customerName
  • issueSummary
  • priority
• The agent flow:
  • Creates a case in Dataverse.
  • Returns caseId and caseUrl to the agent.
• The agent responds in Teams with:
  • “I’ve created case 12345 for customer X. You can view it here: …”

The classic Dataverse create/update logic is still in Power Automate. The difference is that the agent now orchestrates when that logic runs.

Designing Agent Flows vs Classic Flows

You can reuse a lot of your classic patterns, but you need to design for:

• Explicit inputs and outputs.
• Agent-friendly error handling.
• Short, focused actions.

1. Inputs: make parameters explicit and stable

Agent flows work best when their inputs are:

• Named parameters that match the agent’s skill definition.
• Stable over time (changing parameter shape requires updating the skill mapping).

Practical tips:

• Avoid overloading a single flow with many optional parameters for different use cases. Instead, create separate flows/skills for:
  • "Create case"
  • "Update case status"
  • "Get case summary"
• Use simple types where possible:
  • Text
  • Numbers
  • Booleans
  • Structured objects only when the agent really needs them.

2. Outputs: think like an API, not a UI

The agent doesn’t see your flow’s UI; it only sees the output object.

Best practice for outputs:

• Return structured data, not formatted text.
• Include both:
  • Data fields the agent can reason about (IDs, status codes).
  • Human-readable text the agent can surface directly if needed.

Example pattern for our support scenario (conceptually, not code):

• Output object:
  • caseId: "12345"
  • caseUrl: "https://..."
  • status: "Created"
  • userMessage: "I’ve created case 12345 and assigned it to the Support queue."

The agent can:

• Use caseId and status to decide on follow-up actions.
• Use userMessage directly in the conversational reply if appropriate.

3. Error handling: fail loud, not silently

Classic flows often log errors or send an email and move on. For an agent flow, this leads to confusing conversations.

For agent flows:

• Surface errors in the output so the agent can explain what happened.
• Avoid silent failures or partial success without clear status.

A simple approach:

• Always output:
  • success: true/false
  • errorCode: text (empty when success is true)
  • errorMessage: text (empty when success is true)

Then define in Copilot Studio how the agent should respond when success is false.

4. Scope and duration: keep agent flows tight

Agent flows are better suited to:

• Short-running actions.
• Single-responsibility tasks.

Keep long-running orchestration in classic flows triggered by:

• Dataverse events.
• Scheduled triggers.
• HTTP/webhook triggers.

You can still start those classic flows from an agent flow if needed (for example, by writing a record that a separate flow listens to), but don’t try to cram a full multi-hour process into a single agent skill.

Reusing Classic Flows as Agent Skills

Most teams want to avoid rewriting everything. You can often reuse classic logic with some restructuring.

Step 1: Identify candidate flows

Good candidates for conversion to agent flows:

• Flows that already implement a single, well-defined business action, such as:
  • Create a case.
  • Update a case status.
  • Get a summary of records.
• Flows that run quickly and don’t depend on long delays or approvals.

Poor candidates:

• Complex approval flows with many human steps.
• Long-running batch processes.
• Flows that depend heavily on triggers tied to specific systems (e.g. “when a file is created in SharePoint”).

Step 2: Wrap existing logic

A common pattern:

1. Leave the original classic flow as-is.
2. Create a new agent flow that:
   • Receives parameters from the agent.
   • Calls the original logic indirectly (for example, via Dataverse or an HTTP endpoint if you’ve exposed one).
   • Returns a clean, agent-friendly output.

This gives you:

• A stable interface for the agent.
• The ability to change underlying implementation without touching the agent skill.

Step 3: Map skills in Copilot Studio

In Copilot Studio:

• Define the skill and its parameters.
• Link the skill to the agent flow.
• Test the mapping end-to-end with realistic user phrases.

For our support team:

• The existing “Create case” flow might be triggered by email.
• The new agent flow writes a case record using similar logic, but is triggered by the agent skill.
• Both coexist; one handles email ingestion, the other handles conversational requests.

Security and Identity: What Actually Runs Where

Experienced practitioners usually ask: “Under whose identity does this run?”

Connections and environment

Agent flows:

• Run in a Power Platform environment, like other cloud flows.
• Use the connection references configured in the flow.
• Respect environment-level governance (DLP, security roles, etc.).

That means:

• If your agent flow updates Dataverse, it does so under the identity backing the Dataverse connector in that flow.
• The end user’s identity in the conversation doesn’t automatically flow into the Dataverse operation.

Implications for our scenario

For the support agent:

• Case creation happens under the service account or user configured in the agent flow’s connectors.
• If you need per-user behaviour (for example, cases assigned based on the requester’s security context), you’ll need to:
  • Pass user identifiers from the agent into the flow.
  • Use that data inside the flow to drive assignment or access checks.

You should be explicit with stakeholders that:

• Agent flows are server-side automation, not client-side actions.
• Permissions and data access are governed by the flow’s connections and environment, not by the Copilot UI alone.

Performance, Limits, and Practical Constraints

Agent flows sit on the same underlying platform as classic flows, so most familiar constraints apply. The key differences are about expectations.

Performance expectations

Because agent flows are called mid-conversation:

• Users expect fast responses.
• Long delays feel worse than they do in background automation.

Practical guidance:

• Keep agent flows focused on operations that typically complete within a few seconds.
• Avoid heavy loops over large datasets in an agent flow.
• Use background classic flows or other batch mechanisms for large-scale processing, and have the agent report status rather than doing the work inline.

Limits and throttling

Agent flows are subject to:

• The same Power Automate limits as other flows (runs per user/environment, connector throttling, etc.).
• Any licensing constraints in your tenant (per-user, per-flow, or capacity-based).

You should:

• Monitor run history for agent flows like any other flow.
• Treat agent flows as production workloads when sizing capacity; conversational usage can spike quickly.

Before/After: What Changes for the Support Team

Let’s crystallise the impact on our scenario.

Before: classic-only setup

• Email ingestion flow creates cases.
• SLA update flow runs on a schedule.
• Teams notification flow alerts owners.
• Users must:
  • Open Dataverse/CRM or Teams tabs.
  • Know which commands or forms to use.

After: classic + agent flows

• Existing classic flows keep doing background work.
• New agent flows:
  • CreateSupportCaseSkill – called by the agent to create cases.
  • UpdateCaseStatusSkill – called to change status.
  • GetCaseSummarySkill – called to summarise a case.
• The Copilot Studio agent:
  • Uses these skills when users ask for actions in natural language.
  • Returns structured results and explanations.

What changed:

• The automation layer (classic flows) stays largely intact.
• A new interaction layer (agent + agent flows) sits on top.
• The team now maintains:
  • Classic flows for system-driven processes.
  • Agent flows for user-driven, conversational actions.

One Practical Takeaway

When you see “agent flows Copilot Studio” in documentation or UI, think of them as API-style skills your agent can call, not a replacement for your existing flows. Start by identifying one or two high-value actions (like “create case” or “get customer summary”), wrap them in small, explicit agent flows with clear inputs/outputs, and let your agent call those. Once that pattern is working, extending your classic automation into the conversational world becomes incremental rather than a full rebuild.