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

## Veille

Analisi di Janakiram MSV (The New Stack, 20 luglio 2026) sulla **convergenza architetturale** delle piattaforme agent enterprise dei tre hyperscaler: in nove mesi, **Amazon Bedrock AgentCore**, **Microsoft Foundry** e **Gemini Enterprise Agent Platform** sono convergenti sugli **stessi sei primitivi** — runtime, memoria, tool gateway, identità, osservabilità, governance — sotto nomi commerciali diversi. Ciò che 18 mesi fa era una collezione frammentata di librerie sta diventando un **livello di piattaforma** a sé stante. La tesi: questa convergenza ripercorre l'**inflessione PaaS 2011-2016**, in cui **Cloud Foundry** ed **Heroku** hanno unificato VM, load balancer, code e secret store attorno a un **contratto applicativo** portabile — salvo che qui **non esiste ancora un contratto equivalente**, e **nessun progetto open source lo ha rivendicato**. Conseguenza: un'impresa non può **spostare un agente da un cloud all'altro** (stato di sessione, tracce e identità finiscono tutti presso un unico fornitore; migrare significa ricostruire tutto). L'autore propone una **mappatura riga per riga** del contratto Cloud Foundry sugli agenti, definisce tre principi di design (impacchettare l'agente come **una singola unità distribuibile**, **collegare** le capacità invece di incorporare i fornitori, integrare il livello **operativo** nell'astrazione), indica ciò che i protocolli aperti (MCP, A2A, OpenTelemetry) lasciano fuori campo — il **ciclo di vita** — e formula tre domande di due diligence: **governance** (fondazione neutrale vs. fornitore), **packaging** (lo stesso artefatto su due cloud senza riscriverlo), **stato** (memoria esportabile). Verdetto: chi finirà per possedere il **control plane degli agenti** definirà *cos'è 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

Piattaforme agent enterprise, convergenza architetturale, portabilità, lock-in, reversibilità, contratto applicativo, 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, identità, osservabilità, governance, control plane degli agenti, PaaS, Cloud Foundry, Heroku, buildpack, Cloud Native Buildpacks, service broker, service binding, Korifi, Kubernetes, Twelve-Factor App, risorsa collegata, MCP, Model Context Protocol, A2A, OpenTelemetry, convenzioni GenAI, immagini OCI, LangGraph, LangSmith, checkpointing, Agentic AI Foundation, Linux Foundation, goose, AGENTS.md, Strands, harness export, due diligence, governance neutrale, packaging, stato esportabile, hyperscaler, potere negoziale, Janakiram MSV

## Authors

Janakiram MSV

## Ton

**Profilo**: pezzo da architetto/analista (thought leadership infrastrutturale) di Janakiram MSV — un practitioner, analista e advisor di startup della Silicon Valley — per The New Stack, indirizzato ai platform team e ai decision-maker infrastrutturali. Registro analitico, strutturato (una tesi, un'analogia storica sostenuta, una tabella di mappatura, tre principi, tre domande di due diligence), alta tecnicità ma didattico, lunghezza media (~1600 parole).

**Stile**: costruisce l'intero argomento su un'**analogia storica** — la traiettoria PaaS 2011-2016 come specchio dell'inflessione degli agenti — e la porta fino in fondo (buildpack che sopravvivono a Cloud Foundry via CNCF/Korifi; Kubernetes che vince il mercato ma eredita i principi). Una postura di analista distaccato: definisce la convergenza "comportamento razionale piuttosto che complotto" (il margine sta nell'integrazione verticale), rifiuta il tifo per i fornitori ("qualunque cosa dica la brochure della piattaforma"). Utilizza **strumenti decisionali riutilizzabili**: una tabella a tre colonne (astrazione PaaS → equivalente agente → dove oggi si rompe la portabilità), tre principi di design nominati, tre domande di due diligence "in termini semplici". Fonti fattuali precise e datate (date di GA, rinomine, appartenenze alla Linux Foundation). Rimanda a un precedente pezzo dello stesso autore sull'Agent Substrate di Google. Una chiusura deliberatamente proiettata al futuro ("Chi finirà per possedere il control plane degli agenti… definisce cos'è un agente"). Nota di trasparenza editoriale TNS: l'azionista Insight Partners investe in OpenAI, Anthropic, Real.

