The short answer is that HTML was never the hard part. A capable model produces correct markup without breaking a sweat. What it doesn't produce is judgement: when a table beats a set of cards, which action should be primary, when an operation needs confirmation. That information isn't in the HTML, and it usually isn't in the component API either.

That is the abstraction problem. We are asking the model to work at the lowest available level — tags and styles — when everything it needs in order to get the answer right lives two layers up.

Knowing a component exists is not knowing when to use it

Say an agent has access to Button, Card, Table, Chart and Modal. Technically it knows the catalog. But the catalog doesn't answer the questions that matter: when a table is better than cards, whether a modal may contain another modal, which variants are destructive, which actions require confirmation, which components can appear together.

An experienced designer answers nearly all of them without thinking, and not because the information lives in the props. They learned it from internal documentation, from design reviews, and from product decisions nobody ever wrote down. The agent has access to none of that.

Which turns design systems into a different problem than the one they were built for. Making components reusable is no longer enough; the logic that explains how to use them has to become machine-readable.

A component carries more meaning than its props can hold

A developer is happy to find this in the docs:

<Button variant="destructive">Delete</Button>

For an agent we probably want something closer to a tool definition: what the component does, which variants exist, what it may contain, when to use each variant, and what constraints apply.

Component: Button
Purpose: Trigger a discrete user action.
Variants: primary | secondary | destructive
Composition: May contain Text and Icon.
Guidance:
Use primary for the main action in a group.
Avoid multiple primary actions in the same context.
Use destructive for consequential actions.
Interaction: Must reference a registered application action.

Now Button stops being a visual implementation and becomes a concept the model can reason about. The same applies to layout. A Stack doesn't mean display: flex; it means these elements belong to a sequence. Tabs say these views are alternatives within the same context. A Modal says this interaction interrupts the flow and demands attention before anything else continues. For a human that meaning is implicit in how the interface looks. For an agent it is worth making explicit.

This is already happening

Through 2026 several frontend tools have moved in this direction. Storybook shipped Storybook MCP for React, which exposes component metadata, stories, APIs and documentation to agents, with the stated goal of getting them to reuse what already exists instead of inventing alternatives. Storybook stops being only the place where humans inspect components and becomes a source of truth agents can query.

Figma is on a similar path: its MCP infrastructure serves design-system information — components, variables, styles — and links it to real code through Code Connect. Even shadcn/ui started documenting the structural composition of its components explicitly:

Card
├── CardHeader
│ ├── CardTitle
│ ├── CardDescription
│ └── CardAction
├── CardContent
└── CardFooter

To a human that reads as documentation. To an agent it reads much more like a grammar rule.

Discovery, selection and composition are three problems

An agent being able to query the whole design system doesn't mean it should receive all of it in every prompt. A mid-sized company can have five hundred components, twelve hundred variants, four hundred patterns and thousands of examples. Pushing all of that into the model on every request is expensive and probably counterproductive.

The problem looks a lot like tool discovery. First you decide which components are relevant to the task. Then which of the available ones best represents the user's intent. Then how they compose correctly. It is retrieval over the design system: the agent doesn't need to memorise the product, it needs to fetch the part of the vocabulary the task calls for.

Components are probably not the interesting abstraction

Here is the more interesting part. Good designers don't think in Card + Text + Button + Modal. They think in comparison, confirmation, selection, progressive disclosure, error recovery, review, destructive action. Components are the implementation of those patterns, not the pattern itself.

A design system built for agents probably needs those layers kept apart: primitives (Text, Button, Stack, Input), components (Table, Chart, Modal, DateRange), interaction patterns (comparison, confirmation, review, error recovery) and domain patterns specific to the product — a refund flow, a portfolio comparison, a flight selection.

The pattern layer is the one that helps reasoning most. Instead of asking the agent to reconstruct from scratch how a confirmation for an irreversible operation should be designed, you can hand it:

Pattern: DestructiveConfirmation
Use when: The user is about to perform a consequential
or difficult-to-reverse action.
Requires: Explanation of consequence, explicit confirmation, cancel path.
Avoid: Using for reversible or low-risk operations.

The agent can still adapt the interface. What it no longer has to do is reinvent the interaction logic on every response.

This looks a lot like how we give agents tools

A tool definition says here is what you can do, here is what it means, here are the valid arguments, here are the constraints. A component definition for agents says exactly the same thing with "show" in place of "do". A pattern adds a third thing: here is a valid way to resolve this class of interaction.

Together they bound much of what the agent can do inside the product — tools define what it can execute, components what it can display, patterns how it can structure the interaction. We already design the APIs we give agents for the backend with some care. The frontend is next.

The research points the same way

One recent line of work questions something more fundamental: perhaps we are forcing agents to operate on abstractions designed exclusively for humans. CI4A: Semantic Component Interfaces for Agents, published in January 2026, proposes encapsulating UI components as agent-accessible semantic primitives — instead of reasoning about low-level interaction detail, the agent gets operations tied to what the component means. The authors implemented it across 23 Ant Design component categories and reported an 86.3% success rate on their modified version of WebArena.

CI4A targets web automation rather than UI generation, but the conclusion travels: agents do better when they can operate on explicit semantics instead of reconstructing them from interfaces built for the human eye. That doesn't mean agents stop needing vision. It means that when the semantics already exist inside the software, making them infer it again from pixels throws information away.

Generating the interface makes it more urgent

All of this matters more once the agent doesn't just use an interface but builds one. Proposals like A2UI let an agent describe an interface declaratively and have the client render it with its own component catalog. The catalog bounds what it can produce, which is already something. But the prior question remains — how does the agent know which component to pick — along with a more uncomfortable one: how does it know which experience is right. The protocol defines how an interface is communicated; the semantics needed to build it well have to come from the design system.

They also need to know what is forbidden

A human design system is full of negative rules nobody writes down. We don't nest a modal inside a modal. We don't put three primary actions on screen at once. We don't use a destructive pattern for a trivial operation. For an agent, those constraints can be explicit:

{
"component": "Modal",
"allowedChildren": ["Stack", "Text", "Form", "Actions"],
"forbiddenDescendants": ["Modal"]
}

Or at a higher level: a destructive action requires confirmation and cannot appear inside a purely informational surface. Some of those rules can be enforced syntactically with structured outputs and validators; others are semantic and will need evaluation. Either way the design system stops being a recommendation and starts behaving like an executable specification of the product.

And then come the tests

If the agent becomes a real consumer of the design system, how it uses the system has to be evaluated. Checking that Button renders correctly is no longer enough. You can start checking that, given "the user wants to delete an organisation", the agent uses the destructive confirmation pattern, offers a cancel path and doesn't delete immediately. Or that, given "compare these four products", it uses comparison-capable components rather than generating four unrelated cards when a structured comparison exists.

That opens a category of test that didn't exist before: agent behaviour against the design system. The question is no longer only whether the generated code is valid, but whether it picked the right components and patterns for the product.

The next consumer of your design system may not be human

Until now a design system was an interface between designers and developers. Agents add a consumer that can't lean on tribal knowledge, old reviews, or documentation written for people. It needs an explicit representation of what exists, what it means, when to use it, how to combine it, and what is off limits.

Storybook, Figma and others are already making parts of that knowledge machine-readable. The next step is to stop thinking of the design system as a component library and start treating it as the semantic API of the product. A collection of components is enough to render an interface; building one well takes the logic behind it.

So the relevant question is no longer whether an agent can use our components. It is whether we have represented the product in a way an agent can understand.