What Makes a Design System Agentic?

A scheduled audit once handed me a number I refused to accept: a little over three thousand colors across the UI pointing at the wrong token — on a system I'd have sworn, that morning, was clean. Most of them were icons. Quietly mis-routed months earlier, invisible in light mode, sitting there waiting to break the day someone shipped dark mode.

Nobody had been careless. No single person had done anything wrong. The system had simply done what every design system does the moment you stop watching it: it drifted.

I'll be honest — my first instinct was that the audit was wrong. (It was not. I was.) And that gap, between how correct I believed the system was and how correct it actually was, is the whole subject of this piece.

Because most "design system" conversations are about how it looks — the components, the spacing, the dark mode. Agentic is about something else entirely: how the system stays correct over time, and who does the work to keep it that way.

In a traditional system, the thing that hears about it is a person. Someone notices the button drifted, opens two files, fixes it by hand. In an agentic system, the thing that hears about it is the system itself. This is the full picture of that shift — what it means, what it's built on, and how to tell which side of the line you're on. (Want the build steps instead of the concepts? That's the companion guide — linked at the end.)

An agentic design system is one a machine can read, verify, and modify without a human guiding every step. That's the whole definition. The tokens and components stop being passive documentation and become structured data an agent can act on.

The unlock is making every decision legible to software. Three moves do most of the work:

Once the system is legible like this, an agent can do real work on it: generate a screen with the right tokens, flag a hardcoded color, re-theme everything for dark mode — without stopping to ask you which value to use. The same structure that makes it readable to a machine, by the way, makes it harder for a human to get wrong. That's not a side effect. That's the point.

Here is the part nobody photographs for the case study. Designing a design system is maybe 20% of the work. The other 80% is keeping design and code in agreement while both keep changing — and that 80% is exactly where traditional systems quietly fall apart.

A color shifts in design. Code doesn't hear about it. A new contributor hardcodes a hex because they couldn't find the token. A component gets copied with a one-off override. None of it is dramatic. All of it compounds. Six months later the "single source of truth" is true in three places and wrong in five — and you're back to my three thousand icons.

The traditional answer to drift is human attention: someone has to notice, then hunt down every copy, then fix them by hand. That doesn't scale. It just turns into a tax you pay in people — and the bill grows with the system.

I want to be precise about where my certainty ends here. I'm confident about the structure — tokens as data, a real pipeline, generated docs, a checking loop. I'm less sure anyone has fully solved the governance of it (more on that later). But the structural claim is the one I'd defend in any room: the work that breaks design systems is maintenance, and maintenance is the thing you can move into the system itself.

Everything agentic rests on one idea: the design decisions are stored as data, not pictures. That's what lets every other layer — code, docs, audits — be derived instead of maintained.

A portable token format (DTCG is the emerging standard) holds the value, the modes, and the usage rules together:

That single object feeds three things at once: the code (compiled to CSS variables and typed tokens), the docs (the usage notes are the documentation), and the audits (a checker knows the value, so it can spot anything that doesn't match). Write the decision once; everything downstream reads it.

This is where the abstract turns concrete. On a large enterprise system I worked on, roughly 386 tokens each carry their own usage notes, and a single command keeps a ~245-row usage table in sync with the design tool's variable descriptions — bidirectionally. Push if the table is ahead. Pull if the variable is. Flag a conflict if both changed. The documentation literally cannot drift from the system, because it's generated from the same data the code compiles from. (The first time I watched it reconcile a conflict on its own, I genuinely wasn't sure whether to trust it. I do now — because it shows its work before it writes anything.)

The difference isn't visual. It shows up in how the system stays correct:

Put the agentic column together and it forms a loop — and every arrow can be run by an agent, not a person:

You don't need all five to start — but the more you can check, the more the system runs itself.

Read that list as a gradient, not a gate. Most teams I've seen can honestly tick one or two today. That's not failure — that's the starting line.

The heart of "agentic" is that last sign: the system checks its own work. Three moves, all automatable:

This is where those three thousand icons get their ending. A single corrective sweep re-bound roughly 3,000 stray colors in one pass — most of them icons mis-routed to the wrong token. No human finds three thousand of those by hand; you'd lose a week and miss half. The reason I could let that run unattended is the two properties that matter most here: the audit and fix commands are idempotent (run them on a clean system and nothing happens) and gated (mutations wait for you to type apply). You trust the loop not because the agent is perfect — it isn't — but because it can't act without showing you the diff first.

That's the real translation of "agentic." Not the machine decides. The machine proposes, proves, and waits.

I don't want to pretend the field has this solved, because it doesn't, and neither do I. The structure is clear to me. The governance around it is where it gets genuinely hard, and these are the questions I haven't fully answered:

Who owns a semantic token decision when the product team, the engineering team, and the design system team all have a legitimate, different stake in it? The data layer makes the change easy. It doesn't tell you who's allowed to make it.

How do you keep a system honest while you're also shipping features on top of it? The team maintaining the system is usually the same team under deadline pressure to use it. The loop helps. It doesn't resolve the tension.

How do you encode intent, not just structure? A token can say where it goes. Teaching it why — the judgment a designer carries about when a rule should bend — is a problem I can describe better than I can solve.

I'm naming these because they're more interesting than the parts I'm sure about. If you've got a real answer to any of them, I'd genuinely like to hear it.

You don't go agentic in a weekend — you move along the spectrum. The order that compounds fastest:

What is an agentic design system, in one sentence?

A design system structured so software agents — not just people — can read it, verify it against its source of truth, document it, and repair drift automatically, because the tokens and components are stored as machine-readable data with the rules baked in.

Do I need AI agents to have one?

No. "Agentic" just means the system is operable by agents — the same structure (portable tokens, a real pipeline, generated docs, automated checks) makes it more reliable whether a person or an agent runs the loop. Run it by hand today and hand pieces to agents as you go.

Isn't this just "design tokens"?

Tokens are the foundation, not the whole thing. Plenty of teams have tokens and still hand-sync code, write docs by hand, and find drift by luck. Agentic is what you get when tokens are data that also drives the pipeline, the docs, and a self-checking loop.

How is this different from a normal design system in Storybook?

Storybook documents components for humans to browse. Agentic adds the machine-operable layer on top: tokens as portable data, a deterministic build, generated docs, and self-checking audit/fix loops. Storybook is a great place to render the system; it isn't, by itself, what keeps it correct.

Won't the automation make mistakes?

It will — which is why verification and auditing exist. Diffs and audits are the guardrails; fixes are gated and produce a reviewable change. You trust the loop because it proves its own work, not because the agent is assumed to be perfect.

Where's the single highest-leverage starting point?

Make tokens the one source of truth, then audit for hardcoded values. Everything else — the pipeline, the docs, the self-healing loop — builds on having one place where the truth lives.

A design system you maintain by hand fights you a little more every month. An agentic one gets steadier as it grows — because the rules live in the data, and the checks run themselves.

The question was never whether your system looks good. It's whether it can keep itself honest.

Build the one that does.