How does MCP work under the hood when an agent calls a tool?

MCP is a stateful client-server protocol built on JSON-RPC 2.0, not a simple function-calling wrapper. Before any tool call happens, the client and server go through a capability negotiation handshake, the server declares what it supports, and only then does tool discovery take place. The connection stays live as a session rather than being a stateless request like a REST call.

What is the MCP handshake and why does it matter?

When an MCP client connects to a server, it sends an initialize request containing its protocol version and capabilities, and the server responds with its own. The client then sends an initialized notification to confirm the exchange before any tools are listed or called. Skipping this step or misunderstanding it is a common reason real implementations break outside of demos.

What is the difference between MCP and a standard REST connector?

A REST connector is stateless, meaning each request stands alone with no shared context. MCP maintains a live session, negotiates capabilities upfront, and exposes tools, resources, and prompts as distinct primitives. This makes it better suited for agents that need to understand what a server can do before deciding how to use it.

Why does MCP use JSON-RPC 2.0 instead of a simpler format?

JSON-RPC 2.0 gives MCP a lightweight but structured message format that distinguishes requests from notifications and pairs responses to the correct request using an id field. This structure supports the sequenced, session-based communication that MCP requires, while remaining simple enough to implement across different clients and servers.

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.

Category: Artificial Intelligence in Business

How MCP Actually Works Under the Hood When an Agent Calls a Tool
Most people treat MCP as the thing that lets their agent call tools, as if it were a fancier function-calling wrapper. That mental model gets you through demos and breaks the moment you try to run something real. If you want to understand how MCP works under the hood, you have to stop thinking about it as a plugin format and start thinking about it as a stateful client-server protocol built on JSON-RPC 2.0.

Towards Data Science published a solid walkthrough of the protocol recently, MCP Explained: How Modern AI Agents Connect to the Real World, and it lines up with what I have been reading in the official Model Context Protocol spec. This post is my attempt to compress the mechanism into a mental model you can actually use when you design servers for Power Platform agents.

The Surface Behaviour: What You See When an Agent Calls an MCP Tool

From the outside, an MCP call looks trivial. You wire an MCP server into Copilot Studio or a Power Apps agent, the agent picks a tool, arguments get filled in, a result comes back, and the model uses it in the next turn. It feels indistinguishable from a REST connector.

That is the illusion. Underneath, three things are happening that a REST connector never does: the client and server negotiated capabilities before any tool call happened, the server is exposing tools, resources, and prompts as separate primitives, and the connection is a live session, not a stateless request. The agent is not just calling an endpoint. It is holding a conversation with a server that has told it what it can do.

Underneath: JSON-RPC, the Handshake, and Capability Negotiation

MCP rides on JSON-RPC 2.0. Every message is a JSON object with a method, params, and either an id (for requests) or no id (for notifications). Nothing exotic. What matters is the sequence.

When an MCP client connects to a server, the first thing it sends is an initialize request. This carries the client’s protocol version and its capabilities. The server responds with its own protocol version, its capabilities, and metadata like server name and version. The client then sends an initialized notification to confirm the handshake is done. Only after this does tool discovery happen, usually through a tools/list call.

Capability negotiation is the piece people miss. The server advertises whether it supports tools, resources, prompts, sampling, logging, and so on. The client picks up only what it understands. This is why an MCP server built against a newer spec can still work with an older client. Backward compatibility is baked into the protocol.

Then there are the three primitives:
- Tools are model-invoked. The agent decides when to call them.
- Resources are application-controlled. The host app decides what to expose.
- Prompts are user-invoked. Templates the user can trigger.
Most people conflate all three into tools. That is why their MCP servers feel bloated. If a chunk of data is really a reference document, it should be a resource, not a tool. Tools are for actions with side effects or computed answers.

Edges and Limits: Transports, Session State, Schema Drift, and Auth

MCP is transport-agnostic in principle but the two real options are stdio and HTTP with Server-Sent Events (or the newer streamable HTTP transport). Stdio is fine for local dev. For anything hosted, you are on HTTP, and that opens the usual questions about session identity, reconnection, and load balancing.

