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

Punti chiave

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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).
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.
13. 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.
14. 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.