AWS collega cataloghi e osservabilità per portare gli agenti AI in produzione

🤖 Cosa cambia

• Amazon Quick permette di trovare tabelle in linguaggio naturale e generare dataset e modelli semantici utilizzando i metadati dei cataloghi aziendali.
• Bedrock AgentCore Observability ricostruisce esecuzioni, chiamate agli strumenti, latenza, token e memoria degli agenti distribuiti negli ambienti produttivi.
• Le nuove funzioni riducono la configurazione manuale, ma richiedono soglie operative, consolidamento della memoria e controllo continuo di costi e prestazioni.

AWS affronta due dei principali ostacoli che impediscono agli agenti AI di passare dai prototipi agli ambienti produttivi: l’assenza di un contesto aziendale affidabile e la difficoltà di comprendere perché un agente diventi lento, costoso o instabile. La nuova Agentic Catalog Experience di Amazon Quick utilizza i metadati già presenti in AWS Glue Data Catalog e Databricks Unity Catalog per individuare le tabelle pertinenti, creare dataset e preservare definizioni e relazioni. Amazon Bedrock AgentCore Observability interviene invece dopo il deployment, collegando tracce OpenTelemetry, metriche e log di CloudWatch per misurare latenza, utilizzo degli strumenti, consumo di token e crescita della memoria nelle sessioni prolungate.

Amazon Quick trasforma il catalogo in contesto per gli agenti

La nuova esperienza agentica di Amazon Quick nasce da un problema ricorrente nelle piattaforme di business intelligence alimentate dall’intelligenza artificiale. Le aziende hanno già investito nella classificazione dei propri dati attraverso cataloghi contenenti descrizioni delle tabelle, significato delle colonne, relazioni tra chiavi, glossari, metriche, livelli qualitativi e regole di governance. Quando queste informazioni devono essere utilizzate da un assistente Text-to-SQL o da un sistema di analisi conversazionale, il contesto viene però spesso ricostruito manualmente. Una definizione come “cliente attivo” può indicare un acquisto effettuato negli ultimi trenta giorni in un sistema e negli ultimi novanta in un altro, mentre ricavi lordi e netti possono essere confusi da un modello che vede soltanto nomi tecnici e valori. Quick Agent permette al curatore di descrivere in linguaggio naturale il tipo di analisi necessario e cerca gli asset più pertinenti nell’intero catalogo, considerando descrizioni aziendali, tag, classificazioni Gold, Silver e Bronze, punteggi di qualità, stato delle tabelle e termini del glossario. L’approccio amplia il modello già introdotto con AgentCore Gateway e l’analisi dei dati in linguaggio naturale, spostando l’attenzione dalla semplice connessione agli strumenti alla qualità semantica delle informazioni che guidano le risposte.

Dataset e relazioni vengono generati con una conferma conversazionale

Dopo avere individuato le tabelle, Quick Agent può creare in blocco i Catalog-Generated Datasets e i Topics utilizzati per interrogazioni e dashboard. Il sistema eredita nei dataset descrizioni tecniche e aziendali, nomi visualizzati, tipi di dato, nullabilità, sinonimi e termini del glossario. Nei Topics trasferisce invece le relazioni tra chiavi primarie e chiavi esterne, la cardinalità e la struttura degli schemi a stella o a fiocco di neve. Un modello finanziario composto da tabelle delle transazioni, prestiti, conti, commercianti e dimensioni temporali può così essere riconosciuto e assemblato senza ricreare manualmente ogni join.

I dati non vengono duplicati: Amazon Quick utilizza Direct Query, mentre il catalogo collegato rimane la fonte autorevole. Con AWS Glue, i metadati vengono letti dal Data Catalog e le interrogazioni passano attraverso Amazon Athena verso i dati conservati in Amazon S3. L’integrazione con Databricks Unity Catalog supporta autenticazione OAuth 2.0 o Personal Access Token. La funzione affronta una difficoltà comune anche nelle piattaforme concorrenti, evidenziata dal lavoro con cui Google Cloud ha unificato agenti, dati, identità e controllo dei costi: un agente enterprise diventa realmente utile soltanto quando sa quali dati può utilizzare, come interpretarli e quali relazioni applicare.

L’eredità semantica riduce le risposte plausibili ma sbagliate

La disponibilità di un catalogo non garantisce automaticamente risposte corrette. Amazon Quick opera come consumatore dei metadati e non sostituisce le piattaforme di catalogazione, evitando di creare una seconda fonte di verità destinata a divergere dall’originale. Le informazioni ereditate vengono mostrate come read-only e possono essere aggiornate manualmente attraverso una sincronizzazione. AWS prevede in futuro una sincronizzazione automatica programmata, ma nella fase iniziale il curatore deve richiedere l’aggiornamento quando cambiano definizioni o relazioni a monte.

