Design system governance for AI agents: 6 rules for 2026

A machine-readable design system is a design system published as structured data (tokens, a component manifest, usage rules) that AI coding agents query through an interface such as an MCP server, so the UI they generate uses the components and decisions the team has already approved. Once agents read it, the design system behaves like an API: it has consumers that cannot ask a colleague, cannot guess intent, and fail on every undocumented change.

This matters to the team that owns a design system and has started to see Cursor, Claude Code or Copilot write screens against it. The tooling arrived fast. Figma's MCP server feeds variables, components and Code Connect mappings to agents. Storybook generates a JSON component manifest for its MCP server. Google Labs published DESIGN.md as an open format. Governance was written for human readers, and it has not caught up. Here is what changes, and the six rules we apply.

What changes when the reader of a design system is an agent?

A human reader fills gaps. A designer who finds two shades of the same blue asks which one is current. A developer who sees a deprecated prop in Storybook reads the note and moves on. An agent does neither. At the AI Design Systems Conference 2026, speakers named documentation drift as the first failure mode: when docs, tokens and components disagree, the agent picks whichever source it found first, according to Into Design Systems' write-up of the talks. In the same report, Romina Kavcic puts pure maintenance at 30 to 40% of a design system team's time.

Three things follow.

• Drift becomes output. An inconsistency that used to cost a review comment now ships in every screen an agent generates.
• Prose loses to structure. A usage note inside a paragraph is advice to a person and noise to a model looking for a field.
• Every change has callers you cannot see. Prompts, rules files and saved context in a dozen editors depend on names someone might rename on any Tuesday.

What a machine-readable design system is made of in 2026

Four parts, each with a format that settled in the last year.

• Tokens. The Design Tokens Community Group published the first stable version of its specification, 2025.10, on 28 October 2025. It defines a vendor-neutral JSON format with aliases, themes and a $deprecated property that a tool or an agent can read.
• A component manifest. Storybook generates manifests, JSON objects listing each component with its props, stories and docs, and serves them to agents through its MCP server. Storybook labels the feature as preview, and the manifest schema is not yet a stable public API.
• Design context. The Figma MCP server gives agents the variables, components and screenshots of a file, and Code Connect maps each Figma component to the code component that implements it.
• Rules and rationale. DESIGN.md, open-sourced by Google Labs, puts tokens in YAML front matter and the reasons behind them in Markdown prose. Its schema still reports version "alpha". AGENTS.md files carry repository instructions the same way.

Murphy Trueman did the count: one design decision can now live in five places, and most teams have no clear answer to who owns the agent-facing layer. That is the governance gap.

Does the format matter?

Yes, and there is data. Diana Wolosin at Indeed parsed 77 components from MDX documentation and ran 1,056 prompts across eight MCP configurations. With Markdown, each query cost about 30,000 tokens, covered 82% of the answers and produced hallucinations. JSON metadata answered more accurately with 80% fewer tokens, at about a fifth of the annual cost, as Into Design Systems reports. The working rule that came out of it: structured data (props, variants, sizes, allowed values) goes in JSON, and rationale stays in prose for when the model needs the why.

The six governance rules

1. One source of truth, everything else generated

Pick the source for each kind of decision and generate the rest from it. Token values live in the DTCG JSON file; the Figma variables, the CSS custom properties, the DESIGN.md front matter and the manifest's token references are build outputs. Component APIs live in the code, and the manifest is derived from the code and its stories. A file that an agent reads and a person edits by hand will drift, and the agent will trust it anyway. Hand-written files keep only what cannot be derived: intent, trade-offs, the cases where a component is the wrong choice.

2. Version the agent-facing layer like a public API

Apply semantic versioning to what agents read, alongside the package. Renaming a token, removing a variant or changing a prop's allowed values is a major change for an agent, even when the visual output is identical, because rules files and prompts reference the old name. Deprecate before removing, and put the replacement in the data: a $deprecated string on a token that names its successor, a deprecated field on a component that points to the new one. Agents read fields. The changelog rarely reaches them.

3. Name one owner for the agent-facing layer

In Trueman's account, tokens tend to sit with the design system team and AGENTS.md with engineering, while the Figma MCP setup stays with whoever installed it. When nobody owns the sum, nobody notices that the manifest stopped regenerating three releases ago. One person or one team signs off on every change to what agents read, with the review a public API change gets. The governance model for a design system with many consumer projects applies here unchanged: agents are one more consumer, and the most literal one.

4. Write usage rules as data

"Use the destructive button only for irreversible actions" is a sentence. {"intent": "destructive", "use_when": "the action cannot be undone", "requires": "confirmation dialog"} is a rule an agent can check. Move every rule with a yes-or-no answer out of prose and into fields: when to use, when not to use, required companions, the replacement. Keep the prose for judgement calls. Teams that already follow a strict token naming convention have done half of this work, because the name carries the intent.

5. Decide what an agent may change

Agents now propose edits to design systems too: token updates, documentation fixes, new stories. Write down which changes an agent may make and on what terms. One tiering presented at the conference: automatic fixes for low-risk changes such as lint errors and accessibility labels, draft pull requests for token values and descriptions, and suggestions only for new component APIs, breaking changes and governance decisions. At GitHub, agents working on the Primer design system can open an issue and cannot merge code, per the same report.

6. Test what agents produce, on every release

A design system used to be tested at its own boundary: the component renders, it passes its accessibility checks. With agents, the boundary moves to the output. Keep a fixed set of prompts (a settings page, a pricing table, an empty state) and run them against the agent-facing layer on every release. Check the generated UI for components that do not exist, raw hex values and props outside the allowed set. Storybook's MCP server already points this way: the agent writes stories for what it generated and runs interaction and accessibility tests on them. Add a CI check that fails when the manifest, the tokens and the code disagree, so component drift shows up as a red build before it shows up in a generated screen.

What this looks like on one component

Take a Button with a variant prop that once allowed danger and now uses destructive. Under governance built for people, the rename ships with a changelog line and a codemod. Under API governance, four things change in the same release:

1. The code keeps accepting danger for one major version and marks it deprecated in its types.
2. The manifest, regenerated from the code, lists danger as deprecated with destructive as its replacement.
3. The token button.danger.background carries "$deprecated": "Use button.destructive.background".
4. The prompt suite runs, and any generated screen that still writes danger fails the check.

The rename costs an extra afternoon. In exchange, no agent keeps generating the old name for months from stale context.

When it is not worth it yet

A team with one product, a handful of components and no agents writing UI gains little from manifests and prompt suites. The cost is real: pipelines to generate files, a review step on every metadata change, a test suite to maintain. Two signals say the time has come: agents already generate screens in the codebase, or more than one product consumes the design system. In both cases the agent-facing layer exists whether anyone governs it or not, and the work above costs less than cleaning up what an ungoverned one produces. We covered the design side of that handoff in our Figma MCP walkthrough and the interface side in designing a UI for AI agents.

Sources

• Design Tokens Community Group: Design Tokens specification reaches first stable version
• Design Tokens Format Module 2025.10
• Storybook docs: Manifests
• Storybook docs: MCP server
• Figma Learn: Guide to the Figma MCP server
• Google Labs: DESIGN.md format specification
• Into Design Systems: Your design system is not ready for AI agents
• Murphy Trueman: Your design system is fragmenting into agent files
• Semantic Versioning 2.0.0