8 patrones emergentes para la memoria de agentes y la clave para la seguridad de la IA

Un pequeño retraso en esta parte final de la serie de 19 sistemas, pero más vale tarde que nunca.

Los seis patrones universales de los 19 sistemas que he estado analizando son la columna vertebral de esta serie. Inversión en calidad en tiempo de escritura. Procedencia que viaja con el hecho. Recuperación híbrida fusionada con RRF. Almacenamiento por niveles con promoción basada en calor. Presupuestos de contexto explícitos. Herramientas, no inyecciones, en la superficie del agente. Cada uno mereció su propio artículo porque tres o más sistemas llegaron a la misma disciplina de forma independiente.

Los patrones universales terminan aquí. A partir de ahí, comienzan los emergentes.

Este artículo trata sobre ocho patrones que se encuentran por debajo del umbral, viviendo en uno o dos sistemas, donde la implementación aborda tan claramente un problema real que es difícil creer que sigan siendo raros. Siete aparecen exactamente en un sistema. Uno aparece en dos y está a una adopción de graduarse. El primero recibe el tratamiento más profundo porque es el más importante.

Ser temprano significa que algunos de estos no se universalizarán. Ser tarde es peor: construyes un sistema en 2026 que se lanza sin autorización a nivel de almacenamiento porque una síntesis lo llamó una rareza aislada, y obtienes una demostración de inyección de instrucciones en Hacker News en 2027.

El motor de almacenamiento es la única autoridad que se mantiene

El artículo anterior argumentaba que el agente debería tener las herramientas. Dale una herramienta SQL y la pregunta se vuelve inmediata: ¿qué impide que consulte la tabla que no debería?

Los enfoques ingenuos son muy transitados y todos están equivocados.

Instrucción a nivel de indicación: "No tienes permiso para leer la tabla de conversaciones." Funciona contra un modelo cooperativo. Falla contra cualquier modelo que malinterprete la instrucción, decida que la prohibición no aplica a su tarea actual, o esté operando bajo un jailbreak.

Filtro a nivel de aplicación: la herramienta sql_query envuelve el SQL del modelo, lo analiza en busca de referencias a tablas prohibidas, rechaza la consulta antes de pasarla a la base de datos. Funciona contra un modelo ingenuo. Falla contra cualquier modelo que cite nombres de tablas, use ATTACH, explote un desajuste de análisis entre el envoltorio y la base de datos, o se enrute a través de una vista definida en otro lugar.

Acceso solo mediado por ORM: el agente nunca toca SQL sin procesar, llama a métodos tipados. Funciona hasta que el sistema incorpora una herramienta de depuración, una herramienta de análisis, una herramienta de migración o una función "deja que el agente una dos tablas", momento en el cual la regla se rompe y la rotura pasa desapercibida.

Dicho claramente: ninguna de estas es ejecución. Son sugerencias. Un sistema que quiera un aislamiento real entre subagentes tiene que pedirle al propio motor de almacenamiento que rechace la lectura, no a la capa superior. Esta es la disciplina que la seguridad basada en capacidades impone a los recursos del sistema operativo: el kernel dice que no, no la aplicación. También es la disciplina que la seguridad a nivel de fila de PostgreSQL impone a los SaaS multiinquilino: la política vive en la base de datos, no en el ORM, porque "el ingeniero que construyó el nuevo microservicio olvidó aplicar el filtro de inquilino" es una clase de error que solo una política del motor de almacenamiento puede descartar.

second-brain es el primer ejemplo práctico del corpus. Su base de datos con ámbito tiene tres capas, cada una necesaria, ninguna suficiente por sí sola.

Una conexión SQLite en memoria nueva por agente con ámbito. El constructor abre :memory: y adjunta la base de datos real en modo solo lectura. La conexión del agente no tiene un esquema principal real, no hay nada que leer excepto lo que la siguiente capa coloque allí.

VISTAS TEMPORALES en el esquema principal que redirigen a tablas permitidas en la fuente. Las definiciones de las vistas provienen del perfil del agente y pueden codificar redacción a nivel de columna o filtros a nivel de fila. Un validador de nombres de vista evita la inyección de nombres de tabla maliciosos a través del perfil.

