TL;DR

Work IQ solved retrieval. Copilot can find anything in your tenant now. But finding isn't trusting — an agent will hand you a number with a straight face and no idea whether it's current, correct, or safe to act on. That's not a retrieval problem, it's a knowledge problem, and it has to be written down somewhere the retriever can read it.

We’ve seen other ecosystems establish new approaches to crafting a visible, cross platform knowledge layer for AI content, such as Google’s new Open Knowledge Format (OKF), but so far  no similar initiative has surfaced for Microsoft 365.

So we're writing it down. Project Copley is a draft spec and a public repo: a schema that validates in CI, pointers to your real sources so nothing drifts, curated knowledge with named owners, and the agents and workflows that keep it current instead of letting it rot. It extends Work IQ, and it works for non-Microsoft agents too.

First community call is Thursday, August 20 at 8 AM PT. Everyone's welcome — especially if you think we've got it wrong.  Register here.

Introduction

For two years, the hardest problem in enterprise AI was retrieval: how do you get the right context in front of a model at the right moment? That problem is now largely solved. Work IQ brokers retrieval across the signals already moving through Microsoft 365 (people, content, activity, and the relationships between them) and makes Copilot and its agents context-aware by default. It's a real leap forward. It also exposes the next problem, and this one is harder: an agent can retrieve a number, a policy, or a "process" with no idea whether that thing is current, correct, or safe to act on. Retrieval got solved. Trust didn't. This post is about the layer I think fixes that, and the open project we're starting in order to build it: Copley.

Your agents are only as good as the knowledge they can trust

Most organizations I work with are standing up agents faster than they are governing what those agents know. The knowledge itself still lives the way it always has, as documents. A renewal process is a slide someone built in 2023. A "key" metric is defined three different ways in three different decks. The policy is buried in an email thread. When a model grounds an answer in that pile, it will confidently surface the wrong version, quote a stale figure, or reassemble a process from fragments, with no way to flag that it did. The failure mode of the document era was that people couldn't find things. The failure mode of the agent era is the opposite: agents find things instantly, with no signal of whether they should trust what they found.

The LLM-wiki moment

The developer community saw this coming and reached for a familiar tool: the wiki. Andrej Karpathy's "LLM wiki" framed it well: a living, agent-maintained markdown library that agents read, cross-link, and keep current, while humans curate direction and quality. You can see the same instinct everywhere now, from AGENTS.md and CLAUDE.md convention files to Obsidian vaults and metadata-as-code repositories. It works because markdown is both human-first and agent-friendly, needs no database or platform to get started, and gives retrievers natural anchors to grab onto.

But every one of these implementations is bespoke. There is no agreed field set, no shared semantics, and, for the enterprise, the real deal-breaker: no built-in provenance, freshness, or governance. One team's wiki cannot reliably interoperate with another's. Google's newly published Open Knowledge Format (OKF) is the first serious attempt to formalize the pattern: a portable bundle of markdown files, one concept per file, with YAML frontmatter carrying structured fields, and later drafts adding the trust signals enterprises actually need: sources, verification, staleness, and lifecycle status. OKF is the closest thing we have to a standard, and its best design choice is that it is a format, not a platform. It is readable on GitHub, indexable by search, and consumable by any agent. Hold that thought.

Work IQ and the rise of brokered retrieval

Now bring it back to Microsoft. Work IQ arrived as Copilot's context engine, a data layer that makes Copilot and agents context-aware by default across Microsoft 365. Instead of every agent bolting on its own retrieval stack, Work IQ brokers it: it reads the graph of people, work, content, and skills already present in your tenant and serves the right context on demand. If you live in Microsoft 365, and most of my clients do, this is the right architecture, and you should use it.

Here is the nuance. Brokered retrieval is excellent at finding what exists and inferring relationships from behavior. What it does not do — what no retrieval layer does on its own — is tell you why a given answer should be trusted, whether it is still current, how a specific number was computed and approved, or what an agent is and isn't allowed to remember and act on. Those are not retrieval properties. They are properties of the knowledge itself, and they have to be written down somewhere the retriever can actually read them.

A knowledge system worth building

So here is the proposal, and I'll be upfront that it is deliberately modest about reinventing anything. We do not need another ontology, and we certainly do not need another documentation platform. We need a thin, governed profile that sits on top of the standards that already work, and we should build it in the open. We're calling it Copley: an OKF-compatible bundle for documenting an organization's work intelligence and the agents that operate on it.

Three layers, one source of truth

Step back from the file list, and Copley is really three layers stacked on one idea.

• At the bottom are pointers to the raw source documents (the renewal playbook, the policy PDF, the metric definition) wherever they already live, in SharePoint, a wiki, or a repository.

• In the middle sit the curated knowledge documents: one markdown file per topic, each with a named owner, a status, and the workflow it belongs to.

• At the top is the schema that validates both, so the structure cannot quietly rot.

Raw source, curated knowledge, schema. That is the whole shape.

One deliberate choice runs through that bottom layer: we point at raw sources instead of copying them in. The moment you snapshot a document into the knowledge layer you are maintaining two versions of the truth, and the copy starts drifting from the original the day it is made. A pointer keeps a single canonical source and records what it looked like the last time we checked, a version stamp, a last-verified date, and a stale-after horizon. When the upstream document changes, validation flags the concept as stale instead of letting it fall silently out of date. You get provenance without a second copy to babysit.

Concretely, a Copley bundle would carry five things:

• A manifest, a single workiq.yaml, declaring the bundle's identity, version, license, maintainers, conformance profile, and validation rules.

