Halilcan Soran

Tag: Power Platform

  • Microsoft Shipped a Dataverse Plugin for Coding Agents and This Fixes the Hallucination Problem

    Microsoft Shipped a Dataverse Plugin for Coding Agents and This Fixes the Hallucination Problem

    Dataverse plugin coding agents architecture diagram

    On June 4, Microsoft announced the Dataverse plugin for coding agents as a companion to their Build 2026 session. The pitch is simple. Coding agents are powerful, but without domain tooling they hallucinate and produce broken solutions. The Dataverse plugin for coding agents gives GitHub Copilot, Claude Code, and other agents guardrailed access to tables, columns, relationships, views, security roles, and solutions.

    I have been waiting for this one. Every time I let a coding agent touch a Power Platform solution, I spent half the session correcting hallucinated table names, fake column logical names, and FetchXML that referenced relationships that do not exist. This is the missing context layer.

    What it actually does

    The plugin exposes Dataverse as a tool surface that coding agents can call directly. Instead of the agent guessing what your account table looks like in your environment, it queries the actual metadata. Tables, columns with their real logical names, relationships, option sets, views, security roles, and solution boundaries. All grounded in the environment you point it at.

    It also handles writes through the same guardrailed path. The agent can scaffold a new table, add columns, set up a relationship, or modify a view, but it does it through the Dataverse API with proper solution awareness, not by generating XML files and hoping the import does not blow up. Solution context matters here. The plugin respects which solution you are working in, so the agent is not silently dropping unmanaged customizations into the default solution.

    The trade-off is permissions. The agent runs with the credentials you give it, which means scoping matters. You do not want a coding agent with System Administrator on a production environment. A dedicated app user with a least-privilege role on a dev environment is the sane setup.

    Why the Dataverse plugin for coding agents matters

    I have been saying for months that the hardest part of agent work is not the model, it is the context. Microsoft Just Shipped Business Skills in Dataverse and This Is How You Teach Agents Your Org fixed this for runtime agents. This fixes it for build-time agents.

    Think about what coding agents were doing before this. You ask Claude or Copilot to write a plugin against the contact table. It writes confident C# that references new_customerstatus as a column. That column does not exist in your environment. It exists in a tutorial the model saw during training. You compile, deploy, fail, debug, fix, repeat. The agent was fast at producing wrong code.

    With the plugin wired in, the agent reads your actual schema first. The generated code references real columns. FetchXML targets relationships that exist. Security role assignments use role IDs that resolve. The output goes from speculative to diffable.

    This is the same architectural shift the Power Pages agentic coding tools made. Ground the agent in the environment, then let it generate. The grounding is what turns these tools from impressive demos into something a pro dev team can commit to in CI.

    One more thing. This is explicitly a pro dev tool. It is not for citizen devs. The audience is the team writing plugins, custom APIs, PCF controls, and complex flows where hallucinated metadata costs hours. If your shop is doing solution-aware Power Platform work in source control, this changes the daily loop.

    What I would do with it this week

    I would spin up a sandbox environment with a copy of one of our more complex solutions. Maybe twenty tables, a handful of plugins, a few custom APIs. Wire the plugin into a coding agent against that environment with an app user scoped to a non-destructive role.

    Then I would run three tests. First, ask the agent to generate a plugin that does something the existing code already does, and diff the output against the real code. That tells me how close the grounded output gets. Second, ask it to extend an existing entity with new logic and check whether it picks the right solution context. Third, ask it to write FetchXML against a relationship chain three hops deep, because that is where hallucination used to be the worst.

    If those three pass, the next step is figuring out where this fits in the actual development workflow. Local agent runs for scaffolding, reviewed PRs into source control, normal pipeline deploys. The plugin does not change the deployment story. It changes what shows up in the PR. If you want to see how Microsoft has been building toward this foundation, the Microsoft Build 2026 Fabric and Azure Databases session makes the data-first direction clear.

    The Dataverse plugin for coding agents is the kind of release that is boring on the surface and quietly reshapes how a team builds. Read the Power Platform docs on it, scope an app user, and start testing this week. I will be writing more about what I find on LinkedIn as I push it through real workloads.

    The grounding layer for build-time agents has arrived. Now the work is wiring it into how teams actually ship.

    This post was inspired by Microsoft Dataverse Plugin: Unleashing Coding Agents on the Enterprise – Microsoft Build 2026 via Microsoft Power Platform Blog.

  • 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.

    This post was inspired by What’s new in Power Platform: June 2026 feature update via 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.

    This post was inspired by What’s new in Power Platform: May 2026 feature update via 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.

    This post was inspired by How To Create Copilot Custom UI Widgets In Power Apps via Matthew Devaney (Power Apps).

  • Dataverse Just Got Knowledge Sources and Agent Feedback Loops and I Want to Wire These Up Now

    Dataverse Just Got Knowledge Sources and Agent Feedback Loops and I Want to Wire These Up Now

    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.

    This post was inspired by Dataverse Is Your Agent Data Platform: Here’s What’s New via Microsoft Power Platform Blog.

  • Power Platform May 2026 Update Shipped and UDTs Going GA Is the Headline for Me

    Power Platform May 2026 Update Shipped and UDTs Going GA Is the Headline for Me

    Power Fx user defined types GA in the May 2026 Power Platform update

    The May 2026 Power Platform feature update dropped on May 14 and the list is long. Copilot updates, Dataverse changes, governance bits. But the one item I keep coming back to is Power Fx user defined types going generally available. If you write any non-trivial Power Apps, this is the change that matters. UDTs are GA as of version 3.26044, enabled for new apps by default, and switchable on existing apps through settings.

    What Power Fx user defined types GA actually does

    UDTs let you define a named, structured type once and use it everywhere in your app. You declare them with the Type function in the App’s OnStart or named formulas. Something like Type({ Id: Text, Name: Text, Status: Text, DueDate: DateTime }) bound to a name, and now every function signature, every variable, every collection can reference that type by name.

    Before UDTs, type information in Power Fx was inferred from whatever record you happened to pass first. Pass a record with one less field and Power Fx would silently widen or narrow the schema. Build a component that took a record parameter and good luck enforcing what was inside it. The result was a lot of defensive coding, a lot of IfError, and a lot of runtime surprises.

    With UDTs you get a contract. A function expects a specific shape. A component prop declares what it accepts. Collections carry a known schema instead of guessing from the first row. The Type function reference covers the syntax if you want the official version.

    Why it matters for app maintainability

    Power Apps has had a maintainability problem for years. Not because the platform is bad. Because untyped records meant every medium-sized app slowly turned into a pile of implicit assumptions. You open someone else’s screen six months later and you cannot tell what shape locSelectedItem is supposed to be without running the app and inspecting it live.

    UDTs make those assumptions explicit. The variable has a type. The component prop has a type. The function returns a type. When the schema changes, you change it in one place and Power Fx tells you everywhere it breaks. That is the difference between a 2000-line app you are afraid to touch and one you can actually refactor.

    There is a real trade-off though. You give up some of the speed of just throwing a record into a variable and moving on. For tiny apps that is overkill. For anything that more than one person touches, or anything that lives longer than a quarter, the upfront type definition pays for itself the first time you onboard a new developer.

    The other thing UDTs do, and this is the part I find more interesting, is that they make Power Fx feel like a language you can actually build component libraries in. Reusable components have been technically possible for a while. They have not been pleasant because the prop interface was loose. With named types, a component library starts looking like an SDK instead of a copy-paste exercise. If you are thinking about how governance fits around that kind of library work, Power Platform governance that does not kill adoption is worth a read before you start standardising component patterns across teams.

    What I would do with Power Fx user defined types this week

    Pick one existing canvas app. Not a critical one. Something internal that you wrote and you are tired of debugging. Enable UDTs through settings, updates, new, user-defined types.

    Then find the single record shape that gets passed around the most. The selected item from your main gallery, the form values for your main edit screen, the API response from your most-used connector. Define it as a UDT in App.OnStart with the Type function. Give it a clear name. Refactor the three or four places that record gets read or written to use the named type.

    You will hit one or two spots where Power Fx now flags a mismatch that was silently working before. That is the point. Those mismatches were latent bugs. Fix them. Then look at any component you wrote that takes a record input and convert the prop to your new named type.

    That is enough for week one. Do not try to type the whole app at once. The way I have seen this go sideways elsewhere is people treating UDTs like a migration project instead of a habit. Start with one type, one screen, one component. Build the muscle.

    I have written before about moving business logic out of system prompts and into managed artifacts, and UDTs are the same idea at the Power Fx layer. Put the contract in one place, let everything else reference it, and stop hiding the schema in tribal knowledge. If you are wiring typed records into flows alongside your canvas apps, the Power Automate error handling patterns post covers how to keep that layer equally explicit about what it expects and what it does when things break. More notes on what I am building with this are on my LinkedIn.

    This is the kind of change that does not look exciting in a release post and ends up changing how I write Power Fx every day.

    This post was inspired by What’s new in Power Platform: May 2026 feature update via Microsoft Power Platform Blog.

  • Microsoft’s Intelligent Apps Post Is About Leadership and I Think They Buried the Lede

    Microsoft’s Intelligent Apps Post Is About Leadership and I Think They Buried the Lede

    Intelligent apps and human leadership in enterprise automation

    I opened Microsoft’s April post on intelligent apps and human leadership expecting another speed pitch. Faster tasks. Faster decisions. Faster output. The usual rhythm. What I actually read was a piece where the words intelligent apps and human leadership are deliberately bolted together, and I think most people skimmed past the second half.

    The leadership piece is doing all the work in that post. The intelligent app is the easy half. I keep seeing automation teams treat AI features as a productivity multiplier when the actual constraint is whether anyone in the org is willing to redesign how decisions get made. Skip that, and you ship faster versions of the same broken workflows.

    I read the post expecting another speed pitch and got something else

    Microsoft could have written a clean speed story. They have the numbers for it. Instead the framing is that intelligent apps need a new shape of work, and that shape is built by humans who lead differently, not by humans who type faster.

    That is not a marketing flourish. That is the part of the message that decides whether your AI rollout pays off or quietly burns budget. I have been writing about decision ownership for a while now, and this post is the closest I have seen Microsoft come to saying it out loud.

    Speed is a trap when the underlying decision rights have not moved

    Here is what I keep running into. A team takes a slow approval process. They drop an agent in the middle of it. The agent now drafts the recommendation in two seconds. Approval still takes four days because three managers still need to sign off, and none of them changed how they review.

    You did not speed up the process. You sped up the part nobody was waiting on.

    Worse, the agent now produces ten times the volume of recommendations the approval chain was sized for. The queue grows. People rubber-stamp to keep up. The quality of the decision drops while the appearance of throughput goes up. I have written before that automating a bad process just makes it fail faster. Intelligent apps make this failure mode worse, not better, because the speed gap between the AI step and the human step gets wider. This dynamic is one reason RPA vs AI automation comparisons often miss the point — neither technology fixes a process where decision rights have not moved.

    If decision rights do not move, speed is a trap.

    What human leadership actually has to do for an intelligent app to work

    The Microsoft post uses the phrase human leadership as if everyone knows what it means. I do not think we do. So here is what I think it has to mean operationally for an intelligent app to actually pay off.

    First, someone with authority has to redraw the decision boundary. Which calls does the agent make on its own. Which calls go to a human. Which calls require two humans. That is not a developer task. That is a leadership task, and most orgs avoid it because it is uncomfortable.

    Second, the constraints the agent operates under have to be owned by a person, not buried in a system prompt. This is exactly why Microsoft’s business skills in Dataverse matter. They give policy a home with an owner and a version history. Without that, your intelligent app is running on tribal knowledge that nobody can update.

    Third, leaders have to stop measuring the team on volume of approvals or tickets closed. If the agent is doing the routine work, the human metric has to shift to quality of exception handling and quality of policy. Otherwise you are paying senior people to do work an agent already did.

    None of this is a feature you ship. All of it is org design. The Power Platform tooling will not do it for you.

    The teams I see getting this right are doing one specific thing first

    The teams I talk to who are actually getting value out of intelligent apps and human leadership do one thing before they build anything. They write down, on one page, who currently owns each decision in the process and who will own it after the agent ships. Same column, different rows. The delta is the work.

    That page is uncomfortable to produce. It surfaces the fact that some managers are about to lose a piece of their job, that some policies have no clear owner, and that some approval steps exist only because nobody ever questioned them. This is the part most teams skip, because it is political, not technical. It is also why most Power Platform Center of Excellence setups stall in month three — the governance conversation requires the same political work that most teams defer until it is too late.

    The teams that skip it ship a working app and wonder six months later why nothing changed. The teams that do it ship a smaller app and quietly reshape how a department works.

    So my read on the Microsoft post is this. They did not bury the lede by accident. The lede is human leadership. The intelligent app is the part of the story everyone is comfortable talking about. The other half is the part that decides whether any of this matters.

    If you want to see how I think about this kind of org-shaped problem, more of my writing is on LinkedIn. The technology is rarely the bottleneck. The willingness to move decisions is.

    Frequently Asked Questions

    What is the relationship between intelligent apps and human leadership in the workplace?

    Intelligent apps only deliver real value when human leadership changes how decisions are made, not just how fast tasks are completed. Without redesigning decision rights and workflows, AI tools tend to accelerate broken processes rather than fix them.

    Why does automating an existing process sometimes make things worse?

    Automation increases the speed and volume of outputs, but if the approval or review process stays the same, the bottleneck simply gets worse. Teams end up rubber-stamping decisions to keep pace, which lowers quality while creating the illusion of better throughput.

    How do I know if my organisation is ready for an AI automation rollout?

    A good starting point is asking whether decision rights have been clearly assigned and whether leaders are willing to redesign how approvals and reviews work. If those structures are unchanged, adding AI tools is likely to surface existing problems faster rather than solve them.

    When should I redesign workflows before deploying intelligent apps?

    Workflow redesign should happen before deployment, not after. If the human steps in a process have not been updated to match the speed and volume AI generates, the technology will outpace the people it is meant to support.

    This post was inspired by Intelligent apps, human leadership, and the new shape of work via 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.

    This post was inspired by Dataverse Is Your Agent Data Platform: Here’s What’s New via 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.

    This post was inspired by Introducing business skills: Teach agents how your organization works via 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.

    This post was inspired by Single Agent vs Multi-Agent: When to Build a Multi-Agent System via Towards Data Science.