## Pense-betes

- **Idea centrale: tre hyperscaler, un'unica architettura.** In 9 mesi, Amazon, Microsoft e Google sono convergenti sugli **stessi sei primitivi** per gli agenti enterprise — runtime, memoria, tool gateway, identità, osservabilità, governance — sotto marchi diversi. Ciò che 18 mesi fa era una collezione frammentata di librerie sta diventando un **livello di piattaforma** a sé stante.
- **Il divario: nessun contratto, quindi nessuna portabilità.** La convergenza dei *componenti* non produce portabilità. Manca il **contratto** (nel senso PaaS) che renderebbe un agente agnostico rispetto a dove viene eseguito. Oggi, stato di sessione, tracce e identità **finiscono tutti presso un unico fornitore**; spostare l'agente un anno dopo significa **ricostruire tutto**.
- **L'analogia guida: PaaS 2011-2016.** Prima di Cloud Foundry / Heroku, i team assemblavano VM, load balancer, code, secret store e agenti di monitoraggio, ciascuno con la propria API. Il PaaS ha unificato tutto questo attorno a un **contratto applicativo**: "l'app dichiara ciò di cui ha bisogno e resta agnostica rispetto a dove viene eseguita." **Ciò che contava era il contratto, non l'implementazione.**
- **Lezione Cloud Foundry: il contratto sopravvive alla piattaforma.** Cloud Foundry **non** ha vinto il mercato (lo ha vinto Kubernetes), ma i suoi principi sono sopravvissuti: buildpack nati con Heroku (2011) → **Cloud Native Buildpacks** (Pivotal+Heroku, gen. 2018, accettati nella CNCF in ottobre); l'astrazione Cloud Foundry ricostruita su K8s tramite **Korifi**. Le aziende su questa base nel 2016 avevano una portabilità che **la maggior parte dei team di agenti oggi non può permettersi**.
- **Le tre piattaforme, spogliate del marketing.** (1) **AgentCore** (GA ott. 2025): 7 servizi componibili (runtime, gateway, memoria, browser, code interpreter, identità, osservabilità); runtime = finestre di esecuzione isolate di **8 ore**; il gateway collega server **MCP** esistenti; osservabilità esportata via **OpenTelemetry** verso CloudWatch. (2) **Microsoft Foundry** (rinominato da Azure AI Foundry il **1° gennaio 2026**): runtime gestito isolato per sessione, identità **Entra Agent ID**, memoria di sessione/utente/procedurale, tracing OpenTelemetry. (3) **Gemini Enterprise Agent Platform** (il nome Vertex AI abbandonato al Cloud Next 2026): Agent Engine → **Deployments**, più Memory Bank, Sessions, Agent Registry, Policies, Gateways.
- **La convergenza non è un complotto, è il margine.** Le aziende di infrastruttura costruiscono piattaforme **integrate verticalmente** perché "l'integrazione è dove sta il margine." La conseguenza ricade sul **cliente**: identità, telemetria e deployment finiscono presso un unico fornitore → **il livello operativo sotto l'agente è ciò che resiste alla migrazione**.
- **La mappatura del contratto (tabella, riutilizzabile per la due diligence).** 8 righe "astrazione PaaS → equivalente agente → dove si rompe la portabilità": app source → codice+istruzioni+suite di eval (ogni framework ha il proprio formato di pacchetto); buildpack → rilevamento+packaging del framework (nessun contratto di build condiviso tra gli SDK); backing service → modello/memoria/retrieval/tool (fornitori cablati nella logica); service binding → collegamento autenticato (credenziali emesse dal cloud ospitante); router → endpoint MCP/A2A (i protocolli esistono, non il ciclo di vita); log → tracce/chiamate tool/costo/qualità (convenzioni GenAI ancora in sviluppo); release promotion → valutare/versionare/distribuire progressivamente (eval accoppiata a un harness del fornitore); policy → identità/permessi/approvazioni (identità legata alla directory del fornitore).
- **Tre principi di design.** (1) **Impacchettare l'agente come una singola unità distribuibile**: codice, istruzioni, dipendenze dei tool, contratto di memoria, permessi e suite di eval viaggiano **insieme o per niente**. AWS si avvicina con il suo *harness export* (un comando → codice **Strands** che preserva modello, prompt, tool, memoria, container), "l'istinto giusto, rivolto a un unico cloud." (2) **Collegare invece di incorporare** (la lezione **Twelve-Factor**): modelli, memoria, retrieval, browser, gateway = risorse collegate via configurazione. "Un agente che nomina il proprio fornitore di modello nella logica applicativa ha già rinunciato alla portabilità." (3) **Integrare il livello operativo nell'astrazione**: le domande giuste sull'agente riguardano se l'agente ha portato a termine il compito, ha scelto i tool giusti, ha superato la propria autorità, a quale costo, e se la qualità è peggiorata dopo un aggiornamento del modello.
- **Un agente non è un'applicazione web con un modello innestato sopra.** Tre differenze portano tutto il peso: comportamento **probabilistico** (stessi input → chiamate ai tool diverse); autorità **delegata** dall'utente (un bug nei permessi diventa un effetto collaterale reale, non una pagina di errore); le **dipendenze cambiano il comportamento senza un deployment di codice** (un aggiornamento del modello o una descrizione di tool rivista cambia ciò che l'agente decide). La regola Twelve-Factor del "processo stateless" non sopravvive qui: richiede **worker usa e getta** *più* **stato durevole, ispezionabile, portabile**. **LangGraph** lo dimostra in open source (checkpointing a ogni passo, interruzioni umane, ripristino da crash) — ma il suo control plane risiede nel prodotto commerciale **LangSmith**: la frammentazione emerge **all'interno di un unico progetto**.
- **Ciò che i protocolli aperti lasciano fuori campo: il ciclo di vita.** MCP (accesso a tool/dati), A2A (scoperta/comunicazione tra agenti), OpenTelemetry (convenzioni GenAI, la maggior parte degli attributi ancora "in sviluppo"), immagini OCI (una via di fuga per il packaging): **esistono quasi tutti i primitivi**. Ma **una fondazione che governa come gli agenti parlano ai tool non dice nulla su come versionare un agente**, promuoverlo attraverso gli ambienti, o riportarlo indietro quando un eval regredisce. **Protocolli ≠ piattaforma per il ciclo di vita.**
- **Il segnale di concessione dei fornitori.** La **Linux Foundation** ha annunciato l'**Agentic AI Foundation** (dicembre 2025); progetti fondatori: **MCP** (Anthropic), **goose** (Block), **AGENTS.md** (OpenAI); **AWS, Google e Microsoft come membri platinum**; Google ha contribuito **A2A** alla Linux Foundation. Gli hyperscaler **ammettono** che un livello neutrale conta.
- **Tre domande di due diligence (da tenere presenti nella scelta di una piattaforma agent).** (1) **Governance**: il progetto è controllato da una **fondazione neutrale** o dal fornitore che vende la versione gestita? (2) **Packaging**: lo stesso artefatto gira su **due cloud senza riscriverlo**? (3) **Stato**: la memoria risiede **da qualche parte esportabile** dall'impresa? **Oggi nessun progetto aperto risponde a tutte e tre.**
- **La posta in gioco finale: chi possiede il control plane possiede la definizione.** Così come Kubernetes ha definito pod/deployment/service e ha plasmato il pensiero di un intero settore, l'equivalente per gli agenti **non è ancora stabilito**. Chi finirà per possedere il **control plane degli agenti** non possiederà solo il deployment: definirà **cos'è un agente**, quali componenti contiene, cosa un platform team può sostituire. Un progetto neutrale restituirebbe alle imprese il **potere negoziale** che i buildpack e i service broker offrivano un tempo — a vantaggio dei fornitori tanto quanto degli acquirenti.
- **Correlati**: "The Development Environment Is The Next Layer To Collapse" (Greyling) e "Building for trillions of agents" (Levie) sui livelli degli agenti; identità degli agenti (voce Uber Engineering, zero-trust/SPIRE) — lo stesso problema di identità delegata affrontato sul lato infrastrutturale; la famiglia sovranità / reversibilità / **Design to Exit** (voce ZML/LLMD) — la stessa logica del "pagare in anticipo per il livello che rende il fornitore sostituibile", trasposta dal silicio al control plane degli agenti.

## RésuméDe400mots

In nove mesi, Amazon, Microsoft e Google hanno ciascuna lanciato o rinominato una piattaforma agent enterprise, e **tutte e tre sono convergenti sulla stessa architettura**: runtime, memoria, tool gateway, identità, osservabilità e governance compaiono ora in **Bedrock AgentCore**, **Microsoft Foundry** e nella **Gemini Enterprise Agent Platform**, sotto nomi diversi. Ciò che 18 mesi fa era una collezione frammentata di librerie sta diventando un **livello di piattaforma** a sé stante.

Per leggere dove questo porta, Janakiram MSV richiama l'**inflessione PaaS 2011-2016**. Prima, i team assemblavano VM, load balancer, code, secret store e agenti di monitoraggio, ciascuno con la propria API. **Cloud Foundry** ed **Heroku** hanno unificato questi elementi attorno a un **contratto applicativo**: l'applicazione dichiara ciò di cui ha bisogno e resta agnostica rispetto a dove viene eseguita. Ciò che contava era il **contratto, non l'implementazione**. Cloud Foundry non ha vinto il mercato — lo ha vinto Kubernetes — ma i suoi principi sono sopravvissuti (buildpack → Cloud Native Buildpacks/CNCF; l'astrazione Cloud Foundry ricostruita su K8s tramite Korifi). L'ecosistema degli agenti si sta avvicinando alla stessa inflessione **senza un contratto equivalente**, e nessun progetto open source lo ha rivendicato.