• Concept documents in plain markdown with YAML frontmatter, one per object that actually makes up a business: people and roles, teams, processes and workflows, content and datasets, systems and APIs, meetings and decisions, and metrics, OKRs, and policies. Required frontmatter includes id, type, title, status, owner, sources, last_verified, stale_after, tags, and relationships.

• Agent documentation objects: an agent's record, its capabilities and skills, the tools and MCP endpoints it uses, its memory scope and retention boundaries, and its safety and approval rules.

• Trust and lifecycle metadata on everything: where it came from, who or what generated it, who verified it, its status, when it goes stale, its access rights, and, for numbers, an attestation of how they were computed and approved.

• Validation and export using JSON Schema and SHACL to keep the structure honest, with optional RDF, JSON-LD, DCAT, and PROV export when you want a true knowledge graph.

Governance is the part everyone skips and shouldn't. I would borrow directly from how the Open Compute Project runs its work: named maintainers, working groups, a real contribution process, clear licensing, and conformance tiers so teams can adopt Copley incrementally: a Core Bundle to start, an Agent Profile when you begin documenting agents, and a Semantic Export tier when you are ready for graphs. Nobody should have to stand up RDF on day one to get value on day one.

How it augments Work IQ

This is the part I care about most, because it is where the two ideas stop competing and start compounding. Work IQ brokers retrieval; Copley governs what gets retrieved. Give every knowledge atom structure and trust metadata, and Work IQ's hybrid retrieval (lexical, vector, metadata-filtered, and graph-neighborhood) gets sharper on every axis:

• Because each concept declares its sources, who verified it, and when it goes stale, an agent can finally answer "why should I trust this?" and "is this still current?" instead of guessing.

• Because we are documenting knowledge specifically for retrieval, we can also say how it should be retrieved: a canonical summary, synonyms, related concepts, chunking hints, and even the evaluation questions a good answer has to satisfy. Most standards document data; almost none document how that data should be found.

• Because a board-ready number can carry a receipt (the approved query, the evidence, and a reviewer's signoff), an agent reports the blessed figure instead of one it quietly recomputed.

• Because memory scope and access rules are written down, agents can hand work to one another with cited context and explicit confidence boundaries, using the same MCP, A2A, and OASF plumbing the industry is already standardizing on.

None of that replaces Work IQ. It feeds it. Work IQ stays the broker; Copley gives it a better library to broker from.

Microsoft value

The reflex in an all-Microsoft environment is to assume the platform will eventually cover all of this, so why bother with an open format? Three reasons.

First, portability and durability. The format is Git-native: plain files, versioned through pull requests, validated in CI. Your work intelligence outlives any single tool, and your governance history is simply the commit log.

Second, trust you can inspect. Brokered retrieval is a black box by design; a governed knowledge layer is legible. When an auditor, a regulator, or your own risk team asks how the agent knew something, you can point to a file, its sources, and its signoff — not a ranking you cannot see.

Third, the world is multi-agent whether we like it or not. Even Microsoft-centered organizations are already running agents from more than one vendor, and standards like MCP, A2A, and OASF exist precisely because agents need to share context and hand off work across boundaries. A layer like Copley is what lets them do that with governance intact, inside Copilot and everywhere your work reaches beyond it.

Why we called it Copley

A quick word on the name. Copley is the square in Boston's Back Bay that is home to the central Boston Public Library, the first large municipal library in America, built on a radical idea that is still carved over its doors: Free to All. That is the spirit we want here. A knowledge layer should be governed and trustworthy, but it should also be open, plain files anyone can read, inspect, and build on, rather than a vault behind a velvet rope. Copley made knowledge a public good. That is the bar we are setting for ourselves.

“Athenaeum” ran a very close second, and for a while it led. The Boston Athenaeum is one of the oldest independent libraries in the country, and "a curated, member-governed collection" is almost too perfect a description of what we are building. Two things cost it the job:

• It is members-only by tradition, and this format is meant to be free to all.

• And, in the interest of full disclosure, I am a genuinely poor typist who cannot spell "Athenaeum" the same way twice to save my life. If the maintainer cannot reliably type the repo name, it is the wrong repo name. Copley it is.

Conclusion

LLMs do not need another documentation site. They need a trustworthy, versioned, human-readable, machine-validatable work-intelligence layer — and Work IQ is the best retrieval broker yet built to sit on top of one.

Copley is our first sketch of that layer, and we intend to build it in the open. The retrieval problem is behind us; the trust problem is the real work now. If that is a conversation you want to have, or a repo you want to help shape, join us.

Kickoff meeting

We’ll host an initial meeting about Project Copley on August 20th, at 8am PT/11am ET. Together, we’ll scope out what a knowledge layer for Work IQ might looks like, how to build one, and how it might work in practice.

Please join us and register for the discussion.  Hope to see you there!

Personal Note

I've been working in knowledge management about as long as I've been working in content management — which is to say, longer than either of us probably wants to count. Even before Project Cortex and Viva Topics.

Back at Knowledge Management Associates in Boston, where I was Practice Director, we were having versions of this same argument: who owns this, is it still true, and how would anyone know? The tooling was unrecognizable compared to today. The questions were not.

Taxonomy, ownership, provenance, freshness: the KM crowd has been carrying that water for decades, and the AI conversation is only now circling back to it. Which is why Project Copley isn't really a new idea. It's an old discipline, finally with a consumer that can't skim past the metadata.

Anyway — here's the KMA hat I still take to the gym.