Content That Manages Itself
I've spent decades building content systems. Content management systems, specifically. And the dirty secret of every CMS I've ever worked with is this: the content doesn't manage anything. Humans do all the managing. The content just sits there.
Think about what happens when you publish a page today. Someone writes it. Someone else tags it with metadata. A third person assigns it to a workflow. A developer wires it into navigation. An SEO specialist checks the meta descriptions. A compliance officer reviews the accessibility. An operations person monitors whether the links still work six months later.
The content itself? Passive. Inert. A lump of HTML waiting to be acted upon.
That was fine when humans were the only audience. It's not fine any more.
In January 2026, Amazon, Microsoft, and Google all launched AI agent commerce. Machines are now browsing, evaluating, and buying on behalf of consumers. Your content isn't just being read by people with browsers. It's being parsed by agents that need to understand what they're looking at, instantly, without a human in the loop. If your content can't introduce itself to a machine, you're already behind.
I started asking a different question. What if the content carried its own instructions?
The metadata layer we always wanted
Every CMS professional knows the value of good metadata. We've been fighting for it for years. Tag your content properly. Fill in the fields. Please, for the love of all that is holy, write a meta description that isn't just the first paragraph copied and pasted.
The problem isn't that people don't understand metadata. The problem is that metadata lives in the CMS, not in the content. Move the content to a different system and the metadata stays behind. Export it as a file and the structure is gone. Hand it to an AI agent and it has to guess what the document is about.
There's a simpler approach. Put the metadata in the document itself.
YAML frontmatter at the top of a markdown file. A few lines that declare what this document is, who it's for, what it depends on, and what it provides. The document carries its own identity everywhere it goes.
---
title: "Installation Guide"
audience: ["developers", "machines"]
requires: ["node-18", "git"]
provides: ["project-setup", "dependency-configuration"]
status: active
---This isn't new technology. YAML has been around since 2001. Markdown is everywhere. The combination is standard practice in static site generators, documentation systems, and developer tooling. What's different is treating this metadata as operational infrastructure rather than decorative afterthought.
A document that declares its audience can be routed by a machine. One that declares its dependencies can be validated automatically. Add a provides field and other documents can reference it by capability rather than by filename. The metadata does the work.
The content just told you what it is. You didn't have to ask.
When documents carry instructions
Self-describing content is useful. Self-acting content is where it gets interesting.
I've been building a system where certain documents contain their own execution logic. Not in some proprietary scripting language, but in plain metadata that an AI agent can read and act on.
Here's a real example. We have an INSTALLME.md at the root of our project. It's a markdown file that any human can read. Clear headings, numbered steps, prerequisites listed up front. Standard documentation.
But it also carries structured metadata: prerequisite check commands, minimum versions, installation steps in order, and verification criteria. When an AI agent encounters this file, it doesn't guess how to set up the project. It reads the instructions, checks the prerequisites, runs the steps, and verifies the result.
The document is the program. The AI agent is the runtime.
This pattern extends further than installation guides. We build self-contained documents we call cogs — short for components of governance. Technically, they're markdown files with structured YAML frontmatter. In business terms, think of them as SOPs that machines can actually read.
Every organisation has standard operating procedures. Onboarding checklists. Deployment runbooks. Content approval workflows. Security review processes. They live in wikis, shared drives, people's heads. Humans read them, interpret them, and carry out the steps. Machines can't touch them.
A cog changes that. Here's what a deployment runbook looks like when the procedure carries its own metadata:
---
name: release-process
type: action-cog
runtime: runbook
requires:
- security-review
- api-governance
provides:
- production-deployment
owner: platform-team
review-cycle: quarterly
---Below that YAML block sits the same plain-language runbook your team already writes. The difference is the machine-readable header. An AI agent reading this file knows what the procedure requires before it starts, who owns it, and when it was last reviewed. Your deployment runbook isn't just steps on a page. It's an instruction set a machine can validate and act on.
The SOP becomes the system. Not a description of the system. The system itself.
SOPs that know their own dependencies
Here's where it gets interesting for anyone running content operations. When every procedure declares what it provides and what it requires, you get an organisational dependency map for free.
Your security review SOP provides "authentication-overview." Your API governance SOP requires "authentication-overview" and provides "api-security-patterns." Your release process requires "api-security-patterns." Those requires and provides fields in the YAML frontmatter are all it takes.
Nobody had to build that hierarchy manually. No taxonomy needed configuring. No graph database, no dedicated tooling. The procedures declared their own relationships using two fields in a text file. A machine reading the release process knows it needs the API governance SOP first, and that SOP needs the security review. The reading order, the prerequisites, the knowledge chain — all explicit in the content itself.
This is what I mean by content that manages itself. Not content that magically rewrites itself. Content that carries enough information about itself that machines can do the managing humans have been doing manually for decades.
Stale procedure? The SOP declares its dependencies, so a machine can check them. Missing prerequisite? The document says what it needs. Outdated? It carries a version and a last-updated date. None of this requires a human to notice the problem first.
What this means if you build content systems
If you run the business side of a CMS operation, here's the headline: self-managing content reduces the human overhead of content governance. Your teams spend less time tagging, routing, checking, and chasing. The procedures carry their own rules. Machines enforce them. People focus on the work that actually needs human judgement.
If you're a CMS vendor or architect, the technical implication is significant. The traditional CMS model assumes content needs a system wrapped around it. Content goes into the CMS. The CMS provides structure, workflow, metadata, permissions, publishing. Without the CMS, the content is just files.
Self-managing content inverts that. The content carries its own structure in standard formats — YAML, markdown, plain text. No proprietary schema. No database dependency for the metadata layer. The CMS becomes a coordination layer, not a container. It orchestrates rather than imprisons. This doesn't make CMS platforms irrelevant. It makes them lighter. Let the content handle the content concerns. Let the CMS handle the people concerns.
If you're a content strategist, think about what this means for governance. Today you maintain taxonomies, tagging guidelines, and style guides as separate documents that people are supposed to follow. With self-managing content, the governance rules live in the content itself. A document either has the required frontmatter fields or it doesn't. A machine can validate that in milliseconds across thousands of documents.
If you're bringing AI agents into your content operations, this is the missing layer. AI agents are capable but they need structured context. They need to know what a document is, what it's for, who should act on it, and what it depends on. Today, that context lives in CMS databases, in people's heads, in tribal knowledge spread across Slack channels. Self-managing SOPs put that context in the one place every agent can read it: the document itself.
The simplest version of this
You don't need a new platform to start. Take a markdown file. Add YAML frontmatter. Declare the title, the audience, the status, and what the document is about. That's it. The document now carries its own identity.
Next step: add dependency declarations. What does this document require a reader to already understand? What does it provide? Now the document knows where it fits in a larger body of work.
Next step: add instructions. What should happen when someone — or something — encounters this document? What actions can be taken based on it? Now you've got an SOP that machines can follow.
Each step is incremental. Each step uses existing standards. Markdown, YAML, plain text. No proprietary formats. No new platforms to learn. No vendor lock-in.
The content just got a little smarter. And you got a little less busy.
The direction this goes
I've been running a system built entirely on this pattern. The SOPs ARE the system. The documentation IS the configuration. Plain text files are the platform. Every procedure declares itself, relates itself to others, and in some cases executes itself.
It works. Not theoretically. In production, with AI agents reading and acting on content daily. We built a registry for these self-managing documents — a place where AI agents look up verified, governed SOPs instead of guessing. The registry is live. The documents are real. The technology is nothing exotic — markdown, YAML, git, standard tooling your developers already know. The business outcome is what matters: the overhead of managing content drops because the content carries the management burden itself.
Organisations are gaining machine workers alongside human workers. Content operations built for humans alone will struggle to serve both. Content that manages itself — procedures that describe themselves in ways both people and machines can read and act on — is how you bridge that gap.
The technologists on your team will recognise the patterns. The business people will recognise the savings: less manual overhead, machine-enforceable governance, AI-ready content from day one.
Start with one document. Add a frontmatter block. See what changes.
About the author: Tom Cranstoun has been building content systems since 1977. From assembler code to Adobe Experience Manager to whatever comes next, the constant has been making content work harder so people don't have to.
Follow Tom on LinkedIn for more on Machine Experience and the future of content that works for humans and machines alike. Read more at allabout.network. Or reach out directly at tom@digitaldomaintechnologies.com.