Create an agent flow

A purchase-order lookup that has to hit the same three systems in the same order on every call is not a conversation, and it is not something you want a language model improvising. It is an agent flow: the automation artifact you build inside Microsoft Copilot Studio, add to an agent as a tool, and rely on to behave identically for identical inputs. Microsoft states the property plainly, describing agent flows as deterministic^[1]: they execute actions or tasks following a rule-based path, and the same input always produces the same output.

Three automation artifacts, three names

Copilot Studio and Power Automate both put automation in front of you, and the names overlap enough that blurring them is the most expensive mistake on this subject.

• An agent flow is the automation artifact built and managed inside Copilot Studio. It is billed in Copilot Studio based on usage, and the agent flows FAQ^[2] states that no Power Automate license is needed to create one.
• A cloud flow is the Power Automate artifact. It is a separate runtime with its own designer and its own licensing, and the FAQ says the two serve distinct purposes even though they complement each other: cloud flows require a Power Automate license and offer general automation across applications and services. A page about cloud flows is not evidence about agent flow behaviour, and the reverse is equally untrue.
• A workflow is the automation artifact of Copilot Studio's new experience^[3], currently in public preview. It repeats the agent flow benefits almost word for word and uses the same When an agent calls the flow trigger, but it is built on a redesigned canvas, and the preview note says agents and workflows created in the new experience can't be converted to the classic experience. This page teaches the classic agent flow.

One collision is worth defusing at first mention, because the word appears on both sides of the product. A flow trigger is not a topic trigger. A topic is matched from trigger phrases under classic orchestration, which is the mode where an agent responds by triggering the topic whose trigger phrases best match the user, or it is chosen by the orchestrator from its description under generative orchestration, the mode where the agent picks tools, topics, other agents and knowledge itself. Those two modes decide how much of the branching you should be encoding in a flow at all, which is the subject of a later section. A flow trigger is something else entirely: the first card of the flow, naming the event that starts a run.

What this page owns

Plan reuseable agent components already answered whether a piece of logic should become a reusable module at all, and which module type fits; an agent flow is one of those module types. This page picks up after that decision and covers the flow itself: the shape it has to have, the two ways to build it, and the conditions that make it visible to an agent.

The neighbouring pages own the rest of the lifecycle. Parameter design in depth is Add input and output parameters. Wiring a finished flow into a conversation is Add agent flows to a topic. Failure paths belong to Implement error handling in agent flows, run history to Monitor agent flows, and approval stages to Create a human-in-the-loop agent flow.

The requirements, collected in one place

Microsoft publishes the criteria for using an agent flow as a tool across several articles rather than in one list. Collected, a flow is callable by an agent when all of the following hold, and the rest of this page takes them one at a time.

Requirement	Where Microsoft states it
Has the When an agent calls the flow trigger	Add an agent flow as a tool to an agent[4]
Has a Respond to the agent action	The same article, and the FAQ[2]
Is configured to respond in real time, with Asynchronous response set to Off	Create an agent flow as a tool[5] (reconciled against the asynchronous-response article later on this page)
Is published	Add an agent flow as a tool to an agent[4]
Is a solution flow, in the same Power Platform environment as the agent	The FAQ, and Modify an existing flow to use with an agent[6]
Answers inside the synchronous response window	Both agent-tool articles

Two of those rows use terms the later sections own, so here they are in one line each. A solution flow is simply a flow that has been added to a Power Platform solution, the container that holds and moves components; the reachability section covers what that buys you. The synchronous response window is the short period in which a flow used as a real-time tool has to return an answer to the agent, and it is short enough, and contested enough, to get a section of its own.

Read the table as a gate rather than a checklist you can partly satisfy. A flow that misses one of the six is not callable: some gaps keep it out of the agent's Add tool panel, others surface when the agent calls it. The rest of this page is those six rows, in the order you meet them while building.

The data an agent sends into a flow and gets back from it lives in two cards. The When an agent calls the flow trigger declares the input parameters the agent has to supply, and the Respond to the agent action declares the output parameters the agent receives back. Call that pair the agent-facing contract. Everything between the two is implementation, and the agent cannot inspect it, so a value that some connector action produced but nobody mapped onto an output does not exist as far as the agent is concerned.

