Halilcan Soran

Tag: AI Agents

  • How to Build Your First AI Agent in Copilot Studio

    How to Build Your First AI Agent in Copilot Studio

    Step by step diagram showing how to build an AI agent in Copilot Studio, from instructions to knowledge to tools to publishing

    Microsoft published a guide on how to build an AI agent aimed at anyone, and the framework is genuinely sound: define the job, give the agent knowledge, give it tools, test it, let it run. What the article does not give you is the clicks. So this is how to build an AI agent in Copilot Studio following that exact recipe, end to end. By the end you have a working internal FAQ agent that can also create a ticket, published to Teams. I built a variant of this internally last quarter, and the framework holds up. The gaps between the steps are where it gets interesting.

    Step 1: Define One Job Before You Build an AI Agent in Copilot Studio

    Microsoft’s guide says start with a clear purpose. In practice this means the Instructions field, and this is where most first builds go wrong. People write vibes: “You are a helpful assistant for IT questions.” That constrains nothing. Write scope enforcement instead:

    You answer questions about internal IT policies using only the attached knowledge sources. If the answer is not in the knowledge sources, say so and offer to create a support ticket. Do not answer questions about HR, payroll, or anything outside IT. Do not guess at policy details.

    Keep it under 500 tokens. I covered why in the business skills post: instruction sets that grow past a few hundred tokens start degrading reliability. One job. Tight boundaries. Explicit refusal behavior.

    Step 2: Attach a Knowledge Source the Agent Can Cite

    In the agent’s Knowledge section, add your SharePoint site. Use the site URL, not a document library deep link, and check that the files are PDF or Word. The indexer handles those well. It handles scanned images inside PDFs poorly, and you will not find out until the agent confidently answers from the two readable pages and ignores the rest.

    Turn on “Use general knowledge” only if you have a reason. For an internal policy agent, leave it off. Grounded-only answers with citations beat fluent answers with no source. If you are choosing between SharePoint and Dataverse here, I compared them in a separate post. For a first build, SharePoint is the shorter path. If you plan to give the agent its own identity and audit trail inside Dataverse, Entra Agent ID gives every Dataverse agent its own identity and is worth reading before you commit to the data layer.

    Step 3: Give It One Tool With a Power Automate Flow

    Microsoft’s guide calls this “giving the agent the ability to act.” Concretely: build a flow with the When an agent calls the flow trigger, add two text inputs (ticketTitle, ticketDescription), create the ticket row wherever your ticketing lives, and end with Respond to the agent returning the ticket number and status. Do not return a bare “success” flag. Return state the agent can reason about on the next turn. The Copilot Studio docs cover the wiring, but they undersell the description field.

    Then add the flow as a tool on the agent, and write the tool description as a retrieval hint, not documentation: Creates an IT support ticket when the user reports a problem that the knowledge sources cannot resolve. The orchestrator scores this against user input to decide when to call it. I went deep on this in How to Design Tool Definitions for Copilot Studio Agents. One tool for now. Resist adding more until the first one behaves.

    Step 4: Test in the Canvas With the Activity Map Open

    Open the test pane and turn on the activity map. Now test the way real users will actually talk, not the way you wish they would. Three categories: questions the knowledge sources answer, requests that should trigger the ticket flow, and deliberately bad inputs. “my thing is broken.” “can you help.” A question about payroll that should get refused.

    The activity map shows you which knowledge source or tool the orchestrator picked and why. When it picks wrong, the fix is almost always the tool description or the instructions, not the model. This is the step people consistently skip, and it is the one that decides whether the agent survives contact with real users. I wrote about why agents fail in production after passing testing, and clean test conversations are the whole story. Testers ask questions they already know the agent can answer. Real users do not.

    Step 5: Publish to Teams and Watch the First Week

    Publish, then add the Microsoft Teams channel. Start with “available to specific users” and pick a pilot group of ten people, not the whole org. Then read the transcripts in the Analytics section every day for the first week. Not the satisfaction score. The actual conversations. You will find phrasings you never tested, a refusal that fired too aggressively, and at least one question your knowledge source cannot answer that it obviously should. That first week of transcripts is worth more than any amount of pre-launch testing. If generative answers start overriding your scoped topics during this phase, the fix is covered in Stop Copilot Studio Generative Answers From Hijacking Your Topics.

    The Working Agent and the Pitfall That Breaks Most First Builds

    Final state: one agent, one scoped job, one SharePoint knowledge source, one flow that creates tickets, published to a Teams pilot group. Microsoft’s five-part recipe maps cleanly onto this. The guide is right that anyone can follow the framework.

    The pitfall: skipping step 4 because the happy path worked twice in the test canvas. In my experience the agents that embarrass their builders are never the ones that failed in testing. They are the ones that were never tested against inputs designed to break them. Budget as much time for hostile testing as for building. The building is the easy half.

    Frequently Asked Questions

    How do I build an AI agent in Copilot Studio for the first time?

    Start by writing a tight Instructions prompt that gives the agent one clear job and explicit boundaries, then attach a knowledge source like SharePoint, and connect a single Power Automate flow as a tool. Test it before publishing to a channel like Teams. Keeping the scope narrow on your first build makes it much easier to identify where things go wrong.

    What should I write in the Instructions field when creating a Copilot Studio agent?

    Instead of writing a vague description, define exactly what the agent can and cannot do, which sources it should use, and how it should respond when it does not know the answer. Keeping the instruction set under 500 tokens helps maintain reliability, as longer prompts can reduce consistency.

    When should I turn on general knowledge in Copilot Studio?

    Only enable general knowledge if your agent genuinely needs to draw on information beyond your attached sources. For internal use cases like a policy or FAQ agent, leaving it off produces more trustworthy answers because responses are grounded in your own documents and can be cited.

    Why does my Copilot Studio agent give incomplete answers from PDF files?

    The knowledge indexer in Copilot Studio handles standard PDF and Word files well but struggles with scanned images embedded inside PDFs. If your documents contain scanned pages rather than real text, the agent may only read the portions it can process and skip the rest without flagging it.

    Source: How to build an AI agent: A simple guide for anyone (Microsoft AI Blog).

  • Entra Agent ID Gives Every Dataverse Agent Its Own Identity

    Entra Agent ID Gives Every Dataverse Agent Its Own Identity

    Diagram of Entra Agent ID Dataverse identities assigning security roles to individual AI agents

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

    On 6 August 2026, Microsoft announced Entra Agent ID for Dataverse. Every AI agent that touches Dataverse can now get its own dedicated identity in Microsoft Entra, show up as a first-class agent user in the environment, and receive security roles like any other principal. It matters because it retires the worst pattern in agent deployments today: agents doing real work under a borrowed human or service account with broad permissions and no attributable audit trail.

    Entra Agent ID makes agents first-class users in Dataverse

    The mechanics are straightforward, which is exactly what you want from an identity feature. An agent gets an Entra Agent ID, which is a real directory object, not a tag on someone else’s account. That identity maps to an agent user inside Dataverse. From there, everything an admin already knows how to do applies. You assign security roles scoped to exactly the tables and privileges the agent needs. You see the agent’s activity in audit logs under its own name. You manage its lifecycle in the same admin surfaces where you manage users, app registrations, and service principals.

    None of this is a new concept. Service principals have existed for years. What is new is that the plumbing now reaches agents specifically, so a Copilot Studio agent writing to Dataverse does not need to impersonate anyone. The identity is the agent’s own, end to end.

    Borrowed credentials were the governance debt every agent deployment carried

    I keep hearing the same story from people at other organisations rolling out agents. The agent works. It creates records, updates statuses, closes cases. Then security or internal audit asks a simple question: who updated this record? And the answer is a human’s name attached to actions no human took. Usually the maker’s account, because that is what the connection was created with. Sometimes a shared service account with System Administrator, because someone hit a permissions error six months ago and fixed it the fast way.

    That pattern is not a small smell. It breaks least privilege, because the agent inherits everything the borrowed account can do. It breaks auditability, because the log tells you a person did something they never did. And it breaks lifecycle management, because when the maker leaves the company and their account gets disabled, the agent dies with it. Poof. Production automation down because of an HR event.

    I made a version of this mistake myself building an early internal agent. The connection ran under my account, and every record it touched carried my name. Harmless until someone asked why I had modified two hundred records at 3 AM. I had not. The agent had. Explaining that distinction to an auditor without a dedicated identity is not a conversation you want twice.

    This also completes a picture Microsoft has been assembling all year. Dataverse as the agent data platform gave agents skills, knowledge sources, and feedback loops. What it did not have was an answer to the identity question. Skills tell an agent what to do. Identity determines what it is allowed to do and who is accountable when it does it. You cannot govern the first without the second.

    Agents that write to production Dataverse should migrate first

    Not every agent needs this on day one. A read-only agent answering questions from a knowledge source under a scoped service account is a low-grade risk. The agents that should move first are the ones writing to production data. Anything creating or updating records in tables that feed reporting, billing, or compliance processes. Those are the deployments where the audit trail question is not hypothetical, it is one incident away.

    The trade-off is real work. Each agent identity needs a security role designed for it, and designing least-privilege roles takes longer than granting System Administrator and moving on. You also add lifecycle overhead: more principals to review, more roles to maintain. I think that cost is worth paying, for the same reason I argued when the Dataverse plugin for coding agents shipped that running it as System Administrator was the wrong setup. Broad permissions are always faster until the day they are catastrophically not. The same principle applies when you are running a Power Platform licensing audit before you ship: knowing exactly which identities hold which permissions is far easier to audit up front than to untangle after the fact.

    If I were planning a rollout, I would inventory every agent connection today and flag any that resolve to a human account. That list is your migration order. In my experience, the teams that treat identity as a prerequisite ship slower in week one and faster every week after, because they never hit the retrofit project. If you are also thinking about how agent tools should be scoped and named so that least-privilege roles map cleanly to actual capabilities, How to Design Tool Definitions for Copilot Studio Agents is a useful companion read.

    Identity was the last missing layer under enterprise agents, and now the interesting question is how fast admins make it mandatory.

    Source: Secured and Governed your AI Agents: Microsoft Entra Agent ID for Dataverse (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

  • How to Design Tool Definitions for Copilot Studio Agents

    How to Design Tool Definitions for Copilot Studio Agents

    Diagram of well-structured Copilot Studio agent tools with clear names, descriptions, and typed parameters

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

    The most common failure I see in agent builds is not the model and not the orchestrator. It is the tool definition. Copilot Studio agent tools get selected by a runtime relevance score, not by a human reading a list, and a definition written like internal documentation produces silent misrouting. This walkthrough takes one tool from a vague definition to one the planner can bind against reliably. By the end you have a repeatable checklist you can apply to every tool on every agent.

    If you want the mechanics behind why this works, I covered the scoring behavior in how Copilot Studio tool selection works under the hood. This post is the practical half.

    Step 1: Name the tool as a verb phrase

    Rename the tool from a system name to an action. SAPQuery tells the planner nothing. GetOpenInvoicesForCustomer tells it exactly which user intents should route here. The name is scored alongside the description, so it is free relevance signal. Do not waste it on the name of the backend system. The trade-off: verb-phrase names are longer and less pretty in your solution explorer. Accept that. You are optimizing for the planner, not the maker portal.

    Step 2: Write the description as a retrieval hint

    This is where most Copilot Studio agent tools go wrong. The orchestrator scores your description against the user’s actual words, so write it in the vocabulary users type, not the vocabulary your architecture diagram uses.

    Bad: Calls the finance API endpoint to retrieve invoice records from the ERP integration layer.

    Good: Returns unpaid or overdue invoices for a specific customer. Use when the user asks about outstanding balances, open invoices, what a customer owes, or payment status.

    The second version contains the phrases real users produce. Anthropic’s guidance on tool use for Claude lands on the same principle: describe when to use the tool, not how it is implemented. This holds across every function calling stack I have worked with, not just Copilot Studio. If you are thinking about how topic descriptions interact with the same orchestration layer, Stop Copilot Studio Generative Answers From Hijacking Your Topics covers the overlap and where the fix lives.

    Step 3: Give parameters binding-friendly names and descriptions

    A parameter named id of type string gives the planner nothing concrete to bind against. When the user says “show me what Contoso owes,” the planner has to guess which fragment of the utterance belongs in id. Rename it to customerAccountNumber and describe it precisely: The customer's account number in the format CUST-00000. If the user gives a company name instead, resolve it with SearchCustomerByName first.

    That last sentence matters. Parameter descriptions are one of the few places you can teach the planner tool sequencing without writing orchestration logic. Use enums wherever the value set is closed. status as a free string invites hallucinated values; an enum of open, paid, overdue removes the guesswork entirely. The Microsoft Learn documentation for Copilot Studio covers the input schema options, but it will not tell you to write them this defensively. Experience will.

    Step 4: Return full state, not a status flag

    Design the output for the agent’s next turn, not for a log file. A tool that returns {"status": "success"} leaves the agent with nothing to reason about. If the user then asks “which of those is overdue by more than 30 days,” the agent has no data and either calls the tool again or makes something up. Return the invoice list with dates, amounts, and statuses in the response. Yes, that costs tokens. It is cheaper than a second tool call and far cheaper than a confident wrong answer. I traced several production incidents back to exactly this pattern when I wrote about why agents fail in production after passing testing. The same principle applies at the agent architecture level — as I argued in The Model Is the Cheapest Part of Every Enterprise AI Agent, grounding data and tool design are where reliability is actually won or lost.

    Step 5: Test with overlapping intents, not happy paths

    Do not test by asking the question the tool was built for. Test the boundaries between tools. If you have GetOpenInvoicesForCustomer and GetOrderHistoryForCustomer, ask something ambiguous like “what’s the situation with Contoso’s account” ten times and watch which tool fires. If routing flips between runs, your descriptions overlap and you need to sharpen the “use when” clauses until they carve up the intent space cleanly. Also test with the wrong entity format on purpose. Give a company name where an account number is expected and confirm the planner chains through the lookup tool instead of stuffing garbage into the parameter.

    The finished state

    You end up with a tool that has a verb-phrase name, a description written in user vocabulary with explicit “use when” phrases, typed parameters with formats and enums, and an output rich enough to support follow-up questions. Apply the same pass to every tool on the agent and misrouting drops sharply. In my experience, this single pass fixes more agent reliability problems than any prompt engineering on the instructions.

    One pitfall to watch: do not keep adding well-designed tools forever. Past roughly 10 to 15 tools on a single agent, the relevance signal gets noisy no matter how clean your definitions are. At that point the fix is splitting the agent, not another description rewrite.

    Frequently Asked Questions

    How do I write good descriptions for Copilot Studio agent tools?

    Write descriptions using the vocabulary your users actually type, not technical or architectural language. Include phrases like ‘use when the user asks about…’ so the orchestrator can match the tool to real user intents. Describing when to use a tool, rather than how it works internally, consistently improves routing accuracy.

    Why does my Copilot Studio agent keep routing to the wrong tool?

    Tool selection is driven by a relevance score calculated at runtime, not a manual lookup, so vague or technical definitions cause silent misrouting. If your tool names and descriptions are written for developers rather than the planner, the orchestrator cannot reliably match them to user input. Rewriting names as verb phrases and descriptions in plain user language usually resolves the problem.

    What is the best way to name tools in a Copilot Studio agent?

    Name tools as verb phrases that describe a clear action, such as GetOpenInvoicesForCustomer rather than SAPQuery. The name is scored alongside the description, so it carries relevance signal and should reflect user intent rather than the underlying system or API.

    How do I define parameters so a Copilot Studio agent can fill them correctly?

    Give each parameter a descriptive name and a clear explanation of what value it expects and where that value comes from in the conversation. A parameter named ‘id’ with no context forces the planner to guess, while a name like ‘customerName’ with a description reduces binding errors and makes extraction from user utterances more reliable.

    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

  • Microsoft Previews a Security Agent for Power Pages

    Microsoft Previews a Security Agent for Power Pages

    AI security agent scanning a Power Pages site configuration, illustrating the Power Pages Security Agent preview

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

    On 29 July 2026, Microsoft announced the Power Pages Security Agent preview, an AI assistant built into the Power Pages experience that can scan a site’s security configuration, diagnose access issues, and walk makers through hardening steps in plain language. It matters because Power Pages security settings are spread across authentication providers, table permissions, web roles, page permissions, site visibility, and WAF settings, and until now nothing sat on top of all of it to tell you what you actually exposed.

    The Power Pages Security Agent Preview Puts Scans, Diagnosis, and Fixes in One Chat

    Concretely, the agent does three things. You can ask it to run a security scan of the site and it inspects the live configuration: which tables are reachable, which table permissions apply, how web roles map to them, whether anonymous access is enabled anywhere it should not be. You can ask it diagnostic questions like why a specific user can see a specific record, and it traces the answer through the actual permission chain instead of you clicking through four different screens to reconstruct it manually. And you can ask it to help harden the site, where it proposes changes to things like authentication settings and access restrictions and explains what each one does before you apply it.

    The important detail is that it reads your real site configuration. This is the same design decision that made the Dataverse plugin for coding agents useful: grounding in the actual environment instead of guessing from training data. A generic chatbot can tell you what table permissions are. This agent can tell you that your Contact table has a Global scope read permission attached to the Anonymous Users web role, on your site, right now.

    Fragmented Settings Are Why Portals Leak, and This Targets the Real Cause

    The model is not the interesting part here. The consolidation is.

    Power Pages sites do not ship with exposed tables because makers are careless. They ship that way because the security surface is fragmented. Authentication lives in one place. Table permissions live in another. Web roles, page permissions, IP restrictions, and site visibility each have their own screen, and none of them gives you a single view of what an anonymous visitor can actually reach. I have watched experienced people get this wrong, because the feedback loop is invisible. You do not find out a table is exposed until someone crafts the right OData URL, and by then it is an incident, not a config review.

    An agent that inspects the whole configuration and surfaces misconfigurations conversationally attacks that fragmentation directly. That is a better fix than another documentation page, because the problem was never that the security documentation is missing. The problem is that applying it requires holding six screens in your head at once. If you are building agents or automations alongside these portals, running a Power Platform licensing audit before you ship is the same class of discipline: catch the configuration gaps before they become incidents.

    Now the honest caveat. This is a preview, and a security tool that gives a wrong answer confidently is worse than no tool at all. If the agent tells you a table is locked down and it is not, you have converted uncertainty into false confidence, which is the most dangerous state a portal can be in. Until this thing has a track record, I would treat every scan result as a guided audit, not a sign-off. Verify what it flags, and verify a sample of what it clears. I have been burned enough times by preview features behaving differently under edge cases to extend that trust slowly.

    Inherited Sites and Anonymous-Access Audits Should Get Scanned First

    Where this fits: the first candidates are inherited sites. Every enterprise has at least one portal built three years ago by someone who has since left, where nobody currently on the team can explain the web role setup. Pointing the agent at that site and asking what an anonymous user can access is worth doing on day one of the preview reaching your tenant. Not because the agent is infallible, but because the alternative is that nobody audits it at all.

    The second candidate is any site with anonymous access enabled on purpose. Public-facing portals with self-registration are exactly where a Global scope permission accidentally attached to the wrong role does the most damage. A conversational audit lowers the cost of checking from an afternoon to ten minutes, and things that cost ten minutes actually get done.

    Who benefits most is the maker in the middle: someone comfortable building the portal but not deep enough in the security model to trace a permission chain by hand. Pro devs who already know where every setting lives will use it as a faster lookup. Citizen devs building portals without understanding table permissions were the risk this feature exists to reduce. The broader pattern here connects to something worth keeping in mind: the model is the cheapest part of every enterprise AI agent, and this feature is a good example of that — the value is in the grounding and the consolidation, not the underlying AI capability itself.

    Security tooling for low/no-code platforms is finally starting to assume the builder is not a security engineer, and that assumption is overdue.

    Source: Announcing the Power Pages Security Agent (Preview): Your AI Partner for Site Security (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

  • Tino Cuellar Joining Anthropic’s Board Is a Governance Signal

    Tino Cuellar Joining Anthropic’s Board Is a Governance Signal

    Tino Cuellar joining the Anthropic board of directors, representing AI governance and oversight

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

    On 3 August 2026, Anthropic announced that Mariano-Florentino (Tino) Cuellar, president of the Carnegie Endowment for International Peace and a former California Supreme Court justice, is joining the Anthropic board of directors. The appointment came through the company’s Long-Term Benefit Trust, the governance mechanism Anthropic built specifically to seat directors who are not financially tied to the company. For anyone deploying these models inside an enterprise, this matters because board composition sits upstream of every usage policy and deployment constraint that eventually lands in your agents.

    This is not a product release. There is no benchmark table to read twice. But I think it deserves the same attention as one, because governance moves like this one shape what the products are allowed to do two years from now.

    Tino Cuellar Joins Anthropic’s Board of Directors as a Jurist, Not an Investor

    Look at who typically sits on the board of an AI lab. Founders, lead investors, maybe an operator from a previous portfolio win. The incentive structure is uniform: grow the company, protect the equity. That is normal and I am not pretending it is scandalous. It is just narrow.

    Cuellar breaks the pattern. He spent years as a justice on the California Supreme Court, taught at Stanford, worked on domestic policy in the Obama White House, and now runs the Carnegie Endowment, one of the oldest international affairs think tanks in existence. His entire career is about how institutions constrain power, across borders, under law. Putting someone with that profile in a director seat, with actual voting rights rather than an advisory title, is a different move from hiring a policy VP. Advisors get consulted. Directors get to say no.

    The Long-Term Benefit Trust Doing What It Was Designed For

    The mechanism matters more than the name. Anthropic set up the Long-Term Benefit Trust years ago: a group of trustees with no financial stake in the company, holding the power to elect a growing share of the board. When it launched, plenty of people dismissed it as governance theater. A structure that exists on paper but never gets exercised is exactly that.

    This appointment is the structure getting exercised. The LTBT chose a jurist and international policy scholar, not another tech operator, and the company seated him. That is the difference between a governance document and a governance practice. I made a similar argument when Anthropic published the Fable 5 rollback postmortem: the public artifact is the contract. A trust that visibly places independent directors is a stronger commitment than any responsible AI pledge on a marketing page, because it is structurally hard to walk back. Anthropic has shown a similar instinct in how it approaches safety methodology — the Fable jailbreak safeguards framework is another example of a public commitment designed to be hard to quietly abandon.

    The trade-off is real, and worth naming. Independent directors with mandates beyond shareholder value can slow a company down. They can block a lucrative deployment. If you are an investor, this is friction. If you are an enterprise betting a multi-year agent architecture on this vendor, that friction is partly the point.

    What Board Composition Tells You When You Are Betting on a Model Vendor

    People I talk to at other organisations have started asking governance questions during vendor evaluation, not just capability questions. Who decides when a model gets pulled? What happens to our deployment if the safety team loses an internal argument? Those questions used to get answered with a shrug and a link to a trust center page. Board composition gives you something more concrete to point at.

    The chain is longer than it looks but it is real. Board priorities shape company policy. Company policy shapes the usage terms and safety frameworks. Those frameworks shape what the API will and will not do, which shapes what your Claude-backed agents can be trusted with in production. As I have written before, the model is the cheapest part of every enterprise AI agent. The expensive part is everything around it, and a chunk of that surrounding structure is set by people in a boardroom you will never see.

    None of this makes Anthropic immune to bad decisions. A board seat is a signal, not a guarantee, and I would still evaluate the models on evals, postmortems, and deprecation behavior. But when two vendors score similarly on capability, the one that voluntarily installed a former supreme court justice through an independent trust has told you something the other one has not.

    As models take on more autonomous, agentic work, expect governance structure to become a line item in enterprise vendor evaluations, right next to latency and price per token.

    Source: Tino Cuellar (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

  • Zapier Opens Its App Connector Library to AI Agents for Free

    Zapier Opens Its App Connector Library to AI Agents for Free

    Diagram of an AI agent reaching thousands of apps through a single Zapier connector endpoint, illustrating free AI agent app access

    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

  • The Model Is the Cheapest Part of Every Enterprise AI Agent

    The Model Is the Cheapest Part of Every Enterprise AI Agent

    Cost breakdown diagram showing the model as the smallest layer in enterprise AI agents, beneath data grounding, governance, and measurement

    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

  • How MCP Actually Works Under the Hood When an Agent Calls a Tool

    How MCP Actually Works Under the Hood When an Agent Calls a Tool

    Diagram showing how MCP works under the hood between an AI agent and a tool server

    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

  • Anthropic’s Claude Opus 5: Why Those Long Horizon Agent Numbers Matter

    Anthropic’s Claude Opus 5: Why Those Long Horizon Agent Numbers Matter

    Claude Opus 5 release notes open on a laptop next to an agent workflow diagram

    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

  • Power Apps MCP Server Now Has Closed-Loop Learning Capabilities

    Power Apps MCP Server Now Has Closed-Loop Learning Capabilities

    Power Apps MCP server closed-loop learning diagram for enterprise agents

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

    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.

    Source: What’s new in Power Platform: June 2026 feature update (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