Category: Artificial Intelligence in Business

Dataverse MCP Server Got a New Tool Shape and the Metadata Inspection Story Is What Stands Out

Microsoft published a new post on June 8, 2026 walking through the updated Dataverse MCP server tool shape. The headline is that agents can now inspect metadata, query records, and search across structured and unstructured data through cleaner, well-defined tool boundaries. You can read the original write-up on the Power Platform blog.

This is not a feature dump. It is a redesign of how the agent talks to Dataverse. And that is more interesting than it sounds.

What it actually does

The old tool surface gave agents a handful of broad tools and expected them to figure out the rest from context. In practice, that meant the agent would call a query tool, get back something it could not interpret, call again with different parameters, fail, and burn tokens guessing at column logical names. I have watched this happen in traces. It is not pretty.

The new shape breaks the surface into clearer categories. Metadata inspection is its own thing now. The agent can ask what tables exist, what columns a table has, what the relationships look like, before it tries to query anything. Record querying sits next to that with predictable inputs. Search across structured and unstructured data is its own tool boundary, so the agent does not have to invent a strategy for whether to hit the relational side or the knowledge side.

The practical effect: fewer wasted tool calls, less prompt bloat from stuffing schema hints into the system prompt, and more predictable agent behavior when it hits a Dataverse environment cold.

Why it matters

This connects directly to a pattern I keep hitting. When you wire an agent to business data, the model is rarely the problem. The friction is the discovery loop. The agent does not know your schema. It does not know your naming conventions. It does not know that your account table has a custom column called cr1a3_segment that nobody documented.

The old answer was to dump schema into the system prompt. That works until your prompt crosses a few hundred tokens and agent reliability starts degrading. I wrote about this in the context of business skills in Dataverse, and the same logic applies here. Pushing knowledge into a managed, queryable surface beats stuffing it into a prompt every time.

The new tool shape gives the agent a path to discover the schema on demand instead of carrying it around. That is the architectural shift. It is the same lesson I keep seeing play out across the agent stack: tighter tool boundaries beat broader ones, because they shrink the search space the model has to reason about.

It also pairs well with the low-latency Dataverse to Fabric sync story. If your agent can inspect metadata cleanly on the operational side and pull near real-time analytical data on the Fabric side, the data path behind the agent finally starts feeling coherent instead of stitched together.

What I am skeptical about: tool shape changes are easy to undo if the team gets feedback that agents want more flexibility. I hope Microsoft holds the line on the boundaries. Broad, do-everything tools are how you end up back where you started.

What I would do with it this week

First, point an agent at a non-production Dataverse environment with the updated MCP server and watch the tool call traces. Not the chat output. The traces. That is where you see whether the new shape actually reduces wasted calls or just renames them.

Second, strip schema hints out of system prompts on any existing Copilot Studio agent wired to Dataverse, and let the metadata inspection tool do the work. Compare reliability before and after. I expect the shorter prompt wins, based on what I have seen building internally and on what I keep reading from peers at other organisations. The Dataverse plugin for coding agents that Microsoft shipped at Build 2026 is worth reading alongside this, because it tackles the same hallucination-from-missing-schema problem from a different angle. You can also check the Power Platform docs for the current setup steps.

Third, write down which tool should handle which question type for your agent and treat that as a contract. If the agent starts calling the search tool for things that should hit the query tool, that is a sign your boundary is wrong, not that the tool is wrong. I have been writing about these patterns on LinkedIn for a while now, and the discipline of writing the contract down before deployment saves you a month-six cleanup project.

If the new tool shape holds up under real workloads, this becomes the default way agents talk to business data on the Microsoft stack.

This post was inspired by Dataverse MCP Server: Understanding the New Tool Shape via Microsoft Power Platform Blog.

June 25, 2026
Azure Just Laid Out the Next Phase of Agentic Cloud Operations and the Insight to Action Loop Is What I Am Watching

