What is MX?

Content Ops is the discipline of creating, managing, improving, publishing, distributing, archiving, and retiring content across every digital channel. Machine Experience (MX) is the layer that keeps Content Ops work usable when an AI agent, or any other system, encounters the file outside the environment that produced it.

MX is the practice of making digital content readable by every machine that consumes it, so no machine has to guess.

MX is a methodology rather than a framework or a library, a way of thinking about content that acknowledges a fundamental truth: your website, your documents, and your data are all consumed by machines, and every machine deserves first-class content.

The Core Insight

For 30 years, web design served one user type: humans with visual browsers, pointing devices, and the ability to infer meaning from context.

Then AI agents arrived.

These agents don't have eyes. They can't hover. They don't infer. They parse structured markup, follow semantic hierarchies, and take explicit instructions literally.

MX accepts that building for humans alone is no longer sufficient. In an AI-mediated world, websites must work for both human visitors AND the agents acting on their behalf.

How MX Differs from Traditional Web Design

Traditional Approach

• Visual design first, structure second
• Rely on human inference ("users will figure it out")
• Accessibility as compliance checkbox
• Metadata as SEO afterthought

Machine Experience Approach

• Structure and semantics first, visual design on top
• Explicit declarations ("make intent clear for all users")
• Accessibility as foundation for agent compatibility
• Metadata as primary communication channel with agents

The shift. The brief moves past "make it look good" and onto "make it unambiguous".

What MX Is Not (Before We Go On)

MX is not SEO, GEO, AEO, Schema.org, JSON-LD, or microdata. Those are tactics and formats that operate at the discovery layer. MX is the layer above them, where an agent that has already found and parsed the page works out whether to act on what it just read. SEO got you found. GEO got you understood. MX gets you used.

How MX Works

MX has a simple architecture. It defers to every standard that already exists, then adds a governance envelope above them. Two layers, both required.

Layer 1: The standards MX defers to

MX never invents where a standard already covers the ground. The discovery layer of a well-built MX page reads like a checklist of established work:

• Schema.org for what an entity is (Product, Offer, ContactPoint, Article, Person)
• JSON-LD as one carrier for that vocabulary in the page head; microdata and RDFa as alternative carriers
• WCAG 2.1 AA for the semantic and accessibility structure that machines and assistive technologies both depend on
• Semantic HTML elements that name what each region of the page is for
• Dublin Core, EXIF, OpenAPI, RFC 9421, and other domain-specific standards for the fields they already define

A page that does this layer well is well-found, well-cited, and accessible. It is not yet ready for an agent to transact against. That is the next layer.

Layer 2: The governance envelope MX adds

Schema.org names a price. It does not say who issued the figure, when, against which booking conditions, or whether the version on the page is the version the publisher actually issued. That is the work the MX layer does. Every MX record carries:

• Provenance. Who wrote it, who maintains it (often a different person from the author), the canonical URI where the durable record lives, and a cryptographic signature the agent can verify against the publisher's public key
• Lifecycle. When it was created, when it expires, what triggered the last update, and whether a later record has superseded it
• Locale and conventions. Which decimal grouping is in force, which currency and timezone apply, which booking or contract terms the figure is attached to
• Agent affordances. What may a machine do with this record, under what terms, with what attribution
• Carrier-neutral instructions for use. The same record travels with the file when it leaves the web (PDF brochure, confirmation email, partner data feed, contract, archived court record) without losing any of the above

The two layers together do something neither layer can do alone. The discovery layer gets the file in front of the agent. The governance envelope tells the agent what to do with it. Schema.org carries the field; MX carries the version, the signer, the date, the locale, the canonical home, and the carriers the same record survives. Reading only the discovery layer is reading a price with no clock on it.

The Two Pillars Working Together

The system has two operational pillars, both required for a record an agent can act on:

• MX itself makes content machine-readable. The metadata, semantic HTML, and explicit declarations that let any machine find the content and know what it is
• REGINALD makes content machine-trustworthy. The public registry that attests who wrote the record, when it was published, whether it has been modified, and whether the version the agent is reading is the version the publisher issued

A record can be readable without being trustworthy. It can be attested without being readable. Machine-ready content needs both. The framework is open and standards-governed by The Gathering; any organisation can operate a registry on the same specification.

MX in Action: A Simple Example

Before MX (Human-Only Design)

<div class="contact-box">
  <div class="phone">Call us: 555-1234</div>
  <div class="email">info@company.com</div>
</div>

Human sees: Contact information clearly displayed. AI agent sees: Two generic containers with text. Are these contact methods? Which is preferred? What are the hours?

After MX (Human + Agent Design)

<div itemscope itemtype="https://schema.org/ContactPoint">
  <span itemprop="contactType">Customer Service</span>
  <div itemprop="telephone">555-1234</div>
  <div itemprop="email">info@company.com</div>
  <meta itemprop="hoursAvailable" content="Mo-Fr 09:00-17:00">
