Por qué la memoria de un agente de programación debe contener solo el delta, y cómo almacenarlo.
La memoria del agente de codificación debe contener solo aquello que el modelo no pudo adivinar. Cuatro pruebas para cada entrada, tres necesidades para el almacenamiento, y por qué Markdown en Git encaja bien.
Fuentes: Why Your Agent Needs Memory, and How to Organize It
Imagínese un almacén de memorias personales para un agente de programación en una sola máquina. Alberga 181 archivos temáticos detrás de un índice de 134 líneas, y casi nada de ello constituye conocimiento en el sentido habitual. El agente ya comprende el middleware de Express, la estructura de una prueba de Playwright y qué hace un Dockerfile, habiendo leído sobre estos tres temas mucho más de lo que cualquier persona podría hacer. Cada línea en ese almacén existe por la razón opuesta: marca un punto en el que un mundo específico difiere de la media del sector.
Dos ejemplos ilustran esta idea. Un verificador de despliegues bloquea una publicación siempre que no se puede ejecutar una comprobación, y eso es intencional. La puerta de aprobación automática de una secuencia de publicaciones lee .status en lugar de .conclusion, un detalle que costó toda una tarde antes de convertirse en una sola línea en un archivo.
Esa es la forma que debe tener la memoria de un buen agente. No es una copia de lo que el agente sabe; es el delta, la parte restante. Todos coinciden en que un agente necesita memoria, pero nadie ha especificado cuál debe ser, por lo que el resto de este texto sigue dos pasos: primero, explicar por qué un agente necesita memoria en absoluto, y segundo, cómo organizarla. La segunda parte se divide en cuatro secciones: mantenerla simple, las exigencias de cada unidad de memoria y del almacenamiento, el almacenamiento que cumple esas exigencias, y la rutina para trabajar con ella.
La memoria del agente no es la memoria humana
El instinto natural es razonar por analogía: como las personas recuerdan cosas, los agentes también deberían hacerlo. Sin embargo, esta analogía falla desde el primer paso. Una persona comienza sin nada, por lo que la memoria humana debe almacenar tanto lo habitual como las excepciones. Un modelo, en cambio, llega ya con los datos promedio cargados, en una escala que supera a cualquier individuo. Decirle qué es el middleware no aporta información alguna; solo añade tokens.
Los tokens tienen un costo, y ahí es donde muchos cometen errores. El contexto que no se necesita no es neutral, representa una pérdida neta. En un estudio, los investigadores contaron con qué frecuencia un modelo realizaba llamadas a la API correctamente. Cuando el modelo recibía documentación de APIs que ya conocía bien y la recuperación de esa información era imperfecta, su tasa de llamadas correctas disminuía en 39 puntos porcentuales. Por el contrario, obtener ese tipo de documentación para APIs poco comunes que el modelo no había visto ayudaba, aumentando la precisión en nueve puntos. Mismo contenido y mismo proceso, pero el efecto cambiaba de signo.
Visto de esta manera, un archivo de memoria es como una diferencia aplicada sobre las suposiciones existentes del modelo. Cada línea que reafirma una convención conocida compite por la atención con la única línea que realmente importa, y la atención es lo que escasea.
Registra solo lo que el modelo no podría haber adivinado.
Al pasar los archivos de contexto reales por ese filtro, la mayor parte de su contenido desaparece. Las reglas de nombramiento, el principio de “composición sobre herencia” y la estructura de las carpetas de recursos son conocimientos básicos que maneja un analizador de errores y que el modelo ya posee. Lo que queda suele ser contenido complicado: soluciones temporales, rutas abandonadas, algo que es cierto en esta base de código pero no en ningún otro lugar.
En la tienda de ejemplos, con unas 3,700 líneas de longitud (3,831 si se cuenta el índice), ninguna línea indica qué middleware se utiliza o cómo estructurar una prueba. Las líneas que explicaban una herramienta famosa se eliminan, ya que el modelo ya la conocía y se desperdiciaban tokens en cada solicitud sin motivo.
La memoria más económica es la que no necesitas
Si la memoria no me falla, el delta depende de cuánto se desvíe un proyecto del patrón común. Si se sigue la arquitectura habitual, casi no se le exige nada al agente, ya que conoce bien el terreno. Si se inventa un sistema de módulos privado, cada una de sus reglas se convierte en una línea que debe escribirse, mantenerse vigente y costearse en cada solicitud.
No se necesita ningún benchmark para percibir el efecto. En una tecnología estándar, el agente simplemente continúa con su tarea. En un lenguaje de nicho o en un framework interno desarrollado por la propia empresa, el agente se detiene, hace conjeturas o plantea preguntas. Para cerrar esa brecha, uno mismo debe gestionar el contexto: escribirlo, versionarlo y mantenerlo actualizado de por vida.
No existe una prueba A/B clara para esta afirmación, y sería deshonesto fingir lo contrario. La investigación citada aquí respalda el mecanismo, mientras que los archivos de una sola persona solo respaldan la práctica, lo cual no constituye prueba del mecanismo. Sin embargo, la experiencia es consistente: el trabajo nuevo en estructuras comunes avanza rápidamente, mientras que el trabajo en sistemas grandes y antiguos, donde la mayor parte del contexto nunca se anotó, avanza más lentamente, a veces incluso más lento que hacerlo a mano.
Por lo tanto, las decisiones arquitectónicas se han convertido en decisiones relacionadas con la memoria. Elige el patrón aburrido y ampliamente utilizado, y no habrá nada adicional que mantener para siempre. Cada desviación del patrón común implica una línea que alguien debe anotar y mantener precisa, y un camino personalizado cuesta más en cada solicitud posterior, no solo en la que lo creó.
La parte difícil es mantenerlo pequeño
Ese es el porqué. El cómo comienza con un hecho incómodo: lo que destruye los sistemas de memoria en producción no es el olvido, sino la acumulación.
La utilidad queda rezagada con respecto al tamaño. El doble de memoria no equivale al doble de valor, ya que el desorden se acumula más rápido que la información útil, y pasado un cierto punto, un almacenamiento más grande proporciona respuestas peores que uno más pequeño, incluso para las preguntas para las que fue diseñado.
Los conflictos crecen más rápido que el tamaño. Cualquier hecho nuevo puede contradecir a cualquier otro existente, por lo que la cantidad de posibles conflictos aumenta mucho más rápido que la cantidad de archivos. Una contradicción también cuesta mucho más que una laguna de información. Cuando falta un hecho, el agente no está seguro, y no estar seguro es aceptable: pregunta o falla donde otros pueden verlo. Cuando dos hechos se contradicen, el agente está seguro pero equivocado, y como nada en el proceso parece estar roto, nadie se da cuenta.
Peor aún, la mayoría de los productos de memoria no son capaces de detectar el problema. La similitud vectorial registra dos oraciones sobre el mismo tema, pero no que una diga sí mientras la otra dice no. Por lo tanto, el valor se reduce, los conflictos siguen aumentando y, pasado cierto tamaño, el sistema de memoria empeora al agente.
La memoria rara vez falla de manera evidente. Falla al dar respuestas erróneas con total confianza, mientras que cada consulta sigue funcionando correctamente.
La dificultad, entonces, no radica en acumular más datos, ya que cualquier producto lo hará sin problema. Consiste en mantener un tamaño reducido sin dejar de ser suficiente. Eso requiere eliminar contenido, y eliminar significa juzgar uno mismo sus propios escritos anteriores.
La gente tiende a buscar primero una estructura. Frente a un montón desordenado, imponen una taxonomía de jerarquías, categorías, gráficos o esquemas formales de conocimiento. Eso suele tener efectos negativos. En una evaluación de 2026, se probó añadir mayor profundidad a un índice contextual a demanda con el mismo modelo y herramientas, y la precisión disminuyó de 0.91 a 0.64. El enfoque plano superó al jerárquico en todos los casos en que se probó. Una estructura elaborada no resuelve la complejidad; es otra capa de complejidad añadida a la primera, y ahora ambas necesitan mantenimiento.
Por lo tanto, organizar la memoria no se trata tanto de crear un diagrama mejor, sino más bien de establecer un umbral que cada elemento debe superar, además de un sistema que haga que superarlo sea sencillo.
Cuatro pruebas para cada unidad de memoria
Ese umbral se aplica a la unidad, no al sistema. En un equipo, también son estos los criterios que verifica un revisor.
- Sencillo y denso. Solo información sobre semillas. No existe ninguna oración con el único propósito de sonar completa. Una línea que no cambia lo que haría el agente es decorativa, y la decoración tiene un costo.
- Sin conflictos. No existen dos hechos que no puedan ser verdaderos al mismo tiempo. Esto requiere esfuerzo activo, ya que los conflictos se acumulan lentamente y nunca de forma intencionada.
- Útil de forma medible. La memoria no hace que un agente sea más inteligente; lo hace más rápido y económico manteniendo la misma calidad, proporcionando las mismas respuestas sin necesidad de redescubrimiento. Un archivo que no reduce visiblemente el tiempo o los recursos en una tarea real no merece su mantenimiento.
reference_, las reglas establecidas en 50 archivos feedback_, y los estados perecederos en 14 archivos project_. El lector sabe qué afirma un archivo antes de abrirlo.Un resultado publicado parece socavar la tercera prueba y, de hecho, la respalda. Investigadores de la ETH Zúrich realizaron una comparación entre archivos de contexto de repositorios y la ausencia total de archivos. No se observó ninguna mejora general en el éxito de las tareas, sino que se incrementó en más del veinte por ciento el costo de inferencia; además, los archivos generados por máquinas obtuvieron puntuaciones ligeramente inferiores a las de no tener ningún archivo. Al analizar la regla de delta, se comprueba que eso no constituye un resultado contradictorio. Un archivo lleno de conocimientos promedio es precisamente lo que la regla predice que costará algo sin aportar beneficio alguno. El hallazgo no afirma que los archivos de contexto fallen, sino que aquellos que repiten información promedio fracasan, lo cual describe a la mayoría de ellos.
Por lo tanto, la disciplina implica escribir menos y realizar más eliminaciones: cada línea debe mantenerse densa, y ningún par de líneas puede estar en desacuerdo.
Addy Osmani abordó el mismo problema desde la perspectiva del mantenimiento en agosto, sosteniendo que los archivos de los agentes se vuelven obsoletos a medida que mejoran los modelos (su publicación lleva como título un examen de los archivos de los agentes); por lo tanto, merecen una limpieza y reconstrucción periódicas en lugar de un crecimiento interminable. La memoria que solo crece está en cuenta regresiva.
Luego, divida lo que queda por tareas, tal como lo hace su propio sistema de recuperación de información. Lo que se carga para escribir texto difiere de lo que se carga para depurar un proceso de construcción.
Nadie necesita una sola memoria. Lo que se necesita es la porción más pequeña y correcta para la tarea en cuestión.
Tres requisitos para el almacén
Esos cuatro tests no dicen nada sobre dónde se almacenan los archivos, que es la otra mitad de la organización.
Una pista proviene de lo que ya comparten las herramientas existentes. AGENTS.md es un archivo markdown ordinario en una ruta predecible, y más de veinte herramientas lo leen, a pesar de que sus creadores compiten en casi todo lo demás. Los proveedores rivales nunca han implementado la misma API de memoria.
Una encuesta sobre agentes de codificación en uso (publicada en Substack) indicó que siete de ellos adoptaron un mismo diseño sin coordinación previa: un pequeño archivo markdown siempre presente en el contexto, además de un archivo más grande en el disco que se abre cuando una tarea lo requiere. Ninguno utilizó búsqueda vectorial. Aunque no comparten un estándar de medición, los siete cumplen con los mismos tres requisitos.
Se puede buscar sin necesidad de instalar nada. La función de “búsqueda” suele sugerir búsquedas semánticas, pero ese ni siquiera es el caso habitual. La propia herramienta de memoria de Anthropic permite ver, crear, reemplazar, insertar, eliminar y renombrar, pero no cuenta con ninguna operación de consulta. El agente enumera un directorio y lee su contenido. Una memoria que solo funciona cuando está creado el índice, los embeddings están actualizados y el proveedor está activo representa un punto débil en el contexto. Debe seguir funcionando incluso cuando todo eso deja de funcionar.
Se puede cambiar mientras alguien lo observa. La memoria que se actualiza por sí misma es donde el sistema sufre daños. Según un examen de 10,134 registros extraídos automáticamente en entornos de producción, el 97.8% de ellos fue considerado basura. Otro estudio hizo que los modelos guardaran en la memoria sus ejecuciones exitosas y obtuvo resultados peores que los de no tener memoria alguna, en los cuatro agentes probados. La memoria que se reescribe varía según el nivel de confianza, no de forma gradual, por lo que cualquier cambio debe ser visible como una diferencia, rechazable e irreversible.
Se puede mantener con herramientas que ya están disponibles. La corrupción rara vez pone fin a un sistema de almacenamiento de memoria. La negligencia sí lo hace: el archivo se escribe una vez, nadie lo vuelve a consultar, y poco a poco se vuelve inválido. Según un informe de un estudio de 2026, la mitad de los archivos de contexto nunca fueron modificados después del primer commit, y el 6 % que sí fueron revisados pertenecían a personas que reportaron beneficios reales del agente. El mantenimiento debe realizarse en el editor, en los sistemas de búsqueda y control de versiones que la gente utiliza todos los días.
Esa es la especificación completa. Lo que queda por decidir es qué tipo de almacenamiento la cumple.
Por qué los archivos en Markdown en Git son adecuados
La defensa de los archivos no es algo nuevo. Los autores de Medium han sostenido que “markdown supera a las bases de datos vectoriales para la memoria de los agentes” al menos seis veces el año pasado, y los hilos de Hacker News al respecto siguen generando bromas que se resumen en el uso de texto plano. Lo que rara vez se explica es el razonamiento detrás de ello.
Tres proveedores que venden bases de datos de memoria publicaron opiniones en contra de los archivos en un plazo de tres meses, mientras que los dos proveedores que ofrecen los agentes más avanzados ya habían elegido los archivos. El argumento aquí no tiene nada que vender, solo una carpeta.
Qué almacena el campo
Lo que almacena un sistema determina todo lo demás.
- Mem0 almacena una oración extraída por un LLM junto con su embedding, como una fila en un índice vectorial. Lo que se obtiene no es el documento original, sino una parafrasisación del extractor, y no se puede abrir.
- Zep mantiene un borde de grafo escrito para cada hecho y sigue dos líneas de tiempo por hecho, de modo que cada uno cuenta con un período de validez. Las correcciones se realizan mediante reemplazo: el borde antiguo se marca como inactivo en lugar de ser editado.
- Una empresa emergente especializada en memoria vectorial ha gestionado archivos vectoriales durante años. A principios de 2026 cambió el almacenamiento predeterminado para sus agentes de programación a un árbol de archivos markdown en un repositorio git, realizando un commit por cada edición.
- Anthropic ofrece una herramienta de memoria que se limita a operaciones con archivos en el directorio
/memories, ejecutadas por el propio cliente. Su API de almacenamiento de memoria, aún en versión beta y alojada en la nube, nombra los elementos según su ruta en el sistema de archivos y resuelve escrituras concurrentes mediante un hash de contenido, lo que equivale al modelo de datos de git con una capa HTTP. - Asistentes de consumo ofrecen un resumen que los usuarios solo pueden ver tal como se muestra. Hasta septiembre de 2026, no existe una exportación documentada y legible por máquinas para ninguno de ellos.
La verdadera línea divisoria radica en si la memoria puede ser leída, y el enfoque basado en archivos frente a bases de datos no la tiene en cuenta. Todas las opciones que no son archivos comparten algo en común: no es posible comparar la memoria en dos momentos diferentes. Las correcciones se realizan mediante un interruptor, no mediante un commit.
Cada bando tiene razón en parte
En marzo de 2026, MatrixOrigin afirmó que el markdown estático se degrada y no impone ninguna restricción. Cinco semanas después, Mem0 publicó un artículo titulado “¿La memoria de tu agente de IA es solo un archivo? Ese es el problema”, señalando que los archivos planos repiten los errores de la época anterior a las bases de datos de la década de 1970: sin búsqueda semántica, sin razonamiento temporal, sin escrituras concurrentes seguras y sin capacidad de olvido. En junio, Zep añadió “El markdown no es memoria de agente”, destacando que un archivo markdown solo muestra lo que se escribió, nunca qué reemplazó o por qué.
Mientras tanto, el propio agente de programación de Anthropic almacena su memoria en formato markdown simple en el disco, y la documentación de Windsurf aconseja discretamente trasladar todo lo que valga la pena conservar fuera de su almacenamiento de memoria y a formato markdown bajo control de versiones. Vale la pena observar quién vende qué.
Los proveedores de bases de datos sí tienen dos argumentos válidos. Los vectores ganan cuando la pregunta y la nota no comparten vocabulario, como en el caso de una solicitud sobre “lo que se siente al estar agotado” frente a una nota que nunca menciona el agotamiento. Solo un método de embedding puede superar esa barrera a una velocidad constante en millones de filas. Grep no puede encontrar algo que no se pueda nombrar.
Los grafos ganan en términos de tiempo. Para responder qué creía alguien el martes pasado y qué lo reemplazó, se necesitan datos con fechas de inicio y final, y una puntuación de similitud no puede indicar cuál de dos hechos contradictorios es el actual. Según se informa, una nueva evaluación realizada por un tercero en las preguntas temporales de una prueba de memoria a largo plazo arrojó un 63.8% para el sistema basado en grafos frente al 49.0% del sistema basado en vectores. Los archivos pierden en ambos casos.
La evidencia, con su salvedad
Los resultados de recuperación en 2026 sorprendieron al campo. Los agentes que exploraron un simple montón de archivos mediante grep, find y la lectura directa de los mismos superaron a todos los métodos basados en palabras clave, embeddings y sistemas de reclasificación. Un estudio de referencia sobre búsquedas con agentes reveló que eliminar el sistema de recuperación basado en embeddings y permitir que los agentes leyeran los archivos elevó la precisión del 69 % al 80 %, con casi un tercio menos de costos. Otro estudio sobre preguntas relacionadas con la memoria a largo plazo mostró que la búsqueda simple por palabras clave superó a la búsqueda semántica en cada configuración de llamada a herramientas integradas. Sin embargo, cuando los resultados se obtenían en formato de archivos, el orden se invertía en la mitad de los casos, ya que las preguntas premiaban la localización de elementos exactos como fechas, cantidades, identificadores o cadenas de errores.
El artículo sobre búsqueda basada en agentes también incluye una advertencia evidente: si se aumenta el conjunto de documentos de 100,000 a 400,000, el mismo método pasa de una precisión del 80 % a menos del 40 %, al tiempo que se necesitan tres veces más llamadas a la herramienta. Grep funciona dentro de ciertos límites de tamaño y no representa una ley natural; dentro de esos límites, gana en calidad y costo, pero más allá de ellos, su rendimiento se desploma.
Por lo tanto, la pregunta honesta es en qué lado de esos límites se encuentra un sistema, y no qué enfoque gana en general. Un conjunto de 181 archivos es cientos de veces más pequeño que el volumen de datos donde, según se dice, comienzan los problemas. Un sistema de memoria de producción en una empresa grande como LinkedIn no es así, y nadie sostiene que deba utilizar markdown.
Tabla de comparación: archivos frente a las alternativas
Frente a estos tres requisitos, los archivos en Markdown cumplen con cada uno de ellos casi sin costo alguno. Grep funciona como solución alternativa; cualquier cambio se representa como un diff (un commit reversible dentro de un repositorio), y las herramientas de mantenimiento ya están disponibles en el escritorio.
Existen dos beneficios adicionales que se obtienen sin costo alguno. Las contradicciones se manifiestan porque dos hechos conflictivos se presentan como dos líneas de texto en lugar de dos arrays de tipo float, y el formato almacenado sirve también como formato de exportación.
El compromiso debe ser nombrado en lugar de ocultado. Los archivos pierden ventaja frente a los embeddings cuando se necesita una recuperación imprecisa de muchos documentos. La solución es colocar un índice sobre los archivos, que pueda reconstruirse en cualquier momento, en lugar de sustituirlos. Las implementaciones basadas en memoria básica lo construyen sobre SQLite, memsearch lo hace sobre Milvus, y la idea de Karpathy de wiki compuesto se arregla con solo una página de índice, sin embeddings en absoluto. Cuando el índice es el almacenamiento, se renuncian a la inspección, las diferencias, la propiedad y la portabilidad en pos de una recuperación que de todos modos ya estaba disponible.
Si no puedes buscarlo con grep, compararlo con diff y eliminar una línea de él, entonces no es tu memoria. Es el caché de alguien sobre ti.
Así es un sistema en ejecución
Los principios son económicos, así que aquí hay una configuración funcional.
- Capas de punteros, sin manifiesto alguno. El primer archivo que abre el agente tiene 21 líneas. Funciona como un mapa con tres áreas de nivel superior, una línea cada una, que apuntan a archivos más profundos. Un nivel más abajo, un archivo de proyectos contiene lo que es verdaderamente personal: el repositorio activo frente al que se eliminó tras un cambio de nombre, las versiones a las que está fijado todo, las reglas de comunicación que deben seguirse. Hay veintiocho archivos de este tipo distribuidos en todo el árbol de proyectos, todos escritos a mano, y cada uno se carga únicamente cuando el trabajo requiere acceder a él.
- Un almacén al que escribe el agente, y un humano lo aprueba. Junto a eso está la memoria automática, con 181 archivos de tema detrás de un índice de 134 líneas. Solo el índice se carga al iniciar una sesión, y un archivo de tema se abre en el momento en que una tarea lo necesita.
Capas para cargar datos, no para razonar
Cuando se cuentan los niveles anteriores, hay cuatro, que representa la profundidad contra la cual advierte el resultado anterior de 0.91 a 0.64. Pero la variable en ese estudio era la profundidad, y un índice como tal se mantuvo en cada configuración. La mejor configuración era un índice plano por tarea: el agente lo lee en una sola pasada antes de decidir qué abrir, lo que casi duplicó la precisión en comparación con la navegación directa, a un costo aproximadamente la mitad. Los resultados empeoraron únicamente cuando el índice desarrolló ramas que el modelo tenía que recorrer, teniendo que adivinar únicamente a partir de las etiquetas cuál contenía la respuesta.
El índice de esta configuración es un ordenamiento plano: un único nivel que se lee completo al comenzar una sesión. Contiene 134 líneas, aproximadamente una por tema, cada una con el nombre de los archivos a los que apunta acompañado de una breve frase resumida. No hay ramificaciones, por lo que no es necesario adivinar nada. Se trata de una pequeña tabla de enrutamiento mantenida a mano, no de una taxonomía mediante la cual el modelo pueda razonar, y puede ser imperfecta: once de los 181 archivos faltan en ella. Los archivos de los temas son pequeños, planos y se leen en su totalidad; se abre una capa porque el trabajo se trasladó a esa área, no porque alguna consulta haya buscado algo específico. Eso es divulgación progresiva.
La prueba es sencilla. Si el modelo debe adivinar qué rama contiene la respuesta basándose únicamente en las etiquetas, se ha construido un árbol y el resultado será 0,64. Si lee todo el índice y abre un archivo por su nombre, se trata de un orden de carga.
La estructura existe para decidir qué cargar. No está allí para que el modelo lo analice paso a paso.
Una medida de protección contra la deriva
El agente propone algo, la modificación se muestra como una diferencia, y una persona la acepta o no. Los archivos que se encuentran en los repositorios tienen su propia historia, lo que significa que la pregunta de por qué el agente cree algo puede responderse leyendo dicha historia, algo que ningún almacén vectorial ni página de memoria de proveedor puede ofrecer. Una memoria que nadie revisó es solo un rumor con un nombre de archivo.
Ocasionalmente se realiza una limpieza rutinaria: se eliminan las líneas que eran verdaderas en junio, los archivos que el modelo ha absorbido desde entonces y las reglas reemplazadas por otras mejores. Los almacenes se reducen con más frecuencia de lo que la gente predice.
Todo está en formato Markdown simple en el disco local y funciona sin la ayuda del asistente que lo ayudó a escribirse. Cuando llegue uno más potente el próximo año, diríjalo a la misma carpeta y continúe.
Una verificación que puede realizar hoy
La organización cabe en una tarjeta: cuatro pruebas para cada línea conservada, tres requisitos sobre dónde se guarda y una intervención humana entre el agente y el archivo.
Para determinar su propia posición, abra el archivo de contexto del proyecto, ya sea CLAUDE.md, AGENTS.md o lo que sea que lea la herramienta, y elimine todas las líneas que el modelo habría adivinado por sí solo. Reducirlo a la mitad es un resultado realista. Luego, asigne la siguiente tarea real al archivo simplificado y vea si algo empeora. Después de eso, cada vez que el agente cometa un error en algo que no tenía forma de conocer, añada una sola línea y hágala revisar como código. Esa es la disciplina, y no se escala añadiendo más elementos.
El agente ya conoce el promedio. La única tarea es calcular el delta.
Leer más
- Por qué los indicadores de memoria de los agentes engañan y cómo evaluar con tus propios datos — Las listas de clasificación públicas de memoria tienen claves de respuestas y evaluadores defectuosos. Separa la recuperación de información de las respuestas, añade verificaciones de consistencia, recencia, abstención y olvido, y haz un seguimiento del costo.
- Inyección de promptes y la tríada letal: cómo proteger a los agentes de IA — Por qué los agentes no pueden distinguir entre tus instrucciones y las de un atacante, cómo funcionaron los ataques EchoLeak y GitHub MCP, y qué medidas de defensa son efectivas.