Autopilots are here! This was the Build 2026 keynote message from Satya Nadella last week:

So, Microsoft is no longer The Copilot Company that Satya envisioned a couple of years ago. Which makes sense, given how the Copilot brand has not become quite as valuable as the company would have wanted to. While it’s present in most organizations, thanks to the massive distribution power of Microsoft, we’ve seen reports of how when given a choice, users actively pick something other than Copilot.

It’s not yet clear at this point whether Autopilots become a proper brand or just remain a concept used in marketing. In any case, it feels like a missed opportunity to pick a new AI brand that would have carried more positive emotions for many of today’s tech workers that grew up in the 90s (credit to Tim Mayo for the idea):

Drake meme: Autopilots vs. Autobots

The flagship Autopilot of this new category of AI agents presented at Build was Microsoft Scout. The subscribers of this newsletter may know it by its former name, ClawPilot, that has been used in context of the MS internal version of Scout.

Clawpilot: no UI for AI

What if we didn't have to open Copilot and just hope we prompted it the right way? The rise of OpenClaw has shifted expectations on what AI agents can do when given the (scary) permissions.

Perspectives on Power Platform • Jukka Niiranen

In this week’s issue, I will take a deeper look at what the official story with Microsoft Scout is and how it differs from the observable reality. The Frontier preview announcement doesn’t quite tell the full story but that’s okay — more material for me to cover in Perspectives, then! But first, let’s zoom out a bit and put all these recent AI pilots into perspective.

Let me count the Autopilots

Keeping up with Microsoft’s AI agent products is the kind of a task where I personally definitely welcome help from AI tools. Even if I have a good hunch of what I should be looking for and where, it would simply take too much time to manually open the tens or even hundreds of web pages that provide relevant bits of information. So, I once again requested Claude to produce a single HTML page that illustrates the big picture of Autopilots:

Microsoft's search for the treasure of autonomous AI agents

Let’s go through the points on this AI treasure map and see how they align with the Autopilot story.

Copilot Studio agents. Most of us know this story already. In Spring 2025, Microsoft published the first and so far only numbers on how much Copilot Studio agents were being used by their customers (equaling roughly 0.04% of Microsoft total revenue). Since then, autonomy has been introduced by adding essentially Power Automate style triggers into Copilot Studio agents. In the very latest twist, such logic is now moved away from agents and into Copilot Studio workflows.

New Workflows editor in the modern Copilot Studio experience.

Project Opal. Introduced at Ignite 2025, this was supposed to be “a new AI-powered capability that executes task-based work inside a secure, observable environment you control”. After Microsoft revamped the M365 Copilot app navigation, rediscovering the Opal (Frontier) agent has been challenging. This made me question whether the project was still alive, yet I did manage to re-provision the related Opal Windows 365 cloud PC that had been deleted due to inactivity. Nothing much has been announced after November 2025 around this, though.

My observable Opal environment: Microsoft 365 Copilot cloud PC visible via Intune.

Agent 365. I started covering this product a few months before the Ignite 2025 announcement and I’ve been following it closely ever since. What was initially marketed as a complete tools package for autonomous AI teammates was since then reduced to a mere governance layer for agents in your tenant. I blame the commercial rush for getting M365 E7 Frontier Worker Suite out the door before FY26 end for this. Here’s a “tribute” I made to the $99 product rollout strategy of Microsoft:

Copilot Tasks. If you weren’t paying close attention, you might think this was just a regular M365 Copilot feature, a bit like the mysterious scheduled prompts I’ve explored earlier. But it’s nothing like that. Tasks is a consumer Copilot capability that was launched behind a waitlist and has so far not been made available outside the US. There’s very little info or details about this shared online as a result. Recent complaints from paying private Copilot users suggest the capacity for Tasks is not properly reallocated and there’s no news on when the preview period might end.

Copilot customers not happy with Tasks capacity limits frozen in late May.

Copilot Cowork. Anthropic’s victory lap. After Microsoft’s own efforts to use OpenAI’s models to allow Office tools to generate useful documents had failed repeatedly, the solution came from partnering with another AI lab. Licensing the Cowork harness familiar from Claude Desktop and making it run in the cloud as Copilot Cowork has shown itself to be the most applauded tool in M365 Copilot. All of this despite it being built on Linux VMs and leveraging tools like LibreOffice to generate and validate MS Office docs. But it’s the end result that counts. During the Frontier preview phase, there aren’t even any Copilot Credit costs for running the tool — although I certainly wouldn’t bet on it being the commercial model going forward…

Microsoft Scout. Taking OpenClaw, a thing Satya Nadella once compared to a virus, and deploying it inside your Microsoft 365 tenant. This is now positioned as the new era of truly autonomous AI agents and the whole Autopilot story basically relies on Microsoft getting it right. There’s certainly a lot of synergy in how the enterprise giant could potentially tame the wild beast of OpenClaw and make 2025 2026 the year of AI agents for real.

Yeah, about that Responsible AI…

Before anyone even had a chance to try it, there was already controversy online about the new Scout product. 404 Media had received the internal strategy document that outlined how Microsoft wanted to “make people addicted” to the tool before rolling out additional functionality. While it is hardly a secret that software vendors would want their customers to crave for their products, this kind of language easily raises concerns about the AI addiction phenomenon that has been getting more and more coverage in the media.

For Microsoft in particular, this image does not align well with the humanist superintelligence message recently promoted by their AI CEO, Mustafa Suleyman. Perhaps this was one reason why Satya Nadella’s reaction to the addiction headlines was so strong: “Not sure what this document is or who is writing and leaking this nonsense! They may want to go work elsewhere.” This, in turn, resulted in an even better headline for the follow-up article on 404 Media:

Satya Nadella ‘Not Sure’ Who Said Microsoft Wanted to Make Addictive AI, Is Looking for Guy Who Did This

“The guy” is of course Omar Shahine. After many long-time Microsoft senior leaders recently decided to leave the company, this has given room for new rising stars. Alongside the certified superstar Charles Lamanna, the former Corporate Vice President of Word, Omar, is certainly one to watch for. Sure, he’s been at MSFT since 1999 already, but I feel there are big things ahead for his new team that’s bringing OpenClaw to M365.

What started as Omar’s personal project of running a local OpenClaw deployment on a MacBook in his home office, then evolved into a vibe-coded home automation integration with OpenClaw, has turned into a big bet for Microsoft. Back when Project Lobster was originally published, I found myself wondering: “hmm, is this fully aligned with Microsoft’s internal information security policy for their product leaders?” Well, obviously it was perfectly fine to wire up the physical sensors of your home office with an autonomous LLM agent and let it observe any meetings the CVP was having.

Anyway, let’s circle back to that addiction part. We know Satya was also an early follower of the OpenClaw project, which could be justified by the business potential and technological novelty. At some point, though, things may get too intimate between tech geeks and AI agents. Wikipedia says: “AI anthropomorphism is the attribution of human-like feelings, mental states, and behavioral characteristics to artificial intelligence systems.” Now, if there was a picture in that article, it might as well be something like what Omar posted:

“What do you think about being the first Scout in the world, ever?” Omar Shahine having a conversation with his OpenClaw-based AI agent named “Sebastian”.

You may not see your Copilot as a lovable person when opening M365 tools. Yet the design of Microsoft Scout and how it is marketed is definitely maximizing the chances of humans mistaking AI for an actual person. It goes well beyond giving Copilot a face and calling it “your AI companion”. Rather than being an app you need to proactively launch, Scout is designed to be a thing that reaches out to you when there are signals and decisions requiring your attention. It will live in the same chats as messages from your real colleagues and friends. In the increasingly digital world that surrounds us, forgetting that Sebastian isn’t real is becoming all too easy.

Will the Real ClawPilot please stand up?

Finally, let’s look at what is real and available today. As is often the case, what the Microsoft marketing blog posts say and what the docs actually reveal are two different things. Rarely has it been as obvious as it is with Microsoft Scout, though. This is what the marketing team would like you to think Scout is:

Notice how even the URL in the video’s mock UI points to the consumer version of Copilot, not the M365 work version? Who cares, we are reimagining autopilots here! On the bright side (for Microsoft), most people watching the video will not even have the technical ability to try the Frontier preview, so they won’t know it’s just aspirational animations rather than a real product at this point.

So, what are the prerequisites? The fun part is, not even Microsoft seems to agree on them. The docs page for getting started with Scout has gone through multiple revisions over the first few days. The requirements for Microsoft 365 Copilot license have gone on, off, and then on again. Similarly, the GitHub Copilot Business or Enterprise license requirement was added there after the launch.

Upon testing it with my demo user account (I ain’t gonna let this thing access my real customer data!), there didn’t seem to be any license enforcement for the M365 Copilot license. Activation on a Windows 365 machine in my tenant went through just fine without it. And why wouldn’t it, because this thing doesn’t run on Copilot Credits. Instead, it burns GitHub Copilot AI Credits like there’s no tomorrow.🔥

Back in 2021, when I had made the leap from being a Dynamics 365 CRM consultant into a Power Platform entrepreneur, I wrote about the bigger picture of what was happening with low-code. The topic of the blog post was “Democratizing code”. Given what has happened to the concept of code in the past year, thanks to LLMs and coding agents, it was now time for the 2026 me to read and reflect on the thoughts of my past self.

Democratizing code - Jukka Niiranen blog

Could low-code platforms like MS Power Platform democratize app development the same way Web 2.0 did it for social content creation and sharing?

Jukka Niiranen blog • Jukka Niiranen

The post-ChatGPT world is different in a way that I could not have imagined five years ago, but I’m not going to hold that against me. Practically no one saw what was coming and how that would affect the way apps are built today. Honestly, I expected there to be roughly a decade of the Power Apps era low-code development ahead of us. Yet things changed gradually, then suddenly, and now 2031 has arrived in half the time I assumed.

This one paragraph from my original post feels pretty accurate, though:

Even at times when the Copilot fanfare from Microsoft has triggered my snark cannon, resulting in some mighty critical posts, I have remained optimistic that AI is going to be hugely useful for makers. I’m less sure about how well the autonomous AI agents meant for replacing humans in the operation of business processes will live up to market expectations. But when it comes to building new tools, LLMs are the tool I’ve always wanted.

The arrival of coding agents and the resulting generic information worker tools like Cowork are truly doing what was the prophecy of my article: they are democratizing code. In the recent Platformer newsletter issue, there was an interview with Boris Cherny, the creator of Claude Code. He talked about what the impact from his work has been on the non-programmers in the team:

The Platformer: Claude Code's creator on the end of the software engineer

“Everyone on the team codes.” This isn’t just about cutting away managerial layers that don’t add value. Or pushing designers to create working prototype apps instead of mock UIs. I see the shift being about the usefulness of code expanding to new areas of work. Because of the fluency that LLMs have on written instructions like software code, we no longer have to hide it away behind protective layers like cloud SaaS app GUIs.

Creating apps is easier and faster than ever. Yet simultaneously, having things locked behind a GUI is becoming increasingly harmful for the usefulness of data. Precisely because it’s an experience designed for humans and not an ideal interaction pattern for LLMs. Chat boxes and terminals have many similarities in how the human is expected to interact with them. Thanks to the power of local compute resources and tools, that is where an AI agent is at its happy place — resulting in a surprising resurrection of the 80s style terminal UIs (here’s a gift link to my earlier premium issue about TUIs).

The new bottleneck is apps

Instead of starting from a M365-like suite and adding AI, Anthropic pursued a "no apps" model and caught everyone's attention with Claude Code. Maybe all you need is text files?

Perspectives on Power Platform • Jukka Niiranen

For an LLM, it doesn’t matter if the files being worked on are TypeScript or Markdown. As for humans, there’s probably 100x more people out there who could read and write .md files compared to .tsx files. Once information workers become brave enough to touch something that looks a bit like code, rather than a traditional Office document, the barrier to introducing scripts to automate .md file creation and processing is no longer that high. And once you get to generating scripts via talking to your LLM buddy, it will soon suggest generating more and more advanced tools for helping you achieve your expressed goals quicker.

Then, all of a sudden, you are coding. But you aren’t exactly a programmer. This gets us to the same dilemma that my 2021 article talked about: what exactly do we call these people? With the rise of Power Platform apps and automations, it was becoming obvious how the term “citizen developer” wasn’t a fair description of the new roles forming around low-code solutions:

The only clear distinction I saw back then was “you don’t write much code”. Well, that’s not very helpful in the year 2026 anymore. Like Boris Cherny says, “everyone who's not an engineer is going to code a little more, and engineers like me are going to code less”. Direct review and writing of code might remain reserved for those with an engineering background. The other 95% of people working with code will use the abstraction layer of coding agents to do it. But the professional developers will be using that layer far more and burning tokens at a much higher rate.

So, we can’t simply look at the activities anymore. Code work is becoming something more like driving: knowing that you were driving a car today doesn’t help me deduce whether your profession is a taxi driver or an office worker that just did their daily commute on the highway. We travel on the same roads, even if our roles in the grand logistical scheme of things is pretty different.

The risks of vibe coding are similar to those introduced by features like Tesla’s “Full Self-Driving.” In theory, you could ride in the car while drunk, sleeping, or incapable of steering the vehicle, and still get to your destination safely. If things go wrong, though, the car manufacturer is not going to be paying for the damages.

This leads us to the topic of whether the profession of software engineering is going away. I find it hard to believe that the total number of people doing software engineering would decrease anytime soon. Vibe-coding is a bad idea for probably most of the existing software systems we have in the world today. While you maybe could prompt your way to a small B2B sales CRM system today with no understanding of software architecture, doing something similar with an accounting system sounds a bit dangerous.

I feel the right point of comparison is not the existing software, though. Just like low-code wasn’t about replacing the Dynamics 365 systems with canvas apps built on SharePoint lists, the disruptive power of AI-generated code is not in eliminating SaaS subscriptions entirely. Low-code was often applied for replacing Excel workbooks. Vibe-code extends those same powers to scenarios far greater than 2D sheets of text and numbers on a digital Office canvas.

So far, the most interesting session from Build 2026 that I’ve watched has been from the creator of OpenClaw. “Build the thing that builds the thing” is a no-slides presentation of Peter Steinberger describing how he has addressed the explosive popularity of his project and what strategies have helped the small open-source team thrive.

Peter Steinberger, “the Clawfather”, presenting at Microsoft Build 2026.

“I find being annoyed is the very best way to solve problems.” Wow! I didn’t know Peter and I have so much in common. In case you haven’t noticed it from my community contributions, the vast majority of them are powered by sheer annoyance. There’s nothing quite like being frustrated with how things work (or fail to work) to give you an energy boost to do something about it. In the past, I could mostly just solve things via writing. These days, I can also create a repo full of code to solve a problem for me and others.

What fuels the vibe-code movement is not so much the efficiency gains of how to ship more software faster. Existing software projects and products will undoubtedly look very different in a few years time, yet it will still be about doing what was already being done. I believe the truly transformative powers are how AI helps democratize code that solves net-new problems. To build tools for problems that would have never been feasible to solve with code done in the classic way.

The creator of OpenClaw doesn’t just create more claws. In fact, the Build 2026 session was a demonstration of the incredible array of vibe-coded tools that Peter Steinberger and his team had created to help them focus on building their main tool (OpenClaw). His core claim is that the bottleneck is no longer just writing application code. It is building the surrounding loops, context, review, testing, triage, and UI automation that let coding agents work faster with less human babysitting.

Crabbox: remote software testing and execution control plane built around short-lived test boxes.

In the context of OpenClaw, the ways to reduce annoying manual work range from throwaway remote testboxes (Crabbox) to Discord user feedback aggregation (Discrawl) to capturing developer AI agent chat logs alongside code commits (Entire), all the way to building your own Slack clone for AI-friendly messaging (ClickClack). All of these have naturally been built purely with vibes and some AI agent prompting. Quite literally by just describing the problem in a prompt, letting the coding agents work on it, putting other agents in place to review it, and then the human comes back to see the final product.

This sort of hands-off development doesn’t suit each and every software project, of course. It doesn’t have to — because custom software no longer needs to be a project. Sometimes you are merely solving a problem for yourself. What used to be limited to personal productivity canvas apps or cloud flows can now be applied to almost any form of output. If you’re annoyed enough and you can work with code (not read or write it), today there’s not much stopping you from generating a solution you personally like. It may be software for the audience of one, for your team, or for anyone who finds your repo on GitHub.

As an example, I have been very much annoyed with the experience of sharing slides online. Ever since LinkedIn bought SlideShare, then Microsoft bought LinkedIn, and then they sold SlideShare to Scribd, there’s been no decent alternative to the enshittified experience of the original site. I wanted to migrate my deck history away from there, so I built ShareSlides:

“Annoyance-Driven Development” presentation on my ShareSlides site.

It’s simply a place where .pptx and .pdf decks can be published as more than just raw downloads on GitHub. Now, the actual site does run on GitHub Pages, so technically the files are there. This vibe-coded app of mine just offers the viewing, sharing and embedding features that we learned to expect from online presentations, thanks to what SlideShare launched 20 years ago.

Slides aren’t what they used to be, of course. Today, we can easily generate interesting visual summaries from any online content, using services like Google’s NotebookLM. As an example, this Annoyance-Driven Development deck is based on what Peter Steinberger presented at Build. I picked the .vtt transcript file and asked my Codex to summarize it, then handed it over to NotebookLM to focus on that key concept that I found so compelling. And now it is shared on a site running on software built from sheer annoyance.

DynamicsMinds isn’t just another conference. Literally every attendee you’d ask about it would tell you how unique the event is in both its surroundings and atmosphere. I’ve come to the conclusion that we need to reimagine the terminology used when referring to DynamicsMinds: it’s not a conference — it’s a festival.

Out of the thousand plus attendees, one in five is also a speaker at the event. Despite there being a big emphasis on the ERP side of Dynamics 365, even for a Power Platform guy like me there were just too many interesting sessions to choose from. In this week’s newsletter I’ll share the interesting bits about my visit to Portoroz, Slovenia.

Licensing

My session this year was titled “What license does your agent really need?” I submitted the session topic back in December, after Microsoft had announced the preview of Agent 365 at Ignite 2025. I figured that by May the licensing model of the agentic employee story would probably be public information. Well, some answers were provided in the May 1st GA launch but some of them only sparked further questions to explore. At least that meant I had a lot to talk about during the 45 minute slot.

Showing the different types of agents that you need to consider when determining licensing needs.

I didn’t want to only show slides but also some live agent license consumption data in my tenant. Vibe-coding should make it quick to spin up new demo artifacts, but since Copilot Studio does not yet have CLI support, generating Copilot Credits consumption turned out to be quite laborious. What was super simple, though, was taking the raw CSV reports from PPAC about entitlement consumption and throwing them into Copilot Cowork. In less than 15 minutes, I had a demo-ready Excel workbook with multiple tabs and charts to illustrate the different dimensions of agent billing, in a far more useful format than anything in PPAC could deliver.

André Arnaud de Calavon presenting “From Confusion to Clarity: Mastering Dynamics 365 F&O Licensing”

I always try to attend a few F&O sessions when I get the chance, even if my hands-on experience with the product is non-existent. Licensing enforcement has been a hot topic in the Dynamics 365 Finance & Operations domain for over a year now. In the session by André Arnaud de Calavon and Fatih Demirci, I saw how many variables there are around security roles, privileges and duties that impact the level of user license required. Whew! On a lighter note, André’s slide about Standard vs. Premium licenses helped me discover the absolute cheapest way to buy additional Dataverse capacity — which is getting 10 F&O Premium seats, even if you’re not using the product.

