Agent Flows vs Workflows in Copilot Studio: What They Are and When to Use Each

The question I now hear in almost every Copilot Studio session is some version of this: “Is a workflow just the new name for an agent flow?” It is not. Agent flows vs workflows is a real choice, and it changes what you pay, how you test and what your governance team has to sign off.

They are two separate features that happen to share a page in Copilot Studio. One is not a newer version of the other, and there is no convert button between them. That makes this a design decision, not a setting.

Agent flows vs workflows: the short answer

An agent flow and a workflow do the same job. Both are a fixed sequence of steps your agent can call as a tool. In an agent flow, every step follows a rule, so the same input gives the same output. In a workflow, individual steps can also read, classify, reason or hand off to an agent.

The choosing rule fits in one line. If every step can be written as a rule, build an agent flow. If at least one step has to read or reason, build a workflow, and put a person on any route the AI is unsure about.

Why the naming trips people up

Most of the confusion comes from one word. For years, “workflow” was the generic term for any automated sequence in the Microsoft stack. Microsoft now uses it as the product name for one specific feature.

The real distinction sits underneath, in the harness. Microsoft describes a harness as the runtime between what you design and the model. Two of them matter here:

• The standard harness powers rule-based agents and agent flows.
• The Microsoft Copilot harness powers reasoning-heavy agents and workflows. You may have seen it under its earlier name, the GitHub Copilot harness.

So ignore the designer and the label. What matters is which runtime executes your steps, because that decides capability, billing and approval.

Power Automate cloud flows add one more layer of muddle. They are a third thing, licensed separately. A cloud flow can be converted to an agent flow. It cannot be converted to a workflow.

What an agent flow is

An agent flow is a deterministic automation built inside Copilot Studio. Microsoft calls it the established flow format, and if you have built a Power Automate cloud flow you already know how to build one. It has a trigger and a set of actions: connector calls, conditions, loops, approvals and data operations.

That predictability is the point. The agent decides whether to act. The agent flow guarantees how the action is carried out. Take a discount request above the standard threshold:

1. The user asks the agent for the discount.
2. The agent calls the agent flow with three inputs: customer, request and reason.
3. The flow looks up the requester, sends an approval to a named manager and waits.
4. A condition routes the outcome, approved or not, each with its own notification.

Nothing in steps 3 and 4 is left to the model. The human gate is a step in the flow, not a line in the instructions.

What a workflow is

A workflow is the newer automation experience, built on a redesigned canvas. It still has a trigger and actions. What changes is the kind of action you can place on the canvas:

• Agent node: hands a step to a published agent, or to a small agent you define inline.
• Copilot node: calls Microsoft Copilot, including Cowork and agents such as Researcher and Analyst.
• Classify node: routes free text to a branch based on its meaning.
• Extract node: pulls structured values out of unstructured text.

You also get human-in-the-loop actions, such as a request for information that pauses the run until a person answers, and node-level testing, so you can run a single step before you run the whole thing.

Microsoft’s own wording on predictability is careful, and worth repeating to a client. A workflow follows a defined sequence, but results can vary when an action uses AI or retrieves changing data. A workflow is a rule-based skeleton with intelligent steps in it. It is not an agent, and it is not fully deterministic either.

Go back to the discount request. A classify node can read the free-text request and decide whether it is a standard renewal or an above-threshold discount before the human gate. That removes rigid input forms. It also introduces a step that can misread, which is why the default route should always go to a person.

The differences that matter

Source: Microsoft Learn, checked 12 November 2026. This area is moving quickly, so check the workflows FAQ before you commit a design.

How to choose: four questions

Start with the process, not the product. Write the steps down and mark each one as a rule (a condition, a lookup or a fixed action) or a judgement (something has to read, interpret or decide). Then ask four questions in order.

1. Can every step be written as a rule? Build an agent flow. Approval routing, record updates, notifications and anything with a numeric threshold belong here.
2. Does at least one step need to read or reason? Build a workflow. The AI nodes do in one step what would otherwise need a prompt action plus parsing logic.
3. Is your environment cleared for usage-billed features? If capacity, data policy or model choice has not been agreed with whoever owns governance, stay on agent flows until it has.
4. Do you have Power Automate flows to reuse? They convert to agent flows and not to workflows. Reuse is a legitimate reason to stay on the established format.

Use neither when a single connector action added directly to the agent does the job. A one-step automation does not need a canvas.

A step that reads is not a rule

This holds in both formats. If the decision is “discount above 15 per cent”, capture the discount as a number and test it in a condition. Do not ask a classify node to infer it from a sentence. Use AI steps for interpretation, and conditions for anything you would be asked to defend in an audit.

How each one connects to your agent

From the agent’s side the two look identical. Each is a tool with a name, a description, inputs and outputs. The orchestrator reads the description to decide when to call it, so the description matters more than the build.

Both need the “When an agent calls the flow” trigger and a “Respond to the agent” action. Both must be published, respond in real time, and respond within a 100-second limit.

That limit shapes the design, because a human approval will take longer than 100 seconds. Microsoft’s guidance for agent flows is that actions placed after the response carry on running. So respond early with a status, such as “request submitted, awaiting approval”, and let the approval continue. Test the same pattern in a workflow before you rely on it.

Workflows also run the other way. A workflow can call an agent through an agent node, which gives you two patterns: conversation first, where the agent starts the process, and process first, where a trigger starts the run and an agent handles the one step that needs reasoning.

One warning. If two tools on the same agent do the same job, the orchestrator has to choose between them and your testing becomes unreliable. Keep one enabled per job.

Cost and governance

The choice has a cost and an owner. Treat it as a recorded decision.

• Build and test costs differ. Agent flow test runs from the designer or the test chat are not charged for flow actions, although prompts inside the flow are metered separately. On the Microsoft Copilot harness, building and testing might consume Copilot Credits. A cohort of twenty people building workflows in a morning is a line on the capacity report.
• Licences change the maths. When a user with a Microsoft 365 Copilot licence is talking to an agent that calls an agent flow, those flow actions are not charged. That exemption disappears when the agent runs autonomously.
• Capacity is enforced. When prepaid capacity runs out, new runs are blocked and runs in progress complete. Decide in advance whether pay-as-you-go is switched on.
• Monitoring is split. The Workflows page shows 30 days of credit usage for workflows but shows N/A for agent flows. Use the Power Platform admin centre for the full picture.
• Autonomous triggers need approval. A scheduled or event trigger runs without anyone asking. That is where cost and risk grow unwatched.
• Human gates need a name. The control is a step with a named person in it, placed before the consequential action. Confirm nothing downstream ran before that person answered.

One principle covers both formats: AI operates within defined authority, and people approve consequential decisions.

The takeaway

An agent flow is rules all the way through. A workflow is rules with steps that can read and reason. Your agent calls either one as a tool, there is no conversion between them, and the harness underneath decides the bill.

For most teams the practical path is to start with agent flows for the actions that must never vary, then introduce a workflow where a real process has a step that rules cannot express. Choose deliberately, record the reason and name the owner of the cost.

Build this hands-on in December

If you would rather work through these decisions on a live build than on a whiteboard, I am running four half-day workshops on Microsoft Teams on 14 and 15 December 2026. The sector sessions include hands-on agent building, and the leaders’ session covers agent governancehttps://gethynellis.app/events and sprawl controls. Seats are £150 plus VAT.

See the December Copilot workshop sessions and book a seat.