Estado 2 · Agéntico

El Estado 2 empieza cuando dejamos de tratar al agente como un problema que hay que resolver con prompts mejores, y empezamos a tratarlo como un lector al que hay que dar contexto estructurado. El salto no es técnico; es editorial. El agente lee lo que le damos. Si le damos poco, inventa. Si le damos demasiado, se pierde. Si le damos lo estructurado, compone.

Qué cambia

Seis cambios concretos separan el Estado 1 del Estado 2.

Uno. Tokens con metadatos de política

Los tokens del Estado 1 son valores con nombres. Los del Estado 2 son valores con nombres y policies. El campo $extensions.policy del DTCG 2025.10 permite declarar:

{
  "color.action.primary": {
    "$value": { "colorSpace": "oklch", "components": [0.53, 0.18, 26] },
    "$type": "color",
    "$extensions": {
      "policy": {
        "mutableBy": "agent:tier-2",
        "rollback": "auto",
        "requires": ["visual-regression-pass", "contrast-aa"]
      }
    }
  }
}

El agente lee esa declaración y sabe qué puede tocar y qué no. El humano también. La governance, que antes vivía en convenciones implícitas, vive ahora en el propio token.

Dos. Contract testing con schemas estrictos

Un Button del Estado 1 tiene props documentados en Storybook. Un Button del Estado 2 tiene además un schema JSON que describe qué props son válidos, qué combinaciones están prohibidas, qué tokens consume. Cuando un agente intenta componer <Button variant="destructive-outline-ghost">, el schema rechaza. El agente recibe un error comprensible. Reintenta dentro del espacio permitido.

Herramientas 2026: Storybook Interactions con play functions, Chromatic TurboSnap, validadores custom con Zod o JSON Schema. El principio: nada que el agente pueda proponer debe llegar a producción sin pasar por el contrato. Ver la ficha completa del Button primary con sus catorce estados, las cuatro técnicas activas en CI y las cinco variants descartadas por el camino.

Tres. Policies as code

Open Policy Agent (OPA) lleva años en el mundo de infraestructura. Traducirlo a design systems es directo: reglas escritas en Rego que evalúan composiciones antes de que se rendericen. Reglas típicas:

• Un componente Button con variant="destructive" requiere un modal de confirmación adyacente en el árbol.
• Los agentes de tier bajo no pueden mutar tokens primitive; solo semantic o superiores.
• Un DataTable con más de 10 columnas requiere un token de density explícito; no vale el default.

Estas policies se ejecutan en CI y, opcionalmente, en runtime vía WASM. Publican por qué rechazan, lo que convierte los fallos en material didáctico.

Cuatro. Telemetría de consumo

En el Estado 1 no solemos saber si <Toast> se usa mil veces al día o ninguna. En el Estado 2, con OTLP hacia Grafana o PostHog, sabemos qué componentes se renderizan, en qué rutas, con qué props, por humanos o por agentes. Esa telemetría es el feedback que el sistema necesita para evolucionar sin adivinar.

Un descubrimiento típico al activarla: el 30% de los componentes del sistema se usan menos de diez veces al mes. Material para una poda.

⁂ Lámina pendiente /images/arquitectura/kahn-servido-servidor-estado-2.jpg

Cinco. Exposición vía MCP

El Model Context Protocol, ratificado en 2024 y maduro en 2026, permite a un servidor publicar herramientas que un cliente LLM consume de forma estructurada. Un mcp.sistema.empresa.com puede exponer:

list_tokens(filter?)              → tokens disponibles
get_component_contract(name)      → schema de props
validate_composition(tree)        → OPA + tests + a11y
render_preview(tree, context)     → screenshot + reporte

El agente deja de imitar nuestro design system. Empieza a usarlo como API.

Seis. Governance restrictiva por defecto

La regla editorial del Estado 2, y este punto es deontológico, es:

El agente solo puede hacer lo que una policy explícita le permite. El espacio de lo permitido se amplía por decisión humana documentada, no por omisión.

Esto es lo opuesto al Wild West de 2023–2025, donde los agentes tenían acceso abierto y confiabamos en post-hoc review. En el Estado 2, la restricción viene por defecto y se amplía por merit.

Qué añade el Estado 2 a la decomposición

Las seis capas del Estado 1 siguen siendo las mismas (átomo, compuesto, regla, pieza, familia, estado). Lo que cambia es que ahora cada capa es auditable por máquina y puede mutarse bajo policy en lugar de por convención humana. Cuatro movimientos operativos marcan el salto:

• La regla se vuelve ejecutable. Lo que en el Estado 1 era convención (pull request, code review) se escribe en Rego y se ejecuta en CI con salida auditable. La policy rechaza y explica por qué rechaza. El rechazo es material didáctico.
• La genealogía se documenta. Cada token lleva su historia (2019 como hex, 2022 como semantic alias, 2024 como OKLCH, 2025 con $extensions.policy). La genealogía permite al agente entender la intención del cambio histórico y no sólo el valor actual.
• El desmontaje es atómico. Un componente compuesto (<Card>) se descompone explícitamente en sus unidades recombinables (<Surface> + <Stack> + <Heading> + <Action>). El agente puede recomponer dentro del espacio declarado sin inventar primitivos.
• Los descartes se catalogan. Las variants propuestas y rechazadas se documentan con año y motivo. Un compendio del Estado 2 no es solo la lista de lo que existe: es también la lista de lo que se rechazó y por qué. La memoria negativa protege del reinventar.

El riesgo que no conviene esconder

Hay un peligro editorial. Convertir el design system en algo tan estructurado que deje de ser usable por humanos sin ayuda de un agente. Ese sería el fallo. El Estado 2 no es un estado solo para máquinas; es un estado legible por máquinas y humanos. Cada decisión (cada policy, cada schema, cada metadato) debe hacer la experiencia humana igual o mejor. Si un schema te obliga a leer JSON para entender un componente, el schema es el problema.

La prueba: si un nuevo diseñador junior llega al sistema y no puede contribuir sin dominar OPA, hemos fracasado. El Estado 2 tiene que ser más amable que el Estado 1, no menos.

Qué hacer si quieres entrar en el Estado 2

1. Auditar el Estado 1 primero. Sin una base estratificada, el Estado 2 es humo.
2. Elegir un componente piloto. El <Button> es clásico. Aplica $extensions.policy, escribe su contract test, exponlo vía MCP.
3. Medir. Telemetría desde el primer día. Sin medición, no sabemos si el Estado 2 está funcionando.
4. Escribir las policies en público. Commit-able, revisable, versionable. Nada de tribal knowledge.
5. Invitar al agente a participar, no a liderar. El agente propone; la policy decide.

Qué aún no es el Estado 2

Generar componentes enteros “desde cero” con IA. Dejar al agente modificar tokens primitive en runtime. Confiar en una única evaluación humana post-hoc sin contract testing. Todo eso es Estado 1 con IA atornillada, que es una categoría peligrosa que produce falsos positivos durante meses antes de romperse.

El Estado 2, bien construido, es menos espectacular que esa versión atornillada. Pero es el único que sobrevive al primer año en producción.

Draft 1 · Mayo 2026 · Continúa en Estado 3 · Plástico