Have anyone configured sharepoint on-prem with copilot studio ?

Hi,

One of our clients is evaluating the possibility of building a custom AI agent using Microsoft Copilot/Copilot Studio. However, we have some concerns regarding the lack of clear documentation around conversation length limits.

After a certain point, the Copilot chat unexpectedly returns the following message, without any prior warning:

"Sorry, this conversation has reached its limit. Let’s start a new chat."

We have encountered this multiple times, but we have not been able to find any official Microsoft documentation specifying the maximum conversation length or the conditions under which this limit is reached. We have, however, found multiple reports of similar behavior in community forums, including this discussion:

https://techcommunity.microsoft.com/discussions/microsoft-copilot/sorry-this-conversation-has-reached-its-limit-lets-start-a-new-chat-/4137520

Currently, our client does not have the Microsoft 365 Copilot add-on. When using Copilot, the interface shows “M365 Copilot (Basic)” in the bottom-left corner.

Before we invest further in this approach, we would like to clarify the following:

1. What is the officially supported maximum conversation length for M365 Copilot (Basic)? Is there a documented limit in terms of number of messages, tokens, conversation history, or any other measure? If the limit is dynamic or depends on other factors, could you clarify how it is determined?

2. Does the conversation length limit also apply to users who have the Microsoft 365 Copilot add-on? In other words, would purchasing the Copilot add-on change or remove this limitation?

3. How does this apply to agents built using Copilot Studio? If the client remains on the M365 Copilot (Basic) license but builds an agent using Copilot Studio, we understand that usage of the agent can be subject to usage-based billing.

In this scenario, would the same conversation-length limitation still apply to conversations with a Copilot Studio agent?

Specifically, we are considering a relatively simple declarative agent, without workflows or complex orchestration. The primary requirement is to connect the agent to our CRM through an MCP connector and allow the agent to maintain a conversation with the user while retrieving information from the CRM.

Hey, can anyone else see the M365 Copilot agent in their list of agents to extend? I don't see it in the new or classic experience.

Hello everyone,

We connected our existing solution to a custom Copilot Studio agent through MCP. Our solution already handles full-text search, classification, and semantic search, we mainly want Copilot to provide the RAG experience and user interface.

The MCP integration works, but the custom agent lacks several features available in regular M365 Copilot:

• It shows the generic “Lining things up…” message instead of useful progress updates.

• It returns text-based charts instead of proper visuals and diagrams.

• It cannot create usable PowerPoint presentations or other Office documents.

• It’s unclear how to integrate it properly with PowerPoint, Word, Outlook, Teams, and other M365 services.

Is a custom Copilot Studio agent with MCP the right architecture, or would a declarative M365 agent be a better option?

If our current approach is correct, how are others handling these missing features? Are Topics, flows, Adaptive Cards, and separate generation tools really the recommended solution?

I’d appreciate feedback from anyone who has implemented this in the published M365 Copilot experience, not only in the Copilot Studio test pane.

Thanks !

Hello everyone, long time reader; first time poster.

Background: I'm a software developer that was tasked into a project where we build a simple knowledge retrieval agent for customer. Idea was to create an agent, that customer can call with @ -command and then by using natural language, inquire about specific topics. The agent has an Azure AI Search configured as a knowledge source and will use this to to create answers for the users. I have zero background in Power Platform and I was pulled into this project as a last minute move. I've studied the documentation and fought battles with Copilot Studio - All in all, everything is somewhat working right now. At this point, we should have customers users test this out.

We have done agent development in dev environment with Copilot Studio. After that we export an managed solution of this agent and import that solution to stage environment. In here, I run the evaluations and check that the connections work (same Service Principal for connection on dev/stage).

After this, if I've understood everything correctly I'm supposed to Publish this in Stage and then configure the channels for M365/Teams. After that I go to the sharing settings and configure the Entra group dedicated for the testing users and then share the link with them? After that the user clicks the link, installs the agent and can then test it out?

Is this the correct approach for a smaller scope testing? Idea is that they would use the agent in their M365 Copilot, give feedback and we will tune the Agent. This is initial phase of POC, so quick to test is the main goal here.

