Algo interesante está sucediendo en el espacio de la infraestructura agentica, y no es lo que la mayoría esperaba. Durante los últimos dos años, el paradigma dominante para dar a los agentes acceso al conocimiento ha sido Retrieval-Augmented Generation: embebe tus documentos, almacénalos en una base de datos vectorial y deja que el modelo los consulte en tiempo de inferencia. RAG funcionó. Era lo suficientemente bueno. Pero \"lo suficientemente bueno\" tiene fecha de caducidad, y en 2026 esa fecha está expirando.
\n\nUn nuevo patrón está emergiendo en toda la industria, y está convergiendo desde múltiples direcciones a la vez. Mintlify reemplazó toda su pipeline de RAG por un sistema de archivos virtual y vio cómo la creación de sesiones pasaba de 46 segundos a 100 milisegundos [1]. Turso construyó AgentFS, un sistema de archivos respaldado por SQLite que le da a cada agente su propio sandbox copy-on-write [2]. Box, el gigante empresarial de contenido, anunció que está reposicionando toda su plataforma como una capa de sistema de archivos virtual para agentes de IA [3]. Y ByteDance liberó como open source OpenViking, una base de datos de contexto que organiza toda la memoria, recursos y habilidades del agente como un sistema de archivos jerárquico [4].
\n\nEstos no son experimentos de nicho. Son señales de un cambio fundamental. El sistema de archivos se está convirtiendo en la interfaz universal para la cognición de los agentes, y la base de datos está pasando a ser silenciosamente su sustrato.
\n\nRAG era la respuesta correcta para 2023. Tenías un montón de documentos, un modelo con una ventana de contexto limitada, y necesitabas una forma de mostrar fragmentos relevantes en el momento de la consulta. Los embeddings vectoriales y la búsqueda por similitud resolvieron ese problema elegantemente.
\n\nPero los agentes no son chatbots. Un agente no hace una pregunta y se va. Explora. Lee un archivo, descubre una referencia, la sigue, lee otro archivo, ejecuta un comando, escribe un resultado. Este no es un problema de recuperación. Es un problema de navegación.
\n\nLas pipelines de RAG luchan con esto por tres razones. Primero, son stateless por diseño. Cada consulta es independiente; no existe el concepto de \"estaba mirando este directorio, ahora muéstrame el archivo adyacente\". Segundo, aplanan la estructura. Un sitio de documentación con una jerarquía clara de secciones, páginas y ejemplos de código se desmenuza en fragmentos anónimos de 512 tokens que pierden su contexto organizacional. Tercero, son caras a escala. El cálculo de embeddings, el mantenimiento del índice vectorial y el re-ranking añaden latencia y costo que se acumulan a medida que crece el corpus.
\n\nEl sistema de archivos resuelve las tres. Es inherentemente stateful (el agente tiene un directorio de trabajo). Preserva la estructura (directorios, subdirectorios, archivos). Y es rápido porque las operaciones son simples: ls, cat, grep, find. Estas no son abstracciones novedosas. Son la interfaz más probada en la computación.
Lo que hace significativo este momento es que el patrón del sistema de archivos está emergiendo de forma independiente en contextos muy diferentes.
\n\nChromaFs de Mintlify es quizás el ejemplo más ilustrativo. Mintlify potencia asistentes de documentación para miles de empresas. Su arquitectura original era RAG de manual: fragmentar los documentos, embeberlos, recuperarlos en el momento de la consulta. Cuando la reemplazaron por ChromaFs, un sistema de archivos virtual que intercepta comandos UNIX y los traduce en consultas a la base de datos Chroma, los resultados fueron dramáticos. La creación de sesiones pasó de 46 segundos a 100 milisegundos, una mejora de 460x. El costo marginal por conversación cayó de $0.0137 a efectivamente cero [1]. La idea clave: el agente ya sabe cómo navegar un sistema de archivos. Enseñarle a usar cat /auth/oauth.mdx es trivial comparado con enseñarle a formular la consulta vectorial correcta.
AgentFS de Turso ataca un problema diferente: el aislamiento y la auditabilidad del agente. Cada agente obtiene su propio sistema de archivos respaldado por SQLite con semántica copy-on-write. El sistema de archivos del host es una capa base de solo lectura; el agente escribe en una capa delta de SQLite. Cada operación de archivo, llamada a herramienta y cambio de estado se registra. Todo el runtime del agente, archivos, estado, historial, cabe en un único archivo SQLite portable [2]. Esto no es solo un sistema de archivos. Es un entorno de ejecución auditable y reproducible.
\n\nEl VFS empresarial de Box es el más significativo desde el punto de vista estratégico. El CEO de Box, Aaron Levie, ha sido explícito: los agentes necesitan un sistema de archivos para hacer trabajo de conocimiento en la empresa [3]. Pero Box no está proponiendo un sistema de archivos literal. Están proponiendo un \"contrato dinámico de entrega de datos\" que puede estar respaldado por almacenamiento de objetos, bases de datos relacionales o su propia plataforma de contenido. El sistema de archivos es la interfaz; el almacenamiento subyacente es lo que tenga sentido para los datos. Lo que hace interesante la apuesta de Box es la capa de gobernanza: permisos, trazas de auditoría y límites de cumplimiento que se transfieren automáticamente desde la plataforma de contenido al agente.
\n\nOpenViking de ByteDance lleva el patrón más allá. Organiza todo el contexto del agente, memorias, recursos, habilidades, conocimiento, bajo un protocolo viking:// usando semánticas estándar de sistema de archivos. Los agentes navegan con ls y find. Pero la parte inteligente es el modelo de acceso por niveles: cada pieza de contexto se procesa en tres capas. L0 es un resumen de una oración para recuperación rápida. L1 es una visión general con información central para la planificación. L2 es el contenido completo para lectura profunda [4]. El agente comienza con L0, profundiza en L1 cuando necesita más, y solo carga L2 cuando está haciendo trabajo detallado. En el benchmark LoCoMo, esto redujo el consumo de tokens de 24.6 millones a 4.2 millones mientras aumentaba las tasas de finalización de tareas al 52% [4].
El patrón que conecta los cuatro es lo que yo llamaría la dualidad VFS: el sistema de archivos gana como interfaz, y la base de datos gana como sustrato. Esta no es una elección de uno u otro. Es una arquitectura por capas.
\n\nPor qué el sistema de archivos gana como interfaz es directo. Los LLMs se entrenan en internet, e internet está construida por desarrolladores que piensan en términos de archivos, directorios, rutas y herramientas de línea de comandos. Los modelos son inusualmente competentes con estas primitivas porque han visto miles de millones de ejemplos de desarrolladores navegando bases de código, leyendo archivos y ejecutando comandos de shell. Cuando le das a un agente un sistema de archivos, te estás encontrando con él donde viven sus datos de entrenamiento.
\n\nPor qué la base de datos gana como sustrato es igualmente claro. En el momento en que la memoria del agente necesita ser compartida, auditada, consultada por múltiples agentes, o hecha confiable bajo concurrencia, necesitas garantías de base de datos. Transacciones ACID, control de acceso, búsqueda semántica, historial de versiones: estos son problemas difíciles que las bases de datos han pasado décadas resolviendo. Reimplementarlos sobre un sistema de archivos literal es un camino al dolor.
\n\nEl patrón VFS te da ambos. El agente ve archivos y directorios. El sistema ve tablas, índices y listas de control de acceso. ChromaFs almacena todo en Chroma pero lo expone como archivos. AgentFS almacena todo en SQLite pero lo expone como un sistema de archivos POSIX. OpenViking usa su propio motor de almacenamiento pero lo expone como rutas viking://. Box usa su plataforma empresarial de contenido pero la expone como un árbol navegable.
La objeción natural a todo esto es: ¿por qué no usar simplemente el sistema de archivos real? POSIX está ahí. Cada sistema operativo lo incluye. ¿Por qué añadir una capa de abstracción?
\n\nQuería responder esta pregunta empíricamente, así que construí markdownfs, un sistema de archivos virtual hecho desde cero en Rust diseñado específicamente para cargas de trabajo de agentes [6]. Soporta el conjunto completo de comandos tipo UNIX (ls, cat, grep, find, chmod, chown), versionado estilo Git con almacenamiento direccionable por contenido, permisos multiusuario, y expone tres métodos de acceso: una CLI/REPL, una API HTTP/REST, y un servidor MCP al que agentes como Claude y Cursor pueden conectarse directamente.
La arquitectura es simple: una tabla de inodos en memoria respaldada por un almacén de blobs direccionable por contenido usando hashing SHA-256, con tokio::RwLock para acceso concurrente seguro. Los archivos se desduplican automáticamente. El control de versiones usa el mismo modelo de commit/revert que Git, pero a nivel del sistema de archivos. La persistencia se maneja a través de snapshots atómicos de bincode.
Cuando hice benchmark de markdownfs contra el sistema de archivos nativo a través de las operaciones estándar de agentes (creación de archivos, lecturas, escrituras, listado de directorios, grep, find, mover, copiar, eliminación), markdownfs promedió aproximadamente 130x más rápido en todos los frentes. Las razones son estructurales, no incidentales. Las operaciones en memoria eliminan por completo el I/O de disco. El almacenamiento direccionable por contenido significa que los archivos duplicados se almacenan una sola vez. Las lecturas zero-copy significan que el agente obtiene datos sin overhead de serialización. Y porque todo el estado del sistema de archivos vive en un único proceso, no hay límites de llamadas al sistema que cruzar.
\n\nLa comparación es particularmente marcada para las operaciones que los agentes realizan con mayor frecuencia:
\n\n| Operación | \nPor qué gana el VFS | \n
|---|---|
| Lecturas repetidas (agente releyendo contexto) | \nEn memoria, zero-copy. Sin búsquedas en disco, sin fallos de caché de página. | \n
| grep entre archivos (agente buscando patrones) | \nTodo el contenido está en memoria. Sin recorrido de directorios, sin gestión de file handles. | \n
| Creación rápida de archivos (agente produciendo artefactos de trabajo) | \nSin journaling del sistema de archivos, sin asignación de inodos en disco, sin fsync. | \n
| Listado de directorios (agente explorando estructura) | \nBúsqueda en BTreeMap vs. syscalls de readdir. | \n
Pero el rendimiento no es el argumento real. El argumento real es lo que el sistema de archivos nativo no puede hacer. Un sistema de archivos POSIX no tiene concepto de búsqueda semántica. No tiene versionado integrado (necesitas Git para eso). No tiene un modelo de acceso por niveles (obtienes todo el archivo o nada). No tiene desduplicación de contenido. No tiene una traza de auditoría de operaciones de agentes. Y críticamente, no tiene una interfaz MCP, lo que significa que los agentes no pueden acceder a él a través del protocolo estándar en el que el ecosistema está convergiendo.
\n\nEl VFS no es solo más rápido. Es una primitiva más rica. Te da la interfaz familiar de ls y cat mientras añade las capacidades que los agentes realmente necesitan: versionado, permisos, búsqueda, desduplicación y acceso nativo al protocolo vía MCP o HTTP.
Para ser claros, RAG no está muerto. La búsqueda vectorial sigue siendo valiosa para consultas difusas y semánticas donde el agente genuinamente no sabe qué está buscando. Pero la evaluación honesta es que RAG se ha sobreaplicado. Muchos de los casos de uso donde los equipos desplegaron pipelines de RAG, recuperación de documentación, navegación de bases de código, gestión del conocimiento empresarial, se sirven mejor con una interfaz de sistema de archivos.
\n\nLa evidencia es contundente. La mejora de 460x de Mintlify vino de reemplazar RAG por un sistema de archivos, no de aumentarlo [1]. Investigación de Letta muestra que los agentes usando operaciones simples de sistema de archivos alcanzan un 74% de precisión en benchmarks de memoria, competitivo con herramientas especializadas de recuperación. Y los enfoques agenticos de búsqueda por keywords pueden alcanzar más del 90% del rendimiento de RAG sin bases de datos vectoriales [5].
\n\nEl futuro probablemente será híbrido. RAG para búsqueda semántica abierta. Sistema de archivos para navegación estructurada y ejecución de tareas. Pero el centro de gravedad se está desplazando hacia el sistema de archivos, y las implicaciones estratégicas son significativas.
\n\nSi estás construyendo infraestructura agentica, necesitas una estrategia de VFS. He aquí por qué.
\n\nPara empresas SaaS: la lección de Box es que el sistema de archivos se está convirtiendo en la superficie de integración para los agentes. Si el contenido de tu plataforma no es navegable como un sistema de archivos, los agentes te pasarán de largo. Las empresas SaaS que exponen sus datos a través de interfaces tipo sistema de archivos se convertirán en parte del flujo de trabajo agentico. Las que no lo hagan se volverán invisibles para los agentes, lo que significa invisibles para los usuarios.
\n\nPara proveedores de infraestructura: la base de datos no va a desaparecer. Se está moviendo debajo del sistema de archivos. Esto es en realidad una buena noticia para las empresas de bases de datos. Turso entendió esto y construyó AgentFS sobre SQLite. Cada agente que se inicia crea una nueva base de datos. Cuántos más agentes ejecute el mundo, más bases de datos necesitará el mundo. Pero la base de datos necesita desaparecer detrás de una abstracción de sistema de archivos.
\n\nPara empresas: lo que importa es la historia de gobernanza. La propuesta de Box no es realmente sobre sistemas de archivos. Se trata del hecho de que su modelo de permisos, traza de auditoría e infraestructura de cumplimiento se extienden automáticamente a los agentes cuando el contenido se accede a través de la capa VFS [3]. Esta es la respuesta a la pregunta que cada CISO se está haciendo: \"¿Cómo permitimos que los agentes accedan a nuestro contenido sin crear una pesadilla de seguridad?\"
\n\nEl stack de infraestructura agentica ha estado evolucionando en fases claras: herramientas (MCP), habilidades y grafos de contexto. El sistema de archivos virtual encaja en este arco como el mecanismo de entrega para los tres. Las herramientas MCP se invocan a través del sistema de archivos. Las habilidades se almacenan como archivos. Los grafos de contexto se navegan como árboles de directorios. El sistema de archivos no reemplaza estas capas. Las unifica detrás de una única interfaz familiar.
\n\nEsta es la verdadera idea. El sistema de archivos no es una idea nueva. Es la abstracción más antigua de la computación. Pero eso es exactamente por qué funciona para los agentes. En un mundo donde estamos inventando nuevos paradigmas cada trimestre, el movimiento más poderoso podría ser volver a la interfaz más probada que tenemos y poner una base de datos moderna detrás.
\n\nLas empresas que entienden esto, Mintlify, Turso, Box, ByteDance, no están construyendo algo nuevo. Están reconociendo algo viejo y dándole un nuevo trabajo.
\n\nReferencias:
\n\n\n\n\n\n\n\n\n\n\n\n", "source_hash": "sha256:b576661fe0d14759bc1b074608bc4208873bd898abf89987b9d7e9a126ba21b9", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T07:26:02.778141+00:00" }