</div>

Human sees: Exactly the same contact information. AI agent sees: Structured contact data with explicit types, availability, and purpose.

What MX Is Not

MX is not:

• A replacement for good UX design
• Only for large enterprises
• Complicated or expensive to implement
• About choosing machines over humans
• A memory-pool design (an LLM-wiki, a vector store, an Obsidian-style knowledge base). Memory-pool architectures organize knowledge inside one system. MX is what a file carries when it leaves any system.

MX is:

• A complement to human-centered design
• Applicable to any website, any size
• Often simpler than existing approaches (explicit beats clever)
• About serving ALL users, human and machine
• The DNA a file carries when it leaves any pool, so the next reader can interpret it without inference

Frequently Asked Questions

The Business Case

Organizations implementing MX see:

• Higher SEO rankings (Google rewards structured data)
• Better accessibility scores (WCAG compliance built-in)
• Increased agent recommendations (when AI shopping agents work for your users)
• Future-proofed digital presence (as agent usage grows)
• Reduced support costs (agents answer questions correctly the first time)

Who Needs MX?

Industry Applications

E-commerce sites - AI shopping agents are already mediating 40%+ of purchases in early-adopter segments.

Service businesses. When potential customers ask AI "Find me a plumber in Seattle", structured contact data determines who gets recommended.

Content publishers - AI agents citing sources need structured authorship, publication dates, and explicit licensing.

SaaS products - Agents evaluating tools need explicit feature comparisons, pricing structures, and integration capabilities.

Any website - If you want to be found, understood, and recommended by AI agents, you need MX.

Beyond the Website

Your website is a fraction of your content estate. Contracts, policy documents, product specifications, and technical reports aren't on the web, but AI agents inside enterprise tools are already reading them, inferring what they can, guessing the rest.

Being on the web and being machine-readable are not the same thing. A PDF on a public URL is still opaque to an agent that has no context about what the document is, who wrote it, what version it represents, or what claims it makes. Web accessibility solves discoverability. MX solves comprehension.

The principles, structured data, explicit intent, declared provenance, apply whether a document is on your website, in your document management system, in a partner's inbox, or in a regulator's archive.

The Convergence Thesis

The insight central to Machine Experience:

The things that make websites work better for AI agents are the SAME things that make them work better for humans.

Semantic HTML helps screen readers AND AI agents. Explicit form labels help people with cognitive disabilities AND machine parsers. Structured contact data helps vision-impaired users AND AI shopping assistants.

MX is about good design serving all users, however they reach your content. Nothing about human experience gets compromised for machines.

Why the Plumbing Beats the Tactics

Most advice on getting cited by AI assistants still talks about the LLM as if it were one surface. It is not. ChatGPT, Claude, and Gemini have different ingestion paths and different trust signals, and the agents built on top of them add another layer of variation. A tactic that lifts your citations in one tool can do nothing in another, and the gap widens every time a vendor tightens its rules, changes its system prompt, or ships a new model. New readers arrive every quarter, parsing your pages by rules you cannot predict.

The way through that churn is plumbing, not tactics. Output what the simplest machine can read:

• Right MIME types, so each file is delivered as the type it actually is.
• A discoverable sitemap, listing the pages you want machines to find.
• An llms.txt that is actually wired up, served, listed in the sitemap, and referenced from page heads.
• Structured data that matches the rendered page, with no drift between the markup and what a visitor sees.

If the dumbest reader can parse the result, every smarter one can too. Tactics will reshuffle every few months. Plumbing does not.

Getting Started with MX

You don't need to rebuild your website from scratch. MX is adoptable incrementally, working from the discovery layer up:

1. Start with structured data - Add Schema.org markup to your most important pages so machines can find and understand what the entities are
2. Bring the page to WCAG 2.1 AA - Use it as your baseline for the semantic and accessibility structure
3. Make implicit explicit - Review forms, buttons, navigation for hidden assumptions
4. Add the MX governance envelope - Declare provenance, lifecycle, locale conventions, and canonical URI on each record so an agent knows whether the version it parsed is current and trustworthy
5. Where it matters, sign and register - For commerce, regulated content, contracts, publish the signed record to a registry so the agent can verify what the page claims rather than take it on trust
6. Test with agents - Ask AI assistants questions about your site and see how they answer

The goal is progress, not perfection.

Every layer adds value, but the discovery layer without the governance envelope is the £203,000 cruise misread waiting to happen. Schema.org names the field; MX names the version, the signer, the date, the locale, and the carrier the same record survives.

What's Next?

Now that you understand what Machine Experience is, explore:

→ Why MX Matters - The business urgency → Key MX Principles - Deeper dive on the standards MX defers to and the governance envelope MX adds → Implementation Examples - See MX in practice

Ready to implement MX at your organization?

Get MX Consultation →