Il costo è concreto: stato di sessione, tracce e identità **finiscono tutti presso un unico fornitore**; spostare un agente un anno dopo richiede **ricostruire tutto**. La convergenza non è un complotto ma un comportamento razionale — integrazione verticale, "è lì che sta il margine" — la cui conseguenza ricade sul cliente.

L'autore propone una **mappatura** del contratto Cloud Foundry sugli agenti (app source → codice+eval; buildpack → packaging; backing service → modello/memoria; binding → collegamento autenticato; router → MCP/A2A; log → tracce/costo/qualità; promotion → eval/versioning; policy → identità), quindi tre principi: **impacchettare l'agente come una singola unità distribuibile** (AWS si avvicina con il suo *harness export* verso codice Strands, "l'istinto giusto, rivolto a un unico cloud"), **collegare le capacità invece di incorporare i fornitori** (la lezione Twelve-Factor), **integrare il livello operativo nell'astrazione**. Un agente non è un'applicazione web: comportamento probabilistico, autorità delegata, dipendenze che cambiano comportamento senza un deployment. LangGraph lo dimostra in open source, ma il suo control plane risiede in LangSmith (un prodotto commerciale).

I protocolli aperti (MCP, A2A, OpenTelemetry, OCI) forniscono quasi tutti i primitivi, ma **non il ciclo di vita**: versioning, promotion, rollback. La **Linux Foundation** ha lanciato l'**Agentic AI Foundation** (dic. 2025, progetti fondatori MCP/goose/AGENTS.md, hyperscaler come membri platinum). Restano tre domande di due diligence — **governance, packaging, stato** — a cui nessun progetto aperto risponde. Chi finirà per possedere il **control plane degli agenti** definirà *cos'è 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/it/fiches/janakiram-agent-platform-portability-contract-2026-07-20/