Microsoft published From insight to action: The next phase of agentic cloud operations on June 25, and the framing is worth reading closely. The pitch for agentic cloud operations on Azure is no longer just copilots that surface insights. It is copilots that execute, chain decisions, and hand work between each other with approval gates in the middle.

I have been reading a lot about this lately and watching how it lands with people at other organisations. The marketing is doing a lot of work in places. The underlying direction is real.

What it actually does

The post lays out a few moving parts that matter if you run anything on Azure.

The FinOps copilot, the reliability copilot, and the security copilot are being repositioned as action-takers rather than dashboards with chat on top. Microsoft is describing a loop where signals come in from your environment, an agent proposes an action, a human (or another agent) approves it, and the action gets executed against the same control plane you already use. The agents can chain across domains. A reliability signal can trigger a FinOps reassessment. A security finding can pause a deployment.

The execution layer is the interesting bit. These are not agents writing a Teams message asking you to go fix something. They are calling ARM, Defender, Monitor, and Cost Management APIs with scoped permissions, and the audit trail lives in the platform.

The approval gate is the safety story. You can set policies for what an agent can do unattended versus what needs a human in the loop. That is the same pattern Power Platform uses for Dataverse business skills, and it is the right pattern. I looked at this when Microsoft shipped Dataverse business skills for agents and the approval boundary design there maps directly to what Azure is describing here.

Why it matters

The honest take: insight without action has been the broken promise of cloud operations for years. Every platform team I talk to has the same problem. The signal is there. The recommendation is there. Nobody has time to act on it. Cost recommendations sit in a tab for six months. Reliability advisor flags pile up. Security findings get triaged into a backlog that never drains.

Agentic cloud operations on Azure is interesting specifically because it tries to close that gap with execution, not with another dashboard. If the FinOps copilot can actually right-size a VM after approval instead of just telling me to, that is a real change in how on-call and platform engineering work.

Where the marketing is doing too much work: the chaining story. Cross-domain agent handoffs sound great in a blog post. In production, the failure mode is an agent making a FinOps decision based on a stale reliability signal, or a security agent pausing a deployment for a reason nobody can trace back two hops later. I have written about agentic workflow latency before, and chained agents compound that problem. Every handoff is another round trip, another context reconstruction, another place where the audit story gets fuzzy.

The other thing I keep thinking about: this changes what platform teams own. If the agent is taking actions on your subscription, the runbook is now a policy document, not a wiki page. Who owns the approval thresholds? Who reviews the agent’s action history? That is a leadership question, not a tooling question, and Microsoft’s intelligent apps post is really about that same tension between speed and decision rights, and most orgs avoid it because it is uncomfortable.

What I would do with it this week

I would not chain anything yet. I would pick one narrow loop and wire it up end to end.

Start with FinOps. Pick a non-production subscription. Turn on the action-taking mode for one specific recommendation type, like idle resource cleanup. Set the approval gate to require a human for anything above a small cost threshold. Let it run for two weeks. Read every action it took. See if the audit trail actually answers the question “why did this happen” without you having to reconstruct it.

Then, and only then, look at where this connects to Power Platform. The natural fit is the approval layer. An Azure agent proposes an action, the approval lands in a Power Automate flow that routes it to the right owner with context attached, the decision flows back. That is a useful pattern. It is also a place to be careful because you are now spanning two control planes, and Power Automate flows need explicit error handling for the case where the Azure-side action fails after approval. The Microsoft Build 2026 Fabric and Azure databases framing is also relevant here because the data layer that feeds these agents matters as much as the agents themselves.

The part I am genuinely watching is whether the cross-agent handoff story holds up in real environments or whether teams end up using one domain agent at a time for the next year. My bet is the latter, and that is fine. Single-domain action loops with clean approval gates would already be a meaningful step forward.

If this lands the way the post describes, the role of a platform engineer shifts from triaging recommendations to designing the policies the agents operate under. That is a more interesting job. I will be writing more about how this plays out as the patterns settle.

This post was inspired by From insight to action: The next phase of agentic cloud operations via Azure Blog.

