Si miras cómo están arquitecturados la mayoría de los sistemas de memoria de agentes de IA en producción, encontrarás un patrón familiar: una base de datos vectorial como Pinecone o Weaviate para búsqueda semántica, Elasticsearch u OpenSearch para búsqueda por palabras clave, Redis para caché de memorias calientes, y Postgres para datos estructurados. Cuatro servicios que desplegar, cuatro servicios que monitorear, cuatro servicios que pueden fallar, cuatro facturas a fin de mes.
La complejidad se trata como inevitable —el precio que pagas por una memoria capaz. Pero no es inevitable. Es una consecuencia de recurrir a herramientas de sistemas distribuidos para resolver un problema que no los requiere.
La memoria de ZeroClaw es un único archivo SQLite. Aquí está por qué eso no es un compromiso.
La trampa de la infraestructura
Las bases de datos vectoriales son herramientas genuinamente poderosas. Para un sistema RAG sobre millones de documentos, o un motor de búsqueda sobre un corpus grande, son la elección correcta. Pero la memoria de los agentes de IA es un problema diferente.
La mayoría de los agentes almacenan miles de memorias, no millones. Un año de conversaciones diarias podría producir 50.000 turnos de conversación. Eso no es un problema de big data —es un problema de datos pequeños que se trata como un problema de datos grandes porque las herramientas fueron diseñadas para otra cosa.
El coste de ese desajuste es real. Pinecone empieza en 70 USD/mes para uso en producción. Weaviate requiere un servidor en ejecución. Cada búsqueda de memoria es un viaje de ida y vuelta por la red —típicamente 10-50 ms— que añade latencia a cada respuesta.
Por qué SQLite es la base correcta
SQLite es la base de datos más desplegada del mundo. Corre en cada smartphone, cada navegador, cada dispositivo embebido. Ha estado en desarrollo continuo desde 2000, tiene un conjunto de pruebas exhaustivo y es usado en producción por empresas que manejan miles de millones de transacciones. No es un juguete.
ZeroClaw usa dos extensiones de SQLite juntas para construir un sistema de memoria que maneja ambas cosas que los agentes necesitan: recuperación exacta y comprensión semántica.
FTS5: Búsqueda de texto completo
La extensión FTS5 de SQLite proporciona búsqueda rápida por palabras clave con ranking BM25:
```sql CREATE VIRTUAL TABLE memory_fts USING fts5(content, tokenize='porter');
-- Buscar memorias sobre "despliegue en Rust" SELECT * FROM memory_fts WHERE memory_fts MATCH 'rust deployment' ORDER BY rank; ```
FTS5 maneja la tokenización, el stemming y el ranking automáticamente. Es rápido —submilisegundo para tamaños típicos de memoria de agentes— y sobresale en la recuperación exacta.
Búsqueda vectorial: similitud semántica
ZeroClaw almacena vectores de embeddings junto al texto y realiza búsqueda de similitud coseno directamente en SQLite. Esto maneja los casos donde la búsqueda por palabras clave se queda corta: encontrar memorias que están conceptualmente relacionadas incluso cuando no comparten palabras exactas.
"Mi configuración de Raspberry Pi" coincide con "despliegue en hardware ARM" aunque no comparten palabras clave. La búsqueda vectorial entiende el significado, no solo las palabras.
Búsqueda híbrida: obteniendo ambas cosas bien
Ninguno de los enfoques por sí solo es suficiente. La búsqueda por palabras clave pierde conexiones semánticas. La búsqueda vectorial pierde coincidencias exactas —buscar "CVE-2026-25253" podría devolver contenido de seguridad vagamente relacionado en lugar del CVE específico que buscas.
ZeroClaw ejecuta ambas búsquedas en paralelo y fusiona los resultados usando Reciprocal Rank Fusion:
```sql score(doc) = 1/(k + rank_fts) + 1/(k + rank_vector) ```
Donde `k` es una constante (típicamente 60) que controla cuánto peso va a los resultados mejor clasificados. Los documentos que se clasifican alto en ambas búsquedas suben a la cima.
Los números de rendimiento
En una Raspberry Pi Zero 2 W —el hardware más limitado en el que ZeroClaw corre comúnmente— la recuperación de memoria tarda menos de 3 ms en total: aproximadamente 0,3 ms para la búsqueda FTS5, 2 ms para la búsqueda vectorial y 0,1 ms para fusionar los resultados. En hardware x86, estos números son submilisegundo.
Para comparar, un viaje de ida y vuelta por la red a Pinecone o Weaviate típicamente tarda 10-50 ms. La recuperación de memoria de ZeroClaw es más rápida que el tiempo que tarda un único paquete de red en viajar a través de una ciudad.
Tu memoria es solo un archivo
La consecuencia práctica de la memoria basada en SQLite es que todo tu historial de conversaciones, todo el contexto aprendido de tu agente, todo lo que sabe sobre ti —vive en un único archivo llamado `memory.db`.
Hacer una copia de seguridad es `cp memory.db memory.db.bak`. Moverlo a una nueva máquina es copiar el archivo. Inspeccionarlo es abrirlo con cualquier cliente SQLite. No hay herramientas de exportación, no hay scripts de migración, no hay llamadas a la API que hacer.
Cero infraestructura, cero coste, cero complejidad, y rendimiento que las bases de datos externas no pueden igualar porque no hay red de por medio. Para la memoria de agentes de IA, eso no es un compromiso —es el diseño correcto.