Why do variables break when I enable Power Automate concurrency in an Apply to each loop?

Variables in Power Automate are shared across the entire flow run, not isolated to individual loop iterations. When concurrency is enabled, multiple iterations run at the same time and overwrite the same variable, causing unpredictable values to appear in your actions. No errors are thrown, so the problem can be hard to detect.

How do I safely store per-item values inside a concurrent Apply to each loop?

Replace Set variable with a Compose action, which keeps its output scoped to the iteration that created it. This means parallel iterations cannot overwrite each other's values, and Compose is also faster because it does not lock shared flow state.

Why does my Power Automate flow produce correct results in testing but wrong results in production?

This often happens because test runs use a small number of items that process sequentially, while production runs have enough items to trigger parallel execution. Once concurrency kicks in, shared variables get overwritten across iterations and the output becomes unreliable.

When should I turn off concurrency in Power Automate instead of refactoring my variables?

Reverting to sequential mode is a reasonable option only if your logic genuinely depends on Set variable and refactoring is not practical. However, running iterations one at a time will be slower, so it should be a fallback rather than a first choice.

How do I run a Power Platform licensing audit before deploying a solution?

Start by inventorying every connector in your solution and flagging anything premium, such as SQL Server, Dataverse, HTTP, or custom connectors. Then trace how each flow runs, since standalone flows need separate licensing while flows triggered by a Power Apps canvas app can be covered by the user's Power Apps license. Finally, pull real license assignments from the Microsoft 365 admin center to confirm every user has the right SKU before rollout.

What is the difference between a standard and a premium connector in Power Platform?

Standard connectors like SharePoint, Outlook, and Teams are included with most Power Platform licenses at no extra cost. Premium connectors, which include SQL Server, Dataverse, HTTP, and all custom connectors, require users to hold a Power Apps or Power Automate Premium license to use them.

Why does a single HTTP action in a flow affect licensing for all my users?

The HTTP action is a premium connector, so any flow that includes it requires the users who interact with it to hold a premium license. Because this action does not show up in an app's connection list, it is easy to miss during a review and can trigger unexpected licensing costs at the point of deployment.

When should I check who owns standalone flows in my Power Automate solution?

You should verify flow ownership before any production rollout, not after an incident occurs. If a standalone flow runs on a personal license and that person leaves the organisation, the flow will be suspended when their license is removed, causing silent failures in business processes.

What is the most expensive part of building enterprise AI agents?

The biggest costs in enterprise AI agents are not the model itself but the surrounding layers: data grounding, governance policies, tool configuration, and measurement pipelines. These are bespoke to your organisation and cannot be swapped out the way a model can, which is why they consume the most engineering time and budget.

How do I choose the right AI model for an enterprise agent?

Model selection matters far less than most teams assume, since modern platforms let you swap models with minimal effort. A better approach is to spend the majority of your planning budget on data grounding, connector policies, and measurement before you finalise any model choice.

Why does my enterprise AI agent give unreliable answers despite a strong model?

Unreliable outputs are usually a grounding problem, not a model problem. If the agent lacks access to your organisation's policies, naming conventions, and internal context, even a frontier model will produce generic or incorrect responses. Moving that knowledge out of long system prompts and into structured, versioned records tends to improve consistency.

When should I move AI policy instructions out of the system prompt?

Once your system prompt grows beyond a few hundred tokens, reliability starts to drop and maintenance becomes difficult. Migrating policy instructions into a managed data layer gives each rule a clear owner and version history, and it keeps the prompt focused on behaviour rather than organisational context.

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.

Category: Artificial Intelligence in Business

Zapier Opens Its App Connector Library to AI Agents for Free

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published August 4, 2026

In early August 2026, Zapier published a guide and a free tier for giving AI agents reliable app access through its connector layer. The short version of the Zapier AI agent app access pitch: agents do not fail at reasoning, they fail at authentication flows, endpoint quirks, and data shapes that differ per app, so Zapier is putting its maintained integration catalog in front of agents as installable, app-specific toolkits. For free, at least at the entry tier.

One Endpoint in Front of Thousands of Maintained Integrations

The concrete shape of what shipped: every Zapier connector becomes a toolkit an agent can install and call. The connector wraps the parts that actually break in practice. OAuth handshakes, token refresh, pagination rules, rate limit behavior, the specific way each vendor shapes a contact record versus a deal record. The agent talks to one endpoint and gets typed tools back, instead of learning each app’s rules from training data and getting the little details wrong.

That last part is the real problem being solved. I wrote about this from the Power Platform side when I built a custom connector for Copilot Studio: the agent does not just need an API, it needs the tool description, the response schema, and the auth flow all shaped so an LLM can reason about them. Get any one of those wrong and the agent picks the wrong action or returns a useless status: done. Zapier is selling exactly that shaping work, done once, maintained centrally, for thousands of apps.

Free AI Agent App Access Is the Hook, Connector Upkeep Is the Product

My honest read: the free tier is customer acquisition. The product is outsourced connector maintenance.