Session state is the first sharp edge. An MCP session is stateful. If your server is behind a load balancer with no sticky sessions, you will see broken initialize sequences and mysterious method not found errors after a reconnect. This is not a bug. It is the protocol working as designed against infrastructure that assumed statelessness.

Schema drift is the second. Tool schemas are exchanged at tools/list time. If your server changes a tool’s input schema mid-session without notifying the client via notifications/tools/list_changed, the agent will keep calling the old shape and fail silently or noisily depending on how strict your validation is. The new Dataverse MCP server tool shape is a good example of what a clean split between metadata inspection, querying, and search actually looks like in practice.

Auth is the third. The core MCP spec deliberately left auth as a transport concern for a long time. The newer authorization spec pins it to OAuth 2.1. If you are wiring an MCP server into an enterprise agent, this is where you spend most of your time, not on the tool logic itself.

What This Means When You Build an MCP Server for Power Platform Agents

A few concrete implications for anyone pointing Copilot Studio or Power Apps agents at MCP.

Design tool descriptions as retrieval hints, not documentation. I wrote about this in how Copilot Studio agent tool selection actually works. The orchestrator scores names, descriptions, and parameter names together. MCP does not change that. It just gives you a cleaner surface to expose them from.

Split tools, resources, and prompts properly. If you dump everything as tools, you inflate the tool count, degrade selection quality past ten to fifteen entries, and force the model to reason about things that should have been passive context.

Treat session lifetime as part of your design. Idle timeouts, reconnect logic, and schema change notifications are not edge cases. They are the load-bearing parts of a production MCP server. The same session and state management issues are a core reason AI agents fail in production when they worked fine in testing.

MCP is not a plugin format. It is a protocol. Build servers like protocol servers and the sharp edges stop cutting. Skip that and you are building another silo with extra JSON on top. In my day-to-day, that shift in framing is what changes the design.

Frequently Asked Questions

How does MCP work under the hood when an agent calls a tool?

MCP is a stateful client-server protocol built on JSON-RPC 2.0, not a simple function-calling wrapper. Before any tool call happens, the client and server go through a capability negotiation handshake, the server declares what it supports, and only then does tool discovery take place. The connection stays live as a session rather than being a stateless request like a REST call.

What is the MCP handshake and why does it matter?

When an MCP client connects to a server, it sends an initialize request containing its protocol version and capabilities, and the server responds with its own. The client then sends an initialized notification to confirm the exchange before any tools are listed or called. Skipping this step or misunderstanding it is a common reason real implementations break outside of demos.

What is the difference between MCP and a standard REST connector?

A REST connector is stateless, meaning each request stands alone with no shared context. MCP maintains a live session, negotiates capabilities upfront, and exposes tools, resources, and prompts as distinct primitives. This makes it better suited for agents that need to understand what a server can do before deciding how to use it.

Why does MCP use JSON-RPC 2.0 instead of a simpler format?

JSON-RPC 2.0 gives MCP a lightweight but structured message format that distinguishes requests from notifications and pairs responses to the correct request using an id field. This structure supports the sequenced, session-based communication that MCP requires, while remaining simple enough to implement across different clients and servers.

This post was inspired by MCP Explained: How Modern AI Agents Connect to the Real World via Towards Data Science.
July 28, 2026
Anthropic Shipped Claude Opus 5 and the Long Horizon Agent Numbers Are What I Am Reading Twice

Anthropic shipped Claude Opus 5 and the headline everyone is going to quote is the coding score. Fine. That is not what I am reading twice. The Claude Opus 5 release numbers I keep going back to are the long-horizon agentic task results. If the model can actually hold state and reason across a multi-step, tool-using workflow for meaningfully longer than Opus 4.8 could, that changes what I would trust an agent to do end to end.

I have been running Opus 4.8 through Copilot Studio and a few MCP-connected setups for months. The tail failures I wrote about when 4.8 landed did not disappear. They just moved further out into the workflow. Opus 5 looks like it is aimed directly at that problem.