Un enlace de autorizador de la API C de SQLite que deniega cualquier lectura del esquema fuente que no pase a través de una vista. El enlace se activa para cada lectura que SQLite está a punto de realizar, antes de que el optimizador resuelva el nombre de la tabla. Una lectura dentro del cuerpo de una vista está permitida; la vista es el filtro de ámbito. Una lectura de nivel superior se verifica contra el conjunto de nombres de vista que creó el ámbito. Cualquier lectura contra el esquema fuente directamente se deniega sin excepción.

El LLM puede escribir cualquier SQL que quiera. Puede citar nombres de tabla, usar UNION, usar ATTACH, usar la gramática completa de SQLite. No puede lograr leer una fila de una tabla que no esté en la lista blanca, porque el autorizador intercepta la lectura en la capa C antes de que se resuelva el nombre de la tabla. El filtro a nivel de aplicación es evitable. La autorización del motor de almacenamiento no lo es.

Unas 50 líneas de Python estándar. Sin dependencias adicionales, sin procesos adicionales, sin migración de esquema. La sobrecarga por consulta es una devolución de llamada C por lectura, invisible frente al costo de la consulta misma. El patrón se compone limpiamente con todo lo demás: el registro de herramientas del agente aún puede tener restricciones de características, las definiciones de vistas aún pueden codificar redacción a nivel de columna, el historial de conversaciones aún puede redactarse en tiempo de escritura. Ninguna de esas capas se debilita por la ejecución a nivel de almacenamiento. Se ven reforzadas por ella.

El marco importa. Todos los demás patrones de seguridad en los 19 sistemas son sugerencias. El motor de almacenamiento es la autoridad.

Tres más que merecen ser nombrados

Protección contra condiciones de carrera en limpieza asíncrona (llm-wiki)

El mantenimiento de la memoria en segundo plano es fundamentalmente conflictivo con las acciones del usuario en primer plano. Una barrida que comenzó contra el proyecto A y termina contra el proyecto B ha corrompido ambos. Ha movido las decisiones de A al almacén de revisión de B, o ha marcado los elementos de B como resueltos con los datos de A. Esta es una clase de error fácil de introducir, difícil de detectar e imposible de recuperar limpiamente porque el estado corrupto parece legítimo.

llm-wiki ejecuta un bucle de revisión en segundo plano de dos etapas y, en cada punto de rendimiento, vuelve a verificar dos señales de protección contra condiciones de carrera: una señal de cancelación activada por el controlador de cambio de proyecto, y una comparación de ruta contra el proyecto actual en el almacén de la interfaz de usuario. Si alguna de las dos verificaciones falla, la barrida regresa a mitad de vuelo sin aplicar decisiones. El protocolo de cambio de proyecto en el lado de la cola completa el panorama: vacía el estado del proyecto activo al disco antes de limpiar la memoria, revierte los elementos en procesamiento a pendientes, cancela tanto la llamada LLM en vuelo como el juicio de barrida en vuelo, y solo entonces escribe en la ruta del proyecto pausado.

El meta-patrón es la conclusión: determinista donde puedas, LLM donde debas, cancelable en todas partes. La estructura de dos etapas mantiene al LLM fuera de los casos que simples comprobaciones de existencia pueden manejar. La protección contra condiciones de carrera mantiene ambas etapas cancelables. La combinación es una plantilla para cualquier bucle de mantenimiento de memoria en segundo plano en cualquier sistema.

El constructor de no operación degradado automáticamente (graymatter)

El diseño de API de bibliotecas tiene una tensión recurrente. El "hola mundo" más simple quiere que la biblioteca funcione sin más, una línea para construir, una para llamar. La postura de producción más defendible quiere que falle ruidosamente en la construcción con un error estructurado que la persona que llama no pueda ignorar.

graymatter elige fallar en silencio, pero con una disciplina que convierte la compensación en productiva. El constructor nunca devuelve un error. Si la inicialización falla, bbolt está bloqueado, el directorio de datos no se puede escribir, el almacén de vectores no se puede abrir, registra en stderr y devuelve un objeto Memory degradado cuyos métodos son todos no operaciones. Las personas que llaman en producción verifican a través de Healthy() antes de confiar en el identificador. La biblioteca se puede obtener con go get, importar en tres líneas y funciona en la demostración. Healthy() es el impuesto de disciplina de producción.

