Le ha pasado a casi todo el que construye agentes en producción: el agente lleva doce pasos resolviendo una tarea, llama a una API que responde lento, hay timeout, y todo ese trabajo se pierde. Vuelve a empezar desde cero. LangGraph 1.2.18, publicado el 26 de octubre, le mete mano justo a ese problema: podas de checkpoints en PostgreSQL y un manejo de reanudación (resume) más prolijo, además de ajustes en el SDK y el CLI.
Qué es el checkpointing y por qué tu agente lo necesita
En LangGraph, cada vez que un nodo del grafo termina de ejecutarse, el framework puede guardar una foto completa del estado: qué mensajes se intercambiaron, qué herramientas se llamaron, en qué paso va la tarea. Eso es un checkpoint. Sin esa foto, un corte de red o un modelo que tarda demasiado en responder te hace perder el estado completo del agente. Con checkpoints, el agente retoma desde el último nodo que sí terminó bien, no desde el inicio.
En memoria esto es gratis y automático, pero en memoria también desaparece si reinicias el proceso. Para algo que sobreviva un deploy o un crash real, el patrón que ya se volvió estándar es usar AsyncPostgresSaver: le pasas tu cadena de conexión y el grafo queda con persistencia automática, reanudación tras fallo y hasta la posibilidad de viajar en el tiempo a un paso anterior para depurar qué salió mal.
Qué trajo exactamente la versión 1.2
- ▸Poda de checkpoints en PostgreSQL: ya no tienes que escribir tu propio job para limpiar checkpoints viejos, el paquete lo soporta de forma más directa.
- ▸Mejor manejo de la reanudación (resume behavior) y de las tareas pendientes cuando el grafo se interrumpe a medio camino.
- ▸LangGraph SDK 0.4.8: errores de thread-stream más claros y deja de reintentar streams que el servidor ya rechazó (antes se quedaba insistiendo sin sentido).
- ▸LangGraph CLI 0.4.36: arregla los alias de deployment y obliga a que los comandos de deploy usen el contexto activo de Docker, no uno viejo por accidente.
Lo que esto significa para un agente real en producción
Si tu agente corre pocas veces al día, el checkpointing es casi un detalle. El problema aparece cuando tienes una flota de agentes corriendo todo el día: cada paso del grafo escribe un checkpoint, y eso significa muchas escrituras pequeñas y constantes a la base de datos. Ahí es donde conviene poner un pool de conexiones y, si escalas horizontalmente, algo como PgBouncer en modo transacción o RDS Proxy delante de Postgres. Sin eso, vas a ver timeouts de conexión justo en el peor momento: cuando más tráfico tienes.
Lo que nadie te dice en los tutoriales es que los checkpoints se acumulan rápido y ocupan espacio en serio. La poda automática de la 1.2 ayuda, pero si tu caso tiene requisitos de auditoría, no puedes simplemente borrar todo lo viejo: primero copia lo que un auditor podría necesitar —por ejemplo, el detalle de una aprobación humana dentro del flujo— a un log aparte, y recién después podas el resto.
Un agente sin checkpointing no es un agente en producción, es una demo que todavía no falló.
Dónde aprender esto de punta a punta
El curso Creación de Agentes con LangGraph cubre esto con proyectos reales: grafos con estado, checkpointing con Postgres y cómo depurar un agente que falló a medio camino. Si tu meta es más amplia —diseñar y operar sistemas de agentes completos, no solo un flujo suelto—, la ruta AI Agentic Engineer arma el resto del camino: arquitectura, memoria, RAG agéntico y despliegue.
También tenemos una comparación completa de LangGraph frente a otros frameworks en nuestra página de LangGraph, y si lo que buscas es llevar esto a tu equipo de trabajo, revisa LangGraph para empresas.
Si quieres ir armando esto paso a paso con otras personas que están construyendo agentes al mismo tiempo que tú, cada semana hacemos un taller en vivo en la Comunidad AI Builders, desde 19 USD al mes — es un buen punto intermedio antes de meterte a un curso completo.
La próxima vez que tu agente se caiga a mitad de una tarea larga, antes de pensar en reintentar todo desde cero, revisa si tu checkpointer está bien configurado. Casi siempre el problema no es el modelo, es la infraestructura que lo rodea.