This is the same bet Microsoft made with the Power Platform connector ecosystem a decade ago. Over a thousand certified connectors, and the entire value proposition is that when Salesforce or ServiceNow changes an API version, someone else absorbs the churn. You do not wake up to a broken integration and a rabbit hole of vendor changelogs. That maintenance burden is invisible until you have carried it yourself, and once you have, you pay to never carry it again.

Where the free tier will pinch is predictable. Task quotas, premium app gating, and enterprise auth. API key auth is fine for a prototype agent. The moment you need per-user identity, SSO, or an audit trail of who the agent acted as, you are in paid territory, and rightly so, because that is where the hard engineering lives. The free tier gets an agent talking to Gmail on a Saturday. It does not get an agent acting on behalf of 400 employees on a Monday. Before you reach that point, running a Power Platform licensing audit to flag which connectors require premium plans and which user licenses are actually in scope will save a painful surprise at scale.

Where This Sits Next to Power Platform Connectors for Agent Builders

If you already run Copilot Studio or Power Automate with premium connectors licensed, wiring Zapier in as well mostly means building another silo. You would have two connector catalogs, two auth stores, two places where data flows through a third party, and two governance conversations with security. In my experience, the second integration layer never gets the same scrutiny as the first, and that is exactly where things leak.

But for teams starting from zero, this is a genuinely strong on-ramp. Indie builders, startups, agents living outside a Microsoft tenant entirely. If I were building an agent with no connector estate behind me and no enterprise licensing to lean on, this is what I would reach for before writing a single custom integration. The trade-off is clear: you give up control over the integration layer and accept a vendor in your data path, and in exchange you skip months of auth debugging and API archaeology.

The bigger signal is that every major integration vendor now agrees on the diagnosis. The model is not the bottleneck. The plumbing is, and whoever maintains the plumbing owns the agent economy’s toll booth. That framing maps directly to what I argued in The Model Is the Cheapest Part of Every Enterprise AI Agent: connector governance and grounding data are where the real budget and hours go, not the model choice itself.

Source: How to give your AI agents reliable app access for free (Zapier Blog).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

August 4, 2026
Why Do Variables Break When I Turn On Concurrency in Power Automate?

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published August 4, 2026

Short answer: variables in Power Automate are scoped to the entire flow run, not to a single loop iteration. When you enable Power Automate concurrency on an Apply to each and use Set variable inside it, twenty iterations write to the same variable at the same time and stomp on each other’s values. Use Compose for per-iteration values, use Append to array variable for collecting results, and only fall back to sequential mode if you genuinely need Set variable.

That is the whole answer. If you just shipped a flow that produces the right output for item 1 and garbage for items 2 through 40, that is almost certainly what happened. The rest of this post explains why, because the failure mode is nastier than it sounds.

Why Power Automate concurrency causes this

By default, Apply to each runs sequentially. One item at a time, in order. Flip on the concurrency control in the loop settings and it runs up to 50 iterations in parallel, with a default degree of 20. Microsoft documents this in the Apply to each reference, but the docs are quieter about what happens to your variables.

Here is the problem. Set variable is a read and write against shared flow state. Iteration 3 sets the variable to its item’s value, and before it can use that value in the next action, iteration 7 has already overwritten it. Your Condition or your email body then reads whatever value happened to land last. Nothing throws an error. The flow run shows green checkmarks all the way down. You only find out when someone asks why customer A received customer B’s invoice.

I burned an afternoon in this rabbit hole once with a flow that formatted a string per item and appended it to an email digest. Sequential test run with three items: perfect. Production run with 60 items and concurrency at 20: the same three names repeated in random order. No failed actions, no signal, nothing to catch. The debugging was miserable precisely because every individual action succeeded.

The second thing concurrency takes away is ordering. Parallel iterations complete whenever they complete. If your logic assumes items are processed in the order they arrived, that assumption is gone the moment you move the slider.

How to fix it

The fix depends on what the variable was doing.

If you were using Set variable to hold a per-item value, replace it with a Compose action. Compose outputs are scoped to the iteration that produced them, so parallel iterations cannot see each other’s outputs. This covers most cases, and it is faster too because Compose does not lock flow state the way variable actions do.

If you were collecting results across iterations, use Append to array variable or Append to string variable. These operations are atomic, so they are safe under concurrency. What you give up is order: items land in the array in completion order, not source order. If order matters, append objects that carry an index and sort afterwards.

If you were transforming every item into a new shape, ask whether you need a loop at all. A Select action maps an entire array in one operation, no loop, no concurrency, no race condition. Same for Filter array when you are only keeping some items. I reach for these first now and only use Apply to each when an action genuinely has to run per item.

And if you truly cannot avoid Set variable inside the loop, set the concurrency degree back to 1. You lose the parallel speedup, but a slow correct flow beats a fast wrong one every time. That trade-off is not close.

Related gotchas

Two more things bite people once the variable problem is fixed. First, throttling. Twenty concurrent iterations means twenty simultaneous connector calls, and SharePoint and Dataverse will start returning 429s well before you expect. The built-in retry policy masks this until volume grows, which is a pattern I covered in my post on error handling patterns. If you see intermittent failures only on large runs, drop the concurrency degree before you touch anything else.

