La respuesta corta es que el HTML no es el problema. Un modelo capaz genera markup correcto sin despeinarse. Lo que no genera es criterio: cuándo una tabla es mejor que unas tarjetas, qué acción debería ser la primaria, cuándo una operación necesita confirmación. Esa información no está en el HTML. Tampoco está, casi nunca, en la API de los componentes.

Ahí está el problema de abstracción. Le estamos pidiendo al modelo que trabaje al nivel más bajo posible —etiquetas y estilos— cuando lo que necesita para acertar vive dos capas más arriba.

Saber que un componente existe no es saber cuándo usarlo

Supongamos que un agente tiene acceso a Button, Card, Table, Chart y Modal. Técnicamente conoce el catálogo. Pero quedan preguntas que el catálogo no responde: cuándo conviene una tabla y cuándo tarjetas, si un modal puede contener otro modal, qué variantes son destructivas, qué acciones exigen confirmación, qué componentes pueden aparecer juntos.

Un diseñador con experiencia responde a casi todas casi sin pensar, y no porque esa información esté en las props. La ha aprendido de la documentación interna, de las revisiones de diseño y de decisiones históricas del producto que nadie escribió nunca en ningún sitio. El agente no tiene acceso a nada de eso.

Eso convierte los design systems en un problema distinto del que resolvían hasta ahora. No basta con que los componentes sean reutilizables: hay que hacer legible por máquinas la lógica que explica cómo se usan.

Un componente tiene más semántica de la que cabe en sus props

A un desarrollador le basta con encontrar esto en la documentación:

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

Para un agente probablemente queramos una definición más parecida a una descripción de herramienta: qué hace el componente, qué variantes existen, qué puede contener, cuándo usar cada variante y qué restricciones tiene.

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.

Así Button deja de ser una implementación visual y pasa a ser un concepto sobre el que se puede razonar. Lo mismo vale para el layout: un Stack no significa display: flex, significa que esos elementos pertenecen a una secuencia; unos Tabs dicen que esas vistas son alternativas dentro del mismo contexto; un Modal dice que la interacción interrumpe el flujo y exige atención antes de continuar. Para un humano esa semántica está implícita en cómo se ve la interfaz. Para un agente conviene que sea explícita.

Esto ya está pasando

Durante 2026 varias herramientas de frontend se han movido en esta dirección. Storybook publicó Storybook MCP for React, que expone a los agentes metadatos de componentes, stories, APIs y documentación, con el objetivo declarado de que reutilicen lo que ya existe en lugar de inventar alternativas. Storybook deja así de ser solo el sitio donde los humanos inspeccionan componentes y empieza a ser una fuente de verdad consultable por agentes.

Figma va por un camino parecido: su infraestructura MCP sirve información del design system —componentes, variables, estilos— y la conecta con el código real mediante Code Connect. Incluso shadcn/ui empezó a documentar explícitamente la composición estructural de sus componentes:

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

Para un humano eso es documentación. Para un agente se parece bastante más a una regla gramatical.

Descubrir, elegir y componer son tres problemas

Que un agente pueda consultar todo el design system no significa que deba recibirlo entero en cada prompt. Una empresa mediana puede tener quinientos componentes, mil doscientas variantes, cuatrocientos patrones y miles de ejemplos. Pasar todo eso al modelo en cada petición es caro y probablemente contraproducente.

El problema se parece mucho al tool discovery. Primero hay que decidir qué componentes son relevantes para la tarea. Después, cuál de los disponibles representa mejor la intención del usuario. Y por último, cómo se combinan correctamente. Es, en esencia, retrieval sobre el design system: el agente no necesita memorizar el producto entero, necesita recuperar la parte del vocabulario que la tarea requiere.

Los componentes probablemente no sean la abstracción importante

Y aquí aparece la parte más interesante. Los buenos diseñadores no piensan en Card + Text + Button + Modal. Piensan en comparación, confirmación, selección, revelación progresiva, recuperación de errores, revisión, acción destructiva. Los componentes son la implementación de esos patrones, no el patrón.

Un design system pensado para agentes probablemente necesite esas capas separadas: primitivas (Text, Button, Stack, Input), componentes (Table, Chart, Modal, DateRange), patrones de interacción (comparación, confirmación, revisión, recuperación de errores) y patrones de dominio propios del producto (un flujo de reembolso, una comparación de carteras, la selección de un vuelo).

La capa de patrones es la que más ayuda al razonamiento. En vez de pedirle al agente que reconstruya cada vez cómo debería diseñarse la confirmación de una operación irreversible, se le puede dar directamente:

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.

