Los agentes de programación ya dejan un registro detallado de su trabajo: exploran el código, prueban soluciones, encuentran errores, consultan documentación y cambian de dirección. El problema es que ese registro suele quedarse archivado, sin una forma práctica de consultarlo cuando aparece una tarea relacionada.
Hugging Face propone una solución con funes, una capa de memoria duradera para agentes como Claude Code, Codex, pi y Hermes. La herramienta convierte las sesiones anteriores en una memoria local, consultable y con referencias exactas al origen de cada decisión.
De las trazas archivadas a la memoria útil
Guardar diez mil turnos de conversación no significa que un agente pueda responder qué ocurrió en una decisión concreta. ¿Por qué se abandonó un parser de streaming? ¿Qué error hizo cambiar el enfoque? ¿Qué solución se descartó y por qué?
Para contestar preguntas así hacen falta varias piezas: indexación, búsqueda, ranking y procedencia verificable. Funes reúne ese proceso en una sola herramienta y aprovecha las sesiones que ya existen en tu máquina.
Su instalación básica es directa:
curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh
funes add claude
También puedes integrarlo con codex, pi o hermes. El comando inicial crea el índice, proporciona herramientas de recuperación al agente e instala la automatización que indexa cada turno completado.
La indexación es incremental. Las nuevas sesiones agregan turnos al índice sin volver a procesar toda la historia, mientras que el contenido antiguo puede incorporarse progresivamente en pasos controlados.
Cómo recupera la información un agente
Cuando una tarea toca una decisión pasada, el agente puede consultar la memoria dentro de la conversación. No necesitas recordar el nombre de la sesión ni copiar manualmente grandes bloques de contexto.
La función recall devuelve el texto original, no una síntesis. Además, muestra el agente que produjo la información, la fecha, la sesión y el turno correspondiente. Cada resultado incluye un comando get para abrir el turno completo junto con su contexto cercano.
Por debajo, funes normaliza las trazas de los agentes en una estructura común de turnos y bloques. Después divide el contenido, genera embeddings con un modelo local fijado y guarda los datos en un conjunto Lance local.
La búsqueda combina varios métodos:
- Búsqueda vectorial, para encontrar ideas relacionadas aunque no usen las mismas palabras.
- BM25, para localizar coincidencias textuales relevantes.
- Fusión de rankings, que combina los resultados de ambas búsquedas.
- Cross-encoder, que vuelve a ordenar los candidatos con una evaluación más precisa.
- Reponderación por recencia, para dar importancia a información reciente.
- Contexto vecino, que incorpora fragmentos cercanos al resultado encontrado.
El resultado busca equilibrar relevancia semántica, coincidencia literal y contexto temporal. No se trata simplemente de buscar una palabra en un archivo de registro.
Una memoria común para varios agentes
Una de las ideas más interesantes es que la memoria no pertenece a un único agente. Claude Code, Codex, pi y Hermes escriben en el mismo formato, por lo que sus historiales pueden consultarse desde una sola memoria.
Puedes iniciar una tarea en Claude Code, continuarla en Codex la semana siguiente y permitir que el segundo agente recupere las decisiones del primero. Incluso puedes alternar entre modelos locales y servicios alojados sin perder el razonamiento acumulado.
Esto ataca un problema cotidiano: el agente que tienes delante suele comportarse como un extraño frente a las decisiones tomadas ayer. Funes intenta que cada nueva sesión conozca el camino recorrido sin cargar toda la conversación anterior en el contexto.
La memoria no reemplaza el razonamiento del agente. Le entrega evidencia para que pueda razonar con una historia que antes estaba escondida.
Memoria local y sincronización con Hugging Face
Funes funciona localmente por defecto. La indexación, los embeddings y el reranking se ejecutan en tu máquina, sin que un modelo alojado procese tus sesiones para construir el índice.
Si quieres llevar la memoria entre equipos, puedes vincularla a un dataset de Hugging Face:
funes add codex acme/funes-memory
La memoria local se almacena como un dataset de Lance y la memoria compartida como un dataset de Hugging Face, privado por defecto. El sistema publica los cambios en los límites de cada sesión y mantiene la indexación local.
En otra máquina puedes ejecutar el mismo comando para recuperar esa memoria. Los archivos del dataset remoto se almacenan en caché localmente, de modo que las consultas posteriores pueden acercarse a la velocidad de una búsqueda local.
La ventaja es que el Hub aporta propiedad, control de acceso, versionado y distribución sin obligarte a utilizar un servicio separado de memoria. Tu historial no se convierte en una cuenta dentro de una plataforma nueva ni en un recurso que luego debas alquilar mediante una API.
Seguridad y evidencia original
Antes de publicar información en el Hub, funes elimina credenciales durante la indexación. Después, analiza nuevamente cada fragmento y retiene cualquier contenido que todavía parezca un secreto.
El proyecto documenta este proceso en SECURITY.md, incluyendo sus límites. Esto es importante: ningún detector de secretos debe interpretarse como una garantía absoluta. La revisión humana sigue siendo necesaria antes de compartir sesiones de trabajo.
La decisión de conservar el texto original también tiene implicaciones prácticas. Funes no convierte cada hallazgo en un dato resumido al momento de guardarlo. Si una respuesta parece dudosa, puedes regresar al turno exacto que produjo la conclusión y revisar el razonamiento completo.
ask permite consultar sin instalar una integración
Si solo quieres hacer una pregunta puntual, puedes usar funes ask:
funes ask claude "what did we decide about the streaming parser"
También puedes consultar una memoria compartida:
funes ask claude "why is funes append-only" --memory huggingface/funes-memory
funes ask es la versión de solo lectura de funes add. Recupera pasajes, se los entrega a un agente de programación y devuelve una respuesta fundamentada que identifica sus fuentes. No instala una integración ni modifica la configuración persistente del agente.
Si la memoria no contiene evidencia suficiente, el sistema no debería inventar una respuesta. El agente puede indicar que no encontró soporte, permitirte reformular la pregunta o sugerir una integración que haga búsquedas iterativas durante el trabajo normal.
Qué cambia para equipos y proyectos abiertos
El valor de esta memoria crece cuando deja de ser individual. En un equipo, un nuevo integrante podría consultar meses de decisiones desde su primer día, incluidos los enfoques descartados y las razones que nunca llegaron a una solicitud de cambios.
En un proyecto de código abierto, los mantenedores podrían publicar la memoria detrás de una versión concreta. Sería algo parecido a un CLAUDE.md que no solo explica cómo funciona el proyecto, sino también por qué terminó funcionando de esa manera.
Las memorias publicadas incluyen una tarjeta de dataset y la etiqueta funes, lo que facilita reconocerlas y descubrirlas en el Hub. La propuesta amplía el uso de los datasets: ya no solo contienen datos o modelos, también pueden conservar decisiones, experimentos fallidos y contexto de desarrollo.
Recall frente a compactación y handoffs
Las sesiones largas terminan siendo costosas. A medida que crecen, cada turno necesita transportar más contexto, hasta que el agente gasta más recursos en recordar que en resolver. Las respuestas habituales son compactar la sesión o escribir un handoff antes de comenzar otra.
Hugging Face comparó esas alternativas con recall en un benchmark de handoff contra recuperación. Las tareas evaluadas requerían conocimiento previo de la sesión y no podían resolverse reconstruyendo el contexto desde cero.
La compactación fue la única de las tres opciones cuyo resultado se dividió: resolvió una tarea, pero no la otra. Cuando falló, el resumen había eliminado hallazgos importantes. Recall, en cambio, recupera los pasajes originales, por lo que una conclusión no necesita sobrevivir a una síntesis.
Según la medición compartida, recall fue la opción más barata en ambas tareas: ocho veces más económica que un handoff escrito en una de ellas y cuatro veces más económica en la otra.
La idea recuerda una frase de Jorge Luis Borges en Funes el memorioso: pensar también implica olvidar diferencias y construir abstracciones. En el caso de los agentes, el reto es elegir qué abstraer sin perder la evidencia que explica una decisión.
Una memoria que puedes inspeccionar y mover
Funes no inventa desde cero todos los componentes de su sistema. Se apoya en modelos abiertos de embeddings capaces de ejecutarse localmente, en los datasets append-only de Lance y en las funciones de caché y deduplicación del Hub.
La aportación está en conectar esas piezas con el flujo real de un agente de programación. El objetivo no es acumular conversaciones por acumularlas, sino permitir que una sesión futura encuentre una decisión, consulte su origen y continúe el trabajo.
Para desarrolladores individuales, esto puede reducir la repetición de investigaciones. Para equipos, puede conservar conocimiento que normalmente desaparece entre sesiones. Y para proyectos abiertos, puede hacer visible la historia técnica que rara vez cabe en la documentación formal.
La herramienta es de código abierto y está disponible en GitHub. Puedes reportar problemas de instalación, errores de recuperación o solicitar compatibilidad con otros agentes. La pregunta ya no es si los agentes generan memoria, sino quién puede consultarla, verificarla y conservar el control sobre ella.
