Development 101
What is an agentic design system?
Agents can now build screens straight from a design system, and it is the most interesting thing to happen to design systems in a decade. The missing piece is not the agent. It is the part of the system that can say: wrong. Here is what that takes, in plain terms.
If you work with Cursor, Claude Code, or v0, you have watched an agent assemble a screen from your components in seconds. You have probably also watched it pick a grey that is almost yours, or invent a button variant you never designed. The distance between those two moments is what the phrase agentic design system is really about.
One clarification before anything else, because the term gets slippery. By design system we mean the thing design teams already run: tokens, components, patterns, and the guidance around them. Not design philosophy in general. The question on the table is what happens to that familiar artifact when its most frequent reader stops being a person, and it is a genuinely open question that the whole field is working through together.
One name, four different machines
A traditional design system standardizes UI. It ships tokens, components, and patterns, and a human assembles the product from them. A computational design system adds the logic that governs those assets: rules, constraints, and relationships, so that spacing follows from density and viewport rather than sitting in a doc as a number. At that point the system is less a library than a function: design = f(context, content, constraints). A generative design system takes a goal and produces candidates for a human to choose between. An agentic design system plans, chooses, builds, and evaluates.
The last two are the easiest to conflate, and one example separates them. Ask a generative system for three dashboard layouts and you get three dashboard layouts. Tell an agentic system you need an executive security dashboard and the reasoning in between is the product: executives read trends, not raw events, so lead with KPI summary cards, collapse the technical detail, drop to an executive density, pick chart patterns that show movement rather than volume, build the page, and check the result against the system it was built from. The difference is not output volume. It is that the second system made decisions on the way.
Laid out as a table, the differences are clearer than the marketing around them.
| Traditional | Computational | Generative | Agentic | |
|---|---|---|---|---|
| Core purpose | Standardize UI | Encode design logic | Produce options | Make and execute decisions |
| Contains | Tokens, components, patterns | Components, rules, constraints | Rules and a generation space | Context, rules, goals, reasoning |
| Human says | Use this component | Apply these rules | Generate options for this goal | Build this experience |
| Output | Building blocks | Computed UI | Candidates | A product surface |
| Explains a decision at runtime | No, though the rationale is written down | Yes, the rule is the reason | Sometimes | Unsolved |
| Verified against | Human review | The rules themselves | Human curation | Unsolved |
| Recourse when wrong | Edit the code | Change the rule, recompile | Pick another candidate | Unsolved |
Three cells in the last column say unsolved. That is not a knock on the idea. It is simply where the field honestly is in August 2026, and those three rows are where the most interesting work is happening right now, for everyone building in this space.
Drawn as processes instead of attributes, the same four look like this: what runs between a person and the product, and where the judgment sits along the way.
- Traditional (judgment stays with the human): Human → System → Product
- Computational (some judgment is encoded as rules): Human → Rules → Product
- Generative (judgment picks the winner): Intent → Generator → Options → Product
- Agentic (judgment is shared with the agent): Intent → Agent → Plan, build, evaluate → Product. Evaluation runs against the rules, and loops until the output passes.
The first column deserves a kind word too. Material and Carbon carry some of the best written design rationale in the industry. What a traditional system cannot do is explain a specific decision at the moment it is made: the rationale exists, but nothing at runtime can point to it. A written-down reason and a checkable rule are different things, and that difference is the thread running through the rest of this post.
The ladder is the wrong shape
Columns imply succession. Each stage replaces the last, the way 4G replaced 3G. That is not the relationship between these four things. The relationship is dependency.
Read bottom to top, the four types are one stack:
- Assets: tokens, components, patterns. The vocabulary.
- Logic: rules, constraints, relationships. The grammar.
- Generation: candidates shaped within that grammar. The voice.
- Agency: planning, choosing, acting, evaluating. The author.
A note on the generation layer, because the one-liner undersells it. Generation is not a neutral machine stamping out candidates. Every candidate carries a point of view: composition, emphasis, rhythm, tone. The grammar bounds the space of acceptable answers; style is a position taken inside that space. Which is exactly why the layer beneath matters so much: when nobody authors the position, the model still takes one, and it comes from the training data rather than from you.
An agent without the logic layer beneath it is not a more advanced design system. It is a model producing plausible UI with nothing to check itself against. A generator without that layer produces variety, which is not the same thing as producing options, because options implies a standard by which one of them is better.
Read as a ladder, the computational layer looks like a phase the industry passed through on the way somewhere more interesting. Read as a stack, it is the floor. Everything above it is only as trustworthy as the definitions below it.
The field’s own definitions already point here, even when the diagrams do not. The guide from Into Design Systems, drawn from talks by GitHub, Indeed, and Brad Frost at the 2026 AI Design Systems Conference, describes an agentic design system as infrastructure that lets agents read and reason over components, tokens, and guidelines, with intent and constraints encoded as machine-readable context. The Design System Guide frames the same shift as a move from a passive library to an operational layer, where a component stops being an import and becomes a contract.
Everyone agrees the interesting part is the top of the stack. Every definition rests on the bottom of it.
Verification is the row nobody prints
Almost every agentic diagram has an evaluation loop drawn into it. Almost none of them name what the evaluation runs against.
That omission matters more than it looks. An agent that generates output, reviews its own work, and ships has not evaluated anything. It has agreed with itself. Evaluation needs a standard outside the thing being evaluated, and in a design system that standard is the computational layer.
Picture the mundane version. An agent builds a settings page and reaches for a grey that is one shade off yours. Close enough to pass a glance, wrong enough to drift. Who catches it? A designer, if they happen to look at that screen that week. A system catches it only if your greys exist as a closed set that a value can fail to belong to. That is all verification means here: the rules you already have, written so a machine can check them. Not design tokens as a list of hex values, but as a set with edges. Not a usage guideline as a paragraph, but as a condition a build can break on.
Which relocates the hard work somewhere encouraging: it lands with design teams. The reasoning loop is not the scarce part. The scarce part is a precise, testable description of what good looks like in this product, for this user, at this moment in the flow. That is design knowledge. Writing it down at machine-checkable resolution is design work, and no model release will do it for you, which is exactly why it holds its value while everything above it improves.
Trust needs a way back
As decisions move from the person to the system, the question that matters day to day is not whether the system can decide. It is whether you can see what it decided, override it, and roll it back when it is wrong. Designers already know this instinct from version history; agents just raise the stakes.
Capability is the easy half. A system that makes a thousand correct choices and one wrong one, with no way to find the wrong one, is harder to live with than a library that makes none, because the failure stays invisible until a customer finds it.
The wider market gives a sense of scale here. In a June 2025 press release, Gartner predicted that over 40% of agentic AI projects would be canceled by the end of 2027, citing inadequate risk controls among the causes, and coined agent washing for tools rebranded as agentic without the capability underneath. The useful way to read that number is not cynicism. It is a checklist: wherever agents touch your product UI, ask where the decision log lives and what the rollback story is.
Recourse belongs on the comparison table because it is the row that decides whether a team can honestly trust the rest of the column.
The whole field is converging here
The encouraging part: this is not one company’s theory. zeroheight delivers documented design system context into Cursor, VS Code, Copilot, and Claude Code over MCP, and runs a structured audit before handover that flags what is off-system. Supernova, Frontify, and Figma are moving the same direction. And in June 2026 Meta released Astryx, an open-source design system built, in its own words, "for people and the agents building alongside them." When tools that disagree on everything else agree that agents need machine-readable design context, the shape of the next few years is fairly legible.
Within that convergence, two questions separate the tools, and they are worth asking of any of them, ours included.
First: what does it assume you already have? Documentation platforms make an existing design system readable to agents, which is exactly right if you have one, and a prerequisite you may not meet if you do not. Aestheria, the design context layer, ships the system itself, so a team can start from a working one. Neither approach is wrong; they serve different starting points, and knowing yours decides which is useful.
Second: does it carry assets, or judgment too? Context tells an agent what exists. Judgment tells it what good looks like here: when an action needs a confirm step, when a table beats a card grid, when a side panel beats a modal, when density should drop because the user is scanning rather than reading. A component inventory cannot answer those. A rule set can, and a rule set is also the only thing an agent can be tested against.
What we ship, and what we do not
Aestheria ships the logic layer. Tokens, constraints, component contracts, and templates, delivered over MCP so an agent reads the system instead of guessing at it. As of August 2026, Claude Code, Cursor, and Copilot all read it natively, and the docs cover the setup in a single file at project root.
The full reasoning loop above that layer is directional. We are building toward it, and the cells marked unsolved in the table are unsolved for us too. Anyone in this space claiming otherwise about their own product deserves your follow-up questions, and so do we.
The bet underneath is simple. Models improve on someone else’s roadmap, and every team gets that improvement at the same moment. A precise, testable definition of your own design language does not arrive that way. It has to be authored, it compounds as you refine it, and it is the thing every smarter agent will stand on. The substrate is the durable asset; the agent is its interface. That is the whole trajectory in one sentence: the design system stops being something an agent merely reads and becomes knowledge it can reason with.
If you maintain a design system
Three things are worth doing before any of this becomes urgent:
- Write the rules as rules. Prose in a doc site is a human artifact. If a constraint cannot fail a check, an agent will treat it as a suggestion.
- Name what verification runs against. Pick the standard your generated output gets tested on. If the answer is that a designer looks at it, you have a review process, not a system.
- Decide the recourse story early. Inspect, override, roll back. Retrofitting that after agents are writing production UI is an expensive quarter.
The shift toward agentic design systems is real, and it is further down the stack than the charts suggest. The work it asks for looks less like prompting and more like writing a specification precise enough to be wrong. That is design work, which is the good news: the teams best placed for this era are the ones who already know what their system believes.
And if your team already has a working answer to the verification question, you are ahead of most of the industry. Write it up. This corner of the field needs more notes from practice and fewer diagrams, and we read everything published in it.
Read the docs
Questions
What is an agentic design system?
An agentic design system is a design system an AI agent can read, apply, and be verified against when it builds product UI. It encodes tokens, constraints, component contracts, and usage rules as machine-readable context rather than as documentation prose. The distinguishing feature is not that an agent can generate from it, but that the system can determine whether the generated output is correct.
How is an agentic design system different from a generative design system?
A generative design system produces multiple candidates and relies on a person to choose between them. An agentic design system plans, builds, and checks its own output against an external standard before a person sees it. Without that standard, an agentic system is a generative one with a longer feedback delay.
Do I need an existing design system before AI agents can use one?
It depends on the tool. Documentation platforms make an existing, documented design system readable to agents, so they assume you already have one. Aestheria ships the system itself, including tokens, components, and the rules that govern them, so a team with no design system can start from a working one.
What does an agentic design system verify its output against?
It verifies against the computational layer: the token set, density and spacing rules, contrast floors, component contracts, and the states each pattern is allowed to have. Those have to exist as machine-checkable constraints rather than written guidance. An evaluation loop with no external standard is a model agreeing with itself.
Is MCP required for an agentic design system?
MCP is one delivery mechanism, not a requirement. What matters is that the rules reach the agent in a structured, machine-readable form at the moment it is generating code. MCP is currently the most direct route into Claude Code, Cursor, and Copilot, which is why most tools in this category use it.