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.

What is the relationship between intelligent apps and human leadership in the workplace?

Intelligent apps only deliver real value when human leadership changes how decisions are made, not just how fast tasks are completed. Without redesigning decision rights and workflows, AI tools tend to accelerate broken processes rather than fix them.

Why does automating an existing process sometimes make things worse?

Automation increases the speed and volume of outputs, but if the approval or review process stays the same, the bottleneck simply gets worse. Teams end up rubber-stamping decisions to keep pace, which lowers quality while creating the illusion of better throughput.

How do I know if my organisation is ready for an AI automation rollout?

A good starting point is asking whether decision rights have been clearly assigned and whether leaders are willing to redesign how approvals and reviews work. If those structures are unchanged, adding AI tools is likely to surface existing problems faster rather than solve them.

When should I redesign workflows before deploying intelligent apps?

Workflow redesign should happen before deployment, not after. If the human steps in a process have not been updated to match the speed and volume AI generates, the technology will outpace the people it is meant to support.

Category: Artificial Intelligence in Business

Power Pages Agentic Coding Tools Just Went GA and the GitHub Copilot CLI Plugin Is What I Am Trying First

Microsoft just announced that the Power Pages agentic coding tools GA milestone is here. The plugins for GitHub Copilot CLI and Claude Code are now generally available, after a preview that landed earlier this year. You can read the full announcement on the Power Platform blog.

This is the part I have been waiting for. Power Pages site building is moving out of the maker portal and into the terminal where pro devs actually live. That changes who can credibly own a Power Pages project inside a large org.

What it actually does

The plugin sits inside GitHub Copilot CLI or Claude Code as an extension. You describe the site in natural language. The agent generates the scaffolding, sets up Dataverse tables, wires up the Web API, configures table permissions, and deploys the site.

The important bit is the grounding. The plugin is not asking the model to guess at Liquid syntax or invent table names. It reads your actual environment, your existing tables, your site settings, your authentication setup. The output lands in your repo as files you can diff, review, and commit.

You get the standard pro-dev loop. Branches. Pull requests. CI checks. Code review. The site definition is text, the agent generates text, and Git handles the rest. No more configuring half the site in the maker studio and the other half through manual file edits and praying the two stay in sync.

Why moving to GA actually matters

Preview features do not get deployed to production at most enterprises I talk to. Security reviews block them. Procurement blocks them. Internal policy blocks them. GA flips that switch.

More importantly, GA means the API contract is stable enough that you can build CI around it without expecting it to break next month. That is the difference between a fun side experiment and something a team commits to as a standard delivery pattern.

The bigger shift is cultural. Power Pages has always had a split personality. The studio handles the front-end click work, but the layer underneath, Liquid templates, Web API calls, table permissions, plugin logic, is real code. I wrote about this when the server-side skills landed. The maker portal hid the code layer behind a UI that pro devs did not want to touch and citizen devs could not safely change.

Pulling the build process into Copilot CLI or Claude Code lets a pro dev own the whole site end to end without leaving the terminal. That is a real unlock for the kind of internal portal work that has been stuck between teams for years. If you are also thinking about how multi-agent orchestration patterns in Copilot Studio fit alongside this kind of terminal-driven build loop, the two are worth thinking about together.

The trade-off is honest. This is not for citizen devs. If your maker has never opened a terminal, this is not their tool. The maker studio is not going away, and it should not. But for the portal projects where someone wanted to use Git, code review, and a real deployment pipeline and could not, the path now exists.

What I would do with it this week

I would pick the smallest internal Power Pages site I can find. Something with two or three tables, an authenticated user experience, and a form that writes back to Dataverse. Nothing customer-facing. Nothing with sensitive data.

Install the Power Pages plugin in GitHub Copilot CLI. Point it at a dev environment that mirrors a real one but is safe to break. Ask it to scaffold the site from a short description and let it generate the Dataverse tables and Web API config. If you want the agent to do more than scaffold, Dataverse knowledge sources and agent feedback loops are worth wiring in at this stage.

Then I would intentionally break something. Change a table permission by hand in the maker studio. Re-run the agent. See how it handles drift. That is the failure mode that will hurt in production, and you want to know the answer before you commit to this for a real project. I have learned the hard way that the demo path always works. The drift path is where tools live or die.