You normally get both cards for free. Microsoft's guidance is explicit that when you create an agent flow in Copilot Studio as a new tool^[5], the required flow trigger and response action are added for you, and the designer opens on a starter template that already contains them. That is why the ordinary build order runs in the direction it does: add the input parameters the trigger needs, add the business actions between the two cards, then map the values you want returned onto the response action's outputs.

Why the middle stays in the middle

The temptation, especially when the agent is doing the talking anyway, is to skip the mapping step and let the agent sort out whatever the flow happened to fetch. It cannot. The response action is the only exit, and its output parameters are the only vocabulary the agent has for the result. A flow that queries an order table and never maps the order status onto an output returns a successful run and no usable answer, which is a far more confusing failure than an error.

Keeping business actions strictly between the trigger and the response also keeps the contract stable while the implementation churns. Swapping a SharePoint lookup for a Dataverse lookup changes nothing the agent sees, provided the same outputs still get populated. That stability is the whole reason an agent flow works as a reusable module: one published flow can be added as a tool to any of your agents, and each of them binds to the contract rather than to the actions.

The figure below traces one call from the agent, through the trigger, the implementation actions and the response action, and back.

One contract, even when the flow branches

A flow that looks up an order in one of two systems has two natural ending points, and Microsoft allows both to carry a response action. The rule attached to that permission is the important half: the response action can be used at multiple branches in the flow^[6], but it must have the same outputs at each usage. Two branches, two response actions, one output set. A branch that returns a different shape is not a variant of the contract, it is a second contract, and the agent has no way to know which one it got.

Removing the response action is a design decision, not a shortcut

There is a third possibility that catches people out, because it looks like a mistake and is in fact documented behaviour. If your environment supports asynchronous responses but you want the agent to reply immediately, remove the Respond to the agent action from the flow^[7]: the agent then responds immediately after it successfully triggers the flow. That is a deliberate fire-and-forget design, and it is the documented route to an immediate acknowledgement. It is not a route to a faster answer, because with the response action gone the flow has nothing to return. The timing section below picks this up as one of three ways to deal with a slow flow.

The takeaway to carry forward: design the trigger inputs and the response outputs first, treat them as the published surface of the flow, and let the actions in between change as often as the business needs them to.

Copilot Studio gives you two entry points to the same designer. The choice is about how you start, not about what you finish with, and both paths end with you reviewing the flow card by card.

Describing the flow to Copilot

On the natural-language path you describe what you want the agent flow to do^[8] in the Copilot chat panel, in ordinary language. Microsoft's guidance is to write the description in a When X happens, do Y shape and to include as much as you can of the trigger, the connector or service involved, the actions, any conditions, and specific named parameters such as a SharePoint list name or a Teams channel. Copilot then presents a plan, you refine that plan by describing the changes in the chat, and when you are satisfied you confirm, at which point Copilot builds and configures the flow end to end, including connections and parameters.

Two details on that path change how you work. First, selecting Save finalizes the flow and opens it in the designer, and once it is open in the designer the Copilot chat panel can no longer make changes to it; from that point on you edit in the designer. Second, the feature uses Anthropic models and may dynamically select or fall back between supported models, and access depends on an administrator having turned on external models for the environment or environment group. That last point sits on the administrator's side of the fence, but a builder who has not heard it will read a missing chat panel as a product defect rather than an environment setting.

Building on the canvas

On the designer path you assemble the flow yourself. Below the card where the new step belongs you select Insert a new action^[9] and pick the action from the panel; selecting any trigger or action card opens its configuration panel with the Parameters tab shown by default, where a value is either chosen from a dropdown or set dynamically with an expression. The same canvas holds the view controls, the version history and the Flow checker.

Version history is worth setting up deliberately rather than discovering later. Microsoft records a version history in Microsoft Dataverse as you build or modify a flow, versions are grouped by date with indicators for latest version, published and past published, and the history is based on saved versions, which is why the guidance is to save drafts before the flow is complete. A flow you built in one long unsaved session has nothing to roll back to.