What it actually does

Opus 5 is the new frontier model in the Claude lineup. The release ships with three things I care about.

First, a jump on long-horizon agentic benchmarks. Anthropic is publishing task-completion numbers on multi-turn, tool-using evals that run significantly longer than the ones they highlighted for 4.8. The distinction matters because average benchmark performance and the ability to keep a coherent plan across 30 or 40 tool calls are not the same skill.

Second, better tool-use reliability. Structured output adherence, function argument shape, and schema compliance are all up. This is the boring plumbing that decides whether your agent works or spends half its runs retrying because it put a string where an integer belonged.

Third, coding scores went up again. This is the number that will dominate every roundup post this week. It is real and it is useful, but for anyone building agents it is downstream of the first two.

The pricing sits in the same neighborhood as Opus 4.8. Available on the direct Anthropic API, on Bedrock, and on Vertex.

Why the long-horizon numbers matter more than the coding score

Here is the thing I keep repeating to people at other organizations who ask about model swaps. A workflow that completes 70 percent of the time is a demo, not a workflow. The reason most internal agents get pulled after the pilot is that the human check-in halfway through is what actually makes them work, and once you add that check-in you have not saved anyone any time.

Long-horizon task performance is the specific number that decides whether you can remove that check-in. If Opus 5 completes a 20-step research-and-write workflow at 85 percent instead of 60, that is not a marginal improvement. That is the difference between a pattern I would deploy and one I would kill. If you are thinking about how to measure whether that improvement actually shows up in practice, How to Measure Useful Work Per Dollar for Your Power Platform AI Agents is the framework I would reach for first.

The coding score is downstream of this for a simple reason. Better tool-use reliability and better structured output are the same underlying capability that makes coding scores go up. A model that produces cleaner function calls also produces cleaner code. So if the coding number moved but the long-horizon number did not, I would be skeptical. Both moved. That is a good signal.

What I am watching for over the next two weeks is whether the published numbers survive contact with real workflows. Anthropic ran a public rollback on Fable 5 earlier this year and the postmortem was clear about how launch evals can miss regressions that only show up in production. Opus 5 will get the same treatment from anyone paying attention.

What I would do with it this week

Three concrete things.

One, pick the longest agent workflow I already have running on Opus 4.8 and rerun the last 50 production traces on Opus 5. Same prompts, same tools, same inputs. Diff the completion rates and the tool-call error rates. Not average latency. Completion rate on the tail. The failure modes worth hunting are exactly the ones I covered in Why Do AI Agents Fail in Production When They Worked Fine in Testing?

Two, look at the system prompt. Every time a new model lands I see people paste the old prompt in and complain the results are worse. Opus 5 will have different steering. I would strip the prompt down to the shortest version that still enforces the policy and let the model do more of the work.

Three, for the Copilot Studio side, wait. Model availability inside Copilot Studio lags the direct Claude API by weeks. There is no point speculating about which slot Opus 5 will fill until Microsoft actually plugs it in. Test on the direct API now, plan the migration path later. I learned the hard way that prototyping on one endpoint and moving to another at the last minute burns a sprint.

If the long-horizon numbers hold up under real traces, this is the release that finally lets me push a handful of agents from human-in-the-loop to human-on-the-loop.

This post was inspired by Claude Opus 5 via Anthropic.

July 24, 2026
Dataverse Plugin for Coding Agents Landed in the Cursor Marketplace and I Want to Wire It Up Today
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.
July 24, 2026
Power Apps MCP Server Just Got Closed-Loop Learning and I Want to Point It at a Real Agent This Week

Microsoft dropped the June 2026 Power Platform feature update on June 11, and the headline for me is Power Apps MCP server closed-loop learning for enterprise agents. Not a UX refresh. Not another connector. A real change in how agents get better after you ship them.

The rest of the update is worth reading too, but this is the one I want to test against a real internal agent this week.

What shipped on June 11

