Back to catalog

Season 7 15 Episodes 52 min 2026

Microsoft Copilot Studio

2026 Edition. A technical deep dive into Microsoft Copilot Studio, covering generative orchestration, agent flows, tools, enterprise grounding, and more (2026).

AI/ML Frameworks LLM Orchestration Visual Prototyping

🌐 English 🇪🇸 Español 🇫🇷 Français 🇵🇹 Português 🇮🇹 Italiano 🇵🇱 Polski 🇩🇪 Deutsch 🇷🇴 Română

Now Playing

Click play to start

0:00

Generative Orchestration

Discover the paradigm shift from classic trigger phrases to Generative Orchestration in Microsoft Copilot Studio. Learn how AI dynamically selects topics and tools based on descriptions, entirely eliminating the need for rigid conversational mapping. This episode explains how intelligent routing handles multi-intent queries effortlessly.

3m 22s

AI-Based Agent Authoring

Learn how to use natural language to accelerate your bot building process. We explore AI-based agent authoring, allowing you to generate complex topics, prompts, and flows simply by describing them. Understand how LLMs are used at build-time to rapidly prototype agents.

3m 21s

Topics and Nodes

Dive into the structural anatomy of an agent. This episode breaks down System versus Custom topics, and the deterministic node logic required for specific business rules. Learn how to map out precise conversational paths using variables and conditions.

3m 28s

State and Variables

Give your agent a memory. Discover how to work with variables in Copilot Studio to pass context between topics, eliminating repetitive questions. We also explore using environment variables for securely storing Azure Key Vault secrets.

3m 39s

Entities and Slot Filling

Extract structured data from unstructured natural language. This episode explains prebuilt entities, custom closed lists, regex entities, and the magic of proactive slot filling, which allows the AI to skip questions when the user provides information upfront.

3m 53s

Enterprise Knowledge Grounding

Turn your existing enterprise data into a conversational expert. Learn how to connect SharePoint, Dataverse, and public websites as knowledge sources for Generative Answers. Discover the limits and capabilities of grounding your AI.

3m 47s

Tenant Graph Grounding

Unleash the full power of Microsoft Graph and semantic search for high-precision retrieval. This episode explores Tenant Graph Grounding, utilizing Microsoft 365 Copilot licenses to search massive enterprise documents with deep semantic understanding.

3m 37s

Prompt Tools

Empower your agent to perform specific data processing or summarization tasks on the fly. Learn how to craft Prompt Tools, define templates, specify inputs, and set response formats directly within Copilot Studio.

3m 31s

Agent Flows

Bridge Copilot Studio with complex, multi-step backend automations using Agent Flows. This episode details how to add Power Automate flows as tools, emphasizing the critical 100-second execution limit and synchronous response requirements.

3m 39s

Power Platform Connectors

Tap into thousands of existing APIs across the Microsoft and third-party ecosystems. Discover how to use Power Platform Connectors as active tools in your Copilot Studio agents to interact with external services effortlessly.

3m 37s

The Computer Use Tool

Automate legacy systems that lack APIs using vision-based automation. Discover the preview Computer Use tool, which leverages models like Claude Sonnet 4.5 to interact with graphical user interfaces via a virtual mouse and keyboard, complete with enterprise security guardrails.

3m 31s

User Authentication

Secure your agent and unlock personalized experiences. Dive deep into User Authentication in Copilot Studio, comparing 'Authenticate with Microsoft' against Manual OAuth2 setups. Learn how to configure scopes and ensure least privilege access.

3m 16s

Voice and IVR

Take your agent off the keyboard and onto the phone line. Discover the Interactive Voice Response (IVR) capabilities of Copilot Studio. Learn about speech recognition, DTMF (keypad inputs), barge-in, and customizing agent voices with SSML.

3m 43s

Agent Analytics

You can't improve what you don't measure. This episode breaks down the Analytics dashboard in Copilot Studio, explaining the hybrid view for conversational vs autonomous sessions, and how to export transcripts for deep analysis.

3m 03s

Model Context Protocol

Future-proof your agents with the open standard for AI context. Learn how to integrate Copilot Studio with external Model Context Protocol (MCP) servers to ingest Resources, Tools, and Prompts dynamically.

3m 28s

Episodes

Generative Orchestration