El agente sigue pudiendo adaptar la interfaz. Lo que deja de tener que hacer es reinventar la lógica de interacción en cada respuesta.

Se parece mucho a cómo damos herramientas a los agentes

Una definición de herramienta dice esto es lo que puedes hacer, esto es lo que significa, estos son los argumentos válidos y estas son las restricciones. Una definición de componente para agentes dice exactamente lo mismo cambiando «hacer» por «mostrar». Y un patrón añade una tercera cosa: esta es una forma válida de resolver esta clase de interacción.

Las tres juntas delimitan buena parte de lo que el agente puede hacer dentro del producto: las herramientas definen qué puede ejecutar, los componentes qué puede mostrar y los patrones cómo puede estructurar la interacción. Ya estamos diseñando con cuidado las APIs que damos a los agentes para actuar sobre el backend. Va a tocar hacer lo mismo con el frontend.

La investigación apunta en la misma dirección

Hay una línea de trabajo reciente que cuestiona algo más básico: quizá estamos obligando a los agentes a operar sobre abstracciones diseñadas exclusivamente para humanos. CI4A: Semantic Component Interfaces for Agents, publicado en enero de 2026, propone encapsular los componentes de UI como primitivas semánticas accesibles al agente: en lugar de razonar sobre detalles de interacción de bajo nivel, recibe operaciones asociadas al significado del componente. Los autores lo implementaron sobre 23 categorías de Ant Design y reportaron un 86,3 % de éxito en su versión modificada de WebArena.

CI4A busca automatizar navegación web, no generar interfaces, pero la conclusión sirve para los dos problemas: los agentes rinden mejor cuando pueden operar sobre semántica explícita en lugar de reconstruirla a partir de interfaces pensadas para el ojo humano. No significa que dejen de necesitar visión. Significa que, cuando esa semántica ya existe dentro del software, obligarles a inferirla otra vez desde píxeles es tirar información por el camino.

Generar la interfaz lo vuelve más urgente

Todo esto importa más cuando el agente no se limita a usar una interfaz sino que la construye. Propuestas como A2UI permiten que el agente describa una interfaz de forma declarativa y que el cliente la renderice con su propio catálogo de componentes. El catálogo limita qué puede producir, que ya es algo. Pero queda la pregunta anterior —cómo sabe el agente qué componente elegir— y otra todavía más incómoda: cómo sabe qué experiencia es la correcta. El protocolo define cómo se comunica una interfaz; la semántica para construirla bien tiene que venir del design system.

También hay que decirles qué está prohibido

Un design system humano está lleno de reglas negativas que nadie escribe. No metemos un modal dentro de otro. No presentamos tres acciones primarias a la vez. No usamos un patrón destructivo para una operación trivial. Para un agente, esas restricciones pueden ser explícitas:

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

O a un nivel más alto: una acción destructiva requiere confirmación y no puede aparecer dentro de una superficie meramente informativa. Parte de esas reglas se pueden imponer sintácticamente con structured outputs y validadores; otras son semánticas y habrá que evaluarlas. En ambos casos el design system deja de ser una recomendación y empieza a comportarse como una especificación ejecutable del producto.

Y entonces aparecen los tests

Si el agente se convierte en consumidor real del design system, hay que evaluar cómo lo usa. Comprobar que Button renderiza correctamente deja de ser suficiente. Se puede empezar a comprobar que, ante «el usuario quiere borrar una organización», el agente use el patrón de confirmación destructiva, ofrezca una vía de cancelación y no ejecute el borrado de inmediato. O que, ante «compara estos cuatro productos», use componentes de comparación en lugar de generar cuatro tarjetas sueltas cuando existe una comparación estructurada.

Eso abre una categoría de tests que hasta ahora no existía: comportamiento del agente sobre el design system. Ya no se trata solo de validar que el código generado es correcto, sino de si eligió bien los componentes y los patrones del producto.

El próximo consumidor de tu design system puede no ser humano

Hasta ahora un design system era una interfaz entre diseñadores y desarrolladores. Los agentes añaden un consumidor que no puede apoyarse en conocimiento tribal, en revisiones antiguas ni en documentación escrita para personas. Necesita una representación explícita de qué existe, qué significa, cuándo se usa, cómo se combina y qué está prohibido.

Storybook, Figma y otros ya están haciendo machine-readable partes de ese conocimiento. El siguiente paso es dejar de pensar en el design system como una librería de componentes y empezar a tratarlo como la API semántica del producto. Una colección de componentes basta para renderizar una interfaz; para construirla bien hace falta la lógica que hay detrás.

Así que la pregunta relevante ya no es si un agente puede usar nuestros componentes. Es si hemos representado el producto de una forma que un agente pueda entender.