On October 14, Microsoft announced a team knowledge base in SharePoint. Congratulations to the SharePoint and Work IQ teams. It's the clearest sign yet that Microsoft sees knowledge, and not only retrieval, as the next problem for Copilot and agents.
Here's how it works. A team picks the email threads, meetings, chats and files that matter. Work IQ's knowledge compilation engine turns them into a library of linked markdown pages on a SharePoint site. People read the pages and edit them, with version history. Agents use the pages as their starting point instead of searching raw files every time. Microsoft's early internal testing reports agent answers up to four times faster and about 30% more token-efficient. Those are Microsoft's own numbers, not customer results, but the direction is right.
We've been here before
This one feels familiar. With Project Cortex and Viva Topics, we used AI to find topics across a tenant, build pages for them, and ask people to curate the results. The idea was right then. Two things held it back: the pages were hard for anything other than a person to use, and curation never kept up with the content.
The new knowledge base improves on both. Markdown is easy for people and models to read. Work IQ gives Copilot a much better picture of the people, content and activity in a tenant than we had in 2021. I'm glad to see the work picked back up, and I'm looking forward to trying it in our own tenant.
A first step, not a finished one
The announcement is honest about what's still to come, and I appreciate that. Today the feature is in Frontier preview, available only to users enabled for usage-based billing. Copilot updates pages only when someone asks. Automated curation, coding-agent access through Work IQ, and support in Cowork, Teams and Copilot Studio are all on the roadmap.
Some of the harder questions are still open:
Permissions. Pages don't inherit the permissions of their sources, and sensitivity labels don't carry over. Anyone who can read the knowledge base can see what was compiled into it.
Provenance. Readers need to trace a statement back to the email or meeting it came from, and to see which parts an agent wrote.
Freshness. A policy can change in a meeting nobody contributed. Someone has to notice, and each page needs a date when it should be checked again.
Ownership. A knowledge base an agent compiles still needs a person who is accountable for it.
None of these are new problems. KM practitioners have worked on them for decades. Back at Knowledge Management Associates in Boston, we considered the same three questions: who owns this, is it still true, and how would anyone know? The tools have changed completely. The questions haven't.
The community belongs in the next phase
Microsoft will build a better product if it brings that experience in early. AIIM members, records and information managers, and KM leaders around the world know how knowledge goes stale and who should be accountable for it. They also know where knowledge lives outside Microsoft 365: ticketing tools, quality systems, specialist platforms, and the heads of experienced colleagues.
To be clear, I'm not suggesting Microsoft should hand this off to anyone. I'm suggesting the people who have done this work by hand for 20 years should help shape what it looks like when an agent does it.
Where Copley fits
In August we announced Project Copley, an open, governed knowledge layer for Microsoft 365 and beyond. It's built to complement what Microsoft shipped, not compete with it. Work IQ handles retrieval. Copley governs what gets retrieved.
The pattern isn't ours alone. Andrej Karpathy's "LLM wiki" described a markdown library that agents maintain and people curate. Google's Open Knowledge Format (OKF) made that pattern more formal, with one concept per file, YAML frontmatter, and trust fields like sources, verification and staleness. Copley is OKF-compatible and lives on GitHub. Every concept has a named owner, declared sources, a last-verified date, and a stale-after date. A schema validates the whole bundle in CI, so the structure doesn't drift.
We've started building it against SharePoint. In the current build, you choose an authoritative source library and review a fixed plan before anything is written. Copley checks that the new library's audience is a subset of every source's audience. Each draft keeps its source trail. Generating drafts is the only step that writes to SharePoint, and nothing is published automatically. It's early, too: today the first pass handles text, markdown, Word and text-based PDF, and skips PowerPoint and Excel.
Here’s an early prototype:
Project Copley Prototype v0.1
Microsoft's knowledge base and Copley are working on the same problem from two directions. The best outcome is a page Copilot compiles in SharePoint that carries the same trust metadata as a page in a GitHub repo, so any agent can read it and know whether to rely on it.
Resources
August blog post - Retrieval Got Solved. Trust Didn't. | The Synozur Alliance
Copley specification on GitHub - https://github.com/chris-mcnulty/copley-workiq/
Join us November 13
Our next Project Copley community call is Friday, November 13, at 8 AM PT / 11 AM ET. We'll look at the SharePoint knowledge base, compare it with the Copley spec, and decide where the community can contribute most. KM practitioners, AIIM members, Microsoft MVPs and Microsoft product teams are all welcome, especially if you think we've got it wrong.
Register here: https://events.teams.microsoft.com/event/787e08db-8341-4642-9e3d-d6572e0ce951@b4fbeaf7-1c91-43bb-8031-49eb8d4175ee
Copilot writes the pages. People still have to own them. Let's work out together what that looks like.