Spec de sistema de diseño agéntico — Instituto de Diseño Agéntico

Un design system “listo para agentes” no es uno con más componentes: es uno que una máquina puede leer, aplicar y extender sin adivinar. Esta spec es la lista con la que se audita eso, capa por capa, de cimiento a remate. Marca cada punto. Lo que no puedas marcar es tu deuda agéntica.

1 · Vocabulario (el cimiento)

El vocabulario es lo único que un agente no puede inferir: si un color no tiene nombre ni intención, se lo inventará. Desde el 28 de octubre de 2025 existe un formato abierto y estable para escribirlo (la primera versión estable (2025.10) de la especificación de Design Tokens del W3C Community Group), así que “JSON propietario” dejó de ser excusa. Un matiz que conviene auditar: el formato base es estable y consumible hoy, pero los módulos de color avanzado y de modos/theming (el resolver) siguen en borrador, con aviso explícito de no implementar. La capa de modos es todavía pre-estándar.

Cada token tiene nombre semántico, no solo un valor (color.action.primary, no azul-600).
Cada token declara para qué sirve y cuándo no usarse, en texto legible por máquina (la propiedad $extensions del DTCG existe justo para eso).
Los tokens están en formato abierto W3C DTCG, no en un JSON propietario.
No hay valores sueltos en componentes: todo referencia un token.
Existe un único archivo fuente de verdad para el vocabulario, versionado.

2 · Componentes (las piezas)

Un componente que el agente entiende es uno descrito como dato, no como captura de pantalla: nombre, propiedades, estados y límites enumerados. Si el nombre en diseño y en código no casa, el agente recompone en vez de reutilizar, y ahí empiezan las piezas duplicadas que nadie gobierna.

Cada componente tiene reglas escritas: un único primario por pantalla, estados, qué no se permite.
Los nombres de los componentes coinciden entre diseño y código (Button/Primary ↔ Button variant="primary").
Las variantes están enumeradas y cerradas, no abiertas a interpretación.
Cada componente dice cuándo usarse y cuándo no (el anti-patrón explícito).

3 · Reglas (lo que el agente aplica)

Un principio en prosa es decoración; un principio que el agente aplica es una regla evaluable. La accesibilidad es el caso más claro: escrita una vez como criterio (no como buena intención), se verifica en cada cambio en lugar de auditarse tarde y caro.

Los principios del sistema están escritos como criterio evaluable, no como buena intención (“un error nunca se avisa solo con color: color, icono y texto”).
Hay reglas de accesibilidad ejecutables (contraste, foco, ARIA) que el sistema verifica en cada cambio.
Está escrito qué se delega a un agente y qué no se delega nunca.

4 · Exposición (cómo lo lee el agente)

De nada sirve un sistema impecable que el agente no puede consultar. Hoy la exposición tiene piezas concretas: un documento legible por máquina (llms.txt) y un servidor MCP. El servidor MCP de Figma (Dev Mode), por ejemplo, expone en el propio editor tres herramientas núcleo (código, imágenes y definiciones de variables) y se consume desde Claude Code, Cursor, VS Code, Windsurf o Codex. Con Code Connect, el código que genera reutiliza los componentes reales del repositorio en lugar de recrearlos; sin ese mapeo, como resume el equipo de Figma, el modelo adivina.

Existe un llms.txt / documento legible que describe el sistema sin ambigüedad.
Hay un servidor MCP (o equivalente) que expone tokens y API de componentes a un cliente agéntico.
Si trabajas desde Figma, los componentes están mapeados a su código real (Code Connect) para que el agente reutilice, no recree.
Los flujos que un agente puede ejecutar contra el sistema están documentados.

5 · Governance (lo que lo hace auditable)

La velocidad de un agente sin governance es velocidad para equivocarse a escala. La capa que cierra el sistema convierte cada salida en algo trazable y validable antes de producción (reglas que se comprueban en integración continua, no a ojo) y deja la rendición de cuentas en una persona.

Toda salida de un agente deja traza: qué cambió, contra qué regla, quién firma.
Hay reglas que se validan en CI (p. ej. con políticas ejecutables tipo Open Policy Agent), no solo revisión manual.
Hay un punto de validación antes de que lo del agente entre en producción.
La rendición de cuentas no se delega: hay un humano que responde.

Cómo se lee el resultado. Si marcas las capas 1 y 2 pero no la 4, tienes un buen sistema que el agente no puede consultar: invisible para él. Si marcas la 4 pero no la 1, expones ruido. El orden importa: vocabulario → componentes → reglas → exposición → governance. Cada capa se apoya en la anterior.

El estándar detrás de cada capa

Esta checklist no es una opinión del Instituto: se apoya en fuentes públicas y verificables. Para ir al origen (última revisión: junio de 2026):

W3C · Design Tokens, primera versión estable 2025.10 y el formato base, el cimiento del vocabulario. Es un Final Community Group Report, no aún una Recomendación formal del W3C.
Módulos en borrador: color y resolver/modos, la capa de modos y theming sigue pre-estándar; cítala como trabajo en curso, no como referencia normativa.
Style Dictionary · soporte del formato DTCG, implementación de referencia (de primera clase desde la v4).
Figma · Dev Mode MCP server y su documentación, cómo se expone el sistema al agente desde el IDE.
Figma · Code Connect en el MCP, para que el agente reutilice tus componentes reales en vez de recrearlos.
Model Context Protocol, el protocolo de exposición.
llms.txt, el documento legible por máquina.
Open Policy Agent · políticas en CI/CD, un patrón para la governance ejecutable.