I would also run the same prompt through both the Copilot CLI plugin and the Claude Code plugin and compare the output. Same site, same description, two agents. The deltas will tell you a lot about which one to standardise on.

For anyone running portal projects inside a large org, this is the week to actually try it. The Power Pages docs have the setup steps and the plugin is a clean install.

The terminal is becoming a real surface for Power Platform work, and I am here for it.

This post was inspired by Build Power Pages Sites with AI through Agentic Coding tools, now Generally Available via Microsoft Power Platform Blog.

June 2, 2026
How to Build Custom Copilot UI Widgets in Power Apps Step by Step

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.

This post was inspired by How To Create Copilot Custom UI Widgets In Power Apps via Matthew Devaney (Power Apps).

June 1, 2026
Anthropic Shipped Claude Opus 4.8 and the Coding Numbers Are What Caught My Eye

Anthropic dropped the Claude Opus 4.8 release today. I read the post twice before writing anything because the coding and tool-use deltas are the part that actually matters for people building agents, not the headline number.

Most model bumps are easy to ignore. This one I am paying attention to, and not for the reason most posts will tell you.

What it actually does

Opus 4.8 is an incremental release on top of the Opus 4 line. The model card focuses on three areas: coding quality, tool-use reliability, and long-horizon agentic task completion. Anthropic reports gains on SWE-bench style coding tasks and improvements on multi-step tool sequences where the model has to plan, call a tool, read the result, and decide what to do next without losing the thread.

The pricing and context window stay in line with the Opus 4 family. It is available on the Anthropic API, on Claude.ai, on Amazon Bedrock, and on Google Vertex. Same deployment story as before.

The thing that jumped out at me was the reduction in tool-call errors on longer agent traces. Not the average. The tail. That is a different problem to fix and a different problem to feel in production.

Why it matters for agent builders

If you have built anything resembling a real agentic workflow, you know the failure mode. The agent runs fine for 4 or 5 steps. Then on step 8 it calls a tool with malformed JSON, or hallucinates an argument, or forgets which tool it already called. The whole trace dies and you are looking at logs trying to figure out where the drift started.

Coding quality and tool-use reliability are the same problem wearing two different hats. A model that writes better code is a model that produces better structured outputs, better function arguments, and better adherence to a schema. That is what makes a multi-step agent stop falling apart on turn 9.

I have written before about latency being the quiet killer of agentic workflows. Reliability is the louder one. A workflow that completes 70 percent of the time is not a workflow. It is a demo. And most teams I talk to are sitting at 70 percent and calling it production.

If Opus 4.8 actually pushes the tail of tool-call failures down, that is the difference between an agent you can schedule overnight and an agent that needs a human babysitting every run. That is the gap I care about.

The other piece worth naming: this is Anthropic doubling down on coding and agents as the wedge. Not consumer chat. Not creative writing. They are picking a lane and shipping into it. Anthropic has been consistent about this for months and Opus 4.8 fits that pattern cleanly. That same strategic focus is visible in moves like Anthropic acquiring Stainless, where the SDK layer itself became a competitive asset.

What I would do with it this week

One test. Not a benchmark. A real one.

Take the agent or automation in your stack that fails most often on long traces. The one where you keep adding retry logic and validation steps because the model keeps producing slightly wrong tool arguments. Run the same trace 20 times on whatever model you are using now. Log the failure points. Swap to Opus 4.8 with the exact same prompt and tools. Run it 20 more times.

If the tail failures drop noticeably, you have your answer. If they do not, you keep what you have and you saved yourself a migration.

I would also pay attention to cost per successful completion, not cost per token. A more expensive model that completes the workflow on the first try beats a cheaper model that needs three retries every time. That math is what people forget when they compare price sheets. It is the same logic that applies when you are deciding whether to build a multi-agent system instead of a single agent — the right architecture is the one that actually completes reliably, not the one that looks cleanest on a whiteboard.

One more thing. If you are running Claude through Bedrock or Vertex, give the model version a week or two to land cleanly in your region before you build anything critical on it. I learned the hard way that prototyping on the direct API and then lifting to Bedrock at the last minute will burn a sprint on region availability and version naming. And if you are watching the broader competitive picture on AI coding agents in enterprise environments, the OpenAI and Dell Codex on-premise partnership is worth reading alongside this release — the two moves are aimed at the same buyer.

