Autonomous agents - Technique 3: Provide tools for steps your agent can't easily handle (like Agent Flows)

Continuing the theme of this series on how to build effective AI agents which have some autonomy and operate on the instructions you give, we need to address another aspect of keeping an agent on rails - specifically, when agents take action. That might be updating an external system or database, sending an e-mail or other message, asking for human approval in a step, cross-referencing some organisational data, or any number of other things we may want an agent to do. The challenge is that steps like these often need to be very defined and exact - simply specifying what should happen in agent instructions is often never going to work. "Update our CRM with the new lead details" or "Raise an invoice for the order" are vague guidance with nowhere near enough context - even the most capable AI agent backed by the latest LLM will fail on those without help. If the agent could talk it would conceivably say "What CRM, where? How do I authenticate? How are leads stored, and how do I ensure the lead is associated with a client and I'm not creating a duplicate?" 

In the last post we focused on writing good instructions for agents - but most agents need more than that. They need to call out to tools which are pre-defined and wrap up the complex details of taking actions on specific systems, integrating data, or performing precise steps in a process. Every agent framework has a 'tools' concept, and for Microsoft agents built with Copilot Studio, this is agent flows - ultimately Power Automate flows triggered from Copilot Studio agents which. This post covers how to make your agent more reliable in actions it performs by calling out to agent flows, including the specific help Microsoft give you to simplify this.  

But first, here's a recap of the full series:

Articles in this series

1. Techniques for autonomous agents in Copilot Studio - intro 
2. Scenario video - Microsoft architect with proposal generation
3. Technique 1 - Getting AI-suitable descriptions right - data, tools, agents themselves 
4. Technique 2 - Define explicit steps in agent instructions when "reasoning the process" isn't appropriate
5. Technique 3 - Provide tools for steps your agent can’t easily handle [like agent flows] (this article)
6. Technique 4 - Leveraging Power Platform and Microsoft 365 capabilities in your agents
7. Technique 5 - Understand cost, capability, and governance implications of agents you create
   
   

Agent flows - what are they?

As a concept, agent flows isn't anything too new - this is Power Automate within the Microsoft ecosystem but adapted for the AI and agent world. An agent flow is essentially a Power Automate cloud flow which can only be called from an agent. Here's a quick primer on some of the differences and commonalities:

Agent flows - a primer