The Power Apps MCP server now supports closed-loop learning. In practice that means the agent can adjust its grounding and skill selection based on how it is actually being used, without a developer manually rewriting prompts or retraining anything.

Before this, teaching an agent your org meant one of two paths. Either you fed it documents and custom instructions and hoped the retrieval was good enough, or you stood up a data science workflow to run evaluation and optimization cycles yourself. Both paths break down at maintenance time. Docs go stale. Nobody wants to rerun eval jobs every quarter.

Closed-loop learning changes the shape of that problem. Outcome signals from real usage flow back into the agent’s behavior at runtime.

What Power Apps MCP server closed-loop learning actually does

To be precise about what is and is not happening here: the underlying model is not being fine-tuned. What is being updated is the agent’s grounding layer and its skill selection policy, based on outcome data that lands in Dataverse.

I wrote about this separation before in my post on the MCP server as the feedback layer. Skills are the policy layer. The MCP server signals are the feedback layer. Keep those two straight and the mental model holds up.

The technical surface, as far as I can read from the docs and the Power Platform learn pages, looks like this. When a user interacts with the agent, outcomes get captured. Not just accept or reject clicks, but structured signals about what worked and what did not. Those signals feed a learning loop that updates how the agent grounds itself and which skills it reaches for in a given context. The Dataverse MCP server tool shape update that split metadata inspection, querying, and search into cleaner boundaries is part of what makes this grounding layer more precise.

That is closer to how a good colleague gets better at their job than how a model gets fine-tuned. Which is the point.

Why this changes the agent maintenance story

Most internal agents I see, and most I hear about from people at other organisations, are frozen at deploy time. They make the same mistake in month four that they made in week one, until someone finally opens a ticket and a developer patches the prompt. That is not maintenance. That is triage. It is also exactly the kind of failure pattern I covered in why AI agents fail in production when they worked fine in testing.

Closed-loop learning breaks that pattern if you set it up carefully. The agent adapts to how the process actually runs, not how the process was documented eighteen months ago when the SOP was last updated. Process drift stops being invisible.

The trade-off is real though. Runtime learning means the audit story gets harder. Version history now has to cover learned behavior, not just authored skills. If a policy owner asks why the agent behaved differently in July than it did in May, someone has to be able to answer that from data, not from memory. Microsoft has not fully answered that governance question yet, and I want to see how the audit surface actually looks in a live environment.

The other risk is signal quality. If your team treats every user click as positive feedback, you are teaching the agent that fatigue clicks and correct clicks mean the same thing. They do not. The learning loop is only as good as the signals you decide to trust.

What I would do with it this week

I have an internal agent in mind that has been quietly degrading for a few months. Not broken, just noticeably less useful than at launch. Perfect candidate.

The plan looks like this. First, turn on closed-loop learning in a non-production copy and run it against a shadow traffic sample for a few days. Second, define the outcome signals I actually trust ahead of time, before I look at any data. Accept-without-edit is one signal. Accept-with-edit is another and it means something different. Explicit thumbs down is the cleanest. Fatigue clicks I want to filter out entirely.

Third, set a review cadence. Not because I do not trust the loop, but because I want to see what it learns and whether the changes match the policy the skill owner would have made themselves. Having a clear way to measure whether the agent is actually improving is where a framework like measuring useful work per dollar for Power Platform AI agents becomes useful alongside the learning loop.

If the learned behavior lines up with what a human policy owner would do, the loop is doing its job. If it drifts somewhere I did not expect, that is the interesting part.

This is the first update in a while where I closed the browser tab and immediately opened a new one to start planning a test. I cannot wait to see how it holds up on a real workload.

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

July 22, 2026
OpenAI Just Launched Presence for Enterprise Voice and Chat Agents and the Positioning Is Aggressive

OpenAI shipped Presence today. It is positioned as an enterprise AI agent platform for deploying voice and chat agents across customer service and internal workflows. Not a model release. Not a new API. A platform play. The openai presence enterprise agent platform framing puts them in direct competition with vendors that Power Platform teams already evaluate alongside Copilot Studio.

