After merging the business and consumer Copilot products during the summer, Microsoft is proceeding to the next stage of the Super App plan. Before we get to the part that’s most interesting for the business apps crowd, it’s worth mentioning the changes that have been a public secret / obvious direction for some time:

With company leadership blog posts saying out loud how “we’re not the flashiest AI company out there”, it sounds like Microsoft has decided to double down on what they’re good at. Which means pretty much surrendering the generic consumer AI market to ChatGPT, Claude and Gemini. Two years ago, “The new Copilot” initiative tried to build a personal AI companion for everyone. This era is now over and it’s time for the AI built for work.

It makes a lot of sense to focus on the places where customers are already interacting with your products, instead of slowly suffering in all the markets while trying to cover everything. Last fall, the leaked numbers for M365 Copilot adoption rate of 2% after 2 years led me to write a piece saying the product was a commercial failure. Many people in the ecosystem didn’t like that kind of perspective being shared online. Me, I didn’t like how many partners kept pretending things were going just great and that customers were just “holding it wrong” if they didn’t see the magic.

Now, Microsoft 365 Copilot is no more. As a product name, that is. The SKU itself remains in place and a per-seat subscription will be sold by Microsoft, in addition to the Copilot Credits based services billed by usage. The documentation pages have been scrubbed to remove mentions of “Microsoft 365 Copilot” as the name of the app, making especially the transition guidance for consumers a highly confusing thing to read:

Aside from removing the different product variants and focusing on Microsoft 365 subscribers (business and consumer), Copilot is also expanding to new areas. In the previous newsletter issue I introduced the Managed Apps concept of how Copilot Cowork and Copilot Studio users can generate apps without touching Dataverse or any Power Apps tools. That issue is definitely recommended as prior reading before proceeding further.

Once we understand how these prompt-to-app scenarios are now positioned as part of Microsoft 365 services, it’s time to dive deeper into the implications for the ecosystem. Although the new Copilot Code tab will be positioned as the primary first-party way of creating Managed Apps, it is not the full story. The real agenda is in turning Copilot into a platform for hosting apps built with other AI tools.

Microsoft’s first experiments for building apps with an agent in Copilot last year were “unmanaged”, such as the App Builder agent that I didn’t rate too highly in my review. They really were just demos to show “hey, our AI can do vibe apps, too!” This time around, Microsoft has actually invested time in building something sensible behind the UI layer. Which is of course well in line with the “AI built for work” positioning of Copilot’s latest reincarnation.

The new positioning reads a lot more like the kind of Microsoft service IT departments are looking for. From the announcement blog post:

This addresses the real need that arises the minute someone has prompted Claude to generate a nice-looking app to support their very important and highly unique business process. How and where do you deploy it? If IT cannot give a decent answer in that moment, it’s the shadow IT phenomenon all over again as savvy business users find ways to share their apps on anything that opens from a URL.

The problem is quite real, given how popular the prompt-to-app generators like Lovable have become. With a $600M ARR and two-thirds of Fortune 500 companies using Lovable, there’s a sizable enterprise audience for these apps that were never designed for an IT-governed environment like Power Platform. Which is why Microsoft has now planned a model where it supports third-party authoring experiences to create Managed Apps:

The CLI, the SDK and the host are all designed to invite non-Power Apps artifacts to come and live within the admin walls of Microsoft’s cloud. The idea is to serve various audiences of app builders without requiring them to make an upfront conscious decision of the technical details behind the apps.

The citizen developer may start creating them via Cowork. The low-code developer might create apps from within Copilot Studio. The professional developer could use VS Code or GitHub Copilot CLI to generate them. And then, the user of a third-party app builder who simply picked the best tools for the job to create their application would in the future be allowed to deploy their creation to run inside the Copilot Managed Runtime.

The launch post included this quote from Lovable:

What we still need from these third parties is to introduce actual support for the SDK in their products. It’s not exactly a drop-in replacement for what the Lovable Cloud currently offers. Their latest TanStack Start framework for apps, Cloudflare Workers-based deployment, the Supabase back-end — all those pesky technical details need to be handled differently if developers want to run the apps inside Copilot Managed Runtime instead. The same will be more or less true for Replit, Bolt, Base44 and others.

Then there’s the whole governance layer that’s intended to keep Managed Apps secure by default. Which is all about enforcing more restrictions than the aforementioned products make the vibe coders worry about. It is more than likely that the default policies inside Microsoft’s developer environments are going to clash with what apps built on other platforms expect to be able to do. Such as these Content Security Policies:

