Design systems start shipping for machines.

Spotify exposed Encore via MCP. Mobbin opened its 621,500-screen library to Cursor, Claude, and Lovable on May 12. Vercel published an Agent Readability Spec. The design system used to ship components for humans; it just started shipping context for the machines writing the code.

TRACK 01 ◄◄ ► ►► Tooling · Spotify Encore, Mobbin MCP, the May rollout

The Encore turn.

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.

⚠ TRACKING ERROR · DESIGN IMPLICATION
The deliverable of a design system is widening from the component to the documentation an agent can read. If your design system has no machine-readable surface — an MCP server, an llms.txt, a /.well-known/ai-agent.json, even a single AGENTS.md at the repo root — the agents already in your codebase will route around it, and the resulting components will not look like the work you have shipped for years.
TRACK 02 ◄◄ ► ►► Technique · tokens, components, behavioural contracts

Three surfaces, one library.

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.

220K Tokens
Encore foundations in use
86K Components
Encore instances at Spotify
621.5K Patterns
App screens in Mobbin MCP

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.

⚠ STANDBY · PRACTICAL MOVE
Add one machine-readable surface to your design system this month and measure it. The simplest test is to ask Cursor to build a screen with the surface available, then ask it to build the same screen with the surface removed, then diff the result. If the two screens are indistinguishable, the documentation was already in the model's head. If the surface-aware screen is meaningfully more on-brand, the surface earned its place and you ship the next one.
TRACK 03 ◄◄ ► ►► Workflow · studio practice, after Indeed

The MDX-to-MCP pipeline.

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.

CC1 ◄ ► CC2 A design system that does not show up in the agent's context window is a design system the agent will route around — and the team's taste leaves the building one component at a time.

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.

⚠ STUDIO NOTE · SIDE EFFECT
The Indeed team reports a side effect worth flagging. Once the MCP went live, the docs site stopped drifting. The agent caught stale prose on the first generation pass — the canonical component had a new variant the docs had not learned about — and the PR thread routed the fix back to the writer the same morning. The agent is now the most attentive reader of the design system, and the system gets better because the reader keeps showing up.
TRACK 04 ◄◄ ► ►► Prompt Lab · system-first-v1

Recreate this page.

Paste this into your AI design or build tool to reproduce this issue's visual system.

> PROMPT · RECREATE THIS PAGE CH 010 · TAKE 01
Design a single self-contained HTML page as a vaporwave VHS broadcast, a lapsed cable channel rendered as a webpage. The content is a daily design-news briefing: a top nav, an issue masthead with number, date, and read time, a hero headline with a one-line deck, a boxed art-direction note, numbered sections of linked news items with one or two sentences of context each, one pullquote, a monospace prompt block, a sources list, and a colophon.

Treatment: a deep-navy field from #0D0732 to #1E0D5B; the masthead as a VHS chrome bar with a blinking REC dot, channel number, and timecode; a full-width hero of a sunset-to-magenta gradient over a perspective cyan wireframe horizon with polygon palm silhouettes and a sun cut by three navy bands; magenta #FF2EC8 plus cyan #5BFCFC color-bleed text shadows on the display headline only; sections badged TRACK 01 through 06 with transport-control glyphs; the pullquote as a burnt-in TV subtitle with closed-caption corner marks; takeaways as on-screen alerts with a magenta side bar; pearl #ECE6FF prose, coral #FF7AB3 and sunset #FFE873 accents; a faint scanline overlay.

Type: Monoton for monumental display, Space Grotesk for body, VT323 for all chrome, timecodes, and the sources list.

Guardrails: body text at least 18px with line height 1.6 or more, prose in the body face and never in monospace, line length 60-75 characters, WCAG AA contrast on every surface, hover and focus states on real links, decoration in the margins and panels rather than under running prose, no fake readable text in images, and no default AI styling (no purple-blue gradients, no glow, no pill-shaped everything). Gradients belong to the hero sky and chrome only; body prose is flat pearl on flat navy at 19px or larger.

Works in v0, Lovable, Bolt, Figma Make, Beaver Builder AI, or as a Claude / GPT system brief.

TRACK 05 ◄◄ ► ►► Field Note · editor's mark

The system was always documentation.

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.

TRACK 06 ◄◄ ► ►► Sources · verified 17 May 26

Channel listings.

A field experiment from the team behind Beaver Builder AI.