Cómo implementar memoria en agentes antes de herramientas para mejorar la efectividad
Por qué tu agente necesita memoria antes de herramientas
Tiempo estimado de lectura: 4 min
- Memoria antes de herramientas: Sin memoria contextual, las herramientas incrementan errores, coste y riesgo de daño a datos y presupuesto.
- Episódica vs semántica: Episódica = historial reciente; semántica = hechos persistentes indexados por similitud.
- Run loop recomendado: Buscar semántica → recuperar episódica → ensamblar prompt → validar argumentos → ejecutar → persistir resultados.
- Métricas y trazabilidad: Mide validaciones fallidas, reintentos, TTFT, coste por request y porcentaje de intervención humana.
Si tu primer movimiento fue añadir herramientas al agente, lo estás haciendo al revés. Entender por qué tu agente necesita memoria antes de herramientas es la diferencia entre un sistema que actúa y uno que razona. Sin memoria contextual, un agente repite errores, alucina resultados y convierte cada tool en una bomba de relojería para tus datos y tu presupuesto.
Resumen rápido (lectores con prisa)
Qué es: La memoria provee contexto (episódico y semántico) que evita repetir errores y reduce alucinaciones.
Cuándo usarla: Antes de permitir que un agente invoque herramientas en producción o gestione datos persistentes.
Por qué importa: Mejora coherencia, reduce coste y riesgo, y permite recuperación cuando una tool falla.
Cómo funciona (resumen): Buscar en memoria semántica → recuperar historial episódico → ensamblar prompt → validar y ejecutar herramientas → persistir resultados.
Por qué tu agente necesita memoria antes de herramientas
Las herramientas son los actuadores; la memoria es el mapa. Cuando una llamada a una API falla o una transacción SQL choca, el agente sin memoria solo ve el último input. Reintenta lo mismo, consume tokens y, en el peor de los casos, escribe datos corruptos en producción. Con memoria —episódica y semántica— el agente sabe qué intentó, qué falló y cómo adaptar su estrategia sin volver a romper nada.
Aumentar la capacidad de acción sin dotar de historia al agente es ampliar su radio de daño.
Memoria episódica vs semántica: función y uso práctico
Memoria episódica (corto plazo)
- Qué es: historial cronológico de la sesión —mensajes, decisiones del modelo y resultados de herramientas.
- Para qué sirve: coherencia conversacional y rastreo de pasos en flujos multilargo.
- Implementación típica: Redis o caché en memoria con TTL y extracción de los últimos N eventos.
- Estrategias: sliding window (mantén los N mensajes más recientes) y resumen periódico (el modelo genera una síntesis que reemplaza bloques antiguos).
Memoria semántica (largo plazo)
- Qué es: hechos persistentes sobre usuarios, reglas, configuraciones y decisiones previas, indexados por similitud semántica.
- Para qué sirve: recuperar contexto relevante que trasciende sesiones (preferencias, infraestructuras, políticas).
- Implementación típica: bases de datos vectoriales (pgvector sobre PostgreSQL es una opción pragmática: pgvector).
- Patrón habitual: RAG aplicado a la memoria del agente —consulta embeddings antes de ensamblar el prompt.
No son intercambiables: la episódica responde “qué pasó ahora”, la semántica responde “qué deberías saber de antes”.
El run loop correcto (práctico y reproducible)
Antes de permitir que el agente invoque una tool, sigue este flujo:
- Embeddiza el input del usuario y consulta la memoria semántica (top-k).
- Recupera los últimos N eventos de la memoria episódica.
- Ensambla el prompt: instrucciones base + hechos semánticos verificados + resumen episódico + herramientas disponibles.
- Envía al modelo; si decide llamar una tool, valida los argumentos con un esquema antes de ejecutar.
- Persiste la decisión y el resultado en la memoria episódica.
- Si la llamada falla, serializa el error (estructura ZodError o equivalente) y úsalo para autocorrección o para encolar revisión humana.
sem = searchSemanticMemory(userVector)
epi = loadEpisodic(sessionId, N)
context = buildContext(systemPrompt, sem, epi, toolsMeta)
decision = model.decide(context)
if decision.tool → validate → execute → saveEpisodic(result)
Ese orden evita que las herramientas actúen en el vacío.
Por qué no basta con ventanas de contexto gigantes
Modelos con contexto masivo (Gemini, Claude) tienta a inyectar todo el historial en cada petición. En teoría funciona; en producción falla por tres razones:
- Latencia (TTFT): enviar 100k–1M tokens degrada la experiencia.
- Coste: procesar historial enorme en cada request sale caro.
- Precisión: la atención se degrada cuando la información clave está enterrada (lost in the middle). Ver discusión técnica.
La memoria estructurada filtra, prioriza y entrega solo lo relevante; es más eficiente, auditable y económico.
Operacionalidad: métricas y señales que importan
Mide para poder decidir:
- tasa de validación fallida de herramientas (/% llamadas rechazadas por schema),
- reintentos por fallo (media y P95),
- latencia TTFT y costo por request (tokens consumidos),
- porcentaje de decisiones que derivaron en intervención humana.
Registra siempre: prompt construido, fragments recuperados, rawResponse del LLM, result de Zod (.error.flatten()), y la tool invocada. Sin trazabilidad no hay postmortem útil.
Criterio para arquitectos y equipos
Antes de añadir una nueva tool, pregúntate: si esa tool falla, ¿el agente tiene suficiente historia para entender por qué y recuperarse sin crear daño? Si la respuesta es no, diseña memoria. Empieza con episodic + semántic básico (Redis + pgvector), políticas de resumen y validación estricta de inputs. Solo entonces añade más herramientas.
La memoria no es una mejora incremental: es la infraestructura que permite que las herramientas sean seguras, eficaces y escalables. Construir al revés es barato hoy y peligroso mañana. En el siguiente artículo veremos patrones de resumen semántico y cómo integrar autocorrección de argumentos usando errores estructurados (Zod) para convertir fallos en aprendizaje automático.
Para equipos que trabajan con agentes y workflows, una referencia práctica y recursos adicionales están disponibles en Dominicode Labs. Considera esto como continuidad técnica: plantéalo si necesitas plantillas de run loops, patrones de memoria y ejemplos de validación de herramientas.
FAQ
- ¿Qué diferencia práctica hay entre memoria episódica y memoria semántica?
- ¿Por qué validar argumentos antes de ejecutar una herramienta?
- ¿Qué métricas debo priorizar al operar agentes en producción?
- ¿Es suficiente aumentar el contexto del modelo en cada petición?
- ¿Qué hacer cuando una call a la tool falla repetidamente?
- ¿Qué herramientas tecnológicas se recomiendan para empezar?
¿Qué diferencia práctica hay entre memoria episódica y memoria semántica?
La memoria episódica guarda el historial reciente de la sesión (mensajes, decisiones, resultados) y sirve para coherencia conversacional y seguimiento de flujos multilargo. La memoria semántica guarda hechos persistentes indexados por similitud (preferencias, reglas, configuraciones) que se recuperan entre sesiones.
¿Por qué validar argumentos antes de ejecutar una herramienta?
Validar previene ejecuciones incorrectas que consumen tokens, fallan o dañan datos en producción. Es la barrera que evita que inputs malformados o decisiones erróneas se conviertan en efectos adversos.
¿Qué métricas debo priorizar al operar agentes en producción?
Tasa de validación fallida de herramientas, reintentos por fallo (media y P95), latencia TTFT, coste por request (tokens) y porcentaje de decisiones que derivaron en intervención humana. Registra también prompt construido, fragments recuperados y rawResponse del LLM para trazabilidad.
¿Es suficiente aumentar el contexto del modelo en cada petición?
No. En producción esto aumenta latencia y coste, y puede degradar la precisión cuando información clave se pierde en un contexto enorme. La memoria estructurada entrega solo lo relevante de forma priorizada y auditable.
¿Qué hacer cuando una call a la tool falla repetidamente?
Serializa el error (estructura ZodError o equivalente), persiste el fallo en memoria episódica, usa la información para autocorrección y, si es necesario, encola revisión humana. Registra detalles para postmortem.
¿Qué herramientas tecnológicas se recomiendan para empezar?
Empezar con una memoria episódica en Redis y una memoria semántica en una base vectorial práctica como pgvector sobre PostgreSQL. Añade políticas de resumen y validación estricta de inputs antes de expandir herramientas.
