AWS porta gli agenti AI nel ciclo software: AgentCore, Quick e Codex diventano enterprise

🤖 Cosa cambia

• AgentCore entra nel ciclo di sviluppo software con workflow AI-DLC e permette di migrare agenti esistenti verso runtime, memoria e tool gestiti senza riscriverli subito.
• Amazon Quick collega Outlook via Microsoft Graph e formalizza pattern produttivi per automazioni multi-agent con supervisione umana, osservabilità e passaggi deterministici.
• AWS porta Codex dietro LiteLLM e Bedrock, semplifica QuickSight con Cognito e OpenSearch Serverless con PrivateLink; Moovit riduce i costi dati del 33%.

Amazon Web Services sta trasformando l’AI agentica da insieme di servizi sperimentali a piattaforma operativa che attraversa sviluppo software, automazione aziendale, coding, analytics e gestione dei dati. Le nuove architetture pubblicate da AWS mettono Amazon Bedrock AgentCore dentro il ciclo di sviluppo, definiscono un percorso per migrare agenti esistenti senza riscriverli integralmente, collegano Amazon Quick a Microsoft Outlook, portano OpenAI Codex dietro un gateway LiteLLM gestito dal cliente su ECS e semplificano identità e networking per QuickSight e OpenSearch Serverless. Il caso Moovit mostra infine l’altro lato della strategia: modernizzare l’architettura dati scegliendo il motore corretto per ogni workload può ridurre del 33% il costo complessivo delle pipeline.

AgentCore entra nel ciclo di sviluppo e trasforma l’AI in un collaboratore della software factory

Il nuovo modello parte dall’AI-Driven Development Lifecycle, AI-DLC, nel quale l’intelligenza artificiale non interviene soltanto nella generazione del codice ma partecipa alla pianificazione, alla creazione degli artefatti e ai controlli continui. Nella guida tecnica dedicata all’AI-DLC con Amazon Bedrock AgentCore AWS pubblica due implementazioni di riferimento. La prima prende schemi SQL salvati in Amazon S3 e utilizza AgentCore Runtime per produrre automaticamente diagrammi Mermaid ER, lavorando esclusivamente sui metadati dello schema e non sulle righe dei database.

La seconda costruisce un’architettura multi-agent destinata all’analisi del codice inserita nelle pipeline CI/CD, combinando AgentCore Gateway, Memory e strumenti esterni per produrre controlli di sicurezza, verifiche CVE e report di conformità prima della revisione umana. Il passaggio è importante perché porta AgentCore dentro attività che normalmente appartengono alla software factory e non alla semplice chatbot aziendale. L’umano conserva il controllo sulle decisioni critiche, mentre gli agenti assumono attività ripetitive di analisi, pianificazione e produzione degli artefatti. È un’evoluzione coerente con la trasformazione di AgentCore in un livello comune di valutazione e governance per agenti costruiti con framework differenti, dove AWS aveva già separato osservabilità e testing dalla tecnologia utilizzata per costruire il singolo agente.

Leggi anche: AWS Agent Registry governa agenti, skill e server MCP negli ambienti enterprise

Migrare un agente significa togliere all’applicazione runtime, memoria e autenticazione dei tool

AWS affronta anche un problema più concreto: molte aziende possiedono già agenti sviluppati con LangGraph, framework proprietari o modelli esterni e non vogliono ricostruire tutto per adottare un’infrastruttura gestita. Nella procedura di migrazione verso Amazon Bedrock AgentCore viene utilizzato come esempio un agente di customer support esistente che classifica le richieste, consulta strumenti ed esegue escalation.

Il percorso è progressivo. Nel primo stadio il grafo LangGraph rimane sostanzialmente invariato, ma AgentCore Runtime prende in carico l’esecuzione, Gateway gestisce gli strumenti e Memory sposta lo stato conversazionale fuori dal processo applicativo. In una fase successiva il loop può essere ricostruito attraverso Strands Agents e infine affidato maggiormente all’harness di AgentCore. La distinzione è industrialmente rilevante: AWS non propone soltanto un framework per creare nuovi agenti, ma una strategia per sottrarre al team attività come patching del sistema operativo, isolamento delle sessioni, persistenza dello stato e autenticazione verso ogni tool.

