Tag: Copilot Studio

  • Anthropic Published a Jailbreak Safeguards Framework for Fable and the Red Team Methodology Is What I Am Studying

    Anthropic Published a Jailbreak Safeguards Framework for Fable and the Red Team Methodology Is What I Am Studying

    Anthropic Fable jailbreak safeguards framework red team methodology diagram

    Anthropic just published the Fable Safeguards Jailbreak Framework, a detailed writeup of how they stress-test and defend Fable against adversarial prompts. The interesting part of the anthropic fable jailbreak safeguards framework is not that a creative-writing model has guardrails. It is that the methodology behind those guardrails is reproducible, and it maps almost one-to-one to how internal enterprise agents should be evaluated.

    I read it twice. The second time I read it with a notebook open, because half of it applies directly to the agents I see people building on Copilot Studio and Power Platform.

    What Anthropic actually shipped

    The framework covers four things in concrete terms. First, a taxonomy of jailbreak attempts: role-play escalation, incremental context poisoning, persona hijack, and multi-turn drift. Each category comes with example prompts and the failure signature they produce. Second, a red team process: how attacks are generated, how they are scored, and how the results feed back into training and system prompt tuning. Third, an evaluation harness that runs adversarial suites on every candidate model before release, with pass thresholds per category. Fourth, a post-deployment monitoring loop that treats jailbreak patterns as a live signal, not a launch-time checkbox.

    The document is Fable-specific in places. The character stability and narrative coherence categories are unique to a long-form fiction model. But the process scaffolding around it is general. It is the same shape you would want for any agent that talks to real users.

    Why this framework matters beyond Fable

    Most internal agent rollouts I hear about have no adversarial testing at all. The eval suite is a set of happy-path questions the product owner wrote in a spreadsheet. If the answers look reasonable, ship. I wrote about this pattern after the Fable 5 rollback, and this framework is essentially Anthropic answering the question of what a real pre-launch eval looks like.

    The transferable parts are the ones I care about. A taxonomy of failure modes for your agent. A generation process for adversarial prompts (LLM-generated attacks scored by a separate LLM works surprisingly well). Pass thresholds per category, not one aggregate score. And a monitoring loop that logs suspicious prompts in production and feeds them back into the next eval run.

    The Fable-specific parts do not transfer. Nobody deploying an HR agent needs to worry about narrative coherence over 20,000 tokens. But the persona hijack category absolutely applies. If your Copilot Studio bot has a system prompt that says “you are a helpful HR assistant,” someone will try to convince it it is now a poet, or a Linux terminal, or an unrestricted chatbot. Anthropic has a category for this with concrete test prompts. You can borrow it.

    The other reason this matters: Anthropic is publishing the methodology openly. That is a shift. Most vendors treat red team work as internal-only. When the process is public, builders like me can use it as a contract. If your agent cannot pass a stripped-down version of this suite, you have not finished building it.

    What I would do with it this week

    Three concrete things.

    One, take the taxonomy and map it to whatever agent you have in production or staging. Persona hijack, role-play escalation, incremental context poisoning, multi-turn drift. Write down what each of these would look like against your specific bot. For a Copilot Studio agent connected to a Dataverse knowledge source, persona hijack usually means getting the bot to answer questions outside its scope. Incremental context poisoning means feeding it a benign document that contains hidden instructions.

    Two, generate an adversarial prompt set. I would use Claude itself for this. Give it your system prompt, your agent description, and the taxonomy, and ask it to produce 30 attack prompts per category. This takes an afternoon.

    Three, run the suite before your next prompt change or model swap. Not just the happy path. If your only pre-deployment test is “does it still answer the FAQ correctly,” you are shipping the same launch mistake that caused the Fable 5 rollback. Regressions live in the edge cases. The Claude Fable 5 Mythos 5 release is a good reminder that even well-resourced teams treat persona stability and long-context behavior as areas that need dedicated eval coverage, not afterthoughts.

    I have been writing more about this kind of pre-deployment discipline on LinkedIn, because it is the gap I keep seeing between teams that ship reliable agents and teams that ship one and spend six months patching it.

    The framework is not a silver bullet. But it is the closest thing to a public template for red-teaming an LLM agent that I have seen, and I plan to keep it open in a tab for a while.

    Source: More details on Fable 5’s cyber safeguards and our jailbreak framework \ 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

  • SharePoint vs Dataverse as a Copilot Studio Knowledge Source

    SharePoint vs Dataverse as a Copilot Studio Knowledge Source

    SharePoint vs Dataverse copilot studio knowledge sources comparison

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

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

    Content ceiling and file limits

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

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

    Governance and ownership

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

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

    Latency and answer quality

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

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

    Cost and licensing

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

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

    Choose SharePoint if, choose Dataverse if

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

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

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

    Frequently Asked Questions

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

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

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

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

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

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

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

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

    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

  • Thirty Days Running Ollama Locally for Automation Work

    Thirty Days Running Ollama Locally for Automation Work

    Workstation running Ollama locally for automation prototyping with Power Automate flows on a second monitor

    I spent the last thirty days running Ollama locally for automation prototyping. Power Automate flow drafts, Copilot Studio prompt iteration, extraction tests on documents I did not want to push to a hosted endpoint during early experimentation. This is the honest review.

    The short version: local AI earned a permanent spot in my prototyping loop. It did not earn a spot in production. The gap between those two things is bigger than most tutorials admit, and the hardware reality check is the part nobody writes about until they have lived through it.

    What I used it for and the setup

    Workstation is a 32GB RAM machine with a decent GPU. Nothing exotic. I ran Ollama with a rotation of models: Llama 3.1 8B for fast iteration, Qwen 2.5 14B for anything that needed actual reasoning, and a quantized Mistral variant for extraction work. Pulled, swapped, benchmarked over four weeks.

    The work itself was three buckets. Drafting Copilot Studio topic prompts and testing how they handled vague phrasing before I touched the real environment. Prototyping extraction logic for unstructured text where I wanted to see the shape of the output before deciding on a hosted model. And quick scratch work: rewriting a Power Fx expression in plain English, sketching a flow outline, asking dumb questions I did not want logged anywhere.

    What it does well

    Iteration speed. This is the win. When I am tuning a system prompt for a Copilot Studio topic, I want to run it twenty times with small variations and see what breaks. Doing that against a hosted endpoint means watching token costs, hitting rate limits, and waiting on network round trips. Locally, I iterate as fast as I can type. That alone saved me probably six hours over the month.

    Working with sensitive drafts. There are documents I would not paste into a cloud chat during a five-minute exploration. Internal text, draft policies, anything that has not been cleared for an external endpoint. Having a local model means I can think out loud against real text instead of synthetic placeholders. The placeholders always lie to you about how the real prompt will behave.

    Offline. I traveled twice this month. Trains, hotel wifi that pretends to exist. Ollama did not care. My prototyping loop kept moving.

    Learning the failure modes up close. Running models locally forced me to actually see how an 8B model reasons versus a 14B, where quantization hurts, where context windows bite. That intuition transfers directly to how I think about agentic workflows, because the reasoning layer is the reasoning layer regardless of where it runs.

    Where it falls short

    Quality drop on anything that needed real reasoning. I tried wiring a local model into a Power Automate flow through a custom connector for an extraction task that hosted models handle cleanly. The 8B model produced confidently wrong JSON about thirty percent of the time. The 14B was better but slower than I could tolerate inside a flow that triggered on document upload.

    Hardware reality. Most tutorials show a 7B model running snappy and call it a day. Try running a 14B model with a 16K context window while you also have Teams, a browser with forty tabs, and Power Apps Studio open. My machine started swapping. Cooling fans did things I did not know they could do. If you do not have a dedicated GPU with serious VRAM, you are running small models or you are waiting.

    Tool calling is rough. Hosted models have spent a year getting better at structured tool use. Local models I tested were inconsistent at best. For an automation developer, this matters. The whole point of an LLM in a flow is reliable structured output. When the local model returns malformed JSON for the fourth time in a row, you go back to the hosted endpoint and you do not feel bad about it. The work being done on the Dataverse plugin for coding agents is a good example of how the hosted side is pulling ahead on exactly this problem.

    No place in production. I want to be direct about this. I would not put a locally hosted model behind a production Power Automate flow at my desk. It is not redundant, it is not monitored, it is not anyone’s responsibility but mine. Production is a hosted endpoint with an SLA or it is self-hosted properly in infrastructure that someone else also watches. The OpenAI and Dell Codex on-prem partnership is the more honest version of what on-premise AI actually requires to work at that level.

    Where I would (and would not) reach for it next time

    I will keep running Ollama locally for prompt iteration, exploratory extraction tests, and any draft work that should not leave my machine. That is the lane. It is a real lane and it saves me real hours.

    I will not reach for it when I need consistent tool calling, when the task needs the reasoning quality of a frontier model, or when anyone other than me depends on the output. For those, I go back to hosted. I share my thinking on this kind of tradeoff regularly on LinkedIn, and the pattern is always the same: prototype locally, ship hosted.

    Should you start learning local AI right now? Yes, if you prototype a lot or handle drafts you would rather not send to a cloud endpoint. The intuition you build about model size, quantization, and context limits pays off everywhere else. Just do not let anyone sell you that your laptop is going to replace a hosted model in production. It is not. Not yet.

    Frequently Asked Questions

    How do I get started running Ollama locally for automation prototyping?

    You can install Ollama on a machine with sufficient RAM (32GB is a comfortable starting point) and pull models suited to your tasks, such as a smaller 8B model for fast iteration or a larger 14B model for more complex reasoning. From there you can test prompts and extraction logic against local documents without touching any hosted endpoints or incurring API costs.

    What are the main benefits of using a local AI model instead of a hosted one?

    Local models let you iterate quickly without worrying about rate limits, token costs, or network latency. They also allow you to work with sensitive or uncleared documents that you would not want to send to an external service during early experimentation.

    When should I use a local model versus a hosted AI endpoint for automation work?

    Local models are well suited to the prototyping and prompt-tuning phase, where speed and privacy matter more than peak output quality. For production automation workflows, hosted models typically offer better reasoning quality and reliability, making them the stronger choice once you move past early experimentation.

    Why does model size matter when choosing an Ollama model for automation tasks?

    Smaller models respond faster and use less memory, which suits quick iterative work, but they reason less reliably on complex tasks compared to larger models. Understanding this tradeoff locally builds practical intuition that directly applies when selecting and configuring models in production agentic workflows.

    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 Platform June 2026 Update Shipped and the Power Apps MCP Server Closed-Loop Learning Is the Headline

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

    Power Platform June 2026 update MCP server closed-loop learning diagram

    The Power Platform June 2026 update MCP server announcement dropped on June 11 and the headline for me is not the usual feature list. It is the Power Apps MCP server and what Microsoft is calling closed-loop learning for enterprise agents. Source: What’s new in Power Platform: June 2026 feature update.

    I read the post twice. The first read I filed it under “another MCP integration.” The second read I realised what they actually shipped. Agents can now learn from real usage signals inside Power Apps without you standing up a data science team to run training and evaluation cycles. That is a different category of thing.

    What it actually does

    The Power Apps MCP server exposes app context, user actions, and outcomes to an agent as structured signals. Until now, teaching an agent how your org works meant one of two paths. Either you fed it knowledge as documents and custom instructions, which is what most teams are doing today. Or you ran your own training, evaluation, and optimization loop, which almost nobody outside the big AI shops actually does.

    Closed-loop learning sits in between. The agent observes what happens when a user takes its suggestion. Did the form get submitted. Did the approval get reversed two days later. Did the user override the recommendation. Those signals flow back through the MCP server and the agent’s behavior adjusts based on whether its suggestions actually worked.

    The mechanism is the interesting part. It is not fine-tuning the underlying model. It is updating the agent’s grounding and skill selection based on outcome data that lives in Dataverse. Combine this with the business skills work Microsoft shipped earlier and the picture gets clearer. Skills are the policy layer. MCP server signals are the feedback layer.

    Why it matters

    Here is the architectural shift I think the release notes underplay. Agent knowledge stops being a build-time artifact and starts becoming a runtime asset.

    Most agents I see today are frozen at deploy time. You write the instructions, attach the knowledge sources, ship it, and then it just sits there making the same mistakes for six months until someone files a complaint and a developer goes in to patch the prompt. That is the model we have been stuck with since Copilot Studio launched.

    Closed-loop learning breaks that pattern. If the signal pipeline works the way the post describes, an agent that recommends the wrong approver three times in a row will stop doing that without anyone editing a prompt. The policy still lives in a business skill with a named owner. The behavior tunes itself based on what actually worked.

    The risk is obvious and I want to name it. If you wire usage signals into agent learning without thinking about which signals count, you end up reinforcing the wrong behavior. A user clicking accept because they are tired is not the same signal as a user clicking accept because the suggestion was right. The MCP server gives you the plumbing. Picking the right outcome signals is still your job, and I expect the first wave of failures to come from teams treating every user action as positive feedback.

    I also want to flag the governance angle. The Power Platform May 2026 update made me start thinking about agent constraints as versioned records. Runtime learning means version history now has to cover learned behavior too, not just authored skills. That is a real audit question and Microsoft has not fully answered it yet.

    What I would do with it this week

    I have an internal approval-routing workflow that I have been wanting to test something like this on. The agent currently picks an approver based on a static skill, and it gets the routing wrong roughly one in six times because the org chart does not reflect who actually owns what.

    My plan for this week is simple. Wire the Power Apps MCP server to that app. Define two outcome signals. First, did the selected approver actually approve within 48 hours, or did they reassign. Second, did the requester come back and edit the routing manually after submission. Anything else I am ignoring on purpose, because I want a clean signal before I open the door wider.

    Then I let it run for two weeks and compare the routing accuracy against the static baseline. If the closed loop moves the needle even five points on a workflow this messy, I will be writing about it. If it does not, I want to understand why before I trust it on anything that matters. If you are thinking about how to expose this kind of agent behavior through a proper UI layer, the guide on building custom Copilot UI widgets in Power Apps is worth reading alongside this.

    The Power Platform docs will need to catch up on the MCP server specifics, and I expect the configuration story to get cleaner over the next few releases. For now, this is the most interesting thing shipped this month and I cannot wait to see what the signal quality looks like in a real workflow. More on this once I have run the experiment. You can follow along on LinkedIn if you want the results.

    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

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

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

    Power Platform May 2026 feature update highlights for builders

    The Power Platform May 2026 feature update dropped on the 14th and the release notes are dense. I read through the whole thing twice. Most of it is noise for day-to-day builders. A few things are not. This is the short list of what I am actually turning on this week and why.

    What shipped in the May 2026 update

    The headline item is Power Fx user defined types going generally available as of version 3.26044. UDTs are enabled by default on new apps and require a manual toggle in settings > updates > new > user-defined types on existing ones. Defined with the Type function in App.OnStart or app-scoped formulas.

    Beyond that, the release covers Copilot Studio shipping bits around agent authoring, more Dataverse plumbing for skills and knowledge sources, governance tweaks for managed environments, and a long tail of small Power Apps and Power Automate quality-of-life updates. Some of it is useful. A lot of it is preview-flag churn that will not affect what I build this month.

    Why this release is heavier than it looks

    On the surface, the May 2026 update reads like another monthly drop. It is not. UDTs going GA changes how I write Power Fx, full stop. Component libraries stop being copy-paste exercises and start behaving like an SDK. The agent and skill updates keep moving business logic out of system prompts and into managed Dataverse artifacts, which I have written about before.

    The governance pieces are quieter but they hit the parts of the platform that decide whether your environment stays usable at 200 makers or collapses into sprawl. None of these are flashy. All of them shift how you architect.

    The three things I am turning on this week

    1. Power Fx user defined types on existing apps. This is the one. Before UDTs, type information was inferred from whatever record you passed first. One missing field and the schema silently widened. Runtime surprise. With UDTs you declare the shape once with Type and the formula bar catches mismatches at authoring time. I am going through my medium-sized apps and flipping the toggle, then retyping the component props that have caused the most regression bugs. The trade-off is real. Existing formulas can break when types get strict. You will spend an afternoon fixing things. You get type safety for the next two years. Worth it. More on what UDTs unlock in my earlier post.

    2. The Copilot Studio agent authoring improvements tied to Dataverse skills. If you have not moved your business logic out of system prompts yet, this release is the nudge. A focused 400-token skill outperforms a 4000-token prompt every time. I am rebuilding two internal agents this week, lifting policy logic into skills with named owners and version history. The governance gain matters more than the latency gain. If you want a practical look at surfacing those skills inside an app, How to Build Custom Copilot UI Widgets in Power Apps covers how to wire the Copilot payload to a real component rather than a text box.

    3. The managed environment governance updates. Specifically the changes around DLP scope and the maker access controls. I am not going to pretend this is exciting. It is the unglamorous flipping of switches that keeps the platform from rotting. If you run a CoE, read that section twice and update your baseline. Skipping this is how you end up with the month-three stall I described in Inside a Power Platform Center of Excellence: Why Most Setups Stall in Month Three.

    What I am ignoring this month: most of the preview flags, the cosmetic Power Apps studio tweaks, and anything in the Copilot canvas experience that is not GA. Preview features burn debugging time and break when the next release lands. I will come back to them when they ship for real.

    For the official documentation on UDTs and the Type function, the Microsoft Learn reference is the place to start. For my running notes on what I turn on and what I skip, I keep a list on LinkedIn.

    Monday morning: toggle UDTs on one app, port one skill out of a system prompt, update the managed environment baseline. Three concrete moves. Everything else can wait.

    Source: What’s new in Power Platform: May 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

  • How to Build Custom Copilot UI Widgets in Power Apps Step by Step

    How to Build Custom Copilot UI Widgets in Power Apps Step by Step

    Copilot custom UI widgets in Power Apps rendering a card instead of text

    Default Copilot responses in Power Apps are text. Useful for quick answers, useless when the user actually needs a card, a form, or a chart. This walkthrough shows how to build copilot custom UI widgets power apps style, so the chat renders a real component when a specific question is asked, and falls back to text otherwise. Credit to Matthew Devaney’s writeup which is the spine I am building on here.

    End state: a canvas app with a Copilot chat. Ask it about an order, and a card component appears in the conversation with the order details. Ask anything else and you get normal text.

    Step 1: Add the Copilot control and a component to your canvas app

    In your canvas app, insert the Copilot control from the Insert panel. Place it on the right side of the screen. Keep the default width, you will want the space.

    Now create the component that will act as your widget. Go to the Components tab in the tree view, create a new component called OrderCardWidget. Add an input property called OrderPayload of type Record. Inside the component, drop a container with a few labels for order ID, customer name, status, and total. Bind each label to OrderCardWidget.OrderPayload.OrderId and so on.

    Add the component to the screen. Set its Visible property to false for now. You will flip this on from the Copilot response in Step 3.

    Step 2: Configure the Copilot topic to return a structured response

    Open the Copilot studio agent connected to this app. Create a new topic called Show Order Details. Add trigger phrases like show me order, display order, open order card.

    Add a question node asking for the order ID. Then add a tool call to a Power Automate flow that returns the order as structured JSON. The flow does a Dataverse or SharePoint lookup and returns a response with this shape:

    { "widget": "OrderCard", "payload": { "orderId": "...", "customer": "...", "status": "...", "total": 0 } }

    The widget field is the trigger phrase for the UI layer. The payload field is what binds into the component. Do not skip the typed schema on the flow response. If you return a generic object, the Copilot control hands you a string and you spend the next hour wondering why parsing fails. I wrote about that exact failure mode in my custom connector walkthrough.

    Finish the topic with a Message node that returns the JSON as the final response. Microsoft’s docs on Copilot in canvas apps have the current control reference if your version differs.

    Step 3: Bind the component to the Copilot response payload

    Back in the canvas app, select the Copilot control. The control exposes a property called OnResponse that fires every time the agent sends a message. This is where you parse the JSON and route it.

    Set OnResponse to:

    Set(varLastResponse, ParseJSON(Self.LastMessage)); Set(varWidgetType, Text(varLastResponse.widget)); Set(varOrderPayload, varLastResponse.payload)

    Now set the component’s Visible property to:

    varWidgetType = "OrderCard"

    And set its OrderPayload input to:

    { OrderId: Text(varOrderPayload.orderId), Customer: Text(varOrderPayload.customer), Status: Text(varOrderPayload.status), Total: Value(varOrderPayload.total) }

    The widget now renders only when the agent says it should, and only with the data the agent returned. If you want to support multiple widgets later, swap the boolean for a switch on varWidgetType and toggle different components. If you are thinking about when that kind of routing logic warrants a dedicated agent per task, single agent vs multi-agent is worth reading before you scale this pattern.

    Step 4: Test the widget end to end and handle the fallback

    Run the app. Open the Copilot chat. Type show me order 1042. The topic should trigger, the flow should fire, and the card should appear with the right data.

    Now test the fallback. Ask something unrelated like what is the weather. The card must disappear. If varWidgetType is not reset between turns, the old widget hangs around showing stale data. Add a default branch to OnResponse:

    If(IsBlank(varLastResponse.widget), Set(varWidgetType, ""))

    Also test a malformed response. Force the flow to return invalid JSON once and confirm the app does not crash. ParseJSON returns blank on failure, your visibility check handles it, the chat continues as text. That is the behavior you want.

    Final state and one pitfall to watch for

    You now have a Copilot chat that renders a real Power Apps component when the topic returns the right payload, and text the rest of the time. Same pattern works for forms, charts, anything you can build as a component. If you want the agent behind this to pull from richer knowledge sources or close feedback loops on responses, the Dataverse agent data platform new features are worth wiring up alongside this.

    The pitfall: the Copilot control reads the raw message text. If your topic adds any conversational wrapper around the JSON, like Sure, here is your order: {...}, ParseJSON fails silently and the widget never appears. Return pure JSON from the final Message node, nothing else. That one rule will save you an afternoon of debugging. More notes on this kind of integration thinking on my LinkedIn.

    Frequently Asked Questions

    How do I build copilot custom UI widgets in Power Apps?

    You add a Copilot control to your canvas app, create a component to act as the widget, and configure a Copilot Studio topic to return a structured JSON response that includes a widget identifier and a data payload. The canvas app then reads the response, checks the widget field, and toggles the component visible while binding the payload to its input properties.

    Why does my Copilot control return a string instead of a parsed object in Power Apps?

    This usually happens when the Power Automate flow response does not have a typed schema defined. Without a typed schema, the Copilot control treats the response as plain text, which causes JSON parsing to fail. Always define the response schema explicitly in your flow to ensure a structured object is passed back.

    When should I use a custom widget instead of a default text response in Copilot?

    Use a custom widget when the user needs to view or interact with structured data, such as order details, forms, or charts, rather than a plain text answer. Text responses work for simple questions, but components give users a far more usable experience when the data has multiple fields or requires visual formatting.

    How do I connect a Power Automate flow to a Copilot Studio topic?

    Inside your Copilot Studio topic, add a tool call node and select your Power Automate flow as the action. The flow handles the data lookup and returns a structured JSON response back to the topic. Make sure the flow output schema is typed so the Copilot control can pass the data correctly to your canvas app.

    Source: How To Create Copilot Custom UI Widgets In Power Apps (Matthew Devaney (Power Apps)).

    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

  • Dataverse’s New Knowledge Sources and Agent Feedback Loops Explained

    Dataverse’s New Knowledge Sources and Agent Feedback Loops Explained

    Dataverse agent data platform new features including knowledge sources and feedback loops

    Microsoft published Dataverse Is Your Agent Data Platform: Here’s What’s New on May 5. I already wrote about the positioning shift, but the dataverse agent data platform new features in this post are the part I actually want to wire up this week. Knowledge sources you can attach to an agent. Agent feedback captured and stored back in Dataverse. Tighter coupling between business skills and the data model. That last bit is the one that changes my build order.

    What it actually does

    Three things stand out from the post.

    First, knowledge sources on Dataverse. You can now attach SharePoint sites, websites, files, and Dataverse tables as knowledge an agent can reason over, governed at the Dataverse level rather than configured per agent. The point is that knowledge becomes a managed artifact in the data platform, not a per-agent setting buried in Copilot Studio.

    Second, agent feedback stored in Dataverse. Thumbs up, thumbs down, and the conversation context land as rows you can query. That means feedback is not trapped in a separate analytics surface. You can write a flow on it. You can build a Power BI report on it. You can route a thumbs-down with a specific topic tag to the skill owner.

    Third, business skills tied to the data model. The business skills I wrote about when they shipped now sit closer to the tables they operate on. Skill ownership, policy versioning, and the data the skill reads from are governed in one place.

    For the official surface area, the Microsoft Learn docs are the right starting point once you have read the announcement.

    Why it matters

    I have built enough Copilot Studio agents to know where the pain actually sits, and it is never the model. It is the loop between what the agent does, what users think of what the agent did, and the policy owner who has to fix the thing that went wrong. That loop has been broken on Power Platform for a year.

    Feedback used to live in conversation transcripts you had to export. Knowledge used to be attached per agent, which meant the same SharePoint site got wired up four different ways by four different makers. Business logic lived in a 4000-token system prompt or a hardcoded Power Automate flow nobody could find six months later.

    Putting all three in Dataverse closes the loop. Feedback is a table. Knowledge is a managed artifact. Skills are versioned records with owners. You can finally write the query that says “show me every thumbs-down on the leave policy topic in the last 30 days, grouped by the skill that was invoked.” That query was not possible before. Now it is a view.

    The thing I am cautious about is the same thing I flagged with business skills. Sprawl. If five teams attach overlapping knowledge sources to overlapping skills with no naming convention, the agent will misroute silently and the feedback table will just tell you users are unhappy without telling you why. Governance has to come before deployment, not as a month-six cleanup. The multi-agent orchestration patterns that are now GA in Copilot Studio make this even more important to get right before you scale.

    What I would do with it this week

    I have a small internal agent that answers process questions. The plan for the next few evenings looks like this.

    Move knowledge out of the agent and into Dataverse. Right now the agent has three SharePoint sources wired up directly. I want one knowledge source registered in Dataverse, owned by the process owner, that any future agent on the same domain can reuse. That is the silo fix.

    Turn on feedback capture and build the report. Thumbs-down without a report is just noise. I want a Power BI page that shows feedback rate per topic, with a drill-through to the conversation. If I cannot see which skill was invoked when the user said no, I cannot improve anything.

    Pick one skill and version it properly. I am going to take the leave policy skill, rewrite it as a Dataverse business skill with an owner who is not me, and document the handoff. If the policy changes, the policy owner edits the skill. I do not get a ticket. That is the architectural shift I keep talking about, and it only works if I actually do it on something real. The error handling patterns that hold up in production become especially relevant once feedback loops are writing rows back into Dataverse and triggering flows downstream.

    None of this needs a new model. It needs the data platform to do its job, and it finally can.

    The interesting question now is what the second wave of agents looks like once knowledge and feedback stop being per-agent problems.

    Source: Dataverse Is Your Agent Data Platform: Here’s What’s New (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

  • Microsoft Just Reframed Dataverse as the Agent Data Platform and the Update List Is Worth Reading

    Microsoft Just Reframed Dataverse as the Agent Data Platform and the Update List Is Worth Reading

    Dataverse agent data platform diagram showing knowledge sources, business skills, and Fabric integration

    Microsoft published a post on May 5 called Dataverse Is Your Agent Data Platform: Here’s What’s New. The framing is the part worth reading. Dataverse is no longer being sold as the database under your model-driven apps. It is being repositioned as the dataverse agent data platform, the layer that gives agents real business understanding instead of just rows and columns.

    That is a meaningful shift in how Microsoft wants you to think about the stack. I have been waiting for this framing to land properly.

    What it actually does

    The update bundles several things that were previously scattered across announcements into one coherent story.

    Knowledge sources let an agent ground itself in Dataverse tables, SharePoint sites, files, and external systems through a managed reference instead of a hand-rolled retrieval pipeline. The agent sees the data with its semantics: table relationships, choice columns, business rules. Not just a vector dump.

    Business skills are now first-class records in Dataverse. I wrote about this in Microsoft Just Shipped Business Skills in Dataverse. Skills move policy and process logic out of system prompts and into a managed, owned, versioned artifact. The May 5 post confirms this is the intended pattern, not an experiment.

    Deeper Fabric wiring means agents can reach analytical data through Dataverse without you stitching mirroring and shortcuts manually for every project. The semantic model carries through.

    Copilot Studio integration is tighter on the agent side. Connected agents in Copilot Studio can pick up Dataverse knowledge sources and skills as native primitives instead of you wiring them through custom connectors and Power Automate flows.

    None of these are individually new ideas. The point of the post is that they now line up as one platform story.

    Why it matters

    The hardest part of building an internal agent is not the model. It is getting the agent to behave like someone who actually works at your company. Org-specific policies, naming conventions, what counts as an active customer, which approval thresholds apply when. That tribal knowledge is where every agent project I have seen gets stuck.

    If that knowledge lives in a 4000-token system prompt, the agent degrades. If it lives in hardcoded Power Automate flows, nobody can find it six months later. If it lives in a Word document on someone’s OneDrive, it might as well not exist.

    The dataverse agent data platform framing says: put it in Dataverse as a typed, owned, versioned record, and let any agent on the stack consume it. That is an architectural decision, not a feature toggle. It changes who owns what. The policy owner updates the skill directly. The data steward owns the knowledge source. The agent builder stops guessing.

    The risk I keep flagging is skill sprawl. The moment multiple teams start writing skills with overlapping scopes, the agent starts misrouting silently. Governance has to come before deployment, not as a cleanup project in month six. Microsoft is shipping the platform. The org design is still on you. That same principle applies to Power Platform governance that does not kill adoption — the structural decisions made early determine whether the whole thing scales or stalls.

    I also want to see how this plays with multi-agent orchestration. I covered the patterns in multi-agent orchestration in Copilot Studio. If knowledge sources and skills become the shared substrate that connected agents draw from, the per-agent prompt size drops and routing gets more reliable. That is the part I find genuinely exciting.

    What I would do with it this week

    Three concrete things, in order.

    First, pick one existing agent that has a bloated system prompt. Anything past 2000 tokens. Pull out the policy chunks and rewrite them as business skills in Dataverse. Measure the prompt size before and after, and run your behavioral tests on both. You will see the consistency change in the edge cases.

    Second, take one knowledge source that today is glued together with a custom connector or a Power Automate flow doing retrieval. Replace it with a Dataverse knowledge source pointing at the same data. Compare the answers on questions that depend on relationships between tables. The native version handles joins the hand-rolled one fakes.

    Third, draft a one-page skill ownership matrix for your tenant before anyone writes a third skill. Who owns customer policy, who owns finance approvals, who owns HR routing. Boring document. Saves you from the sprawl that kills these projects.

    Read the Power Platform docs alongside the announcement. The framing finally matches what practitioners have been building toward. I am curious where it lands by the end of the quarter.

    Source: Dataverse Is Your Agent Data Platform: Here’s What’s New (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

  • Microsoft Just Shipped Business Skills in Dataverse and This Is How You Teach Agents Your Org

    Microsoft Just Shipped Business Skills in Dataverse and This Is How You Teach Agents Your Org

    Dataverse business skills for agents announcement reaction

    Microsoft announced business skills in Dataverse on May 1, and this is the announcement I have been waiting for. Dataverse business skills for agents let you encode org processes, policies, and the tribal knowledge that lives in people’s heads as natural-language instructions. Agents discover them and follow them at runtime. No more cramming everything into a 4000-token system prompt and hoping the model remembers how your finance team handles approvals.

    I have been reading the docs since Friday. Here is my honest take.

    What business skills actually do

    A business skill is a Dataverse record. It contains a natural-language description of when the skill applies, what the agent should do, and what data or actions it can use. Agents query Dataverse at runtime, find the skills that match the user’s intent, and follow the instructions inside.

    The shape matters. You are not writing code. You are writing the kind of paragraph you would send to a new hire on day one. Things like: When someone asks about expense approvals over 5000 EUR, route to the regional finance lead, never to the team manager. The lookup table is in the Finance Approvers table. Always confirm the amount and the cost center before submitting.

    That description is stored, versioned, and indexed. Multiple agents can use the same skill. You update the skill once and every agent that discovers it picks up the new behavior. There is also a permission layer, so a skill can be scoped to a security role, a team, or an environment.

    Underneath, this is grounding. The agent does not memorize your org. It retrieves the relevant skill at runtime and follows it.

    Why this changes how you build internal agents

    The hardest part of deploying internal agents has never been the model. It has been getting the agent to behave like someone who actually works at your company. The model can reason. It cannot know that your procurement policy changed in March, or that the Madrid office handles APAC tickets on Wednesdays because of a coverage gap.

    Until now, that context lived in three bad places. System prompts that grew until they hit the context window and started degrading. Power Automate flows with hardcoded business logic that nobody could find six months later. Or worse, it lived nowhere and the agent guessed.

    I have written before that a focused 400-token instruction set produces more reliable behavior than a 4000-token one. Business skills make that practical. You stop stuffing the prompt and start composing skills. The agent picks the right ones for the job.

    The other thing this fixes is ownership. A business skill in Dataverse has an owner, an audit trail, and a lifecycle. When the policy changes, the policy owner updates the skill. They do not need to find the agent maker, file a ticket, or wait for a release. That is a real architectural shift, not a feature flag. If your org is still working out who owns what when policies change, Power Platform governance that does not kill adoption covers how to structure that before it becomes a cleanup problem.

    The risk I am watching: skill sprawl. If every team writes their own skills with overlapping scopes, the agent will face the same routing problem multi-agent setups face. Skill descriptions will start competing with each other and you will get silent misrouting. Governance has to come early, not as a cleanup project in month six.

    What I would do with it this week

    Pick one painful, well-bounded process. The kind where the answer is always it depends on who you ask. Approval routing is a good candidate. Onboarding checklists work too.

    Write three to five business skills that capture the rules. Keep each one short and specific. Connect them to a Copilot Studio agent that already has the right Dataverse and Power Automate connectors. Test with the messy questions, not the clean ones. Watch which skills get picked and which do not.

    The thing to measure is not whether the agent answers correctly. It is whether the right skill was selected for the right phrasing. If selection is unreliable, your skill descriptions are too similar or too vague. Rewrite them and try again. If you are also wiring up custom connectors to extend what the agent can reach, How to Build a Custom Connector for Copilot Studio Step by Step is worth keeping open in a tab.

    I will be writing more about this once I have run a real internal pilot. Early signals are good. In my experience, the patterns that survive contact with production are the ones where context is stored where it belongs, not where it was convenient at build time.

    This one belongs in Dataverse. Finally.

    Source: Introducing business skills: Teach agents how your organization works (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

  • When should I build a multi-agent system instead of a single agent?

    When should I build a multi-agent system instead of a single agent?

    Diagram comparing single agent vs multi-agent system architecture

    Short answer: stay single-agent until you hit one of three specific failure modes. Tool overload past roughly 8 to 10 connectors. Conflicting system prompts that cannot be reconciled in one instruction set. Or genuinely parallel workstreams that need to run at the same time. If none of those apply, the single agent vs multi-agent question is already answered. Build one agent.

    Most posts on this topic make multi-agent sound like the natural next step. It is not. It is a tax you pay when a single agent can no longer do the job, not an upgrade you take because it sounds more sophisticated.

    The longer answer

    I read a good piece on Towards Data Science walking through ReAct workflows and when scaling to multi-agent makes sense. The framing matched what I keep running into when I talk to people building on Copilot Studio and similar platforms.

    A single agent is a loop. It reads, picks a tool, calls the tool, reads the result, picks again, until it decides it is done. That loop works well when the tool list is small enough for the model to reason over cleanly and the instructions do not pull the model in two directions.

    It starts breaking in predictable places.

    The first is tool overload. I have written before about how a model that hits 95 percent accuracy on tool selection with two connectors can drop to 70 percent with five, because tool descriptions start competing with each other. By the time you have ten or twelve tools, the agent picks the wrong one regularly and you cannot fix it with prompt tweaks.

    The second is prompt conflict. If your agent needs to behave like a strict policy checker for one task and a friendly explainer for another, those two personas fight inside one system prompt. You can feel it in the outputs. The model compromises in the wrong direction.

    The third is parallelism. A single agent loop is sequential by design. If you have three independent workstreams that must run at the same time, no amount of prompt engineering will make a single ReAct loop parallel. This is also where thinking through whether AI automation is even the right fit versus a simpler RPA approach becomes worth the time.

    Everything else, latency, observability, prompt size, can usually be solved without splitting agents.

    How to decide in practice

    I use a short checklist when someone asks about single agent vs multi-agent for a Copilot Studio build.

    Count the tools. If you are under eight connectors and the descriptions do not overlap, one agent is fine. Past ten with overlap, start thinking about splitting.

    Read the system prompt out loud. If it contains contradictory instructions for different scenarios, that is a real signal. Splitting reduces prompt size per agent, and a focused 400-token instruction set produces more reliable behavior than a 4000-token one. I covered this in more detail in my post on multi-agent orchestration patterns in Copilot Studio.

    Map the workstreams. Are they actually independent, or are they sequential steps you are calling parallel because it sounds nicer? Most automation work is sequential. Real parallelism is rarer than people think.

    Budget the latency. Every hop between agents adds round-trip overhead. If you split a single agent into three, you have just added two more model calls and two more HTTP boundaries to every request. I have written about how accumulated round-trip overhead kills perceived performance long before any single call gets slow.

    If the checklist points to multi-agent, default to a supervisor pattern. One parent agent routes to focused child agents. Skip the peer network where agents call each other freely. It looks elegant in diagrams and is painful to debug in production.

    Microsoft has shipped real multi-agent orchestration in Copilot Studio, so the platform support is there. The question is whether your problem actually needs it.

    Related gotchas

    Routing in Copilot Studio multi-agent setups depends on the description you write for each connected agent, not on trigger phrases. A vague description causes silent misrouting that is harder to debug than a broken trigger. Write descriptions like API contracts, not marketing copy.

    When a parent agent picks the wrong child confidently, you get the same failure mode as a single overloaded agent, just one layer deeper. Splitting agents does not eliminate misrouting. It moves it.

    Token costs multiply faster than you expect. Each agent in the chain re-processes context. Three agents in a sequence is not three times the cost. It is often closer to five or six times once you count the context each one needs to reason properly.

    If you are still on the fence, build single first. You can always split later. Going from multi-agent back to single, on the other hand, almost never happens once the architecture is in place. That is the trade-off worth keeping in mind. More on how I think about these trade-offs here.

    Frequently Asked Questions

    When should I use a single agent vs multi-agent system?

    Stick with a single agent until you run into one of three problems: too many tools causing the model to pick the wrong one, conflicting instructions that cannot coexist in one system prompt, or parallel workstreams that need to run at the same time. If none of those apply, a single agent is the right choice.

    How do I know if my agent has too many tools?

    A good rule of thumb is to keep your tool count under eight to ten connectors. Beyond that, tool descriptions start competing with each other and the model’s ability to select the right one drops noticeably, even if prompt tweaks do not seem to help.

    Why does a single agent struggle with conflicting instructions?

    When a system prompt asks the model to take on two opposing behaviours, such as acting as a strict policy checker and a friendly explainer, those personas create tension within a single instruction set. The model tends to compromise in ways that produce unreliable outputs rather than handling each mode correctly.

    What are the main reasons to build a multi-agent system?

    Multi-agent systems are worth the added complexity when you need genuinely parallel workstreams, have irreconcilable prompt conflicts, or are dealing with tool overload that cannot be resolved through better descriptions. Outside of those scenarios, the extra coordination overhead rarely pays off.

    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