Les dimos a los agentes un millón de tokens en la ventana de contexto, pero aún así no funcionan.
Guarda esto :)
Le das a un modelo capaz algunas herramientas y una tarea larga. Durante los primeros quince pasos, es brillante. Enfocado y preciso. Respondiendo bien las preguntas e interrogando al usuario.
Sin embargo, a medida que las conversaciones comienzan a escalar, el agente empieza a desviarse. El agente comienza a contradecir las decisiones que tomó hace diez pasos. Empieza a contaminar la ventana de contexto con información inventada. Sabe que las preferencias del usuario existen, pero no puede recuperarlas de manera confiable. Todo mientras luchas por entender por qué las cosas se rompieron.
Entonces terminas buscando más. Un modelo con una ventana de contexto más grande para mantener la tarea por más tiempo. Intentas optimizar el pipeline RAG. Buscas en internet soluciones de memoria para agentes.
Y nada funciona como esperabas.
Entender el porqué detrás de esto nos apunta directamente a la capa más valiosa y menos comprendida de toda la pila de agentes.
El Fracaso es un Bucle
La razón por la que los agentes se degradan no es una falta de capacidad. Es un bucle de retroalimentación, y tiene cuatro eslabones. Una vez que ves los cuatro, las soluciones habituales dejan de parecer soluciones.
Primer eslabón: un modelo no puede usar todo su contexto por igual, y empeora a medida que el contexto se llena.
Esta es la parte que la mayoría nunca internaliza. La capacidad de un modelo para usar información no es uniforme en toda su ventana de contexto. Los modelos usan de manera confiable lo que está al principio y al final, y sistemáticamente prestan menos atención al medio, incluso cuando están específicamente diseñados para entradas largas. Mete más, y la confiabilidad cae aún más. Esto se manifiesta incluso en tareas tan triviales como repetir una lista de palabras. Agrega un solo distractor, y el rendimiento baja de forma medible. Agrega varias cosas compuestas.
Así que el contexto efectivo, la parte sobre la que el modelo puede razonar de manera confiable, es mucho más pequeña que el número en la caja. Y se encoge a medida que metes más contenido.
Ahora piensa en lo que hace un agente. Acumula. Cada resultado de herramienta, cada paso del historial, cada nota para sí mismo se añade al contexto. Lo que significa que el agente está reduciendo constantemente la calidad de cada paso que da. El contexto creciente está fabricando errores por paso.
Segundo eslabón: esos errores por paso no se suman. Se multiplican.
Un pequeño error por paso estaría bien si los agentes tomaran un puñado de pasos. Toman docenas. Y los fallos se acumulan en lugar de sumarse. Un agente que es 95% confiable en cinco pasos no sigue siendo 95% confiable en una tarea de 20 pasos. Ejecuta suficientes pasos, y te acercas cada vez más a un cara o cruz.
Es peor que eso, porque los errores se auto-refuerzan. Una llamada a herramienta que se desvía ligeramente de la trayectoria hace que la siguiente sea más propensa a desviarse también. Apila eso sobre el primer eslabón, donde la tasa de error base está aumentando a medida que se llena la ventana, y obtienes el modo de fallo característico de los agentes de largo horizonte. No se degradan de manera gradual. Se mantienen y luego de repente se desploman.
Tercer eslabón: la tarea es larga, el modelo no tiene estado, así que pones el estado en algún lugar fuera del modelo.
Los modelos de lenguaje no retienen nada entre llamadas. Cada llamada comienza en blanco. Lo único que sabe un modelo es lo que le devuelves. Así que para cualquier tarea larga, tienes que externalizar el estado. Blocs de notas. Archivos de progreso. Puntos de control. Almacenes de vectores. Capas de memoria dedicadas que extraen hechos y los vuelven a servir entre sesiones.
Esto es correcto y necesario. Y parece una solución limpia. El agente no olvida nada importante, porque todo lo importante vive en almacenamiento duradero.
Cuarto eslabón: la memoria almacenada es inerte, y traerla de nuevo alimenta el mismo problema que se suponía que resolvería.
Aquí es donde se cierra el bucle. Un modelo no puede razonar sobre una base de datos. Solo puede razonar sobre lo que está en su ventana de contexto. Así que la memoria ayuda solo en el instante en que se recupera. Y cada recuperación añade tokens. Cada resumen que el agente escribe para rastrear el progreso es un token que tendrá que releer más tarde. Cada paso de compactación que condensa el historial para hacer espacio tiene pérdidas, y el detalle que descarta suele ser el sutil cuya importancia solo se aclara después.
Así que el sistema de memoria que construiste para vencer el límite de contexto termina alimentándolo. Más memoria significa más recuperación, lo que significa más ruido en la ventana, lo que significa más error por paso, que se acumula, que es lo que te llevó a buscar memoria en primer lugar.
El bucle es real. Y no le importa lo grande que sea tu ventana de contexto.
La Capacidad Nunca Fue el Eje Importante
Una vez que ves el bucle, la futilidad de las soluciones estándar se vuelve obvia.
Una ventana de contexto más grande no lo resuelve. Solo eleva el techo de cuánta podredumbre puedes acumular antes del desplome. Mientras tanto, cada estudio sobre el contexto efectivo sigue mostrando lo mismo: la fracción utilizable de manera confiable crece mucho más lentamente que el número anunciado. Estás comprando capacidad que no puedes usar realmente.
Más memoria no lo resuelve. Aumenta el volumen de material que compite por reingresar a una ventana que ya no puede contenerlo todo.
La próxima arquitectura tampoco lo resolverá. Los contendientes que se alinean contra la atención, los modelos de espacio de estados como Mamba y sus híbridos, ganan comprimiendo el pasado en un estado de tamaño fijo en lugar de mantener cada token direccionable. Eso compra inferencia de tiempo lineal y una huella de memoria que no crece con la secuencia. No puede comprar un recuerdo. Un estado de tamaño fijo no puede contenerlo todo, así que olvida por diseño. A escala, los modelos de espacio de estado puro se quedan atrás de los transformers exactamente en lo que existe la memoria externa para proporcionar: recuperar un hecho específico desde un punto arbitrario anterior en la secuencia. Por eso los esfuerzos serios posteriores a la atención son híbridos que mantienen una minoría de capas de atención para hacer el recuerdo que un modelo de estado no puede. La pared no se mueve cuando cambias la arquitectura. Simplemente la alcanzas desde el otro lado.
Así que la lección no es "elige un número más grande". Es que la capacidad nunca fue la limitación principal.
La limitación principal es la calidad de la decisión sobre qué tokens ocupan la ventana en cada paso.
Ese es todo el juego. No el contexto disponible más grande, sino el más pequeño suficiente. Relevancia sobre recuperación. Olvido deliberado como una operación de primera clase en lugar de un accidente de truncamiento. La investigación respalda esto directamente: la recuperación que preserva el orden de unos pocos miles de tokens bien seleccionados supera a volcar una ventana completa de 128K en el modelo. La ventaja está en elegir qué entra, no en cuánto puede entrar.
Y esta es la trampa que atrapa a la mayoría de los equipos, porque la herramienta a la que recurren para hacer la elección tiene la forma equivocada.
La Similitud No Es Relevancia
La forma predeterminada de decidir qué contexto traer de vuelta es la búsqueda por similitud. Incrusta todo, y cuando el agente necesita contexto, recupera los vectores más cercanos a la consulta actual.
Pero la similitud responde a la pregunta equivocada. Devuelve lo que está cerca, no lo que está relacionado. Y esas son dos cosas muy diferentes.
La pregunta que un agente realmente necesita responder nunca es "qué es similar a esto". Es "dada esta tarea y este estado en este momento, qué se conecta con lo que importa". Esa es una pregunta relacional. Se trata de dependencias, procedencia, qué reemplazó a qué, y qué decisión causó qué resultado. Un almacén ajustado para recuperar vectores similares le entrega al modelo un montón de casi-aciertos en su lugar. Y los casi-aciertos son exactamente los distractores del primer eslabón, los que impulsan el error por paso que se acumula en el desplome.
Por eso la solución no puede ser una caché delgada frente a un almacén de incrustaciones. La inteligencia no está en la búsqueda. Está en la estructura.
La Capa que Nadie Está Teniendo en Cuenta
La capa más importante de capturar en la pila de agentes no es el modelo, y no es el almacén. Es la capa intermedia. La que decide a qué presta atención el modelo.
Y para hacer realmente ese trabajo, tiene que ser tres cosas.
Tiene que ser neutral. Los internos cambian constantemente bajo los pies de todos. Transformer a espacio de estados a híbrido. De un modelo frontera al siguiente, con un nuevo líder de precio-rendimiento cada pocos meses. Una estrategia de contexto soldada a un solo modelo es una apuesta a un objetivo en movimiento. Lo que tu organización realmente acumula valor es su contexto, el registro estructurado y ganado con esfuerzo de lo que tus agentes saben y han hecho. Bloquear eso a las características de memoria de un solo proveedor significa que has convertido tu activo más duradero en rehén de una hoja de ruta que no es tuya. Una capa de selección que vive fuera de cualquier modelo único permite que el mismo contexto organizado sirva a cada modelo que ejecutes, y al próximo que aún no has adoptado.
Tiene que ser horizontal. El punto de control de un framework sabe de una sola ejecución. La memoria integrada de un modelo sabe de las conversaciones de un solo modelo. Un índice vectorial sabe de un solo corpus. Ninguno de ellos tiene la imagen que realmente importa una vez que estás ejecutando cargas de trabajo reales: muchos agentes, muchas sesiones, muchos modelos, todos necesitando una vista coherente y consultable del contexto. Ese rol de sistema de registro no es algo que una aplicación, un framework o un laboratorio esté diseñado para tener, porque cada uno solo ve su propia porción. Es una capa propia, situada horizontalmente sobre todos ellos.
Tiene que ser estructurada. Esto es lo que la separa de "solo una mejor base de datos". La selección es un problema de relevancia, y la relevancia es relacional. La estructura sobre el contexto, las relaciones y dependencias, la procedencia y la superación, es lo que convierte la recuperación en selección. Eso es una primitiva fundamentalmente diferente del almacenamiento, y es la que el bucle exige.
“¿Los Laboratorios No Van a Implementar Esto?”
La objeción obvia es que los laboratorios de modelos absorberán esto. Siguen lanzando características de memoria y contexto, y tienen acceso privilegiado a la atención del propio modelo.
Lo harán, y la objeción es medio correcta. Para un solo modelo que envuelve una sola aplicación, dejar que el laboratorio lo maneje suele ser suficiente. Eso está bien.
Pero el incentivo de los laboratorios es hacer que su propio modelo sea más difícil de cambiar. Eso es lo opuesto a la portabilidad. La curación fusionada con los internos de un solo modelo no puede servir al caso multi-modelo y de toda la organización. Un sustrato de contexto real no compite con esas características de frente. Existe para la situación que los laboratorios, por estructura, no están inclinados a servir: aquella en la que ejecutas varios modelos a través de muchos agentes y equipos, y te niegas a dejar que la capa que decide en qué piensan tus agentes sea propiedad del proveedor cuyo modelo ejecutan hoy.
Y la tendencia solo agudiza esto. Cuanto más capaces se vuelven los modelos, más se usan. Cuanto más se usan, más agentes ejecuta una organización. Cuantos más agentes ejecuta, más vale una capa de selección neutral, horizontal y estructurada.
¿Quién está construyendo esto?
Aquí es donde entra Hydradb. Neutral, horizontal y estructurada. Contiene las relaciones, dependencias, procedencia y superación que la búsqueda por similitud aplana. Está versionado temporalmente y consciente de preferencias, y por lo tanto sabe no solo qué es verdad, sino qué lo reemplazó. Desbloquea la visibilidad de lo que un agente determinado ha aprendido con el tiempo. Esa estructura es lo que convierte la recuperación en selección.
Debajo, HydraDB se ejecuta en almacenamiento por niveles: una caché activa en memoria para contexto activo, NVMe para cálido, almacenamiento de objetos para frío. El contexto se promueve y degrada según la actualidad y la importancia, para que el conjunto de trabajo sobre el que el modelo razona se mantenga pequeño a propósito. Entre el modelo y todo lo que podría saber.
La Pregunta que Todo Agente Tiene que Responder
Deja de lado los debates de arquitectura, los productos de memoria, la carrera armamentista de ventanas de contexto. Debajo de todo eso, todo agente de largo recorrido responde la misma pregunta en cada paso.
De todo lo que sabe, ¿en qué debería estar pensando ahora?
Una ventana más grande no responde eso. Solo le da al agente más para ignorar. El bucle es real, es permanente, y ninguna cantidad de capacidad lo cierra.
La industria sigue intentando comprar su salida con capacidad. No puede. Los equipos que internalizan que siempre fue un problema de selección lanzarán agentes que funcionan, mientras que todos los demás lanzan agentes que casi funcionan.
Esto nunca fue una limitación pura de los modelos. Cualquier cosa que opere bajo un presupuesto finito tiene que elegir a qué presta atención. La selección no es un parche para los límites de hoy. Es lo que el razonamiento bajo límites siempre ha requerido.
Si te resultó útil, sígueme @eng_khairallah1 para más contenido de IA como este. Publico desgloses, cursos y herramientas cada semana.
espero que te haya sido útil, Khairallah ❤️
