We’ve documented everything. We just can’t find it.
What are we actually talking about – and which tools are involved?
There are three layers that rarely get separated clearly in practice:
- ● SharePoint: The structured knowledge store. Documents, policies, templates, manuals. Explicit knowledge with clear access controls.
- ● Microsoft Teams: Where actual work happens. Decisions get made in chat. Contextual knowledge forms in channels. And stays there.
- ● Microsoft Foundry / Copilot Studio: The AI layer that can consolidate knowledge from distributed sources and make it contextually accessible – when configured properly
The triangle sounds simple. In practice, all three layers get mixed up, confused, or simply ignored. The result: information lives everywhere. Knowledge lives nowhere.
What SharePoint actually does well – and what it doesn’t
The strengths: where SharePoint delivers
SharePoint is an excellent document management system. Full stop. It can:
- ● Version documents and enrich them with metadata
- ● Control access rights at a granular level (group, site, folder, file)
- ● Be made searchable across the entire M365 ecosystem via Microsoft Search
- ● Serve as a single source of truth for explicit, structured knowledge – processes, policies, templates, project wrap-ups
The prerequisite: a clean information architecture. Who is allowed to store what? What naming convention applies? Who owns the content? Without answering those three questions before the first folder gets created, you get chaos in slow motion.
Watch out for …
A clear site structure from day one (3 well-structured sites beat 15 unclear ones)
Naming conventions written down and included in onboarding docs
Named content owners per site or document area – otherwise nobody maintains anything
Search optimisation: configure metadata and managed properties early, not as an afterthought
The structural gap: what SharePoint cannot see
SharePoint only sees what someone actively puts in. That sounds trivial. It isn’t.
Every organisation has a second layer of knowledge: decisions made in a Teams chat. Solutions communicated by email. Lessons learned from a project that exist only in the project lead’s head – and were never written down. That knowledge is real. It is operationally relevant. And it simply does not exist in SharePoint.
That is not a criticism of SharePoint. It is a structural characteristic. SharePoint is passive. It waits for someone to file something. It does not detect important decisions being made in chat. It does not flag when a policy has not been touched in 14 months. It does not raise the alarm when someone leaves the company and their knowledge walks out with them
Typical knowledge gaps – recognise any of these?
The Teams chat from Project X is the actual project documentation
The SharePoint policy dates from 2022 – the organisation has changed three times since
When colleague A is on leave, nobody knows how process Y works
New joiners find documents but not the context behind them
Nobody knows for certain which documents are still current and which are not
The knowledge lifecycle: the thing almost everyone overlooks
Here is the uncomfortable truth: most organisations have a knowledge repository, but no knowledge cycle. That difference is everything.
A knowledge lifecycle describes what happens to knowledge from creation through to archiving or deletion. Without this cycle, SharePoint goes stale quietly. Nobody notices. Until someone searches for a policy and finds the wrong one.
The lifecycle in five phases – made concrete
- • Creation: Where does knowledge originate? Not just in documents – also in projects, meetings, client conversations and chats. Who is responsible for recognising this knowledge and deciding whether it needs to be documented?
- • Documentation: Who writes it up? In what format? Where? With which metadata? Clear ownership and a defined template are the difference between “filed somewhere” and “findable.”
- • Use & distribution: How does knowledge reach the people who need it? Who gets notified when a relevant document is updated? Microsoft Search, Viva Topics (assumption: if licensed) or an AI agent can actively support here.
- • Update & maintenance: Who reviews which documents at what interval? Twice a year for operational processes, annually for strategic documents – this must be defined upfront and scheduled. Not as an intention. As a calendar event with an owner.
- • Archiving or deletion: What happens to knowledge that is no longer current? Clearly defined retention labels in SharePoint help – but only if someone maintains them and the rules are consistently applied.
Lifecycle quick-start: answer these 4 questions first
- 1. Who is content owner for which areas in SharePoint?
- 2. How often are documents reviewed for accuracy?
- 3. What happens to knowledge from Teams and Outlook – does it ever get transferred?
- 4. Who decides when a document gets archived or deleted?
AI agents: works – when you get it right
No pretending here: AI agents built on Microsoft Foundry or Copilot Studio are technically impressive. But I will also name the limits.
What an AI agent can do: it analyses knowledge sources across systems – SharePoint, Teams chats, Outlook (with the right configuration) – and makes distributed knowledge contextually accessible. Instead of searching across five channels, you ask the agent: “How did we solve this for client X?” You get a consolidated answer with source references.
What an AI agent does not do: it does not replace the lifecycle. It surfaces knowledge that exists somewhere. If the knowledge was never documented, it will not find it. If documents are outdated, it returns outdated answers. Garbage in, garbage out – that applies to intelligent systems too.
Works, IF …
- … a solid SharePoint foundation exists (structured and reasonably up to date)
- … indexing and access rights are correctly configured (keyword: Semantic Index for Copilot)
- … the agent has clearly defined sources and is not set to search “everything”
- … users understand what the agent can and cannot do (not an oracle, but an assistant)
- … the organisation is willing to actively maintain knowledge – AI only amplifies what is already there
AI Search: The question is not “What does the agent know?” – it’s “What is it allowed to index?”
When a Microsoft Foundry AI agent is supposed to answer knowledge questions, everything hinges on one single question: what has the agent actually seen? The intelligence of the model is one thing. The index – the set of sources actually reachable – is another. And in practice, the index is the more common problem.
Microsoft Foundry uses Azure AI Search as its indexing layer. That means: before an agent can answer anything, documents and content must be ingested into a searchable vector index. This index determines what the agent “knows” – and what simply does not exist for it. SharePoint documents can be connected directly. But organisational knowledge rarely stops at the SharePoint boundary.
Connecting external sources: where MCP servers come in
Many SMEs run external systems alongside SharePoint: Confluence or Notion as a wiki, Jira or ServiceNow for tickets and processes. That knowledge is real, actively used – and never makes it into SharePoint. Classical integrations would mean building API connections, synchronising data, aligning access rights.Complex and error-prone.
That is exactly where MCP servers (Model Context Protocol) come in. MCP is an open protocol that lets an AI agent retrieve context from external sources at runtime – without data needing to be migrated or permanently synchronised first. The agent queries, the MCP server delivers the context, the response takes it into account. Confluence pages, Jira tickets, ServiceNow entries – everything stays where it lives. The agent sees it anyway.
This is not a marketing promise – but it is not plug-and-play either. MCP servers need to be configured, access rights must be accurately mapped, and source quality must be solid. An outdated Confluence wiki causes the same damage as an outdated SharePoint. The index is only as good as what is in it.
Which sources belong in the index – and what to keep in mind
- SharePoint: Direct connection via Azure AI Search connector – prerequisite: clean structure and current content
- Confluence / Notion: Connectable via MCP server – data stays in the source system, no data transfer required
- Jira / ServiceNow: Ticket history and process knowledge via MCP – especially valuable for support and IT agents
- Access rights: what a user is not allowed to see in the source system, the agent must not deliver to them either – this needs to be cleanly mapped in the configuration
- Source quality: an agent amplifies what is in the index – outdated knowledge does not become accurate through AI
Reality check: how do I know it’s working?
- Signs it’s working
• New joiners find relevant documents within minutes – without having to ask anyone
• When someone leaves, their knowledge stays in SharePoint – not just in their head
• Documents have a last-updated date no older than one year – for operational processes
• A SharePoint search returns the first relevant result on page one
• Teams chats are actively and deliberately transferred to SharePoint when they contain long-term relevant knowledge
If it is not working: check these 3 things first
- • No content owners: If nobody is responsible for an area, nobody maintains it. Not because people do poor work – but because there is no ownership.
- • No maintenance schedule defined: “We update when needed” is not a process. It’s a wish. Quarterly reviews for critical documents go in the calendar – as a recurring event with an assigned owner.
- • SharePoint structure grew organically, not planned: If the site structure evolved over three years without a plan, it is time for an information architecture workshop. Better to clean it up once than to keep searching forever.
Conclusion: SharePoint is good. But it is not enough on its own.
SharePoint is a solid foundation. One of the best document stores M365 has to offer – when used with structure. But a knowledge management system it is not. It is one part of one.
The real lever is the lifecycle. Define who maintains knowledge – and at what rhythm – and you have won half the battle. The rest is technology. And technology is solvable.
AI agents can be a genuine game-changer. But they only amplify what is already there. A solid knowledge base in SharePoint, clear content owners and an active lifecycle – that is the prerequisite. Not the outcome.
My honest learning from multiple SME projects: organisations that fail at knowledge management rarely fail because of the technology. They fail because they introduced SharePoint – and then stopped thinking.
☕ Espresso moment: SharePoint is the stage. But you write the script – or nobody shows up.
Quick checklist to take away
- • Assign content owners per SharePoint area – in writing, not just verbally
- • Define maintenance intervals: every 6 months (operational) / annually (strategic)
- • Document naming conventions and embed them in onboarding
- • Actively transfer implicit knowledge from Teams – or surface it via an AI agent
- • Configure retention labels in SharePoint and define archiving rules
- • Only deploy AI agents once the foundation is in place (structure + current content)
- • At least once a year: run an information architecture review
