AI Contextsfoundations· 12 min read

AI-Ready Design Systems, Part 1: How 31 Public Design Systems Score in 2026

How AI-ready are design systems in 2026? We scored 31 public design systems on tokens, APIs, MCP, llms.txt and agent guidance. The median is 5 out of 10.

  • Nezar MansourContent Writer

Share

Summarize

Twelve of the 31 design systems we checked have an AGENTS.md file in their repository. All twelve are written for the people who build the design system: which package manager to use, how to run the tests, how to open a pull request.

None of them is written for the thousands of engineers using that design system in their own products. Those engineers' agents never open the design system's repo, so they never see the file.

That pattern runs through the whole data set, and it points to the most useful finding in it. The hard part of making a design system agent-ready is already done almost everywhere. What's missing is mostly cheap.

This is Part 1 of a two-part series on AI-ready design systems. It covers what we checked, how each system scored and what the results mean. Part 2 is the practical guide: how to make your own design system fully AI-ready, step by step.

The short version. Tokens and typed component APIs are close to universal (28 and 26 of 31 systems). After that the numbers collapse: 9 official MCP servers, 3 docs sites an agent can read in full, 3 systems with agent guidance for consuming teams. The median score is 5 out of 10 and nobody scores 10. If every system added two static files, a guidance file for consumers and an llms.txt index, the median would rise to 7 and the number of systems in the top band would go from 9 to 26.

The scoring

Five checks, two points each, all verifiable by anyone from public sources. They cover the agent-facing half of the seven criteria for an enterprise-grade design system. The other half (access control, adoption data, governance) can't be judged from outside an organisation, so it isn't scored here.

Check2 points1 point0 points
Tokens as dataPublished as JSON or JS in an installable packagePublished only as CSS or Sass variablesOnly visible on a docs site or in a design tool
Component APIs as dataPackage ships TypeScript types, a custom-elements.json manifest, or equivalent option filesMachine-readable API for some packages onlyProps described in prose, or no component package
Agent accessOfficial MCP server maintained by the design system teamPre-release official server, or a community-built oneNone
Docs agents can readllms.txt leading to full markdown contentllms.txt index pointing at HTML pagesNo llms.txt
Agent guidance for consuming teamsInstructions or skills for teams using the system, shipped in the package or published for downloadAgent instructions exist, but only for contributors to the system's own repoNone

Scores fall into three bands, based on whether a design system can only be read or can be resolved into a specific answer.

  • 0–3, Readable: built for people.
  • 4–6, Partly resolvable: the data is there, but an agent has to go and dig for it.
  • 7–10, Resolvable: an agent can connect, ask, and get an answer.
Heat map of 31 public design systems against five agent-readiness checks, sorted by score: tokens and component API rows almost fully filled, agent access, docs and guidance rows mostly empty after the leaders

Each column is a design system, sorted by score. The top two rows, tokens and component APIs, are almost solid. The bottom three, the parts built specifically for agents, empty out as soon as you move past the leaders.

What the data tells us

1. The data exists. Getting it to agents is the gap.

Across 31 systems there are 310 possible points. The systems scored 162. Of the 148 missing points, 135 sit in the last three checks: agent access, docs and guidance. Tokens and component APIs account for 13.

So the work most teams assume they need to do, restructuring tokens and cleaning up component APIs, is mostly finished. Ten years of design-token work has paid off. The data is sitting in published packages. What almost nobody has done is tell an agent where it is and how to use it.

2. Teams made their design systems agent-friendly for themselves first

Fourteen systems have agent instructions written only for contributors. Three have guidance written for the teams consuming the system.

That's an understandable order. The design system team uses agents too, and its own repo is where it feels the pain. But a design system exists to be used by other people, and their agents are getting nothing from that work.

3. The cheapest points are the ones most often skipped

The two checks with the most zeros are docs (25 systems score 0) and consumer guidance (14 score 0). Both can be fixed by publishing a static file. No new infrastructure, no new service to run.

That's where the "median 5 to 7" figure comes from. Add a guidance file for consumers to every system, and an llms.txt index to every docs site that doesn't have one, and 26 of 31 systems move into the top band. Part 2 covers how to do both.

4. Where owners haven't built agent access, users are building it themselves

The GOV.UK Design System, the U.S. Web Design System and Fluent UI each have an MCP server built and published by someone outside the team.