I read the announcement twice to make sure I was not reading marketing copy. The word that stuck with me was proven. OpenAI does not usually lead with that word.

What OpenAI Presence actually is

Presence is a managed platform for building, deploying, and governing voice and chat agents. It sits on top of the Realtime API for the voice side and the Responses API for the chat side, but it wraps both in an opinionated shell with tenancy, transcript handling, handoff patterns, and observability baked in.

The pitch is straightforward. You bring the workflow. Presence handles the agent lifecycle. Deployment, versioning, evaluation, guardrails, and the integration layer to call into whatever backend systems the agent needs to talk to.

The voice piece is what makes this different from every enterprise chatbot pitch of the last two years. Most enterprise agent platforms I have looked at treat voice as an afterthought or a partner integration. Presence puts voice on the same footing as chat, which matters if you are targeting contact centers or any workflow where a phone call is still the primary channel.

The trust framing is aggressive too. OpenAI is claiming enterprise controls, data handling guarantees, and deployment patterns that are meant to survive procurement review. This is not a sandbox for hobby builds. It is aimed at buyers with a compliance team.

Why this launch matters

OpenAI is no longer just a model provider. With Presence they are becoming a full stack agent vendor. That is a real shift in how the market is going to look for anyone building on Power Platform, Copilot Studio, or the equivalent stacks from other cloud vendors.

The reason I care is not that Presence is going to displace Copilot Studio in large enterprises. It is not. Governance, DLP, environment strategy, and the Microsoft 365 identity fabric are not solved by a new platform from OpenAI. I made a similar argument when OpenAI shipped Workspace Agents and I stand by it.

What matters is expectation shift. When a stakeholder sees a Presence demo where a voice agent handles a helpdesk call end to end, transfers to a human with full context, and logs the transcript into a case system, they will ask why the internal version needs a six week discovery phase. That conversation is coming. If you are thinking about how to justify agent projects internally, the framework I use in How to Measure Useful Work Per Dollar for Your Power Platform AI Agents is worth having ready before that conversation starts.

The open question for me is whether Presence is a genuinely opinionated platform or a governance wrapper around Realtime plus Responses. Those are very different products. An opinionated platform makes hard trade-offs about how agents are built, how handoff works, and how you evaluate them. A wrapper just gives you knobs. I cannot tell from the announcement which one this actually is. I need to build something with it.

What I would try with it this week

I want to point Presence at a simple internal helpdesk scenario and see how it behaves. Nothing fancy. A voice agent that answers a call, identifies the caller, looks up the last three tickets from a ticketing system, and either resolves a password reset or hands off to a human with the transcript attached.

Three things I want to stress test.

Handoff. When the agent decides it cannot resolve the request, what does the human receive? A transcript? A structured summary? A live warm transfer with context? This is where most voice agent platforms fall down. It is also the scenario I had in mind when writing about Why AI Agents Fail in Production When They Worked Fine in Testing, and handoff edge cases are exactly the kind of gap that only shows up under real load.

Transcript retention and export. Where do the transcripts live, for how long, and can I pipe them into Power Automate or Dataverse for downstream analysis? If the answer is only inside OpenAI’s tenancy, that is a problem for anyone with data residency constraints.

Non-OpenAI integration. Can the agent call a Power Automate flow through a webhook, or is the integration story really only smooth if your backend is already OpenAI-native? This is the tell for whether Presence is a platform or a walled garden.

I will write up what I find. If it holds up in a real scenario I will say so. If it is a Realtime wrapper with a nice logo, I will say that too. You can follow along on LinkedIn where I usually post the messy version first.

Voice agents that survive contact with enterprise reality are going to be the story of the next year.

This post was inspired by Introducing OpenAI Presence via OpenAI.

July 22, 2026
Link to Fabric Just Got a UX Refresh and the Setup Friction Finally Drops

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.

July 22, 2026
How to Measure Useful Work Per Dollar for Your Power Platform AI Agents

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.

July 15, 2026
Dataverse July 2026 Update Extends the Agent Data Platform to More Coding Marketplaces and 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.