Either way, inspect before you publish

Whatever produced the cards, you own what they do. The Flow checker lists every error in the flow and Microsoft is blunt that you can't publish a flow that contains errors, so the checker is a completeness gate rather than a correctness one. The docs say so directly: just because your flow has no errors and can be published doesn't mean it's going to do what you want it to. Confirm the trigger, the actions, the conditions and the parameter mappings yourself, then run the flow's own test, which is covered in the publishing section below.

The figure below shows both entry points converging on the designer and the checker.

The create-menu path is described inconsistently, so anchor on the template

The published articles do not agree on what you click. The agent flows overview^[1] says to go to the Workflows page and select New agent flow. The create-as-a-tool article^[5] says to go to the Flows page from the left pane and select New flow followed by Agent flow. The natural-language article^[8] splits the difference, telling you to select Flows from the navigation pane to go to the Workflows page. All three are current and all three describe the same act.

Do not memorise a label from any one of them. What is stable across every version is the outcome, and it is the thing worth carrying into a question: the agent flows designer opens on a starter template that already includes the required When an agent calls the flow trigger and Respond to the agent action. If the designer you are looking at opened without those two cards, you are not on the agent-callable template, whatever the menu called it.

Saving records a version; publishing makes the flow callable. Those are two different acts on the same artifact, and confusing them is a common way an otherwise finished flow refuses to work.

The requirement is stated flatly: to be added as a tool, the flow must be published^[4], which is what puts it in the agent's Add tool panel. The publish command lives on the menu at the top of the designer canvas, and it is gated by the Flow checker^[9]: you can't publish a flow if it contains errors, and you must correct all of them first. A red action card is therefore a publish blocker, not a runtime surprise, which is the good half of the design. The bad half is that a clean checker tells you nothing about whether the values are right.

The figure below shows the states a flow moves through on its way to being callable.

The word "publish" means two different things on this exam

Plan channels and deployment uses publication for the agent: content going live on the channels the agent is connected to, as distinct from distribution, which is getting the app in front of users. A flow's publication is a third thing, on a different artifact, with its own button in a different designer. Publishing the agent does not publish the flow.

That distinction is exactly what makes the classic trap work. A maker opens a published flow that is already a tool on an agent, adds an output parameter to the Respond to the agent action, saves a draft, then republishes the agent and expects the agent to see the new output. The agent binds to the published flow, and the new output only exists in a draft, so nothing changed. The fix is to publish the flow.

Test after publishing, not instead of it

Microsoft puts the flow's own test after publication for a reason: you save and publish, select Test on the canvas menu, choose whether to run it manually or automatically, and then inspect the output of each action to confirm the flow does what you intended. A green check on the run is evidence about the actions; the outputs each action produced are evidence about the contract.

One caveat rides along with that test, and the cost section below explains it in full: a designer test does not consume the Copilot Studio capacity that a real run does, so a clean test says nothing about what the flow will cost in production.

A flow the agent cannot see is usually a question of where the flow lives rather than something to debug inside the flow. Two conditions decide it: flows must be stored in a solution^[6], and that solution has to be in the same Power Platform environment as the agent. The FAQ states the first of those as the flow having to be a solution flow, alongside the When an agent calls the flow trigger and the Respond to the agent action. The Default Solution counts; Microsoft says flows can be added to it for use with agents, or moved into a different solution.

A Power Platform solution^[10] is the container that carries components between environments, and Plan reuseable agent components treats it as such. Here it is doing a narrower job: solution membership is what makes the flow addressable inside its own environment. Whether a flow is in a solution is visible on the flow's detail page, where a Solutions tile lists the solutions it belongs to.

Why your flow is not in the list

The predictable misread is to treat an absent flow as a permissions problem. It is almost always provenance. The FAQ is explicit that the Copilot Studio Flows page only displays agent flows created in Copilot Studio^[2], and that flows created in Power Automate must be managed in Power Automate unless you convert them to agent flows. So the first question about a missing flow is not who can see it, but which product created it.

That gives three starting positions, shown in the figure below.

Path one: it is already an agent flow

Nothing to move. Walk the six requirements from the first section: trigger, response action, real-time configuration, published, in a solution, in this environment.

