AX – El orquestador agente de Google
El nuevo proyecto AX de Google busca ofrecer un “agentic orchestrator” de código abierto basado en Kubernetes para ejecutar grandes cantidades de agentes de IA en entornos seguros y aislados, con funciones como reanudación rápida de instantáneas y controles estrictos de red y permisos. Los comentaristas están divididos: algunos lo ven como una herramienta seria, de nivel de infraestructura, adecuada para laboratorios de investigación o empresas que necesitan gestionar cargas de trabajo de agentes no confiables y con picos de actividad a escala, mientras que otros lo consideran un “Kubernetes para agentes” sobrediseñado e innecesario para el uso típico de desarrollo. El escepticismo aumenta por el historial mixto de Google a la hora de sostener tanto productos como proyectos de código abierto, por lo que muchos tratan AX como algo experimental y posiblemente de corta vida, pese a su ambición técnica.
Qué es y qué no es AX
- Muchos lectores tuvieron dificultades para entender el propósito de AX a partir de la página de inicio; “orchestrator” resultaba vago.
- Algunos lo aclararon como: un plano de control basado en k8s para ejecutar agentes LLM en sandboxes aislados fuera de la máquina del usuario, con controles de egreso, límites de recursos y suspensión/reanudación rápidas.
- Es de nivel de infraestructura, no un framework de agentes de capa de aplicación como LangChain; se centra más en “dónde y cómo se ejecutan los agentes” que en “cómo piensan”.
Kubernetes, YAML y complejidad
- Críticas fuertes de que AX es “Kubernetes para agentes”: requiere un clúster de k8s, un registro de contenedores, la Agent Substrate API, configuraciones YAML.
- Algunos ven esto como una sobrerreingeniería innecesaria y nada “ergonómica”, a pesar de las afirmaciones de marketing.
- Otros sostienen que en entornos empresariales o en infraestructuras k8s ya existentes es algo natural: primitivas conocidas, un añadido fácil si ya tienes clústeres y alineado con los patrones de infraestructura del sector.
Seguridad, sandboxing y escala
- Reacciones positivas a un fuerte aislamiento: microVM/gVisor, allowlists de egreso de confianza cero, gateway MITM, reanudación rápida de tareas, persistencia del espacio de trabajo.
- Varios señalan que esto responde a necesidades reales para ejecutar código de agentes no confiable, especialmente a escala o en flujos de trabajo sensibles a la seguridad.
- Debate sobre tecnologías microVM y sobre cuánto aislamiento proporcionan realmente distintos enfoques (Firecracker, qemu, smolvm, etc.).
- AX se considera más relevante para cargas de trabajo de agentes grandes y con picos de actividad (evals, RL, entrenamiento) que para pequeños equipos de desarrollo.
Comparación con otros esfuerzos de Google y el ecosistema
- AX se construye sobre Agent Substrate, que se está moviendo a la CNCF; se lo contrasta con otro proyecto de Google, Scion, que envuelve harnesses existentes y algunos ven como más integrador.
- Algunos prefieren Scion u otros orquestadores que ejecutan “cargas de trabajo normales” y harnesses ya existentes en lugar de requerir una nueva pila.
- Muchos comentan que “todo el mundo y su abuela” está construyendo frameworks/sandboxes de agentes; todavía no hay un claro “React de los agentes”.
Confianza en Google y longevidad
- Escepticismo recurrente sobre la longevidad de los productos y del código abierto de Google, citando la historia de “muerte por Google” y herramientas abandonadas rápidamente.
- Otros responden con ejemplos de OSS de Google de larga vida (Kubernetes, Go, Chromium, etc.), pero el sentimiento general es: considerar AX experimental y evitar una dependencia profunda en producción.
Utilidad y exceso
- Algunos ven méritos técnicos sólidos y están entusiasmados por estudiar su diseño.
- Otros argumentan que muy pocos usuarios realmente necesitan “miles de millones de agentes” o una infraestructura tan pesada; para muchos, las VMs simples, los contenedores o las herramientas locales siguen siendo suficientes.