The Metaverse Has a Content Management Problem
Somewhere in the sprawling data-Loss Angeles of the information economy, someone decided that every website should define its own reality from scratch. StoryPress respectfully disagrees.
The Franchise Model
In the beginning — which is to say, about fifteen years ago, which in Internet time is roughly equivalent to the Cenozoic Era — every content management system handed you a blank schema and said: go forth and define thy content types. And lo, ten thousand developers did exactly this, each one reinventing the same Hero Block, the same Feature Grid, the same Testimonial Carousel, slightly differently, in slightly incompatible ways, until the landscape of web content resembled nothing so much as a strip mall designed by a committee of competing architects who refused to share a common building code.
StoryPress operates on a different principle. One schema. Universal. Shared across every site on the platform like a franchise agreement — except instead of mandating identical signage and floor plans, it mandates a common vocabulary of composable primitives. Container. TextRich. Background. CTA. Images. These are not suggestions. They are the atoms of the system.
The counter-argument writes itself: surely this is constraining? Surely every project needs its own bespoke component library? To which the answer is: you are confusing the vocabulary with the literature. Shakespeare used roughly twenty thousand words. The average person uses about the same number of component types to express an infinite variety of web pages. The constraint is the point.
Reason Is a Daemon That Runs on Pattern Recognition
Here is a thing that becomes obvious once stated but which approximately nobody in the CMS industry has internalized: an artificial intelligence that has learned a schema once can deploy that knowledge across every site that shares it. When every StoryPress site uses the same component definitions, the AI doesn't re-derive the rules of engagement for each new client. It already knows. A container is a container is a container, from the first site to the ten-thousandth.
The recipes are the kicker. A recipe in StoryPress is not a vague design pattern described in a Confluence doc that no one reads. It is a validated, type-checked composition — a container with a background overlay, a centered textRich heading in white, and a CTA button — that has been verified against the schema at build time. When an AI agent encounters a recipe, it is encountering a proof. Not a suggestion. A proof that this specific arrangement of components is structurally valid.
Give the agent a TypeScript interface of the schema and it will write correct component structures on the first attempt. Not because it is brilliant — though it is, in the narrow, terrifying way that large language models are brilliant — but because the type system leaves no room for ambiguity. The schema is the spec. The types are the spec rendered in the agent's native tongue.
Schema-Driven
Everything proceeds from components.json like constitutional law. A gen script derives the relationships, the recipes layer on creative guidance, and multiple consumers — the CMS, the AI, the MCP server — all read from the same Rosetta Stone. Change the schema, everything downstream updates. This is how civilized systems work.
CMS-Agnostic
Under the hood, StoryPress currently speaks Storyblok. But the ContentProvider abstraction means this is an implementation detail, not a commitment. Swap in Sanity. Swap in a bespoke database. The schema doesn't care. The components don't care. The rendering pipeline emphatically does not care. Everything resolves to StoryData, the universal currency.
Agent-Native
The MCP server doesn't bolt AI capabilities onto a system that was designed for humans clicking buttons. It treats the AI agent as a peer. get_session determines context. get_schema provides the type system. execute_code lets the agent write a program that restructures an entire page in a single sandboxed execution. The agent is not a user. It is an operator.
Composition Over Configuration
The typical CMS gives you forty-seven specialized block types, each one a small fiefdom of bespoke logic. A Hero Block with twelve fields governing parallax behavior, overlay opacity, and button variant. A Testimonial Block with star ratings built into its DNA. A Pricing Table Block that assumes three tiers because the product manager who specced it had three tiers.
StoryPress gives you a handful of primitives that compose like LEGO — if LEGO bricks were type-checked at compile time and validated against a universal schema. Need a testimonial? Container, textRich for the quote, images for the avatar, textRich for the name. Need a pricing table? Containers in columns with cards enabled. The system doesn't have a Testimonial component because it doesn't need one. The composition IS the component.
Fewer components means a smaller attack surface for bugs, a shallower learning curve for agents, and — crucially — less schema to keep synchronized when you swap CMS backends.
Three Formats, One Truth
It turns out that the question 'how should we represent schema to an AI?' has the same answer as most engineering questions worth asking: it depends on what the AI is about to do.
If it's composing JSON for a tool call — insert this component here with these fields — it wants the raw schema. Every field type, every option value, every constraint. The source of truth, unabridged.
If it's writing JavaScript that will execute in a sandboxed Dynamic Worker — it wants TypeScript interfaces. Union literals for option fields. Optional markers. Discriminated unions on the component field. The type system becomes the specification, and the specification becomes the prompt.
If it's browsing, exploring, getting the lay of the land — it wants the markdown summary with human-written descriptions and AI hints. Quick, scannable, opinionated.
Same data, three projections. The agent picks the lens that matches its immediate task.
The Bifurcated User
Picture two versions of the same person. Version A sits at a desk with three monitors, the CMS editor open, a staging preview refreshing in real-time, iterating on a hero section with the focused intensity of a flight controller during reentry. Version B is on a commuter train, phone in one hand, coffee in the other, dictating to Claude: 'add a blog post about the Q3 launch, use the hero with the dark gradient, keep it short.'
These are not edge cases. These are the two fundamental modes of content work, and any system that doesn't account for both is serving exactly half of reality. StoryPress calls them Connected and Headless. Connected means a WebSocket is open, a PreviewHub Durable Object is tracking your session, and every component edit broadcasts to the live preview in real time. Headless means there's no editor, no preview, no WebSocket — just the API and a direct save.
The agent discovers which mode it's in with a single call to get_session. Not by guessing. Not by trying a tool and seeing if it fails. By asking the SessionRegistry Durable Object: does this user have any open connections? The answer determines everything that follows — whether to broadcast surgical edits through the preview pipeline or push a complete story object directly to the CMS API.
About the Author
Neal Town Stephenson is an American writer known for his works of speculative fiction. His novels have been categorized as science fiction, historical fiction, cyberpunk, and baroque.
Snow Crash, published in 1992, is the novel that coined the term 'Metaverse' — Snow Crash is a 1992 science fiction novel by Neal Stephenson. Like many of Stephenson's novels, its themes include history, linguistics, anthropology, archaeology, religion, computer science, politics, cryptography, memetics, and philosophy.
The concept of the Metaverse — A metaverse is a virtual world in which users interact while represented by avatars, typically in a 3D display, with the experience focused on social and economic connection.
The Punchline
This page — seven sections, column layouts, card grids, animated gradients, prose styling, a CTA — was edited by a sandboxed JavaScript function that fetched research from Wikipedia, updated specific components surgically, and broadcast every change to a connected browser editor over WebSocket.
It left the sections it didn't need to touch completely alone.