Second, parallel branches are not the same feature and have their own trap. When two branches rejoin, the joining action runs only if its run-after conditions are met, and the default is that every preceding branch succeeded. One branch fails, the join silently skips, and the flow ends looking half green. Check the run-after settings on the first action after any join.

Concurrency is genuinely useful. I have flows where it cut a 40-minute run to under 4. But the platform lets you drag and drop fast, and this is one of those places where you need to plan even faster. I have written more about these production failure modes on LinkedIn if you want the ongoing version.

Frequently Asked Questions

Why do variables break when I enable Power Automate concurrency in an Apply to each loop?

Variables in Power Automate are shared across the entire flow run, not isolated to individual loop iterations. When concurrency is enabled, multiple iterations run at the same time and overwrite the same variable, causing unpredictable values to appear in your actions. No errors are thrown, so the problem can be hard to detect.

How do I safely store per-item values inside a concurrent Apply to each loop?

Replace Set variable with a Compose action, which keeps its output scoped to the iteration that created it. This means parallel iterations cannot overwrite each other’s values, and Compose is also faster because it does not lock shared flow state.

Why does my Power Automate flow produce correct results in testing but wrong results in production?

This often happens because test runs use a small number of items that process sequentially, while production runs have enough items to trigger parallel execution. Once concurrency kicks in, shared variables get overwritten across iterations and the output becomes unreliable.

When should I turn off concurrency in Power Automate instead of refactoring my variables?

Reverting to sequential mode is a reasonable option only if your logic genuinely depends on Set variable and refactoring is not practical. However, running iterations one at a time will be slower, so it should be a fallback rather than a first choice.

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

August 4, 2026
How to Run a Power Platform Licensing Audit Before You Ship

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published August 3, 2026

A working app in your dev environment tells you nothing about what it costs to run for 300 people. I have watched a solution sail through UAT and then stall at rollout because one flow used an HTTP action, which flipped the whole thing premium, and suddenly every user needed a license nobody had budgeted. A structured power platform licensing audit takes an afternoon and catches this before procurement finds out the hard way. By the end of this walkthrough you will have a one-page map of every connector, every flow context, and every license gap in your solution.

Step 1: Inventory Every Connector in the Solution

Open the solution in make.powerapps.com, then go through each app under Details and check the connections list. Premium connectors carry the diamond Premium tag. SharePoint, Outlook, and Teams are standard. SQL Server, Dataverse, HTTP, and every custom connector are premium. I wrote a full walkthrough on building custom connectors, and the licensing footnote there matters: they are always premium, even when they wrap a free public API.

Do not stop at the app level. Open every flow in the solution and read the actions, because the HTTP action never appears in the app’s connection list. Search the flow definitions for shared_http if you want to be thorough. This is where most surprises hide.

Step 2: Trace the Context of Every Flow

Licensing for flows depends on how they run, not what they do. A flow with a Power Apps (V2) trigger, packaged in the same solution as the app that calls it, runs in the context of that app and is covered by the app user’s Power Apps license. A scheduled or automated flow that runs standalone is not covered by anything. It needs Power Automate Premium on the owner, or a Process license attached to the flow itself.

While you are here, check who owns each standalone flow. A flow running on the personal license of someone who leaves the organisation gets suspended when that license is removed. Move business-critical standalone flows to a service account or a Process license now, not after the first silent outage. If your flows rely on desktop automation, the selector strategy you choose also affects maintenance overhead — Selectors vs Image Recognition for Power Automate Desktop Flows covers the tradeoffs in detail.

Step 3: Map Real Users to Real Licenses

Pull the actual license assignments from the Microsoft 365 admin center, or with Get-MgUserLicenseDetail in PowerShell. Do not assume everyone has the same SKU. Mixed tenants are the norm, and the F3 users in the warehouse do not have what the E5 users in finance have.

Then do the arithmetic. Per-app runs 5 dollars per user per app per month, Power Apps Premium runs 20 per user per month. The break-even sits at four apps per user. If your solution is app number one for a group of frontline workers, per-app wins. If the same 50 people will end up using five internal apps within a year, per-user is cheaper and you should say so before someone locks in the wrong plan. The Microsoft licensing overview has the current SKU details.

Step 4: Check API Request Limits and Dataverse Capacity

Licenses carry daily Power Platform request entitlements, and they are not generous at the low end. A Power Apps Premium user gets 40,000 requests per 24 hours. A user running on a seeded Microsoft 365 license gets 6,000. A flow that loops over 2,000 SharePoint items with three actions per item burns 6,000 requests in one run. The request limits documentation lists the allocations per SKU. Check your heaviest flow against the lowest entitlement in your user base.

Dataverse capacity is the other quiet cost. If your solution logs every run or every submission into a Dataverse table, estimate table growth per month against your tenant’s storage allocation. Capacity overages show up on someone else’s budget line, which means they show up as an angry email. If you are also planning to add AI features to those Dataverse tables, the new Prompt Columns in Dataverse column type adds storage considerations of its own that are worth factoring in early.

Step 5: Test With a Standard-Licensed Account

