Google publico el 12 de mayo de 2026 una guia muy practica sobre agentes de larga duracion con ADK. El ejemplo gira alrededor de onboarding de empleados, pero el mensaje importante va mucho mas alla: un agente de produccion no puede depender de un historial de chat infinito.

Esta es una distincion clave para equipos web. Un chatbot responde en minutos. Un workflow real puede durar dias: esperar una firma, confirmar un pago, recibir una respuesta de soporte, revisar un documento o aprobar una accion.

El problema de los agentes sin estado

Muchos ejemplos de agentes funcionan asi: se guarda cada mensaje y se vuelve a enviar todo al modelo. Para una conversacion corta, es aceptable. Para un proceso que dura dias o semanas, se rompe.

Los fallos son previsibles:

• el contexto se llena de informacion antigua;
• el coste en tokens crece sin aportar valor;
• el modelo puede asumir pasos que nunca ocurrieron;
• una caida del contenedor puede dejar el proceso en un estado ambiguo.

Google propone tratar estos flujos como procesos durables, con estado explicito y eventos de reanudacion. Eso se parece mas a backend serio que a una demo de chat.

Estado durable antes que historial infinito

La idea que mas me interesa es la maquina de estados. En lugar de preguntar al modelo “recuerdas por donde ibamos?”, el sistema le dice exactamente en que paso esta.

type OnboardingStep =
  | "START"
  | "WELCOME_SENT"
  | "DOCUMENTS_SIGNED"
  | "IT_PROVISIONED"
  | "HARDWARE_DELIVERED"
  | "COMPLETED";

En Laravel, esto encajaria con una tabla de workflows, jobs en cola y eventos externos. En Astro o una app de contenido, podria aplicarse a revisiones editoriales, generacion de borradores o aprobaciones antes de publicar.

Eventos, webhooks y pausas reales

El punto mas practico de la guia es que un agente no deberia quedarse bloqueado esperando. Si el proceso necesita una firma o confirmacion, debe dormir y reanudarse con un webhook, un evento o una tarea programada.

Esto cambia el diseno:

• el modelo decide menos cosas;
• el sistema guarda mas estado;
• las integraciones externas disparan avances claros;
• cada reanudacion recibe solo el contexto relevante.

Para producto, esto reduce incertidumbre. El agente no “cree” que algo paso: lo sabe porque el estado durable o el evento lo confirma.

Como lo llevaria a una app web

Un ejemplo realista seria un flujo de soporte B2B:

{
  "case_id": "support_1842",
  "current_step": "WAITING_FOR_CUSTOMER_LOGS",
  "last_verified_event": "diagnostic_request_sent",
  "next_allowed_actions": ["summarize_logs", "ask_followup_question"]
}

El agente puede redactar, resumir o proponer. Pero las transiciones importantes siguen viviendo en backend, con logs y reglas.

Takeaway para equipos full stack

La guia de Google ADK confirma una tendencia: los agentes utiles se parecen menos a chats y mas a sistemas distribuidos pequenos. Necesitan estado, eventos, limites y observabilidad.

Para equipos Laravel, PHP, Astro o Vue, la leccion es clara: si un workflow de IA dura mas que una conversacion, disenalo como producto backend desde el principio. La IA puede razonar, pero el sistema debe recordar.