June 25, 2026
Low-Latency Sync for Dataverse to Fabric Hit GA and This Closes a Real Gap in Near Real-Time Reporting

Microsoft announced on June 9 that low-latency sync for Dataverse to Fabric is GA. If you have ever tried to build operational reporting or trigger Fabric pipelines off Dynamics 365 CE or F&O data, you know the old replication window was the bottleneck. Low-latency sync for Dataverse to Fabric GA cuts that window down to something close to real-time, and it ships without requiring you to rearchitect the Link to Fabric setup you already have.

I have been waiting for this one. The old 15 to 60 minute lag killed a lot of conversations before they started.

What it actually does under the hood

Link to Fabric has been around for a while. The original mechanism mirrored Dataverse tables into a Fabric OneLake shortcut using a delta sync that ran on a schedule. Reliable, cheap, fine for daily or hourly reporting. Useless for anything operational.

Low-latency sync changes the replication path. Instead of waiting for the batch interval, Dataverse pushes change events into the Fabric-side tables on a much tighter cadence. Same OneLake destination. Same Delta format. Same shortcut model. The difference is the lag between a row being written in Dataverse and that row being queryable in Fabric.

You enable it in the Link to Fabric configuration in the Power Platform admin center. Existing links can opt in. You do not have to tear down what you built. That is the part that made me actually want to test it this week instead of next quarter.

One thing worth flagging. Low-latency sync is for the CE and F&O tables you already mirror. It is not a streaming pipeline replacement. If you need event streaming with custom transformations mid-flight, you still want Eventstream or a proper Spark job. This is operational reporting territory, not Kafka territory.

Why this matters for reporting and agent scenarios

Two reasons I care about this.

First, operational dashboards. Anyone who has had the conversation with a sales ops lead about “can we see pipeline movement today” knows the answer was usually no, or we faked it with a direct Dataverse query that fell over at any real volume. With low-latency sync, the Fabric copy is fresh enough that a Power BI report on the OneLake shortcut actually reflects what is happening on the floor. That is a real shift in what you can promise.

Second, and this is the one I am more interested in, agent scenarios. I have written before about Dataverse as the agent data platform. Agents that need to reason over historical or cross-table data are better off hitting the Fabric copy than hammering Dataverse directly. The old lag meant any agent reading from Fabric was working with stale context. A sales agent answering “what is the status of this account” off 30 minute old data is useless. Off near real-time data, it is finally credible.

The latency question on agentic workflows is one I keep coming back to. It is not always the model that is slow. Often it is the data path behind the model. That same theme came up when I covered how Microsoft Build 2026 made Fabric and Azure Databases the foundation for agentic apps, and the low-latency sync GA feels like a direct follow-through on that direction.

What I would do with it this week

Three things, none of which require rearchitecting.

One. Pick an existing Link to Fabric setup on a non-prod environment and enable low-latency sync on it. Measure the actual end-to-end lag. Write a row in Dataverse. Time how long until it shows up in a Fabric notebook query. The marketing number and the real number for your tenant are usually different. I want to know my number.

Two. Take one Power BI report that currently runs on a scheduled Dataverse refresh and repoint it at the OneLake shortcut. See if the freshness story holds up when a business user pokes at it. This is the cheapest way to prove the value internally.

Three. Wire a Fabric data pipeline to trigger off a Dataverse table change through the low-latency path and have it call back into a Power Automate flow via a webhook. This is the pattern I want to validate for agent grounding scenarios. Whether the trigger-to-action loop is tight enough to feel real-time end to end is the actual question. If you are also thinking about how Dataverse surfaces structured knowledge to agents, the post on Microsoft shipping business skills in Dataverse is worth reading alongside this one. The Link to Fabric docs have the setup details.

I will probably write up what I find. Curious how this lands for anyone running heavy F&O workloads where the table volumes are an order of magnitude bigger than CE.

This is the kind of plumbing release that does not get a keynote slot but quietly unblocks a year of stalled conversations.

