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*.
#Plataformas de agentes empresariales#convergencia arquitectónica#portabilidad
**Informe periódico de Mozilla**, *The state of open source AI*, **v1.0.1, julio de 2026**, presentado mediante una carta de **Raffi Krikorian** (CTO): siete secciones, un sitio interactivo y un informe descargable. Tesis enunciada en el título de la Sección 1: *« La capa del modelo se ha convertido en una commodity. El valor se acumula en el harness que se sitúa por encima. »* **Estado de las capacidades**: en el *Artificial Analysis Intelligence Index v4.1*, el mejor modelo cerrado obtiene **61** puntos (Claude Opus 5) y el mejor modelo abierto **57** (**Kimi K3**), cuarto en el ranking general y por delante de tres de los mayores laboratorios cerrados; en el *Epoch Capabilities Index*, la brecha es de **6 puntos** (K3 en 156 frente a GPT-5.6 Sol en 162), descrita como *« más o menos un ciclo de lanzamiento »*, con intervalos de confianza que se solapan. **Frontera en diente de sierra**: el open lidera en código frontend (K3 con 1.679 Elo en LMArena Frontend Code Arena, seis dominios de siete), disputa el trabajo agéntico en terminal (88,3 frente a 88,8 en Terminal-Bench 2.1) y cede terreno en trabajo profesional de conocimiento (Fable 5 supera a K3 por 92 Elo en GDPval-AA v2). **Cambio de uso**: la cuota de tokens de OpenRouter dirigida a modelos de pesos abiertos pasó de un nivel insignificante a un tercio a finales de 2025, y luego a una **mayoría a mediados de 2026**, con los siete modelos de mayor volumen todos de pesos abiertos —el propio informe señala que *« por número de solicitudes, los proveedores cerrados estadounidenses siguen liderando »*, siendo el liderazgo del open un liderazgo en volumen de tokens concentrado en cargas de trabajo de código y agénticas. **El contraste central**: *« El open es fácil de lanzar. El open es difícil de desplegar. »* —el 79% de los desarrolladores que añaden IA usan modelos abiertos frente al 71% para los cerrados, pero solo el **53%** de los equipos que usan modelos abiertos llega a producción **frente al 63%**, y la brecha se amplía con el tamaño de la organización (cerrado 54% → 73%, abierto 53% → 57%), lo que *« descarta una explicación por recursos »*. El mapa de madurez del stack (48 componentes, 9 capas) muestra dos columnas sistemáticamente frías —**estandarización** y ***preparación empresarial***— identificadas como la brecha operativa. **Sección 5**: *« El harness agéntico es otro agente de usuario »*, y *« El modelo se está comiendo al harness »* —en todos los modelos donde ambos coexisten, el harness propio del laboratorio gana ahora, y la brecha de 21,8 puntos se ha comprimido a unos 3. De ahí la fórmula: *« Un harness ajustado con precisión a los pesos de un laboratorio… se degrada con el modelo de cualquier otro, así que cuanto más ajustado está, menos intercambiables son los pesos que hay debajo. El lock-in llega como efecto secundario de la optimización. »*
#Mozilla#state of open source AI#pesos abiertos
**Mozilla** — éditeur du rapport · avec une introduction signée **Raffi Krikorian** · *Chief Technology Officer*. Publié en **juillet 2026** (v1.0.1). Données issues de sources tierces créditées (Artificial Analysis, Epoch AI, OpenRouter, LMArena) et d'une enquête propre menée avec **SlashData** (*Mozilla / SlashData 2026 developer survey*, n = 1 410 sur la question des freins).
Whitepaper de Google (la entrega "Day 1" de una serie, de Addy Osmani, Shubham Saboo y Sokratis Kartakis) que traza la transformación del ciclo de vida del desarrollo de software (SDLC) en la era de los agentes de codificación. Tesis: el cambio fundamental no es un nuevo lenguaje, sino el paso de escribir código a **expresar intención**. El documento plantea un espectro que va del *vibe coding* (proponer y aceptar) a la *agentic engineering* (la IA implementa bajo restricciones, pruebas y bucles de retroalimentación diseñados por humanos), con la **context engineering** como habilidad central, el modelo de **software factory** (el entregable del desarrollador = el sistema que produce el código), la **harness engineering** (Agente = Modelo + Harness), y un análisis económico CapEx/OpEx del coste total de propiedad.