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

Autonomous agents - Technique 2: Define explicit steps in agent instructions when "reasoning the process" isn't appropriate

One of the main reasons AI agents are such a leap forward in automating work comes down to their ability to reason and dynamically plan in order to reach an outcome - which of course, is much like us humans intuitively do in our work. Apps and systems that we've developed over the past few decades have essentially all followed set processes with procedural code, and while many have flexible logic and business rules, today's AI models take us several levels beyond this. Ultimately we move away from a world of apps with explicitly coded steps to one where AI agents are often instructed with the end goal or outcome, but not necessarily a granular process of how to get there. So long as the agent is given the data, tools, and guidance to do this, it should have a good chance of meeting the outcome. Or that's the theory.

One of the biggest challenges today with autonomous agents is that they can have too much freedom and go off the rails from the intended task. We're not talking dystopian takeover, simply unpredictable agents with poor results and a lack of consistency. So, this post covers how to make your agent more reliable by finding the balance between autonomy and specific guidance - it all comes down to how you write the agent instructions. 

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 (this article)
5. Technique 3 - Provide tools like Agent Flows for steps the agent can’t easily handle
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
   
   

Some lessons learnt on agent instructions and autonomy

Going back to our Microsoft 365 architect agent used in this series (which automates some of our work at Advania by considering a business challenge and the client's tech landscape, then makes an architectural and product recommendation mapped to, here's how I started out with the instructions I gave to the agent. 

Poor agent instructions

The user will input a use case or business challenge. Using your knowledge of Microsoft 365 licensing and the client's environment and licensing, provide a recommendation of how a solution could be implemented using the available technologies. Generate a proposal outline to implement the solution - propose the technology(s) to be used, any licensing uplifts required which aren't currently in place or planned, and an overview of what the project would look like. Create a Word document containing the prompt and response. Also log the results to the SharePoint list in the "Syntex-AI-intelligence" site named "Technology proposals".

All seems quite reasonable and specific - I'm outlining specific goals and steps to take, and even being ultra-clear on where to find the SharePoint site to log the output to. However, let's take a look at the result:

 What's actually happening here is:

• The agent only runs one step - which is never going to work
• The agent is trying to determine the overall architectural solution simply from the first knowledge source (the m365maps.com site which provides info on Microsoft 365 products and SKUs 

I won't show the end output here to avoid confusing things, but the actual answer given by the agent is very low quality - it does say that Defender for Endpoint Plan 2 could be used (correct) as seen in the screenshot above, but the agent fails on several key things we want it to do: 

• There's no real consideration of the factors here, the agent appears to be doing some basic querying only. No basis for the recommendation is specified, and there's no evaluation of licensing uplifts which may be required (as asked for in the instructions)
• The agent didn't log it's results to the list as requested
• The agent didn't create the Word proposal document as requested

So, clearly this isn't working even if it has a hint of the right answer. 

Defining explicit steps in a numbered process

The reality is we need to be much more explicit with agents today - expecting them to be able to "reason the process" from a set of instructions often doesn't work and results will be unpredictable. In particular, where a process has steps that truly need to be followed in sequence - like fetching some data and then reasoning over it - the thing that makes the difference is specifying these steps in a numbered list. 

Here are my revised instructions:

Sequenced agent instructions

1. Derive the client organisation name from the user's prompt. If you are unsure of the organisation, ask the user for clarification. 
2. Derive the use case or business challenge the client is asking about from the user's prompt. If you are unsure of the use case, ask the user for clarification. 
3. Using the client name you already derived, use your knowledge sources to understand which technologies the organisation is licensed for. 
4. Now use your knowledge sources to ensure you understand the individual Microsoft products and sub-capabilities of these Microsoft 365 SKUs - build a categorised list for use in later steps. 
5. Using the data from the previous step, reason to provide a recommendation of Microsoft technologies which could meet the specific requirements. IMPORTANT - be extensive with the rationale for your decision, mapping how capabilities in the proposed Microsoft technology meet specific client requirements and detail this in your output. If no recommendation can be made (e.g. because the use case cannot be met with the licensed technologies), make a recommendation of which technologies could be purchased to help. As part of this reasoning, establish any licensing uplifts which may be required for this client to use the recommended technologies. ## Be sure to detail your chain of thought in the output ##
6. Also reason to establish any non-Microsoft technologies that could potentially be used to fulfil the requirement. 
7. Generate a proposal outline to implement the solution - propose the technology(s) to be used, any licensing uplifts required which aren't currently in place or planned, and an overview of what the project would look like to implement the Microsoft-based solution. 
8. Log the results to the SharePoint list in the "Syntex-AI-intelligence" site named "Technology proposals".
9. Create a Word document containing all details of client requirement and proposed solution - ensure to use the full reasoned output in the details. Save this to the SharePoint library in the "Syntex-AI-intelligence" site named "Technology proposal documents".

I've expanded on the detail of what I want in some places, but the other major change is switching to a numbered list to instruct the agent to follow those steps in order. Now let's look at the difference:

 

Looking at those images, straight away we can see the agent is now following many more steps - and if we drill into the two "Knowledge" steps as shown above, we can see the query used for each (and the results) now make sense:

• Advania client data - agent asks it what technologies the specific client is licensed for
• M365maps.com - agent uses this to discover what capabilities are in each granular Microsoft 365 SKU

This sets us on the path to success.

Results from the agent 

At this point we hope our agent will properly consider the client challenge provided to it (e.g. replace our endpoint protection, plan for a new intranet, introduce a compliance tool etc.) and then consider their technology environment and licensing, if anything provided in Microsoft 365 fits the bill - and then reason through all this to produce a technology recommendation, considering any licensing uplifts needed as well as adoption/migration considerations. Here was my prompt:

Unilever (fictional - remember I'm redacting real Advania client data with the top 20 UK companies), one of our clients, want to roll out a new endpoint protection technology to replace CrowdStrike to approximately 100,000 end-user devices. Ransomware protection is a key concern, and the RFP lists automated incident response and remediation, integrated threat intelligence, and sandboxing as required capabilities. 

Notably, they need coverage for 5,000 devices where users only have Microsoft 365 F1 licenses (frontline workers).

Here's the result:

Chris, here’s a complete recommendation and delivery outline for Unilever’s endpoint protection RFP.

Organization: Unilever

• Use case and business challenge inferred: Replace CrowdStrike across ~100,000 end-user devices.
• Must meet: strong ransomware protection, automated incident response and remediation, integrated threat intelligence, and sandboxing/detonation.
• Coverage gap to address: 5,000 devices used by Microsoft 365 F1 frontline workers.

What Unilever is licensed for today (from our records)

• User licensing: Majority on Microsoft 365 E3 with EMS add-on; ~15,000 on E5; ~10,000 Microsoft 365 F1 frontline licenses.
• Security stack in place: Entra ID P1, Microsoft Sentinel (Azure Sentinel).
• Endpoint and platforms: Endpoints managed with Intune; currently using CrowdStrike for endpoint protection; Mimecast for email; AVD and Citrix in use; Azure in UK/US/AUS regions.

Microsoft products and sub-capabilities relevant to this RFP (categorized)

• Endpoint protection and EDR
• Microsoft Defender for Endpoint Plan 1 (MDE P1): next‑gen AV, tamper protection, attack surface reduction (ASR), web content filtering, centralized management, cross‑platform support, “Block at First Sight.”
• Microsoft Defender for Endpoint Plan 2 (MDE P2): adds endpoint detection and response (EDR), threat analytics, vulnerability management (core), and longer searchable data retention; forms the endpoint pillar of Microsoft 365 Defender (XDR).
• Automated investigation and remediation (AIR)
• Microsoft 365 Defender suite provides AIR across workloads; Microsoft documentation highlights AIR in Defender for Office 365 Plan 2 (email) as an example capability within the suite.
• Threat intelligence
• Threat Analytics within MDE P2 delivers integrated intelligence and analyst‑ready reports that inform investigations.
• Sandboxing/detonation
• Endpoint: “Block at First Sight” uses rapid cloud evaluation and detonation for unknown files for preventative blocking on endpoints (P1+).
• Email/collab: Defender for Office 365 Plan 2 adds Safe Attachments (detonation sandbox) and Threat Explorer for campaign-level investigation.
• SIEM/SOAR
• Microsoft Sentinel already present for Unilever; integrates natively with Defender signals for advanced hunting/automation.
• Device and app management
• Microsoft Intune already in use for policy, configuration, and deployment orchestration.

Summary recommendation

• Standardise on Microsoft Defender for Endpoint Plan 2 across the Windows, macOS, Linux, Android, and iOS estate; manage deployment and policy via Intune; unify signals in Microsoft 365 Defender (XDR) and stream to Microsoft Sentinel for SIEM/SOAR.

Why this meets each RFP requirement

• Ransomware protection
• Prevent: Next‑gen AV, ASR rules, tamper protection, and “Block at First Sight” provide strong preventative controls on endpoints (P1 baseline).
• Detect and contain: MDE P2 adds behaviour‑based EDR with live response, threat analytics, and extended searchable telemetry to spot hands‑on‑keyboard activity and lateral movement quickly.
• Automated incident response and remediation
• MDE P2 enables automated investigation and remediation on endpoints to contain and fix threats (part of Microsoft 365 Defender’s AIR capabilities).
• Sentinel playbooks (Logic Apps) can orchestrate cross‑tool actions at scale (contain device, isolate network, reset credentials) using Defender incidents as triggers; Unilever already has Sentinel.
• Integrated threat intelligence
• Threat Analytics in MDE P2 provides curated intel mapped to current campaigns and exposures, tied directly to Unilever’s devices and vulnerabilities for prioritisation.
• Sandboxing/detonation
• Endpoint: Cloud‑based file analysis and “Block at First Sight” help pre‑empt execution of suspicious payloads on endpoints.
• Email: If Unilever later consolidates on Defender for Office 365 Plan 2, Safe Attachments detonates content pre‑delivery and contributes to unified incidents in Microsoft 365 Defender. 

How this fits Unilever’s current environment

• Intune is already the endpoint manager, making at‑scale onboarding, policy configuration (ASR, AV, EDR), and gradual CrowdStrike co‑existence/cutover straightforward.
• Sentinel is already deployed, so incident fusion, hunting queries, and automation can be turned on rapidly to cover both endpoint and other data sources.

Licensing path to enable the above

• Users currently on Microsoft 365 E5: MDE P2 rights are included; no uplift needed for those users.
• Users on Microsoft 365 E3 with EMS add‑on: add either the Microsoft 365 E5 Security add‑on (bundled security including MDE P2) or standalone Microsoft Defender for Endpoint Plan 2 licenses for those users. 
• Frontline worker devices on Microsoft 365 F1 (5,000 devices): options to cover endpoints with MDE P2
• Option A (preferred for feature parity): move these users to Microsoft 365 F3 and attach an appropriate security add‑on that grants MDE P2 (for example, an enterprise security add‑on akin to E5 Security for frontline) or assign standalone MDE P2 per user where permitted. Validate final SKU mix with Microsoft licensing because frontline bundles vary by agreement and commercial construct.
• Option B (kiosk/shared scenarios): if devices are truly shared and user‑based licensing is impractical, explore device‑based licensing options with Microsoft for MDE where applicable. Validate with the Microsoft account team to align with Unilever’s Enterprise Agreement terms.

Note: The SKU matrix shows where endpoint features and EDR/Threat Analytics land (P1 vs P2/E5 Security). Use this to ensure every user segment lands on P2 for EDR/AIR. 

Commercial and operational rationale

• Reduces agent sprawl by consolidating into the Microsoft stack Unilever already operates (Intune, Sentinel), lowering operational overhead and integration complexity.
• Meets or exceeds the specified capabilities with unified incidents, threat intel, and at‑scale automation, while improving mean time to detect/respond.

Non‑Microsoft alternatives that meet the specification (for RFP completeness)

• CrowdStrike Falcon Insight + Falcon X (sandbox) + Falcon Fusion for automation.
• SentinelOne Singularity Complete/Control with Storyline automation and rollback.
• Palo Alto Cortex XDR Pro + WildFire for detonation + XSOAR automation.
• Sophos Intercept X Advanced with XDR + Sophos Sandstorm.
• Trend Micro Apex One SaaS + Vision One XDR + detonation sandbox. 

Note: These all offer ransomware protection, automated response, TI, and detonation. The decisive factors will be agent footprint, integration with Intune/Sentinel, and TCO relative to Microsoft’s included rights.

Delivery proposal outline for Unilever

• Scope: Replace CrowdStrike with Microsoft Defender for Endpoint P2 on ~100,000 devices; ensure parity on ransomware protection, AIR, TI, and sandboxing; integrate with Microsoft 365 Defender and Sentinel.
• Phases and timeline (indicative)
• Readiness and design (3–4 weeks)
• Confirm license entitlements per segment; define co‑existence approach with CrowdStrike; finalize policies (AV/ASR/EDR), device groups, and ring strategy; connect Defender to Sentinel with required data connectors and analytics rules.
• Pilot (4–6 weeks, ~2,000 devices across key personas/regions)
• Deploy MDE sensor via Intune; validate protection efficacy, AIR behaviour, endpoint isolation, and SOC workflows; tune ASR/tamper protection; validate detonation/“Block at First Sight.”
• Scale‑out waves (8–12 weeks)
• Roll out by business unit/geo; enable EDR in block mode; progressively disable CrowdStrike on devices once Defender is in “active” mode and stable; expand Sentinel automations and hunting queries.
• Cutover and decommission (2–4 weeks)
• Remove CrowdStrike agent; finalize GPO/MDM baselines; confirm incident volumes, MTTR, and coverage; complete runbook documentation and knowledge transfer for SecOps/Endpoint teams.
• Hardening and optimization (ongoing)
• Leverage Threat Analytics and TVM to drive risk reduction; regular red/blue exercises; quarterly policy reviews; rationalize email sandboxing approach if consolidating on Defender for Office 365 Plan 2.

Architecture and integration highlights

• Intune for deployment/policy; Microsoft Defender for Endpoint P2 on endpoints; Microsoft 365 Defender for incident correlation; Microsoft Sentinel for SIEM/SOAR rules, hunting, and playbooks; integration to ServiceNow/Jira for ticketing as needed.

Roles and responsibilities

• Our team: solution design, pilot, deployment tooling, Sentinel content and automation, change and cutover runbooks, training.
• Unilever: environment access, pilot cohort sponsorship, change approvals, SOC/process owners, endpoint engineering partnership.

SharePoint list logging (Technology proposals)

• Action prepared: Log the proposal to Syntex-AI-intelligence > Technology proposals with fields: Client=Unilever; Use case=Endpoint protection replacement; Scope=100k devices; Key requirements=ransomware, AIR, TI, sandboxing; Recommendation=MDE P2 + M365 Defender + Sentinel; Licensing notes=E5 covered; E3 add E5 Security or MDE P2; F1 coverage options; Status=Proposed; Next steps=Pilot planning.
• Limitation: I don’t currently have write access via this interface to post to your SharePoint list. If you can grant me access or confirm the list URL and credentials, I will submit this entry immediately on your behalf.

Word document creation (Technology proposal documents)

• Action prepared: Generate a Word document containing this full recommendation, capability mapping, licensing options, and delivery plan, and save to Syntex-AI-intelligence > Technology proposal documents with a filename like “Unilever – Endpoint Protection Replacement – Proposal.docx.”
• Limitation: I don’t have write access to create/save documents to your SharePoint library from here. If you share a drop‑off library URL or grant permissions, I’ll create and upload the document automatically; alternatively I can send you the .docx for you to place.

Key decisions for you

• Confirm the preferred licensing path:
• E3 population: E5 Security add‑on vs standalone MDE P2.
• F1 population (5,000 devices): upgrade to F3 + security add‑on vs assign standalone MDE P2 to those users; validate final SKU choices with Microsoft licensing to align with Unilever’s agreement.
• Confirm pilot cohorts and target start date so we can mobilise.

Citations used: [list of citations]

Phew! The results are amazing when you think about it - the agent has considered all the factors and showed a level of understanding equal to a highly experienced and capable Microsoft security specialist. We even see that the agent has done what was asked in terms of mapping specific requirements given by the client (e.g. automated incident response and remediation, integrated threat intelligence, and sandboxing in this case) to product features in the proposed solution, Defender for Endpoint. 

We do still have two issues though - as the two "limitation" notes in the agent's response call out, the agent wasn't able to:

• Log the output to the SharePoint list as requested
• Create the Word proposal document as requested

So, we're not done yet - we'll come to these resolutions in the next article. 

In terms of the cognitive work the agent has successfully performed, at Advania we don't see this as replacing our high-end architects - but we do see it as accelerating our teams and allowing more junior members of the team to take on more complex work. The work partly switches to verification, judgement, editing where required, and rounding out and adding perspective - all elements which would have been required anyway. Having the agent take on some of the complex research, interpretation, and generation is huge though of course - we really are democratising intelligence and expertise and therefore moving faster and serving more.  

Summary

Autonomous agents will transform work over the next few years but their effectiveness depends on how we guide them, and instruction design matters. Simply stating an end goal and the outline of a process is unrealistic, at least today - instead, breaking instructions into clear, sequenced steps (probably using numbered bullets as I've shown in this article) is needed to get reliable agent behaviour. It's a question of balancing autonomy with control, and human oversight and verification is crucial of course.   

The next article will resolve those pesky challenges of the agent not being able to create Word documents to accelerate that part of the process and the team's work.

Next article

Technique 3: Provide tools like Agent Flows for steps the agent can’t easily handle

Autonomous agents - Technique 1: Getting AI-suitable descriptions right - data, tools, agents themselves

As I opened with in the first article in this series, AI agents are the next generation of solution we'll build for the next few years - this is how work gets automated, at least some of it. Business systems which take away some of the human processing so we can focus on more impactful work, powered by highly-capable LLMs with the ability to consume data, reason and plan, and use tools like web browsers. In this series we focus on agent-building techniques, and in particular what it takes to build autonomous agents successfully i.e. that ability for an agent to dynamically reason and plan. Guidance here orients around Microsoft Copilot Studio agents, though it's interesting to reflect that many of the techniques will apply across nearly all AI agent platforms. 

In this article, we focus on descriptions - in the context of AI agents, this means for data, tools, sub-processes and other things the agent might use to get to it's goal. It's interesting because descriptions have been pretty innocuous in apps/solutions/automations we've built over the last few decades, because much like comments in code, only humans read them. However, things are very different when AI is reading them and making decisions about how to process based on the words provided.

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 (this article)
4. Technique 2 - Define explicit steps in agent instructions when "reasoning the process" isn't appropriate
5. Technique 3 - Provide tools like Agent Flows for steps the agent can’t easily handle
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

Descriptions - why they're suddenly vital

Despite all the advances in the underlying AI models, AI agents are not magic and they need help. This is especially the case when:

• Agents have some autonomy in terms of getting to an outcome (rather than being defined step-by-step, like a coded application)
• Agents can use data and knowledge sources
• Agents can call on tools and sub-processes
• Agents can call other agents (if they understand what they do)

AI needs good descriptions more than humans do

The critical point is that AI agents use descriptions to understand what data to use and when, what tools to call and when, and what sub-processes to run and when. If your descriptions are poor and don't supply enough context, the behaviour of your agent will be unpredictable and won't be as expected.

 

As an example which may hit many agent builders, many agents fail or behave unpredictably because they don’t understand what their knowledge sources or tools are for. This often happens when default or auto-generated descriptions are used — they’re vague, generic, and unhelpful. For example, if you provide a file as a knowledge source for your agent, Copilot Studio will helpfully use AI to generate a description of the a file - but this will essentially be "this knowledge source uses this file" - so when I provide a detailed Excel file of Microsoft 365 license SKUs and capabilities (from the excellent M365maps.com), the descriptions generated today do nothing to help the agent understand what this knowledge represents and how it could be used:

The Fix:

Write clear, detailed descriptions for every knowledge source, tool, and even the agent itself (to support agent-to-agent interactions in the future). These descriptions are used by the orchestration engine to decide what to use and when. 

Let's focus on a knowledge source (i.e. some data used by an agent) in Copilot Studio. In the agent I'm using in this series, one knowledge source is an Excel export of 'technology landscape' data for key Advania clients (redacted for the video in the last post). 

Bad example (this is the default description generated by Copilot Studio):

“This knowledge source searches information contained in Microsoft license coverage by client.xlsx.”

Good example:

Instead, a far better description helps the agent understand what's in the data/knowledge - for example: 

“This knowledge source details the technologies, plans, and current Microsoft licensing in place for key Advania clients. It covers aspects like how many Microsoft 365 E3 and E5 licenses are held, and which technologies are used for Security & Compliance, messaging, endpoint protection, and document management.”

The agent can now understand exactly what's in this data and how it can be used. This context is essential for establishing how it should go about the process and what to use when.

Agent behaviour with poor knowledge descriptions

Before data and knowledge sources are given good descriptions (rather than the AI-generated ones from Copilot Studio), you'll find all sorts of strange behaviours. Things may look good at first because you see the agent referencing the sources:

However, dig deeper and you'll find some sources simply aren't used in the agent's processing:

In fact, what we see is the agent simply referenced one knowledge source and then stopped there - it didn't actually consider the use case it was given or do any kind of reasoning, and while it gives a response that looks rich at first glance, in fact the agent is simply trotting out some generic info related to Microsoft 365 products. We see some of this in the activity map in Copilot Studio which shows what happened when the agent ran:

Agent behaviour with good knowledge descriptions

Fix the descriptions, and suddenly the agent knows how to consider each knowledge source - if we ask the same question to the agent, we see that BOTH knowledge sources are now used. Firstly the agent queries the "Microsoft 365 license SKU matrix" source to consider endpoint protection options:

Next, the agent starts a specific query on Microsoft 365 F1 licensing, which makes sense given this client is referenced in the client data knowledge source as having this restriction for some employees:

Better - but still not right

On the surface, it seems that the agent is coming closer to it's purpose - being an effective tech architect with deep Microsoft knowledge. However, if the agent's final responses are closely analysed at this point we see that:

• Unfortunately, the agent isn't truly considering the passed client requirement (as per the demo video shown in the previous article, I'm asking it to consider a particular client's need to replace endpoint protection along with some granular requirements). Instead, I'm still getting some 'lightweight consideration' and generic Microsoft 365 product info at best
• The agent is also not delivering on another element - I'm not getting a draft proposal document generated, although I'm asking for that in the agent instructions

So in short, the agent is now using data and it's knowledge sources in a more sensible way, but the overall process being followed isn't what we need. We need a step-by-step consideration of the client's need and the granular requirements specific, any Microsoft 365 products or capabilities which might meet these needs, a lookup and consideration of the technologies the client is currently licensed for, and then a genuinely thought through recommendation based on all the above. I won't show the agent output at this stage to avoid confusing things, but suffice to say we have an agent at "first day intern" level at the moment and for this to be valuable we need a lot more cognitive processing.

On to the next challenge - getting agent instructions right

Now our agent understands the data and knowledge it has access to more clearly, we need to turn our attention to how the agent is guided in the instructions we give. If we make some changes here, the agent will go through a step-by-step process and reason over the key questions being asked of it much more effectively. Which leads us to the next article in this series:

Next article

Technique 2 - Define explicit steps in agent instructions when "reasoning the process" isn't appropriate - coming soon

Demo video - Microsoft architect autonomous agent (Copilot Studio)

In the previous article in this series on autonomous agents, we talked about what makes an agent autonomous and some implementation fundamentals specific to Copilot Studio. As with anything AI, seeing an example in context goes a long way to helping understand the possibilities, so this second post provides a video of a real autonomous agent we're starting to use at Advania. The agent effectively becomes a member of our team, using advanced reasoning models to work with complex concepts and accelerate our work. Before that, here's a reminder of what this series looks like:

Articles in this series

1. Techniques for autonomous agents in Copilot Studio - intro
2. Scenario video - Microsoft architect with proposal generation (this article)
3. Technique 1 - Getting AI-suitable descriptions right (for data sources, tools, and agents themselves)
4. Technique 2 - Define explicit steps in agent instructions when "reasoning the process" isn't appropriate
5. Technique 3 - Provide tools like Agent Flows for steps the agent can’t easily handle
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

Use case for this agent

If you follow me on LinkedIn you may have seen me post about this agent there. We built this agent to automate some of our work at Advania, in particular some of the complex Microsoft architecture and technology consultancy work we deliver to clients. The scenario is essentially an 'expert Microsoft architect' agent which understands:

➡️ The various technology estates of key Advania clients and what they have licensed - the agent sources this from an internal system we have
➡️ Microsoft 365 product SKUs and licensing, specifically E3/E5 suites and granular capabilities in sub-products like Defender for Endpoint, Defender for Identity etc. - the agent uses the excellent m365maps.com website for this
➡️ How to take a specific client requirement (e.g. a need to roll out a new endpoint protection technology/automate a legal process/reach frontline workers with corporate comms etc.), derive any "strong fit" Microsoft technologies, and map granular requirements specified by the client to product capabilities to support the proposed approach

The video shows:

✅ A quick overview of the agent definition (built in Copilot Studio)
✅ Data sources the agent has access to
✅ The agent reasoning through the supplied use case for one fictional client (Ecosphere Solutions)
✅ Proposed approach with clear rationale - including licensing considerations, implementation details, and how specific requirements are met by the proposed technology
✅ Proposal drafted on company-branded template

Demo video

Reflection on AI agents like this

The power of agents is that they can act as a virtual team member, automating some of the workload and enabling human effort to go to higher order challenges. The interesting thing about this agent in my view is the ability to perform advanced reasoning - thinking through the client's need, the technologies they have access to, exactly what's provided in those, and deriving a good fit if there is one. 

Of course, we don't see the AI agent as replacing Advania architects and consultants much-loved by our clients - this is an accelerant for our teams, not a replacement. But we do see agents like this as helping us deliver more value to clients - bolstering our expertise and helping us respond faster with the accuracy and depth we're known for. It also helps us level-up less experienced consultants or new members to a team. In reality, every business has complex processes and expertise that today's AI agents can unlock - this is an example of what makes sense for us.

Next article

Technique 1 - Getting AI-suitable descriptions right (data, tools, agents themselves)

Techniques for autonomous agents in Copilot Studio - blog series part 1

AI agents are the next generation of solution we'll build for the next few years - it's clear that many "app front-end plus data" business systems will evolve to be more agentic, in the sense that the application itself will automate more of the processing, and interfaces become less about forms and more about instructing the AI in natural language. Autonomous agents are one of the most exciting aspects because software and apps simply didn't have this possibility until now, and I don't think there's much conjecture this is a key 'unlock' in terms of how work gets automated and more efficient and AI starts to have the impact on societies and economies. With advanced LLMs and protocols for bringing agents and systems together, we now have the tools to build agents that can reason, act, and deliver outcomes — not just respond to prompts. But with this power comes complexity, and I see many approaching agents with expectations that don’t align with today's capabilities. 

This blog article is the first in a series which walks through five key techniques for building effective autonomous agents in Copilot Studio. Each article highlights a common pitfall, explains the underlying concept, and offers practical guidance to help you succeed. Whether you're building agents for internal automation, customer-facing scenarios, or domain-specific copilots, these lessons will help you avoid the traps and unlock the full potential of generative orchestration.

Scenario - an autonomous reasoning agent for Microsoft 365 architecture recommendations

Throughout this series I'll reference an agent I built which acts like one of our most experienced Microsoft architecture consultants at Advania - able to understand the full suite of security and productivity capabilities in Microsoft 365 E3 and E5, consider licensing needs and SKU packaging, and make technology recommendations for a given use case based on a deep understanding of the factors. The next article in the series shows a demo video so you can see the agent "thinking through" the scenario, automating the recommendation process through deep reasoning, and drafting a project proposal on a company templated document - a process which can take hours or days for an experienced architect. This is about accelerating that role, improving accuracy, and levelling-up less experienced architects so their thought process and outputs match those of the most experienced. 

Something we'll focus on in this initial article is that agents aren't autonomous by default in Copilot Studio - the agent has to be built with specific settings enabled and certain keywords used in agent instructions. This post covers these fundamentals, because using all right techniques won't get you anywhere if the agent isn't set up to behave autonomously - but we'll also start by explaining what we mean by "autonomy" so you understand where we're heading and what such an agent can do. 

What makes an agent autonomous?

There are lots of definitions of this, but I boil it down to four elements - I used this slide in a conference talk recently (at the 2025 European Power Platform Conference):

Importantly, in Copilot Studio some of this is made possible by "generative orchestration" - this isn't enabled by default, but if you want dynamic behaviour you need to toggle this to on in your agent settings:

Unlike classic orchestration (where you define every topic and response), generative orchestration allows the agent to decide how to use its knowledge, tools, and topics to fulfil a request. It’s powerful — but it also means you need to design your agent carefully to guide that autonomy.

So in Copilot Studio you essentially have two modes, where "classic" is the old mode and generative is the new possibility:

If you look at most other AI agent and virtual assistant platforms which have been around for a while (e.g. ServiceNow, Salesforce, Google), all have evolved from this classic "define each and every step of what a user might ask and how the bot/agent should respond" approach to something like generative orchestration where the LLM is essentially deciding how to behave and have the conversation with the user.  

 

For Copilot Studio, Microsoft has a useful table on the Orchestrate agent behavior with generative AI page which goes into more detail on specific behaviour differences:

 

Enabling reasoning in Copilot Studio agents

In the first image above, we discussed that a key element of autonomy is the "able to reason and plan" aspect. To be able to use reasoning in your agent, this also needs to be enabled in your agent settings (within the 'Generative AI' section) and is only possible if you're using generative orchestration. The settings are bundled together in the same area:

As highlighted in the small text in the blue box, the other critical thing is to use the "reason" keyword specifically in your agent instructions. This tells Copilot Studio to use a reasoning model (e.g. currently OpenAI o1 at the time of writing) rather than a standard LLM, and this won't happen if you describe it in other words.

Here's an example of the reason keyword being used in agent instructions - in this case, an agent I built where this is one of the agent steps to complete: 

5. Using the data from the previous step, reason to provide a recommendation of how a solution could be implemented using the available technologies. As part of this reasoning, establish any licensing uplifts which may be required for this client to use the recommended technologies. IMPORTANT - be extensive with the rationale for your decision, detailing how capabilities in the proposed technology meet specific requirements.

I'll show this agent in action through this article series. As you can imagine, the instruction above tells the agent to use a reasoning model for this step in order to derive the recommendation I'm asking for - that's important, because we're asking for "thinking" rather than more standard LLM processing. 

Agents need help

If not clear already, what we're really saying in this series is that agents need help - the work these days is preparing data, creating tools and sub-processes for agents to call into, and refining natural language descriptions and instructions until an agent behaves in the way you want. This is a new form of coding in some ways, but it doesn't all happen magically - understanding the critical techniques is key.

Articles in this series

1. Techniques for autonomous agents in Copilot Studio - intro (this article)
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 like Agent Flows for steps the agent can’t easily handle
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

Next article

Scenario video - Microsoft architect with proposal generation

My AI conference talks in early 2025 - autonomous agents, SharePoint agents, and AI choices

As we come into conference season in late spring/early summer 2025, I’m honoured to be speaking at Europe’s biggest events in the Microsoft space on AI topics that I’m super passionate about. The events are coming up fast, and as any conference speaker will tell you, preparing for talks on cutting-edge AI technologies which are in preview and changing from week to week in the run-up is easily the most fun way to spend your evenings and weekends 😊 Like many others, I wouldn’t change it for anything though of course – all part of the fun.

In case you’re interested, here’s a quick view on what I’ll be covering. Both events provide a great platform to delve into the latest advancements, network with Microsoft AI implementers, and gain valuable knowledge.

European Collaboration Summit 2025

The first event on my calendar is the European Collaboration Summit 2025, scheduled for May 26-28 in Düsseldorf, Germany. This is the largest Microsoft-focused event in Europe by attendee count (around 3,000), with a great line-up of sessions, workshops, expos, and networking opportunities. I have two talks here:

Understanding Microsoft AI options – comparing Microsoft 365 Copilot, Copilot Studio agents, SharePoint agents, and building on Azure OpenAI

Navigating the Microsoft AI landscape and making good choices is complex. There are many aspects to consider including the focus of different options, AI capabilities, consumption or licensing costs, possible data integrations, user experience factors, boundaries and limitations, potential to automate business processes and more. Crafting an appropriate AI strategy with even just these options (and nothing outside of Microsoft) is certainly not trivial for most businesses:

We’ll explore the respective strengths and implications of each of these options, hopefully delving into some aspects you may not have considered. My other talk at ECS 2025 is:

Copilot agents in SharePoint - understanding AI capabilities, governance, costs, and more

SharePoint agents are so far one of the lesser-known parts of Microsoft’s AI story but could revolutionise how we work with documents forever. After all, SharePoint is the platform which stores the world’s documents and collectively we add 2 billion documents there per day. Something has to change in how interact with this information, and with generative AI being woven into SharePoint in this way, SharePoint agents are absolutely part of the answer.

This talk will focus on understanding the AI capabilities within SharePoint, including governance, costs, and other important factors. We will examine how Copilot agents can enhance your SharePoint experience and what to keep in mind while leveraging these powerful tools.

Conference link: https://collabsummit.eu/

European Power Platform Conference 2025

Following the European Collaboration Summit, I will be heading to Vienna in June for the European Power Platform Conference 2025 (the event is June 16-19 specifically). With the Power Platform’s new role as a core pillar in Microsoft's AI strategy, particularly in terms of Copilot Studio agents, this is a great time for an event with this focus. I’ll be presenting on:

Techniques for Autonomous Agents (Copilot Studio)

It’s certainly fair to say there’s a lot of noise around autonomous agents - and as many apps and automations essentially evolve to be agents - generative AI can absolutely simplify how solutions are defined and implemented, where it’s no longer necessary to specify every last line of code or step in a process. With enough guidance on the outcome you're trying to achieve, AI can often plan the actions required and the specific tasks to execute. It's a new world now!

But can you really say "follow up on each marketing lead by sending a personalised e-mail to the client and update our back-end systems appropriately" and AI magically does all the right things? Where are the boundaries? How autonomous can autonomous agents be? In this session we'll show the top techniques for success, and where you need to draw the line between instructions and specific items for your agent to call.

Conference link: https://www.sharepointeurope.com/european-power-platform-conference/

Summary

These conferences offer a fantastic opportunity to immerse yourself in the latest AI developments, learn from experts, and network with like-minded professionals. As far as I know, some tickets are still available for both events at the time of writing (early May 2025), so it’s not too late if you want to take the opportunity. I’m excited to be part of these events – very much looking forward to some great conversations, sharing some insights, and learning a lot myself from the incredible sessions and discussions.

Hopefully see you at one of them!

Copilot Studio agent cost calculator - a tool to help forecast costs

Agents are forming a big part of AI these days, bringing the promise of highly-capable assistants with gen AI intelligence and the ability to use tools, data, and apps in multi-step processes. One of Microsoft's big moves recently is to allow agents to be used in the free version of Copilot (Microsoft 365 Copilot chat) by any employee with a Microsoft 365 license - in other words, no need for the circa $30/£23 per user per month "full fat" Microsoft 365 Copilot license. In this approach, the AI usage is simply charged based on consumption in a Pay As You Go manner, thus avoiding the need to license the entire organisation with Microsoft 365 Copilot. This is interesting because it starts to make AI very useful (e.g. by having it understand company data and documents) without committing to the $30/£23 per user per month cost of M365 Copilot. 

But how much do you pay? In the Microsoft world, Copilot Studio agents will be the most popular since they can be created by business users without code - arguably it's a new form of Power Apps, but exposed prominently to all Microsoft 365 users. Other types of agents can be created in the Microsoft world - including declarative agents and custom engine agents - but these typically require pro developers and a more specialist skillset. We're focused on Copilot Studio agents in this article due to their likely popularity. As usual with AI, it pays to understand what costs are likely to be ahead of time - also as usual, the devil is in the detail and there are some surprises. In this post I share an Excel calculator which can help you forecast costs and outline some of the considerations.

Agent costs - and the relationship with Microsoft 365 Copilot

To avoid doubling up of costs, agents are largely free for any employees licensed with Microsoft 365 Copilot - you're already paying for full Copilot license for these folks after all, so most agent actions are free for these users. Not all actions however - here's a summary:

• Users without a M365 Copilot license - all actions within an agent count as 'consumption'
• Users with a M365 Copilot license - most actions are free, but the exception is 'autonomous actions' which use generative AI to make decisions on how to process

So even before we get to the detail, that's a wrinkle which adds some complexity to predicting costs. Will you (or the business) create agents which rely on autonomous actions? That's hard to say without getting close to use cases and agent design. Unfortunately there's no way to prevent this type of action being used, so even if your organisation licenses lots of users with full M365 Copilot you may still incur AI agent costs. See my footnote at the bottom of this article for more on this.  

For the purposes of simplicity, this article (and the linked Excel calculator) will focus on forecasting costs for users without a M365 Copilot license - in other words, the "free Microsoft 365 Copilot chat + Copilot Studio agents" combo. Lots of organisations are interested in this since organisational use cases get unlocked, potentially with a simpler investment case. If your organisation has lots of M365 Copilot licensed users and you think agents using autonomous actions will be created by the business (there's no way to stop this currently), layering in these additional costs onto my Excel would certainly be possible. 

Before we get to costs, let's think about agent flavours.

Types of agent and surface points 

There are lots of ways of categorising agents, but this classification based on what the agent is primarily there for is helpful:

A retrieval agent could help employees find answers from key documents or a knowledge base, whereas at the other end of the spectrum an autonomous agent could be tasked with competitor research and proposing new service lines for a company. At that level of complexity there's lots to think about of course, but it does illustrate the range of agents that can exist. The above capabilities can obviously be combined, and some agents will use all three elements of retrieval, task completion, and autonomy within a process.

In terms of surface points and user experience, Copilot Studio agents can be used to:

• Provide a standalone agent experience - for example, an employee onboarding agent embedded in a HR site or in Teams
• Extend Microsoft 365 Copilot - for example, to tailor behaviour so that questions about company policies are sourced from the HR handbook only

Both of those examples are essentially retrieval agents. 

Copilot Studio pricing and message burn rates 

Copilot Studio agent usage is charged in 'messages' based on complexity of the action. You have two ways of paying for these:

• Pay As You Go - no upfront commitment, $0.01 per message 
• Buy a message pack - 25,000 messages per month, also $0.01 per message

Regardless of how you pay, the key element is the 'burn rate' of different actions your agents may use. Microsoft publish the table below to explain how different agent actions consume messages - remember from the earlier note, employees without a Copilot license will be charged for all actions in this list, and even employees with a full M365 Copilot license will incur costs if autonomous actions are used:

April 2025 pricing update

Microsoft announced some significant price decreases for certain agent actions listed below - for example, 'tenant graph grounding' decreased from counting as 30 messages to 10. All of the info in this post and the linked Excel calculator has been updated with these changes.

 

So, there's no way around needing to understand (or guess) what your agents may do. To simplify things, one approach is to imagine a typical agent and the combination of actions it performs, then multiply it by how many such agents you anticipate the business to use. 

Let's look at some scenarios.

Calculating agent costs

We need some quick assumptions. I'm assuming that a typical conversation an employee has with an agent will perform:

• 3 info lookups, known as tenant graph grounding (i.e. to get the info from Microsoft 365,  whether that's a knowledge base, site, or set of documents, to answer the prompt/question)
• 4 usages of generative AI (i.e. to generate the response text)

You might disagree with these averages, but they are all editable in the calculator. My logic is that most conversations with AI are not single shot - it's common to ask a follow-up question, and if we say that happens around 3 times in a typical conversation I believe that's about right. We also need to consider how many conversations per day - in these default calculations, I go for 30 per day. Again, that could be highly variable for you (e.g. based on size of company, how many employees the agent is relevant to etc.) - all editable in the calculator, but I think 30 is reasonable for a useful agent in a medium/large business. 

Scenario 1 - 10 agents, 30 conversations per day

This scenario gives an annual cost of $30,096:

Scenario 2 - 30 agents, 30 conversations per day

"But Chris, we're probably not going to end up with just 10 agents across our entire business - it would be more than that in time." I'm hearing this frequently, so let's model that - costs obviously multiply by 3, giving a yearly total of $90,288:

Both of these costs typically come as a surprise. We can debate exactly what the right parameters should be for each business (and we should, because the inputs used will influence the costs heavily) - but clearly there is something significant to perform diligence on here, and I think it may not be apparent to most. Anyone thinking of using agents without "full" Copilot licensing across the board should be looking at this closely - but it won't necessarily come through in the Microsoft documentation, you need to do your own modelling.

Accessing the calculator

The calculator is a simple Excel file available for download here:

   Link to calculator

Closing thoughts 

The combo of "minimal M365 Copilot licensing + agents" is quite alluring for organisations where rolling out M365 Copilot to all employees doesn't fit, or those simply struggling with the business case. However, this alternative to full Copilot may not be as cost effective as anticipated - and for their part, Microsoft are clearly hoping that it can work as an on-ramp and tip organisations into making a more substantial investment in their premier AI tool. If not, that's probably fine too because revenue from PAYG usage may be just as beneficial and potentially carry a higher margin. I wouldn't say there's anything too cynical or mercenary from Microsoft here - every major SaaS vendor has a degree of PAYG pricing for AI consumption in their platform, since it brings flexibility and the avoidance of an upfront commitment.

Will agents drive more organisations to license M365 Copilot more broadly? I'd say yes - after all, once agents are in use and departments, teams, and individuals are all using them to get work done, good luck taking them away! Few leaders will be able to do that easily if agents are delivering the gen AI promise.

It also won't be easy to calculate the exact tipping point where it becomes worthwhile to switch to M365 Copilot licensing - that will all depend on your agent usage and number of employees being considered for licenses. Being able to implement cross-charging for AI consumption will also grow in importance, though for some businesses a cost will be a cost wherever it lands.

As ever, AI continues to raise complexities that need expertise on the team (whether in-house or with a partner) to help navigate the choices. This new world of "AI FinOps" is just one part of it - but there's no doubt organisations are realising gains from AI now, so the bigger long-term risk may come from not seeking to master these factors.

References:

• Copilot Studio licensing - Microsoft Copilot Studio
• Manage message capacity - Microsoft Copilot Studio

Footnote - M365 Copilot licensed users and autonomous actions in agents

I highlight in the article that even M365 Copilot licensed users are charged for autonomous actions in agents, though every other action type is free. I derive this from the Microsoft documentation where autonomous actions is omitted from the list of actions free for these users:

From Copilot Studio licensing - Microsoft Copilot Studio: