Halilcan Soran

Tag: Dataverse

  • Dataverse Plugin for Coding Agents Landed in the Cursor Marketplace and I Want to Wire It Up Today

    Dataverse Plugin for Coding Agents Landed in the Cursor Marketplace and I Want to Wire It Up Today

    Dataverse plugin cursor marketplace listing shown inside the Cursor editor

    Microsoft shipped the Dataverse plugin for coding agents to the Cursor Marketplace on July 21. That is the dataverse plugin cursor marketplace listing I have been waiting for since the plugin first landed for GitHub Copilot. Cursor is where a lot of developers I talk to actually spend their day, and now they can query, generate, and reason about Dataverse from inside that editor without switching windows.

    I am going to install this today. Here is what it does, why the distribution channel matters more than the feature list, and what I am pointing it at this week.

    What the dataverse plugin cursor marketplace listing actually does

    The plugin exposes Dataverse to Cursor’s agent as a tool surface. It reads live metadata from a connected environment, so when you ask the agent to generate a plugin, a custom API, a PCF control, or a complex Power Automate expression, it grounds the output in the actual table schema, column logical names, and relationships that exist in your target environment.

    That is the same grounding story I wrote about when the plugin first landed for coding agents. The model is not guessing at new_customerid versus cr123_customerid based on training data from tutorials. It is querying your environment and diffing against what is really there.

    Practically, in Cursor that means:

    • Ask the agent to scaffold a plugin registration and it uses your real entity metadata.
    • Ask it to write a fetchXML query and it validates against columns that exist.
    • Ask it to generate a TypeScript client for a custom API and the signatures match your published definitions.

    You connect it with an app user in a dev environment. Not System Administrator on prod. That was the wrong setup for the Copilot version and it is still the wrong setup here.

    Why the Cursor Marketplace channel matters

    The feature itself is not new. The distribution is. Microsoft meeting developers inside Cursor is a signal, and I think it is the more interesting story than the plugin capabilities.

    Cursor is not a Microsoft product. Two years ago I would not have expected the Power Platform team to ship a first-party plugin into a competing editor’s marketplace. That they did says the pro-code path into Dataverse is now considered strategic enough to follow developers wherever they already are, rather than trying to pull them back into VS Code or the maker studio.

    Marketplace distribution also changes the adoption math. Installing a plugin from a marketplace with a single click is a completely different friction curve than cloning a repo, running a setup script, and fighting with auth. I have watched pro devs skip the Dataverse story entirely because the tooling did not meet them where they work. This removes that excuse.

    There is a governance angle too. When your devs are pulling MCP-style tools from random community repos, your platform team has no view into what is connected. A first-party plugin in a known marketplace is auditable. It is the same trust-signal argument I made about certified MCPs in the July Dataverse update, just applied to the coding surface instead of the runtime surface.

    What I would do with it this week

    I have a dev environment with a solution I have been slowly refactoring. Custom tables, a few plugins, one custom API that needs a proper TypeScript client, and a PCF control that is still half-configured. That is my test bed.

    My plan for the week:

    • Install the plugin from the Cursor Marketplace and connect a least-privilege app user scoped only to the dev environment.
    • Point Cursor’s agent at the custom API and have it generate a typed client. Diff the output against what I would have written by hand.
    • Ask it to write a plugin that reacts to a specific message on a custom table and check whether it correctly uses my column logical names, not invented ones.
    • Try a deliberately ambiguous prompt (“add validation to the account form”) and see whether it grounds the answer in real metadata or hallucinates a JavaScript path.
    • Compare the same prompts side by side in Cursor and in the GitHub Copilot version to see if the tool responses diverge. The new Dataverse MCP server tool shape splits metadata inspection and querying into cleaner boundaries, so I am curious whether that distinction surfaces differently across editors.

    I will write up what I find. My prior from building things internally is that grounding fixes maybe 70 percent of the hallucination problem on Dataverse code, and the remaining 30 percent is prompt discipline and knowing when to stop trusting the agent. Curious to see whether Cursor’s agent loop changes that ratio in either direction. If you want a framework for thinking about where that remaining cost lands, the useful work per dollar measurement approach I laid out for Power Platform agents applies here too.

    If you live in Cursor, install it today and try it against a real solution, not a demo one.

    This post was inspired by Dataverse Plugin for Coding Agents Now Available in Cursor Marketplace via Microsoft Power Platform Blog.

  • Link to Fabric Just Got a UX Refresh and the Setup Friction Finally Drops

    Link to Fabric Just Got a UX Refresh and the Setup Friction Finally Drops

    Link to Fabric UX refresh setup screen in Power Platform

    Microsoft announced a Link to Fabric UX refresh on July 20, 2026. Same underlying capability, cleaner setup path. If you have been putting off wiring Dataverse into Fabric because the old flow felt heavy for anyone who is not a data engineer, this is the week to revisit it.

    I have set this thing up more times than I want to count. The capability was solid. The setup screens were where people bailed.

    What the Link to Fabric UX refresh actually does

    The refresh does not change what Link to Fabric is. You are still creating a managed replication of Dataverse tables into a Fabric workspace, landing them as Delta Parquet, and getting a SQL analytics endpoint on top. That plumbing is unchanged.

    What changed is the front door. The old flow had too many decision points stacked in the wrong order. You picked a workspace, then got prompted about capacity assignment, then got a table picker that dumped every table in the environment on you, then had to reason about which relationships and long-term retention flags mattered. Makers who were building a Power App and just wanted their data in Fabric for a Copilot grounding source would get halfway in and close the tab.

    The new flow collapses those decision points. Table selection is filtered and searchable by default. The workspace and capacity checks happen up front so you fail fast if permissions are wrong, instead of after you have already picked twelve tables. The confirmation screen actually tells you what will happen and roughly when.

    It is a UX pass, not a feature drop. That is fine. The feature was already there.

    Why the Link to Fabric UX refresh matters

    Setup friction is one of those things that sounds like a small thing until you count how many projects it kills. I have watched teams decide against Fabric entirely because their first attempt at Link to Fabric turned into a two-week ticket exchange with the platform team over capacity and workspace roles. By the time it was sorted, someone had already built a Power BI dataflow against the Dataverse connector and moved on.

    The other reason this matters is agents. I wrote about low-latency sync for Dataverse to Fabric going GA a while back. That closed the freshness gap. This closes the onboarding gap. If you are building agents that ground on Dataverse data through Fabric, both of those need to be easy. A capable data path that nobody sets up correctly is not a data path.

    The people who benefit most here are not the data engineers. They already had the old flow memorised. It is the Power Platform makers who own a solution end to end and need analytics or agent grounding without filing a ticket to a separate team. That is a real audience, and it has been underserved on this specific path for a while. If you are thinking about how to evaluate what that grounding work actually costs versus what it returns, measuring useful work per dollar for your Power Platform AI agents is worth reading alongside this.

    What you give up: nothing that I have found. The advanced controls are still there, they are just not in your face on step one.

    What I would do with it this week

    Three concrete things.

    First, take a Dataverse environment where you previously gave up on Link to Fabric and try it again. Time the setup. If it went from a half-day of back and forth to under thirty minutes, that is your signal to standardise on this path for future work.

    Second, wire a small agent against the resulting Fabric tables. Nothing fancy. A Copilot Studio agent with a knowledge source pointed at two or three tables you replicated. See how the answers feel with fresh data underneath. If you are still weighing whether to pull from SharePoint or Dataverse for that knowledge source, my SharePoint vs Dataverse as a Copilot Studio knowledge source comparison lays out the decision rule clearly. This is the loop I keep coming back to, and I have written more about how I think about grounding sources on my LinkedIn.

    Third, revisit your Link to Fabric documentation and admin guardrails. The easier the setup gets, the more makers will do it themselves, which means capacity governance and workspace access reviews matter more, not less. Easier onboarding without governance turns into skill sprawl’s cousin: workspace sprawl.

    The pattern here is familiar. Microsoft ships the capability, then eighteen months later ships the UX that makes people actually use the capability. That gap is where a lot of good features go to die. Glad this one did not.

    Next up on my watchlist: whether the same treatment lands on the mirroring configuration screens.

    This post was inspired by Announcing Link to Fabric UX refresh via Microsoft Power Platform Blog.

  • How to Measure Useful Work Per Dollar for Your Power Platform AI Agents

    How to Measure Useful Work Per Dollar for Your Power Platform AI Agents

    Power BI dashboard showing useful work per dollar for AI agents in Copilot Studio

    OpenAI published a piece on managing AI investments in the agentic era and the metric they anchor on is useful work per dollar. Not tokens per second. Not model benchmarks. Useful work per dollar for AI agents, measured against the actual business outcome the agent is supposed to produce. That framing maps cleanly onto Power Platform agents if you wire up the telemetry properly. This walkthrough shows how to instrument a Copilot Studio agent so you can see cost, task success rate, and useful work per dollar per workflow, then use that to decide what to scale and what to kill.

    The working result: a Dataverse table plus a Power BI page that gives you a per-agent, per-workflow view of cost efficiency in production. No guessing, no vibes.

    Step 1: Define what counts as useful work for the agent

    This is the step everyone skips and it is the one that decides whether the whole exercise is worth anything. Useful work is not “the agent responded.” It is the outcome the workflow is supposed to produce.

    For a support triage agent, useful work might be “ticket classified correctly and routed without human correction within 24 hours.” For an invoice extraction agent, it is “line items extracted with zero manual edits before posting.” For an internal knowledge agent, it is “user did not open a follow-up ticket on the same topic within 48 hours.”

    Write this down as a single boolean per invocation: isUsefulWork = true/false. If you cannot define it in one sentence, the agent probably does not have a clear job yet.

    Step 2: Log invocations and outcomes to Dataverse

    Create a Dataverse table called AgentInvocation with these columns at minimum: InvocationId, AgentName, WorkflowName, UserId, StartTime, EndTime, InputTokens, OutputTokens, ToolCallsCount, Outcome (choice: Success/Failure/Escalated), IsUsefulWork (bool), and Notes.

    In Copilot Studio, add a Power Automate flow at the end of the agent topic that writes a row to this table on every invocation. Pass the run context so you can correlate it later. For the IsUsefulWork field, you have two options: infer it automatically from a downstream signal (was the ticket reopened, did the invoice post, did the user thumbs-down) or capture it with a lightweight feedback prompt at the end of the conversation. I prefer downstream signals because self-reported feedback is noisy.

    Microsoft has a good primer on writing to Dataverse from flows if you have not done this pattern before.

    Step 3: Pull token and action costs into the same table

    Cost is not just tokens. For a Copilot Studio agent using Power Automate flows, tool calls, and premium connectors, the cost per invocation is a stack: model tokens plus per-message consumption plus any premium connector actions triggered inside tool flows.

    Build a simple cost model as a Dataverse calculated column or a Power BI measure:

    InvocationCost = (InputTokens * InputRate) + (OutputTokens * OutputRate) + (ToolCallsCount * FlowActionCost) + MessageMeterCost

    Get the current rates from your tenant’s Power Platform licensing page and your model provider. The exact rates will drift, so store them in a separate PricingRates table with an effective date rather than hardcoding them into the measure. Trust me on this one. I learned the hard way when connector pricing shifted and every dashboard I had was quietly wrong for a month.

    Step 4: Build the useful work per dollar view in Power BI

    Connect Power BI to the AgentInvocation table. Create three core measures:

    TotalCost = SUM(AgentInvocation[InvocationCost])

    UsefulWorkCount = CALCULATE(COUNTROWS(AgentInvocation), AgentInvocation[IsUsefulWork] = TRUE)

    UsefulWorkPerDollar = DIVIDE([UsefulWorkCount], [TotalCost])

    Build one page with a matrix visual: rows are WorkflowName, columns are the three measures plus task success rate and average invocation cost. Add a line chart showing useful work per dollar trending weekly per workflow. That trend line is the one you will actually look at.

    Slice by agent, by workflow, by user segment. The interesting patterns are usually in the segments, not the overall number. One workflow can be printing money while another quietly burns budget on retries.

    Step 5: Set a scale or kill threshold and review weekly

    Numbers without a decision rule are decoration. Set a threshold before you look at the data so you do not rationalize whatever the chart shows.

    My rule of thumb: if a workflow’s useful work per dollar is at least 3x the manual baseline (what the same work would cost in human time), it is a scale candidate. If it is below 1x for four weeks running, it gets killed or redesigned. Between 1x and 3x is the improvement zone: look at where the cost concentrates, usually retries, oversized system prompts, or unnecessary tool calls. If you want to understand what is driving those unnecessary tool calls, How Copilot Studio Agent Tool Selection Actually Works Under the Hood covers the orchestrator scoring pass and how to structure tools so the agent stops reaching for the wrong one.

    Review weekly. Monthly is too slow, daily is noise.

    Final state and one pitfall

    You end up with a Dataverse table capturing every invocation, a cost model that reflects real pricing, and a Power BI page that shows useful work per dollar per workflow with a scale-or-kill threshold. That is the whole loop.

    The common pitfall: measuring useful work by proxies that are easy to log rather than the ones that actually matter. “User did not thumbs-down” is not the same as “the work was correct.” Spend the extra effort to wire up a downstream signal, even if it means waiting 24 hours to mark an invocation useful. Noisy signals produce confident wrong decisions, and this is a place where being confidently wrong is expensive. If you want to see what happens when agents that looked fine in testing start failing on real signals, Why Do AI Agents Fail in Production When They Worked Fine in Testing walks through exactly that. For more on how I think about this stuff, see my LinkedIn.

    Frequently Asked Questions

    How do I measure useful work per dollar for AI agents in Power Platform?

    Start by defining a clear, binary outcome for each agent workflow, such as whether a ticket was routed correctly or an invoice posted without edits. Then log each invocation to Dataverse with cost and outcome data, and use Power BI to calculate the ratio of successful outcomes to total spend. This gives you a per-agent, per-workflow view of cost efficiency rather than relying on vague performance indicators.

    What is useful work in the context of a Copilot Studio agent?

    Useful work refers to the specific business outcome an agent is designed to produce, not simply the fact that it generated a response. For example, a support triage agent produces useful work only if the ticket is classified and routed correctly without human correction. If you cannot define that outcome in a single sentence, the agent likely lacks a clear purpose.

    How do I track AI agent invocation costs in Dataverse?

    Create a Dataverse table that records key details for every agent run, including token counts, tool calls, timestamps, and the workflow outcome. A Power Automate flow triggered at the end of each Copilot Studio topic can write this data automatically. Over time, this log gives you the raw numbers needed to calculate cost per successful outcome.

    When should I use downstream signals instead of user feedback to measure agent success?

    Downstream signals, such as whether a ticket was reopened or an invoice posted without edits, are generally more reliable than asking users to rate the interaction directly. Self-reported feedback tends to be inconsistent and easy to ignore, while automated signals reflect actual business outcomes. Use feedback prompts only when no suitable downstream signal exists for the workflow.

    This post was inspired by How to manage AI investments in the agentic era via OpenAI.

  • Dataverse July 2026 Update Extends the Agent Data Platform to More Coding Marketplaces and Certified MCPs

    Dataverse July 2026 Update Extends the Agent Data Platform to More Coding Marketplaces and Certified MCPs

    Dataverse July 2026 update expanding agent data platform with certified MCPs

    Microsoft shipped the July 2026 Dataverse update on July 6, and reading it back to back with the previous months makes the pattern obvious. The dataverse july 2026 update is not about new agent features. It is about reach and governance. The Dataverse plugin is expanding into more coding agent marketplaces, MCP tool coverage is growing, partner MCPs are getting certified, and internal MCPs are being pulled under enterprise governance.

    If you have been paying attention to the last three months of Dataverse announcements, this one fits the arc. Microsoft is turning Dataverse into the substrate every agent on the stack talks to, and now they are dealing with the mess that comes with that.

    What shipped in the July 2026 Dataverse update

    Four things landed together.

    First, the Dataverse plugin for coding agents is being pushed into more coding agent marketplaces. This is the same plugin that fixed the hallucination problem for coding agents generating Power Platform code. Wider distribution means more developers will hit it through their existing IDE and agent setups instead of having to hunt for it.

    Second, MCP tool coverage is growing. The Dataverse MCP server now exposes more of the platform surface, which continues the direction we saw when the tool shape shifted toward metadata inspection. Tighter tool boundaries, more of them, less guessing by the agent.

    Third, partner MCPs can now be certified. This is the one I think most teams will underestimate. Microsoft is publishing a certification path so third-party MCP servers can carry a trust signal. Think of it like connector certification, but for the agent tool layer.

    Fourth, internal MCPs get pulled under enterprise governance. DLP, environment scoping, audit. The plumbing you would expect from a Power Platform connector, applied to the MCP tool surface an agent can call.

    Why the certified MCP and governance angle matters

    Here is the part I keep thinking about. Every team I talk to that has been experimenting with agents in the last six months has quietly wired up MCP servers from wherever. Community repos. Vendor previews. Somebody’s GitHub. The tool surface an internal agent can reach is already sprawling, and nobody centralised the decision.

    Sound familiar? It is the same shape as the SharePoint site as a knowledge source problem I wrote about when knowledge sources and feedback loops shipped. Four makers, four wirings, no shared governance. MCP is worse because the surface is executable, not just readable.

    Certified partner MCPs are Microsoft’s answer to shadow adoption. Give platform teams a list of MCPs that carry a trust signal, register the ones that make sense, block the rest. The enterprise governance layer for internal MCPs is the other half. DLP policies that treat MCP tools like any other data movement. If you want to understand how the orchestrator evaluates tools before it ever calls them, how Copilot Studio agent tool selection actually works under the hood is worth reading alongside this update.

    The trade-off is real. Certification takes time. If your team needs a niche MCP that nobody has certified yet, you are either waiting or accepting risk. But the alternative is what I keep seeing on LinkedIn from people six months into agent projects. A tool surface nobody can inventory, and no clean way to answer the auditor when they ask what data the agent can touch. That sprawl is also one of the cleaner explanations for why AI agents fail in production when they worked fine in testing.

    What I would do with it this week

    I would not build a new agent this week. I would audit.

    Start with a simple inventory. Which MCP servers are already wired to any agent in your tenant. Where they came from. Who registered them. Whether they touch Dataverse, SharePoint, or anything with customer data. Most teams have never written this down.

    Then look at the certified partner MCP list as it lands and pick the two or three that actually match what your makers have been asking for. Register those under a governed environment. Publish the list internally. Say the quiet part out loud. If it is not on the list, it does not go into a production agent.

    Finally, get the Dataverse plugin for coding agents into the hands of the pro devs writing plugins and PCF controls. Not the citizen dev crowd. This is a pro dev tool and treating it otherwise misses the point. Scope it to a dev environment with a least-privilege app user, not System Administrator on production. I wrote about that setup in the original plugin post and it still applies.

    If you want to see how this ties back to the broader agent data platform direction, the Power Platform docs are catching up quickly and worth a scan. And if you want to compare notes on how other teams are handling MCP governance, I keep track of what people are saying on LinkedIn.

    The month the platform team gets ahead of MCP sprawl is worth more than the month you shipped one more agent.

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

  • SharePoint vs Dataverse as a Copilot Studio Knowledge Source

    SharePoint vs Dataverse as a Copilot Studio Knowledge Source

    SharePoint vs Dataverse copilot studio knowledge sources comparison

    Every Copilot Studio agent I have built or seen built starts with the same decision. Where does the knowledge live. SharePoint or Dataverse. The copilot studio knowledge sources picker makes it look like a flat choice. It is not. The two behave very differently once real content and real users hit them, and the wrong call shows up around month three when answers start drifting.

    I have been reading a lot about this lately and talking to people at other organisations who hit the same wall. Here is how I actually compare the two now, across four dimensions that matter.

    Content ceiling and file limits

    SharePoint as a knowledge source caps out at 4 SharePoint sites per agent, and Copilot Studio indexes the documents through Graph search. That sounds generous until you realise the same site is often wired into three agents with different filters, and indexing latency on freshly uploaded files can run several minutes before the agent sees them.

    Dataverse knowledge sources let you attach tables with up to 25 columns indexed for semantic search, and you can scope to specific rows with security roles. The ceiling is higher and the control is finer. The tradeoff is you have to actually get the content into Dataverse rows in the first place, which is real work if your source of truth is a folder of PDFs.

    Governance and ownership

    This is where I keep seeing teams pick wrong. SharePoint feels easy because the content is already there. But the same SharePoint site ends up wired four different ways by four different makers with no shared governance, which I wrote about in more detail when Dataverse got knowledge sources and agent feedback loops.

    Dataverse forces ownership. Each knowledge source is a managed record with an owner, a solution layer, and environment promotion. You can audit who changed what. With SharePoint sites, the agent sees whatever a site owner decides to upload that afternoon. That is not governance, that is hoping.

    Latency and answer quality

    Dimension SharePoint Dataverse
    Indexing latency 2-10 minutes typical Near real-time on row update
    Content ceiling 4 sites per agent Multiple tables, row-level filters
    Citation quality File and page reference Row-level with column context
    Governance Site owner discretion Solution-bound, owned record
    Setup effort Low if content already in SharePoint Higher, needs data model

    Citation quality matters more than people admit. When an agent cites a 200-page PDF in SharePoint, users still have to find the answer inside the document. With Dataverse row-level citations, the agent points at the specific record, which makes hallucinations easier to spot and correct. The new Dataverse MCP server tool shape splits metadata inspection, querying, and search into cleaner boundaries that make this even more precise for agents.

    Cost and licensing

    SharePoint knowledge sources use the standard SharePoint connector, which keeps things in the base licensing envelope for most internal scenarios. Dataverse knowledge sources mean Dataverse capacity, and depending on how much you index, that adds up. If near real-time data freshness is part of your argument for Dataverse, the low-latency sync from Dataverse to Fabric hitting GA is worth factoring into the broader data architecture conversation at the same time. Do not pay for Dataverse capacity you do not need.

    Microsoft documents the current connector and capacity behaviour in the Copilot Studio docs, and it is worth checking before you commit a topology.

    Choose SharePoint if, choose Dataverse if

    Choose SharePoint as your Copilot Studio knowledge source if the content is already in SharePoint, lives as documents rather than structured data, the agent serves under a few hundred users, and you can live with multi-minute indexing latency. It is the right call for a policy lookup agent pointed at an existing HR site.

    Choose Dataverse as your knowledge source if the content is structured, ownership and auditability matter, you need row-level security, or the agent is going to be promoted across environments under ALM. It is the right call for any agent that touches process logic, business skills, or anything a regulator could ask about later.

    The decision is not which one is better. It is which one matches the shape of your content and the seriousness of the use case. I have made the wrong call on this and paid for it in debugging time. Pick deliberately.

    Frequently Asked Questions

    What are the best copilot studio knowledge sources for enterprise agents?

    The two main copilot studio knowledge sources are SharePoint and Dataverse, and the right choice depends on your governance needs and content structure. SharePoint is quicker to set up if content already exists there, but Dataverse offers better control, row-level filtering, and near real-time indexing for more demanding use cases.

    When should I use Dataverse instead of SharePoint as a knowledge source in Copilot Studio?

    Dataverse is the better choice when you need strict governance, auditable ownership, or row-level security over your content. It also suits scenarios where indexing latency matters, since Dataverse updates are reflected near real-time compared to SharePoint’s typical 2-10 minute delay.

    Why does my Copilot Studio agent not pick up newly uploaded SharePoint files immediately?

    Copilot Studio indexes SharePoint content through Graph search, which can introduce a delay of several minutes before freshly uploaded files become visible to the agent. This latency is a known tradeoff of using SharePoint as a knowledge source rather than a structured data store like Dataverse.

    How do I improve answer quality in a Copilot Studio agent?

    Switching from SharePoint to Dataverse as your knowledge source can improve citation quality, since Dataverse returns row-level references with column context rather than broad file or page links. Scoping your knowledge source to well-structured tables with relevant columns indexed for semantic search also helps the agent return more precise answers.

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

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

    Dataverse MCP server tool shape diagram showing metadata inspection and query tools

    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.

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

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

    Low-latency sync Dataverse to Fabric GA architecture diagram

    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.

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

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

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