Most organisations deploying a Copilot agent against their SharePoint content start from the same assumption: the content exists, it has been there for years, and the agent should be able to use it.
That assumption is doing a lot of work. And it is usually where the reliability problems start.
We have written before about why reliability matters and how to tell when your Copilot agent is getting it wrong. This post is about why the problem exists in the first place. Because if you are a knowledge manager responsible for the SOPs, work instructions, and regulatory procedures sitting behind your Copilot deployment, there is a good chance the issue is not the agent. It is the content you are pointing it at.
The content is there. But there are problems.
SOPs in pharma and manufacturing are written for people. Experienced people. People who know what “as per the process outlined in Section 3.2” actually means, who have already done the training, who can fill in the gaps from memory, and who bring enough contextual knowledge to the document that they only need it to be broadly right.
That is exactly how subject matter experts write them, and it makes perfect sense, because that is who the documents are for.
A Copilot agent does not read like a person. It does not bring prior knowledge to the page. It reads what is there, tries to identify what is relevant to the question being asked, and synthesises an answer from that. When the document was written for a human reader who was expected to bring context, the agent is operating without the context the document was designed to assume.
This shows up in predictable ways. Procedural steps buried mid-paragraph, because the author was explaining the reasoning as they went, are harder for the agent to extract than clearly numbered steps. Long narrative sections that walk through a process discursively get parsed for keywords, not sequenced logic. The agent pulls back a plausible-sounding answer that may or may not reflect what the document actually says.
Tables and numbered lists present a different kind of problem. The structure that makes them easy for a human to scan can make them difficult for an agent to parse reliably, particularly when column headers carry meaning that is not repeated in each row.
Then there are the cross-references. Most mature SOP libraries are built on them. A procedure for handling a deviation will tell the reader to follow the corrective action process documented elsewhere. A work instruction will reference the standard operating procedure it is derived from. A regulatory procedure will point to the relevant section of the quality manual. A human reader navigates these references automatically. A Copilot agent retrieving from SharePoint only has access to what it can find. If the cross-referenced document is not returned in the same retrieval, the agent answers with a partial picture. And it does not tell you that.
Version control is another issue. Many SharePoint SOP libraries carry revision history in the document body itself: a table at the top or bottom of the file listing change dates, revision numbers, and the sections affected. To the agent, that content looks like part of the document. It will read it. Sometimes it synthesises from it. If a previous version of a step is documented in the revision history, there is a real risk the agent conflates it with the current process, particularly if the history is not clearly separated from the live content.
The same issue appears with regional variants. A global life sciences organisation will often store country-specific versions of the same procedure as separate files, named similarly, sitting in adjacent folders. There is no explicit relationship between them in SharePoint unless someone has built one. The agent does not know which version applies to the user asking the question.
The metadata problem is separate, and it compounds everything.
Even if your SOPs were perfectly structured, the agent still has to find the right one. And that depends on metadata.
When a Copilot agent receives a question, it retrieves documents from SharePoint based on relevance signals: what the document is about, how it is tagged, what terms appear in it. The more clearly a document is described in its metadata, the better the chances that it shows up when it should.
Most SharePoint SOP libraries were not built with that in mind. They grew over years, maintained by whoever was responsible for the library at the time, which was often a rotating cast of people with different approaches to naming, tagging, and filing. Document titles that made sense when the file was created may not reflect what is in the document now. Metadata columns that exist in one library do not exist in another. Tagging, where it happens at all, is not consistent.
Here is the practical consequence. If an operator asks the agent a question about a quality assurance inspection procedure, the agent needs to find the right document. But whether the library uses “QA procedure,” “quality assurance SOP,” “QA process,” or “inspection protocol” to describe that document determines whether it is retrievable for that query. Without a controlled vocabulary, a managed list of terms that tells SharePoint these phrases all mean the same thing, the agent is working without a thesaurus. It guesses. Sometimes it guesses well. Often it does not.
This is not a failure of the agent. It is doing exactly what it was designed to do: retrieve from what is in SharePoint. The gap is in the layer beneath it.
“Close enough” is not a category that exists in these environments.
In most applications, an AI assistant getting something slightly wrong is an inconvenience. A user asks about the refund policy, gets a partial answer, and asks again. Nobody gets hurt.
The documents sitting behind a Copilot agent in a pharmaceutical plant or a medical device manufacturer are not that kind of document. They are the procedures that people follow when carrying out processes that affect product quality, patient safety, and regulatory compliance. A slightly wrong answer to a question about a cleanroom protocol, a deviations procedure, or a change control process has a different category of consequence: operational errors, failed audits, and at the sharp end, risk to the people the products are being made for.
The agent does not know that. It returns its answer with the same confidence regardless of whether it is drawing from the right document, the current version, or a complete picture of the relevant content. The answer looks authoritative. The user has no obvious signal that something may be off.
The tolerance for that gap is much lower here than in other industries. The current state of most SOP libraries in SharePoint does not reflect that.
This is a content and structure problem. That means it is solvable.
Nothing described above is a fundamental limitation of Copilot. The agent is doing what it was built to do. The question is whether the content in SharePoint is structured well enough to support reliable retrieval, and whether the metadata layer is rich enough to make the right documents findable.
We have seen what this looks like in practice with a global life sciences organisation. The reliability issues they were attributing to the agent were consistently traceable back to three things: document structure that buried procedural content in narrative text, a cross-referencing approach that created dependencies the agent could not follow, and a metadata layer that had grown organically over a decade without any controlled vocabulary.
None of those are permanent problems. They are fixable. But fixing them requires knowing specifically where the gaps are: which documents, which structural patterns, which parts of the metadata layer are creating the most retrieval failures. That is not something you can assess from a gut feel about how the library was built. It requires a structured look.
That is the part of this that most organisations do not have a process for yet. They know the agent is not performing as expected. They may have a vague sense that the content is the issue. But without a clear view of where the content is failing, it is difficult to know where to start.
The first step is understanding exactly where your content is letting your agent down. That is what the Altuent Copilot Agent Reliability Score is designed to do. Find out how we approach it.