Your dev account masks everything. It almost certainly has per-user premium plus an E5, so every connector works and every flow runs. Create a test user with exactly the license mix your real end users have, share the app with it, and run every screen and every flow path. If there is a gap, this account hits the premium license prompt immediately, and you fix it before rollout instead of during it. In my experience, this single step catches more licensing problems than the previous four combined, because it tests the actual runtime entitlement chain instead of your reading of the documentation.

The Final State

You now have a connector inventory with premium flags, a flow list with run contexts and owners, a user-to-license map with the per-app versus per-user math done, and a request limit sanity check. That one page is the difference between a rollout and a procurement escalation.

The pitfall to watch: child flows. A standard-looking parent flow that calls a child flow containing one HTTP action inherits the premium requirement, and nothing in the app’s connection list will tell you. Open every child flow. Read every action. It takes ten minutes and it is the ten minutes people skip.

Frequently Asked Questions

How do I run a Power Platform licensing audit before deploying a solution?

Start by inventorying every connector in your solution and flagging anything premium, such as SQL Server, Dataverse, HTTP, or custom connectors. Then trace how each flow runs, since standalone flows need separate licensing while flows triggered by a Power Apps canvas app can be covered by the user’s Power Apps license. Finally, pull real license assignments from the Microsoft 365 admin center to confirm every user has the right SKU before rollout.

What is the difference between a standard and a premium connector in Power Platform?

Standard connectors like SharePoint, Outlook, and Teams are included with most Power Platform licenses at no extra cost. Premium connectors, which include SQL Server, Dataverse, HTTP, and all custom connectors, require users to hold a Power Apps or Power Automate Premium license to use them.

Why does a single HTTP action in a flow affect licensing for all my users?

The HTTP action is a premium connector, so any flow that includes it requires the users who interact with it to hold a premium license. Because this action does not show up in an app’s connection list, it is easy to miss during a review and can trigger unexpected licensing costs at the point of deployment.

When should I check who owns standalone flows in my Power Automate solution?

You should verify flow ownership before any production rollout, not after an incident occurs. If a standalone flow runs on a personal license and that person leaves the organisation, the flow will be suspended when their license is removed, causing silent failures in business processes.

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

August 3, 2026

Selectors vs Image Recognition for Power Automate Desktop Flows

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published August 2, 2026

Every desktop flow forces the same decision at some point: do you target the application through Power Automate Desktop selectors, or do you fall back to image recognition and click on pixels? I have built flows both ways, and I have babysat flows built both ways. The short answer is that selectors break less often and are cheaper to fix. But the honest answer needs numbers, because there are situations where image recognition is genuinely the only option, and pretending otherwise sets teams up for pain.

One caveat before the comparison. If the target system has an API or a documented connector, neither of these is the right answer. I wrote about that in Stop Reaching for Desktop Flows. This post assumes you have already lost that argument and the UI is all you have.

What Breaks Power Automate Desktop Selectors

Selectors read the application’s accessibility tree. They break when the tree changes: a developer renames a control, an update reshuffles the window hierarchy, or the selector was recorded with a fragile ordinal like Button[3] instead of a stable attribute like AutomationId. The failure is loud and specific. You get an error naming the exact UI element that could not be found, and the flow stops at that step.

Image recognition breaks when pixels change. A theme update, a new font, Windows display scaling moving from 100% to 125%, a notification toast overlapping the target, or an unattended machine resolving at 1024×768 instead of the 1920×1080 you recorded at. None of these are code changes. Most of them are things IT does without telling you. The failure is often not even a failure: the match lands on the wrong lookalike button and the flow keeps running with wrong data.

Maintenance Cost

When a selector breaks, I open the UI element repository, repair one attribute, and I am done in ten minutes. The fix is surgical because the error tells me exactly which element died. Better yet, editing the custom selector to use wildcards on volatile attributes (window titles that include document names, for example) prevents whole categories of future breaks.

When an image match breaks, I have to reproduce the exact visual state of the machine to re-capture the image. If the flow runs unattended, that means connecting to the runner, matching its resolution and scaling, and re-recording. I have seen a single Windows font scaling change take out six image-based steps across three flows in one morning. Each one needed a new capture. There is no surgical fix for pixels.

Environment Sensitivity

Selectors are largely immune to resolution, scaling, and theming. The accessibility tree does not care whether the window is maximized or what DPI the session runs at. This matters enormously for unattended runs, where the RDP session Power Automate creates may not match your development machine at all.

Image recognition is hostage to the environment. You can loosen the tolerance parameter (it defaults to 10 in PAD’s image actions) to survive minor rendering differences, but every point of tolerance you add increases the chance of a false positive match. Tight tolerance breaks on scaling changes. Loose tolerance clicks the wrong thing. There is no setting that gives you both.

Debuggability

A failed selector produces an error message with the element name and the step. You can read the run history in the Power Automate Desktop portal and know what happened without touching the machine. A failed or mismatched image gives you “image not found” at best and silent wrong-clicks at worst. Diagnosing it means screenshots, session recordings, and guesswork. The same principle that makes AI agents fail in production when they worked fine in testing applies here: silent failures and poor observability compound until something important breaks without warning.