Path two: keep it in Power Automate, but make it agent-callable

An existing cloud flow with the wrong trigger can be edited in place. Microsoft's procedure is to open the flow in the Power Automate portal with the correct environment selected, remove the existing trigger^[6] from the three-dot menu on the trigger card, search under Add a trigger for Copilot and select When an agent calls the flow, then add a final step from the Copilot connector and select Respond to the agent, then save and publish. If the flow is not already in a solution, you add it with Add existing followed by Automation and Cloud flow from inside the target solution. This is the path behind the scheduled-recurrence flow that ends in an email and now has to answer an agent: the schedule trigger goes, the agent trigger arrives, the email can stay.

Path three: convert it to an agent flow

Conversion changes the cloud flow's plan and billing rather than rebuilding its logic. Microsoft's steps run from the cloud flow's detail page in the Power Automate portal: confirm the flow is in a solution, confirm it is in the Power Platform environment whose Copilot Studio capacity you want to consume, select Edit, change the flow's plan to Copilot Studio, save, and confirm. Two constraints ride along and both are decision-shaping. Conversion requires that Copilot Studio capacity^[1], prepaid or pay-as-you-go, is available in the environment. And conversion is a one-way operation that can't be reversed, because the flow's billing changes.

The environment boundary does not bend

A flow that sits in a different environment from the agent is not reachable by naming it, giving it permissions, or publishing it harder. The answer is to get a copy of the flow into the agent's environment, which is solution work: Create a solution and the pipeline pages in the management domain own that journey. A shared-services team that publishes its flow inside a solution in a dedicated automation environment has built something perfectly valid and perfectly unreachable from an agent that lives somewhere else.

A flow used as a real-time tool has to answer inside a short synchronous response window, and how long that window is depends on which Microsoft article you are reading.

The agent-tool requirement articles state it as a 100-second action limit^[5], with the instruction to optimize the flow logic, the queries and the amount of data returned so that a typical run finishes below it. The asynchronous-response article and the express-mode article state it as a two-minute limit^[7], the express-mode page adding that by default a flow initiated by an agent or app fails if it takes longer than two minutes to respond. Both readings are current documentation, and this guide does not pick a winner: design to the shorter of the two figures and neither reading catches you out. What both agree on is the shape of the constraint, which is what a question will actually turn on.

Three separately documented ways exist to handle work that will not fit. The figure below lays them on one timeline.

Move the slow work after the response

The cheapest option changes nothing about configuration. Actions in the flow that need to run longer can be placed after the Respond to the agent action^[6], where they continue to run up to the flow run duration limit of 30 days. The agent gets its answer at the response action and the archiving, notifying and reconciling carry on behind it. Reach for this whenever the slow work is not what the agent is waiting for.

Turn on Asynchronous response when the result itself is late

When the agent genuinely needs the outcome of a long-running process, the flow can keep running and call back. You open the flow, confirm it uses the When an agent calls the flow trigger, select the Respond to the agent action on the canvas, open Settings, turn on Asynchronous response^[7], and save or publish. The flow then continues beyond the normal two-minute limit and returns a callback response to the agent once it finishes.

Three published details decide whether that is available to you and how it behaves.

• The feature is available only in environments running on the new infrastructure^[11].
• The callback is fully supported in Microsoft Teams. Microsoft notes other channels might also support callbacks but aren't formally tested, and states that callbacks aren't supported for Microsoft 365 Copilot and telephony channels.
• If the user sends another message before the flow completes, the flow still runs to completion, but the agent responds to the user's latest request without waiting for it.

That last behaviour is the one to recognise in a scenario: a callback is not a hold on the conversation.

Reconciling the toggle with the tool requirement

The requirement articles and the asynchronous-response article look like they contradict each other, and the reconciliation matters. Adding a flow as a tool^[4] lists, among the criteria, that the flow be configured to respond in real time and not asynchronously, with the Asynchronous response toggle set to Off under Networking in the response action's settings. The asynchronous-response article tells you to turn that same toggle on. Both are describing the same switch and two different runtime shapes: Off is the real-time tool contract those articles enumerate, and On is the newer callback behaviour that only exists on the new infrastructure. Treat the choice as a design decision about how the answer arrives, not as a setting one article got wrong, and never assert one of them as the settled requirement.

