Un agente que arranca de cero en cada llamada no sirve para nada que dure más de un turno de conversación. Si estás construyendo con LangGraph y ya resolviste el patrón ReAct básico (el agente que razona y usa herramientas), el siguiente problema real es que tu agente recuerde lo que pasó ayer y que, en los pasos delicados, se detenga a esperar que un humano apruebe antes de seguir. Eso es lo que resuelven el checkpointing y el human-in-the-loop, y es exactamente lo que armamos en las sesiones 3 y 4 del taller.
Por qué un agente sin memoria se queda corto rápido
LangGraph modela tu agente como un grafo de estados: cada nodo hace algo (llama a una herramienta, pide algo al modelo, decide a dónde ir después) y el estado viaja entre nodos. El problema aparece cuando el proceso no cabe en una sola ejecución -un agente que procesa un reclamo de cliente en varios pasos a lo largo de horas, o que necesita retomar una conversación que el usuario dejó a medias ayer. Sin persistencia, cada ejecución nueva pierde todo el contexto anterior y el agente repite preguntas que ya habías respondido.
Checkpointing: la memoria que sobrevive al reinicio
El checkpointer de LangGraph guarda el estado completo del grafo después de cada paso -no solo el historial de mensajes, también variables intermedias que definiste tú, como qué herramientas ya se usaron o qué validaciones pasaron-. Eso te da dos cosas que un simple historial de chat no da: puedes retomar exactamente donde quedó el agente aunque el proceso que lo ejecuta se haya caído, y puedes "viajar en el tiempo" al estado de un paso anterior para depurar por qué el agente decidió algo que no esperabas.
- ▸Guarda el estado completo del grafo, no solo los mensajes del chat
- ▸Permite retomar una ejecución interrumpida desde el último punto guardado
- ▸Hace posible el human-in-the-loop: sin checkpoint no hay dónde "pausar" al agente
- ▸Sirve para debug: puedes inspeccionar el estado exacto antes de una decisión que salió mal
Human-in-the-loop: dónde sí necesitas que alguien apruebe
Con el checkpoint ya armado, agregar un punto de pausa es poner una interrupción antes del nodo que hace algo irreversible -enviar un correo, mover dinero, cerrar un ticket- y dejar que el grafo espere ahí hasta que una persona lo apruebe o lo corrija. El agente no se cae ni pierde el hilo: se queda pausado en ese checkpoint exacto, y cuando el humano responde, retoma desde ahí con la decisión ya tomada. Esto es lo que hace que un sistema de agentes sea auditable: puedes mostrar exactamente en qué paso intervino una persona y qué decidió.
El error que más veo: meter human-in-the-loop en todos los pasos "por las dudas". Si el agente pausa a cada rato, nadie revisa con atención -la gente empieza a aprobar sin leer. Resérvalo para las 2 o 3 decisiones que de verdad importan en tu flujo.
Multi-agente: cuando un humano no alcanza para revisar todo
La sesión 4 del taller junta memoria, human-in-the-loop y sistemas donde varios agentes trabajan en paralelo sobre el mismo estado compartido -uno de los patrones que más se usa en producción es que un agente revisor (otro LLM, no una persona) filtre lo obvio, y solo lo que ese revisor marca como dudoso llegue al punto de pausa humano. Así el equipo revisa 5 casos al día en vez de 200, y le dedica tiempo real a los que importan.
Un caso concreto: aprobación de reembolsos
Para que quede menos abstracto: imagina un agente que atiende solicitudes de reembolso. Revisa el pedido, consulta el historial del cliente y calcula un monto. Si el monto es menor a cierto límite, el agente mismo lo aprueba y sigue -nodo normal, sin pausa-. Si supera el límite o el historial del cliente tiene alertas previas, el grafo se detiene en un checkpoint y manda el caso a una bandeja para que alguien del equipo lo revise con el contexto completo ya armado por el agente: no desde cero, sino con el análisis hecho y solo la decisión final pendiente. Esa es la diferencia entre automatizar el 100% de un proceso (riesgoso) y automatizar el 90% dejando el 10% que realmente importa en manos de una persona.
Qué más cubre el taller
Son 4 sesiones y 11 horas: fundamentos de LangGraph y tu primer agente, herramientas y enrutamiento condicional, memoria persistente y gestión de estado, y el bloque de human-in-the-loop con sistemas multi-agente que acabamos de ver. Si quieres ir un poco más atrás y reforzar LangChain antes de entrar a los grafos, el curso completo de Creación de Agentes con LangGraph cubre lo mismo con más tiempo de práctica guiada.
Si quieres entender dónde encaja LangGraph frente a otras formas de construir agentes -CrewAI, AutoGen, frameworks propios de cada nube- la página de LangGraph reúne esa comparación. Y si tu meta es una carrera completa en agentes, no solo esta herramienta, la ruta de AI Agentic Engineer agrupa LangGraph con el resto del stack en un solo recorrido.
