Copilot studio Agents published on Sharepoint
Hi everyone, I'm hoping someone can confirm or correct my understanding of a limitation we're experiencing. We have a Copilot Studio agent published to a SharePoint site. When users interact with the agent, they are unable to see their previous chat history — unlike the built-in SharePoint AI agents (e.g. SharePoint Agents / Copilot for SharePoint), which do appear to retain and display conversation history. Is it correct that Copilot Studio agents published to SharePoint do NOT support persistent chat history visible to the end user, while native/built-in SharePoint AI agents do support this out of the box?
New Agent experience - how to add Fabric data agent
When using the new (Agent) experience in Copilot studio how can you add Fabric Data agent as connected agent ? There does not seem to be an option. Also should adding it as an MCP server be supported (under Tools) ? https://learn.microsoft.com/en-us/fabric/data-science/data-agent-mcp-server says the following: Currently, you can use the Fabric data agent MCP server only in VS Code. If you're using your own MCP client, it can also work, as long as you set up authentication Has anyone tried this? If yes, by using with authentication? OAuth2? Thanks
Giving AI Agent access to move files between folders
Hi Community, I have built a PDF to Excel reconcilliation AI Agent using Microsoft Copilot that reconciles supplier statements against payables data for our organisation. The agent works well. it reads PDF supplier statements and Excel reports from a SharePoint document library, performs the reconciliation, and produces a structured audit-ready report. However, I am hitting a limitation at the final step. Once the reconciliation is complete, I would like the agent to automatically move the processed supplier statement PDF from its current folder to a subfolder called "reconcilled" within the same SharePoint document library. My question is What is the recommended way to give a Copilot AI Agent the ability to move files between SharePoint folders? Any guidance, documentation links, or examples from others who have implemented similar workflows would be greatly appreciated. Thank you!
Copilot Studio + SharePoint: Markdown (.md) Files in Doc Libraries Supported as Knowledge Sources?
Hi all, We’ve been doing some deeper testing with Copilot Studio agents grounded in SharePoint knowledge sources, and I’m hoping to clarify whether what we’re seeing is a known limitation or an undocumented gap. Scenario A Copilot Studio agent uses SharePoint document libraries as a knowledge source The library contains Markdown (.md) files that are intentionally used as canonical design references The same .md files: ✅ Work well when uploaded directly to the agent ❌ Are not retrievable or citable when stored in a SharePoint library and added as a SharePoint knowledge source To help with grounding, we created modern SharePoint index pages that: Explain what the markdown collections are (Patterns, ADRs, Guardrails) Link directly to the canonical folders and files Explicitly state that the .md files are the source of truth The agent can: Discover and summarize the index pages correctly Understand that .md artifacts exist and where they live But it cannot: Read the content of the individual .md files Apply a specific pattern or ADR from those files in a design conversation Cite them as sources, even when permissions and search indexing are confirmed What We’ve Checked Permissions (agent user has access) Folder depth (kept shallow) Search results (markdown files appear in SharePoint search) SharePoint indexing status Work IQ enabled Same content works when attached directly to the agent This behavior also seems consistent with what others have reported here: Markdown works when uploaded directly Markdown retrieval degrades when hosted in SharePoint libraries Questions for the Product Team / Community Are Markdown (.md) files in SharePoint document libraries officially supported as Copilot Studio knowledge sources today? If yes, are there specific constraints (file size, rendering, parsing, indexing) that differ from Word/PDF? If no (or “not yet”), is this a known limitation on the roadmap? Is the recommended pattern to: Convert important markdown files into .aspx pages, or Use thin “index / summary” pages and keep markdown canonical until retrieval improves? We’re happy to adapt our information architecture — just trying to align with the intended platform direction rather than work against it. Thanks in advance for any guidance or clarification. This capability is extremely powerful, and clearer expectations here would help a lot of teams make the right design tradeoffs.
Copilot Podcast Creations Stuck in “Creating” State
My Copilot podcast creations are stuck in the “Creating” state and will not delete. The delete button is greyed out. I have already tried closing all browsers, restarting my iPad, phone, and PC, and the issue persists across all devices. It looks like the jobs are stuck in the backend queue and cannot be cleared from my side. I also attempted to open a support chat, but the service request auto‑closed before an agent joined. Is there a way to clear these stuck podcast creations on the backend, or can someone from Microsoft confirm if this is a known issue?
Copilot Studio Agent resetting when processing PDF drawings (300MB+) via Claude 4.6 Sonnet
Hello everyone, I am building an automated drawing review verification agent inside Copilot Studio using the Claude 4.6 Sonnet model. The goal of the agent is to read a comments package (20-40MB) and verify if those design comments were successfully incorporated into a milestone drawing set (300MB–400MB). When testing this workflow natively within Claude, the model handles the token load perfectly and returns an accurate compliance/incorporation summary within approximately 20 minutes. However, when running the exact same agent setup within Copilot Studio, the conversational canvas repeatedly crashes and resets the session. I suspect I am hitting the 100-second synchronous conversational timeout or overloading the chat runtime payload limits due to the massive file sizes. Because of corporate compliance policies, this agent must live within our Microsoft tenant so it can be scaled across our operations team via Microsoft 365. How can I fix Copilot Studio to have its performance match Claude's, as it is utilizing the same agent model. I am fairly new to working with AI but am willing explore any avenue as if I can figure out a solution this will help save a lot of time for colleagues. Thanks in advance for any insights!Agent Builder, Copilot Studio, or Azure AI Foundry: How We Decide for Every Client
Every client conversation starts the same way. Someone has seen a demo, attended an Ignite session, or read a press release. They want to build an agent. Then comes the question that derails more projects than any technical challenge: "Which tool should we use?" After deploying agents for clients across industries - insurance, professional services, manufacturing, public sector - we have developed a repeatable framework for answering that question. It is not based on which tool is newest or which has the best marketing. It is based on where projects actually succeed or fail in production. The three tools are not competitors The first mistake most teams make is treating Agent Builder, Copilot Studio, and Azure AI Foundry as a hierarchy - basic, intermediate, advanced. That framing leads to bad decisions. They are not a ladder. They are three distinct tools built for three distinct contexts. The right question is not "which tool is most powerful?" It is "which tool fits this project's constraints?" The framework: 4 questions We evaluate every project against four dimensions before recommending a tool: Who is building it? Where do users live? How complex is the logic? Who owns it after go-live? Agent Builder Copilot Studio Azure AI Foundry Builder profile Maker, no code Developer / power user Pro developer, Python User surface M365 Copilot Chat Teams, web, M365 Copilot Custom app, any surface Logic complexity Simple Q&A, task routing Multi-step flows, connectors Fully custom orchestration Post-go-live ownership Business team IT + Business joint Engineering team Governance M365 Admin Center Power Platform DLP Custom, Azure RBAC When we recommend Agent Builder Agent Builder is the right call when the business team wants to own the agent end-to-end, the use case is bounded, and the users already live inside M365 Copilot Chat. The key advantage is distribution - an Agent Builder agent surfaces natively inside Copilot Chat with zero additional deployment work. No IT ticket, no app registration, no Teams app package. The ceiling is real. Agent Builder does not support complex branching logic, external API calls, or dynamic prompt injection. The moment a client asks "can it also update a record in our CRM?" the answer is usually no. Use it when: The maker owns it, the use case is narrow, and M365 Copilot is already the user's primary surface. When we recommend Copilot Studio Copilot Studio is our default recommendation for the majority of enterprise agent projects. It covers the wide middle ground between no-code simplicity and full-code flexibility - within the Microsoft governance perimeter most enterprise IT teams already control. Power Platform connectors - 1,000+ out-of-the-box connectors means most enterprise data sources are reachable without custom API development M365 Copilot channel - surface a Copilot Studio agent directly inside M365 Copilot Chat, Agent Builder-level distribution with enterprise-grade logic underneath Topic-level governance - fallback behaviors, confidence thresholds, escalation paths configurable without code DLP policy enforcement - the agent operates within the same data loss prevention perimeter as the rest of the Power Platform tenant The most common mistake: under-investing in the knowledge layer. The agent authoring is the easy part. Getting SharePoint content structured, metadata consistent, and documents deduplicated is where most projects hit delays. Budget for it. Use it when: The use case requires connectors, dynamic responses, or M365 Copilot integration - and you want IT to own governance without requiring a developer team. When we recommend Azure AI Foundry Foundry is the right call when you need to bring your own model, build a fully custom orchestration pipeline, or integrate into a surface that has nothing to do with Microsoft 365. In practice, this means one of three scenarios: The client has a model fine-tuned on proprietary data that must be used The agent is embedded inside a custom-built web or mobile application The logic requires Python-level control - complex reasoning chains, multi-agent coordination, custom evaluation loops Foundry projects require a professional developer, take longer, and produce something the business team cannot maintain without engineering support. That is not a reason to avoid it - it is a reason to be honest with the client upfront. Use it when: You need full control of the model, the orchestration, or the surface - and you have a developer team to own it. The question that resolves most debates When a client is torn between Copilot Studio and Foundry, we ask one question: "Who is answering the 2am support call when this breaks in production?" If the answer is a developer, Foundry is viable. If the answer is the IT admin or the business owner, Copilot Studio is the right call. Not because Foundry is unreliable, but because the operational model has to match the tool. More projects fail from ownership mismatch than from technical limitations. What we see go wrong Reaching for Foundry too early. Developers often want full control and reach for Foundry before validating the use case. We have rebuilt several Foundry POCs in Copilot Studio when the production constraints called for it - faster to ship and cheaper to run. Under-scoping Agent Builder. Business teams choose Agent Builder because it looks simple, then hit the ceiling at month two. The re-platform cost is higher than building in Copilot Studio from the start. Ignoring the M365 Copilot channel. Many Copilot Studio projects are deployed as standalone Teams apps when they could surface directly inside M365 Copilot Chat. The distribution advantage is significant and underused. The short version Agent Builder - maker-owned, bounded use case, M365 Copilot surface, fast Copilot Studio - IT + business joint ownership, connectors, production governance, M365 Copilot integration Azure AI Foundry - developer-owned, custom model or surface, full control, higher cost Start with the ownership model. Everything else follows. Elliot Margot - Team Lead Jumpstart, Copilot and Agents at Witivio (Microsoft Partner). Connect on https://www.linkedin.com/in/elliot-margot-52742a156/.
How to use agents response as an input to a topic?
Hi I would like to use the agents reponse to store it in a word or excel file. For that, I would like to use the response provided by the agent, pass it on to my custom topic which triggers an agentic workflow to store the agents response in a word or excel file. I cannot sort out how to pick the agents response and pass it on to my custom topic, any help will be highly appreciated, thanks!
