Component libraries vs a design sheet for AI-built UI

If an AI agent writes most of your UI, you need some way to keep it consistent. Two approaches come up most: install a component library into your repo and tell the agent to use it, or give the agent a design sheet it reads over MCP. This page compares the approaches, not particular products, and says plainly where each one is the better choice.

The short version#

How a component library works with an agent#

You install a set of components (buttons, inputs, dialogs, menus and so on), theme them, and ask your agent to build with them. The agent reads the components in your repo like any other code.

This works well when the library is already part of your project and the agent knows it. The weak spot is the gap between "these components exist" and "use this one, here". Unless you say so in every conversation or in a rules file, the agent may still write its own card or a new dialog animation, and the theme only covers what the library exposes.

How a design sheet works with an agent#

A sheet holds three things: foundations (colour, type, radius, spacing, shadows and a motion spring), slots with one chosen component each (button.primary, transition.modal, feedback.toast), and short rules. You fill slots from a live library where every component reads your foundations.

The agent connects over MCP. Before it builds UI it calls get_sheet; for a component it calls get_slot and gets that exact code with your values filled in. check_ui reviews what it wrote and lists anything outside the sheet. The decision about which button to use was made once, by you, and the agent looks it up rather than guessing.

Where a component library is the better choice#

• You want everything in your repo from the start, with no service between your agent and your components.
• You work offline or in an environment that can't reach outside services.
• Your app is heavy on complex controls such as data tables, date pickers and comboboxes, where a mature library's depth and edge-case handling are hard to match.
• Your team already knows a library well and has themed it to your brand. Switching away from that has a real cost.
• Budget is the deciding factor. Many good libraries are free.

Where a design sheet is the better choice#

• Your agent keeps drifting. Slots remove the choice: there's one primary button and one modal transition, and the agent is told to fetch them.
• Motion matters to you. Page transitions, list staggers, button presses and toasts are chosen like any other component and share one spring, instead of a different fade in every file.
• You don't have a visual identity yet. You can start a sheet from a starter vibe, a website you like or a description of your app, rather than theming a neutral library from scratch.
• You build for several clients or products. Each gets its own sheet, and the agent works from whichever one you name.
• You're not only on React. translate_asset returns a slot in Vue, Svelte, SwiftUI or vanilla JS with your values.

Using both#

These approaches combine well. Keep a library for the deep, unglamorous controls, and use a sheet for the parts that give the product its character: buttons, cards, navigation, transitions, feedback and whole page sections. Add a rule to the sheet, such as "use the project's existing table and date picker", so the agent knows where the line is.

How to decide#

Ask yourself a few questions:

1. Does my agent already use the components I have, without being reminded? If yes, you may not need more.
2. Do my screens look like one product, or like several built on different days?
3. Is motion part of how I want the app to feel, or an afterthought?
4. Do I need to work offline, or keep every dependency in the repo?

If drift and motion are the problem, a sheet is worth a try: the MCP setup guide gets an agent connected in a few minutes. If offline work and ownership come first, a component library in your repo is the safer choice.