Making your design system agent ready

There has been a real shift in how we design and prototype products, with designers becoming increasingly comfortable vibe coding and generating prototypes on their own, and as a result the barrier between design and implementation is steadily disappearing.

If you've spent time in the world of vibe coding and tried creating production-ready screens, you already know the challenge.

The current state of things

We assume that because our design system is documented in code, components and tokens, vibe coding will give us consistent outputs.

And honestly, the outputs feel do feel magical... until something starts feeling off.

Every screen looks slightly different. Components that were supposed to be the same have different spacing. Similar elements have different visual treatments. Layouts drift from one screen to another.

What started as a fast prototyping slowly becomes a collection of inconsistent design decisions, a.k.a "design debt".

The problem becomes even more noticeable when you start working on a complete flow consisting of multiple screens, various elements, and repeated components. It gets even more worse when those designs are generated across multiple sessions.

And you find yourself repeating prompts and design decisions that should already be saved somewhere?

This is when I started exploring how to solve this for good! It's not complete, I'll continue writing and evolving this but here's a primer on how you can start thinking about this.

Your design system is built for humans

Design systems were designed to be consumed by designers and developers but this doesn't stand true today. They are now also consumed by agents.

The current design system defines a spacing as space-2: 8px. But, this really doesn't give any context to the agent of when and where to use this specific spacing value. Hence the assumptions, and hallucinations.

The problem is that they don't inherently understand the reasoning behind a design decision, unless that reasoning is explicitly communicated.

Imagine asking an AI agent to "design a promotional card component".

The agent notices that most buttons use a 4px corner radius, so it applies the same radius to a promotional card. What it doesn't know is that promotional surfaces intentionally use a larger radius to distinguish them from interactive controls.

From the agent's perspective, the decision is perfectly logical.

What it doesn't know is that cards are intent-based. They follow a different spacing scale for visual balance, a decision that exists only in the team's shared understanding, not in the design system itself.

This single assumption introduces a small inconsistency.

Over time, these small inconsistencies compound into designs that drift further away from the intended system.

The challenge becomes even greater when designs are generated across separate sessions. Without shared context or memory, each session forms its own assumptions about the same design system, leading to slightly different interpretations of the same components.

The result is inconsistent output because the design system was never built for agents to understand.

Making your design system agentic

Now that we understand how LLMs make design decisions and work with your existing design system. Let's look at how we can make our design system LLM ready.

There are primary 2 approaches to do it:

I. Moving beyond component documentation

Most current design system documentation focuses on explaining components, the foundations. This works extremely well for humans because humans can fill in the gaps and make judgment calls.

LLMs cannot.

An AI agent may know how a component works but still struggle to understand when and why a specific design decision should be made.

This is where design guidelines become critical.

Instead of simply documenting components, we need guidelines that communicate reasoning.

These guidelines, often maintained as markdown documentation, help explain:

• Why a particular pattern exists

• When a component should be used

• Dos and Don’ts of the design system

A design.md spec file is divided into 3 simple sections:

Layer 1 — Token layer

This is the section where you define all your tokens used in your project and assign them values. You can also structure components but make sure to variable names rather then directly putting values.

Layer 2 — Intent layer

This is the section where you guide the LLMs on where and when to use specific tokens.

For each section, answer: when to use specific style, when not to, what tradeoffs shaped it, and which cases are exceptions.

This section starts with an overview that defines the brand language and acts as a fallback for situations when a specific tokens or style is not found.

Here is the example of how you can structure this part:

Layer 3 — Guardrails

This is the section where you define common practises and guardrails for generations.

Now every time the agent runs, It uses the design.md files to understand your design guidelines so even if you're starting a new session, the iterations that get’s created are consistent across.

Some bonus content for you:

• Vercel recently made their design.md file available for all - https://vercel.com/design.md

• Here is how you can create a design.md file for your existing project. This is the official open sourced prompt by Google. Learn more here