CSP is essentially a guest list for resources the app’s browser is allowed to load. For instance, when I was converting my Lovable-built Event Decks app in last week’s example into a Managed App, the thumbnail loading for decks got blocked thanks to CSP in the Default Environment Group. The img-src directive has a default setting of 'self' data: <platform> and that wasn’t letting in non-SharePoint URL data. These are things low-coders have rarely needed to specify, so for most of us CSP configuration in Power Platform is a new topic to read up on.

My favorite topic, licensing, is just getting more and more interesting. Like we already established last week, Copilot Credits will be required for both building and using the apps. Unless the user already has Power Apps Premium, in which case usage is covered. The SDK docs contain this section on licensing options:

Okay, so we now have the price point for API calls at roughly $1 per 1k. The docs don’t specifically state what constitutes an API call on this runtime. Given how we’ve never even reached the final conclusion on what is and isn’t consuming Power Platform Requests, expecting the details to be documented at this point is not realistic.

When it comes to licensing, the devil is always in the details, though. What wasn’t explicitly stated anywhere was whether that 0.1 Copilot Credit payment covers every connector, such as Dataverse. So, I reached out to Ryan Cunningham on LinkedIn and he confirmed there is no standard vs. premium divide in connectors when it comes to Copilot Managed Runtime:

What does this mean? Well, one way to read it is that we finally can consume Power Platform premium connectors as a true pay-as-you-go service like Azure. Instead of having the “touch it once and that’s $10 per month per app” style PAYG that the Power Apps licensing previously offered. That is potentially a huge deal for apps needing to be distributed across the tenant for light touch scenarios of an unknown number of users (say, HR forms).

We shouldn’t immediately draw conclusions that every multiplexing clause has been nullified, based on a LinkedIn comment from a MS leader. Keeping an eye on the licensing guides wording and how it evolves around the runtime scenarios is very much recommended. I’m certain Microsoft isn’t looking to just surrender all those sweet Dynamics 365 enterprise seats in exchange for UBB. Because “why don’t we have both?”

How the CLT (Copilot Leadership Team) is framing this latest round of reimagining Copilot is designed to address the audience that has already seen how AI can be put into use in their professional and personal lives. This is less about the “every MS product must have a Copilot” mandate from two years back that assumed adding an AI chat sidecar to existing software would somehow deliver value. Now, instead of passive Office workers, the users are seen more like potential makers again.

The ambition level for this audience is higher than merely wishing AI could create decent slide decks for them. They’ve seen countless posts on LinkedIn from their peers about amazing vibe coded tools created over the weekend and are thinking “I should be able to do this, too, otherwise I may get left behind”. What better way to address the FOMO than switching to the new (Frontier preview) tab called Code in their Copilot:

When Power Apps arrived ten years ago, it introduced apps as a new unit of work that non-developers could create. More recently, Microsoft has tried to make everyone believe apps were a thing of the past and agents were all you should focus on. This disconnect between what tools people use at work vs. what the software vendors were asking them to use resulted in tone-deaf decisions and hostile UX changes like hiding all the Office app icons as far away as possible.

While creating your own agents in M365 Copilot has been a thing for a while now, I bet most users don’t really yet see that much value in creating slightly personalized chatbots for themselves. For instance, I personally still have zero useful custom agents in my Copilot that I’d use for real work instead of demos. They’re great in theory, yet still hardly a replacement for the core tools of information work.

Code is The Real UI for AI. It is what allows creating digital tools that perform tasks and present information to us in an exact and predictable way. Now when there is a commercial model in place for Microsoft to offer new tool creation and hosting via Copilot Credits, the ambitions of the user and the vendor can once again align better. Introducing the idea of creatively using code to the masses that hadn’t been given a real chance to try it before.

The battle for the next frontier in AI products is all about convincing customers they should let the agents do work for them autonomously. The recent media reports hyping up Meta’s Muse agent are shadowed by the fact that the architecture behind it is about provisioning incredibly insecure VMs for anyone to crack open and use as they please. While having humans in call centers secretly performing tasks the AI cannot do. And when the agent can do things like message other users, it might leak your home address to strangers and invite them over without ever asking you.

It’s exactly the level of security and privacy I would expect from Meta, and the reason I try to avoid Zuck’s services as much as possible. For Microsoft, the bar for securing both the systems and the customer data is considerably higher. There’s the constant pressure to show how they’re not falling behind the frontier AI labs in terms of service innovation while still being the adults in the room with big contractual liabilities from pulling the same reckless stunts as the new kids. Sometimes this results in “we’re proud to announce our possession of this cake, which we have also eaten” type of communication: