Un agente de triaje con memoria episódica para resolver outages de Postgres más rápido
Un equipo de TI combina FastAPI, Llama-3.3-70b y la librería Hindsight para que los incidentes de producción aprovechen los runbooks de fallos pasados.

Un equipo de ingeniería describe cómo ha construido un agente de respuesta a incidentes que utiliza memoria episódica para reducir el tiempo de resolución de averías en bases de datos PostgreSQL de horas a minutos. El problema central era la falta de contexto histórico: el equipo había resuelto la misma escasez de conexiones en la pool de PostgreSQL tres meses antes, pero no recordaba la solución exacta al despertar para un page a las 3:14 AM.
El sistema se basa en tres componentes principales. La orquestación y la lógica de triaje funcionan sobre FastAPI y Python 3.11, utilizando el modelo Llama-3.3-70b-versatile de Groq para el razonamiento sobre la causa raíz. El estado relacional de los incidentes se gestiona en SQLite mediante SQLAlchemy. La pieza diferencial es la capa de memoria, implementada con Hindsight, una herramienta que permite a los agentes de IA mantener recuerdos a largo plazo divididos en tres tipos: memoria episódica (detalles completos de incidentes pasados), memoria semántica (runbooks de mitigación y post-mortems) y memoria de efectividad (métricas de cuántas veces un runbook específico ha funcionado).
A diferencia de los pipelines RAG tradicionales basados en vectores, que a veces resultan frágiles, este enfoque utiliza Hindsight para consultar incidentes históricos antes de pedirle al LLM una solución. Esto evita que el modelo genere consejos genéricos y potencialmente peligrosos, como aumentar max_connections en una primaria de PostgreSQL sobrecargada, lo que podría provocar OOM kills a nivel de kernel. En su lugar, el agente recupera el incidente similar más reciente, identifica qué microservicio fugaba conexiones o qué despliegue causó el problema, y sugiere el runbook verificado que solucionó la avería sin reiniciar la base de datos.
La implementación incluye una interfaz abstracta MemoryStore que permite al backend intercambiar la memoria principal por una local en caso de degradación de red. Cuando un incidente se marca como resuelto, el agente almacena automáticamente la causa raíz, los pasos de resolución y las notas del post-mortem en la memoria episódica, cerrando el bucle de aprendizaje.
Para los administradores de sistemas y arquitectos que gestionan infraestructuras críticas, la lección no es solo técnica, sino operativa. Este tipo de automatización no reemplaza el on-call, pero elimina la carga cognitiva de recordar soluciones anteriores. Integrar herramientas de memoria persistente en los flujos de observabilidad y respuesta a incidentes puede ser la diferencia entre un arranque en frío y un diagnóstico inmediato cuando la presión de la producción es máxima.