• Copy this prompt in any agent in your project and it will help you generate a design.md file. The prompt goes through your readme files, text elements to understand more about your business and copy style, It also extracts visual identity and information architecture as per the information organised in existing design

• Make sure to try few iterations of the generated design.md file

II. Improve Naming Conventions and Component Relationships

Why another approach? While documentation gives an agent context, the context has a cost.

As your design system grows, so does your design.md files. Larger documentation means more tokens, slower retrieval, and more information for the agent to process before it can even begin designing.

The better approach is to move some of that knowledge into the design system itself.

Today's design systems are largely named for humans. Components are named after how they look, tokens describe visual values, and relationships between components often exist only as tribal knowledge within the team.

They benefit from a design system that behaves less like a collection of UI elements and more like an API, where every component, prop, and token communicates its purpose explicitly.

1 - Naming your components

For what they do, not how they look. Imagine an agent is generating a checkout experience.

Your component library exposes:

• RoundedCard

• GreenButton

• StatusPill

These names describe appearance, not intent.

The agent now has to infer:

• Which component displays the order?

• Which button actually completes the purchase?

• Is the status pill informational, interactive, or editable?

Now compare that with these component names. There is very little left to infer.

SummeryCard clearly represents the customer's order.

PrimaryActionButton performs the checkout action.

InfoBadge communicates information rather than inviting interaction.

The component name itself becomes documentation.

2 - Communicate intent

Names are only part of the story. Props and tokens should also describe why something exists rather than how it looks.

Instead of writing:

<Button color="green" size="large" />

Prefer:

<Button tone="confirm" priority="primary" />

tone="confirm" tells the agent that this action commits s2omething important.

priority="primary" communicates that this is the primary action on the screen.

The visual styling—green and large—becomes an implementation detail rather than the meaning itself.

A token named green-500 only describes a shade.

A token named color-action-confirm describes a role.

When an agent needs the confirmation color, there is exactly one obvious choice instead of every shade of green in the design system.

The same applies to spacing. space-card-padding tells the agent where the value belongs instead of forcing it to guess whether space-4 is intended for cards, buttons, or page gutters.

3- Define the relationship

Define how components relate to one another. Even with semantic names, one important piece of information is still missing.

How do components fit together?

Human designers understand these relationships naturally because they've worked with the system before.

Agents don't.

Instead of leaving composition implicit, define it explicitly.

SummeryCard:
  requires:
    - LineItem
    - OrderTotal

PrimaryActionButtom:
  mustBeChildOf:
    - CheckoutForm
  disabledWhen:
    - cartIsEmpty

Now the design system communicates structure instead of just individual pieces.

An SummeryCard isn't complete without line items and a total.

A PrimaryActionButton belongs inside a checkout flow and shouldn't be active when the cart is empty.

These relationships become constraints that help agents compose interfaces correctly, much like function signatures help developers write correct code.

Rather than teaching AI only how to use a component, they help it understand when and why it should be used.

That additional context dramatically improves consistency and decision-making across sessions.

Why you need an agentic design system

AI is progressing rapidly.

At this point, the question is no longer whether designers should code.

The industry increasingly expects designers to prototype their ideas directly in code from day one.

As this shift continues, our existing processes need to evolve alongside it.

An Agentic Design System helps bridge that gap.

Rapid prototyping

Brings consistency to AI-generated outputs, allowing teams to explore and iterate faster without constantly fixing design drift.

Better AI-led design audits

When design intent, relationships, and guidelines are clearly defined, AI agents can review designs more effectively and identify inconsistencies with greater accuracy.

Cleaner codebases

Reduces hard-coded values introduced through vibe coding and encourages stronger alignment between generated code and design system standards.

Closing thoughts

Design systems have always been about consistency.

Now they must help agents make those decisions too.

The organizations that adapt their design systems for agents today will be the ones that move fastest tomorrow.

Because the future isn't just designers using AI.

It's designers, developers, PMs, and agents all working from the same system of understanding.

And that makes the design system more important than ever.