Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

Puntos clave

1. Idea central: tres hyperscalers, una arquitectura. En 9 meses, Amazon, Microsoft y Google han convergido en las mismas seis primitivas para agentes empresariales — runtime, memoria, tool gateway, identidad, observabilidad, gobernanza — bajo marcas distintas. Lo que hace 18 meses era una colección fragmentada de librerías se está convirtiendo en una capa de plataforma propia.
2. La brecha: sin contrato, no hay portabilidad. La convergencia de componentes no produce portabilidad. Lo que falta es el contrato (en el sentido PaaS) que haría a un agente agnóstico respecto a dónde se ejecuta. Hoy, el estado de sesión, las trazas y la identidad terminan todos en manos de un único proveedor; mover el agente un año después implica reconstruirlo todo.
3. La analogía guía: PaaS 2011-2016. Antes de Cloud Foundry / Heroku, los equipos ensamblaban VMs, balanceadores de carga, colas, almacenes de secretos y agentes de monitorización, cada uno con su propia API. PaaS unificó todo eso en torno a un contrato de aplicación: "la aplicación declara lo que necesita y permanece agnóstica respecto a dónde se ejecuta." Lo que importaba era el contrato, no la implementación.
4. Lección de Cloud Foundry: el contrato sobrevive a la plataforma. Cloud Foundry no ganó el mercado (lo hizo Kubernetes), pero sus principios viajaron: los buildpacks nacidos en Heroku (2011) → Cloud Native Buildpacks (Pivotal+Heroku, enero de 2018, aceptado en la CNCF en octubre); la abstracción de Cloud Foundry reconstruida sobre K8s vía Korifi. Las empresas que se apoyaron en esa base en 2016 tenían una portabilidad que la mayoría de los equipos de agentes no pueden comprar hoy.
5. Las tres plataformas, despojadas de marketing. (1) AgentCore (GA oct. 2025): 7 servicios componibles (runtime, gateway, memoria, navegador, intérprete de código, identidad, observabilidad); runtime = ventanas de ejecución aisladas de 8 horas; el gateway conecta servidores MCP existentes; la observabilidad se exporta vía OpenTelemetry a CloudWatch. (2) Microsoft Foundry (renombrado desde Azure AI Foundry el 1 de enero de 2026): runtime gestionado aislado por sesión, identidad Entra Agent ID, memoria de sesión/usuario/procedimental, trazado con OpenTelemetry. (3) Gemini Enterprise Agent Platform (el nombre Vertex AI se abandonó en Cloud Next 2026): Agent Engine → Deployments, además de Memory Bank, Sessions, Agent Registry, Policies, Gateways.
6. La convergencia no es una conspiración, es el margen. Las empresas de infraestructura construyen plataformas verticalmente integradas porque "la integración es donde está el margen." La consecuencia recae sobre el cliente: la identidad, la telemetría y el despliegue terminan en manos de un único proveedor → la capa operativa bajo el agente es lo que resiste la migración.
7. El mapeo del contrato (tabla, reutilizable para due diligence). 8 filas "abstracción PaaS → equivalente en agentes → dónde se rompe la portabilidad": app source → código+instrucciones+suite de eval (cada framework tiene su propio formato de paquete); buildpack → detección de framework+empaquetado (sin contrato de build compartido entre SDKs); backing service → modelo/memoria/recuperación/herramienta (proveedores incrustados en la lógica); service binding → conexión autenticada (credenciales emitidas por la nube anfitriona); router → endpoint MCP/A2A (los protocolos existen, el ciclo de vida no); logs → trazas/llamadas a herramientas/coste/calidad (las convenciones GenAI aún en desarrollo); release promotion → evaluar/versionar/desplegar progresivamente (eval acoplado a un harness de proveedor); policy → identidad/permisos/aprobaciones (identidad ligada al directorio del proveedor).
8. Tres principios de diseño. (1) Empaquetar el agente como una única unidad desplegable: código, instrucciones, dependencias de herramientas, contrato de memoria, permisos y suite de eval viajan juntos o no viajan. AWS se acerca con su harness export (un comando → código Strands que preserva modelo, prompt, herramientas, memoria, contenedor), "el instinto correcto, apuntado a una sola nube." (2) Adjuntar en lugar de incrustar (la lección de Twelve-Factor): modelos, memoria, recuperación, navegadores, gateways = recursos adjuntados vía configuración. "Un agente que nombra a su proveedor de modelo en su lógica de aplicación ya ha renunciado a la portabilidad." (3) Integrar la capa operativa en la abstracción: las preguntas correctas sobre un agente son si cumplió la tarea, si eligió las herramientas correctas, si excedió su autoridad, a qué coste, y si la calidad se degradó tras una actualización del modelo.
9. Un agente no es una aplicación web con un modelo injertado. Tres diferencias cargan con todo el peso: comportamiento probabilístico (mismas entradas → distintas llamadas a herramientas); autoridad delegada por el usuario (un bug de permisos se convierte en un efecto secundario real, no en una página de error); las dependencias cambian el comportamiento sin un despliegue de código (una actualización del modelo o una descripción de herramienta revisada cambia lo que decide el agente). La regla "stateless process" de Twelve-Factor no sobrevive aquí: exige workers desechables más estado durable, inspeccionable y portable. LangGraph lo demuestra en código abierto (checkpointing en cada paso, interrupciones humanas, recuperación de caídas) — pero su plano de control reside en el producto comercial LangSmith: la fragmentación aparece dentro de un mismo proyecto.
10. Lo que los protocolos abiertos dejan fuera de alcance: el ciclo de vida. MCP (acceso a herramientas/datos), A2A (descubrimiento/comunicación entre agentes), OpenTelemetry (convenciones GenAI, la mayoría de los atributos aún "en desarrollo"), imágenes OCI (una válvula de escape para el empaquetado): casi todas las primitivas existen. Pero una fundación que gobierna cómo hablan los agentes con las herramientas no dice nada sobre cómo versionar un agente, promoverlo entre entornos, o revertirlo cuando un eval se degrada. Protocolos ≠ plataforma de ciclo de vida.
11. La señal de concesión de los proveedores. La Linux Foundation anunció la Agentic AI Foundation (diciembre de 2025); proyectos fundadores: MCP (Anthropic), goose (Block), AGENTS.md (OpenAI); AWS, Google y Microsoft como miembros platino; Google aportó A2A a la Linux Foundation. Los hyperscalers admiten que una capa neutral importa.
12. Tres preguntas de due diligence (a tener en cuenta al elegir una plataforma de agentes). (1) Gobernanza: ¿el proyecto está controlado por una fundación neutral o por el proveedor que vende la versión gestionada? (2) Empaquetado: ¿el mismo artefacto se ejecuta en dos nubes sin reescribirlo? (3) Estado: ¿la memoria reside en algún lugar exportable por la empresa? Ningún proyecto abierto responde hoy a las tres.
13. La apuesta final: quien posea el plano de control posee la definición. Igual que Kubernetes definió pods/deployments/services y moldeó el pensamiento de toda una industria, el equivalente para agentes todavía no está resuelto. Quien termine poseyendo el plano de control del agente no solo poseerá el despliegue: definirá qué es un agente, qué componentes contiene, qué puede reemplazar un equipo de plataforma. Un proyecto neutral devolvería a las empresas el poder de negociación que en su día les dieron los buildpacks y los service brokers — en beneficio tanto de los proveedores como de los compradores.
14. Relacionado. "The Development Environment Is The Next Layer To Collapse" (Greyling) y "Building for trillions of agents" (Levie) sobre las capas de agentes; identidad de agentes (entrada de Uber Engineering, zero-trust/SPIRE) — el mismo problema de identidad delegada tratado del lado de la infra; la familia soberanía / reversibilidad / Design to Exit (entrada ZML/LLMD) — la misma lógica de "pagar por adelantado la capa que hace reemplazable al proveedor," trasladada del silicio al plano de control del agente.