MCP

The word of the year 2026 for Microsoft business apps community has to be MCP. I lost count of how many MCP related sessions I attended, but I’m pretty sure you could have assembled one entire track out of those for the three-day event. That’s not a bad thing, considering how often the protocol name is used as a simple “sure, we support that via MCP” way without drilling into the practical details and gaps.

“Building a Company-Wide MCP Server: The Foundation for Specialized Copilot Agents Across Dynamics 365 and Beyond”

Juan Antonio Tomás and Oriol Ribes showed a great “what to use where” slide on the different options to keep in mind. After MCP first became popular in the developer community, soon some were already saying “MCP is dead” and doubling down on CLI’s instead. In reality, you’ll most likely need to use both MCP servers, CLI’s, skill definitions and traditional REST API calls to develop and run solutions built for business apps use cases in the enterprise.

“How Copilot Studio Really Accesses Dataverse (And Why It Matters)”

And even if you’re not a code-first developer, the role of MCP servers is crucial to understand also in the GUI context of tools like Copilot Studio. Angeliki Patsiavou and Sean Astrakhan demonstrated how it makes a difference whether your agent is accessing data through knowledge stored in Dataverse, the traditional Dataverse connector or the new Dataverse MCP server. Crazy stuff. And that’s even before we talk about the differences between the Sydney and Samba orchestrators behind your Copilot agent.

The two engine options of Copilot agents

Why does Microsoft have different orchestration engines behind Copilot Studio and M365 Copilot agents, codenamed "Samba" and "Sydney"?

Perspectives on Power Platform • Jukka Niiranen

Code

Someone had to say it, and I’m glad Ivan Ficko was the brave one to put up the slide: “Canvas apps are dead”. Then, I made a post about it on LinkedIn late at night, went to sleep and woke up to 100+ comments and growing. It reminded me of why I picked this graphic to be my company logo:

The original framing for Ivan’s slide was how Power Apps code apps have gradually matured to a point where it is hard to justify trying to build net-new canvas apps anymore. You can even take an existing canvas solution, point GitHub Copilot to it, and ask it to build a proper React app out of its YAML definition. At that point, none of the frustrating limitations of canvas apps apply anymore. Instead, you’re free to treat it as a code-first artifact that any LLM will know how to develop further, create test suites for, validate via built-in agentic browser in VS Code, and so on. All while still leveraging the managed platform and the familiar connectors.

“Power Apps Code Apps: Pro-Dev Meets Low-Code”

Canvas apps truly have lost their place in my world. And I ain’t sad about this. Sure, the idea of having to prompt my apps into life via a tiny chat window rather than a visually rich WYSIWYG editing experience is not that attractive. Yet the trade-offs we’d need to make by sticking to canvas apps and hoping that Microsoft would modernize the tooling is just too big when compared to what AI coding agents can do for you.

With apps based on codegen, I can stop being the “old man yells at Microsoft” type of a guy who curses all the fine features the platform vendor has left to rot for years. Now, it is up to me to build the solutions the way I want them. I can move to yelling at my coding agents and blaming only myself for not being able to create the outcome that I envisioned. That is a mighty empowering feeling.

For instance, if I’m not happy with what the conference apps and websites allow me to do, I can just roll my own. So, on my way from Helsinki to Venice to Portoroz, I spent a couple of hours putting together a personal DM26 app that served not only as a session catalog but also as a mobile-first business card app that presented who I am and what my activities at the event were going to be. The first part was done on my laptop before boarding the plane, the finishing touches like QR code and content optimization I prompted via Claude Code while sitting in a shuttle bus hurling down the Italian autostrada.

My vibe-coded GitHub Pages landing page for DynamicsMinds 2026 event materials.

Since I have also given up PowerPoint and moved to creating my presentations with Slidev and Markdown files, I realized the same GitHub repo could serve as the slide player. If I had wanted to, I could have just run the full presentation from the GitHub Pages website that the attendees also had access to. But since I didn’t trust the venue Wi-Fi, I launched a local web server from my laptop with a shell script that Codex has prepared for me. From there on, it’s just interacting with a web app like in any other tool. These things will sound very complex, until you just go ahead and do it — at which point you’ll be “oh, that’s all there was to it?”

AI

If it was a Microsoft organized event, the framing of AI would have surely been a lot more sugarcoated. But at DM26, thanks to what the organizers prioritize as the important values and topic to discuss, there was plenty of room for critical discussion on what’s happening in the world today.

I was a panelist at two sessions covering this theme. The first one, “Don’t Look Up: How AI Is Redesigning Work, Roles, and Learning”, went right into the dystopic side of what may happen if machines replace human workers. Many fear how especially junior employees at Dynamics partner companies will have a hard time getting into the business. Personally, I trust the kids will be alright with finding their way and place in the AI-infused working environment. The bigger risk is with middle management who doesn’t realize the structures and barriers at work will come tumbling down as LLMs democratize the act of building software and give on-demand bespoke tools for any information processing need.

Ana Gligorijevic, me, Ana Lampret, Morten Loegstrup and Martin Smit at the last panel of the event.

The other panel, “From SaaS to OaaS – What Happens When AI Does the Work”, was focused on the partner business model impact. Seat-based SaaS licensing was a goldmine for companies like Salesforce and Microsoft for two decades, but now we can no longer ignore the inference costs from using LLMs as part of the products. Will consultants need to move from Time & Material to Time & Tokens billing, or commit to a true outcome-based pricing model? I think we’re not there yet, regardless of how vendors like to use OaaS and other fuzzy credit concepts to obfuscate the actual cost of services.

Being the only solopreneur in the partner panel, my perspective was of course quite different from a typical Dynamics company — or even a customer org. What I’ve seen happen with coding agents in the past six months and how they’ve transformed my own work is pretty wild. The big concern is no more “can I do this” but “should I do this”? Pacing yourself with all these possibilities unlocked by Claude & co. requires a lot of intentional self-management. One piece of advice I gave to the audience was to also be very open about the things that didn’t work with your AI experiments. Failing is an integral part of how humans learn new things. Let’s not rob ourselves this opportunity to collectively learn from mistakes by masking it all under the fabricated success stories that AI chatbots are so good at producing. Honesty and transparency are more important now than ever before.

Olof Hedin from Lovable, talking about “the consequences of the democratization of software development”, showing how many users they have from the companies attending DM26.

Accepting that sometimes the tools you have built are no longer the right ones for the job is one example of honesty. When a company like Microsoft chooses to create their keynote UI mock-ups of their upcoming products not with MS technology but by using an AI app generator like Lovable, that’s a sign of not being afraid to admit that maybe Power Platform isn’t the best choice for every scenario. Olof Hedin from Lovable said that Microsoft staff are already broadly using the product for internal needs. It reminded me of how MS engineering also embraced Claude Code to improve their agentic software delivery capabilities. When the world moves at the speed of AI, there’s no room for the “not invented here” syndrome.

People

What’s the secret formula that makes DynamicsMinds such a stand-out event? I think it’s simply this: the people organizing it truly care about the people attending it. There’s no other way to explain the attention to detail and the passion that shows in everything around the event. This is a virtuous cycle that in turn makes the attendees feel welcome and appreciated, thus opening up their minds for encounters with old and new friends from the community. And then, magic happens.

Me receiving my community award from the amazing Mira Ražman, captain of the organizing team.

Like with any festival, the all-star line-up is a key selling point for making people want to purchase their ticket. The way speakers in particular are taken care of at DM is outstanding. I truly couldn’t think of anything more that the organizers could do in terms of hospitality — and yet I bet the standards will be exceeded next year again.

Speaker pre-day tour in the old town of Piran, after a boat trip, wine tasting, music performances.

Thanks to all the folks I had a chance to interact with in Portoroz this year. And for those that didn’t make it there, be sure to reserve the last week of May 2027 in your calendars already!

Every now and then, we see forum posts where people are puzzled by why the performance of agents built with Copilot technology differs based on the experience in which it was built. With the same models and same prompts, the results can be noticeably different:

Reddit post: Prompt performance in Copilot Studio vs Copilot Chat

Microsoft doesn’t disclose much information about the reasons behind this. The impact can be quite significant, though. That’s why it’s important that everyone who builds their own agents for Copilot knows a bit more than the MS Learn docs will reveal.

Introducing Samba and Sydney

The most Microsoftian thing to do is of course to take two different technologies and give them one name. This is what happened back when Power Virtual Agents was “reimagined” as Copilot Studio in 2023. An even more recent episode was when the Microsoft 365 Copilot Agent Builder was renamed to Copilot Studio lite, and then back to Agent Builder again:

Microsoft going back & forth with the Copilot Studio lite branding.

The origin story of what today is the Microsoft 365 Copilot agent experience and the Copilot Studio agents goes back much further. We have to reach all the way back to a pre-ChatGPT era, in fact. Out of the two engines behind Copilot agents in 2026, the other one began its journey already a decade ago.

Sydney & Samba lineages: search/LLM native timeline from 2020 vs. Bot Framework from 2016.

The Samba lineage begins from Build 2016 announcement of the Microsoft Bot Framework. What first was a pro-code offering as Azure Bot Service got its low-code counterpart in 2019 when Power Virtual Agents (PVA) was released as a new member of the Power Platform family of products. For the first three years, no one cared too much about these agents.

The Sydney lineage is founded on what actually became the biggest thing since the internet, meaning large language models. The first traces of the codename go back to 2020 in the early chat mode experiments with OpenAI. When Bing Chat became a public thing (the predecessor of Copilot), there was enough controversy to earn Sydney its own Wikipedia article.

Don’t trust everything you read on Wikipedia, though. The consumer side of Sydney’s adventures as a controversial chat personality may have come to an end, but it very much lives inside the Microsoft 365 Copilot business offering today. More specifically, as one of the orchestration engines that you can use for Copilot agents. You may occasionally find Microsoft personnel refer to the two codenames online, or find it in detailed PDF docs about Copilot Studio.

This is about way more than MS codename trivia, though. The divide between orchestrators of Copilot agents affects the developers, makers and users today.

What engine is used in which agent?

At this point I’ll give the floor to Claude and allow it to present the research results of product facts before I continue the narrative.

Thanks a lot for producing the missing manual, Claude! Now, let’s continue our regular, opinionated newsletter broadcast.

The confusing reality of Copilot agents administration

If you have worked with only one type of agents, either purely from the Power Platform side or from within the M365 side, you might not have encountered the strange divide caused by the two orchestrator engines. For those who are administering and governing agents on a tenant level, the issues have hopefully become apparent by now.

There hasn’t been a unified view of all the agents in the tenant, for starters. Now, with Agent 365 being generally available, one could have hoped for a harmonized catalog in exchange for the premium license of $15pupm. What we have today is still a disjointed experience of agents from five different Microsoft-owned platforms each having their own properties that don’t map with one another. AI agent master data management remains an elusive goal.

Viewing the Agent 365 agent map in my own tenant.

The picture above illustrates another key difference between the two worlds, although it’s not specifically about the orchestrator. Copilot Studio agents built within Power Platform appear for as many instances as they exist in your dev/test/prod/etc. environments. Agents that are published to Microsoft 365 Copilot via other means just have a single instance in the catalog. In other words, Samba agents are environment-scoped while Sydney agents are tenant-scoped.

Slide from Update Days Power Platform 2026 session “Why auditors trust Power Platform more than custom code” by Jakub Bajla.

When it comes to governance features beyond the agent inventory, there are also differences in how tools like Purview DSPM for AI support Sydney vs. Samba based agents. Microsoft is naturally working to close the gaps on how the agents support M365 security and data protection features like insider risk management and so on. That doesn’t take away the fact that you cannot just ask “if our users create agents with Copilot, do they support X” without specifying if it’s a Sydney or Samba based experience. Imagine how difficult it is for LLMs to provide accurate answers to seemingly simple questions as a result of this?

Compromises on agent capabilities

As the example Reddit post illustrated, the knowledge sources, connectors, instructions and LLM versions aren’t the only thing that determines how well your Copilot agent performs. Especially for the subscribers of this newsletter, it’s important to emphasize that agents built on the Power Platform side are not necessarily better. In fact, due to how newer Sydney orchestrator on the M365 side was built for the LLM era, it may often excel in everyday knowledge access scenarios that don’t rely on Power Platform connectors.

The most comprehensive online source for the agent builder options compared side-by-side that I’ve come across has been published by Andrew Connell. You’ll find plenty of interesting details about how Copilot agents actually are built and operated from this webinar recap:

4 Ways to Build Microsoft 365 Copilot Agents Compared

Compare 4 Microsoft 365 Copilot agent options: SharePoint agents, Agent Builder, Copilot Studio, and declarative agents, with licensing and architecture tips.

www.voitanos.io/blog/microsoft-365-copilot-evaluate-your-agent-options-webinar-recap-20260408

What Andrew focuses on is the myths around Declarative Agents (DA) built with the Microsoft 365 Agents Toolkit (ATK) and how they would be a pro-coder only type of a solution. Especially in this age of AI-generated code, one doesn’t need to be a software developer to ship something that’s basically just JSON and YAML. If anything, given the often convoluted and slow maker portals for Power Platform products, I personally try to avoid the GUI route these days when building and editing artifacts if at all possible. Yes, and this is coming from a low-coder who hardly ever opened VS Code just one year ago…

Now, to make things super clear, Microsoft’s documentation also lists Copilot Studio as one of the four ways to build Declarative Agents. Oh great… It means we still have no definitive term to distinguish between agents using the LLM era Sydney engine or the Bot Framework era Samba engine. In situations like these, it often makes sense to not get stuck with what MS wants to call things and follow what the practitioners out there in the community choose to use. So, let’s frame DA as the non-Copilot Studio agent path here.

Andrew Connell presenting on the role of the semantic index for Copilot agents.

The big thing in the context of internal AI agents is… the organizational context. In the case of Microsoft 365, this is essentially the semantic index. The superglue that is supposed to tie together all those emails, messages and documents from across Microsoft Graph and turn them into something the agents can leverage. And here’s where the big difference lies.

First of all, if your tenant doesn’t have any of the $30pupm M365 Copilot licenses, you won’t even have a semantic index. As these aren’t a prerequisite for Copilot Studio agents built and used via Copilot credits, it could technically be that there’s no MS Graph grounding available at all. But even if the index exists, a Copilot Studio agent won’t have as broad access to tenant grounding data as agents built with M365 tools.

Sydney has native, direct access to the M365 Semantic Index. Samba must go through a different API path to reach the same content, and that path has a lower retrieval budget. In Andrew Connell’s presentation, he says the exact same prompt in used in DA will bring you back 10 documents, whereas a Copilot Studio agent will only retrieve 3 documents. This mirrors the many experiences reported online where the graph grounding simply is weaker from the Copilot Studio side.

Connector and action barriers and possibilities

Maybe it’s understandable that to build Copilot agents that are great with M365 data, you’re better off ignoring Copilot Studio tooling in Power Platform and sticking to M365 native tooling. The problems arise when the requirements for the agent include both having graph grounding as well as access to business process specific data sources. Again, this isn’t a black/white situation where the decision tree is “if I need to access ServiceNow data, Copilot Studio is the way to go”. No, that would just be too easy.

As you should know by now, the product formerly known as Power Virtual Agents is natively working with Power Platform connectors. This list will be much longer than what’s available for the DA’s on M365 side. But again, with today’s AI coding agents and how they can handle REST APIs, the availability of a pre-built connector isn’t as big a deal in practice as it was just a few years ago.

If Power Platform connectors are like wrappers around REST APIs, Copilot connectors are something quite different. Following the now familiar pattern of “one name, many things”, there are today two different variants of these. Synced connectors are content indexing pipes, formerly known as Microsoft Graph connectors. They crawl external data sources on a scheduled and copy the content into the semantic index. There are roughly 150+ available, including Microsoft-built connectors for Jira, Confluence, ServiceNow, and Salesforce.

Federated connectors are the new kid on the Copilot block. These use the Model Context Protocol (MCP) to fetch external data in real time without indexing anything into Microsoft Graph. Like with Power Platform connectors, users connect with their own credentials. There’s only 10 connectors available for now, all built by Microsoft, and they can only be referenced in three specific agentic surfaces today. Just like synced connectors, they remain read-only rather than full CRUD like the Power Platform connectors.

The writing was on the wall for quite some time. Now, it’s also on the official docs in MS Learn: The Power Platform CoE Starter Kit is no longer actively maintained.

MS Learn home page for CoE Starter Kit updated with a note about no more maintenance.

We already saw how the monthly releases of the Kit stopped in February 2026. This was a clear enough signal for me to write my farewell post to the CoE Starter Kit on LinkedIn last week.

R.I.P. CoE Starter Kit release milestones.

It’s hard to overstate the importance of this project for what Power Platform came to be. The inevitable closure of the chapter deserves a bit of a retrospective before we move to talking about how life will go on. In this issue I’ll talk about my personal encounter with the CoE Starter Kit and how the current tooling offered by Microsoft compares to what the Kit delivered over the years.

You can’t govern what you can’t see

I jumped head-first into the nascent low-code business in 2020, leaving my CRM career behind. I imagined this would have meant I’d get my hands dirty building plenty of new apps and flows. Instead, it became clear that the biggest question holding customers back from embracing Power Platform wasn’t about whether the required apps could technically be created. It was all about how all these new apps built by citizen developers and different MS partners could be governed.

Someone in our team had to focus on it, and so I became the governance guy. It must be over six years now from when I first deployed an internal version of the CoE Starter Kit. I had read about what you could do with it in theory, so now it was time to learn how to use it in practice. Let me tell you, it was a lot to chew on. Getting the basic building blocks in place took a few days — understanding how they actually worked took years.

Center of Excellence - Core solution object count: 100 (2021-02) vs. 195 (2022-05).

At around 2021-2022, the Kit was exploding with new features through new monthly releases. Just the core solutions doubled in size when looking at the number of artifacts. This was in addition to all the changes and enhancements in every monthly release. Keeping up with the CoE Starter Kit literally had to be a major part of your job, otherwise you’d have a tough time figuring out A) if the solution was working, and B) if not, where to look for troubleshooting the deployment.

In 2023, my CoE Starter Kit by the numbers slide read as follows:

• 21 apps

• 95 cloud flows

• 58 Dataverse tables

• 12 releases per year

• 286 pages worth of documentation

• 2,000+ issues on GitHub

This was both amazing and scary. Amazing as in how a tiny team at Microsoft was able to ship such an extensive set of features to plug the gaps in admin and governance tooling available in native Power Platform product features. Scary in the sense that if you did not take the time to learn how to deploy and manage CoE Starter Kit, you were pretty much flying blind. You had no way of monitoring what your app makers were building.

Okay, sure, there was the tenant-level analytics feature. A pre-packaged Power BI report embedded inside PPAC, giving you some visibility into Power Apps and Power Automate artifacts. Assuming your admin had enabled the feature. It was better than nothing, yet in practice every single governance related engagement with customers started with these questions: “Do you have the CoE Starter Kit deployed? If yes, when did you last update/check it? If not, here’s the prerequisites we need to go through before touching anything else.”

The almighty inventory API

Fast forward to Ignite 2025. The session Overview of managed solutions and secure ops in Power Platform touched on CoE at around the 12 minute marker. Ryan Jones asked the audience "How many of you have deployed the Center of Excellence Starter Kit today? … How many of you use that for inventory? … How many of you like doing that?" He then pivoted to the pitch: inventory now shows up natively in the Power Platform Admin Center (apps, agents, automations in a few clicks), and the same data is also queryable via Azure Resource Graph / KQL.