Dimension	Selectors	Image recognition
Breaks on	UI tree changes	Any pixel change
Fix time	Minutes, one attribute	Re-capture on matching environment
DPI and resolution	Mostly immune	Highly sensitive
Failure mode	Loud, named element	Silent wrong-clicks possible

Where Image Recognition Actually Wins

Citrix and RDP sessions where the remote application streams as a bitmap and exposes no accessibility tree. Legacy Java apps without the access bridge configured. Canvas-rendered UIs that paint everything into a single element. In these cases selectors return nothing and image recognition, ideally combined with OCR to verify state before clicking, is the legitimate tool. In my experience, that covers maybe one flow in ten. The rest use images out of convenience, and convenience at build time is fragility at run time.

The Decision Rule

Choose selectors if the accessibility tree exposes the element at all, even if you have to hand-edit the selector with wildcards to make it stable. Choose image recognition only when the tree is genuinely empty, and when you do, pin the runner’s resolution and scaling, verify with OCR before destructive clicks, and document the capture environment. If you are routing outputs from these flows into Power Platform agents, the same measurement discipline covered in How to Measure Useful Work Per Dollar for Your Power Platform AI Agents applies: you need to know whether the automation is actually completing useful work, not just running without errors. Drag and drop fast. Plan even faster.

Frequently Asked Questions

When should I use Power Automate Desktop selectors instead of image recognition?

Power Automate Desktop selectors are the better default choice because they read the application’s accessibility tree rather than pixels, making them resistant to resolution changes, theme updates, and display scaling. Image recognition is only worth considering when a UI element has no accessible properties for a selector to target.

Why do Power Automate Desktop selectors break after application updates?

Selectors break when the underlying accessibility tree of the application changes, such as when a developer renames a control or a software update reshuffles the window hierarchy. Using stable attributes like AutomationId instead of positional references like Button[3] reduces how often this happens.

Why does image recognition in Power Automate Desktop click the wrong element?

Image recognition matches on pixels, so changes like a new font, a notification covering the target, or a different screen resolution can cause the match to land on the wrong button without throwing an error. This makes failures harder to detect because the flow continues running with incorrect actions.

How do I reduce maintenance work when desktop flow UI elements keep breaking?

Switch from image-based clicks to selectors wherever possible, since selector errors identify the exact element that failed and repairs are usually quick attribute fixes. Using wildcards on volatile parts of a selector, such as window titles that include document names, can also prevent entire categories of recurring breaks.

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

August 2, 2026

The Model Is the Cheapest Part of Every Enterprise AI Agent

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published July 31, 2026

Every agent conversation I get pulled into starts with the same debate. Opus 5 or GPT. Copilot Studio’s default model or bring-your-own. Someone has a benchmark chart open before anyone has asked what the agent is supposed to do. After more than a year of building enterprise AI agents internally, I am convinced this is the least consequential decision in the entire project. Swapping the model has never taken me more than an afternoon. The data plumbing, the connector policy sprawl, the tool selection behavior, and figuring out whether the thing produces useful work per dollar have each eaten weeks. This post is my map of where the real cost centers sit, and it links out to everything I have written on each layer, so treat it as the index.

Every Enterprise AI Agent Kickoff Starts With the Wrong Debate

Model differences are real. I wrote about why Opus 5’s long-horizon task completion numbers matter more than coding benchmarks, and Anthropic shipping verticalized agents like Claude Finance tells you the frontier labs know where the value sits. But here is the asymmetry nobody prices in: the model is the one component you can replace without touching anything else. Copilot Studio lets you change it in a dropdown. A custom orchestration layer changes it in one config line. Meanwhile your Dataverse schema grounding, your DLP policies, your tool descriptions, and your measurement pipeline are all bespoke work that survives every model swap and cannot be bought off a pricing page.

So when a kickoff burns two hours on model selection, I now say the same thing every time. Budget this project like 10 percent model and 90 percent platform. Every agent I have seen die in month two died in the 90 percent.

Grounding Data Is Where the Real Engineering Hours Go

The hardest part of an internal agent is not intelligence. It is getting the agent to behave like someone who actually works at your organisation. Org policies, naming conventions, tribal knowledge, the exception the finance team makes every quarter-end. None of that is in any model’s training data.

The naive fix is stuffing everything into the system prompt. I learned the hard way that prompts past a few hundred tokens start degrading reliability, and a focused 400-token instruction set beats a 4000-token one every time. That is why I consider business skills in Dataverse an architectural shift rather than a feature: policy moves out of the prompt into a managed record with an owner and a version history. If you want persistent AI output that stays queryable alongside that structured data, Prompt Columns in Dataverse are worth understanding as a companion pattern — you define the prompt once and the result lives as a column rather than a one-off generation.

Same logic applies to schema. An agent that does not know your column logical names burns tokens guessing, which is why the Dataverse MCP server’s metadata inspection tools matter, and why grounding coding agents in live environment metadata is the only reliable fix for hallucinated column names. If you want to understand what is actually happening on the wire when an agent calls one of these tools, I broke down how MCP works under the hood. It is a stateful JSON-RPC protocol, not a REST connector, and treating it like one breaks in production.