One symptom is worth memorising because it identifies the third case. If an environment does not support asynchronous response, the agent might receive a "flow completed" response immediately^[7] while the flow continues to run in the background. An agent that cheerfully reports the flow completed seconds into a six-minute run is describing that environment, not a fast flow.

The third option is the one from the contract section: remove the Respond to the agent action entirely and the agent replies immediately after it successfully triggers the flow, with nothing to return afterwards.

Express mode, in one paragraph

Express mode^[12] is prerelease documentation and a preview feature, so it is not production guidance, but knowing what it targets keeps you from mistaking it for the asynchronous decision. It speeds up execution so a flow is more likely to finish inside the two-minute window, it requires the When an agent calls a flow or When an app calls a flow trigger, a response action, a Copilot Studio plan, and an environment on the new infrastructure. Microsoft's own guidance scopes it to logic-heavy flows and warns against data-heavy ones, and when express mode is on the flow must complete in two minutes. It is a performance lever inside the window, never a way past it.

Put a branch inside the flow when the deciding value is one the flow can read, and leave the decision to the agent when it needs interpretation. That single sentence resolves most of the design arguments on this subject.

The reason it works is the asymmetry between the two runtimes. An agent flow is deterministic and follows a rule-based path, and its built-in tools include control structures for looping and branching^[1] alongside data operations and child flows. An agent under generative orchestration^[13] works differently: it selects one or more tools, topics, other agents or knowledge sources to handle a query, and the most important factor in that selection is the description of those items, followed by their names and their input and output parameters and the names and descriptions of those. It can chain several of them in sequence, and it summarises what they returned into an answer. It also uses recent conversation history, which Microsoft says is why the same query can get different responses in a fresh conversation and in a long-running one.

That is judgement, and judgement is the right tool for an ambiguous request. It is the wrong tool for a rule the business has already fixed. A qualification rule that reads a policy record and returns a yes or a no is a condition inside the flow. Returning all the raw policy records to the agent and asking the orchestrator to work out which branch applies costs you twice: the outcome is no longer repeatable for the same input, and the raw data has left the flow to become part of a generated response.

The bound on the determinism claim

Determinism here is a property of the flow's own path, not of the whole turn. Whether the agent calls the flow at all, with which inputs, and how it words the answer afterwards, stays with the orchestrator. So the accurate version of the guarantee is that once the flow starts with a given set of inputs, its actions and branches are fixed. That bound is what makes an agent flow the right home for an irreversible operation such as posting a payment reversal: the steps that must not vary are the ones inside the flow.

Topics are deterministic too, and are still not the answer here

The FAQ is careful about this, and it is a genuine near-miss in questions. Both topics and agent flows are deterministic pathways^[2]: given the same inputs they always produce the same output. What separates them is what they are optimized for. Topics manage conversational flows and can be enhanced with actions running behind the conversation; agent flows manage business processes and carry more comprehensive automation for nonconversational work. So a stem asking for a repeatable multistep connector sequence with no conversational element is pointing at an agent flow, and a stem about collecting an answer from the user before doing anything is pointing at a topic that may then call one.

The takeaway: encode in the flow only the branches whose deciding values the flow can obtain, keep them there so that they stay repeatable, and let the orchestrator do the part of the work that genuinely needs a model.

Every action an agent flow executes consumes Copilot Studio capacity^[1], and every action in the callable path also spends part of the synchronous response window. Those are two different costs with the same cure, which is why the same design instinct fixes both: put in the path only the work that produces the agent's answer.

Microsoft's own capacity arithmetic makes the shape visible. Running an agent flow from a topic consumes one Classic answer plus the agent flow actions, and running one under generative orchestration consumes one Autonomous action plus the agent flow actions. The per-run part is fixed; the part that scales with your design is the action count. A flow that lists every row of a large table and loops over each of them to build a total pays both costs on data the answer never needed, and the requirement-side guidance says exactly what to do about it: optimize the flow logic, the queries and the amount of data returned so a typical run finishes inside the window.

