He visto demasiados ingenieros darle a un agente acceso total a su base de conocimiento y luego sorprenderse cuando todo se incendia.
Siempre pasa igual. Alguien conecta un modelo capaz con acceso al sistema de archivos, lo apunta a una carpeta llena de notas, código, contratos o investigación, y lo suelta. Por un tiempo, es magia. Luego, un día, el agente decide que la forma más limpia de “arreglar” un documento es sobreescribirlo. O refactoriza con confianza un archivo que no leyó del todo. O hace lo correcto en papel pero al archivo equivocado. El trabajo que desaparece rara vez es el que elegirías perder.
El problema más profundo es estructural, y no tiene que ver con el mal día de un agente en particular. Hay tres modos de fallo que veo repetirse en los equipos con los que hablo (Desafortunadamente, casi siempre esdespuésde que ya perdieron datos).
Escrituras destructivas. La del ejemplo anterior. Un agente con amplio acceso de escritura trata tu carpeta de fuente de verdad como un banco de trabajo. Los usuarios le señalan al agente “las cosas que puede tocar”, pero no definen un límite real de lectura/escritura. El agente no sabe qué archivos son intocables porque nadie se lo dijo, el contexto se comprimió y las instrucciones ya no están, o simplemente se convenció a sí mismo de que “rm ~/Pictures/Wedding” es la forma más efectiva de “organiza mis fotos, por favor”.
Dependencia del proveedor. Un equipo se convence de adoptar la función de “memoria” que trae su producto de AI actual. Seis meses después quieren cambiar de modelo, cambiar de herramienta, o simplemente llevarse su contexto, y no pueden. La memoria vive dentro del producto de otra empresa y nunca fue suya para llevársela.
Memoria de caja negra. Aunque el agente sí recuerde cosas, nadie puede auditarqué recuerda. No puedes ver el diff. No puedes revertirla. No puedes preguntar “¿qué cree actualmente el agente sobre la política de reembolsos?” y obtener una respuesta directa. La memoria no es un artefacto, sino más bien una “vibra” amorfa que vive “en algún lugar”.
Cada uno de estos problemas, por separado, es algo que se puede parchar. Juntos, son un error de categoría. Hemos tratado la memoria de un agente como una función del agente. No lo es. Es el sustrato sobre el que corre el agente, y ahora mismo casi nadie es dueño del suyo.
Por qué deberías ser dueño de la capa de memoria de tu agente
Si te llevas algo de este artículo, que sea esto:la capa de memoria de tu agente debe ser algo que puedas sostener en tu mano.
Local. Portable. Inspeccionable. Tuya.
Eso tiene una forma distinta a lo que la mayoría de los productos te están vendiendo. Las herramientas cerradas que compiten por ser la memoria de tu agente tienen un interés real en mantener tu contexto dentro de sus muros. Una vez que tu conocimiento vive en su formato, en su nube, detrás de su cuenta, es mucho menos probable que te vayas. El discurso es “nosotros recordamos las cosas por ti”. La segunda parte no dicha es “y preferimos que no puedas llevártelas”.
No tienes que aceptar ese trato. Y no tienes que creerme solo a mí,no soy el único que lo dice.
Agent Library
El Agent Library es la capa de memoria que queríamos y no teníamos. Es un archivo SQLite local con búsqueda híbrida semántica y por palabras clave, ingiere texto, código, PDFs e imágenes, habla MCP de forma nativa y corre completamente en tu propia máquina. Sin cuenta en la nube. Sin que ningún proveedor vea tus documentos. Sin re-generar embeddings de los mismos documentos en cinco herramientas distintas.
Hoy lo publicamos como open source. El repositorio está en https://github.com/ArcadeAI/agent-library, y hay unvideo que muestra cómo se siente usarlo en la práctica. Ahí te muestro:
- Cómo configurar un nuevo Agent Library
- Cómo agregar fuentes
- Cómo mantener la Library indexada
- Cómo usarlo en múltiples herramientas de agentes
- Cómo usarlo en el CLI
- Cómo buscar contenido en la library
- Cómo gestionar el contenido dentro
Si quieres todos los detalles, ve a verlo.
El límite de lectura/escritura
La decisión de diseño más importante del Agent Library es que, desde el punto de vista del agente,la library es principalmente de lectura.
La mayoría de lo que un agente necesita de una capa de memoria es acceso de lectura: buscar en la library, traer el fragmento relevante, fundamentar la respuesta. El servidor MCP del Agent Library expone un pequeño conjunto de herramientas de lectura (search_library , read_from_library y otras) que cubren ese 90% de los casos. También expone herramientas de escritura (add_to_library , update_library_doc , remove_from_library) para los casos en que quieres que el agente mantenga sus propias notas, pero esas sonopt-in.
Si estás empezando desde cero,expón solo las herramientas de lectura. Una library configurada así no puede, por construcción, borrar tus notas, sobreescribir tu código ni corromper tus PDFs. El agente puede hacerle preguntas a tu base de conocimiento todo el día; no puede editarla.
Cuando algo sí falla (y en algún momento pasará), entra en juego la segunda propiedad: el estado completo del Agent Library es un único archivo SQLite que es tuyo. Puedescp respaldarlo antes de soltar al agente. Puedes comparar dos versiones. Puedes revertir al índice del martes pasado. Puedes abrirlo en cualquier navegador de SQLite y ver, byte a byte, qué sabe el agente en este momento. Eso es una relación distinta con la “memoria” que una caja negra en la nube de otro, y es la relación que quieres la primera vez que un agente te sorprende.
Para ser completamente claro,el Agent Library es una herramienta afilada. Reduce el radio de daño, pero no lo elimina. Si le das a un agente acceso al shell, acceso de escritura al sistema de archivos y Librarian al mismo tiempo, Agent Library no te puede salvar. El agente igual puederm -rf abrirse camino por tu sistema sin importar qué tan cuidadoso sea el Agent Library. El punto es que la capa de memoria del agente no debería ser la que te traicione, y ahora mismo, para demasiada gente, lo es.
Por qué esta forma
El Agent Library tiene opiniones, y esas opiniones son de nuestro CTO, Sam Partee, quien lo construyó.
La postura local-first, la separación lectura/escritura, la superficie nativa de MCP, la elección de SQLite sobre una base de datos vectorial hospedada, la insistencia en que el índice sea un archivo que puedas sostener. Todas esas son sus decisiones, y no son arbitrarias. Vienen de años de ver equipos llevar agentes a producción y descubrir, a las malas, qué atajos se pueden tomar y cuáles no. La memoria es uno de los que no se puede.
También por eso lo estamos publicando como open source. Agent Library no es parte del producto de Arcade, sino un bloque de construcción para agentes. El tipo de cosa que construimos para nosotros mismos porque la necesitábamos, y que creemos que suficiente gente necesita como para que no se quede en un repositorio privado.
Bloques de construcción para agentes de Arcade
Agent Library es el primero de varios proyectos que vamos a publicar como open source. Cosas que construimos para nosotros, con opiniones integradas, que creemos que son útiles por sí solas. Independientemente de si alguna vez tocas el resto de lo que hacemos.
Si estás construyendo agentes y has sentido alguno de los modos de fallo al inicio de este post,consíguelo aquí, apúntalo a una carpeta y pruébalo. Empieza con las herramientas de solo lectura. Haz un snapshot del archivo SQLite antes de cualquier cosa ambiciosa. Y si algo explota de todas formas, cuéntanos, o mejor aún, abre un issue o PR. Así el siguiente bloque de construcción se vuelve más preciso.
La memoria de tu agente no debería vivir en el producto de otra persona. Ahora ya no tiene que hacerlo.
FAQ
¿En qué se diferencia esto de otros productos de memoria?
La mayoría de los productos de “memoria” intentan extraer hechos sobre ti de tu historial de chat (“el usuario prefiere Python”, “la empresa del usuario es Arcade”) y alimentar esos hechos en sesiones futuras. Agent Library no hace eso. Indexa un corpus que ya tienes, notas, código, PDFs, imágenes, y le da al agente una forma de buscarlo. La diferencia está en dónde vive la memoria. Tu índice es un único archivo SQLite en tu disco. Puedes copiarlo, compararlo, hacer snapshots, abrirlo en cualquier navegador de SQLite, moverlo entre máquinas. La memoria es tuya en el sentido literal.
¿Esto no es solo RAG?
La forma de recuperación es RAG, búsqueda híbrida semántica más palabras clave sobre documentos fragmentados. Pero RAG es una técnica, y Agent Library es una postura sobre dónde debería correr esa técnica. La contribución no son los embeddings ni el chunking. Es ellímite (una superficie de herramientas principalmente de lectura que un agente no puede corromper fácilmente), elsustrato (un archivo que puedes sostener en tu mano), y lainterfaz (nativa de MCP, para que cualquier herramienta pueda usarla sin pegamento a medida). Podrías reconstruir la parte de recuperación del Agent Library en una tarde. El punto es todo lo que lo rodea.
¿Qué se queda realmente en mi máquina?
Por defecto, todo. El índice, los embeddings, las secciones y, por supuesto, los documentos que ya tenías localmente. El proveedor de embeddings predeterminado es sentence-transformers local, sin llamadas a la red. La única válvula de escape es el endpoint de embeddings compatible con OpenAI: si configuras uno, ese endpoint ve el texto que está incrustando. Nosotros apuntamos el nuestro a un servidor local compatible con OpenAI, lo que mantiene los datos en la máquina. Si lo apuntas a una API hospedada, esa es una decisión que tú estás tomando de forma explícita.
¿Cuál es la relación con el producto de Arcade?
Agent Library está construido sobrearcade-mcp-serverel framework MCP open source de Arcade, igual que cualquier app de Python se construye sobre sus librerías. No requiere una cuenta de Arcade, una API key ni ningún servicio hospedado. El producto de Arcade es algo separado. Agent Library corre de forma independiente.
¿Está listo para producción?
Es la capa de memoria que usamos nosotros mismos localmente, y las decisiones de diseño están consolidadas: la separación lectura/escritura, el sustrato SQLite y la superficie MCP no van a cambiar. Pero es open source desde el día uno. Espera bordes rugosos, espera que la API se afine conforme la gente la use de maneras que no anticipamos, y espera que arreglemos las cosas más rápido si nos dices qué se rompió. Yo empezaría con las herramientas de solo lectura y haría un snapshot del archivo SQLite antes de cualquier cosa ambiciosa.