Knowledge sources carry the same trap at a different layer. Wire the same SharePoint site into four agents four different ways and you get silent misrouting nobody can diagnose. I covered the governance side in my post on knowledge sources and agent feedback loops. None of this work goes away when you change models. All of it decides whether the agent is trustworthy.

Connector Policies and Tool Selection Decide What Your Agent Can Actually Do

The second cost center is everything between the agent and the systems it touches. I hit this building a GitHub integration: the connector sat in the Business data group in Dev and the Blocked group in Prod, so an agent that passed UAT would not even load its connection at go-live. The full story is in my post on enterprise environment sprawl, and the lesson generalises. The connector is never the problem. The environment strategy around it is.

Then there is tool selection, which most teams treat as magic. It is not. In Copilot Studio, the orchestrator scores tool names, descriptions, parameter names, and enum values against the current turn. It is a retrieval problem, not a dispatch problem, and I walked through the mechanics in how Copilot Studio agent tool selection actually works. A vague operation summary like GetData on a custom connector is not lazy metadata. It is a bad prompt that makes the agent pick the wrong action.

This is also why I push back on premature multi-agent architectures. A model that hits 95 percent tool selection accuracy with two connectors can drop to 70 percent with five, because descriptions start competing with each other. Multi-agent is a tax you pay when a single agent can no longer do the job, not an upgrade, and orchestration routing just moves the misrouting failure one layer deeper where it is harder to debug.

If You Cannot Measure Useful Work Per Dollar, You Built a Demo

The last cost center is the one almost everyone skips. If you cannot define what counts as useful work for your agent in one sentence, it does not have a clear enough job to be worth scaling. I documented my full approach in measuring useful work per dollar for AI agents: a single boolean per invocation, sourced from downstream behavioral signals like ticket reopens rather than thumbs-up ratings, divided into a cost stack of model tokens plus per-message consumption plus premium connector actions.

Measurement is also your early warning system. Agents that sailed through UAT fail in production because test conversations are too clean, and the input distribution shifts the moment real users show up with messy phrasing. A workflow that completes 70 percent of the time is not a workflow, it is a demo, because the human check-in that makes it reliable eliminates the time savings it was supposed to create. Without a useful-work metric you do not find that out until someone quietly stops using the agent.

The encouraging part: this layer is finally getting platform support. Feedback stored as queryable Dataverse rows, closed-loop learning through the Power Apps MCP server, and certified MCPs giving platform teams a trust-signal list instead of shadow adoption from random repos. The tooling is catching up to the problem.

So here is the payoff. Next time an agent project kicks off, do not open with the model comparison. Open with four questions. Where does the org knowledge live and who owns it. Which connectors and policies apply in the environment where this will actually run. How many tools before selection accuracy degrades. And what single boolean defines useful work. In my experience, the teams that answer those four before touching a model dropdown ship agents that survive month three. The teams that start with the benchmark chart ship demos.

Frequently Asked Questions

What is the most expensive part of building enterprise AI agents?

The biggest costs in enterprise AI agents are not the model itself but the surrounding layers: data grounding, governance policies, tool configuration, and measurement pipelines. These are bespoke to your organisation and cannot be swapped out the way a model can, which is why they consume the most engineering time and budget.

How do I choose the right AI model for an enterprise agent?

Model selection matters far less than most teams assume, since modern platforms let you swap models with minimal effort. A better approach is to spend the majority of your planning budget on data grounding, connector policies, and measurement before you finalise any model choice.

Why does my enterprise AI agent give unreliable answers despite a strong model?

Unreliable outputs are usually a grounding problem, not a model problem. If the agent lacks access to your organisation’s policies, naming conventions, and internal context, even a frontier model will produce generic or incorrect responses. Moving that knowledge out of long system prompts and into structured, versioned records tends to improve consistency.

When should I move AI policy instructions out of the system prompt?

Once your system prompt grows beyond a few hundred tokens, reliability starts to drop and maintenance becomes difficult. Migrating policy instructions into a managed data layer gives each rule a clear owner and version history, and it keeps the prompt focused on behaviour rather than organisational context.

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

July 31, 2026
Prompt Columns Reach General Availability as a Dataverse Column Type

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published July 31, 2026

On 29 July 2026, Microsoft announced the general availability of Prompt Columns in Dataverse. You define a natural language prompt once on a table, and AI-generated classifications, summaries, and recommendations are computed and persisted as regular column values on every row. The insight stops being a read-time answer and becomes stored data: filterable in views, aggregable in Power BI, and triggerable in flows, with no code and no custom plumbing.

Prompt Columns Make AI Output a Persisted Dataverse Value, Not a Read-Time Answer

The mechanics are simple. On any Dataverse table you add a prompt column, write a natural language instruction that references other columns on the row, and Dataverse computes the result and stores it. Classify this ticket by urgency based on the description field. Summarize this feedback in one sentence. Recommend a next action based on status and history. The output lands in the column like any value a human would have typed.