Where the surplus work goes

It does not have to be deleted, only moved. The pattern from the timing section applies directly: work that is not part of the answer belongs after the Respond to the agent action, where it continues to run up to the 30-day flow run duration limit without holding up the reply. A flow that looks up an order status, archives a confirmation to SharePoint and emails the warehouse should return the status first and do the other two afterwards. The user gets the answer sooner, and nothing is lost.

Where the cost hides

The first hiding place is the test bench. Testing a flow in the designer, or running it from the agent's embedded test chat, does not consume Copilot Studio capacity. That is convenient during development and misleading as evidence: a test run tells you the flow works, and nothing at all about what it will cost in production.

The second is the shape of the work itself, and the express-mode guidance is useful reading precisely because it names the failure mode. It labels data-heavy flows as the wrong shape, giving as examples listing the rows in a large table, or a get-items action returning 1,500 rows with 100 columns, and it counts each loop iteration as one action. Those specific numbers are express-mode limits^[12], scoped to that preview feature rather than to agent flows generally, so do not carry them over as general quotas. What does carry over is the diagnosis: a loop over a large collection is where an agent flow's action count and its latency both go wrong.

When capacity actually runs out

This is where the builder-side seam meets the licensing side, and the builder-relevant part is the symptom. Once an environment's prepaid Copilot Studio capacity is fully consumed, new agent flow runs are blocked until capacity is available, while flows that are already running complete normally. Microsoft 365 Copilot licensed users and test runs are not affected. An agent that has stopped being able to run its flows while its test chat still works is describing that state, and the remedy sits with whoever manages the environment's capacity rather than in the designer.

The scenarios on this subject are recognisable because each one hides exactly one of the six requirements. Reading the stem for which requirement is missing is faster than reasoning about the flow itself.

Stem shapes and what they are testing

What the stem says	What it is testing	The move
The flow is published, the Flow checker reports no errors, but the agent does not see a new output	The draft-versus-published distinction	Publish the flow, not the agent
An existing cloud flow with a scheduled trigger, ending in an email, must now serve an agent	The contract, and the modify path	Replace the trigger with When an agent calls the flow, add Respond to the agent, keep it in a solution
The flow is published inside a solution in a dedicated automation environment	The environment boundary	Get the flow into the agent's environment; solution membership alone is not enough
The flow runs for six minutes and the agent announces completion within seconds	The environment without asynchronous support	Recognise the immediate "flow completed" response, then decide between async, post-response actions, or a faster flow
The agent must confirm a job started and report the outcome later	Asynchronous response versus removing the response action	Turn on Asynchronous response only when the late result is required; check the channel
A condition ends in two branches, each with its own response action	The same-outputs rule	Both response actions must declare the same outputs
A flow archives to SharePoint and emails the warehouse before returning a status	Callable-path cost and latency	Return the status first, move the rest after the response action
An irreversible ledger posting under generative orchestration	Determinism	The fixed steps belong in an agent flow, not in an orchestration plan

The distractor families

Four wrong answers recur, and each one is a plausible act that solves a different problem.

The first is publishing the agent when the flow is what changed. It is attractive because publishing an agent is a real and frequent operation, and because the agent is the thing the user talks to.

The second is adding the flow to a solution while leaving it in the wrong environment. Solution membership and environment co-location are two requirements, not one, and a stem that mentions a solution has satisfied only half the rule.

The third is turning on Asynchronous response when the requirement is an immediate acknowledgement. The documented answer there is to remove the response action, because asynchronous response makes the result arrive later, not the acknowledgement arrive sooner.

The fourth is reasoning about an agent flow from cloud-flow behaviour, or the reverse. They are separate runtimes with separate designers, separate billing and separate documentation, and a distractor built on a Power Automate detail can look entirely reasonable until you notice which product it belongs to.

One last habit worth keeping. When a stem quotes a menu label or a page name for creating a flow, treat the label as scenery. Microsoft's own articles word that path differently from one another, so a question that turned on the exact label would be unanswerable; what the question is really asking about is the starter template, the trigger and the response action.