Design systems start shipping for machines.

The Spotify Design team published a piece this month titled Can I get an Encore? Spotify's Design System, Three Years On, and the most-quoted line in it is not about humans. The Encore team found that agents had started bypassing the design system entirely — developers opened Cursor, asked for a button, got a non-Encore button back, and shipped it because the design system was too complex for the model to reason about efficiently. Encore's response was an MCP server. The documentation that lived in a docs site now answers an agent's question by the same route Cursor uses to read a Figma file.

The pattern is repeating elsewhere. On May 12, Mobbin launched its own MCP — 621,500 real app screens and 142,200 flows from shipped products, exposed as context for Cursor, Claude, and Lovable. A designer can now ask an agent how Robinhood handles its onboarding paywall and the agent answers from real shipped pixels instead of a hallucinated guess.

The component used to be the shipping unit

For a decade, a design system shipped components — a Button, a Modal, a DataTable — with Storybook entries and Figma libraries. The audience was a human reading the prop table. The agent reads differently. It wants the contract: what the component is for, what props are required, what behaviors are forbidden, which design tokens it consumes. That contract was almost always present in the docs site as English prose, scattered across a half-dozen pages, gated behind a search box agents don't know how to operate.

The new pipe puts that contract on the wire. Vercel's Agent Readability Spec describes a /.well-known surface for site capabilities that an agent can read without parsing the rendered DOM. Indeed's pipeline, presented at the Into Design Systems conference in March, auto-converts MDX docs to JSON metadata on every commit and produced 4,300 AI-generated prototypes in four months. The component still ships. The thing that changed is what ships alongside it.

The Encore writeup splits the design system into three layers, and the split is useful because the agent reads each of them differently. The bottom layer is foundations — colors, spacing, type ramps, motion curves — expressed as design tokens. The middle layer is styles — the visual appearance bound to those tokens. The top layer is behaviors — the interaction logic, often a headless library like React Aria or Radix. Encore's MCP serves each layer separately so the agent's context window holds only the layer it needs.

The numbers come from Encore's own audit and the Mobbin launch release, and they describe the same problem from two angles. Encore wants the agent to write a Spotify-flavored Button without re-inventing the design tokens. Mobbin wants the agent to design an onboarding flow without re-inventing the page layout. Both are saying the same thing: the model already knows React; what it does not know is the team's taste, and taste is what ships alongside the wire now.

The three reads, in order

An agent asked to build a new screen reads the design system in roughly the order a careful human would. It checks foundations first — are there tokens for the spacing and the color it wants to use? It checks the component layer next — is there a primitive that already does most of the job? It consults the behavior layer last, almost as a sanity pass — given the chosen component, what interactions are forbidden? When all three layers are reachable through a single MCP, the model rarely has to invent anything. When any layer is missing, it invents the whole thing.

The Vercel React Best Practices Skill shipped in February codifies the behavior layer for React specifically — forty-plus performance rules an agent consults before writing a component. The Skill format is the file-system flavour of the same idea: a directory of plain markdown that the agent reads when the task matches, rather than a doc site the model never visits.

What you actually expose

For most teams the question is not whether to ship a design-system MCP but which surface to start with. The cheapest first move is to publish the design-token JSON behind a stable URL, because that file already exists in every modern Figma-to-code pipeline. The next move is to ship a component manifest — for each component, a name, a one-line purpose, the props, the slot positions, the forbidden combinations. The third move is the harder one: the prose layer, the system's taste, the answer to when do we use a Card and when do we use a Panel. The model can guess the first two. The third is the one it cannot.

The Indeed pipeline, demoed at the Into Design Systems conference in March, is the move most worth stealing. The studio's design-system team had a problem familiar to everyone — they wrote rich MDX documentation for every component, but the docs site was an island, read by humans during onboarding and otherwise ignored. The pipeline they built reads every commit to the docs repo, walks each MDX file, and emits two artifacts: a JSON schema with the structured fields (props, variants, tokens) and a markdown distillation of the prose (purpose, usage rules, examples). Both are served behind the team's internal MCP endpoint.

The shape of the pipeline

