Un pequeño retraso en esta última parte de la serie de los 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 de calidad en el momento de escribir. Proveniencia viajando junto al dato. Búsqueda 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 se detienen aquí. A partir de ahí, comienzan los emergentes.
Este artículo trata sobre ocho patrones que se sitúan por debajo del umbral, viviendo en uno o quizás dos sistemas, donde la implementación aborda 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.
Llegar temprano significa que algunos de estos no se universalizarán. Llegar tarde es peor: construyes un sistema en 2026 que se envía sin autorización a nivel de almacenamiento porque una síntesis lo llamó rareza, y recibes una demostración de inyección de prompt en Hacker News en 2027.
El motor de almacenamiento es la única autoridad que se sostiene
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 trillados y todos están equivocados.
Instrucción a nivel de prompt: "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 y 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 en bruto, llama a métodos tipados. Funciona hasta que el sistema incorpore 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 que la regla se rompe y la rotura pasa desapercibida.
Dicho llanamente: ninguna de estas es un mecanismo de cumplimiento. Son sugerencias. Un sistema que quiera un verdadero aislamiento entre subagentes debe pedirle al propio motor de almacenamiento que rechace la lectura, no a la capa superior. Esta es la disciplina que el control de capacidades impone a los recursos del sistema operativo: el núcleo dice 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 alcance tiene tres capas, cada una necesaria, ninguna suficiente por sí sola.
Una conexión SQLite en memoria nueva por agente con alcance. 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 ponga allí.
Vistas TEMP 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 previene la inyección de nombres de tabla maliciosos a través del perfil.
Un gancho de autorización de la API C de SQLite que deniega cualquier lectura del esquema fuente que no pase a través de una vista. El gancho 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 alcance. Una lectura de nivel superior se verifica contra el conjunto de nombres de vista que el alcance creó. Cualquier lectura directa contra el esquema fuente 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 de permitidos, 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 eludible. La autorización del motor de almacenamiento no lo es.
Aproximadamente 50 líneas de Python de la biblioteca estándar. Sin dependencias adicionales, sin procesos extra, sin migraciones de esquema. La sobrecarga por consulta es una devolución de llamada C por lectura, invisible comparada con el costo de la consulta en sí. El patrón se compone limpiamente con todo lo demás: el registro de herramientas del agente puede seguir teniendo restricciones por características, las definiciones de las vistas pueden seguir codificando redacción a nivel de columna, el historial de conversaciones puede seguir redactándose en el momento de escritura. Ninguna de esas capas se debilita por la aplicación a nivel de almacenamiento. Se ven reforzadas por ella.
El encuadre 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 de condiciones de carrera en limpieza asíncrona (llm-wiki)
El mantenimiento de memoria en segundo plano es fundamentalmente propenso a condiciones de carrera 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 que es 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 aborto activada por el manejador 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 verificación falla, la barrida regresa a medio 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 proceso a pendientes, aborta tanto la llamada LLM en curso como el juicio de barrida en curso, y solo entonces escribe en la ruta del proyecto pausado.
El metapatrón es la conclusión: determinista donde puedas, LLM donde debas, abortable en todas partes. La estructura de dos etapas mantiene al LLM fuera de los casos que simples verificaciones de existencia pueden manejar. La protección contra condiciones de carrera mantiene ambas etapas abortables. La combinación es una plantilla para cualquier bucle de mantenimiento de memoria en segundo plano en cualquier sistema.
El constructor no operativo con degradación automática (graymatter)
El diseño de APIs de bibliotecas tiene una tensión recurrente. El "hola mundo" más simple quiere que la biblioteca funcione de inmediato, 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 el llamador no pueda ignorar.
graymatter elige fallar en silencio, pero con una disciplina que convierte la compensación en algo productivo. El constructor nunca devuelve un error. Si la inicialización falla, bbolt está bloqueado, el directorio de datos no es escribible, el almacén de vectores no se puede abrir; registra en stderr y devuelve una instancia de Memory degradada cuyos métodos son todos no operativos. Los llamadores en producción verifican a través de \Healthy()\ antes de confiar en el manejador. La biblioteca se puede obtener con \go get\, se importa en tres líneas y funciona en la demo. \Healthy()\ es el impuesto de disciplina de producción.
El patrón hace que la biblioteca sea segura de incrustar en arneses de agente que tienen su propio 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 el camino 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 que fallan ruidosamente no pueden ofrecer sin un 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 coseno. Por encima de 0.95 es casi con certeza un duplicado. Por debajo de 0.7 es casi con certeza que no lo es. El espacio intermedio es discutido, 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 enviarlo. mem9 no lo hace. Ejecuta la consulta de detección de duplicados para cada hecho, registra la puntuación 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. "Envía 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 reordenamiento. Límite de confianza de recuperación. Puerta de calor de promoción de nivel. Umbral 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 concisos
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 que consultar. Es una versión de grano más grueso del mismo estado final que la autorización a nivel de almacenamiento: aislamiento aplicado en el motor, no en la aplicación. El costo de infraestructura que históricamente hacía esto poco práctico ha desaparecido. TiDB Zero aprovisiona automáticamente. 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 de 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: proveniencia más búsqueda 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 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, llenado por el usuario, incluido en cada llamada LLM que el sistema realiza. Cada prompt de ingesta, cada prompt de generación, cada recuperación de chat lo lee. El efecto es una prioridad direccional estable que condiciona todo comportamiento posterior. El LLM va a leer el prompt del sistema de todas formas. Agregar la intención del usuario no cuesta nada y mejora 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 autorizado (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 hooks de pre-commit" no es una petición educada, es una regla que el CI aplica. "La cobertura de pruebas debe mantenerse por encima del umbral" no es una directriz, es una barrera que el ejecutor de pruebas aborta. Una sugerencia puede ser ignorada. 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 fuente. Cada sistema de memoria que le da a un subagente acceso SQL está a una inyección de prompt de una violación de confidencialidad sin la aplicación a nivel de almacenamiento. La infraestructura ya está en su lugar. SQLite tiene \set_authorizer\ desde principios de los 2000. RLS de PostgreSQL es común. LanceDB y ClickHouse tienen sus propios ganchos de políticas. La barrera no es técnica, es de conciencia. second-brain ha proporcionado el ejemplo práctico. La próxima generación de APIs 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 lo envíe primero en una API gestionada sea visiblemente mejor para fundamentar respuestas en el diálogo fuente que quien lo envíe segundo. La presión para copiar es alta. graymatter tiene la fuente por hecho. supermemory tiene linaje. Hindsight tiene proveniencia conversacional completa. Cualquiera de estos está a un PR del patrón.
El constructor no operativo con degradación automática se universalizará en tercer lugar, y en un lenguaje diferente. Las condiciones culturales de Go hacen que el patrón sea seguro. El próximo adoptante probablemente no sea Python, la cultura es demasiado entusiasta con las excepciones, pero podría ser Rust. Es una elección de diseño de API de biblioteca, no una elección de memoria, y se extenderá donde "estética de demo 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 restringirlo, el patrón se gradúa de inmediato, y el tercero y cuarto siguen dentro de un ciclo de lanzamiento porque la ergonomía de ingeniería es indiscutible 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 LLM Wiki de Karpathy reciba 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 dominante del arnés. Ninguno es improbable. Ninguno es seguro.
Una 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á, en 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 sostiene 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 filo de la vanguardia, y el costo de pasarla por alto es el tipo de costo que aparece en Hacker News.
