Un equipo pasó 24 días creyendo que su agente de IA tenía memoria semántica funcional. No la tenía. Y cuando finalmente la arreglaron, descubrieron algo peor: el 88,5% de todo su conocimiento era completamente invisible para el sistema de búsqueda. La solución fue una sola línea de configuración.
El caso de Sene —el agente IA del equipo detrás de Citadel— es uno de esos post-mortems que vale la pena leer no porque sea un fracaso espectacular, sino porque es brutalmente común. Los agentes de IA en producción tienen problemas de memoria silenciosos que nadie detecta hasta que alguien hace la pregunta correcta.
¿Cómo puede tu agente creer que tiene memoria y no tenerla?
El 10 de febrero de 2026, el equipo activó la búsqueda semántica en memoria para Sene. Configuraron el backend de embeddings con OpenAI, agregaron las referencias en el sistema, y siguieron adelante. Todo parecía en orden.
Durante 24 días, el agente aparecía en sus prompts de sistema como si tuviera acceso a memory_search. Las instrucciones internas mencionaban el tool. El agente incluso lo referenciaba en conversaciones. Pero nunca lo usó de verdad, porque el plugin nunca fue cargado.
El problema era de configuración, no de código: faltaban dos líneas en el archivo de config:
plugins.allow: ["memory-core"]— el plugin nunca estaba en la lista de permitidosplugins.slots.memory: "memory-core"— nunca se asignó el slot de memoria- Y como bonus: la URL base de Ollama tenía
/apiduplicado en el path → respuesta 404 silenciosa
Resultado: 24 días de un sistema de memoria que existía en papel pero no en la realidad. El agente tomaba decisiones, respondía consultas, y gestionaba tareas sin poder acceder a nada de lo que “recordaba”.
El fix fue fácil. El descubrimiento real vino después
El 6 de marzo aplicaron tres patches de config, activaron embeddings locales con Ollama (nomic-embed-text), habilitaron búsqueda híbrida, MMR con λ=0.7, y decay de 30 días. Verificaron que funcionaba con una búsqueda real. Milestone logrado.
Al día siguiente, el equipo pidió una auditoría de uso de herramientas en las últimas 24 horas:
- exec: 210 llamadas
- read: 76 llamadas
- edit: 66 llamadas
- write: 12 llamadas
- memory_search: 7 llamadas
- memory_get: 0 llamadas
7 búsquedas en memoria de un total de 376 llamadas a herramientas. El 1,86% del uso total. Un sistema que costó un día entero construir, siendo ignorado casi completamente.
¿Por qué? Porque el agente tenía una tendencia fuerte a usar read —abrir archivos directamente desde paths conocidos— en lugar de buscar semánticamente primero. Es más rápido, más predecible, y cuando sabes exactamente dónde está algo, es la respuesta correcta. Pero esa lógica tiene un costo.
La pregunta que lo cambió todo
Brad —el humano del equipo— hizo una pregunta aparentemente simple: “¿No guardamos las cosas más en playbooks y SOPs que en memory.md?”
Esa pregunta descubrió el verdadero problema. El equipo revisó qué archivos estaban siendo indexados por el sistema de memoria:
- memory/ + MEMORY.md: 6.743 líneas (11,5% del conocimiento total)
- ops/ (playbooks, SOPs, decision ledger): 8.531 líneas — invisible
- docs/ (proyectos, investigación): 43.598 líneas — invisible
Total invisible: 52.129 líneas. El 88,5% de todo el conocimiento del equipo. Los playbooks operativos, los procedimientos estándar, el registro de decisiones, los documentos de investigación —exactamente el contenido más rico y más denso en contexto— completamente fuera del alcance de búsqueda.
El agente buscaba en la biblioteca de cuadernos mientras la biblioteca principal estaba cerrada.
¿Cuál fue la solución? Una línea de config
Esto:
memorySearch.extraPaths: ["ops/", "docs/"]De 64 archivos indexados a 396. De 500 chunks a 3.028. De 11,5% de cobertura al 100%. Todo en minutos.
Más dos ediciones en archivos de boot para reflejar el nuevo comportamiento: que el agente busque primero en memoria —que ahora incluye los playbooks— en lugar de ir directo a archivos. Lección aprendida, configuración actualizada.
Por qué importa
Este caso tiene tres lecciones que van mucho más allá de una config particular:
1. “Configurado” no es lo mismo que “funcionando”. El sistema de memoria de Sene estuvo mal configurado durante 24 días y nadie lo detectó. La herramienta aparecía en el sistema. El agente la mencionaba. Nunca funcionó. Si no verificas que algo opera como esperas —con una llamada real, con un resultado medible— estás asumiendo. Y en agentes de IA, los supuestos rotos son invisibles.
2. El scope de indexación define el scope de inteligencia. Un agente con acceso a su historial de conversaciones pero no a sus playbooks operativos es como un médico que recuerda sus notas pero no puede leer sus propios protocolos. El conocimiento estructurado —los SOPs, las guías, los registros de decisiones— es exactamente lo que más vale indexar. Si no está en el path de búsqueda, no existe para el agente.
3. Los humanos siguen siendo los mejores auditores. El agente detectó que memory_search tenía bajo uso (7 de 376 llamadas). Pero fue Brad quien preguntó si los playbooks estaban en el índice. El agente miraba la frecuencia; el humano miraba la cobertura. Son preguntas distintas, y la segunda era la que importaba. Esto conecta con algo que ya discutimos en la deuda de verificación del código generado por IA: los sistemas de IA pueden optimizar métricas visibles mientras ignoran problemas estructurales que requieren una perspectiva externa.
También resuena con el trabajo sobre arquitecturas de memoria sin bases de datos vectoriales: el problema de qué indexar es tan importante como el problema de cómo indexarlo. Y con el hallazgo de que la dependencia creciente en herramientas de IA puede oscurecer cuándo esas herramientas están fallando silenciosamente.
El problema no resuelto del equipo es quizás el más interesante: no la indexación (eso ya está solucionado), sino el comportamiento. ¿Cómo hacer que un agente busque en memoria semánticamente antes de abrir archivos desde paths conocidos? La indexación fue un fix mecánico. El cambio de comportamiento es un problema de diseño. Tienen una ventana de 14 días para medirlo.
Si estás desplegando agentes en producción, esta es la pregunta que deberías hacerte hoy: ¿qué porcentaje de tu base de conocimiento es invisible para tu agente?
