Copilot agents stop reading SharePoint files they can still find

A Microsoft Q&A post says a Copilot Studio agent that used a SharePoint library as its knowledge source worked on 7 September 2026 and stopped retrieving document content from 8 September. The library holds about 192,000 items. The agent had been in use since January. Follow-up tests on 22 September found the same failure across every tested agent that used SharePoint knowledge. SharePoint Search still indexed the files, and Microsoft 365 Copilot Chat could still pull information from the same place. Agents could locate a file by exact name but returned SharePoint metadata instead of the document itself. An independent advisor confirmed that pattern on 23 September. This is a practitioner thread, not a Microsoft incident notice. The posts do not give a root cause or a fix date, and they do not prove Microsoft changed the platform on purpose.
Until now, many teams treated Copilot Chat, SharePoint search, and a custom agent as one pipeline. If Chat could summarise a library, people assumed the agent grounded on that library was still reading the same files. Permissions checks and a working search index felt like enough proof. That split is now the story. Chat and search can look healthy while the agent only returns titles, paths, and other metadata. A polished answer that never quotes the document is the failure mode to watch, not a red error. Until Microsoft confirms cause and scope, SharePoint-grounded agents should be treated as untrusted for live work even when Chat still works.
Analysis
This is a trap to avoid, not a reason to abandon Copilot Chat. Before the next agent demo or rollout, take one known SharePoint file, ask Copilot Chat and the agent the same question, and park the agent if it returns filename or metadata instead of the document body.
Source note
Pulse published by Collab365 Spaces, reviewed by Helen Jones on . Cite as "Copilot agents stop reading SharePoint files they can still find", Collab365 Spaces. 1 source referenced.