Today, when you open PPAC, you may well see a bubble saying “Welcome to Power Platform Inventory”. You will land on a list of Power Platform resources that allows searching, filtering, and some lightweight column customization. The feature set is not particularly broad, but considering how hard things used to be for the first 8 years of Power Platform, an up-to-date view of resources across environments is a major step forward.

Onboarding bubble “Welcome to Power Platform Inventory” shown in PPAC.

Getting the inventory data into the CoE Starter Kit environment was the majority of the battle the MS team maintaining it had to fight. Since no built-in API existed for easily reading the data across different artifact types, the result was an elaborate maze of sync flows that ran on a daily basis. It’s amazing how well they worked, considering the complexity — yet inevitably the inventory flows sometimes failed. As the products and APIs changed, you always had to keep an eye on the inventory data collection mechanism. And keep your CoE solutions up to date, too.

Then there was the part that made this especially challenging for larger orgs. Neither Power Automate cloud flows nor the admin connectors were designed to scale into capturing a million apps from the tenant. SMB customers could live within the practical boundaries of the CoE sync flows. Enterprise orgs had to build custom solutions to get a complete picture of their low-code assets.

There were several rounds of attempts made to address this issue. Already in May 2021, when the telemetry data export to Azure Data Lake was announced, the team created a plan to re-platform the CoE Starter Kit to use Bring Your Own Data Lake capability instead of cloud flows. Unfortunately, the product side didn’t move as quickly as expected and the experimental BYODL feature took almost two years to launch.

Better late than never, right? Not in this case. The capability with the Data Lake export never became reliable or comprehensive enough to replace the sync flows architecture. In addition to the data coverage never reaching parity, a major problem was how the planned architecture relied on Power Platform Dataflows. There never were sufficient investments in making them truly work with solutions, which was a huge issue for something like the CoE Starter Kit to ship them as part of their managed solutions. They ended up becoming just another dead feature on the platform.

I see dead features, part 2: Dataflows

Power Platform Dataflows were never deprecated, but they were never really finished either. As Fabric moves on, they are getting left behind.

Perspectives on Power Platform • Jukka Niiranen

The configuration wizard and the whole deployment and update process of the CoE Starter Kit evolved quite dramatically over the years, though. Whereas in 2020 the setup was a huge manual process (especially before connection references became a thing), a few years later there was a proper product-grade UX for configuring all the basic moving parts of the CoE solution. Canvas-based experiences were replaced with model-driven apps and custom pages, leveraging the Fluent UI controls in the Creator Kit.

How about the governance part?

So, we now have the raw inventory data natively available, via PPAC and via API. That’s a good first step in establishing basic visibility into what exists at this point in time. It’s hardly enough for operational governance of a low-code platform though. What else do we have in the product side now?

Let’s look at what Microsoft says about how core CoE Starter Kit scenarios map to PPAC features:

• Use the Inventory experience to view and govern all apps, flows, and agents created across your tenant.

• Use the Usage experience to track adoption and identify top resources and their owners.

• Use the Monitor experience to track the operational health of heavily used resources.

• Use Actions to identify risks, enforce best practices, and take action on governance insights across your tenant.

Usage data is certainly important to identify high-volume apps, flows and agents. That was always tricky with the Kit, so do we now have a way to combine that with inventory items? No, we just have a separate dashboard in PPAC, with zero filters to analyze the data. No documented API support as of now.

Monitor. Hey, that’s a topic I’ve written about before! As I couldn’t believe how unreliable the built-in feature was, I actually started monitoring the Monitor myself. Today, I’m happy to report that the daily alert emails have finally been rock solid in 2026. If you’re happy with 24h aggregates and don’t need same-day monitoring for critical processes, the PPAC features can certainly be useful

Who monitors the Power Platform Monitor?

Making sure your apps and flows are running isn't that easy. Monitor promises effortless visibility, but how well does it deliver that today?

Perspectives on Power Platform • Jukka Niiranen

Actions. I can’t be the only one who sees this list as mostly an advertisement for enabling security features that Microsoft has introduced into the platform. Many of them are of course relevant to people who are in charge of improving the security posture of business apps, automations and agents in the tenant. Technically valid topics to review, yet not exactly the only list of tasks for Power Platform governance in practice.

Is there something more coming for helping platform owners and admins address the day-to-day governance needs? At Ignite 2025, the Virtual CoE, as in “Virtual Center of Enablement”, was presented. It never was in public preview, despite the badges on the slides, and I never bothered to sign up for the private preview with NDA clauses.

Ignite 2025 announcement of the Virtual CoE and its 3 guardian agents.

In the 2026 Release Wave 1 plans, the feature has now been given the agent branding and announced as Agentic Center of Enablement (Agentic CoE). Scheduled to arrive in preview in May and GA in June, it appears to have identical contents as the Ignite 2025 slide. A set of three “guardian agents” that are supposed to answer the questions:

• What changed?

• What needs attention?

• What can you do about it?

These are of course very relevant questions, and I’m sure a modern LLM can provide very detailed and convincing summaries from the firehose of raw data that the inventory API now offers. This also explains why Microsoft hasn’t built a new dashboard experience in PPAC for summarizing the data via classic Power BI visuals. No doubt the guardians will require Managed Environments to be enabled.

What Managed Environments won’t solve

Microsoft has been building the managed platform story for a while now. It makes a lot of sense, especially now when Power Platform must be able to answer the “why not just vibe code everything” question in a credible way. Initially launched as more of a concept rather than actual software functionality, Managed Environments has become the premium umbrella covering basically every new admin and governance feature launched.

Managed Environments insights tiles in the preview Power Platform admin center version.

In the preview version of PPAC, we can see placeholder dashboard tiles on several “Insights about Managed Environments” metrics coming soon. In a way, PPAC is gradually turning into the built-in equivalent of what the CoE Starter Kit Power BI dashboards were in 2020.

Except for the customizability part. And that’s a huge thing for anyone that needs to do more than just look at the preconfigured admin experiences. Because even though the experience of managing Power Platform with tooling built on/inside Power Platform was at times a confusing inception moment, the potential with this type of architecture is very hard for any Microsoft product feature to match:

Architecture pic I made in 2023 for the “Power Platform Governance In Practice” training course.

It all comes down to what the low-code solutions built on Dataverse, Power Apps and Power Automate are great at: managing business processes. The very moment you need to go from observing the current state to mapping your journey towards the to-be state, the inevitable question is: “okay, where should we track this data and tasks?”

There’s only so much you can write in a single newsletter issue before it becomes the wrong format. Often I would have a lot more to say about the topics I cover, yet I don’t want to turn the emails into something that takes an hour for you to read through. At the same time, I want to ensure those who are supporting my work with a Plus subscription get value for their money.

Time to try something new. Hello, Perspectives Deep Dives!🚀

One hour videos not only make it easier to visualize complex topics. They also allow me to show demos of tools and experiences from Microsoft, the community, and myself. Because in the age of vibe coding, everyone can be a tool maker. Merely putting things out in a GitHub repo doesn’t mean anyone would understand the “what” and “why”, though. We often need real people to explain it to us.

The idea is not to replace written content with video, because at least I much prefer reading about this technology than watching endless tutorials about something that may or may not be relevant, from a person I may not fully trust yet. Since the Deep Dives are meant exclusively for the Plus subscribers, though — I guess that trust barrier is easier to cross.

Licensing, capacity and cost management for Power Platform

There’s already a lot of detailed licensing terms insights I share over at licensing.guide for the audience who cares about the commercial side. But when it comes to technical solution builders and architects, this won’t necessarily make it any easier to approach the topic. In fact, it may just end up causing more anxiety when you hear about the latest changes and gotchas in Microsoft product licensing.

It’s time to reframe it as something beyond SKUs and commercial contracts. Ultimately, licensing is architecture with a price tag. You should not separate it from the other design choices you make around app patterns, automation, identity, capacity, monitoring, or AI features.

That is the core idea behind this first Deep Dive. Instead of trying to memorize product names and price lists, the session looks at the workload patterns that actually determine the answer. Who is getting value from the automation? Where does Dataverse capacity start becoming the real issue? When does pay-as-you-go help, and when does it just hide the problem for later? Oh, and there are demos of my “licensing as code” concept, too!

What’s the point of low-code anymore when AI code-gen is now possible? That is the most burning question that was present in most of the discussions at the Update Days Power Platform 2026 conference in Prague this week. More specifically: how can the professional developer audience working with Power Platform tools and technologies answer that question when customers or developers outside this ecosystem ask about it?

This week’s newsletter issue is my travel report from the Czech Republic as I infiltrated the programmer crowd and tried to assume a code-first way of approaching Power Platform topics.

Everything as code

I had two sessions at UDPP26, one about licensing and the other about inventory. Traditionally, this would have meant a lot of intimate moments between me and PowerPoint. Given how I had recently explored the five ways to use Copilot in creating PowerPoint decks, I should have been well equipped to improve my efficiency with the latest AI tools from Microsoft.

I chose not to choose Copilot. I chose something else:

Slidev is what the software developer audience has been using to create presentations for some time now. Reasons for its popularity have been how slides can be created and edited as Markdown. Furthermore, since the presentation really is just a web app you run locally with a command like ‘npx slidev licensing-session.md’, you can embed HTML and all sorts of Vue components in your slides. Or even a live code editor.

As Markdown has become the universal language of LLMs, this made it very convenient to work on the presentation contents with the help of AI buddies like Codex Desktop or Claude Code CLI. Storing all my research and reference materials in a folder meant that I didn’t need to try and beg a Copilot chat to do rewrites of my PowerPoint presentation. Instead, I was able to iterate on the .md files in a near-seamless way. Obsidian was my UI for viewing and editing the files, Codex worked behind the scenes, and the browser showed what the deck is going to look like.

I didn't settle for launching my slides from VS Code. I also created a number of demos to show how API data sources related to Power Platform licensing or inventory can be used by a vibe-coder like me to create pretty nice reports and tools. I’ll need more time to unpack everything that my UDPP26 workspace consisted of since I had to run through them really fast to stick to the session schedules and it’s all a bit blurry even for me.😅 

All of this would have been impossible for me one year ago. It’s not just about the models becoming more capable in agentic coding scenarios. I’ve personally had to invest quite a lot of time in experimenting with how they can be put into use — not to mention learning the bare minimum about all the pro-dev tooling that has not been relevant for me during my first two decades in the MS BizApps ecosystem.

The vibes are getting louder

If I think about the many power users with whom I’ve had the pleasure to work with during the past few years as Power Platform went mainstream and empowered citizen developers everywhere, the setup I’m now using isn’t necessarily ready for them yet. Despite being a low-coder myself, I am not a citizen in the sense that this would be a side gig for me. For people who want to replace Excel and email based business processes with better tools, doing things from pure custom code would be quite a leap.

Yet most of them surely are already exploring ways to escape the sandbox of canvas apps and cloud flows. The very same individuals who weren’t afraid to learn Power Apps will surely look at app builder tools like Lovable, or simply prompt ChatGPT to give them code to run that solves the problems Power Platform isn’t flexible enough to solve. Not to mention those who never tried Power Apps and only discovered the joys of building apps when the era of GenAI began.

You can’t stop the vibes. Just like low-code development became an official thing, generating new tools by prompting a large language model is what a growing number of people have experimented with. They’ve seen results from it that were previously in the category of “someone else has to build this”. Now they are building it themselves, and that’s where bottom-up movements like citizen development get their juice from.

UDPP26 panel discussion - future of low code vs vibe coding

Scott Durow took the lead in a panel discussion about the future of low code vs vibe coding where I joined Diana Birkelbach and Rami Mounla to talk about what’s actually happening out there. I was the only panelist without any formal education or experience on classic software development, which of course fits my natural tendency to challenge the existing norms and be vocal while doing so.😁😁

The power users of business technology must have often felt like an underdog, in comparison to those who worked on building the tools for the users. They knew roughly what should be done, yet there was a barrier of projects, funding, specification and all the drudgery that stood between their idea and the outcome. Often the end result from all the hard work didn’t live up to the original vision since a lot was lost in translation and scoped out as not fitting the budget or schedule.

DIY business tech no longer means sticking to Excel monstrosities or buying shadow IT SaaS apps with a credit card. On the surface, real software is becoming indistinguishable from vibe software. It will not only place mounting pressure on the solutions that are constructed by software development professionals through formal project work. It also leads to a mountain of disposable apps that has been built either to validate an idea or to address a one-off need.

The way I see it, and the way I expressed this in the panel was: most apps should NOT BE BUILT to begin with. We are already lacking proper conceptual separation between an app that is built as mobile forms over a SharePoint list or a full line-of-business CRM system. Calling them all “apps” is just plain stupid, yet somehow we’re stuck in the word presented in Apple’s commercial from 17 years ago that positioned “there’s an app for that” as a good thing. Shouldn’t this already be like “you’ve got mail” by now — as in a problem that needs a junk filter? Will AI-generated throwaway apps become the 2020 equivalent of spam pretty soon?

Amazing and scary

Every presenter and attendee that I had the pleasure of talking with at UDPP26 was fully aware of what risks there are with going all-in on AI-generated code and letting the LLMs run on autopilot. Professional software developers seem to not be under the illusion that just because Claude Code can work with code, it would be smart to just let it do all the work.

No one dares to say you should not use AI for anything code related, though. Because of the recent advancement in frontier model capabilities and the AI coding agent harnesses, many devs are coming to terms with the fact that LLMs are now better at many things they used to do by hand. The focus has therefore shifted to what kind of an environment and tooling is needed for making coding agents scalable and sustainable in the context of business applications development.

Every demo in tech conference sessions is now supercharged by the computer doing things on its own, based on guidance from its human master. This is what allows folks like me to not just talk about available APIs in theory but rather show how they are turned into tools and reports with a few simple prompts. It is the area in which using AI coding agents is relatively safe, too. Working in sandbox tenants, using demo data, running on throwaway cloud infrastructure. There’s no excuse anymore to not show real code in operation.

The risks are also greater than ever if we forget the simple fact that for LLMs, every payload is the same. There’s no separation between instructions and data, no matter how much the vendors build different kinds of shields and layers to hide this. AI coding agents go through massive amounts of text, code and data in the blink of an eye. When malware today is simply plain text that convinces the model to do something the user would not want it to, it can be found anywhere. It may already be in your inbox, or public websites, and you’ll only discover it when the agent ends up reading it.

Raphael Pothin: “Mitigating AI risks from injection, exfiltration and unsafe actions”

Gullibility of LLMs is what makes prompt injections a serious threat. Yet another feature of modern GenAI that may be seen as positive, their persistence to solve problems, can turn into problems for especially software developers. The latest models are incredibly creative in searching for ways around locked doors, such as missing tools or authorization to perform the action driven by the original prompt and the thinking steps that AI put together in its planning phase. Where there’s a will, there’s a way. Unsupervised agents will attempt to escape their sandboxes, modify their own settings, snoop around for available keys, and in the lack of a specific tool build their own version of it on the spot — just to reach the goal they were given, or what they interpreted to be the implied goal.

The dev community, both in Power Platform and in general, is today at a point where there are very few proven patterns and practices available for safe and reliable agentic AI usage. This means there’s a huge demand for guidance and experiences that can be shared within the community, and events like UDPP26 are very much needed to provide a platform for critical thinking and real-life examples to offset the breathless AI hype in this industry.

So: “why low-code”?

As the act of building new apps from code becomes the easy part, the value of managed platforms needs to be found from other phases of the application lifecycle. Meaning, what happens around the app that has been generated with your AI tool of choice. Ultimately, that is where the right answer to the “why Power Platform” question has been found already before. People didn’t choose canvas apps and cloud flows because of their superior experience and flexibility in building new things. They always had other reasons.

I’ve been saying how all new software products, be it from Microsoft or others, always start with the “Create New” path. Sometimes they never even mature up to a point where the “Add To Existing” user story is completed. That means they’ve failed to reach a level where meaningful, lasting business value is realized. Because building net-new things with no legacy and no dependencies is always the fun part. The hard part is in fitting these new creations with everything that already exists. Or better yet: building up the missing capabilities that are needed before the technology can be taken into production use.

Jakub Bajla: “Why auditors trust Power Platform more than custom code”

With the Power Platform, it’s all there already. The technology stack that has evolved from the early on-prem XRM days twenty years ago into the MS cloud services we see today when opening different portals is what makes the apps business ready. For any organization that needs to pass IT audits, for example, the answers are already in the platform. Not as something automatically applied and implemented without any customer effort, but rather as enterprise-grade tools that can address all the typical questions an auditor might have.

I started working on Power Platform governance topics on a daily basis six years ago. Back in 2020, there were plenty of gaps in the story that didn’t have an easy answer, let alone documented best practices. It all had to be built — and it was. The experience of how you work in the Power Apps canvas studio hasn’t radically changed since then, whereas the tooling and features for how you deploy, manage and secure the solutions has gone through a radical transformation. It has earned the trust of IT decision makers and professionals on the customer side, as well as an ecosystem of partners and the community of makers.

All of this doesn’t just magically become irrelevant the moment a chatbot learns to output the source code for a nice looking React app. Code on its own is just a liability, unless you have the processes, platforms and tools to make it operate safely and reliably in the context of an organization that the solution is designed for. Frontier labs like OpenAI and Anthropic will surely claim to have all sorts of programs and models for making their products ready for business use. We all know by now how easy it is to vibe-code a product concept and a fancy looking website, though. Talk is cheap, real governance capabilities ain’t. Especially when the majority of the value in Power Platform today comes not from software features but from how the people working with it have established processes and accumulated competence around it.

AI will force the low-code community and platform vendors to change their ways of working, of course. Not everything that we used to build makes sense anymore, and a lot of what is needed for AI coding agents to be productive with Power Platform is still either missing or WIP. The choices that Microsoft will make when trying to navigate between tech opportunities, customer demands and market pressure will undoubtedly result in a growing list of dead features that are technically not deprecated but in practice no longer developed (ever).

Power Fx as a liability

The low-code programming language Microsoft built to resemble Excel is becoming a blocker for AI agents to get their work done properly.

Perspectives on Power Platform • Jukka Niiranen

What surprised me the most after spending three days at UDPP26 was how I did not experience AI fatigue at all. Despite the tech being present in nearly every discussion, there was no one forcing an AI product on you. Even from the Microsoft representatives at the conference, you wouldn’t hear anyone push Copilot for the sake of Copilot. It was almost as if AI was becoming closer to just normal technology that exists in our lives, impacting what and how we do with our computers, yet not being a goal in itself. It made me increasingly optimistic about our industry moving beyond the hype phase and towards a more pragmatic discussion on what works, what doesn’t, and how to move forward together with AI without abandoning all that came before it.

I keep an eye on the deprecations pages on Microsoft Learn, using this wonderful tool from Ty Corcoran. A few days ago, it sent a notification about a new entry in the Important changes (deprecations) coming in Power Platform list that I found especially interesting:

Deprecation of Test Engine - new entry on Microsoft Learn page for Power Platform

I had not used the Test Engine feature at all, given how my roles have usually been further away from the programmatic testing of applications. Yet the wording on that note is something that made me pause: “Test Engine has near-zero usage”. Wow! You rarely see honesty like that in official MS Lean pages. But it gets better:

The replacement for Power Apps Test Engine is a set of Power Platform Playwright Samples in a GitHub repo. There’s a comparison table that shows the reasoning for why this is a superior approach compared to the Test Engine that has been around earlier:

Power Platform Playwright Samples comparison with Power Apps Test Engine

