AWS trasforma Bedrock in una fabbrica di agenti tra GPT-6, Claude e CloudWatch Omni

🤖 Cosa cambia

• GPT-6 Sol, GPT-6 Luna e Claude Opus 5.5 sono disponibili su Amazon Bedrock con profili differenti per costo, capacità e workload agentici.
• CloudWatch Omni unifica osservabilità di applicazioni e agenti AI, usando OpenTelemetry e valutazioni integrate.
• AgentCore e Strands Evals spostano la governance dal semplice monitoraggio dei prompt alla verifica di skill, tool, isolamento e comportamento dell’agente.

AWS sta trasformando Amazon Bedrock da catalogo di foundation model a infrastruttura completa per eseguire, osservare e governare agenti AI in produzione. L’arrivo simultaneo di GPT-6 Sol, GPT-6 Luna e Claude Opus 5.5 allarga la scelta dei modelli, ma le novità più strategiche sono CloudWatch Omni, le valutazioni delle skill attraverso Strands Evals e i nuovi pattern di isolamento multi-tenant di AgentCore. La competizione cloud non riguarda quindi più soltanto quale modello sia disponibile per primo: riguarda chi riesce a trasformare modelli intercambiabili in workflow osservabili, isolati e misurabili senza obbligare l’impresa a ricostruire ogni volta l’intero stack.

GPT-6 Sol e Luna completano la famiglia OpenAI su Bedrock

AWS rende GPT-6 Sol e GPT-6 Luna generalmente disponibili su Amazon Bedrock, affiancandoli a GPT-6 Astra. La distinzione tra i tre modelli è volutamente economica oltre che prestazionale: Astra resta orientato ai task nei quali la qualità massima prevale sul costo, mentre Sol e soprattutto Luna servono workload più frequenti e ripetibili. È un passaggio importante perché Bedrock può ora distribuire la stessa famiglia OpenAI lungo più fasce di costo senza cambiare piattaforma. Un’impresa può riservare Astra alle attività complesse e usare Sol o Luna per classificazione, trasformazioni, agent loop ripetitivi e automazioni ad alto volume. La direzione era già evidente quando GPT-6 Astra era entrato su Bedrock insieme alle nuove capacità di AgentCore e SageMaker. L’aggiunta di Sol e Luna completa il modello operativo: routing della capacità in base al valore del task, non scelta monolitica di un solo modello per tutta l’organizzazione.

Leggi anche: GPT-6 Astra arriva su Amazon Bedrock e AWS industrializza agenti, modelli e inferenza

Claude Opus 5.5 entra nella stessa infrastruttura senza cambiare runtime

Nello stesso ciclo AWS aggiunge Claude Opus 5.5, che Anthropic presenta come il proprio modello Opus più capace per agentic coding, knowledge work e task di lunga durata. Rispetto a Opus 5, il modello dovrebbe completare le attività usando meno token e con un costo medio per task inferiore.

Per AWS il valore non è soltanto offrire un altro modello di frontiera. È dimostrare che OpenAI e Anthropic possono convivere dentro la stessa infrastruttura Bedrock, lasciando a runtime, identità, tool, osservabilità e policy il compito di rendere intercambiabile il motore sottostante. Questo riduce il lock-in sul modello ma contemporaneamente rafforza quello sul piano infrastrutturale. Più i foundation model diventano sostituibili, più il valore si sposta verso gateway, memoria, logging, evaluation, IAM, sandbox e gestione dei tool.

CloudWatch Omni osserva agenti e applicazioni fuori dalla Console AWS

Amazon CloudWatch Omni è il tassello più interessante del ciclo. AWS lo presenta come ambiente dedicato all’osservabilità di applicazioni tradizionali e workload agentici, accessibile tramite un endpoint separato dalla Management Console e integrato direttamente negli strumenti di sviluppo. Omni è costruito su OpenTelemetry. La telemetria già inviata a CloudWatch può essere visualizzata senza riconfigurazioni, mentre workload esterni possono spedire dati verso un endpoint OTLP. L’obiettivo è evitare che agenti, applicazioni, tool call e modelli restino distribuiti tra sistemi di monitoraggio indipendenti.

