Tokens que le hablan al agente

Un valor no sabe nada de sí mismo

#1A1A1A. Un color, sin más. Dáselo a un agente y pídele que componga una pantalla: hará lo razonable, que es usarlo donde le parezca. De fondo, de texto, de borde; combinado con lo primero que tenga a mano. No por torpeza, sino porque un valor es mudo. No dice sobre qué texto se lee bien, con qué fondo no debe tocarse jamás, qué contraste cumple ni en qué momento es la elección correcta. El número está; el criterio, no.

Durante años eso no fue un problema, porque entre el token y la pantalla siempre había una persona que recordaba el criterio. Sabía, sin que nadie se lo hubiera escrito, que ese grafito era la superficie de máxima jerarquía y que solo iba una por vista. Ese saber tácito vivía en su cabeza, no en el sistema. Y un agente no tiene cabeza donde guardarlo: cada vez que compone, parte de cero.

Un token es una palabra, no un número

Una palabra, en un buen diccionario, no llega sola. Llega con su registro, con sus colocaciones (las palabras con las que suele juntarse), con aquello con lo que chirría, con lo que significa según el contexto. «Caer» no es lo mismo en «caer bien» que en «caer enfermo». El diccionario no te entrega solo la grafía: te entrega la gramática de uso, y por eso una palabra bien definida se deja usar sin que tengas que adivinar.

Un token bien hecho debería llegar igual. No solo su valor, sino su gramática: con qué se empareja, qué tiene vetado, qué garantiza, para qué existe. Un número que viaja solo obliga a quien lo recibe a reconstruir todo eso de memoria. Un token que viaja con su gramática se explica sin intermediario. Es, en pequeño, la diferencia entre diseñar el fenotipo y diseñar el genotipo: entre dejar la pantalla hecha y dejar escritas las reglas que la hacen.

$extensions: el campo donde el token cuenta su gramática

El estándar de tokens del W3C (DTCG) define lo esperable: un $value y un $type. Y deja una puerta abierta, $extensions, un espacio con tu propio namespace donde el token puede llevar todo lo que el estándar no contempla. Ahí, en ese campo que casi nadie rellena, es donde un dato deja de ser un dato y se convierte en un pequeño contrato.

{
  "color": {
    "bg": {
      "primary": {
        "$value": "#1A1A1A",
        "$type": "color",
        "$extensions": {
          "es.institutoagentico.uso": {
            "intencion": "Superficie de máxima jerarquía. Una por vista.",
            "emparejaCon": ["color.text.on-primary", "color.border.subtle"],
            "nunca": ["color.bg.accent", "color.text.muted"],
            "contraste": { "contra": "color.text.on-primary", "ratio": 14.1, "wcag": "AAA" }
          }
        }
      }
    }
  }
}

Ese mismo grafito, ahora, le habla al agente. Le dice para qué existe, sobre qué texto puede ir, con qué no debe combinarse nunca y qué contraste cumple. El agente ya no elige a ciegas: elige dentro de unos raíles que tú escribiste una sola vez.

Tres cosas que un token debería saber decir

Con qué se empareja. La mayoría de los errores de un sistema no son tokens malos, sino tokens bien elegidos puestos juntos. Un fondo correcto sobre un texto correcto que, juntos, no se leen. Declarar emparejaCon convierte la pareja en una decisión del sistema y no en una casualidad de cada pantalla.

Qué tiene prohibido. Un nunca explícito vale más que diez recomendaciones bienintencionadas, porque es lo único que detiene el error plausible: ese que parece bien y está mal. Las guías de estilo en prosa describen lo deseable; el agente necesita saber lo vetado, y lo vetado se escribe como una lista, no como un párrafo.

Qué garantiza en accesibilidad. Si el token lleva su ratio de contraste, su tamaño mínimo de impacto, su comportamiento de foco, la accesibilidad deja de ser una auditoría al final y pasa a ser una propiedad del material. Lo que el European Accessibility Act te va a exigir demostrar, el token ya lo afirma de sí mismo.

El sistema deja de depender de la memoria de nadie

El diseñador senior que sostenía todo ese criterio en la cabeza era, sin pretenderlo, el mayor punto único de fallo del sistema. Mientras el porqué viviera solo en su memoria, el sistema valía lo que durase esa persona en el equipo y lo que aguantara su atención un viernes a última hora.

Mover ese saber tácito a $extensions hace dos cosas a la vez. El agente deja de adivinar, porque el dato ya trae el criterio. Y el equipo deja de depender de quién se acuerde, porque el criterio pasó de ser conversación a ser infraestructura. Un token que carga con su propia gramática es un token que sobrevive a su autor.

Escribir así el sistema (que lo lea una máquina sin perder el juicio de quien lo pensó, y que ese juicio quede en los datos y no en la cabeza de uno) es exactamente lo que se practica, sobre tu propio sistema, en el Programa. El siguiente paso, una vez el token sabe hablar, es asegurarte de que el agente lo escucha: los cuatro controles que impiden que rompa el sistema.