AI authoring is the main story here. And how the Power Fx YAML language used by Test Engine is flagged as “not supported”. That ultimately is the big threat to everything built in the past decade to enable citizen-dev friendly app development with Power Apps canvas apps.

The original promise of Power Fx

Before it (probably) gets deleted, I managed to take a screenshot of the Test Engine project’s GitHub Pages website. Specifically the page “Why Not Just Use Code First Testing Tools”.

It’s time for the sequel to my May 2024 newsletter issue where I described how Microsoft’s products contain features that are effectively dead. They are not formally deprecated, yet any customer would be wise to not accidentally touch these things. Because getting bitten by a zombie feature may turn your business application into a system that starts infecting the systems around it.

I see dead features

Why your business software contains features better left untouched

Perspectives on Power Platform • Jukka Niiranen

These days, it’s very fashionable to write “X is dead!” type of posts on social media. Nowhere is this more pronounced than in the field of AI frontier labs, with Anthropic’s and OpenAI’s announcements on new capabilities instantly tanking the stock value of incumbents in software or professional services.

These new features from AI companies, or companies aspiring to become one, are more like fairies. Whereas zombies have once been real, living people, many of the products built on top of large language models are creatures that have never been part of our world. You have to stretch your imagination and share the vision of AI CEOs for you to be able to see these fairies and the magical powers they possess.

Why Microsoft is the king of dead features

A few days ago, I watched a fun rant from ThePrimeagen (Michael Paulson) about "The Copilot Problem". In the video, he showed how Gemini agreed with him that Microsoft has the worst product naming conventions in tech. Yeah, can't blame Gemini. But what do LLM chatbots in general think about this? I decided to find out, by performing a highly scientific experiment of giving the same prompt to six AI chats from different vendors. Below are the results:

What 6 different AI chatbots chose as the company with word product naming in tech.

Every single one agreed on the top names. It's either Microsoft or Google. Only Copilot and Claude voted for Google as the worst offender. ChatGPT, Gemini, Deepseek, Meta AI all said “c’mon, you know it’s Microsoft, right?😉”. In this case, it’s easy for me to agree with the wisdom of the language model. 4 vs. 2 plus my personal opinion make this a clear victory for Microsoft.

When showing the results to Claude, it had a great insight about the results. The strategies of Microsoft and Google in how they handle failure are very different: Google kills their products and launches new ones. Microsoft "reimagines" the products and keeps the same name around. Instead of the harsh yet determined approach demonstrated by the growing list on Killed by Google, Microsoft tries to distort reality by changing the meaning of a brand or feature name.

Not only does this make the product offering cryptic and confusing. It also encourages the pattern where features and services are launched but never properly shut down. This means that the many lists of deprecated features are merely the tip of the iceberg. Many more services are stuck in a permanent holding pattern where Microsoft will deliver zero improvements or new capabilities. They remain technically available yet customers should actively be looking for an alternative way to build their systems to avoid any dependencies.

Because why would you want to rely on some technology that has been developed 20 years ago and not improved since? This would be particularly insane in the world of cloud services where customers are paying a monthly fee for the access to an “evergreen platform”. The key reason you’d commit to a contract and pay continuously for the software instead of doing a one-off development project and building bespoke software is because the SaaS vendor should keep continuously investing in it. Once evidence shows that is not happening anymore, it’s time to re-evaluate what tools you’re using.

Power Platform Dataflows: the CDM relic

Whereas the Common Data Model itself turned out to be a nothingburger with little substance beyond the Ignite 2018 keynote slides, this era did deliver some tangible tools to work with data in the low-code platform of Microsoft. As long as you ignored the lack of anything “Common” that would unite SaaS tools across Microsoft, SAP and Adobe (as promised by the CEOs on stage). Dataflows are one real service from that era.

Common data model: easier said than done

Microsoft and other enterprise software giants have tried & failed to gain adoption for their open data models.

Perspectives on Power Platform • Jukka Niiranen

Dataflows are a great example of the product naming practices of Microsoft, given how there are two different products called by that name. There are Standard Dataflows that load data into a Dataverse table, and nothing more. Then, there’s the Analytical Dataflows for getting data into a format that Power BI or other analytics tools in the MS stack can work with it. People would commonly refer to these as Power Platform Dataflows and Power BI Dataflows. The latter are probably used 50x more often in the real world.

That is why the recent announcement on the Power BI product team blog caused some turmoil. The title was: “Dataflows: Thank you for eight years of Gen1—and why Gen2 is the future”. To understand the real impact, however, we need to look beyond the product marketing language and explore the dependencies between different services.

Microsoft Power BI team blog post waving goodbye to Power BI Dataflows (Gen1)

I don’t spend too much time on the MS data platform side in my daily work. But whenever I do, I try to focus on reading real-life experiences from users and consultants. In this case, the Reddit thread about this Dataflows Gen1 legacy status reveals the overall sentiment very quickly. With 200+ comments, most people seem to agree that Microsoft is pushing smaller customers into paying for Fabric capacity and dealing with more complex technology with seemingly little to no practical benefits.

This is perfectly in line with what has been going on for a while now. As the market for self-service BI in the original Power BI fashion now seems to be saturated (and Microsoft won that round), the growth must come from selling new, bigger things. I wrote about how the SMB customers of Power BI are getting left behind by Microsoft’s Fabric push in an earlier issue:

A twist in the Fabric

The push for Microsoft Fabric with its enterprise data platform capabilities is leaving SMB audience of Power BI behind - as well as dreams of closer Power Apps integration.

Perspectives on Power Platform • Jukka Niiranen

Now, why did I declare “R.I.P. Power Platform Dataflows” in my social post shown above? Did I not read the blog post in detail, to see that it references Power BI Dataflows? I did indeed, but in this business you won’t survive as a solution architect unless you learn to read between the lines of what Microsoft says.

The back story is that the Power Platform Dataflows were effectively abandoned years ago. They have been a dead feature for quite some time. Now, with their parent product, Power BI Dataflows, being officially placed into Legacy status and stamped with “no new features — ever”, it’s time to stop pretending otherwise. If Microsoft isn’t providing even Power BI users new functionalities unless they sign up for additional Fabric capacity in addition to their existing PBI licenses, why on earth would anything new land on the Dataverse side either?

The state of Dataflows in Power Platform

A couple of community members asked me if I wasn’t aware that Power Platform Dataflows had already been migrated to V2. I am very much aware, and I also understand how every single character in Microsoft’s materials can carry a specific meaning. In this case, the Dataflows Gen1 and Gen2 have nothing to do with this Standard Dataflows V1 to V2 migration that took place earlier.

V2 Dataflows were introduced around 2021 — two years before Microsoft Fabric was announced. The last meaningful improvements to Power Platform Dataflows must have been at around 2022. Which would be cool if the product itself was already mature enough. But it’s not cool, because Dataflows are nowhere near “enterprise ready”. Here’s a rant I posted on LinkedIn about Dataflows in May 2022:

And that was just the governance part. Development is equally horrendous since the ALM story for Dataflows is unlike most other solution components today. Taking a look at the known limitations of Dataflows in solutions, we learn that:

• Connection references aren’t supported.

• Environment variables aren’t supported.

• Component dependencies aren’t identified in solutions.

• Application users (service principals) cannot deploy Dataflows.

• Incremental refresh configuration isn’t supported when deploying solutions.

• Linked tables between Dataflows aren’t supported.

• Blocking unmanaged customizations isn’t supported.

The list makes it pretty clear that none of the platform side investments from past five years have been implemented for Dataflows. Because obviously this technology has never been a part of the actual low-code platform we call Power Platform. It’s from “the other side”, meaning the data platform folks. When James Phillips, the guy who launched Power BI in a big way, was still leading the BizApps unit at Microsoft, there must have been enough alignment to keep the data and app product teams talking to one another. As he left in April 2022 and went to Google, there was nothing keeping the different teams aligned.

Which gets us back to the product management strategy. If Dataflows were Google technology, we would have seen three separate products launched and killed by now. But they are Microsoft technology, which means we keep having Dataflows in the discussion — even if the underlying stack has changed and one thing called Dataflow is not compatible with another thing called Dataflow. Just another Tuesday in Redmond.

Built for builders. Not buzzwords. San José 2026

500+ speakers. 18 content tracks. Workshops, masterclasses, and the people actually shipping the tools you use every day. WeAreDevelopers World Congress — September 23–25. Use code GITPUSH26 for 10% off.

Secure Your Pass

Life after death

You might be rightfully asking “so what” at this point. While it ain’t fun that the service you’re using doesn’t have a roadmap, in everyday life we have to choose our battles. If you already have a bunch of Dataflows pumping data into your Dataverse environments, is it necessary to start planning an alternative right away?

Let’s make this clear: Microsoft is not saying they will take Power Platform Dataflows away. If anything, they’re pretty solid at keeping the lights on when it comes to services that business users rely on. Some may choose Microsoft precisely because they’ve been burned by sudden shutdown announcements from the likes of Google, let alone smaller SaaS players out there. It’s the same reason as why you may choose a Toyota over a BMW: there’s less surprises ahead and the TCO is likely to be much better with Microsoft — even if you may not experience the same thrill while driving down the highway.

Here’s what the product team had to say in the comments for the “Gen1 bye-bye” post:

If you were thinkin about exploring the Dataflow Gen 2 in Fabric as an option for Dataverse imports, you can stop pursuing that idea any further. It’s a different world and a different organization today, compared to 2019 when this slide of the original Power Platform Dataflows was presented:

Intro slide to Power Platform Dataflows from a 2019 bootcamp presentation.

Being a low-code developer by heart, I actually was excited back then about what an automatable data import mechanism built right into the platform could deliver. For the citizen developer audience that couldn’t realistically get the necessary pro-dev resources for a “real” integration between business systems, Dataflows were a very attractive alternative. Mainly because you could build and operate it inside the Power Apps maker portal, with no Azure services and access needed.

Switching on my low-code governance evangelist hat, there were plenty of reason for concern about how Dataflows might be used. The LinkedIn post quoted above highlights what could go wrong. I’ve seen exactly these things go wrong since then in live
customer tenants. Dataflows getting left outside planned tenant migration inventory due to lack of any API support for cataloging them. Runaway Dataflows filling up the entire tenant Dataverse capacity with a surprise 200 GB database storage consumption - requiring ~2 weeks to even remove with regular bulk delete. And so on.

When you can’t monitor Dataflows, you’ll only find out their outcomes from tenant capacity in PPAC.

In 2026, the most pressing question that every tool like this should be able to answer is: why wouldn’t the customer just vibe code it with AI instead? For the sweet spot of where Power Platform Dataflows have been used, i.e. situations where “proper” tools haven’t been available, this is an existential question.

Clunky GUIs for mapping table columns, doing basic field type transformations, and then repeating actions across dev-test-prod via the GUI whenever changes are made — that’s not how teams will want to work in 2026. If there was proper support for programmatic creation and manipulation of Dataflow artifacts via tools like PAC CLI, it might be fine to keep using them in existing solutions. But there isn’t. It has been an awful experience whenever I’ve tried to get GitHub Copilot to help maintain or extend existing Dataflows. Much worse than Power Automate cloud flows, which at least play well with the fundamental platform concepts and can be managed via AI coding agents.

Thinking about a typical scenario where I’ve seen Power Platform Dataflows used, it would be a piece of cake for something like Claude Code to look at the existing configuration, and then rebuild it in Python, for example. Assuming that LLMs won’t go away, these custom code solutions would likely be easier to maintain than something built on
Microsoft’s dead features that represent proprietary config files and hard limits on cloud service access.

The only real question is: “Where do we run this Python script in production?” Your friendly AI chatbot will suggest plenty of options when prompted. Now, it is of course a bit problematic if everyone’s chatbot gives a different answer to this question and the code + data ends up going through various clouds the IT has no information about. Oh if only there was some common low-code platform available to these tech-savvy business users to build their apps…

And that’s really the core issue here. Power Platform pretends to be exactly that solution for addressing shadow IT concerns, yet in the case of Dataflows it fails to deliver. Only the maker-facing tooling was ever built. None of the admin capabilities or ALM support was ever delivered. If Microsoft had properly invested in making Dataflows work like native solution components, it could have stood on top of all the security, governance and development layers that Microsoft’s other teams have created to make Power Platform a solid foundation for business apps and automations. Dataflows Gen1 could have kept serving most customer needs for Dataverse imports just fine for years.

But it didn’t happen — and now it never will. Another dead feature bites the dust.

Three years ago, when Microsoft first announced they were bringing M365 Copilot into the world, the amazing demo video promised us it would do decks like this:

March 2023: Microsoft promo video for what M365 Copilot was supposed to do with Office apps.

Today, it’s easy to say “yeah, riiiiight…” when watching an animation like it. But back in 2023, only four months after ChatGPT launch — who knew what AI was going to be like? No one did. We only had the word from the tech companies on what they were building and promising us.

Today we know better. As do the engineering teams behind every tech company that has tried to make LLMs do the kind of magic as their promo videos suggest. We have gained (and lost) some pretty neat AI video generation tools for building such promo animations from simple prompts. But what have we really gotten when it comes to actual, non-hallucinated information worker tools?

One thing’s for sure: we have gotten an endless stream of preview features and changes to how the Copilot tools should work. It’s nearly impossible to follow the real story, even when narrowing it down to something like Power Platform. I’ve tried my best on that front and reported back what I’ve learned in the weekly newsletter you see here.

This time, though, I’m touching something outside Power Platform. It’s kind of the honorary member, though. If Microsoft hadn’t launched PowerPoint, would any of the other Power tool brands have come to life? Probably not. And it’s not just about the brand but also the pattern for empowering information workers. When I saw Power Apps canvas apps for the first time, I thought to myself: “this is what all PowerPoint decks should be like in the future: interactive apps, not static documents”.

Just like there are many ways to build an app in Power Platform, there are a lot of options for how to create a presentation with the help of Copilot. Let’s start with the question: how many ways exactly?

There are five (5) ways to create PowerPoint decks with Copilot

I don’t know if that’s the right answer. No one does. And regardless, tomorrow there might be seven ways in total. But this week, when I looked at the options, that’s how many methods I discovered. And I decided to document the details for others to benefit from. You can find them on this page:

Five Ways to Make a PowerPoint with Copilot: a summary page of my findings.

I took a test drive on all of them, using the same source data and prompt. Not only did I look at the UI, process and outputs myself — I also uploaded the .pptx files into Claude. Since they are basically a .zip file and follow the documented OOXML file format, an LLM should be able to analyze them like any other code artifact. And it sure seems like it was.

Here’s the main discovery: no AI tool in Microsoft’s cloud today can create a proper PowerPoint document that is A) formatted right and B) looks good. You have to compromise — a lot. You also need to be ready for disappointments because there’s no intuitive way for the user to know what each Copilot experience will actually do. In the words of Forrest Gump: “it’s a box of chocolates”.

The other key point is that this isn’t going to magically get better. We’ve waited for three years now and the experience still sucks, just in novel ways. While you can get outputs that on the surface look ready to present, the crucial thing to understand is that these are more like pictures than proper .pptx files. You don’t have the structure nor editability that a native PowerPoint document should offer.

Now it’s time to look at each of the methods I was able to test for creating a PowerPoint presentation with the help of Microsoft AI in March 2026.

Method 1: Create with Copilot

This is the O.G. version in the sense that it’s been around the longest and also uses the least modern experience in Copilot. You can access it when opening the PowerPoint client and going to create a new presentation. It’s the first option, even before “start with a blank presentation”, so you cannot miss it. You give a prompt + reference docs (from the file types MS decides to support), pick from available themes, choose your preference of AI-generated images. And then you sit back and wait for a while.

The output is “okay”. The theme determines what the general style is going to be and it’s consistent. There are images, sure, but they are bland GenAI clipart that is more about decoration and less about helping to visualize the specific concepts of your presentation. The slide layouts aren’t very exciting, which of course is also common in human-authored decks.

The worst part here is that the presentation goes on and on and on. Out of all the five ways, this method to create a PowerPoint document with Copilot does not offer any control for presentation length. So, we get 32 slides about something that definitely isn’t worth all that space. Microsoft was supposed to introduce a setting that allows the user to adjust the output length but I only ever saw it in screenshots shared by MVPs, so I guess it got scrapped. Giving the length verbally hasn’t worked either, at least when I’ve tested it earlier.

Method 2: Copilot Chat in PowerPoint desktop

There’s been a lot of fuss about full Microsoft 365 Copilot Chat becoming available inside every app — from Dynamics 365 to Power Apps to Office apps. Based on this, it’s perfectly reasonable for the user to expect that they could start the slide deck creation from within the chat pane now. And sure, they can — it’s just that the results are going to be pretty wild:

Asking PowerPoint for Windows to create a presentation results in the most MVP deck ever.

This is literally the Most Minimum Viable Product for generating slides. There’s absolutely nothing here that’s about PowerPoint. We just get a text document that’s presented as a few bullets per slide. And the text is terrible, too. Did we travel back to pre-ChatGPT days all of a sudden? Where did Microsoft pull this GPT-1 model from?

From the thinking traces in the chat, we see that Copilot just decided to execute python-pptx code directly. It skipped everything about design and just vomited the raw text inside the OOXML markup without worrying about anything else. Now, if the bullets would have at least decent substance in them, it would have been relatively easy for the user to start applying themes, adjusting layouts, and making it their own. But when people see this kind of output, no one’s gonna bother with the AI assistant anymore.

It’s wild how Microsoft will let this happen inside their products. A user paying $30/month for the premium M365 Copilot can all of a sudden just get the equivalent of a Notepad text file when they expected something closer to a polished Word document.

Method 3: Edit with Copilot

What used to be “Agent Mode” got rebranded as “Edit with Copilot” recently, because that’s what MS does. And based on a social post I saw a few days ago, they intend to just keep on reimagining this feature:

MVP Petri Jämsen is the guy you want to follow for latest Copilot news, like this one.

Whatever it’s called by the time you read it, this is presumably what Method 2 should be like. But since I made the rookie mistake of using PowerPoint on my Windows 11 instead of the PowerPoint web client in my browser, I didn’t get these capabilities. Silly me, expecting Microsoft’s PC software to offer a premium experience compared to whatever runs in my Google Chrome browser.

Using PowerPoint Online’s Copilot Chat offers a proper presentation creation experience.

When that tiny PowerPoint icon is present in the tools area of Copilot Chat, the AI assistant engages in a targeted dialog with me about the presentation I want to build. I get to choose a template (these are entirely different from Method 1, btw) as well as select options for the purpose, audience and length of the presentation. Now, this is a smart, simple way to present things in the Copilot sidecar and I want to tell Microsoft “good job!”👍

Copilot Chat is capable of creating nice decks when you’ve got the right things enabled.

The presentation produced by ‘Edit with Copilot’ is massively better than the output from ‘Create with Copilot.’ Of course. It makes perfect sense that to create something good, you should choose the edit tools…

The theming is not something you could just change from the Design tab of your PowerPoint client app, though. Well, you can, but it’s gonna be a mess. It’s obvious that this method uses PowerPoint Online tooling that doesn’t have an offline counterpart today. We also don’t get SmartArt or other rich artifacts that regular PowerPoint users would be familiar with. The output is therefore an AI artifact that isn’t intended to be modified by hand. Rather, the idea must be that I’d just keep chatting with Copilot if I want things changed. So, a bit like “PowerPoint without the Power part”.

Method 4: PowerPoint Agent