La stessa architettura può continuare a utilizzare modelli provenienti da provider differenti, perché persino un agente che chiama direttamente OpenAI o Anthropic può essere portato nel percorso modificando il livello di inferenza. È la stessa direzione già visibile quando AWS ha introdotto policy deterministiche Dogwood per controllare ciò che gli agenti possono realmente fare: il modello rimane importante, ma il vero prodotto enterprise diventa l’infrastruttura che ne governa l’esecuzione.

Amazon Quick porta Outlook dentro agenti e workflow automatici attraverso Microsoft Graph

Sul livello applicativo, Amazon Quick punta direttamente al lavoro quotidiano. La nuova integrazione ufficiale con Microsoft Outlook utilizza Microsoft Graph API e OAuth 2.0 per autorizzare Quick ad accedere alla posta dell’utente. Una volta collegato l’account, i chat agent possono riassumere thread lunghi e preparare risposte utilizzando anche documentazione e knowledge base aziendali; Quick Flows può estrarre action item, creare briefing per le riunioni e instradare richieste verso i team appropriati. AWS mostra inoltre azioni che permettono di controllare la posta, scrivere email e riassumere gli eventi del calendario. Il valore non è semplicemente avere un LLM che legge Outlook: Quick tenta di costruire un livello operativo sopra gli strumenti esistenti, nel quale il contenuto della comunicazione può diventare l’input di processi successivi. Parallelamente, la guida alle automazioni agentiche con Amazon Quick Automate mette però un limite importante all’autonomia. AWS raccomanda di non trasformare ogni passaggio in una decisione probabilistica dell’agente: responsabilità circoscritte, step deterministici, human review, evaluation e osservabilità devono essere combinati per evitare workflow fragili e imprevedibili. Quick Automate viene quindi presentato come coordinatore di team di agenti attraverso API, applicazioni, interfacce e sistemi terzi, ma la qualità del processo resta più importante della quantità di agenti utilizzati.

OpenAI Codex passa attraverso LiteLLM su ECS e Bedrock diventa il livello di inferenza controllato

La nuova architettura più interessante per gli sviluppatori riguarda OpenAI Codex. AWS pubblica una configurazione nella quale Codex utilizza LiteLLM su Amazon ECS per raggiungere un modello OpenAI disponibile attraverso Amazon Bedrock. Il task loop continua a girare sulla workstation dello sviluppatore: Codex legge i file locali ed esegue gli strumenti approvati all’interno delle proprie regole di sandbox.

La richiesta al modello passa però attraverso un gateway LiteLLM controllato dal cliente, distribuito su ECS/Fargate e protetto da Application Load Balancer e AWS WAF. LiteLLM autentica l’utente, verifica modelli e policy di consumo e utilizza il ruolo IAM del task ECS per richiamare Bedrock. Il gateway diventa quindi il punto centrale per routing dei modelli, virtual key, budget, rate limit e telemetria, evitando di distribuire ai developer la master key. AWS mostra per esempio la generazione di chiavi individuali con limiti di budget, token-per-minute e request-per-minute, archiviate in Secrets Manager con cifratura KMS. La configurazione di Codex punta all’endpoint compatibile con Responses API del gateway, mentre l’autenticazione recupera dinamicamente il bearer token senza salvarlo direttamente nel file config.toml. La scelta assume particolare significato dopo le vulnerabilità che hanno già interessato LiteLLM e mostrato il rischio di trasformare un gateway AI in un punto di concentrazione delle credenziali: centralizzare il controllo aumenta governance e visibilità, ma rende altrettanto necessario proteggere quel livello come infrastruttura critica.

QuickSight usa Cognito per incorporare singole visualizzazioni con controllo per utente

