Is "uncertainty" the feedback signal Copilot Studio agents are actually missing?
At today's M365 Platform Weekly session, we were asked for our input on what feedback we wish we could pull beyond thumbs up/down and verbatims. Is it trends over time, sentiment themes, the response-to-triage loop, etc. Here's an angle: What if the primitive itself is wrong? Thumbs up/down measures satisfaction after the fact. What if we measured confidence instead? How often an agent actually knows it's on shaky ground, and whether the user's reaction matches that? If an agent flags its own uncertainty at the point of response instead of a static thumbs up/down, a feedback prompt gets generated from whatever's trending in that uncertainty instead of the same generic question every time, and "trends over time" becomes "did this agent get more confident or less confident since the last update" rather than a flat satisfaction line. It might also solve the silence problem that most users rarely click anything. A reaction that's actually specific ("you caught something the agent flagged as shaky") seems easier to engage with than a binary good or bad. To be clear, confidence signals already exist in adjacent forms. Copilot Studio and most conversational AI platforms already use a confidence score internally to decide whether to answer directly, ask a clarifying question, or escalate to a human. GitHub Copilot has used a confidence score since its earliest versions too, ranking code suggestions and defaulting to the highest-scoring one. None of that is new. So rather than "add a percentage next to the answer", what if there is a specific flag pointing at the exact claim or step the agent is unsure about, feeding into the feedback loop? Curious if anyone else building in Copilot Studio has run into this: Do you ever wish your agent had hedged when it didn't? What would you actually do with an uncertainty score if you had one? And would just love others thoughts on this :)
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?
Copilot+ laptop cannot access my local files or folders. No permission dialog to approve access.
First up - I'm not a tech expert! I have a new CoPilot+ laptop. Asked CoPilot to do a task in my folders and files that I downloaded from iCloud, but it cannot access my files or folders. Asks me to allow access through Microsoft prompt that never appears. Contacted Microsoft Support yesterday and after 2 hours and no progress, they told me to contact laptop manufacturer support. Which I did, and this resulted in a reset to factory setting of the laptop today. Problem still persists, its not hardware related. I contacted Microsoft Support again and have been directed her on the basis that this appears to be an ongoing Copilot+ issue that has already been through extensive troubleshooting, the Tech Community is currently the best channel to track updates and raise visibility with the teams investigating the problem." Any suggestions on what I need to try next? Bearing in mind, I am not an expert! Thank you in advance Gail
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.
How to Integrate Copilot Studio Agent with a Website Using API?
Hello Team, I have created a Copilot Agent using Copilot Studio and published it on our public website using an iframe. Currently, the agent does not have any authentication configured because we want it to be publicly accessible. However, our website development team has raised a security concern with this approach, as embedding the Copilot Agent directly using an iframe may not be the most secure or recommended approach. We are looking for an alternative integration approach. For example: Is it possible to expose the Copilot Studio Agent through an API or another secure endpoint? Can our website development team call the agent through an API, receive the response, and build their own custom UI instead of embedding the agent using an iframe? Is there any recommended architecture or Microsoft-supported approach for securely integrating a Copilot Studio Agent with a public-facing website? If anyone has implemented a similar solution or has any recommendations, I would appreciate your suggestions.Microsoft 365 Copilot Roadmap: What's New & Available
Register Here: https://aka.ms/MTC/CopilotRoadmapEvent Keep up with the latest in Microsoft 365 Copilot, all in one place. This Roadmap webinar series is your central hub for the latest Copilot innovations. Each session covers what’s new, what’s next, and how it all comes together to drive impact across your organization. Join Microsoft experts for a clear, practical view of Copilot so you can act on what’s available today and plan for what’s ahead. Who should attend: Business leaders looking to unlock productivity with AI IT decision makers planning and enabling Copilot adoption Technical practitioners implementing Microsoft 365 and Copilot solutions Anyone who wants a clear, ongoing view of what Copilot can do today, and what’s coming next Get ready to: Explore the latest Microsoft 365 Copilot capabilities available today Gain early insight into what’s coming next so you can plan with confidence See real-world examples of how organizations are putting Copilot to work across roles, workflows, and business scenarios Identify practical next steps to get started or deepen Copilot adoption Technical level: This is a foundational level event To get the most value out of the event, it would be helpful to have: General familiarity with Microsoft 365 workloads Interest in exploring or expanding your use of Copilot and AI in the workplace No deep technical expertise required, and this session is designed to be accessible and relevant across roles Click here for the Microsoft Event Code of Conduct.