July 12, 2026
SharePoint Copilot Apps Just Hit Public Preview and the Structured UX Layer Is What Caught My Eye

Microsoft shipped SharePoint Copilot Apps public preview this week on the Microsoft 365 Developer Blog. The pitch is simple: guided, action-oriented business experiences that live inside the Microsoft 365 Copilot flow, combining natural language reasoning with structured UX, validation, permissions, and deterministic operations. Source is here.

I read the post twice. Not because it is dense, but because this fills a gap I have been complaining about internally for months.

What it actually does

A SharePoint Copilot App is a declarative app definition that sits inside SharePoint and surfaces inside Microsoft 365 Copilot as a first-class action target. When a user asks Copilot to do something that matches the app’s intent, Copilot hands off to the app, which then renders a structured form or guided flow with validated inputs, honors SharePoint permissions, and executes deterministic operations against SharePoint data.

So instead of Copilot free-forming a response and hoping the model picked the right list columns, the app enforces the shape of the operation. Required fields are required. Dropdowns are dropdowns. Permissions are the permissions the underlying SharePoint site already has. The reasoning layer stays in Copilot. The execution layer is deterministic.

It is not a Power App. It is not a Copilot Studio agent. It is a SharePoint-native app model that Copilot knows how to invoke.

Why it matters

Pure natural-language Copilot interactions are great for exploration and terrible for repeatable business actions. I have written about this before in the Copilot in Power Apps post: coherent is not the same as correct. When an agent writes a record based on a chatty back-and-forth, you get answers that sound complete and quietly did the wrong thing.

The pattern I keep seeing is teams reaching for a full Copilot Studio agent when what they actually need is a form with three fields, a validation rule, and a write to a SharePoint list. That is overbuild. It is also brittle, because now you have a system prompt, tool definitions, and a Power Automate flow all trying to model behavior that a simple structured input would have handled correctly the first time. If you want to understand why that brittleness compounds once the agent hits production, Why Do AI Agents Fail in Production When They Worked Fine in Testing covers exactly that failure pattern.

SharePoint Copilot Apps land right in that gap. If the process is SharePoint-heavy, the data already lives there, and the action is well-shaped, this is closer to your use case than a custom agent. You get the Copilot entry point without paying the tax of building deterministic execution on top of a probabilistic layer.

The trade-off is real. You are locked into SharePoint as the substrate. You give up the flexibility of a Copilot Studio agent that can orchestrate across multiple systems. And you inherit whatever SharePoint permission model you already have, which is a gift or a curse depending on how tidy your sites are.

There is also the honest question of where this sits against Power Apps. A canvas app already does structured input against SharePoint. What Copilot Apps add is the Copilot invocation surface. Users do not have to know the app exists or navigate to it. They say what they want in Copilot and the app appears in the flow. That is the actual delta.

What I would do with it this week

I would pick one high-volume, low-complexity SharePoint process. Something like a request submission, a status update, or a document check-in with metadata. The kind of thing that today is either a clunky SharePoint form or a Power App that nobody uses because they forget the URL.

Then I would rebuild it as a SharePoint Copilot App and see two things. First, does Copilot route to it reliably when users describe the intent in their own words. Second, does the structured form catch the mistakes that a free-form Copilot conversation would have quietly committed. Both of those are testable in a day.

If routing is unreliable, that is the same failure mode I flagged in the multi-agent orchestration post. Descriptions matter more than trigger phrases. Write them like documentation, not marketing copy. The same principle applies inside Copilot Studio — How Copilot Studio Agent Tool Selection Actually Works Under the Hood is worth reading alongside this if you want to understand how the orchestrator scores and selects actions.

For deeper Copilot extensibility context, the Microsoft 365 Copilot extensibility docs are the reference I would keep open while building. And if you want to compare notes on where this fits in the stack, I am usually posting about it on LinkedIn.

I want to see how the routing behaves under real user language before I commit to a pattern, but this is the first structured action surface inside Copilot that feels appropriately scoped rather than oversized.