Opus 4.8 is not a revolution. It is a sharpening. And for the kind of long-running agent work I keep seeing teams try to stand up, sharpening is exactly what is needed right now.

This post was inspired by Claude Opus 4 8 via Anthropic.

May 28, 2026
Dataverse Just Got Knowledge Sources and Agent Feedback Loops and I Want to Wire These Up Now

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

What it actually does

Three things stand out from the post.

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

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

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

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

Why it matters

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

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

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

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

What I would do with it this week

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

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

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

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

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

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

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

May 21, 2026
OpenAI and Dell Are Bringing Codex On-Prem and That Is a Bigger Signal Than the Headline

OpenAI and Dell announced a partnership to bring Codex into hybrid and on-premise enterprise environments. The headline reads like another infrastructure deal. It is not. The OpenAI Dell Codex on-premise story is an admission that the real ceiling on AI coding agents in regulated enterprises was never the model. It was data gravity and where the agent is allowed to execute.

I have been waiting for one of the frontier labs to say this out loud.

What it actually does

The partnership packages Codex to run on Dell infrastructure inside an enterprise boundary. That means the coding agent can sit next to the source code repositories, the build systems, and the production data it needs to reason about, without that material crossing into a public cloud endpoint.

Practically, you get Codex behavior with private deployment posture. The agent can read your repo, propose changes, run tests, and interact with internal systems while the model inference, the context window, and the working memory stay on infrastructure your security team already owns and audits.

This is not a stripped-down Codex. It is the same agent capability, moved to a place where regulated industries can actually use it. Healthcare, defense, banking, public sector. The places where a senior engineer cannot paste a function into a public chat window without filing an incident report.

Why the OpenAI Dell Codex on-premise move matters

Every regulated enterprise I hear from has the same problem. They are not blocked on whether Claude or GPT or Gemini is the best coder this week. They are blocked on a simpler question. Can the agent see the code at all.

If the answer is no, model quality is irrelevant. You end up with developers using public AI tools on personal laptops for snippets, manually retyping the output into the secured environment, and pretending this is a workflow. That is the actual state of AI coding adoption in a lot of large orgs right now. I am not exaggerating.

Moving Codex on-prem changes the question from can we use this to how do we govern this. Those are different problems with different owners. The first one stalls for two years in legal review. The second one gets a project plan.

There is a second signal here that matters more than the deal itself. OpenAI is conceding that the pure SaaS-only posture does not work for the highest-value enterprise segments. Anthropic has been hinting at the same thing with their enterprise services arm, and Microsoft has been quietly threading this through Azure for a while. The frontier labs are realizing that data gravity beats model gravity in the enterprise. The agent has to come to the data, not the other way around.

The trade-off is real. On-prem deployments mean slower model updates, more operational burden on your platform team, and capacity you have to plan for instead of renting elastically. You give up the magic of always on latest. You get back the ability to actually use the thing.

What I would do with it this week

Even if you cannot deploy this tomorrow, you can get ready. The teams that move first will be the ones who did the boring preparation work before the procurement conversation started.

Map where your code and pipeline data actually live. Not the architecture diagram version. The real version. Which repos are in GitHub Enterprise Cloud versus self-hosted. Which CI runners can reach which networks. Which production data the agent would need to read to be useful for debugging versus generation. If you cannot answer this in a meeting, the on-prem agent conversation is going to stall on day one.

Write down the three coding tasks you would actually want an agent to do inside the secured environment. Not refactor our monolith. Specific things. Generate Power Platform solution components from a spec. Write the boring integration tests nobody wants to write. Triage failing pipelines. Pick three and put numbers on them. Hours saved, error rates, anything concrete. If you are thinking about where agents sit in a broader orchestration design, the distinction between single-agent and multi-agent architectures is worth settling before you scope the deployment.

Talk to your security and compliance partners now, before the vendor demo. The fastest path to a stalled pilot is showing up with a tool and no answer to the data residency, audit logging, and model output review questions. I have seen this pattern repeat across orgs and the result is always the same. Six months of slideware, no deployment.

Finally, watch what this does to the Copilot conversation. If Codex can run on-prem next to your code, the bar for what Microsoft has to offer inside the same boundary goes up. That is good for everyone building inside enterprise walls. The Anthropic acquisition of Stainless is worth watching in this context too, because the SDK layer that governs how these agents are called and integrated is quietly becoming as strategic as where the model runs.

