Halilcan Soran

Tag: Copilot Studio

  • Power Platform June 2026 Update Shipped and the Power Apps MCP Server Closed-Loop Learning Is the Headline

    Power Platform June 2026 Update Shipped and the Power Apps MCP Server Closed-Loop Learning Is the Headline

    Power Platform June 2026 update MCP server closed-loop learning diagram

    The Power Platform June 2026 update MCP server announcement dropped on June 11 and the headline for me is not the usual feature list. It is the Power Apps MCP server and what Microsoft is calling closed-loop learning for enterprise agents. Source: What’s new in Power Platform: June 2026 feature update.

    I read the post twice. The first read I filed it under “another MCP integration.” The second read I realised what they actually shipped. Agents can now learn from real usage signals inside Power Apps without you standing up a data science team to run training and evaluation cycles. That is a different category of thing.

    What it actually does

    The Power Apps MCP server exposes app context, user actions, and outcomes to an agent as structured signals. Until now, teaching an agent how your org works meant one of two paths. Either you fed it knowledge as documents and custom instructions, which is what most teams are doing today. Or you ran your own training, evaluation, and optimization loop, which almost nobody outside the big AI shops actually does.

    Closed-loop learning sits in between. The agent observes what happens when a user takes its suggestion. Did the form get submitted. Did the approval get reversed two days later. Did the user override the recommendation. Those signals flow back through the MCP server and the agent’s behavior adjusts based on whether its suggestions actually worked.

    The mechanism is the interesting part. It is not fine-tuning the underlying model. It is updating the agent’s grounding and skill selection based on outcome data that lives in Dataverse. Combine this with the business skills work Microsoft shipped earlier and the picture gets clearer. Skills are the policy layer. MCP server signals are the feedback layer.

    Why it matters

    Here is the architectural shift I think the release notes underplay. Agent knowledge stops being a build-time artifact and starts becoming a runtime asset.

    Most agents I see today are frozen at deploy time. You write the instructions, attach the knowledge sources, ship it, and then it just sits there making the same mistakes for six months until someone files a complaint and a developer goes in to patch the prompt. That is the model we have been stuck with since Copilot Studio launched.

    Closed-loop learning breaks that pattern. If the signal pipeline works the way the post describes, an agent that recommends the wrong approver three times in a row will stop doing that without anyone editing a prompt. The policy still lives in a business skill with a named owner. The behavior tunes itself based on what actually worked.

    The risk is obvious and I want to name it. If you wire usage signals into agent learning without thinking about which signals count, you end up reinforcing the wrong behavior. A user clicking accept because they are tired is not the same signal as a user clicking accept because the suggestion was right. The MCP server gives you the plumbing. Picking the right outcome signals is still your job, and I expect the first wave of failures to come from teams treating every user action as positive feedback.

    I also want to flag the governance angle. The Power Platform May 2026 update made me start thinking about agent constraints as versioned records. Runtime learning means version history now has to cover learned behavior too, not just authored skills. That is a real audit question and Microsoft has not fully answered it yet.

    What I would do with it this week

    I have an internal approval-routing workflow that I have been wanting to test something like this on. The agent currently picks an approver based on a static skill, and it gets the routing wrong roughly one in six times because the org chart does not reflect who actually owns what.

    My plan for this week is simple. Wire the Power Apps MCP server to that app. Define two outcome signals. First, did the selected approver actually approve within 48 hours, or did they reassign. Second, did the requester come back and edit the routing manually after submission. Anything else I am ignoring on purpose, because I want a clean signal before I open the door wider.

    Then I let it run for two weeks and compare the routing accuracy against the static baseline. If the closed loop moves the needle even five points on a workflow this messy, I will be writing about it. If it does not, I want to understand why before I trust it on anything that matters. If you are thinking about how to expose this kind of agent behavior through a proper UI layer, the guide on building custom Copilot UI widgets in Power Apps is worth reading alongside this.

    The Power Platform docs will need to catch up on the MCP server specifics, and I expect the configuration story to get cleaner over the next few releases. For now, this is the most interesting thing shipped this month and I cannot wait to see what the signal quality looks like in a real workflow. More on this once I have run the experiment. You can follow along on LinkedIn if you want the results.

    Source: What’s new in Power Platform: June 2026 feature update (Microsoft Power Platform Blog).

  • Power Platform May 2026 Update Landed and Here Are the Three Things I Am Actually Turning On

    Power Platform May 2026 Update Landed and Here Are the Three Things I Am Actually Turning On

    Power Platform May 2026 feature update highlights for builders

    The Power Platform May 2026 feature update dropped on the 14th and the release notes are dense. I read through the whole thing twice. Most of it is noise for day-to-day builders. A few things are not. This is the short list of what I am actually turning on this week and why.

    What shipped in the May 2026 update

    The headline item is Power Fx user defined types going generally available as of version 3.26044. UDTs are enabled by default on new apps and require a manual toggle in settings > updates > new > user-defined types on existing ones. Defined with the Type function in App.OnStart or app-scoped formulas.

    Beyond that, the release covers Copilot Studio shipping bits around agent authoring, more Dataverse plumbing for skills and knowledge sources, governance tweaks for managed environments, and a long tail of small Power Apps and Power Automate quality-of-life updates. Some of it is useful. A lot of it is preview-flag churn that will not affect what I build this month.

    Why this release is heavier than it looks

    On the surface, the May 2026 update reads like another monthly drop. It is not. UDTs going GA changes how I write Power Fx, full stop. Component libraries stop being copy-paste exercises and start behaving like an SDK. The agent and skill updates keep moving business logic out of system prompts and into managed Dataverse artifacts, which I have written about before.

    The governance pieces are quieter but they hit the parts of the platform that decide whether your environment stays usable at 200 makers or collapses into sprawl. None of these are flashy. All of them shift how you architect.

    The three things I am turning on this week

    1. Power Fx user defined types on existing apps. This is the one. Before UDTs, type information was inferred from whatever record you passed first. One missing field and the schema silently widened. Runtime surprise. With UDTs you declare the shape once with Type and the formula bar catches mismatches at authoring time. I am going through my medium-sized apps and flipping the toggle, then retyping the component props that have caused the most regression bugs. The trade-off is real. Existing formulas can break when types get strict. You will spend an afternoon fixing things. You get type safety for the next two years. Worth it. More on what UDTs unlock in my earlier post.

    2. The Copilot Studio agent authoring improvements tied to Dataverse skills. If you have not moved your business logic out of system prompts yet, this release is the nudge. A focused 400-token skill outperforms a 4000-token prompt every time. I am rebuilding two internal agents this week, lifting policy logic into skills with named owners and version history. The governance gain matters more than the latency gain. If you want a practical look at surfacing those skills inside an app, How to Build Custom Copilot UI Widgets in Power Apps covers how to wire the Copilot payload to a real component rather than a text box.

    3. The managed environment governance updates. Specifically the changes around DLP scope and the maker access controls. I am not going to pretend this is exciting. It is the unglamorous flipping of switches that keeps the platform from rotting. If you run a CoE, read that section twice and update your baseline. Skipping this is how you end up with the month-three stall I described in Inside a Power Platform Center of Excellence: Why Most Setups Stall in Month Three.

    What I am ignoring this month: most of the preview flags, the cosmetic Power Apps studio tweaks, and anything in the Copilot canvas experience that is not GA. Preview features burn debugging time and break when the next release lands. I will come back to them when they ship for real.

    For the official documentation on UDTs and the Type function, the Microsoft Learn reference is the place to start. For my running notes on what I turn on and what I skip, I keep a list on LinkedIn.

    Monday morning: toggle UDTs on one app, port one skill out of a system prompt, update the managed environment baseline. Three concrete moves. Everything else can wait.

    Source: What’s new in Power Platform: May 2026 feature update (Microsoft Power Platform Blog).

  • How to Build Custom Copilot UI Widgets in Power Apps Step by Step

    How to Build Custom Copilot UI Widgets in Power Apps Step by Step

    Copilot custom UI widgets in Power Apps rendering a card instead of text

    Default Copilot responses in Power Apps are text. Useful for quick answers, useless when the user actually needs a card, a form, or a chart. This walkthrough shows how to build copilot custom UI widgets power apps style, so the chat renders a real component when a specific question is asked, and falls back to text otherwise. Credit to Matthew Devaney’s writeup which is the spine I am building on here.

    End state: a canvas app with a Copilot chat. Ask it about an order, and a card component appears in the conversation with the order details. Ask anything else and you get normal text.

    Step 1: Add the Copilot control and a component to your canvas app

    In your canvas app, insert the Copilot control from the Insert panel. Place it on the right side of the screen. Keep the default width, you will want the space.

    Now create the component that will act as your widget. Go to the Components tab in the tree view, create a new component called OrderCardWidget. Add an input property called OrderPayload of type Record. Inside the component, drop a container with a few labels for order ID, customer name, status, and total. Bind each label to OrderCardWidget.OrderPayload.OrderId and so on.

    Add the component to the screen. Set its Visible property to false for now. You will flip this on from the Copilot response in Step 3.

    Step 2: Configure the Copilot topic to return a structured response

    Open the Copilot studio agent connected to this app. Create a new topic called Show Order Details. Add trigger phrases like show me order, display order, open order card.

    Add a question node asking for the order ID. Then add a tool call to a Power Automate flow that returns the order as structured JSON. The flow does a Dataverse or SharePoint lookup and returns a response with this shape:

    { "widget": "OrderCard", "payload": { "orderId": "...", "customer": "...", "status": "...", "total": 0 } }

    The widget field is the trigger phrase for the UI layer. The payload field is what binds into the component. Do not skip the typed schema on the flow response. If you return a generic object, the Copilot control hands you a string and you spend the next hour wondering why parsing fails. I wrote about that exact failure mode in my custom connector walkthrough.

    Finish the topic with a Message node that returns the JSON as the final response. Microsoft’s docs on Copilot in canvas apps have the current control reference if your version differs.

    Step 3: Bind the component to the Copilot response payload

    Back in the canvas app, select the Copilot control. The control exposes a property called OnResponse that fires every time the agent sends a message. This is where you parse the JSON and route it.

    Set OnResponse to:

    Set(varLastResponse, ParseJSON(Self.LastMessage)); Set(varWidgetType, Text(varLastResponse.widget)); Set(varOrderPayload, varLastResponse.payload)

    Now set the component’s Visible property to:

    varWidgetType = "OrderCard"

    And set its OrderPayload input to:

    { OrderId: Text(varOrderPayload.orderId), Customer: Text(varOrderPayload.customer), Status: Text(varOrderPayload.status), Total: Value(varOrderPayload.total) }

    The widget now renders only when the agent says it should, and only with the data the agent returned. If you want to support multiple widgets later, swap the boolean for a switch on varWidgetType and toggle different components. If you are thinking about when that kind of routing logic warrants a dedicated agent per task, single agent vs multi-agent is worth reading before you scale this pattern.

    Step 4: Test the widget end to end and handle the fallback

    Run the app. Open the Copilot chat. Type show me order 1042. The topic should trigger, the flow should fire, and the card should appear with the right data.

    Now test the fallback. Ask something unrelated like what is the weather. The card must disappear. If varWidgetType is not reset between turns, the old widget hangs around showing stale data. Add a default branch to OnResponse:

    If(IsBlank(varLastResponse.widget), Set(varWidgetType, ""))

    Also test a malformed response. Force the flow to return invalid JSON once and confirm the app does not crash. ParseJSON returns blank on failure, your visibility check handles it, the chat continues as text. That is the behavior you want.

    Final state and one pitfall to watch for

    You now have a Copilot chat that renders a real Power Apps component when the topic returns the right payload, and text the rest of the time. Same pattern works for forms, charts, anything you can build as a component. If you want the agent behind this to pull from richer knowledge sources or close feedback loops on responses, the Dataverse agent data platform new features are worth wiring up alongside this.

    The pitfall: the Copilot control reads the raw message text. If your topic adds any conversational wrapper around the JSON, like Sure, here is your order: {...}, ParseJSON fails silently and the widget never appears. Return pure JSON from the final Message node, nothing else. That one rule will save you an afternoon of debugging. More notes on this kind of integration thinking on my LinkedIn.

    Frequently Asked Questions

    How do I build copilot custom UI widgets in Power Apps?

    You add a Copilot control to your canvas app, create a component to act as the widget, and configure a Copilot Studio topic to return a structured JSON response that includes a widget identifier and a data payload. The canvas app then reads the response, checks the widget field, and toggles the component visible while binding the payload to its input properties.

    Why does my Copilot control return a string instead of a parsed object in Power Apps?

    This usually happens when the Power Automate flow response does not have a typed schema defined. Without a typed schema, the Copilot control treats the response as plain text, which causes JSON parsing to fail. Always define the response schema explicitly in your flow to ensure a structured object is passed back.

    When should I use a custom widget instead of a default text response in Copilot?

    Use a custom widget when the user needs to view or interact with structured data, such as order details, forms, or charts, rather than a plain text answer. Text responses work for simple questions, but components give users a far more usable experience when the data has multiple fields or requires visual formatting.

    How do I connect a Power Automate flow to a Copilot Studio topic?

    Inside your Copilot Studio topic, add a tool call node and select your Power Automate flow as the action. The flow handles the data lookup and returns a structured JSON response back to the topic. Make sure the flow output schema is typed so the Copilot control can pass the data correctly to your canvas app.

    Source: How To Create Copilot Custom UI Widgets In Power Apps (Matthew Devaney (Power Apps)).

  • Dataverse’s New Knowledge Sources and Agent Feedback Loops Explained

    Dataverse’s New Knowledge Sources and Agent Feedback Loops Explained

    Dataverse agent data platform new features including knowledge sources and feedback loops

    Microsoft published Dataverse Is Your Agent Data Platform: Here’s What’s New on May 5. I already wrote about the positioning shift, but the dataverse agent data platform new features in this post are the part I actually want to wire up this week. Knowledge sources you can attach to an agent. Agent feedback captured and stored back in Dataverse. Tighter coupling between business skills and the data model. That last bit is the one that changes my build order.

    What it actually does

    Three things stand out from the post.

    First, knowledge sources on Dataverse. You can now attach SharePoint sites, websites, files, and Dataverse tables as knowledge an agent can reason over, governed at the Dataverse level rather than configured per agent. The point is that knowledge becomes a managed artifact in the data platform, not a per-agent setting buried in Copilot Studio.

    Second, agent feedback stored in Dataverse. Thumbs up, thumbs down, and the conversation context land as rows you can query. That means feedback is not trapped in a separate analytics surface. You can write a flow on it. You can build a Power BI report on it. You can route a thumbs-down with a specific topic tag to the skill owner.

    Third, business skills tied to the data model. The business skills I wrote about when they shipped now sit closer to the tables they operate on. Skill ownership, policy versioning, and the data the skill reads from are governed in one place.

    For the official surface area, the Microsoft Learn docs are the right starting point once you have read the announcement.

    Why it matters

    I have built enough Copilot Studio agents to know where the pain actually sits, and it is never the model. It is the loop between what the agent does, what users think of what the agent did, and the policy owner who has to fix the thing that went wrong. That loop has been broken on Power Platform for a year.

    Feedback used to live in conversation transcripts you had to export. Knowledge used to be attached per agent, which meant the same SharePoint site got wired up four different ways by four different makers. Business logic lived in a 4000-token system prompt or a hardcoded Power Automate flow nobody could find six months later.

    Putting all three in Dataverse closes the loop. Feedback is a table. Knowledge is a managed artifact. Skills are versioned records with owners. You can finally write the query that says “show me every thumbs-down on the leave policy topic in the last 30 days, grouped by the skill that was invoked.” That query was not possible before. Now it is a view.

    The thing I am cautious about is the same thing I flagged with business skills. Sprawl. If five teams attach overlapping knowledge sources to overlapping skills with no naming convention, the agent will misroute silently and the feedback table will just tell you users are unhappy without telling you why. Governance has to come before deployment, not as a month-six cleanup. The multi-agent orchestration patterns that are now GA in Copilot Studio make this even more important to get right before you scale.

    What I would do with it this week

    I have a small internal agent that answers process questions. The plan for the next few evenings looks like this.

    Move knowledge out of the agent and into Dataverse. Right now the agent has three SharePoint sources wired up directly. I want one knowledge source registered in Dataverse, owned by the process owner, that any future agent on the same domain can reuse. That is the silo fix.

    Turn on feedback capture and build the report. Thumbs-down without a report is just noise. I want a Power BI page that shows feedback rate per topic, with a drill-through to the conversation. If I cannot see which skill was invoked when the user said no, I cannot improve anything.

    Pick one skill and version it properly. I am going to take the leave policy skill, rewrite it as a Dataverse business skill with an owner who is not me, and document the handoff. If the policy changes, the policy owner edits the skill. I do not get a ticket. That is the architectural shift I keep talking about, and it only works if I actually do it on something real. The error handling patterns that hold up in production become especially relevant once feedback loops are writing rows back into Dataverse and triggering flows downstream.

    None of this needs a new model. It needs the data platform to do its job, and it finally can.

    The interesting question now is what the second wave of agents looks like once knowledge and feedback stop being per-agent problems.

    Source: Dataverse Is Your Agent Data Platform: Here’s What’s New (Microsoft Power Platform Blog).

  • Microsoft Just Reframed Dataverse as the Agent Data Platform and the Update List Is Worth Reading

    Microsoft Just Reframed Dataverse as the Agent Data Platform and the Update List Is Worth Reading

    Dataverse agent data platform diagram showing knowledge sources, business skills, and Fabric integration

    Microsoft published a post on May 5 called Dataverse Is Your Agent Data Platform: Here’s What’s New. The framing is the part worth reading. Dataverse is no longer being sold as the database under your model-driven apps. It is being repositioned as the dataverse agent data platform, the layer that gives agents real business understanding instead of just rows and columns.

    That is a meaningful shift in how Microsoft wants you to think about the stack. I have been waiting for this framing to land properly.

    What it actually does

    The update bundles several things that were previously scattered across announcements into one coherent story.

    Knowledge sources let an agent ground itself in Dataverse tables, SharePoint sites, files, and external systems through a managed reference instead of a hand-rolled retrieval pipeline. The agent sees the data with its semantics: table relationships, choice columns, business rules. Not just a vector dump.

    Business skills are now first-class records in Dataverse. I wrote about this in Microsoft Just Shipped Business Skills in Dataverse. Skills move policy and process logic out of system prompts and into a managed, owned, versioned artifact. The May 5 post confirms this is the intended pattern, not an experiment.

    Deeper Fabric wiring means agents can reach analytical data through Dataverse without you stitching mirroring and shortcuts manually for every project. The semantic model carries through.

    Copilot Studio integration is tighter on the agent side. Connected agents in Copilot Studio can pick up Dataverse knowledge sources and skills as native primitives instead of you wiring them through custom connectors and Power Automate flows.

    None of these are individually new ideas. The point of the post is that they now line up as one platform story.

    Why it matters

    The hardest part of building an internal agent is not the model. It is getting the agent to behave like someone who actually works at your company. Org-specific policies, naming conventions, what counts as an active customer, which approval thresholds apply when. That tribal knowledge is where every agent project I have seen gets stuck.

    If that knowledge lives in a 4000-token system prompt, the agent degrades. If it lives in hardcoded Power Automate flows, nobody can find it six months later. If it lives in a Word document on someone’s OneDrive, it might as well not exist.

    The dataverse agent data platform framing says: put it in Dataverse as a typed, owned, versioned record, and let any agent on the stack consume it. That is an architectural decision, not a feature toggle. It changes who owns what. The policy owner updates the skill directly. The data steward owns the knowledge source. The agent builder stops guessing.

    The risk I keep flagging is skill sprawl. The moment multiple teams start writing skills with overlapping scopes, the agent starts misrouting silently. Governance has to come before deployment, not as a cleanup project in month six. Microsoft is shipping the platform. The org design is still on you. That same principle applies to Power Platform governance that does not kill adoption — the structural decisions made early determine whether the whole thing scales or stalls.

    I also want to see how this plays with multi-agent orchestration. I covered the patterns in multi-agent orchestration in Copilot Studio. If knowledge sources and skills become the shared substrate that connected agents draw from, the per-agent prompt size drops and routing gets more reliable. That is the part I find genuinely exciting.

    What I would do with it this week

    Three concrete things, in order.

    First, pick one existing agent that has a bloated system prompt. Anything past 2000 tokens. Pull out the policy chunks and rewrite them as business skills in Dataverse. Measure the prompt size before and after, and run your behavioral tests on both. You will see the consistency change in the edge cases.

    Second, take one knowledge source that today is glued together with a custom connector or a Power Automate flow doing retrieval. Replace it with a Dataverse knowledge source pointing at the same data. Compare the answers on questions that depend on relationships between tables. The native version handles joins the hand-rolled one fakes.

    Third, draft a one-page skill ownership matrix for your tenant before anyone writes a third skill. Who owns customer policy, who owns finance approvals, who owns HR routing. Boring document. Saves you from the sprawl that kills these projects.

    Read the Power Platform docs alongside the announcement. The framing finally matches what practitioners have been building toward. I am curious where it lands by the end of the quarter.

    Source: Dataverse Is Your Agent Data Platform: Here’s What’s New (Microsoft Power Platform Blog).

  • Microsoft Just Shipped Business Skills in Dataverse and This Is How You Teach Agents Your Org

    Microsoft Just Shipped Business Skills in Dataverse and This Is How You Teach Agents Your Org

    Dataverse business skills for agents announcement reaction

    Microsoft announced business skills in Dataverse on May 1, and this is the announcement I have been waiting for. Dataverse business skills for agents let you encode org processes, policies, and the tribal knowledge that lives in people’s heads as natural-language instructions. Agents discover them and follow them at runtime. No more cramming everything into a 4000-token system prompt and hoping the model remembers how your finance team handles approvals.

    I have been reading the docs since Friday. Here is my honest take.

    What business skills actually do

    A business skill is a Dataverse record. It contains a natural-language description of when the skill applies, what the agent should do, and what data or actions it can use. Agents query Dataverse at runtime, find the skills that match the user’s intent, and follow the instructions inside.

    The shape matters. You are not writing code. You are writing the kind of paragraph you would send to a new hire on day one. Things like: When someone asks about expense approvals over 5000 EUR, route to the regional finance lead, never to the team manager. The lookup table is in the Finance Approvers table. Always confirm the amount and the cost center before submitting.

    That description is stored, versioned, and indexed. Multiple agents can use the same skill. You update the skill once and every agent that discovers it picks up the new behavior. There is also a permission layer, so a skill can be scoped to a security role, a team, or an environment.

    Underneath, this is grounding. The agent does not memorize your org. It retrieves the relevant skill at runtime and follows it.

    Why this changes how you build internal agents

    The hardest part of deploying internal agents has never been the model. It has been getting the agent to behave like someone who actually works at your company. The model can reason. It cannot know that your procurement policy changed in March, or that the Madrid office handles APAC tickets on Wednesdays because of a coverage gap.

    Until now, that context lived in three bad places. System prompts that grew until they hit the context window and started degrading. Power Automate flows with hardcoded business logic that nobody could find six months later. Or worse, it lived nowhere and the agent guessed.

    I have written before that a focused 400-token instruction set produces more reliable behavior than a 4000-token one. Business skills make that practical. You stop stuffing the prompt and start composing skills. The agent picks the right ones for the job.

    The other thing this fixes is ownership. A business skill in Dataverse has an owner, an audit trail, and a lifecycle. When the policy changes, the policy owner updates the skill. They do not need to find the agent maker, file a ticket, or wait for a release. That is a real architectural shift, not a feature flag. If your org is still working out who owns what when policies change, Power Platform governance that does not kill adoption covers how to structure that before it becomes a cleanup problem.

    The risk I am watching: skill sprawl. If every team writes their own skills with overlapping scopes, the agent will face the same routing problem multi-agent setups face. Skill descriptions will start competing with each other and you will get silent misrouting. Governance has to come early, not as a cleanup project in month six.

    What I would do with it this week

    Pick one painful, well-bounded process. The kind where the answer is always it depends on who you ask. Approval routing is a good candidate. Onboarding checklists work too.

    Write three to five business skills that capture the rules. Keep each one short and specific. Connect them to a Copilot Studio agent that already has the right Dataverse and Power Automate connectors. Test with the messy questions, not the clean ones. Watch which skills get picked and which do not.

    The thing to measure is not whether the agent answers correctly. It is whether the right skill was selected for the right phrasing. If selection is unreliable, your skill descriptions are too similar or too vague. Rewrite them and try again. If you are also wiring up custom connectors to extend what the agent can reach, How to Build a Custom Connector for Copilot Studio Step by Step is worth keeping open in a tab.

    I will be writing more about this once I have run a real internal pilot. Early signals are good. In my experience, the patterns that survive contact with production are the ones where context is stored where it belongs, not where it was convenient at build time.

    This one belongs in Dataverse. Finally.

    Source: Introducing business skills: Teach agents how your organization works (Microsoft Power Platform Blog).

  • When should I build a multi-agent system instead of a single agent?

    When should I build a multi-agent system instead of a single agent?

    Diagram comparing single agent vs multi-agent system architecture

    Short answer: stay single-agent until you hit one of three specific failure modes. Tool overload past roughly 8 to 10 connectors. Conflicting system prompts that cannot be reconciled in one instruction set. Or genuinely parallel workstreams that need to run at the same time. If none of those apply, the single agent vs multi-agent question is already answered. Build one agent.

    Most posts on this topic make multi-agent sound like the natural next step. It is not. It is a tax you pay when a single agent can no longer do the job, not an upgrade you take because it sounds more sophisticated.

    The longer answer

    I read a good piece on Towards Data Science walking through ReAct workflows and when scaling to multi-agent makes sense. The framing matched what I keep running into when I talk to people building on Copilot Studio and similar platforms.

    A single agent is a loop. It reads, picks a tool, calls the tool, reads the result, picks again, until it decides it is done. That loop works well when the tool list is small enough for the model to reason over cleanly and the instructions do not pull the model in two directions.

    It starts breaking in predictable places.

    The first is tool overload. I have written before about how a model that hits 95 percent accuracy on tool selection with two connectors can drop to 70 percent with five, because tool descriptions start competing with each other. By the time you have ten or twelve tools, the agent picks the wrong one regularly and you cannot fix it with prompt tweaks.

    The second is prompt conflict. If your agent needs to behave like a strict policy checker for one task and a friendly explainer for another, those two personas fight inside one system prompt. You can feel it in the outputs. The model compromises in the wrong direction.

    The third is parallelism. A single agent loop is sequential by design. If you have three independent workstreams that must run at the same time, no amount of prompt engineering will make a single ReAct loop parallel. This is also where thinking through whether AI automation is even the right fit versus a simpler RPA approach becomes worth the time.

    Everything else, latency, observability, prompt size, can usually be solved without splitting agents.

    How to decide in practice

    I use a short checklist when someone asks about single agent vs multi-agent for a Copilot Studio build.

    Count the tools. If you are under eight connectors and the descriptions do not overlap, one agent is fine. Past ten with overlap, start thinking about splitting.

    Read the system prompt out loud. If it contains contradictory instructions for different scenarios, that is a real signal. Splitting reduces prompt size per agent, and a focused 400-token instruction set produces more reliable behavior than a 4000-token one. I covered this in more detail in my post on multi-agent orchestration patterns in Copilot Studio.

    Map the workstreams. Are they actually independent, or are they sequential steps you are calling parallel because it sounds nicer? Most automation work is sequential. Real parallelism is rarer than people think.

    Budget the latency. Every hop between agents adds round-trip overhead. If you split a single agent into three, you have just added two more model calls and two more HTTP boundaries to every request. I have written about how accumulated round-trip overhead kills perceived performance long before any single call gets slow.

    If the checklist points to multi-agent, default to a supervisor pattern. One parent agent routes to focused child agents. Skip the peer network where agents call each other freely. It looks elegant in diagrams and is painful to debug in production.

    Microsoft has shipped real multi-agent orchestration in Copilot Studio, so the platform support is there. The question is whether your problem actually needs it.

    Related gotchas

    Routing in Copilot Studio multi-agent setups depends on the description you write for each connected agent, not on trigger phrases. A vague description causes silent misrouting that is harder to debug than a broken trigger. Write descriptions like API contracts, not marketing copy.

    When a parent agent picks the wrong child confidently, you get the same failure mode as a single overloaded agent, just one layer deeper. Splitting agents does not eliminate misrouting. It moves it.

    Token costs multiply faster than you expect. Each agent in the chain re-processes context. Three agents in a sequence is not three times the cost. It is often closer to five or six times once you count the context each one needs to reason properly.

    If you are still on the fence, build single first. You can always split later. Going from multi-agent back to single, on the other hand, almost never happens once the architecture is in place. That is the trade-off worth keeping in mind. More on how I think about these trade-offs here.

    Frequently Asked Questions

    When should I use a single agent vs multi-agent system?

    Stick with a single agent until you run into one of three problems: too many tools causing the model to pick the wrong one, conflicting instructions that cannot coexist in one system prompt, or parallel workstreams that need to run at the same time. If none of those apply, a single agent is the right choice.

    How do I know if my agent has too many tools?

    A good rule of thumb is to keep your tool count under eight to ten connectors. Beyond that, tool descriptions start competing with each other and the model’s ability to select the right one drops noticeably, even if prompt tweaks do not seem to help.

    Why does a single agent struggle with conflicting instructions?

    When a system prompt asks the model to take on two opposing behaviours, such as acting as a strict policy checker and a friendly explainer, those personas create tension within a single instruction set. The model tends to compromise in ways that produce unreliable outputs rather than handling each mode correctly.

    What are the main reasons to build a multi-agent system?

    Multi-agent systems are worth the added complexity when you need genuinely parallel workstreams, have irreconcilable prompt conflicts, or are dealing with tool overload that cannot be resolved through better descriptions. Outside of those scenarios, the extra coordination overhead rarely pays off.

    Source: Attention Required! (Towards Data Science).

  • RPA vs AI Automation for Enterprise Workflows

    RPA vs AI Automation for Enterprise Workflows

    RPA vs AI automation comparison for enterprise workflows

    The decision I keep watching teams get wrong: should this workflow be built with RPA or with an AI agent. The RPA vs AI automation debate gets framed as old tech versus new tech, which is the wrong frame entirely. They solve different problems. Picking the wrong one is how you end up with a fragile bot that needs babysitting or an agent that hallucinates its way through invoice approvals.

    I have built both inside a large org. Here is how I actually decide.

    Determinism and predictability

    RPA assumes the screen, the field, and the click path are the same every time. If the SAP transaction code is VA01 today and VA01 tomorrow, RPA wins. It will execute that path 10,000 times with zero variance.

    AI automation assumes variance is the input. The email phrasing changes, the PDF layout changes, the customer asks the same thing five different ways. An agent reasons over that variance. It is non-deterministic by design, which is a feature for unstructured input and a liability for structured execution.

    Rule of thumb I use: if I can write the decision tree on a whiteboard in 15 minutes, it is RPA work. If the decision tree has more than 30 branches and half of them are “it depends on the wording,” it is agent work.

    Cost per execution

    Dimension RPA (Power Automate Desktop) AI Agent (Copilot Studio)
    Per-run cost Near zero after license Roughly 1 message credit per turn, often 5 to 15 turns per task
    License model Per-bot or per-user attended/unattended Message packs, 25,000 messages per pack
    Scaling cost Linear with bot count Linear with conversation volume and tool calls
    Failure cost Bot stops, you fix it Agent confidently completes the wrong task

    RPA at 100,000 runs a month is basically free compute after the license. An agent at 100,000 runs is not. I have seen teams underestimate this by an order of magnitude because they tested with 50 runs and extrapolated linearly without counting tool calls and orchestration turns.

    Maintenance and brittleness

    RPA breaks when the UI changes. A vendor pushes a new SAP Fiori update, three selectors shift, your bot fails at 3am. I have lived this. The fix is usually 30 minutes, but you need someone on call who knows the bot.

    AI agents break differently. They do not fail loudly. They drift. The model provider updates, your prompt that worked last month now produces a slightly different output format, and downstream parsing silently fails. I wrote about this in my agentic workflow post. The failure mode is worse because users find out three days later when the wrong invoice gets paid. If you are building flows that sit underneath an agent, Power Automate error handling patterns that actually work will save you from the silent failures that surface weeks after go-live.

    RPA maintenance is reactive and obvious. Agent maintenance is proactive and requires evaluation infrastructure most teams do not build.

    What the work actually looks like

    This is the dimension nobody compares on. Look at the input.

    Structured input, structured output, no judgment needed: RPA. Copying 200 rows from a legacy system into a SharePoint list, kicking off a daily report, screen-scraping a vendor portal that has no API. Boring, repetitive, deterministic. Power Automate Desktop handles this all day. If you are still deciding whether to invest time in the broader platform, RPA is not the right tool for every repetitive task is worth reading before you commit to a build.

    Unstructured input, structured output, judgment needed: AI. Reading 500 supplier emails and extracting the PO number, classifying tickets by intent, summarizing a 40-page contract into five bullet points. This is where Copilot Studio or a custom agent earns its cost.

    The hybrid case is the most common one and the one most teams miss. The agent reads the email, extracts the structured fields, then hands off to an RPA bot or a cloud flow that executes the deterministic part. The agent is the reasoning layer. RPA is the execution layer. They are not competitors. They are stacked.

    Governance and auditability

    RPA logs are simple. Action ran, action succeeded, here is the screenshot. Auditors love this.

    AI agents need decision logs, not just execution logs. You need to capture why the agent picked tool A over tool B. Most teams I talk to are not logging this and will get caught when the first compliance review hits. I covered this in The Real Shift Is Not Faster Work It Is Who Owns the Decision. Based on what I have built, this is the gap that bites you 6 months in, not on day one.

    Choose RPA if / Choose AI if

    Choose RPA if: the input is structured, the path is deterministic, the volume is high, the cost per run needs to be near zero, and the system has no API. This is most legacy integration work.

    Choose AI automation if: the input is unstructured, the work requires classification or extraction or summarization, variance is the norm, and you have the evaluation discipline to catch silent drift.

    Choose both if: you have a real workflow. Most enterprise automation is hybrid. The line is not RPA versus AI. It is figuring out which layer does what.

    Frequently Asked Questions

    What is the difference between RPA vs AI automation for enterprise workflows?

    RPA is built for repetitive, predictable tasks where the process follows the same steps every time, while AI automation handles unstructured or variable inputs that require reasoning. They are not competing technologies but tools suited to different problems. Choosing the wrong one leads to either a fragile bot or an agent making confident mistakes.

    When should I use RPA instead of an AI agent?

    Use RPA when your process is consistent, rule-based, and can be mapped out as a clear decision tree. If the same fields, screens, or steps repeat thousands of times without variation, RPA will be faster, cheaper, and more reliable than an AI agent.

    How do I know if AI automation is worth the cost for my workflow?

    AI agents consume message credits per turn and most tasks require multiple turns, so costs scale quickly at high volumes. Before committing, calculate expected monthly runs and multiply by average turns per task, not just per conversation. Teams often underestimate this significantly when testing at small scale.

    Why does RPA break so often in enterprise environments?

    RPA relies on fixed UI selectors, so any interface update from a vendor can shift elements and cause the bot to fail. These failures are usually quick to fix but require someone familiar with the bot to be available when issues occur. Unlike AI agents, RPA fails loudly and immediately rather than silently producing wrong results.

  • Microsoft Shipped Multi-Agent Orchestration in Copilot Studio and the Patterns Matter More Than the Feature

    Microsoft Shipped Multi-Agent Orchestration in Copilot Studio and the Patterns Matter More Than the Feature

    Multi-agent orchestration patterns in Copilot Studio diagram

    Microsoft shipped general availability of multi-agent orchestration in Copilot Studio this month, letting one agent call another agent as a skill, including agents built in Azure AI Foundry and external M365 Copilot agents. The announcement landed on the Copilot Studio docs and the blog feed last week. If you build agents inside Microsoft 365, this changes how you should think about agent design starting now.

    I have been testing it for a few days. The feature itself is straightforward. The interesting part is which multi-agent orchestration pattern you pick, because most teams will default to the wrong one and rebuild six months from now.

    What it actually does

    You can now register another agent as a connected agent inside Copilot Studio. The parent agent sees it as a tool. When the LLM decides the user request fits the connected agent’s described purpose, it hands off the conversation, gets a structured response back, and continues reasoning.

    Three things are worth knowing. The handoff is generative, meaning routing depends on the description you write for each connected agent, not on trigger phrases. The child agent runs with its own instructions, its own tools, and its own knowledge sources. And the parent agent receives the child’s output as context it can reason over, not as a final answer it must return verbatim.

    You can chain this. Parent calls child A, child A calls child B. You can also fan out, where the parent calls multiple children based on the request shape.

    Why it matters

    Single-agent designs hit a wall fast. I wrote about this in Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat. When one agent owns too many topics, routing fails at the edges, the system prompt balloons past 4000 tokens, and every change risks breaking three unrelated flows.

    Multi-agent orchestration lets you split by domain. One agent for HR queries, one for IT, one for finance, each with its own tight instructions and tool list. The parent becomes a router with personality. That sounds clean, and it can be, but only if you pick the right pattern.

    From what I have seen building and from what I hear from people at other organisations, three patterns keep showing up:

    Supervisor pattern. One parent agent owns the conversation, delegates to specialists, aggregates results. Best when the user does not need to know which agent is answering. Trade-off: the parent’s instructions become the bottleneck. If the parent picks the wrong child confidently, you get the same misrouting failure mode I described in my post on Copilot Studio agents passing tests and still failing in production, just one layer deeper and harder to debug.

    Sequential pipeline. Agent A produces output, agent B consumes it, agent C finalises. Best for structured workflows like draft, review, publish. Trade-off: latency stacks. Each hop adds seconds, and latency is the quiet killer of agentic workflows — budgeting round-trip time before you build matters more than most teams expect.

    Peer network. Agents call each other based on need, no fixed parent. Powerful, almost always premature. I have not seen a single internal use case where this beats a supervisor design once you account for debugging cost.

    The real win is not the multi-agent capability itself. It is the reduction in system prompt size per agent. When each agent has 400 tokens of focused instructions instead of 4000 tokens trying to cover everything, behavior gets predictable. Output testing gets meaningful. Drift gets easier to catch.

    What I would do with it this week

    Pick one existing Copilot Studio agent that has grown too many topics. Look at the system prompt. If it is over 2000 tokens or covers more than two distinct domains, it is a candidate.

    Split it. Create one child agent per domain. Move the relevant tools, knowledge sources, and instructions into the child. Write a clear description for each child, because that description is what the parent’s LLM uses to route. Vague descriptions kill routing accuracy faster than anything else. If you need to wire external capabilities into those child agents, building a custom connector for Copilot Studio is the practical path for connecting APIs that do not already have a prebuilt connector.

    Then test the edges. Phrasings that sit between two children. Requests that should hit two children sequentially. Requests that should fail cleanly when no child fits. The supervisor pattern looks great on the happy path. The behavior at the edges is what tells you whether the split was worth it.

    Multi-agent orchestration is not a silver bullet, it is a structural tool. Used right, it makes agents maintainable. Used wrong, it builds another silo with extra latency. The patterns matter more than the feature.

  • How to Build a Custom Connector for Copilot Studio Step by Step

    How to Build a Custom Connector for Copilot Studio Step by Step

    Building a custom connector for Copilot Studio with OpenAPI definition and authentication settings

    The built-in connectors cover a lot, but the moment you need to talk to an internal REST API from a Copilot Studio agent, you need a custom connector. This walkthrough builds a working copilot studio custom connector end to end, from the OpenAPI definition to the agent calling it as a tool with structured output the LLM can actually reason about.

    The result: an agent that calls an internal API, gets back a typed JSON response, and uses it in the conversation without guessing.

    Step 1: Get your API contract straight before you open the portal

    Do not start in Power Apps. Start with the API spec. You need an OpenAPI 2.0 (Swagger) file or a clear list of endpoints, methods, query parameters, request bodies, and response schemas.

    If your API returns 200 OK with an empty body on success, fix that first. An agent needs structured output to evaluate what happened. I learned this the hard way building agentic flows: returning {"status":"done"} is not enough. Return the actual record, the actual ID, the actual changed fields.

    Make sure every response has a defined schema. type: object with named properties. No loose additionalProperties: true dumps. The agent reads the schema to decide how to use the result.

    Step 2: Create the custom connector in the Power Platform maker portal

    Go to make.powerautomate.com, pick the right environment (this matters, custom connectors are environment-scoped), then Data, Custom connectors, New custom connector, Import an OpenAPI file.

    Upload your Swagger file. Fill in:

    • Host: api.yourdomain.com (no https prefix)
    • Base URL: /v1 or whatever your API uses
    • Scheme: HTTPS only. Do not ship HTTP.

    If you do not have a Swagger file, use the blank template and define operations manually. It is slower but gives you full control over operation IDs and summaries, which the agent uses to pick the right tool.

    Step 3: Configure authentication properly

    For internal enterprise APIs, OAuth 2.0 with Microsoft Entra ID is the only option I would ship. API key auth works for prototypes and falls apart the moment you need per-user identity in the agent. The same principle applies when thinking about Power Platform governance that does not kill adoption — authentication decisions made at the connector level affect every maker and every environment downstream.

    In the Security tab, pick OAuth 2.0, Identity Provider Azure Active Directory, and fill in:

    • Client ID: from your app registration
    • Client secret: from the same registration
    • Resource URL: the App ID URI of the API, for example api://your-api-app-id
    • Scope: the scope you exposed on the API app registration, e.g. access_as_user

    Save, then copy the Redirect URL Power Platform generates and add it to your Entra app registration’s redirect URIs. Skip this and you will get AADSTS50011 on every connection attempt.

    Step 4: Define operations with names the LLM can understand

    This is where most connectors fail as agent tools. The operation summary and description are not metadata. They are the prompt the LLM uses to pick the tool.

    Bad: GetData. Good: Get order details by order ID.

    For each operation set:

    • Summary: what the operation does, in plain English
    • Description: when to use it, what it returns
    • Operation ID: camelCase, descriptive, like getOrderById
    • Parameter descriptions: every parameter, including required vs optional

    Test each operation in the Test tab before moving on. If it does not return clean JSON here, it will not work in the agent.

    Step 5: Add the connector to a Copilot Studio agent as a tool

    Open your agent in Copilot Studio. Go to Tools, Add a tool, then pick Connector and find your custom connector. Microsoft’s docs on connector tools in Copilot Studio cover the UI changes if anything looks different in your tenant. If you are still getting oriented with the platform itself, If You Are Starting Copilot Studio in 2026 Skip the Chatbot Tutorials is worth reading before you wire up your first tool.

    For each operation you want to expose:

    • Review the auto-generated tool description. Rewrite it if it is vague.
    • Mark inputs as Dynamically fill with AI for parameters the LLM should infer from conversation, or Custom value for static config.
    • Set the connection. For testing, use your own. For production, configure end-user authentication so each user authenticates with their own identity.

    Step 6: Test it end to end with realistic input

    In the Test pane, do not type the obvious phrasing. Type how a real user would ask. Watch the activity map. You want to see the tool getting picked, the parameters extracted correctly, the response coming back as structured JSON, and the agent using specific values from that JSON in its reply.

    If the agent paraphrases instead of citing values, your response schema is too loose or the tool description is misleading. Tighten both.

    The final state and one common pitfall

    You now have a custom connector calling an authenticated internal API, registered as a tool the agent can invoke based on conversation context, returning structured data the LLM uses in its response.

    The pitfall to watch for: connection caching across environments. A connector that works in your dev environment will not auto-promote. You need to export the solution, import it into the next environment, and recreate the connection reference there. Skip that and your ALM pipeline will fail in ways that look like auth bugs but are really environment scoping. If your setup involves agents talking to external systems across multiple environments, the same scoping problems come up in Power Platform Agents Talking to GitHub Sounds Simple Until You Hit Enterprise Environment Sprawl.

    Frequently Asked Questions

    How do I create a custom connector in Copilot Studio?

    To build a Copilot Studio custom connector, start by preparing an OpenAPI 2.0 (Swagger) file that defines your API endpoints, parameters, and response schemas. Then go to make.powerautomate.com, navigate to Data, Custom Connectors, and import your Swagger file. From there you configure authentication, define your operations, and connect the connector to your Copilot Studio agent as a tool.

    What is the best authentication method for a custom connector in Power Platform?

    OAuth 2.0 with Microsoft Entra ID is the recommended approach for enterprise APIs, as API key authentication does not support per-user identity. Authentication choices made at the connector level affect every maker and environment that uses it downstream, so it is worth getting right from the start.

    Why does my Copilot Studio agent not understand the API response correctly?

    If your API returns a vague or empty response body, the agent has nothing structured to reason about. Every response should include a defined schema with named properties so the agent can interpret the result and decide how to use it in the conversation.

    When should I build a custom connector instead of using a built-in one?

    You need a custom connector when your Copilot Studio agent needs to call an internal or proprietary REST API that is not covered by the existing built-in connectors. If your use case involves company-specific data or internal services, a custom connector is the right path.