For the past decade, design systems were built for humans. Designers browsed them in Figma. Developers referenced them in documentation. That model worked well — until AI agents became a meaningful part of how products are built.

AI agents now write UI code, build screens, generate components. They consume your design system. But they were never designed for. The system lives in an external tool. The agent has to be told about it each time, has to interpret it, has to guess how visual decisions translate to code. The result is familiar: inconsistency that compounds with every generated screen.

This is not an argument against Figma or hosted design systems — those tools remain valuable for human collaboration and visual design. The argument is simpler: modern design systems need to support both humans and AI agents. Right now, most don't support agents at all.

The problem — and what changes

What it looks like — the three-layer model

Three structured files do most of the work. Each layer has a distinct role — and the agent reads all three before touching any UI.

Why this matters for design leaders

This is fundamentally a question of design governance in an AI-native environment. The implications extend well beyond technical architecture.

Before the architecture — the thinking

Everything you're about to see came from a deliberate architectural decision made before any code was written. Most teams skip this step. With agentic development, that compounds quickly — agents inherit whatever structure exists, good or bad.

The reference architecture

This structure works inside Claude Code, Cursor, Windsurf, or any agentic IDE that reads project context. The file names and folder conventions map directly across tools.

Two agents. Separate responsibilities.

The most important structural decision: split UI work between two distinct agent roles.

This separation is what makes governance work. The design system agent is the gatekeeper — new components don't appear in the product without going through it. Every component that enters gets documented. The library stays accurate.

What happens when you give a task

A new component request — a countdown timer for session expiry — from task to production-ready.

How to set it up

What the key files look like

tokens.css

:root {
  --color-primary:        #1E6FCC;
  --color-danger:         #CC3B3B;
  --color-warning:        #E5900A;
  --color-success:        #2A8A4A;
  --color-text-primary:   #1A1F2E;
  --color-text-secondary: #5A6478;
  --font-sans: 'Inter', sans-serif;
  --font-mono: 'JetBrains Mono', monospace;
  --space-4: 16px;  --space-6: 24px;  --space-8: 32px;
  --radius-md: 8px;   --radius-lg: 12px;
}

component-library.md — what the agent reads

## Button
Path:     src/components/ui/Button.jsx
Variants: primary | secondary | ghost | danger
Props:    label, onClick, disabled, loading, size

Usage:
<Button variant="primary" label="Submit" onClick={handleSubmit} />

---

## CountdownTimer
Path:     src/components/ui/CountdownTimer.jsx
Variants: compact | full | banner
Props:    duration (ms), onComplete, variant, warningThreshold (ms)

Usage:
<CountdownTimer
  duration={300000}
  onComplete={handleExpiry}
  variant="banner"
/>

A screen using the library

import { Card }       from '@/components/ui/Card'
import { InputField } from '@/components/ui/InputField'
import { Button }     from '@/components/ui/Button'

export default function LoginPage() {
  return (
    <Card variant="flat" padding="lg">
      <InputField label="Email"    type="email"    required />
      <InputField label="Password" type="password" required />
      <Button variant="primary" label="Sign in" onClick={handleLogin} />
    </Card>
  )
}

Making it visible — the stakeholder subdomain

Where design systems are heading

The challenge is no longer creating a design system. The challenge is creating one that both humans and AI agents can actually use.