3m 22s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 1 of 15. Most bot builders spend hours trying to predict and map every possible phrase a user might type. You add fifty variations of a support request, and the system still fails when someone types a phrase you did not anticipate. Generative Orchestration completely eliminates that need by using dynamic description matching. Often, when people hear the word generative in this context, they assume it means generating conversational text. That is not the case here. Generative Orchestration is strictly about dynamic routing and tool selection. It is the intelligence that decides which action to take, rather than just writing a response. In classic orchestration, you build a topic and manually define a list of trigger phrases. The natural language understanding engine relies on those exact phrases to route the user. Generative Orchestration removes trigger phrases entirely. Instead, you write a clear, plain-text description for each topic and tool in your agent. The underlying large language model reads the user query, evaluates all your available descriptions, and dynamically determines the best match. You are no longer mapping inputs to triggers. You are simply describing what your tools do. This completely changes how an agent handles complex inputs. Consider a user who asks: What is the weather in Seattle and when does the store open? In a classic setup, this breaks. The system detects two conflicting intents and either guesses one or throws a fallback error. Generative Orchestration handles it effortlessly. The model parses the entire sentence and recognizes two distinct goals. It scans your descriptions. First, it finds a weather tool. It extracts Seattle from the user query, passes it to the weather tool as an input parameter, and executes it. Then, it remembers the second half of the user prompt. It scans your topics again, finds the one described as handling store business hours, and triggers it. Here is the key insight. The agent chains these actions together automatically. It handles the weather request, then seamlessly transitions into the store hours topic, combining the outcomes. You do not write any routing logic or transition code to make this happen. This shift means the quality of your agent now depends entirely on the quality of your descriptions. If your weather tool description simply says weather, the model might struggle to route accurately. If the description says retrieves current weather conditions for a specified city name, the routing becomes exact. Furthermore, if a user triggers that weather tool but forgets to specify the city, the generative engine automatically notices a required parameter is missing. It will dynamically generate a question to ask the user for the city before executing the tool. Your core takeaway is this. Generative Orchestration turns routing from a fragile phrase-matching exercise into an intelligent capability search, freeing you to focus on what your agent can do instead of guessing how the user will ask for it. If you want to support the show, you can find us by searching for DevStoriesEU on Patreon. That is all for this one. Thanks for listening, and keep building!

AI-Based Agent Authoring

3m 21s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 2 of 15. Usually, building a conversational flow means dragging nodes onto a canvas, manually wiring up logic trees, and guessing every possible trigger phrase your end user might type. But what if you could just tell an AI exactly what you want to build, and let it generate the structural logic for you? This mechanism is called AI-based agent authoring. It is critical to distinguish this from runtime AI behavior. Developers often confuse generative AI at build time with generative AI at runtime. Runtime is when a live user asks a question and the agent dynamically generates an answer using an external knowledge base. Build-time authoring is completely different. This is when you use an AI assistant inside the studio to construct the static framework of the agent itself. You start in the authoring canvas. Instead of clicking to add individual elements, you interact with the Copilot authoring pane. Suppose you need a flow to handle hardware returns. You type out a plain English description requesting a topic that asks the user for their order number, checks if the item is a laptop or a mobile device, and then provides the correct return shipping address based on the equipment type. When you submit that prompt, the natural language understanding model processes your instructions and maps them directly to the internal node schema of Copilot Studio. It automatically generates a set of diverse trigger phrases that a real user might say to initiate this specific flow. It places a question node onto the canvas to capture the order number and assigns a variable to it. It establishes a condition node to branch the logic between a laptop and a mobile device. It then populates the final message nodes with placeholder return addresses. The entire skeleton of the topic appears on your screen instantly. Here is the key insight. This authoring process is strictly iterative. You are not forced to accept the initial generation as a final product. If you look at the generated flow and realize you need to capture the date of purchase, you do not have to manually break the connections and insert a new node. You simply tell the authoring Copilot to add a question asking for the purchase date right before it asks for the order number. The underlying model analyzes the current state of your canvas, understands the sequential insertion point, and safely modifies the flow. Because the AI translates natural language directly into standard Copilot Studio components, you retain complete architectural control. The generated nodes are not black boxes. They are exactly the same elements you would have created manually. You can click into the condition branches, adjust the variable types, or rewrite the prompt text by hand. The language model simply handles the mechanical assembly of the canvas. The true power of AI-based authoring is not that it writes flawless conversational flows on the first try, but that it transforms the slow mechanical process of node wiring into a rapid dialogue about business intent. Thanks for hanging out. Hope you picked up something new.

Topics and Nodes

3m 28s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 3 of 15. Even the most advanced AI agents eventually need deterministic logic for specific business rules. When a customer asks about your return policy or store hours, you cannot afford a probabilistic guess from a language model. You need a strict, guaranteed answer. Topics and Nodes give you that exact structural control. Think of a topic as a discrete conversation path. It is a predefined dialogue tree that dictates exactly how your agent handles a specific intent. Your overall agent is essentially a collection of these topics working together to route the user. A frequent point of confusion is the distinction between System topics and Custom topics. It is simpler than it seems. System topics handle foundational agent behaviors. These govern core events like greeting a user, ending a conversation, escalating to a human, or catching an error when the agent does not understand the input. You can modify their text to match your brand voice, but you cannot delete them. They are permanent fixtures of the system architecture. Custom topics are the paths you build yourself, entirely under your control, to handle your specific business scenarios. Inside every topic, the conversation executes top to bottom through individual steps called nodes. Nodes are the functional building blocks of the path. To understand how they interact, picture a custom topic designed to handle inquiries about Store Hours. When the user triggers this topic, the first step in your flow might be a Question node. A Question node prompts the user for information and waits for a specific type of response. In this case, the agent asks which city the user plans to visit. When the user replies, the node captures that response. This introduces Variable management. The Question node automatically stores the user answer into a variable. You now hold a distinct piece of state in memory, allowing you to route the conversation dynamically based on what the user just said. This is where it gets interesting. Instead of delivering a generic reply, you add a Condition node to evaluate that variable. A Condition node acts as a logical fork in the road. It checks the current state of your variable against rules you define. If the stored city equals New York, the node directs the flow down one branch. If the city equals London, it directs the flow down another. You can add as many branches as you need for different states, plus a fallback branch if the variable does not match any known city. Finally, at the end of each conditional branch, you place a Message node. A Message node simply displays text or media back to the user. The New York branch hits a Message node stating the store opens at nine in the morning. The London branch hits a different Message node stating the store opens at ten. By chaining Question, Variable, Condition, and Message nodes together, you dictate exactly how the logic flows. The single most important takeaway here is that topics isolate your deterministic business rules into predictable paths, ensuring your agent responds reliably when precision matters more than generation. Thanks for tuning in. Until next time!