La stessa logica di separazione tra applicazione, identità e servizio gestito arriva nell’analytics. AWS mostra come incorporare singole visualizzazioni Amazon QuickSight utilizzando Amazon Cognito invece di incorporare interi dashboard. L’architettura è composta da un frontend React distribuito da CloudFront e S3, AWS WAF sul bordo, Cognito User Pools per l’autenticazione, API Gateway con Cognito Authorizer e una funzione Lambda che genera URL temporanei attraverso GenerateEmbedUrlForRegisteredUser.

Quando un utente Cognito accede per la prima volta, Lambda verifica se esiste già in QuickSight e, in caso contrario, lo registra automaticamente con ruolo READER, il livello minimo sufficiente per l’embedding. Il risultato è un modello nel quale una singola applicazione può inserire grafici, metriche e visual specifiche nella propria interfaccia mantenendo un controllo individuale sull’accesso. Non è soltanto una semplificazione estetica: la business intelligence diventa una capacità componibile dell’applicazione e l’identità dell’utente resta il criterio con cui determinare ciò che può essere visualizzato.

OpenSearch Serverless passa a PrivateLink standard e riduce la complessità delle reti private

Sul livello dati, AWS interviene su uno dei problemi meno visibili ma più onerosi delle architetture enterprise: connettere privatamente OpenSearch Serverless tra VPC, account e reti on-premises. La nuova generazione di Amazon OpenSearch Serverless utilizza endpoint interface AWS PrivateLink standard con private DNS nativo, eliminando in molti scenari la necessità di orchestrare manualmente Route 53 Profiles, private hosted zone, record CNAME e resolver inbound.

AWS descrive nove pattern di connettività, compresi accessi cross-account e cross-Region. Le collection possono essere raggiunte attraverso hostname per singola collection oppure attraverso un endpoint regionale per account, con il nome o l’ID della collection inserito nella richiesta. Per le aziende che utilizzano OpenSearch come livello di ricerca, osservabilità o retrieval per sistemi AI, questa riduzione della complessità non è secondaria: meno componenti DNS e networking personalizzati significano meno configurazioni da mantenere e meno punti nei quali un errore può rendere il dato irraggiungibile o esposto. Il cambiamento prosegue il percorso già descritto con MCP stateless, agenti AWS e nuove architetture OpenSearch destinate a separare maggiormente compute, strumenti e livello dati.

Continua con:

• AWS porta pagamenti negli agenti AI e aggiorna OpenSearch, streaming e Bedrock
• Google, Nvidia e AWS rendono più efficienti e verificabili gli agenti AI

Moovit riduce i costi del 33% e mostra perché lo stack AI dipende ancora dall’architettura dei dati

Il caso Moovit chiude il quadro perché mostra che la modernizzazione non può essere ridotta all’aggiunta di agenti. Nella ricostruzione tecnica pubblicata da AWS, la piattaforma di mobilità ha smesso di utilizzare un unico cluster Amazon Redshift come motore universale e ha distribuito i workload tra Redshift provisioned, Redshift Serverless ed Amazon EMR. Prima della migrazione il team ha eliminato processi non più necessari che consumavano circa il 7% della CPU, quindi ha spostato le aggregazioni pesanti verso Spark.

Il primo proof of concept era inizialmente molto peggiore del sistema precedente: circa quattro ore contro 30-40 minuti. Dopo l’analisi dei piani di esecuzione e la riscrittura delle query, il tempo è sceso a circa 10 minuti. La capacità provisioned di Redshift è stata infine ridotta del 50%, i job principali hanno ottenuto una riduzione del 50% del tempo di esecuzione al p90 e il costo complessivo delle pipeline dati è diminuito del 33%. Moovit ha utilizzato anche Claude Code e Cursor per accelerare la traduzione tra Redshift SQL e Spark SQL, mantenendo però validazione e approvazione finale nelle mani degli ingegneri.

È probabilmente il dettaglio che meglio sintetizza l’intero ciclo AWS: agenti e strumenti AI possono accelerare software, email e migrazioni, ma il risultato dipende ancora da governance, identità, rete, osservabilità e scelta dell’architettura corretta per ciascun workload.