The era of AI coding agents being a public-cloud-only story is ending, and the orgs that prepared their data and governance posture early are going to look very smart in twelve months.

This post was inspired by OpenAI and Dell partner to bring Codex to hybrid and on-premise enterprise environments via OpenAI.

May 18, 2026
Anthropic Acquired Stainless and the SDK Layer Just Became a Strategic Battleground

Anthropic just announced it has acquired Stainless, the company that auto-generates SDKs for OpenAI, Anthropic, and a long list of other API providers. The news that Anthropic acquires Stainless dropped this week and most of the commentary I have seen so far is treating it like a routine talent grab. I think that misses what is actually happening here.

This is Anthropic buying the layer that decides whether you actually ship on their platform or not.

What it actually does

Stainless is the tool a lot of AI labs use to turn an OpenAPI spec into idiomatic SDKs across Python, TypeScript, Go, Java, Kotlin, and Ruby. You write the spec once, Stainless generates clients that feel native in each language, handles auth, retries, streaming, pagination, and types. It is the thing that turns a raw HTTP API into something a developer can pip install and use in fifteen minutes.

Both the official Anthropic SDKs and the OpenAI SDKs have been generated by Stainless. So have SDKs for Cloudflare, Together, and others. The team built a real product around the boring but critical work of keeping client libraries in sync with API changes, generating typed responses, and producing docs that do not lie.

Anthropic is keeping Stainless running as a product and the existing customer relationships intact, at least for now. The team joins Anthropic. The IP comes with them.

Why it matters

The part I find most interesting is the strategic read. For years, the developer surface around an API was treated as overhead. You shipped a Python SDK, maybe a JS one, and called it done. Whoever wrote the cleanest curl examples won the docs game and that was the bar.

That bar is gone. When you are building agents, tool calling becomes the API. The shape of the SDK, how easy it is to define a tool, stream a response, handle a partial JSON object mid-stream, retry on a 429, all of that is what determines whether a developer ships or rage-quits. The SDK is no longer a wrapper. It is the product surface.

Anthropic seeing this clearly enough to acquire the team that builds it is, to me, a smarter move than most people will give it credit for. The model gets all the headlines but the SDK is what decides if your agent loop is 40 lines or 400. I have written before about how prototyping on the direct Anthropic API and lifting to Bedrock later burns a sprint. A big chunk of that pain is SDK-shaped. Region naming, model version strings, quota structures, retry behavior. Owning the SDK generator means Anthropic can make that migration story coherent instead of leaving it to whoever happens to be on call.

There is a real tension though. Stainless generates SDKs for OpenAI too. And for several other competitors. Anthropic says the existing customer relationships continue. I believe that for now. I do not believe it forever. At some point a feature lands in the Anthropic SDK two weeks before it lands in the OpenAI one, and people will notice. Neutrality in this part of the stack is going to be tested.

The other thing worth saying out loud: this is part of a pattern. Anthropic has been moving down the stack steadily. Trainium for compute. Finance agents and creative agents for vertical surface. Now SDK generation for the developer entry point. They are not just shipping a better model. They are building the full vertical from silicon to import statement.

What I would do with it this week

Concrete and short.

First, I would pin my current Anthropic SDK versions in any production code and write down the version numbers somewhere I will actually look. SDK velocity is about to go up. That is good news but it means breaking changes will move faster too. Pin and review on a schedule rather than letting Dependabot push silently.

Second, if you are still calling the Claude API with raw HTTP requests inside a Power Automate HTTP action or a custom connector, this is a good week to check whether the official SDK now covers your case. Custom connectors built around the SDK shape tend to age better than ones built around whatever curl example was on the docs page that day.

Third, if you have been on the fence about building tool calling into an agent, the ergonomics around tool definition in the Claude SDK are about to be the most invested-in part of the platform. Now is the time to start. I have been writing about this space long enough to know when a piece of infrastructure is about to get serious attention. This is one of those moments.

The SDK layer is where the next year of the AI developer experience will be won or lost. I am glad someone is finally treating it that way.

This post was inspired by Anthropic Acquires Stainless via Anthropic.

May 18, 2026
Power Platform May 2026 Update Shipped and UDTs Going GA Is the Headline for Me