Nobody builds an unofficial MCP server for a design system they don't need. These are a demand signal, and they're also a risk: an unofficial server can fall out of date with the system it describes, and its users have no way to tell.

5. Public sector systems are furthest behind, and the demand is there

The five government systems in the study average 3.2 out of 10. The other 26 average 5.6. Yet two of the three community-built MCP servers are for government systems. The teams using them want agent access, and the owners haven't provided it yet.

6. This is moving quickly

Of the seven official or pre-release MCP servers we could date from npm, the oldest is Primer's, first published in August 2025. Helios published its first version on 21 September 2026, two weeks before we checked. Run this study 18 months ago and the agent access column would have been empty.

7. Even the leaders haven't solved discovery

Three systems ship guidance for consuming teams inside their npm packages: the Porsche Design System ships agent skills, DB UX ships an agent/ folder with setup instructions and a list of common AI mistakes, and Carbon by Sage publishes a component-selection skill.

But an agent working in a product repo doesn't read files inside node_modules unless something tells it to. Neither the Porsche nor the DB UX package README mentions the agent files. The guidance is in the right place, and most consuming teams won't know it's there.

The full results

Checked 5–6 October 2026. Sorted by score, then alphabetically.

Design systemOwnerTokensAPIsAgent accessDocsGuidanceScore
Ant DesignAnt Group222219
Atlassian Design SystemAtlassian222219
React SpectrumAdobe222219
CarbonIBM222118
DB UXDeutsche Bahn222028
Canvas KitWorkday222017
Fluent UIMicrosoft221117
HeliosHashiCorp222017
PrimerGitHub222017
CarbonSage220026
PatternFlyRed Hat222006
Porsche Design SystemPorsche220026
BackpackSkyscanner220015
EUIElastic220015
LeafyGreenMongoDB220015
OrbitKiwi.com220015
UI5 Web ComponentsSAP220015
U.S. Web Design SystemU.S. GSA201115
BraidSEEK220004
GC Design SystemGovernment of Canada220004
GardenZendesk220004
GestaltPinterest220004
GOV.UK Design SystemUK Government Digital Service121004
KongponentsKong220004
PasteTwilio220004
SaltJ.P. Morgan121004
ScaleDeutsche Telekom220004
CFPB Design SystemConsumer Financial Protection Bureau200002
PajamasGitLab200002
SkineBay200002
ONS Design SystemUK Office for National Statistics100001

A low score here says nothing about how good a design system is for the people using it. Several systems near the bottom are among the most respected in the field. The score measures one thing: how much an agent can get out of the system without a person in between.

How we checked

Everything above comes from public sources: the npm registry, each system's public repository, and its documentation site.

  • Tokens and APIs: we listed the files in each system's latest published packages and looked for token data and type definitions.
  • Agent access: we searched npm for MCP servers under each system's package scope and checked each docs site for MCP documentation. A server only counts as official if it lives in the owner's repository or is documented on the owner's site.
  • Docs: we requested /llms.txt and /llms-full.txt from each docs site and checked whether they lead to markdown.
  • Guidance: we looked for AGENTS.md, CLAUDE.md, Copilot and Cursor instructions in each repo, and for agent instructions or skills inside published packages, then read each one to see who it was written for.

Two systems were left out. Lion is deliberately unstyled, so a token score would be meaningless. Polaris is mid-migration from React to web components, and scoring either version would misrepresent it.

Supernova isn't in the table, because it doesn't publish its own public design system the way these organisations do.

Things change quickly here. If we've scored your system wrong, or something has shipped since 6 October, tell us and we'll update the table.

Score your own design system

Public systems are the visible part. Most design systems are private, and those are the ones agents are using every day inside companies.

We've turned the rubric into a Claude skill that scores your own design system the same way. Point it at your packages, repository and docs site, and it runs the same five checks, gives you a score out of 10, shows you which public systems you're closest to, and lists what to fix first. It also asks about access control, adoption data and governance, so you get the whole enterprise picture.

Next: how to make your design system fully AI-ready

The three systems on 9 (Ant Design, Atlassian and React Spectrum) are all missing the same point, and it's one of the cheapest in the rubric. Part 2 walks through all five checks in order of effort, smallest job first, with the public systems worth copying for each.

Give your agents a system worth following

See how Supernova documents, syncs, and serves your system in one place.