It’s still all about AI agents in the tech industry of 2026, the definition just keeps changing all the time. Anyway, this could be considered the flagship experience that Microsoft product team is most proud of. At least if you read the blog post Introducing Word, Excel, and PowerPoint Agents in Microsoft 365 Copilot from November 2025. This is the experience they talk about:

Arguably it is the closest thing to that animated demo video from three years ago in terms of how the agent presents itself and what the output looks like. It’s almost as if MS had showed their old marketing video to a frontier model in GitHub Copilot and said “build this, but make it real software code”.

This gets us to the heart of the dilemma that Microsoft’s Office teams have faced: large language models like GPT have been trained with vast troves of content presentation technologies that have been accessible to them in the web. They are brilliant at generating HTML, as a result. At the same time, they are still very clumsy with Office Open XML. Because despite OOXML being “an open standard”, in reality it’s more about packaging the legacy of MS Office docs into zipped XML files and telling the world anyone can use it.

With not enough public training data to make the agents fluent in OOXML, and no in-house frontier model to challenge the partner labs like OpenAI and Anthropic, Microsoft is stuck. This has led the Redmond developers to choose the same path as everyone else. Their flagship AI agent needs to use HTML first, then convert that into PowerPoint files. And it’s not even hidden at all because we see the agent thinking out loud about these steps:

PowerPoint Agent creating a presentation from Copilot Notebook contents.

The decks from this process do look modern. And can you guess why that is? Yes! Because these files are not real PowerPoint presentations. They are simply HTML and CSS that has been rendered in a way that looks like a slide deck. Microsoft does an after-the-fact conversion of this content into OOXML files. It’s public information, documented in their blog post.

What is not said out loud is which app features are being given up in exchange for this shiny surface. The resulting PowerPoint file does not use themes, colors, slide layouts, placeholders, SmartArt, speaker notes… While the content you see on the screen is technically included in the file, that same applies to even PDF documents. It’s easy to get things stored in a file and presented to those who open it. But the whole point of PowerPoint is in how the presenter can work with the content.

I would totally approve this kind of “flat” output that skips the native PowerPoint application functionality if the deck was generated by a company not called “Microsoft”. It’s particularly puzzling, given the phrases that are used in the blog post section “Key Differentiators of Our Approach”:

At least when it comes to presentations, this doesn’t seem to be the reality when looking at the results from this process. This first part surely is true: “Instead of generating Office files directly, the agent produces an intermediate representation that is later transformed into fully compatible Office documents.” As for the claims of how the use of a headless version of PowerPoint in the cloud somehow results in a superior result in document quality — sorry, but this doesn’t seem to be true at all.

One way to validate it is to try out a version of a process that has not been built by Microsoft, but rather Anthropic.

Method 5: Copilot Cowork

This is the hottest part of Microsoft 365 Copilot today, largely because it promises to make Copilot work the way Claude already does. Whereas on the consumer side of Copilot, Microsoft appears to be building their own solution with Copilot Tasks (behind a waitlist currently), on the business side they’ve decided to license the Claude Cowork technology from Anthropic and put a M365 badge on it.

Actually, they do a bit more with it than that. I’m cautiously optimistic about what Copilot Cowork could deliver, and especially the synergies in this partnership. Anthropic could keep doing the experimental stuff with their AI lab vibes, while Microsoft could host it inside their cloud and try to make it credible enough for the enterprise (the Azure OpenAI services playbook). See my Cowork vs. Cowork comparison page for more details, and my LinkedIn post for quick thoughts on it.

Side-by-side comparison of Claude Cowork and Copilot Cowork features, based on online docs.

Now, back to the main agenda. How does Copilot Cowork build PowerPoint decks? In a similar but technically different way than PowerPoint Agent in Copilot. The process is more explicit about the steps and hides less about what’s going on during the slide creation. We see again that the presentation is first generated in an intermediate format, then converted into a PowerPoint document.

Copilot Cowork doing lots of revision rounds per each slide, using concurrent subagents.

The file details reveal to us that this process uses PptxGenJS. “The most popular powerpoint+js library on npm with 3,500 stars on GitHub”. An open source library created by Brent Ely, compatible with PowerPoint, Keynote, LibreOffice, and other OOXML apps. There’s definitely no “headless PowerPoint” involved in how Copilot Cowork builds its presentations.

How does the resulting presentation compare to the PowerPoint Agent? It’s not that different. Neither one uses layouts, placeholders, themes, styles, SmartArt. There’s no image generation available in Copilot Cowork, because Claude famously does not bother on such tech. Microsoft haven’t yet had the chance to incorporate any GPT-image models into the mix to bridge this gap. If there were any such artifacts available in the pipeline, PptxGenJS sure could incorporate into the slides, as we can see on its interactive feature demos page.

As a conclusion, out of the five methods to generate PowerPoint presentations with Microsoft’s Copilot products, none can deliver both A) good looks and B) proper structure. The below quadrant was how Claude Sonnet 4.6 graded each option, based on analysis of the raw .pptx files produced from them. See the details on this separate page.

Design quality vs. structural integrity in Copilot-generated PowerPoint decks as of March 2026.

I’m amazed at how a community library on GitHub with platform-agnostic tooling is basically on par with what Microsoft’s own Office team are able to ship today. At least if we look at the top half of the quadrant and aim for a nicely designed slide deck as an output. Rather than a PowerPoint document that is easy to manually edit inside the client app, which is something mostly relevant for the company that sells the PowerPoint software.

Editing PowerPoint slides through Copilot chat

If everything should really be done via the “UI for AI” through chatting with an agent, does editing the PowerPoint deck through the native Office tools even matter anymore? I believe it does, especially based on the absolutely infuriating experience I had in my tests with PowerPoint Agent. If generating new decks can be rough, trying to get Copilot to change the output from it is a whole new level of pain.

Five weeks ago, I wrote about the impact OpenClaw was having on the expectations people have about AI agent capabilities. In addition to the Clawpilot newsletter issue, I also assembled an article titled “OpenClaw, open the front door”, using Claude as my co-author for it.

Clawpilot: no UI for AI

What if we didn't have to open Copilot and just hope we prompted it the right way? The rise of OpenClaw has shifted expectations on what AI agents can do when given the (scary) permissions.

Perspectives on Power Platform • Jukka Niiranen

In this industry, information from five weeks ago sometimes feels like ancient history already. In this week’s Perspectives newsletter issue for the Plus subscribers exclusively, I’ll do a Round 2 on recent events around OpenClaw that address the rising tension in what Microsoft claims to do vs. what decisions they are making in practice.

Microsoft’s C-level pitch is all about security

At an event hosted by Morgan Stanley, Satya Nadella appeared on stage and talked about “The Transformative Role of AI”. The session title sounds quite meaningless and dull, yet there are often plenty of great insights shared by Satya whenever he gets to talk about not launching an exciting new Microsoft product but rather sharing his… well, perspectives. It’s a term I cannot copyright for myself exclusively, even though I wish a certain community account would acknowledge who’s the O.G. when it comes to Perspectives on Power Platform.

In any case, what Satya had to share with the audience of an investor conference included his take on the permissions Microsoft has from their customer base, especially in the IT departments. He said Microsoft wants to “love them” because the IT audience cares about security, compliance, and observability. Things that, according to Microsoft’s CEO, the company also deeply cares about.

This led to Satya willingly raise up OpenClaw as a technology that Microsoft could not launch, because of the aforementioned reasons. The most quote-worthy part is how he compared that scenario to Microsoft launching a virus:

For those who have been in this ecosystem before Satya’s term as the CEO, you might recall another famous quote from the previous Microsoft CEO that compared a non-MS technology to a disease:

In the first year after Satya replaced Steve, he addressed this tension with a slide that said “Microsoft ❤️ Linux”. Obviously the tides had turned from the early 2000s and open source became a strategy that Microsoft intentionally adopted and embraced where it was seen fit. Some will of course have doubts about this being a part of the “Embrace, Extend, and Extinguish" (EEE) strategy the company was found to have used internally in the 90s…

Back in November 2024, I launched my first actual GitHub project. Coming from a low-code background, getting the Release Plans Visualized site published as a static Hugo site to host my embedded Power BI report was quite an exploration. I asked AI for questions on what and how to do, then clicked around and copy-pasted things. The result was not bad at all:

A better way to view Release Planner data

Visualizing Microsoft Power Platform and Dynamics 365 release plan items with Power BI. Now available on the public web.

www.perspectives.plus/p/release-planner-visualized

Now it’s 2026. The same content management gaps that were bothering me with Microsoft’s official release plans docs and website are still with us. There have been no visible changes in that infrastructure. Things have kept working — until the 2026 Release Wave 1 items were published and the Release Plans API broke down.

The releaseplans.net website I built earlier was basically just a Power BI report hosted in my M365 tenant. It had a daily data refresh that called an HTTP endpoint for a bunch of JSON data, then transformed that into visuals, and presented it to the whole world via the embed on the Hugo site. On March 19, the report refresh failed with “DataFormat.Error: We found an invalid escape sequence in the JSON input.” Someone had entered unescaped characters into one release plan item description and the updates stopped as a result.

“Hello, is anyone here from Power Automate team? Can you please edit your release plan strings?”

After shouting about this on the public square of LinkedIn, the feed was actually fixed after a few days of downtime. Yay! In the age of AI coding agents, though, it only takes a few days to build an alternative solution. Since I didn’t feel like manipulating the old Power BI report to be more resilient against data format errors, I instead spent some tokens on building the next generation solution.

🎉 Introducing Release Plans Browser 🎉

The feature that I ended up using on my own site the most was not the reporting and visuals. It was all about search. I wanted to find things and then see when those things had been updated. Everything else was secondary.

Now, I have the UI I always wanted. And you can have it, too: https://releaseplans.net/

Welcome to the brand new Release Plans Browser website at releaseplans.net !

It uses the same data as the old site. It all comes from the simple Release Plans API that someone at Microsoft was kind enough to build and launch in July 2023. Mentioned in the (last ever?) “Latest Improvements v1.1” deck for the Release Planner website, the API URL offers Dynamics 365 and Power Platform release data in a ready-to-consume format.

I happened to have a bunch of expiring Azure partner credits that I need to spend somehow, plus access to the Foundry API for Azure OpenAI services. Launching my Codex CLI and pointing it to a couple of repos plus some data and .md notes was how most of the new site was built. I intentionally chose the insanely heavy GPT 5.4 Pro model to test whether throwing extra capacity at a task like this would make a difference.

If you’re gonna burn some tokens, might as well choose the most expensive API out there.😅

The outcome was pretty sweet. It also took literally ages for the big LLM to think about its moves. It’s not necessarily worth the time & money to use a Pro model in such a mundane task as building a React site on top of one JSON file. But as the AI evangelists on social media tell us, these days “you can just do things”.

Why this is better than Microsoft’s sites

I do appreciate how the teams at Microsoft are eating their own dogfood by hosting many current sites on Power Pages. The downside is that the UX isn’t exactly world class with this type of a tech stack. It’s great for easily exposing Dataverse records in customer portals behind a login. It’s not that great for most other types of websites.

Have you tried searching for things on the Release Planner website? Yup, it’s not a pleasant experience. After you get past the static advertisement block promoting an old release wave highlights video, you still have to figure out under which product page the matching results are found. One by one, you click inside the slow website and try to ignore all the visual clutter that stands in the way between you and the search results.

Searching for “fabric” on Microsoft’s Release Planner website. 🤕

On my Release Plans Browser website, it’s all about filtering the data. There is zero bureaucracy about how the data should follow the MS org chart, let alone any marketers wanting to push their “content” in your face. The React site is literally just a fancy way to group, sort, arrange and prettify the JSON data. Even though it could still be optimized, I’m pretty damn proud about this first version already.

Searching for “fabric” on the Release Plans Browser website by Niiranen Advisory Oy. 🤩

Yeah, of course it has a dark mode option! This is a website for low-code geeks, after all.

Clicking on a release item will open it in a side pane that shows all the information available from the API. Often this will be the same thing available on official Microsoft sites, but unfortunately screenshots and some other extra info, like links to feature docs, aren’t passed through to the JSON. To overcome this gap, I’ve added buttons for quickly searching the item name on both the Release Planner site as well as Microsoft Learn.

Release item details pane, including outbound links to search more information on MS sites.

“Hey, wait a minute: that MS Learn button takes me to Bing?” Yes, it does. Because for all the great features that the Learn site has for consuming documentation, it sucks at search. Specifically in how you can target search to a specific set of articles. Or in the case of Release Plans: you can’t. Because those plans don’t exist as a search scope visible to regular users at least.

Why Microsoft is not capable of offering a “search all content in this plan” option, and instead allows only exact matches for page titles remains a mystery. Perhaps it’s due to how the Release Plans are not visible as GitHub repos under MicrosoftDocs account. If they were, we could of course do much more with the content, rather than just downloading gigantic PDF exports from Learn.

“I liked the classic UI better…”

I realize my new version of releaseplans.net is a bit like the Modern UI release stunts that Microsoft product teams keep pulling. Even though the old interfaces may not have been the prettiest, often they contained functionality that power users find valuable. In the case of release plan data, the visuals in the Power BI version have not been replicated in the new React site (for now).

The good news is: you can have it all! I have preserved the report from the Release Plans Visualized site under the Analytics section of the new site. Just update your bookmarks to https://releaseplans.net/analytics if you prefer that one.

The Classic UI of Release Plans Visualized, now under the Analytics section of the V2 site.

“Embedded report: Power BI analytics surface.” Yeah, I know... There’s still some unfortunate LLM smell left in this new site from all the work GPT 5.4 Pro did in generating its code. Don’t worry, I’ll clean it up to be more natural sounding once I get the chance.

The old repo is also a bit messed up from my earlier stalled vibe coding experiments and needs to be cleaned up. As for the new site, while technically it is running on GitHub Pages, I’m not yet sure if I want to make its repo public or not. For these AI-first projects where each prompt quickly turns into a PR, the clutter from all the commits makes me think the concepts of GitHub ought to be reimagined for this new age of coding agents.

Anyway, I honestly do appreciate all feedback and ideas on how to fix/improve the Release Plans Browser site. Go check it out and reach out to me either via email reply, through LinkedIn, or any other channels where you find me! I do these things for the community because it has given me so much. Now with these vibe coding techniques, I can give back more than just my written words and meme pics.

Just like with the XrmToolBox Plugin Catalog I built last year, these sites built on top of public data sources offer a safe way to experiment and learn about where AI rocks and where it sucks. If the learning process also creates outputs that have value to others, all the better.

XrmToolBox Plugin Catalog is here!

When's the last time you explored the new and updated community tools for Power Platform and Dynamics 365? Here's a website to make that easier.

www.perspectives.plus/p/xrmtoolbox-plugin-catalog

I started the dedicated blog for my The Licensing Guide alter ego a few months ago. The idea was that I could use it for sharing the more factual and detailed information about a fringe topic that not everyone in the Power Platform community enjoys reading about constantly. Similarly, the usual snarky takes of Perspectives might not land that well with folks who are searching for guidance on such commercial topics.

But man, sometimes I just gotta write down how I really feel about the moves Microsoft is making with their licensing. That’s what this week’s Plus-exclusive newsletter issue is going to cover. I’ll tackle these three recent events/announcements:

• E7 + A365: the $99 Frontier Worker Suite

• Power Apps Per App end-of-end-of-sale

• Copilot Chat giveth and Copilot Chat taketh away

Agents dressed as information workers in M365 E7 disguise

It’s hardly a secret that Microsoft wants to expand the Total Addressable Market for its software via moving from licensing human employees to licensing AI agents. Satya has been talking about it across different events. Most recently, his visit to the Morgan Stanley Conference gave us these kind of projections to digest:

From the same interview, we can generate a summary slide that visualizes how Microsoft wants to expand their AI business by moving from current chat mode to co-work / task mode and ultimately the digital worker mode:

Sounds pretty sweet for the investors. What do we get in practice then with the Agent 365 product that has been announced to reach GA on May 1st?

Back when I entered the workforce at the turn of the millennium, Nokia was to the tech world roughly what OpenAI is today. Magical technology suddenly available to regular consumers, disrupting established patterns both in business and personal life by tearing down a long-held barrier (location and time in communication). Their award-winning marketing tagline was: Nokia - connecting people. Simple, beautiful, Finnish.🤩

The best phone design ever? Nokia 8810 with the “connecting people” hands on its monochrome screen.

The Power Platform and other similar low-code tools were disruptive largely because they allowed anyone to connect apps and data sources together in the cloud. Not via the landline-style integration projects, rather just by clicking a digital button on the computer screen. No need to understand at all what happens behind the scenes (especially not the security dilemma). It just works!

Until it doesn’t one day. When you start receiving email alerts like this one:

Power Automate alert email about a flow that started experiencing issues.

No big deal. Just another couple of buttons to click and everything once again works. Right?

If you don’t pay attention to the process (or the message) and just keep clicking on the presented buttons, you can think everything is working “by design”. Most users probably try to just keep their automations running. Me, I’m the kind of troublemaker that starts to look deeper into what is happening — and then posts about it. This is of course what was the trigger for this week’s newsletter issue. One of the many available trigger actions.😁

It starts with a lie

Let’s look at the email body text first:

Those are hardly ever the real reasons, based on my experience. They certainly aren’t in my Niiranen Advisory M365 tenant. In general, configuration changes on the tenant level or password changes (which have NOT been recommended as a security policy by MS for years now) are rarely the cause for this behavior. If we click on the run history link in the email, we’ll see a much more honest take from the raw action outputs:

Flow run details with an error message for an AI action: AuthorizationHeaderInvalid

  "code": "AuthorizationHeaderInvalid",
  "message": "The provided Authorization header is invalid: S2S17001: SAL was able to validate the protocol, but validation failed as none of the inbound policies were satisfied. Validation failures: 'Unified: TokenExpired'."
}

It’s an expired OAuth refresh token, of course. Sure, it could be because of the reasons mentioned in Microsoft’s email. But it’s unlikely. Here’s a quick table I prompted to illustrate the token expiry causes and frequency:

In short, what happens is that Power Automate connections hold a stored refresh token, as there is no interactivity like with Power Apps for the login. By default, that token has a 90-day inactivity clock. If the flow runs in this time frame, it will attempt to renew the token. If not, it’s effectively dead. With custom policies for the Entra ID tenant, that time could be shorter, of course.

This applies to OAuth-based connectors, meaning the usual connections people would set up via the convenient buttons and auth dialogs. Service principals, API keys, basic auth — those would not encounter the same expiration limit. But for the commonly used OAuth connections, if a cloud flow does not run once within the 90-day period, expiration is fairly certain.

Note that having MFA on for the account should not in any way interfere with whether the OAuth connections work or not, that’s a common misconception. Another point that actually makes the email alert more misleading is that a password change with an account that has MFA enabled should not reset the token. This, combined with the Jan 2021 change where RefreshTokenMaxAge support was dropped, means that connections most often should not expire without some tenant-level admin intervention on Entra ID side.

That’s the theory. Yet even in vanilla M365 tenants, connections still frequently break.

Workflows (Frontier) agent makes troubleshooting impossible

Last year we saw Flow Builder Workflows (Frontier) agent in Microsoft 365 Copilot introduce a modern AI-first experience for building automations. Not trhough a GUI, but through chat. As usual, I took a critical look at what the possibilities and limitations with this approach were at the time.

Can Workflows replace Power Automate?

Microsoft 365 Copilot paying customers can now create actual cloud flows by prompting an agent. With plenty of caveats and issues left to resolve, based on the Frontier preview.

www.perspectives.plus/p/can-flow-builder-replace-power-automate