The May 2026 Power Platform feature update dropped on May 14 and the list is long. Copilot updates, Dataverse changes, governance bits. But the one item I keep coming back to is Power Fx user defined types going generally available. If you write any non-trivial Power Apps, this is the change that matters. UDTs are GA as of version 3.26044, enabled for new apps by default, and switchable on existing apps through settings.

What Power Fx user defined types GA actually does

UDTs let you define a named, structured type once and use it everywhere in your app. You declare them with the Type function in the App’s OnStart or named formulas. Something like Type({ Id: Text, Name: Text, Status: Text, DueDate: DateTime }) bound to a name, and now every function signature, every variable, every collection can reference that type by name.

Before UDTs, type information in Power Fx was inferred from whatever record you happened to pass first. Pass a record with one less field and Power Fx would silently widen or narrow the schema. Build a component that took a record parameter and good luck enforcing what was inside it. The result was a lot of defensive coding, a lot of IfError, and a lot of runtime surprises.

With UDTs you get a contract. A function expects a specific shape. A component prop declares what it accepts. Collections carry a known schema instead of guessing from the first row. The Type function reference covers the syntax if you want the official version.

Why it matters for app maintainability

Power Apps has had a maintainability problem for years. Not because the platform is bad. Because untyped records meant every medium-sized app slowly turned into a pile of implicit assumptions. You open someone else’s screen six months later and you cannot tell what shape locSelectedItem is supposed to be without running the app and inspecting it live.

UDTs make those assumptions explicit. The variable has a type. The component prop has a type. The function returns a type. When the schema changes, you change it in one place and Power Fx tells you everywhere it breaks. That is the difference between a 2000-line app you are afraid to touch and one you can actually refactor.

There is a real trade-off though. You give up some of the speed of just throwing a record into a variable and moving on. For tiny apps that is overkill. For anything that more than one person touches, or anything that lives longer than a quarter, the upfront type definition pays for itself the first time you onboard a new developer.

The other thing UDTs do, and this is the part I find more interesting, is that they make Power Fx feel like a language you can actually build component libraries in. Reusable components have been technically possible for a while. They have not been pleasant because the prop interface was loose. With named types, a component library starts looking like an SDK instead of a copy-paste exercise. If you are thinking about how governance fits around that kind of library work, Power Platform governance that does not kill adoption is worth a read before you start standardising component patterns across teams.

What I would do with Power Fx user defined types this week

Pick one existing canvas app. Not a critical one. Something internal that you wrote and you are tired of debugging. Enable UDTs through settings, updates, new, user-defined types.

Then find the single record shape that gets passed around the most. The selected item from your main gallery, the form values for your main edit screen, the API response from your most-used connector. Define it as a UDT in App.OnStart with the Type function. Give it a clear name. Refactor the three or four places that record gets read or written to use the named type.

You will hit one or two spots where Power Fx now flags a mismatch that was silently working before. That is the point. Those mismatches were latent bugs. Fix them. Then look at any component you wrote that takes a record input and convert the prop to your new named type.

That is enough for week one. Do not try to type the whole app at once. The way I have seen this go sideways elsewhere is people treating UDTs like a migration project instead of a habit. Start with one type, one screen, one component. Build the muscle.

I have written before about moving business logic out of system prompts and into managed artifacts, and UDTs are the same idea at the Power Fx layer. Put the contract in one place, let everything else reference it, and stop hiding the schema in tribal knowledge. If you are wiring typed records into flows alongside your canvas apps, the Power Automate error handling patterns post covers how to keep that layer equally explicit about what it expects and what it does when things break. More notes on what I am building with this are on my LinkedIn.

This is the kind of change that does not look exciting in a release post and ends up changing how I write Power Fx every day.

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

May 17, 2026
Anthropic Just Launched Claude for Small Business and the SMB Play Is Getting Serious

Anthropic shipped Claude for Small Business this week. A dedicated tier with admin controls, team billing, and collaboration features aimed squarely at companies that are too big for the personal plan and too small for the Enterprise sales motion. If you have been watching how frontier AI vendors reach the long tail of orgs, claude for small business is a signal worth paying attention to.

For years, SMBs lived on Microsoft 365 plus a pile of spreadsheets and maybe a Power Automate flow somebody built once and never touched again. Anthropic just walked into that space with a real product, not a discount on the Pro plan.

