Reading time:
6 min read
Last updated:
What an Agentic Design System Actually Is
A design system an AI coding agent can read. What goes in the tokens, components and docs so Cursor and Claude ship on-brand UI, and when you need one.
An agentic design system is a design system written so an AI coding agent can use it without a designer in the room. Same tokens, same components, same rules as a normal design system, but stored and described in a way that Cursor, Claude Code or a similar agent can read, resolve and apply correctly on the first try. If your engineers are already shipping UI written by an agent, and most AI-native teams are, this is the difference between a product that stays on brand and one that drifts a little further every week.
Why the normal kind stopped being enough
A traditional design system is built for people. It lives in Figma, it has a documentation site, and it assumes a human reads the guidance, makes a judgement call, then picks the right component. That assumption held for years because a human was always the one writing the markup.
That is no longer true. A lot of interface code is now generated. An agent does not open Figma, does not read the paragraph explaining when to use the secondary button, and does not know that the team stopped using the old card style six months ago. It reads what is in the repository. If the repository holds three button variants with no rule about which to use, the agent picks one, and it will pick a different one next time.
The result is not an ugly product. It is an inconsistent one. Eleven shades of grey, four spacing scales, two kinds of empty state, and nobody able to say when it happened.
Tokens an agent can resolve
The first layer is the tokens. Colour, spacing, type, radius, shadow, motion. A design system for people can get away with a token named brand-blue. An agent needs to know what that token is for, not only what it equals.
That means naming by role rather than by appearance. A token called surface-raised tells an agent where to use it. A token called grey-100 does not. It means every value in the product maps to a token, with no raw hex left in the code for the agent to copy and spread. And it means the token file is machine readable and lives next to the code, not in a design tool the agent cannot open.
Components an agent can pick correctly
The second layer is the component set. The goal here is not more components. It is fewer, with less ambiguity between them.
Every component needs a stated purpose, an explicit list of its props, and the states it is required to handle. For AI products that list is longer than most teams expect, because an AI product has states a normal SaaS product does not: thinking, streaming, partial answer, low confidence, the model got it wrong, and the user needs to undo it. If those states are not components, every engineer invents them, and so does every agent.
The test is simple. Give the system to an agent with no other context and ask it to build a screen you have never built. If it picks the components you would have picked, the system works. If it invents a new one, that gap is your next piece of work.
Rules written as instructions, not guidance
The third layer is the one most teams skip, and it is the one that does the work. Human documentation is written as advice. Prefer the primary button for the main action on a page. An agent does better with rules it cannot misread: one primary button per view, secondary for everything else, never two primaries in the same container.
In practice this lives in the files an agent already reads. A rules file in the repository root, component docstrings next to the code, and usage examples an agent can pattern match against. Written this way, the design system stops being a reference a person consults and becomes a constraint the tooling enforces.
When a startup actually needs one
Not at the beginning. A three person team building the first version of a product does not need this, and building it early is a way to avoid shipping.
The signals that it is time are specific. Your engineers are generating UI with an agent, which most AI-native teams now are. Two people can build the same screen and get visibly different results. You have started saying the product looks a bit inconsistent without being able to point at what changed. A new engineer ships something that looks nothing like the rest of the app and nobody catches it in review. Or you are about to double the surface area of the product and you can already feel the drift.
If none of that is happening yet, write the token file and stop there. That one file is most of the value and takes a day.
What it costs to skip
The cost is not paid in design. It is paid in speed. Once the product has drifted, every new screen starts with an argument about which pattern is correct, and every agent-generated change needs a human to check it against a standard nobody wrote down. The tooling that was supposed to make the team faster starts needing supervision, which is the opposite of the point.
Fixing it later is also more expensive than building it early, because by then you are not writing a system, you are reconciling one against a product that already exists in five slightly different versions.
What a studio actually builds
If you bring this to a design studio, the work is a token file your code can import, a component set covering your real screens including the AI states, and a rules file written for the agent rather than for a person. On top of that, a short audit of where the current product already disagrees with itself, so you know what you are reconciling.
It is a fixed scope piece of work, usually a few weeks, and it is worth doing before a big build rather than after one.
Studio Maydit builds product design systems for AI-native teams in the US, UK and Europe, including the agent-readable layer described above. If you are about to expand the product and can already see the drift, book a 30 minute intro call and we will tell you whether you need a system yet or just the token file.
Related reading
Frequently Asked Questions
Continue Reading
ChatGPT Is Introducing Ads. Here’s the UX Risk Nobody Is Talking About
As ChatGPT prepares to introduce ads, most conversations focus on revenue and scale. But the bigger question is how monetization reshapes user trust, cognitive flow, and product intent. This Studio Notes piece explores the hidden UX risks product teams should pay close attention to.
Siddarth Ponangi
Why designing for power users too early breaks SaaS products
Many SaaS products become difficult to use not because they lack features, but because they introduce complexity before users are ready for it. Designing for power users too early often feels like progress, but it quietly undermines adoption for everyone else.
Siddarth Ponangi
Why second-use experience matters more than first impressions in SaaS
Many SaaS products spend enormous effort optimizing first impressions. What often gets overlooked is what happens when users come back for the second time, which is usually where real adoption either starts or quietly falls apart.
Siddarth Ponangi