State and Variables

3m 39s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 4 of 15. The quickest way to frustrate a user is making them repeat information they just gave you. If your bot asks for a name, triggers a new workflow, and then asks for the name again, the user experience breaks entirely. The mechanism that prevents this amnesia is State and Variables. A variable in Copilot Studio stores data extracted from the user or retrieved from a backend system. The most important decision you make when creating a variable is defining its scope. Listeners often confuse topic-level variables with global variables. A topic-level variable is strictly local. It only exists while its parent topic is active. The moment that topic finishes, the variable is cleared from memory. A global variable, on the other hand, persists for the duration of the entire conversation. Any topic can read it, and any topic can overwrite it. It is tempting to make every shared piece of data a global variable. Do not do this. Overusing global variables creates unpredictable state changes when topics interrupt each other. Instead, pass local variables directly between topics. Think of a topic called Greeting. It asks the user for their name and stores it in a local variable. The greeting ends, and the flow redirects to a new topic called Talk to Customer. To move the name over, you configure the Talk to Customer topic to receive values from other topics. You define an input variable on this destination topic. Then, back in your Greeting topic, the redirect node will automatically prompt you to map a value to that input. You pass the local name variable through the node. The destination topic catches it, the bot continues the conversation using the correct name, and your global state remains uncluttered. When that destination topic finishes its work, it can also return values back to the original calling topic using output variables. That covers data generated during a chat. Now, the second piece of this involves data your agent needs before a chat even begins. If your agent connects to external systems, it needs credentials. You absolutely never store API keys or connection strings in conversation variables. For this, you use environment variables. Environment variables live entirely outside the user session. They store configuration data that applies to the agent itself, allowing you to move your bot from a development environment to testing, and finally to production, without hardcoding values. Pay attention to this bit. When dealing with highly sensitive data, environment variables integrate directly with Azure Key Vault. Instead of pasting a password into Copilot Studio, you create an environment variable marked as a secret. This variable stores a reference to a specific key in your Azure Key Vault. During runtime, the agent securely fetches the secret to authenticate the backend request. The secret is never exposed in the authoring canvas, it is never printed in the chat logs, and it is excluded from your source control exports. The safest state is a scoped state, so keep conversation variables local whenever possible, pass them explicitly across topic boundaries, and always delegate system credentials to secure environment variables. Thanks for listening, happy coding everyone!

Entities and Slot Filling

3m 53s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 5 of 15. You build a bot to take orders, but it forces users through five tedious questions. The user already gave you all the details in their first message, yet your bot ignores that context and still asks for them one by one. This rigid behavior frustrates users, and it is exactly the problem solved by Entities and Slot Filling. Entities are how Copilot Studio recognizes real-world subjects from messy natural language. Think of an entity as a specific data type your bot is trained to spot inside a sentence. Instead of analyzing the whole phrase "I would like to spend twenty bucks", the AI simply looks for the money entity and extracts the value twenty. Copilot Studio comes with a large set of prebuilt entities. These handle standard data concepts out of the box. Prebuilt entities recognize age, dates, colors, numbers, names, and money. They normalize the data automatically. Whether the user types twenty dollars, the dollar sign followed by 20, or twenty bucks, the prebuilt money entity extracts the exact numeric value and the currency. But your business operates on specific terminology. To capture that, you build custom entities. There are two main types of custom entities you will use. The first is a closed list entity. You define a strict list of allowed items, and then you attach synonyms to each item. If you sell outdoor gear, you might create a product category entity with a primary item called hiking. You then add synonyms like trekking, backpacking, and trail walking. When the user types any of those synonyms, the AI maps their input directly back to the primary hiking value. The second custom type is the regular expression, or regex, entity. You use regex entities when users need to provide formatted strings rather than specific words. A common use case is a support ticket or an order ID. If your system uses tracking numbers that always start with the letters TRK followed by five digits, you define that pattern using regex. The AI will scan the user's message and cleanly extract that exact string, ignoring any surrounding text. Identifying the entity is only the first step. You need to store that data to use it. This action is called slot filling. You map an extracted entity to a variable, filling the slot with the user's data. This is where it gets interesting. Copilot Studio uses a feature called proactive slot filling. By default, the natural language understanding engine evaluates every user message against all the variables your conversation topic requires. If the AI detects the required entities in the user's initial input, it fills those slots immediately. Consider a user who triggers your purchasing topic by saying, I want to buy hiking boots under 100 dollars. You have a custom closed list entity for the product category, and you are using the prebuilt money entity for the budget. Because of proactive slot filling, the AI processes that entire sentence at once. It isolates hiking, maps it to your category variable, and stores it. It isolates 100 dollars, maps it to your budget variable, and stores that. Because those slots are already filled, the bot automatically skips the "What category are you looking for?" and "What is your budget?" question nodes entirely. The conversation flow skips straight over them and moves directly to the next missing piece of information. By defining strict entities and trusting proactive slot filling to handle the extraction, you stop writing rigid decision trees and start building conversational agents that respect the user's time. That is all for this one. Thanks for listening, and keep building!