What it actually does

The new tier gives small businesses a Claude workspace with team management, centralized billing, and admin controls. You get the same Claude models the rest of the market uses, but wrapped in the boring infrastructure that actually matters when more than one person needs access: user provisioning, usage visibility, and a single invoice instead of five personal subscriptions billed to different cards.

It is positioned between the individual Pro plan and the full Enterprise contract. No procurement cycle, no security questionnaire, no minimum seat commitment that scares off a ten-person company. You sign up, add your team, and you are running.

The feature list is not exotic. That is the point. Anthropic is not trying to wow SMBs with new model capabilities. They are removing the friction that kept Claude out of small business workflows entirely.

Why it matters

The interesting part is not the product. It is the strategic move.

Frontier AI vendors have spent the last two years chasing Fortune 500 logos. Custom contracts, dedicated capacity, named account teams. Anthropic’s enterprise services arm made that play explicit. But the F500 is a few thousand companies. The SMB segment is millions. And those companies make tooling decisions in days, not quarters.

Microsoft has owned this segment by default. Copilot for Microsoft 365 lives where SMBs already work. Email, documents, Teams. Anthropic showing up with a focused product means the workspace conversation is no longer a Microsoft monologue. A ten-person agency can now pick Claude as their primary AI tool without feeling like they are going off-script.

The bigger second-order effect is what mid-market buyers will start asking for. SMBs adopt fast and complain loud. The patterns that emerge here, the integrations they wire up, the workflows they build, will shape what a 500-person company asks for eighteen months from now. I have written before that vendor stratification was coming for AI tooling the way it came for SaaS a decade ago. This is what it looks like in practice. Anthropic has already shown it will compete on vertical specialization too — the Claude Finance Agents launch is a good example of how the segmentation strategy is playing out across different buyer types.

There is a risk worth naming. SMBs that adopt Claude as their primary AI surface and then grow into mid-market will be running a workspace that does not natively live inside their Microsoft tenant. That integration gap is real. It is also exactly the kind of gap that makes a third-party connector market explode.

What I would do with it this week

If I were running a small operation right now, I would do three things.

First, I would actually try the tier with a real team, not a solo account. The admin and billing experience is where these products live or die for small businesses, and you cannot evaluate it alone.

Second, I would map which workflows currently live in spreadsheets and shared inboxes. Those are the workflows that move to Claude first in an SMB. Not the polished automation candidates, the messy ones nobody owns. The places where a capable assistant with team context replaces a process that was never documented.

Third, I would think hard about the integration surface. Claude on its own is a chat product. The value compounds when it touches your actual data and tools. For a small business that already runs on Microsoft 365, that means either calling Claude from a Power Automate flow through the API, or accepting that the Claude workspace and the Microsoft workspace will live in parallel for a while. Both are fine. Pretending you do not need to pick is not. If you are evaluating how the two model ecosystems compare for automation use cases specifically, Claude vs ChatGPT for automation is worth reading before you commit to a direction.

The addressable market for capable agents just got wider. Watch what the long tail builds with it.

This post was inspired by Claude For Small Business via Anthropic.

May 14, 2026
Microsoft’s Intelligent Apps Post Is About Leadership and I Think They Buried the Lede

I opened Microsoft’s April post on intelligent apps and human leadership expecting another speed pitch. Faster tasks. Faster decisions. Faster output. The usual rhythm. What I actually read was a piece where the words intelligent apps and human leadership are deliberately bolted together, and I think most people skimmed past the second half.

The leadership piece is doing all the work in that post. The intelligent app is the easy half. I keep seeing automation teams treat AI features as a productivity multiplier when the actual constraint is whether anyone in the org is willing to redesign how decisions get made. Skip that, and you ship faster versions of the same broken workflows.

I read the post expecting another speed pitch and got something else

Microsoft could have written a clean speed story. They have the numbers for it. Instead the framing is that intelligent apps need a new shape of work, and that shape is built by humans who lead differently, not by humans who type faster.

That is not a marketing flourish. That is the part of the message that decides whether your AI rollout pays off or quietly burns budget. I have been writing about decision ownership for a while now, and this post is the closest I have seen Microsoft come to saying it out loud.

