Name Things by What They Do: Why Semantic Tokens Are Becoming AI Infrastructure
Nov 2026A product designer's notes on design tokens, the new W3C standard, and who is really reading your design system now.
Why this is on my mind
I'm a product designer building an AI workflow layer for fashion and creative commerce. Every time a model generates something for one of our flows, I find out how good (or bad) our naming is. A color called red-500 tells a model nothing about when to use it. A color called color-text-danger tells it exactly when.
What's true right now
The format is now a real standard. In October 2025 the Design Tokens Community Group, a W3C community group, announced the first stable version of the Design Tokens Specification (2025.10). It was written by more than 20 editors and authors and is backed by reference implementations in tools such as Style Dictionary, Tokens Studio, and Terrazzo. The announcement highlights support for theming, multi-file setups, and modern color, including Display P3 and OKLCH, as covered in the group's mailing-list announcement.
The standard is deliberately about meaning, not syntax. The group's FAQ says JSON is just the syntax and the spec defines the semantics, so tools can exchange tokens reliably. That is the part I care about: a shared meaning layer between design tools and code.
The reader of your design system is changing. Builder.io argues that the primary consumer of design systems is about to be an AI agent, which means documentation has to become structured and machine-legible instead of friendly prose. A separate overview of generative UI makes a similar point: adaptive, component-based design systems are the prerequisite because a model can only compose well from parts that were designed to be recombined.
Put those together and tokens stop being a theming convenience. They are the vocabulary a model uses to talk about your product.
The three layers, and who should see which
The usual structure is primitive tokens (raw values like a specific blue), semantic tokens (purpose, like action-primary), and component tokens (like button-bg). Humans move between all three. A model probably shouldn't.
A worked example of naming by purpose
Illustrative: my own sketch, not a sourced fact.
Same screen, two vocabularies. Suppose a model is asked to add a delete confirmation. Given red-500 and gray-100, it has to guess what each is for, and a guess that looks fine will pass review. Given text-danger and surface-raised, the choice is mostly made by the names. The model is selecting a purpose, not inventing a style.
The error changes shape. With primitives, a wrong pick is a wrong color, which is hard to spot and hard to grep for. With semantic names, a wrong pick is a wrong purpose, such as using a danger token for a warning. That is still a mistake, but it is the kind a reviewer can read in the code and reason about in one pass.
My hypothesis
This section is my opinion, not a sourced fact.
Generative systems should only ever see the semantic layer. Primitives should be private.
My reasoning: if a model can reach blue-500 directly, sooner or later it will use it somewhere the semantic layer would have forbidden, because nothing in the name says not to. If it can only reach action-primary, surface-raised, and text-danger, the worst thing it can do is pick the wrong purpose, which is a far easier error to catch and a far smaller blast radius than an off-brand color. Naming becomes a safety feature, not just a convention.
I also expect semantic tokens to grow short intent notes (when to use, when not to) that are written for models as much as for humans. That is a bet, not something the spec requires.
What I would do first on a real product
My opinion, based on the tradeoffs above.
Audit the names before the values. I would list every token a generator could reach and ask of each one whether its name says when to use it. Anything named after how it looks, not what it does, is a candidate for renaming or hiding. This costs an afternoon and needs no new tooling.
Hide primitives last, not first. Removing access in one step could break existing flows that quietly depend on raw values. I would first make the semantic layer complete enough that nothing needs the primitives, then close the door. If a flow still reaches for one, that gap in the vocabulary is useful information about what is missing.
How I'd test it
Generate the same 20 screens twice, once with the full token set exposed and once with only semantic tokens. Count off-system values (colors, spacings, radii) in each batch. If I'm right, the semantic-only batch has near zero.
What would change my mind
If models become reliable enough at inferring intent from raw values and context, hiding primitives adds friction without adding safety. Today I don't see that.
Where I would not trust this yet
My opinion, based on the tradeoffs above.
A thin semantic layer pushes people back. If the vocabulary is missing a purpose someone really needs, they will find a way around it, and the model will too. Hiding primitives only works if the semantic set is generous enough to cover real work. I would not claim the safety benefit without checking that.
Names can drift. A token called action-primary that is used for three unrelated things has the same problem as blue-500, just better dressed. I would treat the intent notes as part of the token, reviewed when the token changes, not as optional documentation.
References
- W3C Design Tokens Community Group, Design Tokens specification reaches first stable version
- Design Tokens Community Group mailing list, announcement of the stable version
- designtokens.org, FAQ
- Builder.io, Designing Generative UI in an Agent-Native World
- Lazarev.agency, 6 generative UI design patterns behind real products