Design systems are agentic infrastructure now

I've been building UI with AI tools since the early Cursor days, and a lot more seriously over the last two years: Copilot, Claude Code, Cursor, opencode, etc., and no matter which tool I'm using, UI work fails in basically the same way. Ask an agent for a settings page, and you get something that looks fine for about ten seconds. Then you notice the hex codes it pulled out of its ass, the third Card component it wrote when two already existed, the div with role="button" slapped on it, and (if you didn't give it much direction) Inter on a purple gradient.

Anthropic actually has a name for that last one: distributional convergence. "Safe design choices" dominate web training data, so without direction the model samples from the middle, and a landing page "will almost always conform to Inter fonts, purple gradients on white backgrounds, and minimal animations." It's nice to have that in writing, honestly.

So the model isn't dumb. It's uninformed. It knows what a button is; it just has no idea what your button is, because nothing told it.

That's the thing I've been chewing on after reading a pile of recent writing on design systems, and I think it comes down to this: in the agentic era, a design system isn't a library for humans anymore. It's infrastructure for agents. (And no, AI didn't make design systems obsolete. If anything, it's the opposite.)

AI is a new user, and it can't read between the lines

Design systems were always written for people. A developer who's been on the team for six months knows the destructive button goes in the confirmation dialog, knows you don't put two primary buttons side by side, and knows the spacing scale skips a value for a reason somebody explained in a Slack thread years ago. None of that is written down. It never needed to be, because humans infer.

A component library used to communicate a lot just by existing. You look at the button, you look at where it's used, and you get it. An agent doesn't get it. Figma's Zoe Adelman says AI "doesn't inherently know" what designers pick up from understanding the brand and the business, and that systems now need to document "anything you might expect designers to infer without having it explicitly written in the system."

An agent will happily generate a delete button in seconds. What it won't know is that in your product, a delete button inside an alert uses the danger token and always sits next to a cancel. That's the whole problem in one example.

So AI is effectively a new user of your design system, one that needs everything spelled out in a format it can actually parse. And it's a weird user. It's incredibly fast, it never gets tired, and it has zero institutional memory. Every session starts from nothing, so whatever isn't in the context gets filled in with the statistical average of the internet. Which is exactly how you end up with the purple gradient.

Your design system is an API now

I've started thinking of a design system as the API agents use to build your product. I know that sounds like conference-talk hyperbole. But the more I've worked with agents on UI, the more I think it's just accurate. An API is a contract: here's what exists, here's what you can pass in, here's what you get back. That's exactly what an agent needs from your system.

An agent-ready system breaks down into roughly four layers.

Tokens, with names that mean something. red-500 tells an agent what a color is. color.bg.danger tells it when to use it. Semantic names are the cheapest context you can give a model, and for an agent they matter a lot more than the values do. There's also finally a standard format: the Design Tokens Community Group shipped its first stable spec (2025.10) last October. It's a Community Group spec rather than an official W3C standard, but it's stable and vendor-neutral, which is what you want from a file every tool (and every agent) is going to read.

Components that constrain. If your Button only accepts variant="primary" | "secondary", the agent can't invent variant="kinda-red". Typed props are guardrails. One component per job matters too, because every near-duplicate is one more option for the agent to pick wrong.

Rules, written down. Tokens and components say what exists; rules say when to use what. AGENTS.md (used by over 60k open-source projects and now stewarded by the Agentic AI Foundation under the Linux Foundation) and CLAUDE.md are where these go. Keep them short and testable: use semantic tokens only, check for an existing component before making a new one, extend instead of duplicating, etc. Anthropic's docs suggest keeping a CLAUDE.md under 200 lines, which is a good forcing function.

A way in. Agents reach the system through files in the repo and through MCP servers (the protocol agents use to pull context out of other tools). Figma has an MCP server (still in beta), and Storybook 10.3 added one for React (labeled a preview), so an agent can query the components and stories you already have before it invents new ones.

One caveat on that last layer: don't just point an MCP server at your existing Markdown docs and call it done. Long prose docs burn tokens, and they leave the agent digging the actual contract (props, variants, states) out of paragraphs written for humans. I think a structured description per component, in something like JSON, is the better fit. Prose is for humans. Contracts are for machines.

The repo is the source of truth

The other shift is where the system lives. I think the codebase should be the source of truth for what actually ships, with Figma as the place for exploring ideas and for working with people who don't live in the code. Mostly because agents read repos. Tokens sitting in a Figma library are invisible to Claude Code unless something bridges them over. Tokens in a file next to the components are just there.

That also changes what the real risk is. It's not that designers lose Figma. It's that now everyone can build. When several people can each ask an agent for a card, a modal, or a nav pattern, you end up with five slightly different modals, each fine on its own, pulling the product apart a few pixels at a time. Figma's Tara Nadella said it in six words at Schema 2025: "Speed without direction leads to divergence."

The design system is the direction.

Where I'd pump the brakes

I'm bought in on the framing. But a lot of the talk about agentic design systems runs ahead of what I'd actually trust.

Your rules file is a suggestion, not a guardrail. Anthropic's own docs say Claude treats CLAUDE.md as context, not enforced configuration. In my experience, agents follow rules files most of the time, which is not the same as all of the time. So anything that actually matters needs a check that fails loudly: a lint rule that rejects raw hex values, contrast checks on every PR, visual diffs against a reference page, etc.

Don't trust AI with accessibility. This is the one that bites hardest. Agents love putting role="button" on a div and calling it a day, without the keyboard handling and focus behavior a real <button> gives you for free. The first rule of ARIA is basically "use the native element if one exists", and agents ignore it constantly. The fix, I think, is to make accessibility the component library's job: focus traps, keyboard listeners, and ARIA live in tested components, and the agent only composes them. And run axe in your Playwright tests so the obvious stuff (missing labels, bad contrast, duplicate IDs) fails CI instead of shipping. Just don't treat a green run as proof: Playwright's own docs say "Automated testing cannot detect all types of WCAG violations," and a div with role="button" that ignores the keyboard is exactly the kind of thing that can slip through. If your system relies on the agent getting a11y right every time, it's going to get it wrong eventually.

Humans keep the strategic calls. AI is genuinely good at the mechanical parts. Theming tools will now generate a full set of global, alias, and component tokens from a single prompt, and that's actually useful. But brand fit, readability, and accessibility compliance stay with people. Agents can execute a design system. Deciding what it's for is still our job.

Conclusion

If you're wondering where to start: plant seeds, don't buy trees. It's tempting to watch the conference demos and want a fully autonomous agent that fixes everything on day one, but that only works on top of boring foundations: consistent naming, semantic tokens, components with typed props, and a short rules file. Skip those and the agent just reproduces your mess, faster.

Don't over-formalize either. Start lean, with what your product already repeats (colors, type, spacing, buttons, forms, navigation) and let the rest firm up as the product does. A forty-page token taxonomy for a brand that's still changing is just more stuff for the agent to get wrong.

I'll also admit a lot of this is moving fast. Figma's MCP server is still in beta, Storybook's is a React-only preview, and plenty of the "agentic design system" writing I've read is closer to a pitch than a practice. Some of this post will probably look dated within a year.

But I'm fairly confident about the core of it. The agent is going to read your design system whether you wrote it for one or not.

Write it for the agent. The humans will be fine.