Speed is a trap when the underlying decision rights have not moved

Here is what I keep running into. A team takes a slow approval process. They drop an agent in the middle of it. The agent now drafts the recommendation in two seconds. Approval still takes four days because three managers still need to sign off, and none of them changed how they review.

You did not speed up the process. You sped up the part nobody was waiting on.

Worse, the agent now produces ten times the volume of recommendations the approval chain was sized for. The queue grows. People rubber-stamp to keep up. The quality of the decision drops while the appearance of throughput goes up. I have written before that automating a bad process just makes it fail faster. Intelligent apps make this failure mode worse, not better, because the speed gap between the AI step and the human step gets wider. This dynamic is one reason RPA vs AI automation comparisons often miss the point — neither technology fixes a process where decision rights have not moved.

If decision rights do not move, speed is a trap.

What human leadership actually has to do for an intelligent app to work

The Microsoft post uses the phrase human leadership as if everyone knows what it means. I do not think we do. So here is what I think it has to mean operationally for an intelligent app to actually pay off.

First, someone with authority has to redraw the decision boundary. Which calls does the agent make on its own. Which calls go to a human. Which calls require two humans. That is not a developer task. That is a leadership task, and most orgs avoid it because it is uncomfortable.

Second, the constraints the agent operates under have to be owned by a person, not buried in a system prompt. This is exactly why Microsoft’s business skills in Dataverse matter. They give policy a home with an owner and a version history. Without that, your intelligent app is running on tribal knowledge that nobody can update.

Third, leaders have to stop measuring the team on volume of approvals or tickets closed. If the agent is doing the routine work, the human metric has to shift to quality of exception handling and quality of policy. Otherwise you are paying senior people to do work an agent already did.

None of this is a feature you ship. All of it is org design. The Power Platform tooling will not do it for you.

The teams I see getting this right are doing one specific thing first

The teams I talk to who are actually getting value out of intelligent apps and human leadership do one thing before they build anything. They write down, on one page, who currently owns each decision in the process and who will own it after the agent ships. Same column, different rows. The delta is the work.

That page is uncomfortable to produce. It surfaces the fact that some managers are about to lose a piece of their job, that some policies have no clear owner, and that some approval steps exist only because nobody ever questioned them. This is the part most teams skip, because it is political, not technical. It is also why most Power Platform Center of Excellence setups stall in month three — the governance conversation requires the same political work that most teams defer until it is too late.

The teams that skip it ship a working app and wonder six months later why nothing changed. The teams that do it ship a smaller app and quietly reshape how a department works.

So my read on the Microsoft post is this. They did not bury the lede by accident. The lede is human leadership. The intelligent app is the part of the story everyone is comfortable talking about. The other half is the part that decides whether any of this matters.

If you want to see how I think about this kind of org-shaped problem, more of my writing is on LinkedIn. The technology is rarely the bottleneck. The willingness to move decisions is.

Frequently Asked Questions

What is the relationship between intelligent apps and human leadership in the workplace?

Intelligent apps only deliver real value when human leadership changes how decisions are made, not just how fast tasks are completed. Without redesigning decision rights and workflows, AI tools tend to accelerate broken processes rather than fix them.

Why does automating an existing process sometimes make things worse?

Automation increases the speed and volume of outputs, but if the approval or review process stays the same, the bottleneck simply gets worse. Teams end up rubber-stamping decisions to keep pace, which lowers quality while creating the illusion of better throughput.

How do I know if my organisation is ready for an AI automation rollout?

A good starting point is asking whether decision rights have been clearly assigned and whether leaders are willing to redesign how approvals and reviews work. If those structures are unchanged, adding AI tools is likely to surface existing problems faster rather than solve them.

When should I redesign workflows before deploying intelligent apps?

Workflow redesign should happen before deployment, not after. If the human steps in a process have not been updated to match the speed and volume AI generates, the technology will outpace the people it is meant to support.

This post was inspired by Intelligent apps, human leadership, and the new shape of work via Microsoft Power Platform Blog.

May 7, 2026
Microsoft Just Reframed Dataverse as the Agent Data Platform and the Update List Is Worth Reading

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

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

What it actually does

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

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

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

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

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

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

Why it matters

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

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

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

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

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

What I would do with it this week

Three concrete things, in order.

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

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

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

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

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

May 6, 2026