Se un autore modifica uno dei dataset generati dal catalogo, Quick lo trasforma in un dataset personalizzato e avverte che l’allineamento semantico non sarà più mantenuto. La distinzione riduce il rischio di semantic drift, cioè la progressiva divergenza tra il significato ufficiale di una metrica e quello utilizzato dall’AI. L’agente può inoltre sfruttare i metadati durante il reranking delle fonti e rispettare indicazioni relative al mascheramento delle informazioni personali. La stessa necessità di proteggere contesto, memoria e strumenti ha portato alla creazione della Open Secure AI Alliance per la sicurezza degli agenti. AWS punta invece soprattutto sulla provenienza semantica: una risposta verificabile deve derivare da dataset approvati, join preconfigurati e definizioni aziendali già governate.

AgentCore Observability individua dove un agente perde tempo

La seconda novità riguarda gli agenti che completano correttamente i compiti ma rispondono troppo lentamente. Amazon Bedrock AgentCore Observability, integrato con Amazon CloudWatch, consente di analizzare ogni invocazione attraverso log, metriche e tracce OpenTelemetry. AWS propone di definire un budget prestazionale specifico per il caso d’uso: alcuni secondi possono essere tollerabili in un’elaborazione batch, ma risultano eccessivi per un assistente destinato al servizio clienti. Le interrogazioni di CloudWatch possono isolare richieste oltre i tre secondi e ricostruire la sequenza delle operazioni associate allo stesso RequestId. Le cause più comuni comprendono strumenti esterni lenti, recupero inefficiente della memoria, generazione eccessiva di token e chiamate indipendenti eseguite in sequenza. Tre strumenti con latenze di due, un secondo e mezzo e un secondo producono quattro secondi e mezzo di attesa quando vengono eseguiti uno dopo l’altro, ma possono avvicinarsi ai due secondi attraverso il parallelismo. AWS consiglia inoltre di mantenere il recupero della memoria sotto i 200 millisecondi, usare caching, connection pooling, indici appropriati e timeout per le integrazioni esterne. L’osservabilità completa il percorso avviato con Bedrock AgentCore per la costruzione di agenti aziendali, introducendo strumenti operativi per misurare ciò che accade dopo il deployment.

La memoria incontrollata aumenta token, latenza e costi

Le sessioni prolungate possono accumulare conversazioni, risultati degli strumenti e informazioni personali fino a saturare la finestra contestuale o la memoria disponibile. AgentCore Observability permette di individuare sessioni superiori a un’ora, ordinarle per dimensione e controllare se i processi di estrazione e consolidamento vengono eseguiti regolarmente. Una singola sessione analizzata da AWS aveva raggiunto 15.700 token distribuiti su sei tracce, con un aumento progressivo a ogni invocazione. Il problema non viene necessariamente rilevato dai normali allarmi sugli errori: l’agente continua a funzionare, ma recupera informazioni più lentamente, consuma più risorse e può perdere improvvisamente lo stato quando supera i limiti del modello. AWS raccomanda di separare le memorie in namespace dedicati a preferenze, cronologia e conoscenza del dominio, riassumere le conversazioni meno recenti invece di conservarle integralmente e definire limiti quantitativi. Il parametro eventExpiryDuration permette di mantenere gli eventi grezzi per un periodo compreso tra sette e 365 giorni, mentre le strategie di consolidamento fondono record ripetitivi in rappresentazioni più compatte. La sicurezza della memoria non riguarda soltanto prestazioni e costi: tecniche come la Stealthy Memory Injection possono avvelenare silenziosamente il contesto a lungo termine degli agenti, rendendo indispensabile controllare provenienza, dimensione e trasformazioni dei dati conservati.

CloudWatch porta gli agenti dentro le pratiche CloudOps

AWS suggerisce di trattare gli agenti come qualsiasi altro sistema distribuito in produzione, definendo metriche, soglie, dashboard e procedure di intervento prima che gli utenti segnalino un degrado. Una configurazione di riferimento può generare allarmi quando il tasso di errore supera il 5%, la latenza P95 oltrepassa i tre secondi o il consumo di token per sessione cresce oltre il livello previsto. Le dashboard dovrebbero mostrare invocazioni nelle ultime 24 ore, P50, P95 e P99, sessioni attive, utilizzo degli strumenti, consumo della memoria, distribuzione degli errori e costo per sessione. AgentCore Evaluators può valutare automaticamente il comportamento durante l’esecuzione, mentre AgentCore Insights, ancora in anteprima, aggiunge analisi dei fallimenti, estrazione dell’intento e riepilogo dei percorsi eseguiti. La disponibilità di queste funzioni non elimina la necessità di progettare correttamente l’agente: rende però visibile il punto nel quale una catena perde efficienza o devia dal comportamento previsto. AWS aveva già mostrato quanto l’affidabilità degli agenti dipenda dalla sicurezza delle dipendenze quando AgentCore, Strands e jsii sono stati coinvolti in vulnerabilità corrette insieme ai prodotti Cisco. Con cataloghi semantici e osservabilità, il gruppo prova ora a coprire l’intero ciclo produttivo: dati governati in ingresso, esecuzioni misurabili e memoria controllata durante il funzionamento.