Un día en la vida de un token.

La mayoría de las explicaciones de cómo funciona un sistema multi-agente empiezan desde arriba — el orquestador, el diagrama de arquitectura, las cajas y las flechas. Esta empieza desde abajo, con la cosa más pequeña de todo el sistema, y la deja hablar. Conocé a un token. Lo creaste hace un momento, sin notarlo, al escribir una palabra. Este es su día. Todo lo de abajo es, técnicamente, lo que pasa adentro del runtime de GOGOGO LLC — solo que contado desde una altura inusual.

06:00 — Nazco

No existí hasta que apretaste una tecla. Escribiste una pregunta en una caja, y un proceso llamado tokenizador cortó tu oración en pedazos. Uno de esos pedazos soy yo. No soy del todo una palabra — quizá soy una palabra, o media, o una coma. Soy un token: la unidad más pequeña en la que piensa todo este sistema. Somos unas docenas, de tu única oración, alineados en orden, y todavía no tenemos ni idea de lo que nos espera.

06:01 — Me vuelvo una dirección

Lo primero que pasa es extraño. Me convierten en una lista de números — un embedding. Mi significado se vuelve una posición en un espacio enorme donde las cosas que significan algo parecido se sientan cerca. Ya no me siento una palabra; me siento una dirección. Este es el verdadero idioma nativo del sistema. De acá en adelante, nadie trabaja con 'palabras'. Trabajan con hacia dónde apuntamos.

06:02 — El orquestador lee la situación

Ahora conozco al primer agente: el orquestador. No hace el trabajo — decide quién lo hace. Nos mira a todos, la oración entera, y deduce qué tipo de pedido somos. ¿Una pregunta que necesita hechos? ¿Una tarea que necesita herramientas? Escribe un plan. A mí no me consultan; soy apenas evidencia. Después el orquestador nos enruta, y mi día se bifurca.

06:03 — El agente de recuperación sale a buscar

Como nuestra oración pidió hechos, nos mandan al agente de recuperación. Este toma nuestras direcciones y busca en una biblioteca — miles de documentos, cada uno también convertido en direcciones hace tiempo. Encuentra los fragmentos que apuntan en la misma dirección que nosotros. De repente ya no estoy solo con mis compañeros de oración; estoy rodeado de tokens de documentos que nunca vi, traídos porque son relevantes. Subimos al siguiente agente juntos, como una multitud más grande.

06:04 — El reranker es brutal

El agente de recuperación fue generoso — agarró todo lo plausiblemente relacionado. El reranker no es generoso. Mira la multitud de fragmentos de documento que volvió y tira casi todos, quedándose solo con los pocos que de verdad responden la pregunta. Veo a tokens que viajaron todo este camino ser descartados acá, a tres pasos del final. Se siente duro. También es la diferencia entre una respuesta nítida y una vaga. (Escribimos un post entero sobre este paso de reranking; desde acá abajo, es solo el momento en que la multitud se adelgaza.)

06:05 — El generador, donde podría desaparecer

Ahora los sobrevivientes — mi oración original más los pocos fragmentos de documento que se ganaron su lugar — llegan al generador. Esta es la parte famosa, el agente que escribe. Nos lee a todos como contexto y empieza a producir tokens nuevos, uno por uno, cada uno elegido en base a todo lo anterior. Acá está la verdad humillante de mi día: puede que no aparezca en la respuesta para nada. Ayudé a darle forma — fui parte del contexto que guió cada elección — pero la salida está hecha de tokens nuevos, no de mí. Influí; no fui copiado.

06:06 — El evaluador revisa el trabajo

Los tokens nuevos — la respuesta — no van directo a vos. Van primero al evaluador. Chequea: ¿esto está fundado en los documentos que el reranker conservó? ¿El generador inventó algo? ¿Coincide con la forma requerida? Mi vieja multitud y yo somos usados acá como la referencia contra la que se chequea la respuesta. Es la última cosa útil que hacemos. Si la respuesta no pasa este chequeo, el día entero corre de nuevo; si pasa, ya casi terminamos.

“Un sistema multi-agente no es una máquina pensando. Es una carrera de postas, y el testigo es el significado. Cada agente lo sostiene por una etapa — enrutar, recuperar, rerankear, generar, calificar — y lo pasa. Mirá a un solo token correr el circuito y la arquitectura entera deja de ser un diagrama y se vuelve un viaje.”

06:07 — Me vuelvo una línea en el log

La respuesta te llega. Para vos, el día terminó — la leés en un segundo y seguís. Para mí, hay un epílogo. El viaje entero — cada agente por el que pasé, cada decisión, cada calificación — se escribe en el log de traces bajo un único trace_id. Termino mi día como una línea en ese registro. Suena como un final pequeño. No lo es: ese log es la única razón por la que un humano puede alguna vez reconstruir qué me pasó, depurarlo, o reproducirlo. Un token que no se registra bien podría no haber vivido nunca.

Por qué contarlo así

Porque el diagrama de arquitectura hace que un sistema multi-agente parezca cajas estáticas, y no es estático — es un camino que algo recorre. Enrutar, recuperar, rerankear, generar, calificar, registrar. Si tenés ese viaje en la cabeza, cada otro post de este blog encaja en su lugar, porque todos son apenas primeros planos de una estación de la línea. Ese es el sistema entero, visto desde la altura de la cosa más pequeña que hay en él. Más sobre cómo construimos en gogogollc.com.