Agent Credit Limits and Alerts - Copilot Studio
Hi everyone, We're evaluating the use of Agent Credit Limits and alert notifications in the Power Platform Admin Center as a way to control unexpected Copilot Credit consumption. Recently, we had an agent consume 668k Copilot Credits in just 3 days, which raised concerns about how quickly usage can grow before administrators become aware of it. My questions are: How frequently is Copilot Credit consumption evaluated against an agent's credit limit? Are alert notifications generated in near real-time, or are they dependent on the same reporting pipeline used by the consumption reports? If an agent reaches its configured credit limit, is it automatically turned off or blocked from further consumption? Given that consumption reports often appear to refresh hours later (or even the next day), can alerts also be delayed? If there is a reporting delay, is there a risk that an agent could significantly exceed the intended limit before administrators receive a notification? What is the recommended approach for preventing large unexpected consumption spikes in production? Has anyone successfully implemented a governance model that provides more immediate protection against runaway usage, or are the current credit limits and alerts primarily intended for retrospective monitoring? Thanks in advance for any guidance.Copilot Studio agent suddenly stopped working in Teams
Hello, I've run into a strange issue with a Copilot Studio agent and I'm trying to understand where to investigate next. The agent is published to the "Teams and Microsoft 365 Copilot" channel and was working normally in Microsoft Teams until recently. The agent still works correctly in Copilot Studio. The agent still works correctly in Microsoft 365 Copilot / Copilot Chat. The issue only occurs in Microsoft Teams. What happens in Teams: Messages can be sent to the agent. No error message is displayed. No response is returned. Most importantly, no session is created in Copilot Studio (Analytics / Observability). Because no session is created, it looks like the message never reaches the agent runtime. What I've already checked: Republished the agent. Reinstalled the Teams app. Verified the Teams and Microsoft 365 Copilot channel configuration. Checked permissions and sharing settings. Checked Teams Admin Center configuration. Tested in both Teams Desktop and Teams Web. Reviewed Microsoft 365 service health. This same tenant has another Copilot Studio agent that works normally in Teams. The affected agent previously worked in Teams for several weeks before the issue appeared. The agent architecture is very simple (single MCP server, no custom connectors, no Power Automate involved in this scenario). At this point, I'm mainly trying to understand why Teams no longer seems to create a conversation/session for this specific agent while the same agent continues to work in Copilot Studio and Microsoft 365 Copilot. Has anyone seen similar behavior or found a way to diagnose why Teams is no longer forwarding requests to a specific agent ? Thank you for help
Credits usage for Copilot Studio Workflow with agents
If I add an agent(for research and analyze from the JSON provided) in Copilot studio recurring workflow, whose and which credits will be used whenever it runs? Hi Team, I have a question regarding licensing and credit consumption in Copilot Studio. I have created a Copilot Studio agent that performs research and analysis based on a JSON payload. I am planning to invoke this agent from within a Copilot Studio recurring workflow that runs on a schedule. Could you please clarify the following: When the recurring workflow executes and calls the agent, whose credits are consumed? The user who created the workflow? The owner of the agent? The account under which the workflow runs? The environment's pooled credits? Are there separate credit charges for: Workflow execution Agent invocation Generative AI/research actions performed by the agent Any guidance or documentation links explaining the credit consumption model for this scenario would be greatly appreciated. Thank you!Best practice for Copilot Studio agents and SharePoint libraries with unique permissions?
We recently ran into an issue where a Copilot Studio agent was unable to retrieve content from SharePoint libraries that have unique permissions and nested folder structures. Users with elevated permissions were able to retrieve results, while users with read-only/visitor access could not, even though they had access to the underlying documents. We've observed similar behavior across multiple agents and suspect the library's unique permission structure is impacting indexing or content retrieval. For organizations that use SharePoint libraries with extensive unique permissions, nested folders, and restricted access models: What is the recommended approach when using these libraries as knowledge sources for Copilot Studio agents? Are there known limitations or best practices regarding unique permissions and nested folders? Is it better to simplify permissions, create dedicated access groups, flatten the folder structure, or maintain separate agent-specific content locations? How are others balancing security requirements with reliable agent retrieval? We'd appreciate any guidance, best practices, or lessons learned from similar implementations.
Copilot Studio Agent Unable to Retrieve Usable DOCX/XLSX Content from OneDrive (and SharePoint)
Hi everyone, I'm building a Copilot Studio agent that needs to read and process Word (.docx) and Excel (.xlsx) files stored in OneDrive. The agent can successfully locate files and retrieve metadata, but it appears unable to retrieve Office files as usable binary content. I tested the behaviour using the OneDrive Get file content action: A text file (test.txt) was returned correctly and matched the original file contents exactly. A Word file (Test.docx) was returned beginning with the ZIP signature PK and contained recognisable DOCX entries such as [Content_Types].xml and _rels/.rels. However, the returned payload also contained large numbers of Unicode replacement characters (�). The returned content appears to be a text string rather than binary data or base64 content. Because Office files are ZIP-based binary formats, the returned payload cannot be reconstructed into a valid .docx or .xlsx file, preventing downstream libraries such as python-docx and openpyxl from opening the file. Is there any way to resolve this issue?Using Dynamics 365 ERP MCP Server from a Standalone Copilot Studio Environment
We have a Copilot Studio environment that is not connected to Dataverse and is not linked to any Dynamics 365 Finance & Operations environment. We would like to use the Dynamics 365 ERP MCP Server from an agent in this Copilot Studio environment to retrieve data from F&O. Is this configuration supported? If so: What connection and authentication setup is required between Copilot Studio and the Dynamics 365 ERP MCP Server? Does the Copilot Studio environment need to be linked to the target F&O environment or Dataverse environment? Can the ERP MCP Server connect directly to F&O independently of the Copilot Studio environment? How is user authentication handled when the agent invokes MCP tools? Does the MCP connection use the authenticated user's F&O permissions, a service principal, or the connection owner's credentials? Are there any prerequisites, limitations, or recommended architectures for using the ERP MCP Server from a standalone Copilot Studio environment?Copilot Studio agents problems connecting to Sharepoint knowledge source
Hello, Since last week users in my tenant are experimenting issues regarding the connection between copilot studio agents and Sharepoint. The agents are not able to extract information from Sharepoint sites, printing there is not information in the Sharepoint site regarding the user's question when that information is in Sharepoint. These agents used to work well till last week. Does have been any update in Microsoft 365 services that can be affecting these agents ability to retrieve information from Sharepoint?Child agents and local agents in Copilot Studio
I'm AI administrator, and I have a colleague who've build an agent in Copilot Studio that uses to child agents. However on his screen they have the relationship "Local" and he can't access them or do anything. When I look at his agent, the sub agents have relationship "Child" and everything works fine. The image down below is what he sees - and the trigger also gets that orange triangle. Have anybody experienced the same? We tried to give another colleague editor permission to the agent, and that colleague experiences the same. They are both sitting at an office in another country than me.MCP (Model Context Protocol)
gave an AI agent write access to a production system. Not a demo. A real internal tool people depend on. It can now read, create, and update records - in plain language, from a chat window. Four things I learned building it with MCP (Model Context Protocol): 1. The tool description IS the interface. The agent doesn't read your code. It reads one sentence describing each tool, and decides from that alone whether to call it. Write "internal API test" → ignored forever. Write "creates and updates support tickets" → fires correctly. We spent 15 years designing UIs for humans. The design surface is now a sentence a model reads. 2. Agents can't click "Sign in." Any auth flow expecting a browser redirect silently breaks an agent connection. Machine access and human access need separate doors into the same house. 3. MCP errors don't mean what you think. My server returned success on every request -and the agent still failed. A "404" in MCP means session expired, not wrong URL. New protocol, new error vocabulary. 4. Least privilege stops being optional the moment an agent can write. A human with too many permissions makes occasional mistakes. An agent makes them at machine speed, confidently, while explaining why it was right. Why this matters: MCP turns "integrate AI into our systems" from a bespoke project into a standard interface. Expose capabilities, describe them clearly, and any compliant agent can use them. Same shift APIs caused 20 years ago - except the consumer isn't a program following rigid contracts. It's a model deciding at runtime what to call and why. The interfaces we built for humans aren't going away. They're just no longer the only way in. Activate to view larger image,
