Google ADK aterriza agentes que pausan y reanudan: la arquitectura que falta en muchos demos
Google publicó una guía para construir agentes largos con ADK que sobreviven reinicios, webhooks y pausas de días. La señal útil para builders es separar estado durable, eventos y subagentes antes de hablar de autonomía.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Google publicó una guía práctica para construir agentes de larga duración con Agent Development Kit (ADK). La fecha importa: el post es del 12 de mayo de 2026, pero el tema sigue fresco porque ataca una falla que aparece cada semana en productos agentic nuevos: el demo conversa bien durante cinco minutos, pero se rompe cuando el trabajo real dura días.
La historia no va de un modelo más grande. Va de arquitectura. Google usa un caso de onboarding de empleados para mostrar un agente que envía documentos, espera firmas, delega provisión de IT, vuelve a dormir mientras llega hardware y reanuda sin inventar pasos intermedios.
El error: confundir conversación con estado
Muchos prototipos guardan el historial completo y lo vuelven a mandar al modelo. Eso funciona hasta que el flujo tiene cientos de turnos, respuestas viejas de tools, aprobaciones humanas y días de pausa. Ahí aparecen tres problemas: costos de tokens, contaminación de contexto y alucinaciones sobre cosas que nunca pasaron.
La guía de Google propone otro contrato: el agente no “recuerda” el paso actual desde una conversación larga; lo lee desde una máquina de estados durable. En el ejemplo, los checkpoints son explícitos: START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED y COMPLETED.
Ese detalle es más importante que el framework. Si estás construyendo agentes para finanzas, soporte, ventas, compras o HR, casi siempre necesitas que el sistema sepa en qué fase está sin pedirle al modelo que reconstruya la historia.
Qué cambia para builders
El patrón tiene tres decisiones copiables.
Primero, cada tool avanza el estado de forma atómica. Si send_welcome_packet corre y el contenedor muere después, la sesión ya quedó en WELCOME_SENT. Al reiniciar, el agente no repite el paquete ni salta a IT por intuición.
Segundo, el idle time se maneja con eventos. En vez de dejar un proceso bloqueado o hacer polling, un webhook de firma de documentos despierta la sesión, aplica un state_delta y reanuda la corrida. Eso baja costo y reduce comportamiento fantasma.
Tercero, el agente principal delega trabajo especializado a subagentes. Google separa el coordinador de onboarding del agente de IT. Eso mantiene prompts más estrechos y limita tools por rol, justo lo que suele faltar cuando un “superagente” termina con 40 herramientas y cero criterio.
La parte que sí debes probar antes de producción
La guía insiste en evals de varios días simuladas en segundos. Es correcto. Un flujo largo no se valida esperando dos semanas: se valida sembrando estado, simulando webhooks y verificando que el agente no salte gates.
La prueba mínima para tu equipo debería cubrir:
- reanudación después de reinicio;
- evento duplicado de webhook;
- intento del usuario de saltarse una aprobación;
- delegación a subagente con tool equivocada;
- trazas para medir latencia entre evento externo y reanudación real.
Si tu agente no pasa eso, no está listo para una operación con humanos, aunque el modelo conteste bonito en la demo.
Por qué puede captar tráfico cualificado
La intención de búsqueda es clara: long-running AI agents, ADK pause resume, agent state machine, event driven agents y agentes IA con webhooks. No es tráfico de curiosidad; es gente intentando que un agente sobreviva a procesos reales.
Agente IA puede competir porque la mayoría de cobertura se queda en el tutorial. La lectura práctica para Latinoamérica es otra: si tu automatización depende de WhatsApp, correo, facturas, aprobaciones o sistemas legacy, el problema central no es el prompt. Es diseñar estado durable, eventos y validación humana.
Si todavía estás armando la base antes de llegar a flujos de varios días, empieza por el curso gratis. La conclusión corta: un agente largo no es un chatbot con más contexto; es un proceso durable que usa modelos en los puntos donde hacen falta.