L’infrastruttura cloud ora parla il linguaggio degli agenti
Cloudflare e Amazon Bedrock stanno trasformando l'infrastruttura per agenti AI: runtime specializzati, semantic layer, telemetria e gateway unificati per loop autonomi.
La nuova infrastruttura cloud si specializza per gli agenti, con runtime dedicati, semantic layer governati e telemetria orientata ai loop
Hai presente quella sensazione quando leggi la documentazione di una nuova API e capisci che il terreno sotto i piedi si è già spostato?
È successo con la Billable Usage API di Cloudflare: non è un endpoint di reportistica, è un contratto infrastrutturale per agenti. Allocazione cross-provider, rilevamento di anomalie, agenti FinOps che leggono e agiscono in tempo reale — tutto esposto via API, con la granularità di chi sa che il consumatore non è più un umano davanti a un dashboard, ma un loop autonomo che decide in millisecondi.
La stessa logica la ritrovi in WriteGuard per server MCP: gli agenti operano con i permessi dell’utente umano associato. Non è un dettaglio di sicurezza — è la prova che lo strato autorizzativo si sta spostando dal perimetro applicativo al perimetro agentico. Il token non appartiene più all’app, ma all’entità delegata che agisce per conto di qualcuno.
Il runtime non è più un’app serverless con un wrapper LLM
Prendi Amazon Bedrock AgentCore: è un servizio per costruire, connettere e ottimizzare agenti a scala, con qualsiasi framework o modello. nOps lo ha usato per spedire agenti FinOps il 75% più velocemente, abbandonando un’architettura general-purpose per qualcosa di molto più specifico. Il runtime è un container Docker deployato su AgentCore, con infrastruttura completa — runtime, memoria, guardrail, code, funzioni worker — definita in un singolo stack AWS CDK. Niente Kubernetes, niente Lambda da orchestrare a mano.
L’agente singolo basato su Strands ha accesso diretto ai tool per operazioni canvas, esecuzione query, scoperta datasource e orchestrazione workflow. Non è un’app con un plugin AI: è un agente con superficie operativa nativa.
Il semantic layer è la nuova frontiera del dato
Lo strato dati racconta la stessa storia. nOps usa le Databricks Lakehouse Metric Views come semantic layer analitico governato, con Lakebase — PostgreSQL serverless — per lo stato applicativo durevole: sessioni, canvas, specifiche widget. La separazione è netta: il semantic layer serve l’agente, non il report builder. Le viste metriche non sono pensate per essere sfogliate da un analista, ma per essere interrogate da un loop decisionale che deve sapere cosa significa ogni numero senza ambiguità.
E la telemetria?La configurazione di Codex su Amazon Bedrock documenta OpenTelemetry come opzionale, con exporter separati per log, metriche e tracce. Puoi instradare le metriche attraverso un collector OTel locale verso CloudWatch. L’operazione start-telemetry-enrichment abilita l’arricchimento dei tag delle risorse — non è logging, è metadata injection nel flusso agente. Le metriche OTel su CloudWatch mostrano volume d’uso e comportamento operativo: non dashboard di business intelligence, ma segnali per chi deve capire se l’agente sta funzionando o deragliando.
L’infrastruttura non è più per le app, ma per gli agenti. E gli agenti chiedono contratti, non interfacce.
La prova definitiva arriva da l’unificazione di Workers AI e AI Gateway: un unico control plane dove ogni richiesta viene registrata con payload completi, i conteggi dei token sono tracciati per modello e l’attribuzione dei costi avviene senza configurare dashboard. Non è un gateway API general-purpose con qualche header in più — è un punto di controllo progettato per la semantica agente: payload, token, costo, attribuzione. Le quattro dimensioni che servono a un agente per decidere se chiamare o meno un modello.
Cosa cambia per chi costruisce
Significa che il deployment non è più un problema di container orchestration, ma di definizione di stack agente. Significa che la telemetria opzionale è un segnale architetturale preciso: il vendor sa che stai costruendo loop autonomi, e ti lascia attivare solo ciò che serve al loop, non ciò che serve al dashboard. Significa che il gateway unificato è il nuovo API Gateway, ma con una differenza sostanziale: il Gateway classico pensa in HTTP, questo pensa in token.
Lo stack sta convergendo verso quattro strati: runtime agentico (AgentCore, Workers AI), semantic layer (Metric Views, Lakebase), telemetria opzionale (OTel con enrichment) e gateway unificato. Non è una semplificazione: è una specializzazione. L’infrastruttura general-purpose, quella che serviva a qualsiasi carico di lavoro purché fosse HTTP, sta diventando un’astrazione di livello troppo basso. Gli agenti hanno bisogno di primitive più dense — permessi, token, metriche arricchite, gateway semantici — e i vendor cloud stanno rispondendo non con nuovi servizi generici, ma con stack verticali che sanno già cos’è un agente.