I built this exact pattern by hand last year for an internal triage table. Flow triggers on row create, calls an AI Builder custom prompt, patches the result back into a text column, handles retries when the prompt action throttles, and logs failures somewhere nobody checks. It worked. It was also four moving parts to maintain for what is conceptually one thing: a computed field whose formula happens to be a prompt. Prompt Columns deletes that entire plumbing layer. Poof.

Storing the Insight Beats Regenerating It, With Two Caveats

Persistence is the whole story here, and I think it is the part most coverage will skip past. Nearly every AI-in-apps pattern generates insights on demand, at read time. That has two costs people underestimate. Every consumer pays inference cost for the same question, and every consumer can get a slightly different answer. A stored value flips both. The inference runs once, then a view can sort by it, a flow can trigger on it, a Power BI report can aggregate it across a million rows without a single additional model call. I wrote before about how the data path behind the model is often the real bottleneck, and this is the same principle from the other direction: put the AI output where the data already lives.

Two caveats before anyone switches this on across a production table. First, refresh semantics. If the description field changes after the classification was computed, when does the column recompute? A persisted AI value can go stale in a way a read-time answer never does, and you need to know the recompute triggers before you build a queue that sorts on it. Second, cost per row. One prompt execution per row sounds cheap until you enable it on a table with two million existing rows and think about backfill. Model the credit consumption before GA enthusiasm meets your capacity report. If you are already thinking about how to measure that spend against the work it produces, How to Measure Useful Work Per Dollar for Your Power Platform AI Agents is a useful starting point.

There is a third thing that is less caveat and more governance homework. AI-generated text now sits in a column that looks exactly like human-entered data. Nothing in a view distinguishes the two. If a downstream flow or a report treats that column as ground truth, you have quietly promoted a model output to a system of record. That is fine if it is a deliberate decision with a named owner. It is not fine as an accident.

Triage Queues and Classification Views Are the First Places This Pays Off

The obvious first wins are the boring ones, which is a compliment. Triage queues where incoming requests get an AI-assigned category and priority, and the queue view sorts by the AI column. Summary columns on long description fields so a service agent scans a readable sentence instead of opening every record. Sentiment on feedback rows, with a flow triggering on the negative ones and routing them to an owner. Every one of these was possible before with the flow-plus-prompt pattern. Now they are a column definition, which puts them in reach of makers who were never going to build the plumbing version.

The trade-off is worth naming. If you need per-user, per-context answers, or the insight depends on data outside the row, this is the wrong tool and read-time generation with an agent is still the right shape. That boundary also comes up when you are deciding where to store knowledge in the first place — SharePoint vs Dataverse as a Copilot Studio Knowledge Source covers how the two stores differ in ceiling, governance, and latency. In my experience, the honest split is: persist what is a property of the record, generate on demand what is a property of the question.

AI output stored as first-class, queryable data is where this whole space is heading, and a column type is exactly the right place for it to land.

Source: Prompt Columns in GA: Turning Business Apps Data into Persisted AI Insights (Microsoft Power Platform Blog).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

July 31, 2026
Dataverse Plugin for Coding Agents Now Available on OpenAI and Codex Marketplaces

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published July 30, 2026

Microsoft shipped the Dataverse plugin for coding agents to OpenAI and Codex marketplaces on July 28, 2026. Same plugin story we saw hit Cursor a few weeks back. The dataverse plugin openai codex marketplace expansion is the interesting signal here, not the individual drop.

If you write Dataverse code with a coding agent, the excuse for hallucinated table and column names is gone. I want to wire this into a real internal repo this week.

What actually shipped

The Dataverse plugin is now installable directly from the OpenAI and Codex marketplaces. Single-click install, same as the Cursor drop earlier this month. The plugin itself is unchanged in behavior. It grounds the coding agent in live environment metadata so the model queries your actual column logical names like cr123_customerid instead of guessing based on tutorial data from training.

Setup story is also unchanged. You point the plugin at a Dataverse environment through an app user with a scoped security role. Not System Administrator. Not production. A dedicated app user in a dev environment with least privilege. Same rule I have been repeating since the first drop.

What is new is the reach. The plugin now lives inside three of the coding agent surfaces where pro devs actually work. Cursor, OpenAI, and Codex. That covers a real slice of the market I see on LinkedIn when people share their editor screenshots.

Why this expansion matters more than the Cursor drop did

The Cursor drop was the proof of concept. It showed Microsoft was willing to follow developers out of VS Code and the maker studio into competing tools. Fine. Interesting signal.

This expansion is the follow-through. And follow-through is what tells you whether a strategy is real or a one-off gesture.

Three marketplaces in a few weeks means Microsoft is treating the coding agent surface as a distribution channel, not a partnership. That changes the math for platform teams. When developers install Dataverse tooling from a first-party plugin in a known marketplace, you have an auditable trail. When they pull an MCP server from a random GitHub repo, you have nothing. Marketplace distribution is a governance win before it is a productivity win. The Dataverse July 2026 update actually spells out exactly where Microsoft is taking this with certified partner MCPs and enterprise MCP governance, which is worth reading alongside this drop.

The second thing this signals is that the pro-code path into Dataverse is now considered permanent strategy. Not a side project. Not a preview experiment. Microsoft is investing in meeting devs where they already work, and that pulls the low/no-code and pro-code stories closer together than they have been in years.

