SQLite como fuente de verdad y una capa de memoria aparte: el diseño de un agente de clientes

FUEGO es un agente de memoria para relaciones con clientes. La idea es que, antes de una reunión, el sistema recuerde lo que ha pasado sin obligar a nadie a reconstruir la relación a mano a partir de reuniones, tickets y notas sueltas. Su autor ha explicado el diseño, y la decisión que lo sostiene no está en cómo se guarda la información, sino en dónde se separa: los registros estructurados viven en SQLite, el contexto histórico lo recupera Hindsight y Groq convierte ese contexto en una respuesta.

SQLite no es la memoria

El frontend va en Next.js y el backend en Python con FastAPI. Por debajo, tres piezas con responsabilidades que el autor quiere mantener separadas: SQLite guarda clientes, reuniones y tickets con sus fechas, prioridades, estados y resultados; Hindsight actúa como capa de memoria; Groq genera el texto final.

El argumento es que una fila de base de datos no es lo mismo que un recuerdo, y un recuerdo recuperado no es un hecho que pueda sobrescribir un registro. Cuando se registra una reunión o un ticket, el dato estructurado queda en SQLite y el contexto relevante se envía a la capa de memoria. Cuando alguien pregunta, no se manda el historial entero al modelo: se recuperan los recuerdos relevantes para esa consulta.

Hindsight expone tres operaciones: retener lo que ha pasado, recuperar lo que importa y reflexionar sobre varias memorias a la vez. La tercera responde a preguntas que no salen de un registro concreto, del tipo «qué debería tener en cuenta antes de la próxima reunión».

Un intento fallido también es memoria útil

El diseño distingue entre problema, solución y resultado, y clasifica este último como funcionó, funcionó parcialmente o sin confirmar. «Lo intentamos» no es «lo resolvimos», y esa diferencia cambia lo que conviene sacar en la siguiente conversación. Lo mismo con los compromisos: si en una reunión se promete un plan de mejora de rendimiento, el sistema lo registra y no da por hecho que se cumplió porque después haya habido otra conversación. Prefiere mostrar que algo necesita confirmación antes que fabricar un cierre.

El ejemplo que usa es un cliente de demostración con un ticket sobre lentitud al filtrar en un panel de analítica, resuelto con tablas agregadas y un modelo semántico simplificado, y un segundo ticket sobre monitorización insuficiente en el que se añadieron alertas pero el resultado sigue sin validar. Hay también una distinción entre lo que dice la base de datos («el ticket GGL-302 está abierto») y lo que aporta la memoria («se habló de huecos de monitorización y se intentó ampliar el alertado»).

No hay cifras de rendimiento, ni comparación con otras aproximaciones, ni repositorio que enseñar. La aportación es el reparto de responsabilidades: tratar la memoria como una frontera de recuperación distinta de la base de datos, en vez de pegar todo el historial en un prompt y pedirle al modelo que se aclare. Quien esté montando agentes con contexto de cliente tiene ahí un criterio razonable para decidir qué se guarda, qué se recupera y qué no se da nunca por cierto.