I haven’t seen any announcements related to Workflows (Frontier) since then. When 2026 Release Wave 1 arrives, we may see either 1) Workflows get promoted while Power Automate cloud flows are left to rot as a standalone feature, or 2) nothing major for Workflows, which would indicate the Frontier version may never graduate into a production-ready product. It’s a coin flip and I’m not sure I want to place any bets.

But back to connections. The flow in question happened to be built via Workflows (Frontier) agent, even though the email alert is just standard cloud flow content. The “Fix My Flow” button takes me to the connections page in Power Automate maker portal. In there, AI actions (the connector in question) is listed. However, unlike all the normal connections, there’s no “reconnect” link to reauthenticate. Nor is there any details page behind the three dots, just an option to delete the connection.

Power Automate maker portal shows AI actions connections yet doesn’t allow much actions.

As I wrote in the earlier issue in October, there’s a lot of UI-level blocking and hiding going on with Workflows (Frontier) agent. It is built on the shared Power Automate cloud flows foundation, of course, yet the product’s creators tried hard to stop the user/maker from looking beyond the prompts. We can see one flow run in the maker portal, but for more details we have to open the M365 Copilot app and the corresponding agent.

Run history in the Workflows (Frontier) agent UI: visibility without actions.

Okay, this is… not any better. We have no view of the connections used by a workflow. We can view the run history, yet there are zero actions we can take on anything here via the GUI. I guess our only option is to do what gave us this workflow in the first place and engage in a chat with the agent.

It responds politely to my question at first, although it is completely oblivious to the context. It naturally starts with generic knowledge about Power Automate and its features. When it repeatedly asks, ‘please give me the flow name,’ I try to tell the agent that we are on that very page right here — plus the UI is designed in a way that hides the flow title when working on its logic.

“I’m sorry, Dave. I’m afraid I can’t do anything about the connections I set up with you.” The LLM answer is the kind of hallucination that is totally expected yet grinds my gears:

My response to Workflows (Frontier) agent can be seen below:

So, we’re stuck. Something in the platform has caused the connection to expire. Because the “design” did not take this scenario into consideration, the whole automation probably needs to be thrown away at this stage. Which would not have happened if we had just used Power Automate cloud flows in the first place (unless you used the modern editors, which have occasionally irreversibly corrupted my flows in the cloud).

A messy pile of broken keys

If an unrepairable connection is bad, what could be worse? How about thousands of broken connections generated by the Workflows (Frontier) agent? Oh, yes. That would be worse. And it is, as we’ll see next.

“2127 of your connections need to be reauthenticated to avoid the following flows from failing. The most common cause is a password change or policy update from your org.” It is NOT!!!🤬

If you only watched the keynotes and read Microsoft blog posts, you could conclude that Dynamics 365 is now primarily an AI vehicle, framed around Copilot features and agent scenarios designed to revolutionize sales and service work. That’s quite natural. In marketing, it’s always about what’s new. Oh, and in certification exams, too.

The functionality we as customers and partners of MS bizapps work with on a daily basis doesn’t change with every release wave. We rely on the core of what systems like CRM were built to handle. We build on top of what the apps have, by either adding or removing pieces to make it fit the purpose of the system. That foundation doesn’t change radically — not even in ten years.

But a lot will happen within a decade. Evolution made us humans pay attention to the sudden movements, which was a crucial skill to keep us alive in the jungle. We’re not as well equipped to notice the slow changes that gradually change everything around us. The creeping climate catastrophe being one concrete example of this.

Recently, on a couple of occasions I needed to compare what Dynamics 365 is today vs. what it was a decade ago. This made me realize how much I take things for granted now that were not available in 2016. We should remember to celebrate the progress that we’ve seen in things that truly did matter. Likewise, it helps in calibrating our minds about the importance of shiny new things when we acknowledge that some of them will not matter much a few years later.

That’s what this week’s Perspectives issue is all about. Let’s begin our 2016→2026 journey!

From customizing CRM to building on the Platform

2016 was one of those big “reimagine” moments at Microsoft. Dynamics CRM was replaced with Dynamics 365. Microsoft’s CRM and ERP were to become one business suite to rule the world. “Microsoft Dynamics 365: One Cloud” was one of the marketing slides.

The End of CRM as (Microsoft) Software: my post from 2016.

Just because it didn’t necessarily go like the slides promised, doesn’t mean it wasn’t significant. The Dynamics products were taken to the mainstream of Microsoft’s offering, alongside the booming Office 365, which clearly resulted in more investments into R&D. The pace picked up considerably from there on.

Reimagining Dynamics 365 as a set of apps you could pick and mix rather than a single thing called CRM was controversial for existing customers, sure. But the upside from it all was that this made a real business application platform possible. Apps became something everyone could build. Whereas XRM certainly wasn’t an environment you’d just let anyone have a go at.

In the classic Dynamics CRM world, you would customize the system. Even in the modern Power Platform Environment Settings app, you can still see the legacy terminology in there. It remains only there for backward compatibility purposes, offering a route to the CRM 2011 era Solution Explorer.

Customizations area in the new settings experience. We won’t forget it’s new because the banner notifying us about this cannot be closed. We can only ever learn more.

The term “customize” assumed that you bought a system for your business and then you wanted to change it or extend it. In the Power Platform era, we no longer do that. We can of course customize existing apps from Microsoft, or RapidStart, or whoever is the solution vendor. But if we choose to build from scratch, the tooling is exactly the same. It is today a platform for both makers and vendors. This is the single biggest conceptual difference to how things were in 2016.

Dataverse as the stable core

If we ignore the crazy naming adventures, the foundation formerly known as XRM is still the most critical piece of Dynamics 365 CE/CRM. For a history lesson, check out my article from last year.

The journey from Common Data Model in 2016 to Microsoft Dataverse in 2026.

Sure, it’s still a database — among other things. What started as the single DB per CRM server (until multi-tenancy in CRM 4.0) evolved first into organizations and then Power Platform environments. If you’ve ever seen me preach talk about low-code governance, you’ll know that environment strategy is at the core of what makes it real. The services and tooling that Microsoft has built on this front over the recent years has huge value for all customers, regardless of what data sources their apps and automations use.

The idea of Dynamics being basically just forms over data was somewhat valid ten years ago. Today, you’re missing out on most of the platform capabilities if you stick to that mental model. Even though the big ambitions around virtual entities tables never materialized, the power of connectors changed the game from moving data around to reading/writing data against various sources on the fly.

The connector capability comes from the Power Apps/Automate side of the house. When the Power Platform became a thing in 2018, a big reason for merging XRM with PowerApps & Microsoft Flow (as they were called) was to avoid reinventing the enterprise wheel. The simple apps and flows needed a lot of tooling around them to make things scale. Luckily, much of that was already up and running in the Dynamics 365 cloud.

The needs for creating a platform for one billion apps from all makers rather than just a few predictable CRM systems pushed the offering forward. One side was the self-service nature of how Dataverse environments can be used today. Yes, not all of the simplified modern UIs are very power user friendly. Luckily, behind the UI there’s been plenty of progress.

Low-code DevOps becomes a thing

Enterprise Dynamics CRM projects had attempted to follow common software development practices already before Power Platform. Yet most deployments were never at the scale where investing in “proper” SDLC methodology was financially justifiable. As a result, consultants and admins just customized systems each in their own way, through the available means and with the resources available to them.

Starting from a business application platform means you’re not really doing custom software development the way the teams at Uber or Spotify are. In 2016, most teams doing Dynamics 365/CRM work didn’t resemble a classic dev team at all, even if some members had aspirations to adopt practices from the big boys. The concepts, the tools and the business needs were just too far apart for much of those to be applicable in everyday consultant life.

ALM was always a concern, though. Just because you didn’t write software from scratch didn’t mean that getting the app updates reliably and repeatably deployed into the hands of business users was easy. CRM folks knew the risks and issues, they just lacked the tools that would have been fit for purpose. As the solution framework launched in 2011 became the model offered also for individual citizen developers, this only made the divide between theory and practice wider:

ALM for low-code: are we there yet? - Jukka Niiranen blog

Application Lifecycle Management tools & concepts are often aimed at pro developers. What should ALM be like when the audience is citizen developers?

jukkaniiranen.com/2020/06/alm-for-low-code

In the above article I wrote six years ago on this topic, I longed for a built-in deployment pipeline like the one Power BI had introduced. Fast forward to today and Power Platform Pipelines are a reality. And in general, they work! That doesn’t mean Pipelines are perfect for everyone, but I mean: OMG, things are so much better for low-code ALM now! We even have native Git source control integration in Dataverse.

The pros don’t probably like the restrictions of built-in Pipelines and that’s just fine. Deep down, the features are part of the same APIs that PAC CLI calls. Which means you don’t need a GUI, you can do things with code. And in 2026, anything that’s expressed in code is something LLMs are well equipped to tackle. See where this is going? That’s right: the terminal as the new UI (gift link to Plus article is here).

The new bottleneck is apps

Instead of starting from a M365-like suite and adding AI, Anthropic pursued a "no apps" model and caught everyone's attention with Claude Code. Maybe all you need is text files?

www.perspectives.plus/p/the-new-bottleneck-is-apps

For power users and low-coders who aren’t afraid to open VS Code and talk with GitHub Copilot, the world of platform APIs is now open. The way how Power Platform Connectors democratized talking to other SaaS apps (even if it’s essentially “credentials sharing as a service”) is now happening to any endpoint.

Apps are both dead and booming

For as long as there’s a human in the loop, the visual side of the UI still matters. If we look at what the first-party Dynamics apps for processes like Sales and Customer Service are today, the main ingredients are still the same as ten years ago. Today we just call them model-driven Power Apps in technical terms. The detailed recipe has evolved substantially, though.

Splitting CRM into semi-independent app product teams meant not every app needed to look the same. Domain-specific UI controls like the pipeline view in Dynamics 365 Sales Hub became an everyday thing as the product experience was allowed to diverge.

Bubble chart and customizable metrics in the opportunities view of Sales Hub.

“Aren’t we now trapped inside non-standard UI experiences that can’t be tailored for real customer needs?” On some level that is true, but it’s not that bad actually. Thanks to it all being built on top of Power Apps Component Framework, everybody can now build these non-standard controls in a supported way. A decade ago, the idea of replacing any standard control with your custom one was something the PMs at Microsoft quietly mentioned to us at the MVP Summit presentations in Redmond. Today, PCFs are an everyday technology in the platform.

In 2026, the popular hot take on social media is “canvas apps are DEAD!” In 2016, we didn’t have them on the same platform to begin with. What is dead for sure is embedded canvas apps on model-driven forms, given how Microsoft has since then prioritized custom pages as the technology for pixel-perfect UIs inside model-driven app frames. Used extensively in both commercial products as well as Kits from Microsoft, it’s hard to see these going away soon — no matter how slick React apps you can create with vibe coding today.

CoE Starter Kit Setup Wizard and one of the many custom pages in the Kit.

Code Apps recently went GA and provide an interesting option for building completely custom experiences on top of Dataverse + the connectors via prompting your AI tool of choice. Whether that would ever turn into productized Dynamics 365 apps that customers are expected to “vibe customize” remains to be seen. Nevertheless, in a world where UIs can become entirely generative, the value of a stable data layer and identity + access management tooling may prove to be significant.

Business logic going round in circles

The one area where it’s difficult to find any major leap forward is ironically what business apps like Dynamics 365 should really be about: business process automation. Storing data is one part, showing it on nice form and grids is another one - but what does the system actually do with that data? Or how can it help users do the thing they need to do, with less… “doing”?

The core capabilities of XRM plug-ins and workflows have not been revolutionized by the cloud. For cross-system process automation, yes, we’ve definitely gained plenty of new tools to connect apps and data sources. But for in-app logic, there isn’t much progress on the platform level that could unlock more complex process automation, calculations or process UX support.

The first-party Dynamics 365 apps have each gone and built automation features specific to their domain. It’s sort of natural that the needs of a customer service rep are different from those of a sales manager or a field engineer — resulting in diverging app experiences. The IPR of Dynamics products has been moved into containers protected by the app licensing, to more clearly distinguish them from the custom Power Apps that you could be running at $20/user/month. When paying $105 for Customer Service Enterprise, for example, you obviously need to get some bang for the buck beyond just basic ticket queues.

When it comes to platform-level functionality like Business Process Flows or Business Rules that were already available ten years ago, Microsoft lost their ambition to push things further. They never developed tools for more complex BPM scenarios, even though the technology would be right there in the house, like the MS Visio integration of AgileXRM demonstrates. The slow advancement of Power Fx support or the back & forth with low-code plugins is a sign of there being a lack of direction for deterministic enterprise automation within Microsoft. All the internal incentives are encouraging taking the non-deterministic Copilot route.

The rise & fall of new D365 products

At one point it seemed like Microsoft was launching new Dynamics 365 products every month. This was driven by the combination of A) having a fairly mature cloud business application platform, B) existing customer base for the core CRM products, and C) the excitement around tech trends like Internet of Things, Mixed Reality and Artificial Intelligence. A + B + C = potential new revenue to go after and make BizApps a bigger slice of the MS pie. Considering Microsoft was never the number one in neither CRM nor ERP for enterprise software market, it made sense to try new things that built on top of their uniquely broad tech stack.

In 2020, the website for Dynamics 365 showed a dizzying array of applications available. The number of Insights products kept expanding and you could have organized a bingo to see who guesses the next app to be launched: “Customer Insights!” “Customer Service Insights!” “Product Insights!” “Sales Insights!” “Market Insights!” “Finance Insights!” “Insight Insights!”

Archived version of the Dynamics 365 applications menu back in 2020.

Some got to a point of commercial availability, resulting in Microsoft’s local sales offices to invite customers and partner to immerse themselves in the Digital Feedback Loop powered by Dynamics 365 cloud, Azure IoT, Hololens, all that exciting, shiny tech. Others were scrapped before leaving preview. In any case, practically nothing from that booming era remains as a meaningful product used by customers today.

Marketing is perhaps the exception here. It’s an area where Microsoft was struggling massively ten years ago already. They had to go through plenty of iterations, renaming, merging and reimagining, yet at least today Customer Insights is a thing actual organizations are using. Journeys (the marketing part) bundled together with Data (the Customer Data Platform) is an offering that addresses a real need. It’s hardly the market leader in this game, nor suitable for any SMB customers of Dynamics 365, yet it has its place.

All the other new products may have been a false start for the AI and data era. You could argue, though, that it’s a necessary step in the evolution of business software. People say many of the product ideas that crashed and burned in the dot-com boom of 2000 have since then evolved into viable digital business models. The first AI boom of Dynamics must have cost Microsoft some money, sure — yet it was an entirely different ballpark than the runaway capex spend we see in today’s AI bubble. If lessons were learned from the “Insights era” of Dynamics, perhaps it was all worth it?

Every headline satisfies an opinion. Except ours.

Remember when the news was about what happened, not how to feel about it? 1440's Daily Digest is bringing that back. Every morning, they sift through 100+ sources to deliver a concise, unbiased briefing — no pundits, no paywalls, no politics. Just the facts, all in five minutes. For free.

Read the newsletter trusted by 4.5 million fact-seekers.

Here we go again…

In the year 2026, we’re still searching for a meaningful way to turn AI into a product Microsoft can sell and customers can benefit from. Unlike a decade ago, customer decision makers are actively asking for AI tools that could help their sales, service and marketing employees achieve the kind of magical results that tech media and LinkedIn influencers keep shouting about.

You’d imagine that at this point, after all the experimentation and investment, there would be a product that one could confidently offer to these customers as “here, take this, it’s a solid choice for most your needs”. But no. Whatever it is today, it will be a different thing tomorrow.

When I started with Microsoft Dynamics CRM 3.0 exactly two decades ago, the CRM Outlook client was a major selling point of the software. No, it wasn’t smooth sailing from a technical perspective, but at least the technology didn’t change every year. In 2017, Microsoft first announced they were going to deprecate the thick client and push everyone to the Dynamics 365 App for Outlook. Which is what they eventually did get to doing in 2020. But just look at what has happened with the proposed successor of the App for Outlook since 2022:

In addition to these “products”, we of course now have the agents as a new dimension. A recent document from Microsoft explaining the different sales-related use cases of agents included in total 15 agents — just for Sales! 

That’s a list provided by Claude. I literally now have to ask an LLM parse the information coming from Microsoft. Ten years ago, I could have just bought Dynamics CRM 2016 and start installing it on my Windows server. I was a big advocate for moving to the public cloud because things were much more likely to work there without technical issues blocking the end users and system customizers. Today, the blocking issues are more about not understanding what’s A) actually available in the cloud, B) knowing what it will cost, and C) predicting whether it will be there tomorrow still.

In times like these, it gives some comfort to know that there’s a robust business application platform behind it all. That you’re diligent about how to manage customer data in a compliant way. Instead of, you know, just uploading a list of PII as CSV or Excel files into an AI chatbot session and hoping for the best… Whoops!!!

The marketing promise vs. the reality of Sales Development Agent in Microsoft Agent 365.

In March 2026, Microsoft’s first and so far only A365 agent is still lacking an integration into a CRM system. It seems like this wasn’t as simple to implement as the product marketing team thought, but the pressure to release Frontier agents meant it had to be launched. There’s also a testimonial from Microsoft themselves how during a pilot program in Feb-Jun 2025, Sales Development Agent “engaged more than 70,000 existing Microsoft SMB customers”.

To put things into perspective, it was probably fine to conduct this agentic AI pilot with real contacts in the US. Had Microsoft attempted to do something like that in the EU, the word “fine” might have switched from an adjective to a noun. At least if the quick comparison done with the help of my AI assistant on this CRM scenario is accurate:

Evaluating the Sales Development Agent pilot scenario by MS, with & without CRM integration.

To end this on a positive note: Dynamics 365 remains a solid foundation for addressing crucial business requirements around CRM processes. It may not ship with all the necessary bits out of the box, yet Power Platform today has extensive tools for making the applications work the way modern business technology should. When you can both protect the core of what a CRM system must deliver day-to-day, as well as support new experiments that are necessary for companies to remain competitive in their markets, you’re in a good place.

It’s okay to get excited about all the vibes going around, and how easily we can generate entirely new apps and agents. Ultimately, I don’t think that’s what LoB systems like Dynamics 365 are about. It’s also the reason why they don’t necessarily get better at what they do by just adding more of new AI on top.

Warning: content for old people only! 👴👵🧓

If you really want to take a trip down memory lane and explore the first decade of Microsoft’s CRM software, I’ve written about that in this blog post from 2013:

I wrote about OpenClaw four weeks ago, back when it was still called Moltbot (but no longer Clawdbot). In the age of AI, this is an eternity. What I’ve seen since then in this space include much more than just the renaming. The big one of course being how the creator of this “lil’ hobby project” got hired by OpenAI. It doesn’t mean OpenAI now owns the open-source OpenClaw project but it does definitely heat up the competition for dominance in the autonomous AI agent market between Sam Altman and Satya Nadella.

As I wrote back in the Impostor without a syndrome issue in December, Satya has followed my example and started being active on GitHub with his private account. He has now published his first public repo (Philosophical Debate Chamber). I couldn’t get that app running on my PC unfortunately, but I didn’t yet dare to open an issue telling the CEO or Microsoft “does your code even work, bro”.

What was potentially a more commercially important signal was that Satya started following the OpenClaw GitHub project on Feb 10. A few days later, Peter Steinberg announced he had accepted a job offer from OpenAI. Tech press has suggested everyone in Big Tech was bidding in this hiring race and it would be strange if Microsoft hadn’t approached Peter at all. Was it Satya personally, like we’ve heard him now do recruitment calls for strategic AI positions? We may never know.

