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:

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.

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:

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.

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.

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.

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.

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.

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?

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:

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.

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.

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.