# janakiram-agent-platform-portability-contract-2026-07-20

## Veille

Análisis de Janakiram MSV (The New Stack, 20 de julio de 2026) sobre la **convergencia arquitectónica** de las plataformas de agentes empresariales de los tres hyperscalers: en nueve meses, **Amazon Bedrock AgentCore**, **Microsoft Foundry** y **Gemini Enterprise Agent Platform** han convergido en las **mismas seis primitivas** — runtime, memoria, tool gateway, identidad, observabilidad, gobernanza — bajo nombres de marca distintos. Lo que hace 18 meses era una colección fragmentada de librerías se está convirtiendo en una **capa de plataforma** diferenciada. La tesis: esta convergencia repite la **inflexión PaaS de 2011-2016**, en la que **Cloud Foundry** y **Heroku** unificaron VMs, balanceadores de carga, colas y almacenes de secretos en torno a un **contrato de aplicación** portable — salvo que aquí **todavía no existe un contrato equivalente**, y **ningún proyecto de código abierto lo ha reclamado**. Consecuencia: una empresa no puede **mover un agente de una nube a otra** (el estado de sesión, las trazas y la identidad terminan todos en manos de un único proveedor; migrar implica reconstruirlo todo). El autor propone un **mapeo línea por línea** del contrato de Cloud Foundry sobre los agentes, plantea tres principios de diseño (empaquetar el agente como **una única unidad desplegable**, **adjuntar** capacidades en lugar de incrustar proveedores, integrar la capa **operativa** en la abstracción), señala lo que los protocolos abiertos (MCP, A2A, OpenTelemetry) dejan fuera de alcance — el **ciclo de vida** — y plantea tres preguntas de due diligence: **gobernanza** (fundación neutral frente a proveedor), **empaquetado** (el mismo artefacto en dos nubes sin reescribirlo), **estado** (memoria exportable). Veredicto: quien termine poseyendo el **plano de control del agente** definirá *qué es un agente*.

## Titre Article

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

## Date

2026-07-20

## URL

https://thenewstack.io/agent-platform-portability-contract/

## Keywords

Plataformas de agentes empresariales, convergencia arquitectónica, portabilidad, lock-in, reversibilidad, contrato de aplicación, Amazon Bedrock AgentCore, Microsoft Foundry, Azure AI Foundry, Foundry Agent Service, Entra Agent ID, Gemini Enterprise Agent Platform, Vertex AI, Agent Engine, Memory Bank, Agent Registry, Agent Substrate, runtime, memoria, tool gateway, identidad, observabilidad, gobernanza, plano de control del agente, PaaS, Cloud Foundry, Heroku, buildpacks, Cloud Native Buildpacks, service broker, service binding, Korifi, Kubernetes, Twelve-Factor App, recurso adjunto, MCP, Model Context Protocol, A2A, OpenTelemetry, convenciones GenAI, imágenes OCI, LangGraph, LangSmith, checkpointing, Agentic AI Foundation, Linux Foundation, goose, AGENTS.md, Strands, harness export, due diligence, gobernanza neutral, empaquetado, estado exportable, hyperscalers, poder de negociación, Janakiram MSV

## Authors

Janakiram MSV

## Ton

**Perfil**: pieza de arquitecto/analista (thought leadership de infraestructura) de Janakiram MSV — practicante, analista y asesor de startups de Silicon Valley — para The New Stack, dirigida a equipos de plataforma y responsables de decisión de infraestructura. Registro analítico y estructurado (una tesis, una analogía histórica sostenida, una tabla de mapeo, tres principios, tres preguntas de diligencia), alta tecnicidad pero didáctico, longitud media (~1600 palabras).

**Estilo**: construye todo el argumento sobre una **analogía histórica** — la trayectoria PaaS de 2011-2016 como espejo de la inflexión de los agentes — y la sigue hasta el final (buildpacks que sobreviven a Cloud Foundry vía CNCF/Korifi; Kubernetes ganando el mercado pero heredando los principios). Una postura de analista distanciado: llama a la convergencia "comportamiento racional más que conspiración" (el margen está en la integración vertical), rechaza el porrismo de proveedor ("por más que diga el folleto de la plataforma"). Emplea **herramientas de decisión reutilizables**: una tabla de tres columnas (abstracción PaaS → equivalente en agentes → dónde se rompe hoy la portabilidad), tres principios de diseño nombrados, tres preguntas de due diligence "en términos llanos." Fuentes factuales precisas y fechadas (fechas de GA, renombramientos, membresías de la Linux Foundation). Hace referencia a una pieza anterior propia del autor sobre el Agent Substrate de Google. Una línea de cierre deliberadamente prospectiva ("Quien termine poseyendo el plano de control del agente... define qué es un agente"). Nota de transparencia editorial de TNS: el accionista Insight Partners invierte en OpenAI, Anthropic, Real.

## Pense-betes

- **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.
- **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**.
- **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.**
- **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**.
- **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.
- **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**.
- **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).
- **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.
- **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**.
- **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.**
- **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.
- **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.**
- **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.
- **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.

## RésuméDe400mots

En nueve meses, Amazon, Microsoft y Google han lanzado o renombrado cada uno una plataforma de agentes empresariales, y **los tres han convergido en la misma arquitectura**: runtime, memoria, tool gateway, identidad, observabilidad y gobernanza aparecen ahora en **Bedrock AgentCore**, **Microsoft Foundry** y **Gemini Enterprise Agent Platform**, bajo nombres distintos. Lo que hace 18 meses era una colección fragmentada de librerías se está convirtiendo en una **capa de plataforma** diferenciada.