The third thing, and the one I care about most, is that hallucinated schema is officially not an acceptable failure mode anymore. If you have a coding agent generating Dataverse code and it is still inventing column names, that is a tooling choice now, not a limitation. The grounding layer exists in the tools you already use.

What I would wire up this week

I have a plugin project sitting in a dev environment that I want to point this at. Here is the plan.

First, spin up a dedicated app user in the dev environment with a scoped security role. Read on the tables the plugin project actually touches. Nothing more. This is the part most people skip and regret later when the audit conversation starts.

Second, install the plugin from the OpenAI marketplace into my coding agent. Point it at the dev environment. Verify it can read metadata. Confirm it cannot see production.

Third, take an existing plugin file with real custom table references and ask the agent to extend it. The test is not whether the code compiles. The test is whether the generated code uses the actual logical names from my environment or hallucinates something plausible. If it grounds correctly, this becomes part of my normal flow. If it drifts, I want to know exactly where. The failure modes I am watching for here are the same ones I covered in Why Do AI Agents Fail in Production When They Worked Fine in Testing, and schema drift is near the top of that list.

Fourth, run the same prompt against a Codex install to see if there is any behavior difference across the two marketplaces. My guess is no. The plugin is the same. But I want to confirm.

The bigger question I am sitting with is what happens when every coding agent has grounded access to your Dataverse schema. The Power Platform pro-dev story has been fragmented for years. If the plugin holds up across three marketplaces, that fragmentation starts to close.

I will report back on what breaks.

Source: Dataverse Plugin for Coding Agents: OpenAI and Codex Marketplace Expansion (Microsoft Power Platform Blog).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

July 30, 2026
How MCP Actually Works Under the Hood When an Agent Calls a Tool
By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published July 28, 2026

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.

Source: Attention Required! (Towards Data Science).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn
July 28, 2026
Anthropic’s Claude Opus 5: Why Those Long Horizon Agent Numbers Matter

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published July 24, 2026

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.

Source: Introducing Claude Opus 5 \ Anthropic (Anthropic).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

July 24, 2026
Dataverse Plugin for Coding Agents Is Now in the Cursor Marketplace
By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published July 24, 2026

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.

Source: Dataverse Plugin for Coding Agents Now Available in Cursor Marketplace (Microsoft Power Platform Blog).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn
July 24, 2026

Category: Artificial Intelligence in Business

One Endpoint in Front of Thousands of Maintained Integrations

Free AI Agent App Access Is the Hook, Connector Upkeep Is the Product

Where This Sits Next to Power Platform Connectors for Agent Builders

Why Power Automate concurrency causes this

How to fix it

Related gotchas

Frequently Asked Questions

Why do variables break when I enable Power Automate concurrency in an Apply to each loop?

How do I safely store per-item values inside a concurrent Apply to each loop?

Why does my Power Automate flow produce correct results in testing but wrong results in production?

When should I turn off concurrency in Power Automate instead of refactoring my variables?

Step 1: Inventory Every Connector in the Solution

Step 2: Trace the Context of Every Flow

Step 3: Map Real Users to Real Licenses

Step 4: Check API Request Limits and Dataverse Capacity

Step 5: Test With a Standard-Licensed Account

The Final State

Frequently Asked Questions

How do I run a Power Platform licensing audit before deploying a solution?

What is the difference between a standard and a premium connector in Power Platform?

Why does a single HTTP action in a flow affect licensing for all my users?

When should I check who owns standalone flows in my Power Automate solution?

What Breaks Power Automate Desktop Selectors

Maintenance Cost

Environment Sensitivity

Debuggability

Where Image Recognition Actually Wins

The Decision Rule

Frequently Asked Questions

When should I use Power Automate Desktop selectors instead of image recognition?

Why do Power Automate Desktop selectors break after application updates?

Why does image recognition in Power Automate Desktop click the wrong element?

How do I reduce maintenance work when desktop flow UI elements keep breaking?

Every Enterprise AI Agent Kickoff Starts With the Wrong Debate

Grounding Data Is Where the Real Engineering Hours Go

Connector Policies and Tool Selection Decide What Your Agent Can Actually Do

If You Cannot Measure Useful Work Per Dollar, You Built a Demo

Frequently Asked Questions

What is the most expensive part of building enterprise AI agents?

How do I choose the right AI model for an enterprise agent?

Why does my enterprise AI agent give unreliable answers despite a strong model?

When should I move AI policy instructions out of the system prompt?

Prompt Columns Make AI Output a Persisted Dataverse Value, Not a Read-Time Answer

Storing the Insight Beats Regenerating It, With Two Caveats

Triage Queues and Classification Views Are the First Places This Pays Off

What actually shipped

Why this expansion matters more than the Cursor drop did

What I would wire up this week

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

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

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

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

Frequently Asked Questions

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

What is the MCP handshake and why does it matter?

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

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

What it actually does

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

What I would do with it this week

What the dataverse plugin cursor marketplace listing actually does

Why the Cursor Marketplace channel matters

What I would do with it this week