Enterprise Knowledge Grounding

3m 47s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 6 of 15. The hardest part of building a conversational agent used to be predicting every user question and manually authoring the answers. You would spend weeks mapping out dialogue trees, only for users to ask something slightly off-script and hit a dead end. Enterprise Knowledge Grounding completely flips this model. Instead of writing answers, your existing enterprise data does all the heavy lifting. A generic large language model is highly articulate, but it knows absolutely nothing about your specific company. Enterprise Knowledge Grounding bridges this gap by connecting the copilot directly to your actual business data, such as public websites, SharePoint directories, uploaded files, and Dataverse tables. Take a customer support scenario. You need an agent that answers questions about your hardware. Instead of building hundreds of custom topics, you upload your PDF product manuals into the copilot and paste the URL of your public documentation site. When a user asks how to reset a specific router model, the copilot searches those connected sources, retrieves the relevant text, and synthesizes a direct answer. It also provides a citation link back to the specific manual or web page, so the user can verify the information. A common point of confusion is where exactly this knowledge lives within the architecture. You can attach knowledge in two distinct places: at the agent level or at the topic level. Agent-level knowledge is global. It acts as a safety net across the entire copilot. If a user asks a question and no manually authored topic is triggered, the system falls back to this global pool of knowledge. It searches all your connected agent-level sources to generate a response. This means you get immediate value without writing any custom conversation flows. Here is the key insight. Sometimes you need strict control over what data the AI uses, and that is where topic-level knowledge comes in. You configure this by dragging a Generative Answers node directly into the authoring canvas of a specific custom topic. If a user triggers a custom topic for processing a warranty claim, you do not want the AI pulling answers from your general marketing website. By using a Generative Answers node inside that specific topic, you can restrict its data source exclusively to a SharePoint folder containing legal warranty documents. The AI is scoped exactly to the context of that conversation step. When connecting these enterprise sources, the system handles access intelligently. For public websites, the copilot simply indexes the public pages. For internal sources like SharePoint, the copilot uses the Entra ID credentials of the person interacting with the bot. It strictly respects existing file permissions. If an employee does not have access to a specific internal document in SharePoint, the copilot will not read that document, and it will not use it to answer their question. For structured data, you can connect directly to Dataverse tables, allowing the copilot to ground its answers in the live records of your business applications. Using a Generative Answers node inside a custom topic allows you to tightly control the exact boundaries of the AI's knowledge at specific points in a conversation, preventing broad global data from muddying highly specific workflows. That is all for this one. Thanks for listening, and keep building!

Tenant Graph Grounding

3m 37s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 7 of 15. Standard keyword search breaks down the moment a user asks a nuanced question about an internal policy. You do not need better keywords. You need a system that understands the actual meaning of the question across massive datasets. That is exactly where Tenant Graph Grounding comes in. Tenant Graph Grounding brings deep semantic understanding directly to your enterprise data. First, let us clear up a common misconception. This is not standard Dataverse search, and it has nothing to do with scraping public websites. This is an advanced enterprise retrieval capability that plugs your copilot straight into Microsoft Graph. It is built specifically to handle complex internal knowledge stored across your tenant. To use this feature, your environment must meet a few hard requirements. You need a Microsoft 365 Copilot license. Your data needs to be indexed by the Semantic Index for Copilot. Most crucially, your copilot must be configured with Microsoft Entra ID authentication. This is not optional. The copilot must securely pass the identity of the person asking the question to Microsoft Graph. Consider an internal HR copilot designed to search massive employee handbooks. These handbooks often live in SharePoint or OneDrive as massive documents. Standard retrieval tools often choke on large files, but Tenant Graph Grounding supports file sizes up to 512 megabytes. When an employee asks about a highly specific scenario, like the parental leave policy for a secondary caregiver working part-time, a traditional search engine looks for those exact words. If the handbook uses different phrasing, the search fails. Here is the key insight. Because this feature uses the Semantic Index, it maps the conceptual relationships between the user query and the enterprise data. It understands that the query about parental leave maps conceptually to a section titled family time off, even if the keywords do not align perfectly. The logic flow operates entirely within your secure tenant boundary. A user submits a prompt to the copilot. The copilot uses the Entra ID token of that specific user to query Microsoft Graph. Microsoft Graph then searches the Semantic Index, but it only looks at files that the specific user already has permission to read. If a document is restricted, the Graph simply ignores it for that user. The Graph retrieves the highly relevant semantic matches and returns them to the copilot. The copilot then uses those exact data chunks to generate a precise, grounded answer. The entire transaction happens with near-instant precision, bypassing the latency and inaccuracy of trying to build your own custom search indexes over SharePoint data. Tenant Graph Grounding shifts the entire retrieval burden from your custom logic directly onto the Microsoft 365 semantic infrastructure, guaranteeing that your copilot respects existing enterprise data boundaries while delivering unmatched contextual accuracy. If you want to help support the show, you can find DevStoriesEU on Patreon. That is all for this one. Thanks for listening, and keep building!