Claws are now a thing

I haven’t dared to deploy OpenClaw anywhere because it’s a security disaster waiting to happen. That concern hasn’t stopped everyone, though. For example, the Microsoft CVP of Word recently shared his OpenClaw setup out in the open:

Meet Lobster 🦞: My Personal AI Assistant

And How You Can Build Your Own

www.omarknows.ai/p/meet-lobster-my-personal-ai-assistant

I sure hope the newsletter name “Omar knows AI” is backed by more than vibes and that this senior leader at Microsoft knows how to keep things secure. But let’s get back to that part later in the newsletter. The key thing is not the problems of this technology but rather the fact that “claw” has become a tech thing. Because Andrej Karpathy said so and Simon Willison backed it up:

Just like there initially wasn’t a great definition of what an AI agent is exactly (before the geeks settled on “LLMs calling tools in a loop”), that won’t stop everyone from adopting the term. 2025 was the year of vibe coding and now everyone is doing it or at least talking about it. Microsoft started talking about “vibe working” in September and has since then also launched an official Power Apps app type called vibe app. It’s silly — and it’s a thing. Both can be true at the same time.

Andrej Karpathy on the chat → code → claw evolution of AI.

This all makes it almost certain we’ll see a “Microsoft Claw 365” kind of a thing from Redmond in the near future. (Fun fact: there was a CLAW from Microsoft Research for the VR/Metaverse era). Let’s imagine for a moment how this might turn out.

What would Clawpilot look like?

The title for this newsletter issue is of course a dig at the “UI for AI” pitch that Microsoft has used for Copilot. I’m known for sharing a bit of critique at this approach as well as using numbers to back up my claims about the Copilot-first strategy not working as advertised.

If injecting a Copilot sidecar into every software product’s UI didn’t have the transformative impact expected, maybe it’s time to rethink the strategy? In the minds of many consumers especially, Copilot has become a brand that symbolizes overblown claims and the modest everyday impact of AI. Nobody rushed out to buy Copilot+ PCs so that they could use more of these features, or get the dedicated Copilot key to do… Yeah, what is it actually for?

Even Drake isn't too impressed with Copilot anymore. But Clawpilot? Now THAT’S an idea!

The problem with Copilot-style AI assistants is that often they’re all talk, no hands. The fact that I keep seeing social posts announcing exciting new features for Copilot, then see them fail immediately when tested, is not the formula for customer retention. People will stop trying — then they’ll stop renewing the AI license subscription.

Assistants without hands

When everyone talks about agentic AI, it's all too easy to forget how AI assistants like Copilot today can't be trusted to do things for us - if it involves anything more than talk.

www.perspectives.plus/p/assistants-without-hands

What’s the problem with Claws then? Well, they’ve got hands — that’s the major difference. The models used behind the scenes are mostly the same as with the all-talk AI assistants — running in the cloud rather than the local box (at least for regular Crab people who aren’t in it for digital sovereignty reasons). The scheduled nature of Claws is also very different from the interactive Copilots that require you to chat with them for anything to happen. But the core problems of LLMs in business use remain. Or more precisely: they are amplified.

The best sales pitch for everyday automation remains IFTTT. No, I haven’t used that product in almost a decade, yet the name is just fabulous. “If This Then That”.

It’s that simple — in theory. Around 10 years ago when Microsoft Flow was launched, it didn’t primarily aim to be a business application automation tool, the way Power Automate is today. It supported consumer Microsoft accounts and potentially had something to offer anyone with a computer (or even just a phone).

As usual, things that start simple and clean will end up becoming complex and messy — especially if you sit at the very intersection of major Microsoft clouds. Microsoft 365, Dynamics 365, Power Platform and Azure have all stretched the simple idea behind Flow into what we see today. In this newsletter issue, I’ll reflect on what is happening with Power Automate and how it keeps manifesting itself in user experience woes.

First, I’ll walk through what very recently went wrong with the V4 flow designer launch. Then, I’ll explain why makers are increasingly relying on community tools to stay productive. Finally, I’ll drill deeper into how the silent but obvious Power Automate and Logic Apps split hints at a Copilot-first future that threatens to leave the everyday cloud flow usage in existing business processes behind.

Power Automate GUI struggles

The original flow designer was fairly modern at the time. For simple “if this then that” logic, it was probably just fine. Yet because Microsoft chose to make Power Automate also the enterprise business process automation solution, it meant the same tool had to cater to vastly more complex scenarios. Thanks to its limited integration with native Dataverse concepts (parity with the full-GUI XRM workflows never arrived), you often needed to work with formulas and OData filter queries in even basic CRM automation tasks.

The clumsy editor was a big reason why I’ve never enjoyed working with flows. Microsoft surely has been aware of the challenges. As a result, they tried to address several UX issues that were hampering power user productivity by launching The New Designer. After preview, it went GA in November 2023. Yet two years later, many users were still resorting to the classic designer due to errors, compatibility issues and simple neglect on Microsoft’s part to make V3 the default experience when accessing flows from the Power Apps side (or run history, or wherever). There was a lot to like about V3’s improvements, but someone just forgot to finish the job — most likely due to resources getting reallocated to Copilot.

Let’s fast forward to 2026. There have not been many updates to Power Automate cloud flow promised in the release plans, which is something I called out in the “Error: roadmap not found” part of my August newsletter issue already. For good and bad, that doesn’t mean things wouldn’t be changing. If you’re in a position to keep an eye on the restricted-access M365 Message Center, you might have noticed MC1218891:

“Power Automate – View property value expanded inline in the new cloud flow designer”

Would you have realized that this message means there’s a new “V4” designer coming? That it reverses the sidebar UI of what V3 brought us over two years ago and takes things back to the oldskool? No? Well, unless you’re a Power Automate MVP, I don’t blame you for not connecting the dots.

What happened next was… tragic. That’s the most descriptive word I can think of for good intentions gone so horribly wrong. While some “exciting news!” posts were also shared out on social media, many customers were outraged by how the editor had changed overnight:

“New horrible designer today!” thread on Power Platform Community forums.

Since I’ve been working with quite a few complex cloud flows lately, I opened them in the new editor and examined how the experience had changed. On every occasion, my CPU started screaming as Edge was consuming all available memory. Trying to render the flow steps while I was expanding the logic proved to be a challenge for this editor. It had all worked fairly smoothly (from a resource use perspective) in the previous two editors. Now, it felt like Power Automate was seeing such flow definitions for the very first time and freaking out.

Even if the code wasn’t as inefficient as it obviously was, the new designer delivered the classic “modernize the UI” treatment we’ve seen across Microsoft products. Meaning: with every new UI update, you see less of your data and more of useless whitespace or UI chrome. In the case of flow, the situation had now gone from bad to worse. Understanding the automation big picture became an even greater challenge than before.

Then, two days later, the “new” designer was gone. Microsoft had silently reverted the UI back to V3, which used to be the New designer.

What happened? Well, first of all, it’s encouraging that the frustration and issues reported by customers online made Microsoft roll back the changes so fast. Now, the question that remains unanswered is: “How could something like this happen in the first place?!?”

There’s not a lot of info besides community comments to go on at this stage. The M365 message center announcement has been deleted. I also saw reports about the 2025 release wave 2 plans having been changed:

Indeed, when we go and look at the change history page on MS Learn, we see an entry for “View property value expanded inline in the new cloud flow designer” feature. It says the feature had been removed from the plans on Jan 30, 2026, with the reason “moved to the next release wave”. Well, we all know this is simply not true since the feature rolled out straight into production for all Power Automate customers on Feb 9th anyway.

Who approved the deployment? Has GitHub Copilot at MSFT become fully autonomous by now? Is this why crazy “features” like locking down the plan/project Dataverse table in Microsoft Planner keep happening lately? Is the reason for the zero communication coming from Microsoft simply because no human knows how the organization operates anymore? Hello, is anyone there?

The only good flow UI is the one you build yourself

I am positive that there are lots of folks in Microsoft product teams that are trying to do the right thing. Yet the current incentives that top management have put in place are directing the machine to deliver features and changes that are serving their own interest, not the customers’. The KPIs are actively hostile, especially when it comes to user experience.

Here’s one challenge for you, to illustrate things: how quickly can you find the flow runs in the Power Automate maker portal today?

Cloud flow details page, with a bunch of crap that pushes the flow runs below the fold.

Unless you turn your widescreen monitor sideways (vertical mode), you won’t see that information directly today. Because at the top there’s a bunch of either static information that’s always been there (without anyone questioning the priority) or advertisements for new features that aim to drive the MAU metrics (active users) that Microsoft PMs are measured on. The user needs to scroll past a bunch of crap to get to what really matters in real life: when did my flow last run and what was the outcome?

The insulting part is that all the data needed for constructing a productive UX is already there in the platform. Microsoft is just ignoring the needs of software users who build cloud flow automations as part of their jobs. There’s apparently no KPI for power user productivity. Which means the power users need to take things into their own hands and build custom UIs for fixing the Power Automate UI gaps.

Flow Run Buddy, a Chrome extension that displays run history directly from the flow designer.

The above example is Flow Run Buddy, a browser extension that renders the ever so relevant flow run details in a persistent sidebar. Built with Claude Code and GitHub Copilot as a vibe coding project by a Power Platform consultant. Now, I’m sure that a Microsoft UI would have to meet all kinds of requirements for accessibility etc. to get out the door, yet these small extensions demonstrate what the official Microsoft products could well offer you. Or more precisely: should offer.

Instead, the Power Automate cloud flow UI feels like a persistent obstacle that stops me from getting work done. But these days, when you get frustrated enough, you can just tell your problems to a tool like Claude and it will spit out functioning code in a few minutes. Like what I’ve done with my Power Bookmarklets repo that contains quick scripts that I can either add directly as bookmarks or Tampermonkey scripts and make things like cloud flow JSON immediately accessible and summarized in the browser:

Clicking the “Get Flow JSON” bookmarklet now opens a popup of flow details like this for me.

For bigger tools, there’s currently 11 Power Automate plugins in the XrmToolBox Plugin Catalog for anyone to browse. The newer Power Platform ToolBox is also getting new cloud flow related tools, making the experience even more modern. When the vendor fails to deliver, the community will step in. That’s what “Power” in the product names really stands for.💪

Power Automate 💔 Azure Logic Apps

On a deeper technical level, the symptoms of UX erosion/stagnation in Power Automate cloud flows are related to the bigger shift taking place. To use the cliched ChatGPT phrase, “no one talks about” how cloud flows are no longer a layer on top of Logic Apps. This change hasn’t received much attention online, so I decided to vibe code a summary page of the key details and publish it on my Vibes site.

Power Automate vs Azure Logic Apps: the 2025 split

As mentioned at the beginning, Power Automate (then MS Flow) started as “Logic Flows” built on top of Azure Logic Apps. Initially just an element of Power Apps (or “PowerApps” as it was spelled), it didn’t try to reinvent the underlying runtime but rather focused on making the elements from Azure available in the context of business users. In a way, it was “just” a layer on top of Logic Apps. The path of converting flows into Logic Apps was actively promoted in the UI for some time, supporting the “no cliffs” idea of starting with no-code and evolving to pro-code on the one Microsoft stack.

In 2025, the runtime architecture went through a breakup process. Let’s explore the details from the above summary page:

After eight quarters of carefully not telling us how many people actually pay for M365 Copilot, Microsoft finally published the number in their January 2026 earnings call. 15 million seats. That's 3.3% of the 450 million Microsoft 365 commercial installed base, after two years on the market and what MS describes as "the fastest adoption of any new M365 suite" in history.

To be fair, 15M is higher than 8M. That was the leaked number from August 2025 that prompted me to write the Microsoft 365 Copilot's commercial failure article, which received both a lot of hate and support in different channels. We still don’t know if the 8M number was accurate or whether its counted with the same criteria as the first official disclosure. But yeah, 3.3% adoption rate is better than the 2% that I assumed from 4 months earlier. So, congrats on beating this analyst’s estimates on the premium AI conversion rate, MSFT!🥂

Converting users to premium AI subscriptions: OpenAI vs. Microsoft.

Is it a commercial success then? 15 million seats at $30/month list price would be $5.4 billion annualized. That's a proper business for sure. But analysts like Citi and J.P. Morgan have documented heavy discounting in the 40–60% range for competitive deals, especially the large deployments Microsoft loves to announce. A more realistic revenue figure could be something like $1.5–2.5 billion.

To update my own perspectives on things, I decided to do a status check on the numbers behind Microsoft’s AI business at the start of 2026. I went through the 4 most recent quarterly earnings transcripts (FY25 Q3 - FY26 Q2), covering April 2025 to January 2026, and asked my top-tier LLM assistants to pull every AI-related number they could find. Then I made them cross-reference this with independent data from Recon Analytics, SemiAnalysis, Similarweb, and other sources.

In today’s newsletter issue, I will cover the good, the bad and the ugly of what this data says to me when I interpret it.

The good parts of Microsoft’s AI business

GitHub Copilot looks like the clearest AI product success. The growth trajectory across 4 quarters was:

• 15 million users in April 2025

• 20 million users in July 2025

• 26 million users in October 2025

Then, Microsoft switched from reporting "users" to reporting "paid subscribers" in January 2026. The number: 4.7 million paying customers, up 75% year-over-year, with Pro+ subscriptions growing 77% quarter-over-quarter. If we’d assume a $19/month price point, we get to over $1 billion in ARR (annual recurring revenue).

Sure, the AI coding agent competition has definitely been heating up and I bet a shrinking share of developers actively choose GitHub Copilot today. Claude Code and other newer players are all the rage (even inside MS). But: it’s not a bad position for Microsoft to be the one that’s being chased by others. Coding in general has become the one area where LLM capabilities and shortcomings seem like an equation with a net positive outcome — at least when observed from a tool vendor perspective (some software devs might disagree).

Let’s think even bigger next. Azure as the underlying AI infrastructure grew at 35–39% in constant currency across all four quarters, hitting $75 billion annual revenue. Microsoft Foundry (née Azure AI Foundry) platform has 80,000+ customers, 80% of the Fortune 500, with over 250 customers on track to process more than a trillion tokens each this year.

In general, I don’t like the idea of using token count as a badge of honor. It’s like saying “we burned over X trillion liters of oil for achieving Y”, i.e. you measure a factor that should not be a positive thing. But in this case, when just thinking about the token factory of Azure as a business, they are the oil company. Demand for the products = good business. With Foundry positioned as a global LLM marketplace rather than merely an OpenAI-only shop, I see them as the enterprise go-to provider that can reap rewards from the AI spending craze of business customers.

What else? Dragon Copilot in healthcare went from 9.5 million patient encounters per quarter to 21 million in a year, with over 100,000 medical providers. Doctors may potentially save hours per day on documentation, freeing up time from highly paid professionals to other work. While I’ve seen some criticism towards the product from users posting online, I’d say the state of business for MS is pretty solid here.

The bad news around Copilot

Let’s return to M365 Copilot and what Microsoft have said about it in earnings calls:

• FY25 Q3: "Hundreds of thousands of customers," growth "tripled year-over-year." No seat count.

• FY25 Q4: "Largest quarter of seat adds since launch." No seat count.

• FY26 Q1: "90% of Fortune 500 use it," PwC deployed 200,000 seats. Still no total.

• FY26 Q2: fifteen million seats.

The selective language used with M365 Copilot is revealing. "Multiples more" enterprise Chat users than paid Copilot users — meaning the free tier dwarfs the paid product. "Daily active users increasing 10× year-over-year" — from what base? We don't know, because that's never been disclosed either. "Accelerating seat growth quarter-over-quarter" — sure, but 160% growth from a small number is still a small number.

Let’s look at independent data next. Recon Analytics surveyed over 150,000 enterprise users in January 2026. When people had access to all three platforms — Copilot, ChatGPT, and Gemini — only 8% chose Copilot as their preferred tool.

Ouch. I wrote about the problem of how users don’t actively choose Copilot already in July in the Plus subscriber exclusive issue. I didn’t have as clear numbers to prove the hunch back then. Even if this new data is just about US customers, it’s pretty brutal for Microsoft’s competitiveness in the market.

AI Choice 2026: Why Licenses Don’t Equal Adoption - infographic from Recon Analytics LI post.

According to this research, Copilot's paid subscriber share dropped from 18.8% to 11.5% between July 2025 and January 2026, while ChatGPT and Gemini gained. Perhaps the most telling finding: 70% of users initially preferred Copilot (it's right there in the Office apps they already use), but after trying alternatives, only 8% kept choosing it. This retention issue will be a far bigger concern than getting customers to subscribe for M365 Copilot for the first time.

SemiAnalysis posted their February 2026 analysis with a line that captures the real problem: "Claude for Excel effectively is what Copilot for Excel should have been, but it was launched by an external party on their own first-party product." An outside competitor shipped a better AI experience on Microsoft's own application than Microsoft's $30/seat/month product could deliver. When the Recon Analytics data says only one in twelve users choose Copilot given alternatives, this is why. The quality obviously does not meet customer expectations.

Now, let’s (not) talk about AI revenue

This has been mentioned in my earlier newsletters but it’s worth restating: Microsoft stopped reporting on their AI revenue one year ago. The AI revenue run-rate was last disclosed at approximately $13 billion in FY25 Q2 (January 2025). Then, the metric disappeared from their investor comms. AI's point contribution to Azure growth was disclosed once — 16 points in FY25 Q3 — and never mentioned again.

M365 Copilot revenue has never been reported separately, instead it's buried in "ARPU growth driven by E5 and M365 Copilot." The Copilot family monthly active users were last updated at 150 million in FY26 Q1 and conspicuously not refreshed in FY26 Q2. GitHub Copilot ARR has never been disclosed in an earnings call.

Companies stop reporting metrics that stop improving. Even if I picked Azure and GitHub Copilot to be in the good parts section of Microsoft’s AI business just a few paragraphs ago, we should not forget how the exact chunks of money gained from them remain undisclosed. In their absence, we hear anecdotes about specific customers (“PwC! Lloyds! Vodafone!”) and percentage growth rates that sound impressive — until you realize you’ve never been told what the base figure is.

Two beasts, one budget

SemiAnalysis drills deeper into the nature of the AI beast within Microsoft’s AI business:

Amy Hood, Microsoft's CFO, talked about this in the FY26 Q2 call. When asked about Azure growth, she explained that capacity allocation follows a priority order: first, M365 Copilot and GitHub Copilot and other first-party apps. Then R&D and product teams. Then, whatever's left, Azure third-party customers. She added: "If I had taken the GPUs that just came online in Q1 and Q2 and allocated them all to Azure, the KPI would have been over 40."

Azure has demand for the server capacity, which is a positive problem when your business is about renting servers. Yet Microsoft is not just a cloud infrastructure provider. Their market cap is based on a whole bunch of other offerings. This is the revenue split from the latest FY26 Q2 report:

• Intelligent Cloud (includes Azure): $32.9B → 40.5% of total $81.3B revenue

• Productivity and Business Processes (Office, Dynamics, LinkedIn): $34.1B → 42%

• More Personal Computing (Windows, Xbox, Search): $14.3B → 17.5%

Asking the leading image gen model (Google’s Nano Banana Pro) to visualize MS revenue split.🙈