This post was inspired by Announcing Low-latency sync for Dataverse to Fabric in GA via Microsoft Power Platform Blog.

June 21, 2026
Microsoft Shipped a Dataverse Plugin for Coding Agents and This Fixes the Hallucination Problem

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.

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

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.

June 14, 2026
Anthropic Dropped Claude Fable 5 Mythos 5 and the Long-Form Narrative Angle Is What Caught Me

Anthropic just shipped the Claude Fable 5 Mythos 5 release, a variant tuned specifically for long-form narrative and worldbuilding. You can read the announcement on the Anthropic news page. This is not a flagship capability bump. It is another specialized lineup entry, and the pattern is what caught my attention.

Finance Agents. Creative. Now Fable and Mythos. Anthropic is not just shipping bigger models. They are shipping shaped ones.

What it actually does

Fable 5 Mythos 5 is a Claude variant tuned for long-form fiction, worldbuilding, and narrative consistency. The headline improvements are in three areas.

First, long-context coherence. Holding a character voice, world rules, and plot threads across tens of thousands of tokens without drift is the actual hard problem in long-form generation. The model is tuned to keep internal consistency, names spelled the same way, magic systems that do not contradict themselves three chapters later, characters that do not forget what they did in chapter two.

Second, persona stability. Once you give it a narrator voice or a character voice, it holds it. Most general-purpose models start regressing toward a neutral helpful tone after a few thousand tokens. This one is trained to resist that pull.

Third, structural awareness. It understands scenes, beats, chapter structure, and pacing in a way that is closer to how writers actually think about their work, not as a flat stream of tokens.

This is not a model for code. It is not a model for tool use. It is a model for people who write novels, run tabletop campaigns, or build interactive narrative experiences.

Why it matters even if you are not writing fiction

I am not writing a fantasy novel this week. Most people reading this are not either. So why does this release matter?

Because the underlying improvements are exactly what agentic systems need.

Persona stability is the same problem as agent persona stability. If you are building a Copilot Studio agent that needs to talk like an HR specialist or a finance approver, the failure mode is identical: after enough turns, the agent regresses to generic assistant tone. The work Anthropic did to keep a narrator’s voice locked across 50,000 tokens is the same work that keeps your internal procurement agent from drifting into ChatGPT mode by message twelve.

Long-context coherence is the same problem as multi-turn agent memory. An agent that loses track of what it told the user three turns ago, or contradicts a constraint it acknowledged at the start of the session, is failing the same test a novel writing model fails when it changes a character’s eye color in chapter seven.

The specialization play is the real signal here. Anthropic is not selling one Claude. They are segmenting by job. As I wrote when Anthropic launched Claude Finance Agents, this is a deliberate move away from raw capability tiers and toward fit-for-purpose variants. That changes how you pick a model. Not “which is smartest” but “which is shaped for my job.”

This is also a hint about what the next round of enterprise variants will look like. If Fable and Mythos work commercially, expect more shaped Claudes. Legal. Medical. Compliance. The lineup is going to get longer, not shorter. The Anthropic enterprise AI services arm launching to deploy Claude in production is the infrastructure that makes this segmentation commercially viable at scale.

What I would do with it this week

Three things, in order.

One, read Anthropic’s own writeup carefully, not for the fiction angle but for what they say about persona retention and long-context evaluation. The eval methodology is the interesting part. If you build agents, those metrics are closer to what you should be measuring than HumanEval scores.

Two, run a quick comparison test on Claude. Take an agent system prompt you already have, one that defines a specific persona, and run a long multi-turn conversation on a general Claude variant. Note where the persona breaks. That gives you a baseline. When Fable Mythos style tuning eventually filters into general or enterprise variants, you will know what to measure.

Three, stop storing persona definitions in 4000-token system prompts. I have written about this before, and it stays true. If Anthropic is doing the persona work at the model level, your job is to give the model a tight, focused instruction set and let the tuning do the rest. A 400-token persona definition with clear constraints beats a 4000-token character bible every time. The same principle applies when you are thinking about whether to build a multi-agent system instead of a single agent: tighter scope and cleaner constraints outperform bloated configurations every time.

Anthropic is shipping shaped models faster than most teams can decide which one to use. That is a good problem to have.

This post was inspired by Claude Fable 5 Mythos 5 via Anthropic.

June 9, 2026
Power Pages Agentic Coding Hits GA and I Already Know Where I Am Pointing It First

Microsoft just announced Power Pages agentic coding GA for the GitHub Copilot CLI and Claude Code plugins. The official blog post went up today, June 9, 2026, and it moves the plugin from the preview we got a few months ago into something I can actually plan delivery around.

I wrote about why GA matters for Power Pages tooling when the news first broke. Now that it is live in the docs, I want to talk about where I would actually point it first.

What shipped

The Power Pages plugin for GitHub Copilot CLI and Claude Code is now generally available. In the preview you could describe a site in natural language, and the plugin would generate the scaffolding, set up Dataverse tables, wire up the Web API, and deploy the site. GA means the API contract is stable, the plugin is supported, and it can sit inside a real CI pipeline without the rug getting pulled.

The pattern is the same as before. You stay in your terminal. You describe what you want. The plugin grounds itself in your actual Power Platform environment, reads the existing tables and site settings, and generates Liquid, Web API calls, and configuration that match what is really there.

What it actually does

The thing that makes this different from generic AI code generation is environmental grounding. Asking ChatGPT to write Liquid for a Power Pages site produces output that looks right and breaks immediately on deploy, because the model has no idea what your tables are called or what permissions are wired up.

The Power Pages plugin reads your environment first. It knows your table names. It knows your site settings. It knows the authentication contact relationships. The generated code is diffable and committable, not a guess against a hypothetical portal.

The other thing GA changes: this is the difference between a side experiment and something I can put in a pipeline. Preview features at most large enterprises do not make it to production. Security review blocks them. Procurement blocks them. Internal policy blocks them. GA is the switch that lets a pro dev actually own a full portal project end to end without leaving the terminal.

Why it matters

Power Pages has always had a split personality. The maker studio handles front-end click work, and the layer underneath, covering Liquid templates, Web API calls, table permissions, and plugin logic, requires real code and environment-specific context. You end up configuring half the site in one place and half in the other, with no reliable way to keep them in sync.

Agentic coding at GA collapses that split for the pro dev path. You can scaffold tables, generate Liquid, wire up the Web API, and version the whole thing in git. That is a real shift in who can iterate on Power Pages sites and how fast they can do it. If you want more context on where agentic tooling is heading across the broader platform, Microsoft Build 2026 Made Fabric and Azure Databases the Foundation for Agentic Apps and the Direction Is Clear lays out the architecture story behind it.

I want to be careful about one thing. This is not a citizen dev tool. It looks like one because the entry point is natural language, but the output is code that needs to be reviewed, committed, and deployed through a pipeline. Treating it as a click-and-ship tool is how you end up with a portal that nobody can debug six months later. The Power Pages documentation is still required reading.

What I would do with it this week

I would not point this at a polished external portal first. That is the wrong target. The schema is too settled, the design system is too constrained, and the value of AI scaffolding is lowest when the requirements are clear.

I would point it at an internal-facing site where the schema is messy and the stakeholder keeps changing their mind. Think a request intake portal for a small ops team. A vendor onboarding tracker. An internal exception-handling site that nobody has gotten around to building because the requirements never sit still long enough. The Dataverse side of this gets more interesting now that Dataverse Just Got Knowledge Sources and Agent Feedback Loops, which gives the plugin even more to work with when it reads your environment.

Those are exactly the cases where regenerating the scaffolding cheaply matters. The stakeholder says “actually we need a new field and a different approval path” on Thursday afternoon, and instead of rewriting Liquid by hand, you describe the change and let the plugin redo the wiring against the current environment.

That is the workflow I want to test. I have spent enough time rebuilding intake portals because the requirements drifted to know exactly where this saves real hours.

