OOM y gestión de memoria
Muchos agentes funcionan en demo y caen en producción porque acumulan resultados de herramientas, respuestas de APIs y conversaciones largas dentro del mismo contexto.
Objetivos de aprendizaje
- Detectar por qué aparece un OOM en agentes y workflows largos.
- Separar contexto, estado persistente, logs y resultados pesados.
- Aplicar límites, colas y alertas antes de que el sistema muera sin explicación.
En cristiano: OOM. Out of Memory: el proceso se queda sin memoria y el sistema operativo o el runtime lo mata.
Causas típicas
- Guardar respuestas completas de herramientas en el estado del agente.
- Meter documentos enteros en contexto en vez de chunks y referencias.
- Reintentos que duplican mensajes, resultados y trazas.
- Workflows de n8n ejecutándose en un único proceso sin workers separados.
- Buffers enormes en vez de streaming o procesamiento por lotes.
Terminal
politica_memoria:
max_tool_result_chars: 6000
guardar_en_contexto:
- resumen
- ids
- citas
guardar_fuera:
- html completo
- pdf extraido
- respuestas api largas
si_supera_limite:
- persistir_blob
- resumir
- enlazar_por_id
- continuar Idea clave. En LangGraph, los checkpointers sirven para persistir estado de hilo; en n8n, queue mode separa ejecución en workers apoyados por Redis y base de datos. Ninguna de las dos cosas sustituye una política de memoria.
Cuidado. Un OOM puede parecer un fallo fantasma: no hay excepción bonita, solo un worker muerto o un exit code. Por eso necesitas límites, logs externos y cola de errores.
Comprueba que funciona. Revisa un agente tuyo y marca qué campos del estado pueden crecer sin límite. Todo campo sin límite necesita truncado, resumen o persistencia externa.
Guardar y reabrir el proyecto.
No guardes “todo por si acaso”. Guarda lo mínimo para decidir, y lo pesado fuera del contexto.