This post was inspired by SharePoint Copilot Apps Now in Public Preview: From Intent to Action in Microsoft 365 Copilot via Microsoft 365 Developer Blog.

July 9, 2026
Anthropic Shipped Reflect With Claude and the Journaling Angle Is More Interesting Than It Looks
Anthropic just shipped Reflect with Claude, a guided journaling and self-reflection experience built on top of the Claude models. On the surface this reads as a wellness feature. Look at it for two more minutes and Reflect with Claude is a positioning move that tells you where Anthropic thinks the interaction pattern is going.

I want to talk about what it does, why I find it more interesting than the category suggests, and what I plan to actually do with it this week.

What it actually does

Reflect is a structured journaling surface inside Claude. You show up, Claude prompts you with reflection questions, and the session builds on prior sessions rather than starting from zero every time. It is opinionated about pacing. It asks follow-ups. It holds context across days.

The mechanics that matter, if you read past the wellness framing:
- The model prompts the user, not the other way around. That flips the default chat pattern.
- Memory persists across sessions in a scoped, purposeful way.
- The interaction is structured around a specific outcome, reflection, rather than open-ended tasks.
- Privacy defaults are tighter than a general Claude conversation, which Anthropic calls out directly.
You can try it on Claude.ai now. It is not an API surface, it is a product experience.

Why it matters for people who build agents

The wellness label is the wrapper. The interesting part is that Anthropic is publicly shipping a template for what I would call a companion pattern: model-initiated, memory-aware, purpose-bounded. That is not the same shape as a task assistant.

Most enterprise agents I see people build are task assistants. User asks, agent does, session ends. That works for a lot of internal automation. It falls apart the moment you want an agent that follows up, checks in, or maintains a thread across days without being re-prompted from scratch every time.

I have written before about how business logic and memory need real ownership in agent design. Reflect with Claude is a public reference point for what memory-aware, model-initiated interaction feels like when the vendor actually commits to it. The UX decisions in a product like this leak into what users start expecting from every agent they touch, including the ones I ship internally.

The positioning piece is worth naming too. Anthropic is signaling that Claude is not just a coding model or a knowledge worker copilot. It is a companion product. That is a different market than OpenAI is currently chasing with agents-as-workers, and it is a different market than Microsoft is chasing with Copilot Studio. If you follow the model landscape at all, this is the kind of move that tells you where the roadmap is pointed. I keep tracking these positioning shifts because they change what stakeholders ask for six months later. Anthropic’s approach to red-teaming and safeguards methodology is part of what makes a product like this credible at the enterprise level, and worth studying regardless of whether you are building consumer or internal agents.

My honest first take: this is more interesting than the launch post makes it sound. The category is wellness, the pattern is architecture.

What I would do with it this week

Three things, in order.

First, I am going to actually use it for a week. Not skim it, use it. I want to feel how the prompting cadence works, how the memory shows up in session two versus session five, and where the friction lives. You cannot design a companion pattern for internal agents if you have never used a shipped one end to end.

Second, I want to compare the interaction rhythm to what I have tried to build inside Copilot Studio agents. Copilot Studio is very good at request-response. It is not built for a model that opens the conversation. If I want an agent that pings a user with a reflection prompt at the end of the week, what does that actually look like on the Microsoft stack today? Probably a scheduled cloud flow that seeds a Copilot Studio conversation, which is a workaround, not the shape the platform was designed for. Worth stress testing. The reasons agents fail in production often come down to exactly this kind of mismatch between what you prototype and what the platform was actually designed to sustain.

Third, I want to write down which parts of the Reflect UX I would steal for internal use cases. Not the wellness angle. The structural parts. Session continuity, model-initiated prompts, bounded memory, tight privacy defaults. These are the pieces that generalize to things like weekly project retrospectives, onboarding check-ins, or post-incident reviews with an agent.

I cannot wait to try this properly. The launch might read as soft, but the shape underneath is the part I want to sit with.

This post was inspired by Reflect With Claude via Anthropic.
July 9, 2026