When to reach for an agent instead of a flow

Two different shapes of automation

A flow is a fixed path. You decide every step in advance (trigger, actions, conditions) and the flow walks that path the same way every time. Its great strength is exactly that predictability: you can read it, test it, and know precisely what it will do. Even the AI step you added in the first lesson sits inside a path you drew; the flow's shape doesn't change, only the value that one step returns.

An agent is a different shape. Instead of following a path you designed, it's given a goal and a set of tools, and it decides in the moment which tools to use and in what order to reach that goal. That's agentic behaviour: the software chooses its own steps. Microsoft's tool for building these is Copilot Studio, where you can create agents that hold a conversation, answer from your organisation's knowledge, and take actions, including calling flows you've already built.

The trade is straightforward. A flow gives up flexibility for predictability. An agent gives up predictability for flexibility. Neither is "better"; they're for different jobs, and the skill is knowing which job you've got.

When a plain flow is the right answer

Most of the time, it is. Reach for a flow, not an agent, when the job is:

• Triggered by an event, not a conversation. A file lands, a form is submitted, it's 9am on Monday. Something happens, and a fixed response should follow.
• The same every time. The steps don't change based on judgement. Log it, notify them, file it, chase it.
• Describable as a path. You can draw it as a flowchart with a sensible number of branches. If you can sketch it, a flow can do it.

The Fernway feedback flow from lesson one is a perfect flow: an email arrives, one AI step classifies it, a condition routes it. Fixed trigger, fixed shape, one contained judgement. Rebuilding that as an agent would add cost and unpredictability for nothing. When a flow fits, a flow wins: it's cheaper, more predictable and far easier to govern with everything you learned in the last lesson.

The signs a job has outgrown a flow

You'll feel the edges of a flow before you can name them. Watch for these signs:

• It needs a conversation. Someone types a question in their own words and expects a sensible, in-context reply: a helpdesk assistant, an "ask about our policies" tool. Flows respond to events, not open-ended questions; that back-and-forth is an agent's home turf.
• The path has too many branches to draw. If capturing every case would need dozens of nested conditions, you're really asking for judgement, not a decision tree. An agent reasons over the situation instead of you enumerating every route.
• The next step depends on reading and understanding. Not "which of four categories" (a flow with an AI step handles that) but open-ended interpretation across messy, varied input where you can't predict the shapes in advance.
• You want it to pull from a body of knowledge to answer. "Answer staff questions from our HR documents" is a grounding job: an agent answering from a knowledge source, not a flow moving data between apps.

A blunt rule of thumb: if you're forcing a flow to have a conversation or drawing your twentieth condition to cover another case, you've probably outgrown the flow.

They're not rivals: agents use flows

The most useful thing to understand is that this isn't a choice between two camps. A well-built agent often calls flows to do its concrete, reliable work. The agent handles the messy, conversational, judgement-heavy front (understanding what someone wants) and then hands off to a flow for the deterministic bit: logging the record, sending the approval, filing the document. The flow does the part that must happen exactly the same way every time; the agent does the part that needs to flex.

So the skills you've built don't expire the moment you meet agents; they become the dependable actions an agent relies on. A reliable, well-governed flow is a better building block for an agent than a fragile one, which is why the previous lesson still matters here.

Choose the simplest thing that works

The honest default is caution about agents, for the same reason you keep a human on the irreversible step in a flow: an agent that chooses its own path is, by design, less predictable and harder to govern than one you drew yourself. Everything IT asked about a flow (who owns it, what it touches, what it can do unsupervised) matters more for something that decides its own actions, not less. That's not a reason never to use one; it's a reason to use one deliberately, when the job needs the flexibility, and to keep a person on anything the agent does that's costly or can't be undone.

So the decision comes down to a short ladder, and you take the lowest rung that does the job:

1. A plain rule or condition. No AI at all. Cheapest, most predictable.
2. A flow with one AI step. A fixed path with a single contained judgement, guarded by a human check.
3. An agent (Copilot Studio). Only when the job needs conversation, open-ended judgement, or a path too varied to draw.

Reaching for rung three because it's exciting, when rung one would do, is the most common mistake here. The champion's instinct is the opposite: the least clever thing that reliably does the job, with a human kept on whatever could go wrong.

One shape sits beyond this ladder: an AI coworker that works across your tools rather than living inside Power Automate, so the real question is increasingly flow versus agent versus coworker. That's a Phase 6 topic; when you meet it in The AI coworker, the same instinct applies: reach for the simplest shape that does the job, and keep a person on the risky part.

Try it now

Common mistakes

• Building an agent for a flow-shaped job. If it's event-triggered and always the same, an agent adds cost and unpredictability for no gain. Draw it as a path first; if you can, use a flow.
• Forcing a flow to hold a conversation. Twenty nested conditions trying to handle every phrasing of a question is a flow doing an agent's job badly. Open-ended, in-their-own-words interaction is the signal to move up a rung.
• Forgetting an agent needs more governance, not less. Something that chooses its own actions raises every ownership, permission and data question higher. If a flow needed IT's sign-off, an agent needs it more.
• Over-trusting an agent because it's articulate. An agent's fluent, confident manner makes it easy to assume it's also reliable and to hand it the risky step (sending externally, spending money, deleting things) because it "seems to know what it's doing". Fluency is not judgement, and an agent choosing its own path can be confidently wrong in more ways than a fixed flow can. Keep a person on anything costly or irreversible, exactly as you would with a flow; more so, because you drew fewer of the steps yourself.

Keeping current

Agents and Copilot Studio are moving faster than almost anything else in this course: capabilities, licensing and the line between "flow" and "agent" all shift regularly, and features like agent flows blur the boundary further. The 2026 wave 1 direction (roughly April to September 2026) pushes the two closer still: cloud flows can call Copilot Studio agents as actions, and desktop flows are gaining self-healing behaviour that adapts when an app changes. Microsoft's What is Microsoft Copilot Studio and the agent flows overview on Microsoft Learn track the current picture. The judgement is durable, though: match the tool to the shape of the job, take the simplest rung that works, and keep a human on the risky step. Accurate as of 14 July 2026.