AX de Google: el cuello de botella de los agentes es la espera

Donde de verdad se muere un agente

El agente de producción no suele petar porque el modelo se haya inventado una cifra. Peta porque el pod se reinicia a mitad de un trámite largo, dos escrituras concurrentes corrompen la sesión, o un corte de red deja el workflow a medias y no hay forma limpia de volver a encenderlo. El trabajo invisible es ese: durabilidad, orquestación y la capacidad de retomar exactamente donde se quedó.

Un SRE senior de Broadcom, citado por InfoWorld, lo dijo sin adorno: durabilidad, orquestación y resumability son los blockers reales de los agentes en empresa. LangChain y AutoGen sirven para prototipar. Cuando el bucle corre horas o días, suelen romperse.

Un agente que trabaja no es un servicio que responde y se olvida. Es un actor con estado que pasa más rato parado que pensando: espera al modelo, espera a una herramienta, espera a que un humano firme. Si el runtime no sabe pausar, esa espera se convierte en factura y en punto único de fallo.

El orquestador de microservicios no sabe esperar

Según el proyecto AX en agentexecutor.io, los orquestadores de siempre se diseñaron para dos mundos: microservicios sin estado y batch predecible. Un agente no es ninguno. Mantener sandboxes idle encendidas para no perder el hilo se vuelve prohibitivo, y no hay soporte nativo para suspender y reanudar en menos de un segundo.

La mecánica es tosca. Dejas un contenedor vivo, pagando CPU y memoria, porque el trámite no ha terminado: el modelo tarda, la API externa no contesta, o el responsable está en una reunión. Si el worker se cae, no hay resume: hay que reconstruir. Por eso el prototipo funciona el martes y el flujo de backoffice se pudre el jueves, cuando de verdad hay espera.

Checkpoint, siesta, despertar

AX se presenta como plano de control declarativo abierto para ejecutar agentes. La promesa, otra vez según agentexecutor.io, es concreta: los agentes inactivos se checkpointean, se suspenden y se reactivan en menos de un segundo, sin cold-start. Decenas de tareas comparten recursos del mismo worker (multiplexado denso) en lugar de una máquina encendida por cada espera.

El truco no está en el LLM. Está en tratar la pausa como operación de runtime. Guardas el estado, apagas el actor, lo despiertas cuando llega el evento. Quien haya llevado un bar lo entiende: no dejas un camarero congelado delante de cada mesa que espera cocina; un mismo camarero cubre muchas mesas paradas. Eso es el multiplexado denso, dicho en serio.

El origen que cuenta el sitio es interno de Google: investigación de runtimes agénticos, incluida la de Google DeepMind según esa misma página, más experiencia en aislamiento, resumición y scheduling a escala. Debajo corre Agent Substrate, un runtime de cómputo diseñado desde cero para densidad masiva y ciclos de vida rápidos de actores con estado. AX depende fuerte de Substrate y pone encima las abstracciones agénticas y los componentes generativos.

Separar el plano de control (qué debe ocurrir, declarado) del plano que duerme y despierta al actor no es un detalle para la foto. Quien haya intentado reconstruir un agente a partir del historial de mensajes ya sabe por qué: el hilo no es el log. Google ha empujado en paralelo la idea de estado estructurado en vez de contexto acumulado; AX lleva esa intuición al ciclo de vida, no solo al prompt.

InfoWorld describe el runtime de Google como un cruce de modelos de despliegue: permite mezclar Google Antigravity, agentes frontier de Google, agentes propios gestionados por Google y agentes custom que usen el protocolo Agent2Agent (A2A). La pieza útil no es el catálogo. Es que el mismo sitio donde duerme un agente de Google tenga que poder dormir el tuyo. A2A es el enchufe entre agentes; el problema de fondo sigue siendo no perder el estado cuando la conversación se alarga un turno humano de verdad.

Lo que nadie ha medido todavía

Hasta aquí el diagnóstico de Broadcom y la arquitectura que vende AX coinciden: el prototipo se rompe cuando el tiempo deja de ser un rato. La cura es otra conversación. Toda esa tesis se apoya en una promesa de infraestructura sin benchmark independiente en las fuentes consultadas. El resume en menos de un segundo es claim de diseño de AX, no un número que alguien haya reproducido por fuera.

Wavect trata la escala masiva, incluida la ambición de billones de tareas por clúster que circula como eslogan de arquitectura, como ambición de diseño, no como medición. No consta en las fuentes consultadas ningún test de terceros que lo verifique. Repetirlo como hecho sería recitar el folleto.

Agent Substrate se declara early-stage, sin soporte oficial. Estar en github.com/google/ax no convierte el runtime en producto respaldado por Google ni por DeepMind. Las fuentes consultadas no recogen un grado de respaldo corporativo más allá de ese repositorio.

Tampoco consta aclarada, en lo consultado, la relación exacta entre AX (el nombre del repo) y el Agent Executor del que habla InfoWorld. Pueden ser la misma pieza con dos etiquetas. Tratarlos como sinónimos cerrados hincha lo que hay. Las capacidades que describe InfoWorld son de mayo de 2026; el proyecto avisa de breaking changes. No hay versión estable que citar, y lo que corría entonces puede no ser lo que corre ahora.

Un agente de horas no se diseña como un microservicio sin estado. La pausa tiene que ser una operación, no un accidente.

Que la orquestación sea el cuello de botella es una apuesta de ingeniería seria, no un hecho de mercado. El SRE nombra el dolor; AX nombra el primitivo. Coinciden en que LangChain no es un runtime de producción. Si el checkpoint barato se sostiene, dejas de pagar una sandbox encendida por cada aprobación humana. Si no, tienes otro orquestador joven con un sitio convincente. El estado vive fuera del proceso que se puede morir. El resto es folleto hasta que alguien mida el despertar.

Preguntas frecuentes

¿Qué es AX de Google?

AX es el orquestador agéntico abierto que Google publica como plano de control declarativo para ejecutar agentes. Según agentexecutor.io, checkpointea, suspende y reactiva agentes inactivos en menos de un segundo sobre Agent Substrate, con decenas de tareas compartiendo el mismo worker. En las fuentes consultadas no consta que sea un producto con soporte oficial de Google.

¿Por qué LangChain o AutoGen no bastan para agentes en producción?

Un SRE senior de Broadcom, citado por InfoWorld, sostiene que durabilidad, orquestación y resumability son los blockers reales en empresa. LangChain y AutoGen sirven para prototipar, pero suelen romperse cuando el agente corre horas o días. El fallo típico no es el razonamiento del modelo: es no recuperar el estado tras un corte, un reinicio o una espera larga.

¿AX y Agent Executor son el mismo producto?

No consta aclarada, en las fuentes consultadas, la relación exacta entre el repositorio AX (github.com/google/ax) y el Agent Executor del que habla InfoWorld en mayo de 2026. Pueden ser la misma pieza con dos nombres. Tratarlos como equivalentes cerrados sería afirmar más de lo que hay en lo publicado que se ha podido verificar.

¿Está demostrado el resume sub-segundo de AX?

No. Es una promesa de diseño del propio proyecto, sin benchmark independiente en las fuentes consultadas. Wavect trata las cifras de escala masiva como ambición de arquitectura, no como medición. Agent Substrate, el runtime sobre el que corre AX, se declara early-stage y sin soporte oficial.