If there’s one thing Microsoft loves, it’s calling many technically different things with the same name. Within the BizApps domain alone, we have plenty of examples, such as:

Sometimes things improve over time. We may no longer have separate OneDrive clients for Business and Pleasure. Skype has been put to rest on both the business and consumer side. Yet the practice of “reimagining” how different products would actually live under the same brand umbrella is very much ingrained in how MS operates.

Last week, we saw Copilot Studio get this treatment. The familiar Copilot Studio tooling that evolved from Power Virtual Agents is now called “Copilot Studio full experience”. Whereas what used to be Agent Builder in Microsoft 365 Copilot is now “Copilot Studio lite experience”. Simple!

The community reactions to this have ranged between “exciting news!” to “oh no, here we go again”, as is often the case. I think this one comment perfectly captures the dilemma I see with the direction taken with Copilot Studio branding here:

Another can of worms is how Microsoft doesn’t want to consistently refer to the lite experiences as “Copilot Studio lite” in its own documentation. To demonstrate this, I created a short clip to show how the MS Learn pages have been updated in recent days. By visualizing the individual commits to the Learn GitHub repo via the handy Git History tool, we see that it’s a conscious decision from MS documentation team to now publish ludicrous sounding statements like “Copilot Studio agents don’t support Dataverse as a knowledge source” for all search engines and AI tools to index and offer to users.

The biggest issue with these rebranding initiatives tends to be that on the surface, it only takes one announcement to harmonize the naming (plus countless MS Learn and documentation updates, of course). Behind the scenes, though, it can take from years to infinity for technical unification to happen. Let’s look at the current Lite and Full sides of Copilot Studio as they are today in September 2025 and explore the aspects that are easy to miss from just reading the announcements on social media.

Microsoft Learn now includes a page for choosing the right Copilot Studio experience. It starts with a simplified decision tree like this:

The first question about external users is easy to understand. The second one talking about “a broad scope” for the agent already makes you wonder what the definition should be (how many users is “broad”?). The third one is even more vague: what’s “a complex workflow” for an AI agent at a time when no one really is using AI agents at work yet?

The fourth question in the decision tree is the most accurate piece of information included. If you need non-production versions of your agent, role-based access control (would the target audience of this tree know “RBAC” stands for that?) or telemetry, you should avoid the Copilot Studio lite experience. According to MS, its target audience is this:

The example here raises the question: why wouldn’t SharePoint agents be sufficient for this? Indeed, this remains by far the most likely source of those 3 million agents created in the Microsoft cloud in the past fiscal year.

Copilot Studio lite experience seems to have a similar target audience as SharePoint agents. There are even more similarities to it once you dive deeper into how the resulting agent artifacts are actually managed in the MS cloud. Meaning, how little they have to do with what we traditionally thought was Copilot Studio.

I went through the updated documentation and checked what the current UI inside Microsoft 365 Copilot for the “create agent” button offers today. This table presents what I think are the key differences — some of which MS isn’t too keen to point out in their docs:

Let’s start with the key difference: Copilot agents created in the lite experience live inside Microsoft 365. Copilot agents created in the full experience live inside Power Platform.

The agent maker (let’s not use the deprecated “builder” term anymore) UI is the most unified experience of these Copilot Studio versions. You’ll get the same simplified routes to creating a new agent via either describing through chat or configuring via GUI in both.

What happens after that screen is, for the most part, different between lite and full experience Copilot agents. The fun part? At least today, that choice of lite or full Copilot Studio is irreversible. You cannot convert a Copilot agent from lite to full.

Given the entry point into building new agents is very prominent in the cursed modern version of what used to be Office.com home page of M365, most regular users will end up using the Copilot Studio lite experience. While the simplified environment may well encourage users to create more agents (and drive that all-important MS internal KPI up), there’s a potential admin and governance price that customers will pay for this direction.

The lite experience of Copilot Studio reminds me of Dataverse for Teams. Back in 2020, it was designed to lower the barrier for Power Apps users without premium licenses to discover the benefits of not building their apps on SharePoint Lists. However, the limited nature of the “free” offering inside Microsoft Teams meant that benefits like model-driven apps or API access to the database tables or environment settings were missing. DV4T was never developed beyond the initial release and the “Teams as a platform” story was discarded in 2022 once seeing GPT-3 convinced Satya Nadella that GenAI was the future to bet the company on.

It’s perfectly possible the lite version of Copilot Studio could suffer the same fate as Dataverse for Teams. In fact, given the rate of change in how elements of the AI tooling story keep getting rearranged in MS product portfolio, I’d be very surprised if this terminology from September 2025 would still be valid a year later.

The technical differences between the two Copilot Studios are actually far greater than the two Dataverses of “lite” (Teams) and “full” (XRM). Lite agents end up living in a black box managed by Microsoft, inside Cosmos DB. The utterly crazy part about this is that when the “Microsoft 365” Power Platform environment was originally provisioned silently into every tenant, it was said to be a dedicated environment for Agent Builder agents!

Now, it ended up becoming the storage space only for Copilot scheduled prompts. I did take a peek inside the Dataverse tables of this environment in my earlier article about the secret life of Copilot scheduled prompts, but I didn’t find any references to the lite Copilot agents I had built in my tenant. Later, a Microsoft representative confirmed my suspicions that the plans for migrating Agent Builder agents from Cosmos DB to Power Platform environments were put on hold.

As of now, we are left with a single-purpose environment called “Microsoft 365” that solely exists for Copilot scheduled prompts. They are not called agents, though, regardless of the fact that via their scheduling ability they demonstrate more agency than chatbots you need to interactively call when building Copilot Studio lite agents. You can only view the environment contents as an admin, but not modify anything, as I demonstrated in the YouTube video for my previous newsletter issue:

Since this environment can be deleted by an admin, but it gets reprovisioned whenever a Microsoft 365 Copilot (premium) user creates a scheduled prompt, I don’t currently see any way for MS to take advantage of it for scenarios beyond this one single feature. Unless they once again change the purpose and admin capabilities for the environment. Right now, nothing exists there that would show up in any tenant-level admin dashboards.

When rushing to offer customers as many ways to as possible to create things that are called agents, Microsoft has clearly rewarded their product development teams for launching features that A) make users open Copilot UIs (driving up the MAU) and B) encourage them to click “add new agent” (because there needs to be way more than 3M new agents created in the next fiscal, obviously). The administration story has been in the “we’ll figure it out later” bucket.

How this aligns with the “Prioritizing security above all else” memo from Spring 2024 is something each customer organization needs to judge for themselves. While we all hope that MS only launches products and features that adhere to its own Secure Future Initiative (SFI) principles, the smart thing for customers to do is to assume anything built with an LLM behind the scenes is vulnerable to unsolved problems like prompt injection.

Is Microsoft doing everything it can to prevent data breaches happening once customers adopt Copilot tools for communicating with the outside world? Given how its own flagship examples of how to leverage Copilot Studio in customer service processes exhibit avenues for prompt injection attacks, we can rightfully doubt that. Features with names like “prompt shield” sound fancy, yet security researchers have no problems getting around them and leaking CRM data to external parties by simply sending customer support an email message that Copilot Studio agent then reads:

So, it would be neat for Microsoft customers to have a full 360 view of the agents built and operating inside their tenant. Back at Ignite 2024, the Copilot Control System was introduced as “a collection of IT capabilities to enable IT to confidentially adopt and accelerate the business value of Copilot and agents”. If that sounded more like concepts of a plan than actual platform features, I have to agree with you.

Almost one year later, how’s this system coming together? Well, there’s a comprehensive set of presentations about CCS under the Microsoft 365 Copilot Adoption website to keep you busy for a couple of days. Me, I prefer to skim the decks and instead look at the real product UIs to understand what the decks are NOT saying. Let’s explore CCS from the perspective of this newly introduced lite vs. full Copilot Studio experience next.