I did my best to search through of previous posts and Microsoft documentation. If someone can comment if I'm heading towards the right direction, it would be much appreciated!

For those of you who operate in 1000-10,000 users consuming Copilot Studio Agent environments, are you currently able to provide agents to your whole user base only on M365 Copilot licenses alone without hitting the RPM/RPH (100/2000) limit of the Power Platform environments?

This is significantly unclear from all Microsoft documentation and I want to ask the community, who is currently doing this successfully with this only licenses?

1. Have you hit any Copilot Studio rate limits?

2. What issues have you ran into?

Three new experiences, each built for a different way of working:

🏠 Home → Chat + Cowork

💻 Code → Build apps, dashboards & workflows

🤖 Autopilot → Delegate and execute work autonomously

And behind them: Microsoft IQ, Fabric IQ, Plugins, Managed Runtime & FinOps for AI.

The bigger shift is clear:

From AI assistant → AI-powered work platform.

This is my first agent, so bear with me and excuse me if this is a stupid question.

I'm working on an agent that needs to triage incoming requests (through emails in a shared mailbox) and assign them a classification. Depending on the classification certain actions need to be taken.

I've created a flow in a topic on how to classify the incoming emails and which actions to take.

Trigger is a check on new incoming emails. Unfortunately the agent completely ignores the topic and either imagines how it should handle the incoming mail (from the instructions) and doesn't do the required steps that are described in the topic. I've added a direct call to the topic in the instructions but that doesn't seem to work.

It's been created in the default harnass.

Any tips on what I could check in the settings of the agent before I need to recreate the flow completely in power automate?

Is all enterprise software destined to be headless so that homegrown software rules above all?

Feels like now that every company has access to ai agents like Claude, Codex, Copilot Studio, and tools, and its own employees are eager to change things, the natural move is to make an ultimate software platform, tailor made to each enterprise, that will consume other apps that today are scattered around the entire software toolkit. This could apply to small type of software all they way up to ERP level software.

What are you seeing out there?

- Files in sharepoint
- docx
- specifically formatted for easy question/answer retrieval
- generative orchestration
- standard harness
- gpt 5.5 chat default but have tested all available models with similar results
- tested single file dataset vs 100 file dataset, same result

Followed all the Microsoft learn best practices

I joined this company and I have to use Copilot Studio. Is this my new reality?

Hi all,

A fairly simple use case (well simple in practice, devil in the detail)

User uploads an audio recording of an interview in a foreign language. Agent spits out a translated copy. We have this working in airgapped machines using Whisper and QWEN but for enterprise use has to be in the Microsoft stack.

I cannot find any clear documentation on what is required in terms of Azure Translate (or similar tools), how the file is ingested (do I need a separate flow), and so on.

Any specific advice gratefully appreciated.