GA is the green light. Now the question is which internal site gets to be the first one I rebuild.

This post was inspired by Build Power Pages Sites with AI through Agentic Coding tools, now Generally Available via Microsoft Power Platform Blog.

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

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.

June 7, 2026
Microsoft Build 2026 Made Fabric and Azure Databases the Foundation for Agentic Apps and the Direction Is Clear

Microsoft just dropped its Build 2026 post on building agentic apps with Microsoft Fabric and Microsoft Databases, and the framing is the story. This is not a feature drop dressed up as a vision post. Microsoft is putting microsoft fabric agentic apps at the center of how it wants you to build, and the message is direct: the agent layer sits downstream of the data layer, and if your data is not consolidated, your agents will not be reliable.

I read this twice. The second pass is where the direction gets clear.

What it actually does

The post pulls Fabric and the Azure database family (SQL, Cosmos DB, PostgreSQL) into a single story as the substrate for agentic apps. The pitch is that you build agents that reason over the same governed data your analytics and operational apps already use, instead of stitching together vector stores, copies of production tables, and a separate semantic layer.

Concretely, the announcements lean on three moves. Fabric becomes the unified surface for structured, unstructured, and vector data with agent-ready APIs on top. The Azure database family gets tighter native integration with Fabric mirroring and AI capabilities baked into the engines, so embeddings, retrieval, and grounding live next to the data instead of in a sidecar service. And the developer story positions agents as first-class workloads, not bolt-ons. You point an agent at a Fabric workspace, it knows about the data contracts, the lineage, the policies.

The thing I keep coming back to: Microsoft is no longer treating the agent as the product. The data platform is the product. The agent is just one consumer of it.

Why the microsoft fabric agentic apps direction matters

This lines up with something I have been saying for a while. 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. I wrote about that when Microsoft reframed Dataverse as the agent data platform, and Build 2026 extends the same logic up the stack. Dataverse handles the business policy and skills layer. Fabric handles the data and grounding layer. Both are now explicitly agent-aware.

If you are building on Power Platform and Azure and your data still lives across a SharePoint list, a legacy SQL box, a Synapse workspace nobody owns, and three Excel exports somebody emails on Tuesdays, this announcement is a warning shot. The friction is going to show up in a year. Your agents will hallucinate because grounding is inconsistent. Your latency will balloon because every retrieval crosses three services. Your governance story will not survive a single audit. I covered a related version of this problem when looking at Dataverse knowledge sources and agent feedback loops, and the data consolidation argument is the same one showing up here at the Fabric layer.

The trade-off is real. Consolidating on Fabric is not free. You give up some flexibility, you commit harder to the Microsoft stack, and you accept that Fabric capacity pricing is going to be a line item somebody fights about every quarter. But the alternative is building another silo, and silos are what kill agent reliability six months in.

The other piece I like: this framing kills the fantasy that you can buy your way into agentic apps by picking a better model. The model is not the bottleneck. The data contract is. Microsoft is finally saying that out loud.

What I would do with it this week

Three concrete things I want to poke at.

First, I would take one existing Copilot Studio agent that currently pulls from a Dataverse table and a SharePoint list, and rewire its grounding through a Fabric workspace with mirroring on the Dataverse side. Measure two things: retrieval latency end to end, and answer consistency across ten repeat questions. If Fabric mirroring holds up, that is a pattern I can reuse everywhere.

Second, I would build a tiny agent that reasons over a Cosmos DB collection using the native vector capabilities instead of pushing the data into a separate vector store. The question I want answered: does keeping embeddings next to the operational data actually reduce the drift problem, or does it just move the problem.

Third, I would map every current agent project against the question “is the data this agent depends on already in Fabric or on a clear path to it.” Anything that is not gets flagged. Not as a blocker, but as a known fragility. Before doing that mapping it is worth being honest about whether the agent even needs to be multi-agent in the first place — the single agent vs multi-agent decision shapes how complex your data dependencies get before you even write a line of grounding logic. I have learned the hard way that the architecture decisions you defer in month one are the ones that eat your weekends in month nine.