Para leer hacia dónde lleva esto, Janakiram MSV invoca la **inflexión PaaS de 2011-2016**. Antes, los equipos ensamblaban VMs, balanceadores de carga, colas, almacenes de secretos y agentes de monitorización, cada uno con su propia API. **Cloud Foundry** y **Heroku** unificaron estas piezas 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**. Cloud Foundry no ganó el mercado — lo hizo Kubernetes — pero sus principios sobrevivieron (buildpacks → Cloud Native Buildpacks/CNCF; la abstracción de Cloud Foundry reconstruida sobre K8s vía Korifi). El ecosistema de agentes se acerca a la misma inflexión **sin un contrato equivalente**, y ningún proyecto de código abierto lo ha reclamado.

El coste es concreto: el estado de sesión, las trazas y la identidad **terminan todos en manos de un único proveedor**; mover un agente un año después exige **reconstruirlo todo**. La convergencia no es una conspiración sino un comportamiento racional — integración vertical, "ahí está el margen" — cuya consecuencia recae sobre el cliente.

El autor propone un **mapeo** del contrato de Cloud Foundry sobre los agentes (app source → código+eval; buildpack → empaquetado; backing service → modelo/memoria; binding → conexión autenticada; router → MCP/A2A; logs → trazas/coste/calidad; promotion → eval/versionado; policy → identidad), y luego tres principios: **empaquetar el agente como una única unidad desplegable** (AWS se acerca con su *harness export* hacia código Strands, "el instinto correcto, apuntado a una sola nube"), **adjuntar capacidades en lugar de incrustar proveedores** (la lección de Twelve-Factor), **integrar la capa operativa en la abstracción**. Un agente no es una aplicación web: comportamiento probabilístico, autoridad delegada, dependencias que cambian el comportamiento sin un despliegue. LangGraph lo demuestra en código abierto, pero su plano de control reside en LangSmith (un producto comercial).

Los protocolos abiertos (MCP, A2A, OpenTelemetry, OCI) aportan casi todas las primitivas, pero **no el ciclo de vida**: versionado, promoción, rollback. La **Linux Foundation** lanzó la **Agentic AI Foundation** (dic. 2025, proyectos fundadores MCP/goose/AGENTS.md, hyperscalers como miembros platino). Quedan tres preguntas de due diligence — **gobernanza, empaquetado, estado** — que ningún proyecto abierto responde. Quien termine poseyendo el **plano de control del agente** definirá *qué es un agente*.

## GrapheDeConnaissance

- Amazon Bedrock AgentCore —converge_avec→ Microsoft Foundry (TECHNOLOGIE, 0.95)
- Microsoft Foundry —converge_avec→ Gemini Enterprise Agent Platform (TECHNOLOGIE, 0.95)
- Janakiram MSV —affirme_que→ les trois hyperscalers ont convergé sur les mêmes six primitives d'agent (runtime, mémoire, tool gateway, identité, observabilité, gouvernance) (AFFIRMATION, 0.95)
- Janakiram MSV —affirme_que→ l'écosystème agent manque du contrat de portabilité qu'aucun projet open source n'a revendiqué (AFFIRMATION, 0.92)
- Cloud Foundry —permet→ portabilité applicative via un contrat agnostique du lieu d'exécution (AFFIRMATION, 0.9)
- plateforme d'agents d'entreprise —s_inspire_de→ PaaS (Cloud Foundry, Heroku) (TECHNOLOGIE, 0.88)
- contrat de portabilité agent —réduit→ lock-in vis-à-vis d'un hyperscaler (CONCEPT, 0.85)
- Amazon Bedrock AgentCore —utilise→ Model Context Protocol (TECHNOLOGIE, 0.9)
- Amazon Bedrock AgentCore —utilise→ OpenTelemetry (TECHNOLOGIE, 0.9)
- Microsoft Foundry —utilise→ Entra Agent ID (TECHNOLOGIE, 0.9)
- Microsoft Foundry —est_variante_de→ Azure AI Foundry (TECHNOLOGIE, 0.9)
- Gemini Enterprise Agent Platform —remplace→ Vertex AI (TECHNOLOGIE, 0.88)
- LangGraph —permet→ état d'agent durable, inspectable et portable (checkpointing, reprise après crash) (AFFIRMATION, 0.9)
- LangGraph —fait_partie_de→ LangSmith (TECHNOLOGIE, 0.82)
- Model Context Protocol —fait_partie_de→ Agentic AI Foundation (TECHNOLOGIE, 0.9)
- Linux Foundation —publie→ Agentic AI Foundation (TECHNOLOGIE, 0.92)
- protocoles ouverts (MCP, A2A, OpenTelemetry) —s_oppose_à→ plateforme de cycle de vie agent (CONCEPT, 0.8)
- harness export AWS —permet→ conversion d'un harness configuré en code Strands (modèle, prompt, outils, mémoire préservés) (AFFIRMATION, 0.88)
- Twelve-Factor App —recommande→ traiter les capacités (modèle, mémoire, outils) comme des ressources attachées par configuration (AFFIRMATION, 0.85)
- Janakiram MSV —recommande→ évaluer une plateforme agent sur trois questions : gouvernance neutre, packaging portable, état exportable (AFFIRMATION, 0.9)
- Janakiram MSV —prédit→ celui qui possèdera le control plane agent définira ce qu'est un agent (AFFIRMATION, 0.85)
- Kubernetes —a_créé→ abstractions (pods, deployments, services) façonnant la pensée de l'industrie (AFFIRMATION, 0.85)

---
Canonical: https://www.thekb.eu/es/fiches/janakiram-agent-platform-portability-contract-2026-07-20/