El patrón hace que la biblioteca sea segura de incrustar en arneses de agentes que tienen su propia ceremonia de inicio. Un arnés de agente que llama a [graymatter.New](https://graymatter.new/)(...) durante el arranque, ignora la ruta de error porque no hay ruta de error, y continúa, obtiene una capa de memoria funcional en la ruta feliz y un respaldo sin memoria cuando el directorio de datos es de solo lectura. De cualquier manera, el arnés arranca. Ese es un tipo específico de composición defensiva que los constructores de fallo ruidoso no pueden ofrecer sin manejo explícito de errores en cada sitio de incrustación.

Detección de duplicados en modo sombra (mem9)

Todo sistema que implementa supresión de duplicados tiene que elegir un umbral de similitud de coseno. Por encima de 0.95 es casi con certeza un duplicado. Por debajo de 0.7 es casi con certeza que no. El espacio intermedio es disputado, y el corte correcto depende del modelo de incrustación, el dominio, la distribución de consultas y el costo de los falsos positivos frente a los falsos negativos en este sistema particular.

La tentación es abrumadora de elegir uno basado en la intuición y lanzarlo. mem9 no lo hace. Ejecuta la consulta de detección de duplicados para cada hecho, registra la puntuación de coseno en un histograma de Prometheus y no toma ninguna acción. El umbral se difiere hasta que los datos de producción lo justifiquen. "Lanza la observación, no la heurística."

La misma lógica se aplica a cada decisión umbralizada en cada sistema de memoria. Umbral de reordenación. Límite de confianza de recuperación. Puerta de calor de promoción de nivel. Puerta de similitud de fusión de ideas. La mayoría de los sistemas en los 19 envían estos valores adivinados. mem9 envía con el valor diferido. La disciplina es rara y el resultado es mejor.

Cuatro más, más concretos

Aislamiento de base de datos física por inquilino (mem9).

En lugar de un filtro WHERE tenant_id = ? en un almacén compartido, mem9 aprovisiona un clúster TiDB separado por inquilino a través de TiDB Zero. El aislamiento es del lado del motor de almacenamiento. La aplicación no puede consultar accidentalmente entre inquilinos porque no hay un almacén compartido para consultar. Es una versión más gruesa del mismo estado final que la autorización a nivel de almacenamiento: aislamiento ejecutado en el motor, no en la aplicación. El costo de infraestructura que históricamente hacía esto poco práctico ya no existe. TiDB Zero autoaprovisiona. Neon hace lo mismo para PostgreSQL. Cloudflare D1 hace lo mismo para SQLite.

Decoración de turnos de origen con presupuesto de contexto explícito (mem9).

Un recuerdo recuperado es una cadena. "El usuario prefiere Postgres." Correcto, conciso, imposible de fundamentar sin contexto. mem9 adjunta los turnos de conversación de origen como decoración, puntuados contra la consulta y limitados por un triple presupuesto: puntuación mínima, límite por recuerdo, límite total. El agente que lee "El usuario prefiere Postgres" obtiene el turno donde el usuario dijo "probamos MongoDB pero las uniones nos mataron, así que cambié a Postgres el trimestre pasado." No se requiere una segunda llamada a herramienta. La fundamentación está en el resultado. Los requisitos previos ya son universales: procedencia más recuperación híbrida. La mayoría de los sistemas en los 19 podrían implementar esto en dos días.

purpose.md como cuarto archivo (llm-wiki).

El patrón de LLM Wiki de Karpathy tiene tres archivos canónicos: fuentes sin procesar, el conjunto de trabajo del wiki y schema.md para reglas estructurales. llm-wiki añade un cuarto: purpose.md, completado por el usuario, incluido en cada llamada LLM que el sistema realiza. Cada indicación de ingesta, cada indicación de generación, cada chat de recuperación lo lee. El efecto es una prioridad direccional estable que condiciona todos los comportamientos posteriores. El LLM va a leer la indicación del sistema de todos modos. Añadir la intención del usuario no cuesta nada y lo eleva todo. La ausencia en la mayoría de los otros sistemas es más difícil de explicar que su presencia en llm-wiki.

AGENTS.md como contrato de agente autoritativo (Tolaria, OpenContext). La mayoría de los repositorios con un AGENTS.md o CLAUDE.md lo tratan como un archivo de sugerencias. Tolaria y OpenContext lo tratan como un contrato, respaldando cada cláusula vinculante con una verificación mecánica que falla la compilación si el agente la viola. "No omitir los ganchos de pre-commit" no es una solicitud educada, es una regla que el CI ejecuta. "La cobertura de pruebas debe mantenerse por encima del umbral" no es una directriz, es una barra en la que el ejecutor de pruebas aborta. Una sugerencia puede ignorarse. Un contrato respaldado por una verificación no puede. Dos sistemas ya lo hacen. Uno más y se gradúa.

Cuáles se universalizarán a continuación

La autorización a nivel de almacenamiento se universalizará primero. Esta es la predicción más segura del análisis de la fuente. Cada sistema de memoria que le da a un subagente acceso SQL está a una inyección de instrucciones de una violación de confidencialidad sin ejecución a nivel de almacenamiento. La infraestructura ya está en su lugar. SQLite tiene set_authorizer desde principios de los 2000. PostgreSQL RLS es mainstream. LanceDB y ClickHouse tienen sus propios ganchos de política. La barrera no es técnica, es de conciencia. second-brain ha proporcionado el ejemplo práctico. La próxima generación de API gestionadas copiará la disciplina porque la alternativa es indefendible.

La decoración de turnos de origen se universalizará en segundo lugar. Los requisitos previos ya son universales. La implementación son dos consultas más un presupuesto. La ganancia de información del lado del agente es lo suficientemente grande como para que quien la envíe primero en una API gestionada sea visiblemente mejor para fundamentar respuestas en el diálogo de origen que quien la envíe segundo. La presión para copiar es alta. graymatter tiene el origen por hecho. supermemory tiene linaje. Hindsight tiene procedencia conversacional completa. Cualquiera de estos está a una PR del patrón.

El constructor de no operación degradado automáticamente se universalizará en tercer lugar, y en un lenguaje diferente. Las condiciones culturales de Go hacen que el patrón sea seguro. Es poco probable que el próximo adoptante sea Python, la cultura es demasiado entusiasta con las excepciones, pero podría ser Rust. Es una decisión de diseño de API de biblioteca, no una decisión de memoria, y se extenderá dondequiera que "estética de demostración más disciplina de producción" sea la compensación correcta.

El despliegue en modo sombra es el caballo oscuro. Técnicamente trivial, culturalmente difícil. Si un segundo sistema instrumenta un umbral antes de ponerle una puerta, el patrón se gradúa inmediatamente, y el tercero y cuarto siguen dentro de un ciclo de lanzamiento porque la ergonomía de ingeniería es incontestable una vez demostrada.

Los cuatro restantes son cada uno condicionales a que una forma de despliegue específica se vuelva más común. La protección contra condiciones de carrera se universaliza cuando más sistemas incorporen paralelismo de múltiples conversaciones. El aislamiento físico por inquilino se universaliza cuando los clientes empresariales regulados comiencen a solicitarlo. purpose.md se universaliza cuando el paradigma de LLM Wiki de Karpathy tenga su tercera o cuarta implementación. AGENTS.md como contrato se universaliza cuando el marco de "los agentes son colegas" se convierta en la metáfora de arnés dominante. Ninguno es inverosímil. Ninguno es seguro.

Conclusión

El hilo unificador de los ocho es la misma posición: la capa de aplicación no es un límite de aislamiento confiable. La autorización a nivel de almacenamiento es la expresión por agente. Las bases de datos físicas por inquilino son la expresión por inquilino. AGENTS.md como contrato es la expresión por comportamiento del agente. La próxima iteración de este corpus contendrá, según esta predicción, un nuevo patrón universal con ese nombre.

El artículo anterior argumentó que el agente debería tener las herramientas y decidir qué recuperar. Este trata sobre lo que se mantiene cuando el agente dirige esas herramientas a algún lugar que no esperabas. Los seis patrones universales son consenso. Los ocho aquí son los indicadores adelantados de hacia dónde se mueve el consenso a continuación. La autorización a nivel de almacenamiento es el borde de ataque del borde de ataque, y el costo de perdérselo es el tipo de costo que aparece en Hacker News.