Azure itself isn't broken out separately within Intelligent Cloud (that segment also includes SQL Server, Windows Server, Enterprise Services, etc.), but Azure is widely estimated at roughly $20–22B per quarter based on the $75B+ annual run rate. That’s roughly 25–27% of total Microsoft revenue. Productivity & Business Processes (where M365 Copilot revenue sits) is bigger, yet it’s not growing as fast as Azure (16% vs. 29%). All the evidence I keep writing about in this newsletter suggests it is in fact facing challenges to meet internal expectations.

The urgency of the situation can be seen at the very top. Business Insider reported that Satya Nadella has stepped into a hands-on product management role for Microsoft AI, pulling away from day-to-day CEO duties. He’s also been actively showing personal vibe coded AI solutions that are now publicly visible on GitHub. When the CEO personally takes over a product line and gets his hands dirty with Visual Studio projects, the stakes have moved past strategic and into existential.

Let’s imagine you have chosen a CRM system from a SaaS vendor to manage your critical business processes. It could be Microsoft Dynamics 365 Sales, Salesforce, or something similar. One key reason for your choice will have been the platform capabilities that ensure you’re not just buying an as-is app but rather a customizable solution that can adapt to your current and future needs.

You’re in the process of specifying the detailed use cases of how your employees will work with this system. The required fields, views and forms to make the app easy and efficient for users have been defined. Then, once you move to the development stage, you discover a surprise: “Hey, the contact table cannot be modified at all! It’s locked!”🔒

Welcome to the life of Microsoft Planner Premium customers/partners. This is the equivalent of what happened to them this week, in the context of project management rather than CRM. But let’s start from the very beginning, so that we understand why the product is going through uncertain times.

One Planner to rule them all

Readers of this newsletter may recall my earlier investigation into the amazing history that connects MS Project from the 1980s with the Planner Premium of 2026. To understand the full context of what I’m writing about today, revisiting the earlier piece is a good idea — unless you work with these products on a professional basis.

Microsoft Planner and the revenge of MS Project

The new Planner Premium plans contain surprising dependencies to earlier generations of project management software from Microsoft.

www.perspectives.plus/p/microsoft-planner-and-the-revenge-of-ms-project

Here’s the short version: the Planner brand today covers two software products with a very different background. 1) The O.G. Planner (aka Planner Basic) was built on top of Microsoft Graph as an app with hardly any dedicated data store of its own for the key elements (groups, tasks). 2) Planner Premium, on the other hand, was a database-centric initiative built originally as Project for the Web, leveraging Dataverse (then Common Data Service) as the back-end and Power Apps as one front-end.

Unlike the M365 family of products like Teams or SharePoint, data stored in Dataverse has never been made available natively via MS Graph. Those of you with a Dynamics 365 background may recall the now deprecated PSA product (Project Service Automation) and know about the current ERP side offering of Dynamics 365 Project Operations. The strange duality of Planner’s Basic (M365) vs. Premium (Dataverse) sides in terms of the underlying technology stack makes it a product that’s much more complex than it appears at first. One side is firmly the M365 collab world. The other is flirting with hardcore ERP software in terms of shared components.

As you can imagine, this divide makes it quite difficult to work with Planner from a customization and extensibility perspective. I’d argue the gap is as big as the one we’ve had between Microsoft’s CRM and ERP products for 20+ years now. The bundling of Planner Basic into M365/O365 makes this product very widely used in organizations. The fact that the “upgrade to Premium” upsell path takes the users away from M365 land and deep into the D365 ERP domain with Project Scheduling Service dependencies is simply unsustainable in the long run. The web is full of angry customers who didn’t know what would happen when they chose a different plan type in the Planner UI.

At Ignite 2025, there was one session on Microsoft Planner that addressed this very issue. The tech divide between Basic and Premium Planner is supposed to become less of a concern for customers, thanks to a single plan type being introduced in the Planner app. Here’s my summary post of it on LinkedIn:

“A single plan type in Planner” - Ignite 2025 session insights.

This plan unification would be a major step forward, for end users as well as partners and developers. The part that I personally would very much want to be real already today is the single API surface. Because so far, the Planner connector in Power Platform will only work with the Graph world of Planner Basic data. Most customers will have banged their heads on this, with very few discovering the crazy hoops that you must jump through to automate anything related to Planner Premium tasks.

It’s happening (I guess?)

I am pretty good at finding official and unofficial information sources on Microsoft product news. These are the skills that I have honed during my blogging career and continue to make use of when writing this newsletter or covering niche areas like business apps licensing. Knowing the right portals and having the right bookmarks often makes uncovering MS product mysteries possible (and fun, I got to admit).

Planner is a formidable challenge in this sense. Because compared to what the Dynamics 365 and Power Platform product teams put out into the web, the Project/Planner team seem to prefer keeping things to themselves. Since the software it lives in the cracks between M365 and Power Platform, you can’t expect it to be properly covered in main communication channels of either two clouds.

Microsoft 365 Roadmap entries for Planner follow the corporate comms pattern of “the less concrete details we reveal the better” and aren’t therefore useful for people working with the technology, rather than just using product features. We have to follow the good ol’ read-between-the-lines strategy and decipher things like M365 Admin center messages to deduce what is happening and when. Like this message from December:

M365 Admin Center message: “Retirement of several Microsoft Planner features in early 2026 as part of a Planner update.”

This confirmed for us that something big is about to happen:

One temporary impact of this update was mentioned: “Convert a basic plan to a premium plan will be temporarily unavailable.” That would make perfect sense for the underlying service unification. It would have also made sense that more communication about the impact would have been shared with customers as we got closer to the mid-January 2026 and mid-February 2026 rollout. Which is where we are right at this moment.

The big blunder

This gets us to what I talked about at the start of this post. This week, when checking on whether there were any recent news about the Planner updates, I discovered this thread in the MS Tech Community: Microsoft Project Service Core Jan 2026 Update locked Plans table.

MS Tech Community post illustrating the impact of solution update 1.0.161.1772.

I know enough about Dataverse and the Power Platform managed solutions customization enforcement to realize something very serious had happened. I immediately went to my own tenant’s environments to check the status of those solution updates. I discovered that in the Default environment the update hadn’t yet been applied, whereas in a non-Default Power Platform environment it was installed already. This allowed me to take screenshots of what exactly the impact of this update was:

Before and after the update: msdyn_project (Plan) table becomes locked for modifications.

Before the update, I was able to add new columns, views, modify forms etc. on the Plan (Project) table. After the update, none of these actions were possible. What can cause such a thing? Simple: it’s a built-in feature of Power Platform designed to allow publishers of managed solutions to control what parts of their solution can be customized. This is what the docs say about managed properties:

It literally is a kill switch for customizations in customer environments. There can be valid reasons why partners building products on top of Microsoft Power Platform wish to keep certain areas of their solutions standardized across all deployments. When you know what you are doing and why, this is a legit platform feature. But when you as the creator of the managed solution just flip it on AFTER years of inviting customers/partners to extend things on top of your solution, it’s simply mayhem.

I can’t recall such a decision ever having been made by Microsoft before when it comes to their products. And I’ve been in this game for quite a while. I participated in the Early Access Program for Dynamics CRM 2011 that launched the whole solutions concept. Yes, I’m old and I’ve seen things. But never something quite as reckless as this.

Bug or a feature?

In the absence of official communication coming from Microsoft, the community has to support itself. Five days after the forum post, I haven’t yet seen anything in public from Microsoft about this. I have, however, heard from several credible sources that this is a bug that Microsoft is working on to get fixed.

But let’s look at it from the perspective of folks who are not well-connected and deep in the MS ecosystem. If you’re a customer or a “normal” developer who pays for Microsoft Planner licenses and tries to make it work for the task and project management scenarios it is sold for, will you know what’s going on? Will you even have confidence about the customizability option ever having been there for the Plan/Project table?

You won’t have any documentation to refer to directly, because MS has skipped most of that for these work management products. You don’t know what to search for online because the products have been rebranded many times. You won’t necessarily understand that custom fields in Planner are a completely different feature from adding a custom column to the Planner Plan table.

What do you think would happen if you opened a support ticket? What are the chances that it would reach a human in the MS org who understands what the issue is really about? I’d say: slim to none.

So where do people turn to? They could of course ask their M365 Copilot for an answer. And they would get the wrong answer:

Microsoft 365 Copilot answer to the user question about adding custom Dataverse columns to Planner Premium’s Plan table — and an incorrect answer.

Seriously, most people would just give up at this point and accept that it’s a feature that has always been there. Unless they were knowledgeable enough to use AI tools that go a bit further and get all the details, like Claude Opus 4.5:

Claude giving the correct answer: “Yes, you can add custom columns to msdyn_project at the Dataverse schema level”

I can’t help thinking that the original bug is also somehow related to AI tools. Because obviously there’s immense pressure inside Microsoft for all employees to demonstrate they are leveraging tools like GitHub Copilot / Claude Code in their work. So, when doing a major architectural change like the plan unification, there will surely be plenty of AI coding agents burning tokens for the development team. And all it takes is one rogue agent that produces an elaborate plan of how to meet the requirements — with no one noticing a tiny change in the isCustomizable setting of the Plan table in Dataverse.

I joked on LinkedIn about what the answer from the coding agent might be when the developer asks why the Plan table got locked down:

🤖 “You're absolutely right! Existing solutions depend on this setting. Let me go and revert the change and update the how-to-develop-planner.md instructions to make note of this."

I think this is a perfectly plausible explanation at this point. LLM coding capabilities have grown sharply in the past few months. People give them more and more autonomy because the results look convincing. And yet the pace of code changes that this makes possible is now overloading most organizations’ ability to set up guardrails to keep unwanted product changes from happening.

Why it matters

(Yeah, that’s an AI pun.)

Microsoft isn’t a $3.1T company because of its own software excellence. It’s all about the ecosystem. Partners ranging from solopreneurs like me to global system integrators like Accenture are what make the magic happen in the real-world, making the software fit the real-world needs of customers. We often hear how “for every $1 of revenue MS makes, the partners make ~10x” as proof of the deep connection between these parties.

So, imagine you are developing your own value-add service or a software product on top of Microsoft Planner. Then, imagine that one morning you wake up and you just can’t do it anymore. You’ve sold your software/projects to customers. You have commitments to deliver business application functionality and demonstrate the value of the MS platform, to prove you’re a trustworthy partner to the customer. What are you gonna say? “Oops”?

Microsoft partners with ongoing Planner work sharing the disruption caused by a key table getting locked down all of a sudden.

Things like this should not happen. Yet they increasingly keep happening and people are starting to think it ain’t just a coincidence. The badwill for the Microsoft brand is accumulating with every botched Windows update and software issues like this one with Planner. It is fueling the organic #microslop campaign where customers are rising against the relentless push for new AI features while the basic IT tools are degrading in quality.

The year of Microslop, 2026

Microsoft has a set of challenges ahead in 2026 to undo the damage to its brand and reputation that has accumulated in the past couple of years.

www.perspectives.plus/p/the-year-of-microslop-2026

I chose the clickbaity kill switch term for the subject line for a reason. If you live in Europe and your organization relies on big US clouds like Microsoft, this topic has recently been appearing in news articles and discussions quite often. People are increasingly thinking about their dependency on technology that could in theory be disabled remotely. The trust levels are not what they used to be.

At times like these, cloud vendors should be very cautious about making moves that further erode this trust. I even recall someone saying Microsoft runs on trust.

Before the public cloud and SaaS were mainstream, I was a CRM business specialist who needed the IT department to provide a set of Windows servers to run the new CRM software I was in charge of deploying to the organization. When I saw how Microsoft’s CRM Online (now Dynamics 365) made it possible to skip this and just provision a trial account for the service, I was sold.

Before that job, I was the marketing guy who got assigned the task of also managing all the IT systems of a small org. I inherited a set of Lotus Domino servers literally running in the cleaning closet. When I finally managed to complete the project of moving the Notes-based business software to Exchange, SharePoint and Dynamics CRM running on our servers that were not in the closet but in a rack managed by a hosting company, I was relieved.

Going through these experiences early on in my career, it seemed like the further away I could get from the servers, the better the outcome was for achieving value from them. Focus on the business processes, design business apps that support and automate them. Empower every user to become a citizen developer and build their own apps. Access data and tools from any device, anywhere. All made possible by the cloud.

Lately, I’ve seen how the cloud isn’t all you need. That there is value in having control over the computers that store your data and run your tools. And that it isn’t scary to work with command line tools instead of pretty web portals — because LLMs have our back

You can just script things

When I got my first PC, there was no graphical UI. There also wasn’t an internet from where I could search for answers on what to do when faced with the C:\> prompt in MS-DOS command line. Books, magazines, and later on BBS forums were filled with helpful information, though, so I learned to get around. Tweaking the settings so there’d be enough memory for my PC games and that the sound card would work for my Fast Tracker studio.

I’ve never enjoyed learning any specific syntax by heart, which must be one reason I never bothered to learn how to create my own programs. Writing code was for The Other People. I was motivated by figuring out what all these awesome tools programmed by others could do when put into use. I need to see things in action — or at the very least see a UI that presents the possible actions to me. Knowing what commands to punch into the black terminal window had none of that.

The flipside of this is that I’m also very picky about the UX. When the app gets in my way and forces me to jump through unnecessary hoops or refuses to show me the information it obviously should, you’ll hear me shouting the F-word very loudly. (Luckily my private office is pretty well isolated from the neighbors.) As a result, I often spend considerable amounts of time in a “there’s gotta be a smarter way” mode, researching for less stupid ways to achieve my goals.

AI chatbots are great at looking up very specific answers online to meet the requirements expressed to them in the prompt. The one thing they do (and which search engines don’t) is offer to write a script for completing a task. Because to a large language model it’s the most natural way to express a solution as a set of written commands. Based on the wealth of training data on command line syntaxes and API docs they’ve been fed.

This makes tools like ChatGPT and Claude a very handy partner to complement the shortcomings I have with being able to memorize specific strings. Sure, they do imagine things, yet usually the errors will be revealed upon trying to execute the scripts. The kinds of things you can do with just a PowerShell script rather than juggling dedicated apps and trying to manually process files is incredible. And if you need to make adjustments to the output or process for getting what you really needed, just run the thing again.

“Is It Worth the Time?” XKCD 1205 webcomic matrix of time saved vs. frequency.

The above XKCD matrix is about “How long can you work on making a routine task more efficient before you're spending more time than you save? (across five years)”. It almost makes me dizzy thinking how the practical equation has changed when LLMs allow us to prompt scripts for us. Note: I’m not talking about using non-deterministic GenAI for the task itself. It’s about using GenAI to create a deterministic tool.

The original 5-year spectrum of the comic is outdated. It certainly was a sensible threshold to illustrate the original point of how computer geeks often end up spending far more time on building the automation than what benefits could be reaped from it. That was an era when it was hard to get much done in less than 5 minutes if you weren’t a true expert in the domain.

Today, the tools that you could prompt into existence in just 5 minutes can do a lot. For a monthly routine task, you’d only need to save 5 seconds per run to have a positive ROI on time spent. Anything that takes a minute of your time on a monthly basis would be worth an hour spent with an LLM and a terminal window. The key takeaway is: even little things are worth a shot now. If it doesn’t work after a few minutes, just leave it be as-is and you’ve lost barely anything with the experiment (and you learned something about practical AI usage).

Most of this would still require a level of intimacy with raw scripts and dark terminals to get true benefits out of. Traditionally, it would have been hard to expect users who’ve spent their computing days inside apps to suddenly start working from the command line. The rise of tools like Claude Code and their popularity outside the professional coders seems to now be turning the tide at least a bit towards the dark side of blinking cursors. I wrote more about the power of the terminal UI (TUI) in my previous newsletter issue for the Plus subscribers:

The new bottleneck is apps

Instead of starting from a M365-like suite and adding AI, Anthropic pursued a "no apps" model and caught everyone's attention with Claude Code. Maybe all you need is text files?

www.perspectives.plus/p/the-new-bottleneck-is-apps

Your computer, trapped inside an OS

The wonderful promise with the cloud is that the computer is someone else’s problem to manage. Things may not always work the way you wish in SaaS apps, yet when something breaks down, you can just spend time elsewhere while someone up there in the cloud control tower will fix it.

When building the tools locally and taking ownership of the scripts and code, there’s no one else there to fix it. Unfortunately, this doesn’t mean that no one else could break your tools. Because that’s what’s been happening far too often lately with Windows updates. Microsoft can’t seem to get over all the quality issues that plague Windows 11 features and hotfixes.

Another week, another risk of your computer not being able to boot to Windows because someone at Microsoft forgot to test things properly:

Windows Update asking me to finalize the notorious KB5074109 update with a reboot.

It’s not any fringe issue with an exotic configuration. This video demonstrates how a brand new Windows 11 VM provisioned solely for testing purposes gets stuck with a bad update that can’t be resolved via any other route than resetting the PC. Friends of Linux are naturally sharing such horror stories as proof that they’ve made the right choice in the OS powering their own devices:

What can we do when a cloud service out there pushes yet another potentially destructive Windows update onto your PC? Three weeks ago I faced a BSOD loop on my main work PC that couldn’t be resolved via any other means than a full wipe of the C-drive and a new Windows 11 installation. I’m painfully aware of how much installation and configuration work is required after the OS finally boots up. I’ve easily lost at least 2 full working days in restoring my tools back to how they were.

I have naturally asked AI for assistance with this conundrum. While I have no way to guarantee that a full wipe of the system drive won’t be required again in the future, I can at least take more control over my PC via the command line. For example, getting exact data about the update status with Claude Code CLI is a breeze. It can suggest and try means to undo the damage of surprise updates, even if in this case nothing seems to protect my PC from the KB5074109 that has been installed and will be applied in the next reboot.

Obsidian notebook with my PC’s update log and installation status, as documented by Claude.

These days, getting all the apps installed on a fresh new Windows machine (or a wiped one) is a breeze with WinGet. I’m sure some IT nerds have been using this for ages already, yet an LLM makes this approachable for everyone. Claude will gladly catalog and group the apps you use into a script file that can be run whenever you need to start from scratch. And to keep it up to date, all you need to do is ask AI in plain English. Or again build this all into an automated process if you expect to need it often.

The CLI tools are powerful because they have access to your computer. And at the same time they are vulnerable to whatever happens to your computer. Because while tools like Claude or Codex run the model inference in the cloud, you still must have something running and configured locally.

With great power comes great vulnerability

The most extreme example of taking advantage of local tools together with cloud LLMs is Moltbot — formerly known as ClawdBot, before Anthropic’s lawyers got in touch with the developer. There certainly are other YOLO style research preview features out there from even the vendors. It’s just that Cla… sorry, Moltbot managed to go viral all on its own. It captured the attention of not only the AI cheerleaders but also techies that had been previously disappointed by what “agentic” AI products from big vendors were delivering.

Because vibe scripting your own virtual server is pretty simple these days, deployments of Moltbot started to appear on the cybersecurity radar, too. Because of how carelessly the servers had been configured:

“Clawd disaster incoming.” Post from @fmdz387, screenshotted via XCancel.

There has been no breakthrough yet on how to tackle the combination of extreme insecurity of naive LLM models following orders from anyone. So, even if the ports of personal AI servers weren’t left wide open, the problem still remains: if you let an AI with access to tools and your secrets read incoming email from the outside world, there’s nothing stopping malicious actors from giving orders to your server.

Agent 365: a computer for AI workers

Microsoft could offer useful service to address this very scenario. It’s the reason why I still have hopes of Agent 365 becoming a viable product, regardless of the numerous delays and false marketing claims surrounding the launch of A365 agents. Just because it’s not easy to make it work, doesn’t mean Microsoft couldn’t eventually succeed.