• Agent flows share the same workflow designer as Power Automate, the same set of connectors, and the same approach to key concepts like triggers, actions, child flows, and variables
• An agent flow must be created in Copilot Studio (not Power Automate) and start with the Run a flow from Copilot trigger and finish with the Respond to Copilot action.
• Licensing is different - Agent Flows run under Copilot Studio licensing rather than Power Automate licensing (i.e. they consume Copilot credits)
• Agent flows can use Premium connectors without charge (since it's being covered by the Copilot Studio licensing)
• Agent flows DO bring special support for calling from agents - in particular, if your flow has a series of input parameters (let's say pieces of an address), the agent can automatically determine which pieces of data it should pass to each. This works surprisingly well if you name your inputs properly - more on this later
• Agent flows are designed to be shared across agents - they essentially become a toolkit of well-defined actions and sub-processes used by your agents, some of which may be specific to an agent and some shared across many
• Agent flows give better tracking, analytics, and overall control across the actions they take compared to steps an agent would run just from it's instructions - this is helpful in anything you need full control and monitoring over 

This is essentially 'tool calling' in the Copilot Studio agent world.

How agent flows are used in my scenario

Agent flows give us consistent execution across processes and actions - and since we all know about the non-deterministic nature of LLMs by now, it's clear that many agents need this. For the 'technology architect agent' discussed in this series, if you read the the last article you might remember we were hitting issues trying to get the agent to do certain things:

• Issue 1 - agent was failing to create the Word proposal document as requested - which we said would include the technology recommendation, rationale, and licensing uplifts etc. required for this change
• Issue 2 - agent was failing to log it's output to a SharePoint list as requested - this is to give a simple audit trail of requests and corresponding recommendations

Agent flows are needed to fix this.

I created two flows, one for each sub-process:

Let's look at these one by one. 

Agent flow to create proposal document

The objective here is to:

• Creating a draft customer proposal containing all the details of the technology upgrade that the agent has determined - essentially, accelerate our consultants who would normally create such documents from scratch
• Ensure the document is on the Advania branded Word template 

So this is essentially "create a templated document and drop information into placeholders". There are a few ways to do this in Microsoft 365, and this agent flow effectively automates my chosen approach - I'm using a capability in SharePoint Premium/Syntex called Content Assembly, and this provides a handy Power Automate action. Here's the start of the flow in designer:

We'll go into this in more detail in the next post - Technique 4 - Leveraging Power Platform and Microsoft 365 capabilities in your agents. The key message is that to build effective low-code agents in the Microsoft world, you need a solid understanding of wider M365 building blocks and how these can be plugged into your agents - otherwise you'll hit limits of agent building and automation. 

To summarise here, the approach I'm using for templated document creation is a Microsoft Syntex/SharePoint Premium capability called Content Assembly. I've already done the setup work for this which involves:

• Creating a SharePoint list with columns for all the info pieces your document needs
• Creating a 'modern template' in SharePoint, where you upload your branded document and insert placeholders in the right locations for each piece of data to be dropped in

For full details of on this approach, see my article Automate creation of new documents with Syntex Content Assembly.

For my agent, the piece which does the magic is this item - the 'Generate document using Microsoft Syntex' action available in Power Automate and therefore agent flows. Individual blocks of text like the client name, requirement summary, proposed approach etc. are passed into this action for them to be dropped into the document:

 

 

What's happening here is that these pieces of data are being retrieved from a SharePoint list item and then passed into this action, and therefore the document. But that needs something to create the list item in the first place, and that's our agent itself - and specifically, it's my other agent flow which does that step. Let's look at that now.

Agent flow to create SharePoint list item with agent's output

To show what's happening here, let's start with the actual list that stores this data - here's a partial view of it:

The full list of columns is:

All of those items are dropped in by the agent. This is where we come to the important support that agent flows give in simplifying all this - "proactive slot filling". Because my agent flow has three clear input parameters, I can simply ask the agent to work out what to pass in from their names - and again, this is a place where descriptive naming and rich descriptions are absolutely critical for AI and agents, I named them carefully. To do this, in the Tools > Inputs area of my agent I use the "dynamically fill with AI" option for each parameter:

With the 'dynamically fill with AI' approach, the agent itself works out what to pass into each parameter based on their name and pieces of information it's already determined from the conversation. There's quite a bit to what's possible here and Microsoft document it at Implement slot-filling best practices - it's essentially NLU working with some pre-determined entities and the ability to define your own. What this means is you don't need to do the work of parsing out individual pieces of information from either the agent's earlier output or queries and prompts supplied by the end-user - this is AI running over the user/agent conversation so far and extracting what it thinks the right answers are likely to be. The alternative would be you doing this hard work and then passing in 'hard-coded' values to your flow parameters. Of course, the dynamic AI approach won't always work perfectly and it's an area of agent development that needs careful scenario testing using different types of data - and to say it one more time, good naming is critical of course or the AI has no chance.

So that covers how data gets passed in, and from there it's down to whatever steps you implement in your flow using all the standard Power Automate capabilities. As you can imagine, to create our SharePoint list item which then drives the proposal document creation I simply use the SharePoint connector's Create Item action:

Thus, we now have our automation chain of:

1. Architect asks the agent for a proposal on how the client's use case should be addressed
2. Agent uses it's data sources and reasoning to derive an approach that makes sense for this client (based on stated needs, technologies in play or suitable to adopt, licensing etc.)
3. Agent provides it's response
4. Agent calls tool (agent flow 1) to add SharePoint list item containing key elements of the response
5. Agent calls tool (agent flow 2) to create the Word proposal document on the Advania branded template using the SharePoint list item
6. Agent notifies user that it's done

We now have a fully working agent doing it's advanced reasoning and creating the draft proposal document for our architect to enhance and take forward to the client.

The result

Now that we codified exactly where and how to create proposal document (via the agent flows), we now have a document successfully dropped into my chosen SharePoint library:

The draft proposal has all the details of the agent's output and was created on our organisational template:

The next step is to start analysing and enhancing the agent's output - checking the reasoning, architectural and licensing guidance, and turning this into a polished client-ready proposal. But the heavy lifting of contemplating the requirement, embarking upon the research, considering different options, ensuring each granular requirement specified by the client is met, deriving any licensing considerations and uplifts, then structuring a draft proposal - all this is done.

A word on Express Mode for agent flows

A final thing to understand about agent flows is express mode. In Microsoft's framework, agent flows fail if they take longer than two minutes to execute - express mode is a way of opting-in to model giving faster execution times with some limitations, and it's for agent flows only rather than extending to Power Automate flows too. There are no additional costs or licensing implications, but the limitations need to be understood - more on this at https://learn.microsoft.com/en-us/microsoft-copilot-studio/agent-flow-express-mode

Summary

In this article, we focused on one of the most important ingredients for building dependable agents - giving them the right tools to perform precise, repeatable actions. In the Copilot Studio world, this is agent flows. While agents excel at reasoning and orchestrating conversations, they simply can’t execute structured operations (like updating systems, creating documents, or logging data) reliably without clearly defined, deterministic steps. I don't see this changing too much even as models and agent frameworks evolve over the next few years. 

We explored how agent flows act as the “hands” of your agent, wrapping complex processes into reliable Power Automate cloud flows. You get predictable execution, premium connector access, consistent handling of structured data, and better monitoring and governance. Using the architect proposal scenario, we walked through how two agent flows - one to log outputs into SharePoint and another to generate a branded proposal document - take the agent from being a conversational assistant  to providing real automation of the process. We also looked at how dynamic slot filling removes the need for brittle manual parsing, allowing the agent to intelligently map conversation data into flow inputs.

The result is an agent that not only reasons about a problem but also creates the tangible output - in this case, a ready‑to‑review customer proposal based on our branded Advania template. created from a SharePoint‑based template.

One aspect we didn’t dive into here is billing and capacity consumption, which becomes increasingly important as your agent ecosystem grows. That topic deserves its own space, and we’ll cover it in detail in the final article in this series.

Next article (coming soon)

Technique 4 - Leveraging Power Platform and Microsoft 365 capabilities in your agents