El tamaño del prompt se convierte en una métrica de arquitectura

La ventana de contexto de un modelo no es lo mismo que el conjunto de información que ese modelo necesita para decidir, y mezclarlas sale caro. Ese es el argumento que se está instalando entre quien construye agentes: el tamaño del prompt deja de ser un detalle de implementación y pasa a comportarse como una métrica de arquitectura.

El patrón es fácil de reconocer. Un agente accede a un repositorio, así que se le da más repositorio. Una canalización de RAG recupera diez documentos, así que se pasan los diez. Una herramienta devuelve una salida y se arrastra tal cual a la siguiente iteración. Nada falla de inmediato: la ventana todavía tiene sitio y la respuesta parece razonable. El problema es que el historial va acumulando código, logs, resultados intermedios y respuestas de herramientas hasta que la construcción del prompt se convierte en parte del perfil de rendimiento del sistema.

La ventana no es el conjunto de trabajo

Otros campos ya resolvieron esta clase de problema: las bases de datos usan índices, las cachés tienen políticas de expulsión, los sistemas operativos gestionan conjuntos de trabajo y los sistemas distribuidos acotan colas y búferes. La propuesta es aplicar la misma disciplina al contexto.

Un agente que trabaja sobre 2.400 archivos y 180.000 líneas de código puede resolver un fallo de persistencia con el controlador, el servicio, el repositorio, la entidad implicada, un test que falla y la traza correspondiente. Con 6.000 u 8.000 tokens basta. El repositorio sigue siendo la fuente de verdad; no hace falta meterlo dentro del contexto. El camino razonable es indexar, buscar, analizar símbolos y dependencias y extraer solo los fragmentos relevantes antes de llamar al modelo.

Hay además un motivo empírico para no confiarse. El estudio Lost in the Middle observó que los modelos rinden peor cuando la información relevante queda enterrada en medio de un contexto largo. Capacidad no es relevancia.

La aritmética ayuda a verlo. Si un agente hace 100 llamadas y cada una arrastra 40.000 tokens de entrada, una mejor recuperación que baje el conjunto de trabajo a 12.000 tokens recorta el volumen un 70%. El impacto exacto en la factura depende del modelo, del proveedor, del precio y del uso de caché, pero el punto arquitectónico es otro: cada token innecesario se multiplica por cada invocación que lo transporta.

Qué entra en el contexto y qué no

La salida de una herramienta no es contexto por defecto. Si un run_tests() devuelve 15.000 tokens, lo sensato es filtrar y resumir antes de construir el prompt. De miles de líneas con tests correctos, marcas de tiempo, avisos y trazas puede que solo hagan falta tres tests fallidos, dos trazas y cinco archivos modificados. Lo mismo vale para consultas a bases de datos, APIs, búsqueda de código, logs o resultados de navegador. Las interfaces de herramienta deberían soportar filtrado, paginación, selección de campos y respuestas acotadas. Una herramienta que devuelve 50.000 tokens de forma rutinaria no es un problema de rendimiento de la herramienta: es un problema de arquitectura del contexto.

El paso siguiente es una política de admisión, casi como la de una caché: qué es relevante, qué es autoritativo, qué está vigente, qué está duplicado y qué va a necesitar el modelo en la próxima decisión. Eso da a la información un ciclo de vida. Una restricción del sistema puede seguir siendo válida toda la sesión; un documento recuperado puede servir para una sola decisión; un log de compilación de 10.000 líneas puede acabar aportando un único dato. Tratar todo eso como historial permanente equivale a una política de expulsión de nunca expulsar.

De ahí sale la parte mecánica: recuperar menos pero mejor, con filtros de metadatos, búsqueda híbrida y reordenación; y trocear código por símbolo en lugar de arrastrar una clase de 2.000 líneas porque un método es relevante. Quien despliega agentes en producción acabará midiendo esto igual que mide latencia o coste por petición, porque el prompt es ahora una parte del sistema que se dimensiona, no un texto que se pega.