Prompt Tools

3m 31s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 8 of 15. Sometimes you do not need to build a complex API or integrate an external parsing service to process incoming data. You just need a large language model to look at a messy string of text and process it exactly the way you want. That is where Prompt Tools come in. First, we need to clear up a common point of confusion. Prompt Tools are completely different from Generative Answers. Generative Answers scan an external knowledge base or a website to answer user questions dynamically. Prompt Tools do not search for answers. They are specific, heavily engineered instructions that tell a large language model to execute a strictly defined task on data you provide. Think of a Prompt Tool as a reusable function where the underlying logic is written in natural language instead of code. You build it by defining a prompt template, specifying input variables, and providing strict contextual rules. Consider a common scenario. You receive a block of unstructured, rambling customer feedback. You want to extract the underlying sentiment and generate a clean list of specific action items. Instead of writing complex regular expressions or a custom parsing script, you create a Prompt Tool. You start by defining the inputs. In Copilot Studio, you create an input variable called feedback text and set its data type. This simple step tells the tool to expect a dynamic string every time it is invoked by the system. Next, you write the prompt template. This is the core instruction set sent to the language model. You write out precisely what the model must do. You instruct it to read the feedback text variable, determine if the tone is positive, negative, or neutral, and identify any tasks the customer support team needs to handle based on the text. Here is the key insight. The template is practically useless without strict context. You do not just ask the model for sentiment and hope it replies nicely. You define the exact output structure within the prompt context. You explicitly instruct the model to return the result formatted as a strict JSON object containing a sentiment key and an action items array. You forbid conversational filler. This context transforms a generic, chatty language model response into a predictable, structured data payload that your downstream systems can actually parse. When your agent triggers this tool during a live conversation, the execution flow is entirely automated. The agent takes the live customer response and passes it into your feedback text input. The tool dynamically injects that string into your template, sends the complete instructional package to the model, and hands back the structured JSON. The agent can then use those extracted action items to automatically update a database or route the user to a specialized support queue. You define the tool once, and the agent calls it automatically whenever it recognizes the need to process unstructured text. A well-engineered Prompt Tool shifts the burden of complex text processing away from your application code and onto the language model, letting you extract perfectly structured data from complete chaos using nothing but a few lines of plain English. That is all for this one. Thanks for listening, and keep building!

Agent Flows

3m 39s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 9 of 15. Your agent needs to execute a complex backend workflow spanning multiple systems. Maybe it needs to query an isolated database, filter the data, and update an inventory system all at once. A single API call cannot handle that orchestration. The solution is an Agent Flow. Agent Flows bridge Copilot Studio with Power Automate. They allow you to package a multi-step automation as a standalone tool that your agent can trigger autonomously. The agent relies entirely on the name and description you provide for the flow. Based on that text, the agent decides if the flow can solve the current user request. When it finds a match, the agent extracts the necessary parameters from the conversation, passes them into the flow, waits for the execution, and uses the final output to generate an answer. The structure of an Agent Flow is strict. It must start with a specific trigger designed for Copilot, which explicitly defines the text or number inputs. It must end with a specific action that responds back to Copilot, defining the text or number outputs. Everything between those two nodes is standard Power Automate logic. You can loop through arrays, call custom connectors, or parse files. Consider a scenario where your agent needs to retrieve order history from a legacy SQL database. The user asks for their recent orders. The agent triggers the flow, passing the customer ID string as an input. Inside the flow, you build the logic to connect to the SQL database, execute the query, and format the raw database rows into a clean JSON string. The flow then passes that formatted string back to the agent through the response node. The agent reads the string, extracts the order details, and replies to the user in natural language. Here is the key insight. The execution must be entirely synchronous. The agent initiates the flow and keeps the connection open, waiting for the response. If you build an asynchronous flow, it will not work as an agent tool. You cannot include steps that pause the logic. If your flow sends an approval email and waits for a human to click a button, the agent will break. The tool pattern requires an immediate return of data. This brings us to a hard system limit. You have exactly one hundred seconds. From the moment the agent triggers the flow, the logic has one hundred seconds to execute every step, query the database, format the output, and send the response back. If the legacy SQL server is under load, or if your flow iterates through too many records, the execution will exceed the timeout limit. When that happens, the agent drops the connection entirely and returns an error message to the user. To handle this limit, you must keep the automation tightly scoped. If a backend process takes five minutes, do not run it inside the Agent Flow. Instead, use the flow to kick off an external background job and immediately return a tracking ID to the agent. Your automation architecture must respect the timeout window. Design your flows to execute quickly, retrieve exactly what is needed, and return control to the agent, ensuring the user is never left talking to a stalled connection. That is all for this one. Thanks for listening, and keep building!

