Agent-Ready Design Systems

Descripción

Tu design system no está roto. Está escrito para un lector que ya no es el único que lo lee.

Durante años se han diseñado sistemas para una persona: alguien que abre la documentación, entiende el matiz, lee la excepción y decide bien. Toda la disciplina asume ese lector. Las guías de uso, los ejemplos, los "depende del contexto".

Ese supuesto se cayó. Hoy una parte creciente del código de interfaz la escribe un agente, y un agente no interpreta: toma lo que encuentra y lo aplica literal. Donde un humano duda, el agente ejecuta. Y si el sistema es ambiguo, no pregunta. Propaga.

El problema completo, en cuatro líneas

/* Documentación: el nombre describe el valor */ --indigo-600: #5b4ce0; /* Contrato: el nombre describe el uso, y el uso es único */ --color-action-primary: #5b4ce0;

Un diseñador deduce dónde va --indigo-600 y dónde no. Un agente lo pone en un botón, en un título y en un borde de error, porque nada en el token le dijo que no podía.

El bug no está en el color. Está en que el sistema sugirió cuando debía obligar.

Qué vamos a ver

En esta sesión abrimos design.ramoslabs.com, el design system AI-first de RamosLabs, y recorremos las decisiones que tuvimos que tomar para que una máquina lo consuma sin equivocarse.

1. El lector cambió y la documentación no. Por qué un sistema escrito para humanos falla al ser consumido por un agente, y por qué el síntoma nunca aparece en la documentación sino en el código que sale de ella.

2. Tokens como contrato. Nombrar por uso en lugar de por valor. Qué se gana, qué se pierde y por qué la migración duele más de lo que promete cualquier artículo.

3. La capa agéntica. Cómo un agente consulta el sistema, qué le devolvemos y por qué la respuesta no puede ser la misma página que le mostramos a una persona.

4. El costo de un sistema que miente. Qué pasa cuando la documentación queda detras del código, Un humano detecta la inconsistencia y pregunta; un agente la toma como verdad y la replica.

5. Los límites que encontramos. Lo que sigue sin resolverse, dicho con nombre propio.

La última parte es conversación abierta, no presentación.

Para quién es

Es para ti si:

• Ya tienes un design system en producción y estás viendo cómo se comporta ahora que hay agentes escribiendo código contra él.

• Estás a punto de construir uno y prefieres no diseñarlo para el lector equivocado.

• Te toca defender ante tu equipo por qué el sistema necesita reglas más duras, no más ejemplos.

No es para ti si:

• Buscas una introducción a qué es un design system.

• Esperas una demo de herramienta. No vendemos ninguna.

Formato

Modalidad: Online, en vivo

Duración: 60 minutos, más preguntas abiertas

Idioma: Español

Cupos: Limitados

Acceso: Por invitación, con código del organizador

Sobre RamosLabs

RamosLabs es una firma colombiana de software que se hace cargo del trabajo repetitivo con automatización e IA, con control, trazabilidad y gobernanza de datos.
El design system que abrimos en esta sesión no es un caso de estudio, es el que usamos. Está público y auditable:

Most systems ship components. This one ships the decisions.

213 tokens organizados en tres capas, sobre la especificación de Design Tokens del W3C, con la regla dura de que ninguna capa puede referenciar hacia arriba. Y un servidor MCP en vivo con siete herramientas tipadas, para que un agente construya contra el contrato en lugar de raspar HTML.

Todo en design.ramoslabs.com.