The pipeline has four steps and a hard test at the end. A parser walks the MDX and pulls structured frontmatter and the prose body into separate buckets. A compiler converts the buckets into a versioned JSON document and a versioned markdown document, both keyed by component name. A publisher writes those documents to a static folder served by the MCP endpoint. A watcher dumps the resulting bundle into the team's eval harness on every release and re-runs a battery of generation prompts to confirm the agent still produces in-system code. The hard test fails the build if the agent's output drifts past a similarity threshold from the canonical components — the same threshold the Encore team described.

The roles, in one cast list

The cast is small. A design-system maintainer writes MDX the way they always have, treating the prose as load-bearing instead of decorative. A build agent runs the parser-compiler-publisher chain on every commit, with no human in the loop. A reviewer agent reads the published bundle the same way Cursor would, generates a fresh component, and compares it to the canonical one. A human reviewer reconciles the agent's diff with the team's intent on the PR thread. Four readers, two pipelines, one design system. The point of the cast is that the design-system team no longer owns only the components; it owns the surface that other teams' agents read.

The prompt below is what one team gives its coding agent as a project-level rule. It ships as an AGENTS.md at the repo root and as the system prompt for the team's reviewer agent. The clauses that earn their keep are 1 and 4 — the first forces an MCP query before any new component is written, the fourth forces the agent to name the design-system primitive it is extending rather than invent a sibling.

You are writing a component inside a codebase governed by a design system
served over MCP at the endpoint declared in /.well-known/design-system.json.

Before you write code:

1.  Query the design system MCP for the closest existing component to
    the requested behavior. If the result similarity is >= 0.85, do not
    write a new component — import the existing one and report which
    one you used. State the version you read.

2.  If similarity is below 0.85, query the foundations layer for the
    tokens you will need (spacing, color, type). Do not invent values
    that have a token. If a token is missing, that is the finding —
    surface it on the PR before writing the component.

3.  Consult the behavior layer for the interaction primitives. Prefer
    the headless library the system declares; do not roll your own
    focus management, keyboard handling, or aria-state if the system
    has wired one already.

4.  Name the design-system primitive you are extending in the
    component's leading comment. "// extends Encore Button v3.4" is
    a valid name. "// new component" is not.

5.  If the resulting component disagrees with the system's prose
    description on any axis — visual, behavioural, semantic —
    raise the disagreement on the PR rather than silently winning it.
    The system is the canon; your work is the variant.

Do not paraphrase the system in the component file. Link to the
MCP-served document and let the next reader follow.

The line that pays for the rest is clause 5 — raise the disagreement on the PR rather than silently winning it. Without it, the agent quietly adds a new variant whose visual idiom drifts a few degrees off the system, and the drift compounds across PRs until the design system is a museum and the live product is a different system the team did not mean to ship. With it, the disagreement surfaces as work for a human, the system either learns the new variant or the variant goes away, and the canon stays canon.

What is satisfying about this week is how little the underlying job changed. Design-system teams have been writing usage rules, props tables, and decision rationales for a decade. The work was carried by people who were told they were maintaining infrastructure for other humans, and were quietly building the most agent-ready surface on the web in the process. The rollout did not add new work. It revealed which work always mattered.

The vaporwave broadcast on the page above is fitting in the way the idiom is supposed to be fitting. A VHS lower-third reads as a system before it reads as an image — the channel tag, the time code, the transport controls, all wrapped in a chrome that knows how to be re-broadcast. A design-system MCP works the same way for an agent. The wire-format is the system; the rendered button is the artifact. The aesthetic that ships every day on this publication can rotate. The contract underneath it cannot.

1. Can I get an Encore? Spotify's Design System, Three Years On Spotify Design
2. How Spotify is Making Their Design System AI-Ready Into Design Systems
3. Mobbin Launches MCP Server — 621,500 Real App Screens for AI Tools Mobbin · 12 May 26
4. Agent Readability — a Specification for AI-Optimized Websites Vercel KB
5. Agentic Design Systems — the complete guide (Indeed pipeline) Into Design Systems
6. Vercel releases React Best Practices Skill with 40+ rules for AI agents InfoQ · Feb 26
7. Design Systems and AI — why MCP servers are the unlock Figma
8. Building a Natural Language Interface to the Spotify Ads API with Claude Code Plugins Spotify Engineering · May 26
9. How to build your AGENTS.md — the context file that makes AI coding agents work Augment Code
10. An Introduction to MCP for Design Systems Design System U