Power Platform Connectors

3m 37s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 10 of 15. You spend days writing and maintaining custom API integrations just so your agent can talk to the outside world. Meanwhile, thousands of prebuilt wrappers are already sitting in your environment, waiting to be executed. Today, we are looking at Power Platform Connectors. Connectors are standardized API wrappers. They provide a predictable way for Microsoft Copilot Studio to communicate with external services. Before we look at how they operate, we need to clear up a common confusion. Users often mix up using an external system as a knowledge source versus using it as a tool. If your agent queries a database just to retrieve facts and ground its conversational answers, that is passive knowledge. Using a connector as a tool is different. It is an active operation. You are giving the agent the authority to execute actions, create records, or trigger external processes on behalf of the user. There are three categories of connectors available. Standard connectors cover basic Microsoft services and common public endpoints. Premium connectors require specific licensing and connect to enterprise systems like Salesforce or ServiceNow. If the system you need to reach is an internal proprietary API, you can build a custom connector. A custom connector is just an OpenAPI wrapper you define yourself. Once registered in your environment, it behaves exactly like the standard and premium ones. The agent does not care who built it. Let us look at how this logic flows using a concrete scenario. You want your agent to compile a project summary and email it to your engineering team. Instead of manually constructing an HTTP request, you add the Office 365 Outlook connector directly into your copilot as an action. Every connector exposes specific operations. In this case, you select the action to send an email. This is the part that matters. You do not write procedural code to dictate exactly when this email sends. Instead, you define the parameters the connector requires to function. The Outlook connector needs a destination address, a subject line, and the body text. You configure these inputs and provide a clear, plain-language description of what the action does. Copilot relies entirely on that description to determine when to trigger the tool. When a user tells the agent to send the weekly status update to the engineering team, the agent evaluates its available tools. It matches the user request to your Outlook connector description. The agent then dynamically extracts the recipient name and the summary text from the ongoing conversation. It maps those extracted values to the connector inputs and fires the action. Once the external API processes the request, the connector passes a response back to the agent. This might be a simple success code or a payload with specific details about the transaction. The agent receives this data, verifies the action was completed, and generates a natural language response telling the user that the email has been sent. By standardizing the interface, these wrappers remove the need to manage authentication tokens, headers, and error handling for every individual service. You configure the connection once, and the agent orchestrates the execution. Connectors turn your agent from a static conversational interface into an operational tool that actually alters state across your infrastructure. That is all for this one. Thanks for listening, and keep building!

The Computer Use Tool

3m 31s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 11 of 15. If an application has no API, traditional automation hits a wall. You either write brittle scripts that break the moment a button shifts, or you accept manual data entry. The Computer Use tool resolves this by letting your AI literally see the screen and operate the machine itself. Available in preview, this feature allows your agent to interact with a graphical user interface using a virtual mouse and keyboard. It relies on Computer-Using Agents, powered by vision-capable models like Anthropic's Claude 3.5 Sonnet. It is necessary to clarify what this is not. This is not traditional Robotic Process Automation. Standard RPA relies on underlying structural hooks, like DOM tags or UI element IDs. The Computer Use tool operates entirely on pixels. The logic flow is a continuous loop. The tool captures a screenshot of the desktop environment and passes it to the model. The model analyzes the visual layout, reasons about the user request, and calculates precise coordinates for its next move. It outputs instructions back to the system. The system translates these into moving the virtual cursor to a specific X and Y position, clicking a mouse button, or sending a string of keystrokes. After executing the action, the tool takes another screenshot to assess the new state of the screen, verifying if a window opened or text appeared, before deciding on its next step. Consider a scenario where you need to extract data from a legacy Windows desktop application and enter it into a modern web form. The agent looks at the screenshot of the legacy app, visually locates the invoice number, and stores that information. It then outputs instructions to move the mouse over to the browser window, click inside the target web form field, and type the digits. It navigates the interface exactly as a human operator would, guided entirely by the visual context on the display. Giving an AI model physical control over a desktop requires strict security controls. Here is the key insight. You never deploy this on a production server or a user's primary workstation. The agent must operate inside a dedicated, isolated virtual machine or container. You grant this environment the absolute minimum privileges required to complete the specific task. Because the model can navigate web browsers on its own, you must enforce strict network controls. You apply a URL allow list so the agent can only access approved domains, preventing it from interacting with untrusted websites or external services. You also ensure the virtual machine holds no sensitive data outside of the immediate workload. By treating the graphical user interface as just another visual input stream, you bridge the gap between intelligent reasoning and inaccessible legacy software without writing a single line of integration code. That is all for this one. Thanks for listening, and keep building!

