Recordar no es gratis
«Que el asistente recuerde al cliente» suena a mejora obvia. Y lo es, hasta que se mira la factura y la calidad de las respuestas tres meses después.
Todo lo que un agente recuerda viaja en el contexto de cada llamada: se paga, ocupa espacio que podría usar información más relevante y, si entró desde fuera, puede ser falso. Recordar todo no es memoria; es acumulación, y degrada el sistema en vez de mejorarlo.
Los tres tipos que importan
| Tipo | Qué guarda | Cuánto dura | Riesgo principal |
|---|---|---|---|
| De sesión | Lo dicho en esta conversación | Hasta que termina | Crece sin control si es larga |
| Duradera | Hechos del usuario entre conversaciones | Meses o años | Se desactualiza y nadie lo nota |
| De trabajo | El plan y los resultados intermedios de la tarea | Lo que dura la tarea | Arrastra errores de pasos previos |
La mayoría de los problemas vienen de tratar los tres como uno solo: meter todo en un historial creciente que se envía completo en cada llamada.
Memoria de sesión: resumir antes de que duela
Una conversación larga no puede arrastrarse entera. Las estrategias, de peor a mejor:
- Enviar todo. Funciona hasta que no. El costo crece de forma cuadrática respecto al número de turnos y la calidad empieza a caer bastante antes del límite técnico de contexto.
- Ventana deslizante: conservar los últimos N turnos. Simple y predecible, pero el agente olvida de golpe lo que se acordó al principio, que suele ser lo importante.
- Resumen progresivo: cada cierto número de turnos, condensar lo anterior en un bloque de hechos y descartar el detalle. Es la opción que mejor equilibra costo y continuidad.
- Resumen con anclas fijas: igual que la anterior, pero manteniendo intactos ciertos datos que nunca deben perderse —el número de pedido, la decisión tomada, el monto acordado—. Es la versión que usamos cuando hay transacciones de por medio.
La opción 4 cuesta poco más que la 3 y evita el fallo más vergonzoso que puede tener un asistente: olvidar a mitad de la conversación el número de pedido sobre el que está hablando.
Memoria duradera: guarda hechos, no transcripciones
Aquí está la decisión de diseño que más impacto tiene. Comparemos qué se puede guardar después de una conversación:
MAL (transcripción)
"Usuario: hola necesito ayuda... Asistente: claro...
Usuario: es que siempre pido factura y me mandan boleta..."
→ 2.400 tokens en cada conversación futura
BIEN (hechos)
cliente.comprobante = factura
cliente.ruc = 20xxxxxxxxx
cliente.contacto_preferido = whatsapp
→ 25 tokens, y se puede verificar y corregir
Guardar hechos estructurados tiene tres ventajas sobre guardar texto: ocupa una fracción, se puede mostrar al usuario para que lo corrija, y se puede actualizar sin ambigüedad. Una transcripción no se actualiza: se acumula, y cuando el cliente cambia de preferencia conviven las dos versiones y el modelo elige.
Toda memoria necesita caducidad
Un hecho guardado hace dos años puede ser falso hoy. La dirección cambió, la persona de contacto se fue, el plan que tenía contratado ya no existe. Un agente que afirma con seguridad un dato caducado hace más daño que uno que pregunta.
La solución no es técnicamente compleja: cada hecho guardado lleva su fecha y su origen. Pasado cierto tiempo según el tipo de dato, deja de usarse como verdad y pasa a usarse como hipótesis —«tengo registrado que prefieres factura, ¿sigue siendo así?»—. Esa única frase convierte un riesgo en una buena experiencia.
La memoria también se envenena
Si lo que el agente guarda proviene de lo que lee —correos, documentos, formularios, páginas—, un tercero puede escribir ahí lo que quiera. Y a diferencia de una inyección de prompts normal, que afecta a una conversación, una memoria envenenada persiste: queda guardada y se reinyecta en todas las conversaciones futuras.
Tres controles que cierran la mayor parte del hueco:
- Valida al escribir, no al leer. Solo campos conocidos, con formatos esperados. Si el esquema admite «preferencia_comprobante: factura|boleta», no hay dónde alojar una instrucción.
- Nunca guardes instrucciones. La memoria almacena hechos sobre el usuario, jamás frases sobre cómo debe comportarse el agente.
- Marca el origen. Un hecho declarado por el usuario autenticado no vale lo mismo que uno deducido de un PDF que alguien adjuntó.
Lo que el usuario debe poder hacer
Si guardas información de una persona entre sesiones, esa persona tiene que poder verla, corregirla y borrarla. No es solo una exigencia de protección de datos: es la forma más barata de mantener la memoria limpia, porque el usuario corrige gratis lo que a ti te costaría detectar.
Y «borrar» tiene que significar borrar: que el dato desaparezca de donde se consulta, no que se marque como inactivo y siga viajando en el contexto.
Cuándo conviene no recordar nada
No todo agente necesita memoria. Si cada interacción es independiente —consultar el estado de un pedido, calcular un monto, responder una duda de horarios—, agregar memoria suma costo, superficie de riesgo y una categoría entera de errores a cambio de nada.
La pregunta antes de implementarla es concreta: ¿qué decisión va a tomar el agente de forma distinta por recordar esto? Si no hay una respuesta clara, no hace falta.
Conclusión
Una memoria bien diseñada guarda pocos hechos, estructurados, fechados, con origen conocido, visibles para el usuario y con caducidad. Una mal diseñada guarda conversaciones enteras, no se actualiza nunca y se convierte a la vez en el renglón que más crece de la factura y en la puerta por la que entran los datos que nadie validó.
La diferencia no está en la tecnología: está en decidir, antes de guardar, para qué sirve recordar. El mismo criterio con el que se elige qué entra en el contexto, tratado en context engineering.