Per un agente AI, metriche CPU e latency non bastano. Bisogna osservare quale modello è stato invocato, quali tool sono stati scelti, come è stato attraversato il workflow, quali valutazioni sono fallite e quale passaggio ha prodotto un comportamento anomalo. Omni introduce quindi un livello di observability più vicino al reasoning operativo dell’agente che alla semplice salute dell’infrastruttura. AWS estende contemporaneamente Omni alle applicazioni tradizionali, con una seconda esperienza collaborativa che unifica telemetry e troubleshooting in uno spazio condiviso.

Strands Evals controlla se l’agente usa davvero la skill corretta

Un’altra modifica meno spettacolare ma importante riguarda Strands Evals e AgentCore Evaluations. Le skill permettono di fornire agli agenti procedure riutilizzabili per task specifici, ma un output plausibile non dimostra che il sistema abbia selezionato la skill corretta o ne abbia seguito le istruzioni.

AWS introduce quindi valutazioni dedicate alla skill selection e all’instruction following. Il punto è spostare l’evaluation dalla risposta finale al comportamento che l’ha prodotta. È lo stesso cambio di paradigma già necessario nella sicurezza agentica: quando un modello riceve tool, memoria e capacità operative, il perimetro non coincide più con il prompt.

Per sistemi enterprise il controllo diventa essenziale. Un agente che restituisce la risposta corretta utilizzando la procedura sbagliata può comunque avere aggirato policy, consultato dati non autorizzati o prodotto costi inattesi.

Benchling dimostra che il problema vero è isolare il codice generato

Il caso Benchling rende concreta questa infrastruttura. L’azienda esegue oltre 600 sessioni di codice AI al giorno per più di 250 tenant settimanali, utilizzando AgentCore Code Interpreter in VPC mode. Il problema non era soltanto sandboxare Python generato dagli agenti, ma impedire esfiltrazione attraverso DNS, accessi cross-tenant e credenziali troppo ampie. Benchling ha separato l’esecuzione non attendibile in un account AWS dedicato, utilizza credenziali STS per job, Route 53 Resolver DNS Firewall e VPC endpoint policy. Secondo l’azienda, dall’introduzione del sistema non sono stati registrati incidenti né leakage cross-tenant. È precisamente il livello nel quale AgentCore diventa strategico: non più orchestrazione astratta, ma isolamento di codice scritto dinamicamente da un modello che deve accedere soltanto ai dati del tenant corretto.

Continua con:

AWS Agent Registry governa agenti, skill e server MCP in ambiente enterprise

AWS AgentCore, Quick e Codex entrano nello stack enterprise

AWS vuole possedere il livello che resta quando il modello cambia

GPT-6 Sol, Luna e Claude Opus 5.5 attirano l’attenzione perché sono i nomi più visibili. Ma CloudWatch Omni, AgentCore e Strands Evals spiegano meglio la strategia AWS. I modelli cambieranno continuamente e un benchmark vinto oggi può essere perso nel giro di settimane. Runtime, identity, evaluation, observability e sandbox restano invece necessari qualunque modello venga utilizzato. AWS sta quindi costruendo una piattaforma nella quale OpenAI, Anthropic o altri provider possono essere sostituiti senza riscrivere il sistema operativo dell’agente. Il vero asset diventa la fabbrica che esegue il modello, gli assegna strumenti, controlla ciò che fa e misura se lo ha fatto nel modo previsto. È un vantaggio infrastrutturale più resistente del primato di un singolo LLM. Bedrock non deve possedere necessariamente il modello migliore: deve essere il posto nel quale le imprese possano usare quello migliore senza cambiare tutto il resto.