User Authentication

3m 16s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 12 of 15. An agent is only as powerful as the data it can access. But if your agent queries a private system and accidentally serves up your personal calendar to a completely different employee, you have a massive security flaw. To prevent this, you must correctly configure User Authentication. The most common mistake developers make here is mixing up maker-provided credentials with end-user credentials. If you embed your own API keys or service principal credentials into an agent action, the bot executes those actions as you. Every person chatting with the agent will bypass their own security limits and access data using your permissions. User authentication forces the agent to run queries exactly as the person typing the prompt, relying entirely on their unique identity. In Copilot Studio, you primarily choose between two authenticated states: Authenticate with Microsoft, and Authenticate manually. Authenticate with Microsoft is the streamlined path for internal tools. If your agent operates exclusively inside Microsoft Teams or Power Apps, this setting automatically uses the Microsoft Entra ID token of the person currently signed into the application. There is no separate login prompt. The user context simply flows through to the agent. You switch to Authenticate manually when your agent lives on a custom external website, or when you require strict, granular control over permissions. This method relies on setting up an OAuth2 connection to an identity provider, which is typically an App Registration in Microsoft Entra ID. Take a concrete scenario. You are building an agent that checks an employee's personal schedule. You configure Authenticate manually and link it to your Entra ID App Registration. Here is the key insight. The agent does not get blanket access to the user's entire Microsoft account. Instead, you define strict scopes in your configuration. You configure the authentication node to request a specific scope called Calendars dot Read. When a user asks the agent for their schedule, the agent pauses its logic and displays a sign-in card in the chat. The user clicks the link, authenticates through their browser, and sees a screen asking them to grant the agent read access to their calendar. Once they consent, Microsoft Entra ID generates an access token and passes it securely back to the agent. This access token is tied strictly to that individual user and restricted solely to the calendar scope. When the agent makes the actual HTTP request to fetch the schedule, it includes this token. The backend API inspects the token, confirms the user identity, and safely returns only their specific calendar events. Getting user authentication right is what transforms a generic chatbot into a personalized assistant, proving to your backend systems exactly who is asking for data so you never leak private information across sessions. Thanks for spending a few minutes with me. Until next time, take it easy.

Voice and IVR

3m 43s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 13 of 15. The future of customer service is not just text on a screen. People still call support lines, and when they do, they expect an immediate, intelligent response rather than an endless menu tree. Bridging that gap requires connecting your AI directly to telephony networks. That is what we are covering today: Voice and IVR. Taking an agent built in Copilot Studio and making it answer the phone means configuring it for a telephony channel, generally through Dynamics 365 or Azure Communication Services. This transforms your logic into an Interactive Voice Response system, relying on native speech recognition to convert caller audio into text and text-to-speech engines to talk back. But translating chat logic to voice logic requires handling the physical realities of a phone call. Think about a customer calling a support line. The bot answers and starts reading a required legal greeting or a list of options. The caller already knows they need the billing department. If this were a text chat, they would just type their question. On a phone, they speak over the bot. This requires a feature called Barge-in. Without Barge-in enabled, the system ignores incoming audio until the bot completely finishes its playback. With Barge-in active, the speech recognizer listens concurrently. The moment it detects the user speaking, it instantly halts the bot's text-to-speech output and processes the incoming audio. This replicates the natural flow of human conversation and stops callers from feeling trapped by a machine. After interrupting the bot, the caller is prompted for an account number. They could say the numbers out loud, but maybe they are in a crowded room. Instead, they tap the numbers on their screen. This brings us to DTMF, or Dual-Tone Multi-Frequency. People often confuse DTMF handling with standard text inputs, but they are entirely separate mechanisms. DTMF handles phone keypad interactions globally across the telephony network. When a caller presses a key, the network sends a specific frequency tone. Copilot Studio captures these tones directly. You configure input nodes to listen for DTMF sequences, extract the resulting digits, and store them as variables. You can enforce a maximum number of digits, set timeouts, and define a termination character, such as instructing the user to press the pound key when they are finished typing. Here is the key insight. Just capturing input is not enough; the way your agent replies determines whether the caller hangs up. Default text-to-speech can sound flat. To fix this, you use SSML, or Speech Synthesis Markup Language. Instead of sending plain text to the voice engine, you wrap your responses in markup tags. SSML lets you control the pitch, adjust the speaking rate, and enforce specific pronunciations. If your company name is an acronym, you can use SSML to force the engine to read it letter by letter instead of guessing how it sounds as a word. You can insert precise silences, adding a half-second pause after a complex instruction to let the caller process the information. Building for voice requires treating the phone line as a unique interface, accounting for interruptions, keypad tones, and audio pacing. The most effective voice agents do not force users into rigid audio menus; they combine seamless barge-in and precise DTMF handling to simply get out of the caller's way. Thanks for tuning in. Until next time!

