MemoryOps: memoria persistente para que el agente de guardia no se invente el incidente
Un proyecto de respuesta a incidentes separa la evidencia histórica recuperada de la memoria del razonamiento del modelo, con tres estados de memoria explícitos y sin respuestas de relleno.
MemoryOps es una plataforma de respuesta a incidentes para equipos de DevOps y SRE que guarda lo aprendido en cada avería resuelta y lo recupera cuando vuelve a romperse algo parecido. Por dentro lleva FastAPI con SQLAlchemy sobre SQLite como registro de los incidentes vivos, React 19 y Vite en la interfaz, Hindsight como capa de memoria persistente y un modelo servido por Groq Cloud (openai/gpt-oss-20b) como motor de razonamiento. El autor lo plantea desde un caso concreto: en mitad de una caída, una cita inventada por el modelo es peor que un "no tengo datos", porque una cita parece evidencia verificada y te obliga a gastar minutos comprobándola o a aplicar un arreglo que nadie probó.
RETAIN solo cuando alguien resuelve
El ciclo de memoria tiene tres operaciones. RETAIN no dispara al crear el incidente ni durante la investigación ni con las suposiciones del modelo: solo cuando un ingeniero lo marca como resuelto. En ese momento se almacena un documento de experiencia con identificador, servicio, error, síntomas, severidad, causa raíz, pasos de resolución y post-mortem. El document_id se fija al identificador del incidente (INC-101, por ejemplo) para que la retención sea idempotente, y el modelo de datos lleva un booleano memory_retained que solo pasa a verdadero cuando la memoria confirma que ha guardado.
RECALL corre al lanzar la investigación: se construye una consulta semántica con servicio, error y síntomas del incidente en curso, se piden como máximo 2048 tokens de recuerdos y esas memorias se inyectan como contexto en el prompt. REFLECT, expuesto como endpoint y en la pestaña Memory Explorer, sirve para buscar patrones entre averías distintas.
Evidencia por un lado, análisis por otro
La respuesta de la API de investigación no mezcla las dos cosas. Los incidentes históricos similares vienen directamente de la memoria recuperada y el análisis del modelo va en un campo aparte, en JSON estructurado. La interfaz los pinta como etapas distintas del pipeline para que el ingeniero pueda juzgar la evidencia sin contaminarse con la recomendación.
El detalle más útil es cómo trata los fallos. La API expone tres estados de memoria: correcta, vacía (se buscó y no había nada parecido) y no disponible (el servicio de memoria estaba caído o sin configurar). Si la memoria no responde, el sistema no consulta las tablas de SQLite y presenta esos registros como si fueran recuerdos vectoriales. Los registros locales siguen siendo el registro oficial de lo que pasa, y no se disfrazan de otra cosa.
El propio autor avisa de que su ejemplo de alucinación, el incidente INC-214, es hipotético: los datos de siembra del repositorio van de INC-101 a INC-116, así que citar cualquier número por encima de ese rango es invención del modelo. Nada ejecuta acciones por su cuenta; el ingeniero decide.
Lo aprovechable aquí no es el producto, que es un proyecto personal sin números de uso ni enlace público al código en la nota, sino el patrón: recuperar experiencia estructurada en vez de volcar flujos de logs al prompt, y separar siempre lo recuperado de lo generado. La calidad de todo esto depende de una cosa que no se automatiza, el post-mortem que alguien escriba al cerrar el incidente. Si esa parte es pobre, la memoria persistente solo sirve para repetir errores con más confianza.