Microsoft just made the direction obvious. The teams that move on it now will be the ones not refactoring in 2027.

This post was inspired by Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases via Azure Blog.

June 7, 2026
Power Pages Agentic Coding Tools Just Went GA and the GitHub Copilot CLI Plugin Is What I Am Trying First

Microsoft just announced that the Power Pages agentic coding tools GA milestone is here. The plugins for GitHub Copilot CLI and Claude Code are now generally available, after a preview that landed earlier this year. You can read the full announcement on the Power Platform blog.

This is the part I have been waiting for. Power Pages site building is moving out of the maker portal and into the terminal where pro devs actually live. That changes who can credibly own a Power Pages project inside a large org.

What it actually does

The plugin sits inside GitHub Copilot CLI or Claude Code as an extension. You describe the site in natural language. The agent generates the scaffolding, sets up Dataverse tables, wires up the Web API, configures table permissions, and deploys the site.

The important bit is the grounding. The plugin is not asking the model to guess at Liquid syntax or invent table names. It reads your actual environment, your existing tables, your site settings, your authentication setup. The output lands in your repo as files you can diff, review, and commit.

You get the standard pro-dev loop. Branches. Pull requests. CI checks. Code review. The site definition is text, the agent generates text, and Git handles the rest. No more configuring half the site in the maker studio and the other half through manual file edits and praying the two stay in sync.

Why moving to GA actually matters

Preview features do not get deployed to production at most enterprises I talk to. Security reviews block them. Procurement blocks them. Internal policy blocks them. GA flips that switch.

More importantly, GA means the API contract is stable enough that you can build CI around it without expecting it to break next month. That is the difference between a fun side experiment and something a team commits to as a standard delivery pattern.

The bigger shift is cultural. Power Pages has always had a split personality. The studio handles the front-end click work, but the layer underneath, Liquid templates, Web API calls, table permissions, plugin logic, is real code. I wrote about this when the server-side skills landed. The maker portal hid the code layer behind a UI that pro devs did not want to touch and citizen devs could not safely change.

Pulling the build process into Copilot CLI or Claude Code lets a pro dev own the whole site end to end without leaving the terminal. That is a real unlock for the kind of internal portal work that has been stuck between teams for years. If you are also thinking about how multi-agent orchestration patterns in Copilot Studio fit alongside this kind of terminal-driven build loop, the two are worth thinking about together.

The trade-off is honest. This is not for citizen devs. If your maker has never opened a terminal, this is not their tool. The maker studio is not going away, and it should not. But for the portal projects where someone wanted to use Git, code review, and a real deployment pipeline and could not, the path now exists.

What I would do with it this week

I would pick the smallest internal Power Pages site I can find. Something with two or three tables, an authenticated user experience, and a form that writes back to Dataverse. Nothing customer-facing. Nothing with sensitive data.

Install the Power Pages plugin in GitHub Copilot CLI. Point it at a dev environment that mirrors a real one but is safe to break. Ask it to scaffold the site from a short description and let it generate the Dataverse tables and Web API config. If you want the agent to do more than scaffold, Dataverse knowledge sources and agent feedback loops are worth wiring in at this stage.

Then I would intentionally break something. Change a table permission by hand in the maker studio. Re-run the agent. See how it handles drift. That is the failure mode that will hurt in production, and you want to know the answer before you commit to this for a real project. I have learned the hard way that the demo path always works. The drift path is where tools live or die.

I would also run the same prompt through both the Copilot CLI plugin and the Claude Code plugin and compare the output. Same site, same description, two agents. The deltas will tell you a lot about which one to standardise on.

For anyone running portal projects inside a large org, this is the week to actually try it. The Power Pages docs have the setup steps and the plugin is a clean install.

The terminal is becoming a real surface for Power Platform work, and I am here for it.

This post was inspired by Build Power Pages Sites with AI through Agentic Coding tools, now Generally Available via Microsoft Power Platform Blog.

June 2, 2026