Agent Analytics

3m 03s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 14 of 15. You finally deploy your agent, test it yourself, and everything looks perfect. A week later, user satisfaction is dropping, and background processes are failing silently. The problem is not your initial build, it is your lack of visibility into production behavior. The tool to fix this is Agent Analytics. Agent Analytics provides a unified view of how your agent performs once it handles real workloads. The first thing you see is the Summary page. This acts as the command center. It aggregates key performance indicators like total sessions, engagement rate, resolution rate, and escalation rate. Instead of guessing if your agent is helping users, the Summary AI insights analyze user intent and show you exactly which topics are driving successful resolutions and which ones cause users to abandon the session or ask for a human. Here is the key insight. Copilot Studio tracks two fundamentally different types of sessions, and the dashboard presents them in a hybrid view. First, you have conversational sessions. These are exactly what they sound like. A user opens a chat window and talks back and forth with the agent. The analytics track the dialogue turns, user sentiment, and topic triggering. Second, you have autonomous sessions. These run entirely in the background. They are triggered by external events, like a new record being created in a database or an incoming email, not by a user typing a message. There is no chat interface. The analytics track whether the agent successfully completed its background logic or if it hit an error. You need both views to keep an agent healthy. Consider a scenario where you are reviewing this hybrid dashboard. Your conversational metrics look fine, but you notice a sudden spike in failure rates. Filtering by session type reveals the errors are all happening in autonomous sessions. An event-triggered process that is supposed to update order statuses is failing in the background. The summary dashboard tells you there is a failure, but it does not tell you the exact line of logic that caused it. This is where you move from the dashboard to the raw data. Copilot Studio stores detailed execution logs in Microsoft Dataverse as transcripts. You download the specific transcript for the failed autonomous session. Reading the transcript gives you the step-by-step trace of the execution. You can see the exact variable that passed an invalid value, pinpoint the failing node, and fix the logic without having to recreate the error blindly. The dashboard tells you where to look, but the transcript tells you what to fix. If you want to help keep these technical breakdowns coming, you can support the show by searching for DevStoriesEU on Patreon. That is all for this one. Thanks for listening, and keep building!

Model Context Protocol

3m 28s

Download

Hi, this is Alex from DEV STORIES DOT EU. Microsoft Copilot Studio, episode 15 of 15. You spend weeks building custom plugins to let your agent query your internal databases and trigger actions. Then a new platform launches, and you find yourself rewriting all those exact same integrations from scratch. The solution to this endless cycle of redundant work is the Model Context Protocol. The Model Context Protocol, or MCP, is an open standard that connects AI models to external data sources and tools. By adopting an open standard, you effectively future-proof your agents. You write the integration logic exactly once, host it on an MCP server, and any compatible AI client can instantly use it. Copilot Studio acts as one of these clients. Consider a scenario where your engineering team relies on 50 different internal diagnostic scripts and real-time log files. You do not want to manually create and map 50 separate actions inside Copilot Studio. Instead, you configure your agent to connect directly to your proprietary internal MCP server. When the agent initializes, it asks the server what it can do. The server replies with a list of capabilities, immediately granting the agent access to all 50 engineering tools and live file resources. An MCP server exposes three main components to your agent. These are Resources, Tools, and Prompts. Resources are read-only data sources. When your agent needs to check a live configuration file or a database record, the MCP server provides that data as a resource, loading it directly into the context of the model. Tools are executable functions. If the agent decides it needs to restart a virtual machine or update an engineering ticket, it calls the appropriate MCP tool, and the external server executes the action. Prompts are predefined instruction templates provided by the server. They guide the agent on exactly how to format queries or interpret the data specific to that external system. Here is the key insight. People often assume that when you connect an MCP server, Copilot Studio imports and saves permanent copies of those tools into its own user interface. That is not how it works. The tools and resources are hosted completely externally. Copilot Studio dynamically reads what the server exposes at runtime. If your engineering team adds a fifty-first diagnostic tool, or modifies the parameters of an existing script, they simply update the external MCP server. Copilot Studio automatically reflects those changes. You never have to log into the studio interface to republish or update the action. Because the logic lives entirely on the server, you maintain a single source of truth for your organizational data and actions. The agent remains lightweight, functioning merely as the reasoning engine that decides when to communicate with the server. By separating your tools from the specific agent platform, you centralize your integrations and guarantee that your AI always has the latest capabilities, regardless of which client interface you deploy. I highly encourage you to read the official documentation, try connecting an MCP server hands-on, or visit devstories dot eu to suggest topics you want to see covered in a future series. That is all for this one. Thanks for listening, and keep building!