El impuesto del traspaso entre agentes: por qué un “enjambre” lo vuelve a leer todo

Un proceso de agentes con varios saltos no es un modelo respondiendo una pregunta. Son varios especialistas que se turnan: un enrutador clasifica la intención, un planificador descompone la tarea, un recuperador trae contexto, un razonador piensa, un revisor verifica y un redactor final escribe. Entre dos de ellos cualesquiera se traspasa el control, y aquí está la parte que los diagramas amigables pasan por alto: quien recibe obtiene texto. No el estado oculto del emisor, no su caché KV, no la atención que construyó sobre las 50 páginas que acaba de leer: solo una cadena de tokens.

Así que el receptor hace lo más caro que hace un transformer: leer un contexto largo y construir su estado interno, otra vez. Un proceso de cuatro saltos sobre un mismo documento compartido puede tokenizar y volver a procesar (prefill) el mismo material cuatro veces. Tres de esas lecturas no aportan nada: el enrutador ya lo sabía, el planificador ya lo sabía, el razonador ya lo sabía. El trabajo se tira en cada frontera y se reconstruye del otro lado. Ese desperdicio es el impuesto del traspaso entre agentes, pariente cercano del impuesto de tokens, que no se paga eligiendo modelos de más, sino reconstruyendo contexto de más.

La forma más clara de plantearlo viene de un lugar inesperado. En una serie de Towards Data Science sobre inferencia con agentes en producción, el ingeniero Anubhab Banerjee señala que el traspaso entre agentes es estructuralmente idéntico a un arranque en frío tras el traspaso (handover) en una red móvil: cuando su teléfono pasa de una estación base 5G/6G a otra, la nueva antena descarta el estado por dispositivo que tenía la anterior y tiene que reconstruirlo a partir de unas cuantas mediciones de radio nuevas, mientras usted ya va en movimiento. La misma forma: un receptor desecha en una frontera un estado acumulado costoso y se reinicia desde cero.

Cambie “antena de origen” por “agente A”, “antena de destino” por “agente B” y “mediciones de radio” por “tokens de la siguiente subtarea”, y es el mismo problema de ingeniería en dos industrias. Ese reconocimiento entre dominios, la parte útil de este trabajo, vale más que cualquier benchmark aislado: un cuello de botella que se puede nombrar en un campo muchas veces ya está resuelto en otro.

La solución, en ambos dominios, es dejar de pasar texto y empezar a pasar un pequeño latente aprendido (un resumen comprimido de lo que calculó el emisor) que el receptor inyecta directamente, sin volver a leer. Tres pasos:

• Comprimir. Se condensa el contexto de trabajo del emisor en un solo vector de tamaño fijo y luego se pasa por un pequeño autocodificador (un β-VAE) hasta obtener un latente diminuto, del orden de cien bytes. El cuello de botella aprende qué señal relevante para la tarea conservar y cuál descartar.
• Transportar. Ese latente cruza la frontera; es lo único que pasa de un salto al otro. En telecomunicaciones viaja en el mensaje estándar entre celdas; entre agentes es una carga diminuta en lugar de una ventana de contexto enorme.
• Proyectar. En el receptor, el latente se expande (mediante una pequeña red con compuertas) en un puñado de vectores de “memoria” dentro del propio espacio de embeddings del modelo, y se anteponen a la pregunta como un prefijo de prompt suave (soft prompt). El receptor atiende al estado destilado del emisor en lugar de volver a leer su texto.

Es el mismo principio que el de todos los trucos de eficiencia de esta serie de ideas: calcular una sola vez el estado costoso y luego reutilizarlo. Es el mismo instinto detrás de la caché KV (no recalcular la atención) y de la decodificación especulativa (no desperdiciar cómputo ocioso), solo que aplicado entre saltos de razonamiento y no dentro de uno.

Aquí es donde nos mantenemos firmes, porque la fuente también lo hace. Las cifras impresionantes de ese trabajo (eliminar los traspasos de ida y vuelta, el “ping-pong”, recuperar precisión, decisiones en menos de 10 ms) son resultados de radio 6G, no resultados de agentes LLM. El método (llamado ILCP) es un artículo de telecomunicaciones revisado por pares; la versión para agentes es un primer “cableado V1” con una métrica de juguete, y el autor insiste en que los benchmarks del lado de los agentes son trabajo futuro. Incluso incluye una utilidad cuyo único propósito es medir directamente la carga entre agentes en lugar de tomar prestada la cifra del artículo de telecomunicaciones; se niega, en sus palabras, a “hacer pasar los comprobantes de la red de radio por comprobantes de LLM”.

Esa disciplina es exactamente la vara con la que se mide este sitio. El problema (los traspasos por texto desechan estado ya calculado) es real, está establecido y vale la pena diseñar pensando en él hoy. La solución específica para agentes LLM es prometedora pero no está probada, y debe leerse como una hipótesis bien argumentada, no como un resultado definitivo. Mantener ambas cosas separadas es lo que hace confiable una afirmación. Si los traspasos por latentes funcionan para agentes, la ganancia es concreta: menos reprocesamiento redundante significa menor costo y latencia por cada tarea con varios agentes, que es justo el tipo de ahorro que querríamos medir antes de que alguien rediseñe su arquitectura en torno a él.