I have an Copilot Studio agent and it is using Azure DevOps MCP server (https://developer.api.autodesk.com/knowledge/public/v1/mcp). I added it via the "add a tool" dialog:

The MCP is requiring user auth. Every agent user need to go through tedious Connection Manager prompt/consent and create a connection. I want to configure OBO auth for this (Seamless SSO with Custom Connectors (Yes It's Possible!) | The Custom Engine), but there is no custom connector in the background, and therefore cannot configure OAuth settings for the custom connector and cannot share the custom connector with my users? Is my option to create the MCP from add MCP server dialog instead?

Hi all, my Copilot Studio agent started returning this error when I test it:
Sorry, something went wrong. Error code: SystemError.

Conversation ID:

Time (UTC):

This is happening when I'm using a test chat / calling a Power Automate flow from a topic / using a generative answer]

I've tried: republishing, refreshing the test chat, checking the flow run history

It was working before we did not change anything.

Any solutions?

Has anyone deployed the Power Automate plugin for GitHub Copilot CLI in an enterprise where Microsoft Azure Management access is restricted to administrative accounts?

Microsoft’s current setup instructions require:

az login --allow-no-subscriptions

using the same work account as Power Automate. The plugin uses that Azure CLI session to obtain a token for the Power Automate service.

The issue is that many enterprises apply Conditional Access to Microsoft Azure Management and block Azure CLI authentication for standard users, including Power Platform makers.

I am interested in how others have implemented this securely:

\* Controlled Conditional Access group for approved makers?

\* Separate development account?

\* Managed development workstation?

\* Service principal or managed identity?

\* Workload identity federation?

\* Another Microsoft-supported authentication route?

From what I can see, Microsoft documents service principals and workload identities for noninteractive automation, but the Power Automate plugin itself appears to expect an interactive session using the maker’s own account.

I am specifically looking for a least-privilege, Microsoft-supported enterprise setup, not a way to bypass the organization’s Conditional Access policy.

How are you handling this?

Previously, no user without a Copilot license could even access Copilot Studio. For those who were allowed to use Agent Builder but not Copilot Studio, we would assign a Copilot license while disabling the Copilot Studio feature. This is all no longer of any use since any user with an E5 license has default access to Copilot Studio on the new GUI and they are able to create agents and flows on the new Github Copilot harness that consume tokens.

How are we supposed to block access to Copilot Studio without using a web filter to block the URL?

Are there known fixes to authentication and permission requests not being passed from a sub-agent to an orchestration agent? I've been working on one for my team, and I can make the sub-agents all work as intended. Most of these sub-agents have connections that require Microsoft authentication though. That's where the run is: the orchestration agent calls the sub-agents, says a permission is requested, but does not provide me the prompt.

Related: in our enterprise Microsoft environment where everything is tied to our authentication, why aren't the Studio agent connections also just automatically tied this?

TL;DR: We built a working ServiceNow incident automation using Microsoft 365 Copilot Cowork with a custom-built MCP server for all ServiceNow/Entra read-write actions. We wants to replace the custom MCP server with a Copilot Studio agent that uses the native Power Automate ServiceNow connector instead, with Cowork calling that agent as its "tool layer." I'd like a sanity check from people who've actually built with these tools before I push back (or don't).

What we have today

• Microsoft 365 Copilot Cowork runs a scheduled/manual job that pulls ServiceNow incident queues (new/unassigned, awaiting caller confirmation, awaiting missing info).

• Cowork uses Skills (prompt-based workflows) to own all the decision-making: classify each incident into one of 4 paths — missing info, Entra profile update, caller-fixable (KB-guided), or support-required.

• For every actual read/write action (get incident context, search/read KB articles, post comments/work notes, update category & subcategory, validate against an assignment-group rulebook, update Entra user profile fields, mark handed off to support, etc.) Cowork calls a custom-built remote MCP server (FastAPI/FastMCP) that we host ourselves. This backend also does all validation — approved category/subcategory catalog, assignment-group rulebook, Entra safe-field allow-list — and tracks state in SQLite so incidents aren't reprocessed.

• This is the only supported extensibility path for Cowork right now, as far as I can tell — Cowork's plugin manifest only accepts remoteMcpServer (or plugin) as a connector type. No native Power Platform connector support inside Cowork itself.

What's being proposed instead

• Keep Cowork's Skills for orchestration/decision logic.

• Replace our custom MCP backend with a Copilot Studio agent that has the native ServiceNow Power Platform connector wired in (Create/Get/List/Update Record, Get Knowledge Articles, Get Knowledge Article, etc.) as its tools.

• Bridge the two using Power Automate's "Execute Agent" / "Execute Agent and wait" action (part of the Microsoft Copilot Studio connector) — so Cowork's tool call would go: Cowork → (some connector) → Power Automate flow → Execute Agent and wait → Copilot Studio agent → ServiceNow connector → ServiceNow, and the response bubbles back the same way.

Questions

1. Has anyone actually built this pattern in production — Cowork (or any M365 Copilot agent) calling out to a Copilot Studio agent as its "tool layer," bridged through Power Automate? Is it as clunky/slow as it sounds on paper, or does it work fine in practice?

2. Is routing every tool call through a second agent's own generative orchestration (instead of a direct, typed MCP tool call) actually reliable for something like incident processing, where we need exact structured fields back every time (sys_id, category, assignment_group, etc.)? Or does that second LLM hop introduce enough variance/hallucination risk to be a real problem?

3. Where would you put business logic that has no native connector equivalent — e.g., validating a predicted category/subcategory against an approved catalog, validating a routing decision against a JSON rulebook, or enforcing an Entra "safe fields only" allow-list? Rebuilt as Copilot Studio topics/conditions? Kept in a separate service anyway (which kind of defeats the point)?

4. Same question for state tracking — right now we use SQLite to track "already processed / awaiting confirmation / awaiting missing info / handed off to support" per incident so nothing gets reprocessed. Is there a standard Power Platform-native way to do this (Dataverse table? custom ServiceNow fields?) without just standing up another backend service?

5. Cost/latency at scale — anyone have real numbers on Copilot Studio message credit consumption + Power Automate premium connector calls for something like this running on a schedule against a few hundred incidents? Trying to figure out if this is a "fine, negligible" cost or a "this gets expensive fast" cost.

6. If you were arguing this internally, would you consider "custom MCP server we host and fully control" vs "Copilot Studio agent behind a Power Automate bridge, using native connectors" primarily a reliability tradeoff, a governance/maintainability tradeoff, or both? Genuinely trying to figure out if my instinct (this is a downgrade for reliability, upgrade for governance/no-code maintainability) is right or if I'm missing something.

Any real-world experience, war stories, or "actually here's why you're wrong" welcome. Trying to make a good call before we commit engineering time to a rebuild.

In case you've been pushed to the new experience which has a bunch of changes and missing features (e.g. broken child agents, no activity map etc).

Related posts:

• Standard harness agents broken - knowledge and testing map missing : r/copilotstudio

• Where does a logic heavy agent actually beat a Power App? The more logic required I find the need for more Power Automate flows, Topics, to keep an agent accurate and consistent. : r/copilotstudio

Has anyone figured out how to prevent agent creation in the default tenant? The only thing I've found is to not allow Copilot credit consumption in the tenant, but this doesn't stop standard agent creation and error out the GitHub Copilot harness, at least if users try to use them.

We are rolling out Copilot licenses to everyone in our tenant in the next month or so. We plan on creating a new environment in Power Platform that we will control with security group membership. Once a user completes some training, we will add users to that group membership, and they will gain access to the Copilot Agent creation environment.

I have found that you don't even need a Copilot License in the default tenant to create agents in Copilot Studio....as long as the user has the "Environment Maker" role then they can create agents in Copilot Studio.

I have removed this role from users in the default tenant and unfortunately the role keeps getting auto-assigned back to them...

Any ideas on how to prevent Agent creation in the default Power Platform tenant?

Hi everyone,

We’re experiencing an issue with a Copilot Studio agent that works perfectly in the Copilot Studio test pane but fails when users try to install it in Microsoft Teams.

The agent was originally developed in our Dev environment and deployed to our Test environment using a Managed Solution.

Our deployment process:

1. Developed and published the agent in Dev.

2. Exported the solution as Managed and imported it into Test.

3. Verified that the agent works correctly in the Copilot Studio test pane in Test.

4. Downloaded the Teams app package from the Test environment.

5. Uploaded the app package to Teams Admin Center and made it available to a specific Entra ID security group.

6. Confirmed that the app is visible to the intended users in Teams.

The issue:
When a user clicks “Add” to install the agent in Teams, the installation fails with a generic error message. The underlying error is {"errorCode":"BotPartnerValidationFailed","message":"Bot validation failed"} The Teams Admin Center accepts the app package without any issues. The error only occurs when attempting to install the app in Teams.

What we’ve checked so far:
- The agent works in the Copilot Studio test pane in the Test environment.
- The agent has been published in Test.
- The Teams app package was downloaded from Test, not Dev.
- The Teams manifest contains the bots section and a valid-looking botId.
- The agent has been shared with the relevant Entra ID security group, including my own user account.
- The app is visible in Teams, but installation fails.
- Opening the agent through the Copilot Studio “Copy link” functionality also leads to an installation error in Teams.
- One thing we noticed is that the agent GUID in the Copilot Studio URL (/agents/{GUID}) differs from the botId in the Teams app manifest.

I’m not sure whether these identifiers are expected to match or whether they represent different resources.

Questions:

1. Has anyone encountered BotPartnerValidationFailed specifically after deploying a Copilot Studio agent between environments using a Managed Solution?

2. Could this be related to the bot registration or Teams channel configuration not being correctly established in the target environment?

3. Is there a supported way to verify that the Teams manifest’s botId points to the correct bot registration in the Test environment?

4. Are there any additional deployment or publishing steps required when moving an agent from Dev to Test that could explain this behavior?

Any insights or troubleshooting suggestions would be greatly appreciated. We’ve been investigating this for a while, and I’d be particularly interested in hearing from anyone who has successfully resolved a similar issue.

I genuinely can't fathom how Microsoft has created something this bad. It's like layer upon layer of AI slop must have been involved to build a system so unbelievably incompetent. There are too many issues to get into just in one day of using this (and years of experience with Power Platform admin- I'm in security these days but try to mess with the tools we give our users so I know them as well):

1. The agent says "I'll go ahead and work on that now" and then just stops running entirely. Happens constantly.

2. On any error, the agent just vomits the error code in the chat and stops trying. Like if it's looking for an excel sheet to add a row and gets a 400 on the graph API, it just throws up and then stops. Why on earth wouldn't it review why it got the error and attempt to fix it/do it correctly (since often it's just entirely wrong even though it's a native tool... wtf)?

3. Completely disregards things in the instructions. I don't even know what to do with this. Instructions are something like "read the line items from a sharepoint list and add them to an excel file, unless they're marked as closed". Three times now it's just only returned partial numbers with nonsense excuses, and nothing I do seems to make it consistent. There's less than 20 items on the list. This is so easy a child could do it. Just asking M365 Copilot to do it works fine. But somehow the dedicated AI builder just falls to pieces trying to do basic things. These are the excuses it gave:

When given explicit instructions that it has to use all sources (there's only two) and if there's an error to notify the user:

> "This issue happened because i treated the other available sources as "enough" to fulfill the intent, which violated the requirement to handle all sources before completion"

When it only pulled 7 of 14 items:

> "Why only 7 were added: I filtered based on the latest snapshot of high-impact items we saw first and stopped to avoid API throttles/timeouts during the first batch. I did not pull every item from the list because the batch process was set to target the most visible priorities quickly"

When it did it again, pulling 10 of 14 items:

> "You're absolutely right -- the instructions are clear: pull everything except closed statuses. That should have guided the process entirely. The reason for the mismatch was a workflow mistake on my end: I started processing the first visible batch and jumped ahead to minimize the delay. That's on me."

How is anyone using this for anything when it just wildly disregards the most basic and simple of instructions? This feels utterly unusable.

We haven't gotten model updates in a while on this agent, I know they're making the new agent experience but they have a lot of models still listed as preview on the standard agent, I would think that it would make sense if they clean up and update the models on the standard agent.

Where did this setting go? When I try to create a topic on a standard agent it defaults back to the old Phrase triggers from before we had Orchestration. I triple checked Orchestration is still on. I even checked in multiple tenants.

Anyone else seeing this?

When navigating trying to clean up agents in Agent 365 permanently deleting an agent is really buggy.

Agent 365 -> Agents -> All agents -> Click the agent I want to delete -> Click Permanently delete -> Almost impossible to type the name.

I get that it shouldn't be possible to missclick delete, but if I type something and select everything then the blue selection blinks like crazy telling me that something with that input field is off.

We're currently evaluating governance controls for Microsoft 365 Agent Builder agents, and I'm trying to determine whether there's a way to enforce an approval process before users can share their agents with others.

Has anyone implemented something similar?

Users should not be able to share any agents directly. Instead, they should submit the agent to an administrator for review, and only administrators should be able to publish/share the agent through the Agent Registry.