Document OS vs Content OS: Why the Distinction Matters More Than You Think

Sanity made a smart move in March 2026. They stopped calling themselves a headless CMS and started calling themselves a "Content Operating System for the AI era."

They're right that the language needed to change. They're wrong about what the operating system actually is.

An operating system doesn't store data. It executes it.

macOS doesn't store your photos: it gives you the runtime to edit and share them. Linux doesn't store your code: it gives you the environment to compile and run it. When we say a document should be machine-readable, we don't mean "a machine can find it in a database." We mean a machine can pick it up, understand what to do with it, and do it.

That's the gap Sanity hasn't crossed. Their "Content OS" is still a retrieval layer. You build an agent, point it at Sanity via an MCP endpoint, and it reads your content. The content itself remains passive. It's a library, not a kernel.

The difference between queryable and executable.

In MX OS, a document called a COG carries its own action block. The document doesn't just describe something: it specifies what should happen when an agent encounters it. The agent is the runtime; the COG is the instruction set. No separate API. No external agent config. The document is the program.

This distinction sounds philosophical until you think about scale.

If you have 50,000 product descriptions and you want an AI agent to handle returns, recommendations, and compliance across all of them, you have two choices:

Option A: Build a Content OS. Train your agents to understand your CMS schema, write GROQ queries, manage retrieval pipelines, and hope your governance rules hold when the agents improvise.

Option B: Build a Document OS. Each document carries its own structured intent. The agent reads the action block. It knows exactly what it's authorised to do, what data it needs, and where to find provenance verification. No improvisation required.

Sanity's CEO said something true: "When content is modeled intentionally — with relationships, validation rules, governance, and real-time APIs — AI systems stop guessing and start reasoning." He just stopped one step short. Intentional content structure without executable intent still produces guessing at the action layer.

What "OS" should mean in an agentic world.

An OS for AI agents needs to do what every OS does: manage the relationship between data and execution, enforce security boundaries, and create a predictable runtime environment across wildly different hardware.

Documents are the natural primitive, not because it's elegant but because they're already everywhere. Every website, every CRM entry, every product spec, every API response is a document of some kind. The question is whether those documents are dumb blobs an agent has to interpret, or smart executables it can run.

Content OS assumes the content stays dumb and the agent gets smarter. Document OS makes the document smart enough that any compliant agent can run it.

The naming difference reflects an architectural bet.

MX OS bets on the document. The Gathering is the standards body that governs what "smart document" means. REGINALD is the cryptographic registry that proves a document is what it claims to be.

The governance question they can't answer.

There's a second difference that matters more in the long run.

Sanity Context stores your agent system prompts as editable documents inside Sanity Studio. Your agents, your system prompts, your content governance: all running through infrastructure one vendor controls. Every agent that reads your content needs a Sanity MCP URL. Every governance rule belongs to Sanity's schema. Documents never escape Sanity.

MX COGs are an open standard governed by The Gathering, a community body independent of any single vendor. A COG carries its own executable logic, provenance, and routing in the document itself. It can boot without Sanity, without Google, without any platform being present. The document is the unit. The document is sovereign.

We're not building a better CMS. We're building the layer beneath the CMS that every agent needs to operate with confidence.

The Content OS is a compelling product. The Document OS is an infrastructure standard.

Those are different things. In ten years, the infrastructure wins.

Tom Cranstoun is CEO of Digital Domain Technologies Ltd and the founder of MX OS. The MX Handbook is available now. MX: The Protocols ships July 2026.