Le valutazioni di Amazon AgentCore affrontano i fallimenti che il monitoraggio tradizionale non rileva
Amazon ha pubblicato un framework in nove fasi per le valutazioni di Amazon AgentCore dopo aver constatato che un'infrastruttura apparentemente sana può nascondere il deterioramento delle risposte degli agenti. La latenza può restare normale. I tassi di errore possono rimanere stabili. L'agente continua a rispondere, ma la sua risposta sicura di sé potrebbe citare una cifra o un cliente sbagliati.
Questo conflitto è importante perché il monitoraggio tradizionale rileva soprattutto i guasti software che lasciano evidenze tecniche visibili. Gli agenti autonomi introducono fallimenti semantici: l'applicazione funziona, mentre il suo ragionamento, le scelte degli strumenti o le conclusioni diventano meno affidabili.
AWS ha costruito il framework attorno a un sistema multi-agente interno utilizzato da venditori e responsabili commerciali. Agenti specializzati rispondono a domande su prestazioni, clienti e dati strutturati attraverso un'esperienza conversazionale condivisa. Uno strumento o sotto-agente degradato può contaminare la risposta finale senza causare il crash dell'applicazione.
Il framework rappresenta un passaggio dalla valutazione di un agente prima del lancio alla valutazione continua del suo comportamento. Collega esperimenti di sviluppo, gate di distribuzione, canary in produzione, controlli avversariali, rilevamento della deriva, osservabilità e raccomandazioni automatizzate.
Il vero avversario non è un altro provider cloud. È la familiare supposizione che uptime, latenza e richieste completate con successo forniscano prove sufficienti dello stato di salute di un agente. Il caso di Amazon sostiene che questi segnali descrivono la disponibilità, non la correttezza.
Le valutazioni di Amazon AgentCore trasformano la qualità in una condizione di rilascio
Il cambiamento significativo è che AWS tratta la qualità delle risposte come un controllo operativo, non come un'attività di test finale.
AWS ha pubblicato il framework il 16 ottobre 2026, basandosi sul proprio lavoro con un sistema interno in produzione. Il sistema include gli agenti Performance Insights, Customer Insights e Data Insights, al servizio di diverse domande aziendali.
Il Performance Insights Agent gestisce domande su ricavi e prestazioni circoscritte a un territorio. Il Customer Insights Agent combina segnali relativi a utilizzo del prodotto, assistenza, contratti e coinvolgimento. Il Data Insights Agent converte domande in linguaggio naturale in query SQL su dataset strutturati.
Questi agenti operano dietro un'unica interfaccia, ma le rispettive superfici di errore rimangono distinte. Uno strumento di risoluzione dei clienti può selezionare la controllata sbagliata. Un componente di retrieval può restituire un contesto debole. Un orchestratore può instradare correttamente una richiesta, ma distorcere i risultati dei sotto-agenti durante la sintesi.
AWS valuta quindi il sistema su tre livelli. I controlli a livello di strumento esaminano capacità come retrieval, risoluzione delle entità e generazione SQL. I controlli a livello di agente valutano ciascun agente specializzato dalla richiesta alla risposta. I controlli multi-agente valutano instradamento, trasferimento del contesto e sintesi finale.
Ogni livello riceve il proprio dataset di valutazione, soglie e criteri di promozione. Questa struttura è importante perché una media end-to-end favorevole può nascondere un componente in errore. Il guasto può interessare solo un segmento di clienti, un tipo di query o un percorso di orchestrazione.
Il framework misura inoltre cinque dimensioni lungo tutto il ciclo di vita: sicurezza, qualità, prestazioni, costo e controllo operativo. Alla qualità viene riservato il trattamento più dettagliato, ma AWS afferma che la sicurezza resta un requisito per il rilascio.
Le nove fasi formano un ciclo chiuso: definire, sperimentare, integrare, controllare, canary, avversario, deriva, impulso e migliorare. Le fasi si estendono dal primo commit al monitoraggio in produzione e alle revisioni successive.
AWS le collega attraverso AgentCore Evaluations, che supporta modalità di valutazione controllate e in tempo reale. La valutazione on-demand viene eseguita su dataset, tracce o sessioni selezionati. La valutazione online campiona continuamente le interazioni in produzione.
Questa continuità è l'importante promessa del prodotto. Un team può applicare gli stessi valutatori prima della distribuzione e dopo che gli utenti hanno interagito con l'agente. Lo standard di valutazione non dovrebbe cambiare semplicemente perché il software ha oltrepassato il confine della produzione.
AWS combina inoltre AgentCore con CloudWatch, S3, Redshift, Lambda e Amazon Quick. Questi servizi gestiscono tracce, output dei valutatori, persistenza, punteggi personalizzati, allarmi e dashboard.
Non si tratta di un nuovo modello fondazionale né di una nuova architettura per agenti. È un modello operativo per decidere se un agente rimanga idoneo all'uso. Questo cambiamento più circoscritto potrebbe rivelarsi più rilevante per le aziende che vanno oltre le dimostrazioni.
Il framework in nove fasi inizia prima della prima esecuzione di test
Il framework di Amazon inizia definendo il fallimento in termini aziendali, perché un obiettivo di qualità indefinito rende arbitrario ogni gate successivo.
La prima fase stabilisce il contratto di valutazione. I team definiscono risultati aziendali, metriche di valutazione, soglie di fallimento, policy di sicurezza, budget di latenza, obiettivi di costo e risposte operative.
Per i venditori AWS, il successo significa ricevere intelligence aggiornata e accurata sugli account, al giusto livello di dettaglio. Gli utenti della leadership necessitano di input affidabili per revisioni settimanali e trasversali alle linee di business, senza un'ampia preparazione manuale.
Questi risultati vengono poi tradotti in categorie di fallimento misurabili. AWS identifica scambi di metriche, periodi errati, entità errate, cifre non supportate, simboli non corretti e calcoli non autorizzati.
Questa tassonomia è più operativa di un unico punteggio generale di accuratezza. Un tasso di superamento in calo indica che qualcosa è cambiato. Un risultato a livello di categoria indica se il problema risiede nel retrieval, nella risoluzione delle entità, nell'interpretazione temporale, nella formattazione o nel ragionamento generato.
AWS combina diversi tipi di valutatori perché nessun singolo metodo di scoring copre ogni rischio. I valutatori integrati affrontano rilevanza, fedeltà, utilità, rispetto delle istruzioni e selezione degli strumenti. I valutatori personalizzati puntano a errori specifici del dominio.
I controlli deterministici confrontano gli output con un risultato atteso esatto. Sono adatti a identificativi di account, date contrattuali, valori di ricavo, risultati SQL e formati strutturati. La valutazione LLM-as-a-judge utilizza un modello e una rubrica quando più risposte possono ragionevolmente soddisfare la richiesta.
Questa distinzione è essenziale. Chiedere a un altro modello di verificare un identificativo esatto aggiunge incertezza dove un semplice confronto funzionerebbe meglio. Usare il confronto esatto tra stringhe per valutare un ragionamento articolato crea il problema opposto.
AWS utilizza inoltre librerie di valutatori di terze parti e un golden set, ovvero una raccolta versionata di query rappresentative con il comportamento previsto. Tale set include esempi derivati dalla produzione, fallimenti di release precedenti e casi limite costruiti.
A livello di strumento, il golden set testa capacità come l'identificazione dei clienti. A livello di agente, AWS copre domande complete, di reporting, di ragionamento e ambigue. I fallimenti in produzione possono diventare casi permanenti di regressione.
La seconda fase confronta le modifiche proposte con lo stesso contratto di valutazione. Revisioni dei prompt, sostituzioni dei modelli, aggiunte di strumenti e aggiornamenti dei dataset passano tutti attraverso la valutazione on-demand prima dell'integrazione.
Questo confronto comprende qualità, latenza, costo e consumo di token. Un candidato che aumenta l'accuratezza aumentando nettamente tempi di risposta e costi non vince automaticamente. Il framework impone che questi compromessi entrino nel registro decisionale.
AWS riferisce che tre mesi di iterazioni mirate hanno aumentato il tasso di superamento dal 93% al 96%. Afferma inoltre che le allucinazioni pure sono diminuite da 138 a meno di 52 ogni 10.000 risposte.
Secondo quanto riferito, i calcoli non autorizzati sono scesi da 59 a meno di 44 ogni 10.000 risposte. Questi dati provengono dall'account interno di AWS e non hanno ricevuto una verifica indipendente.
Questa precisazione è importante perché la fonte è sia un caso di studio tecnico sia un argomento a favore del prodotto. I risultati mostrano ciò che AWS afferma di aver ottenuto in un ambiente. Non stabiliscono una base di riferimento universale per l'affidabilità degli agenti.
Ciononostante, il design della valutazione resta utile anche al di fuori di AWS. I team hanno bisogno di una definizione condivisa di comportamento accettabile prima di poter confrontare prompt, modelli, sistemi di retrieval o modifiche all'orchestrazione.
Documentare quel contratto crea anche memoria organizzativa. I team che utilizzano una base di conoscenza ingegneristica ricercabile possono conservare definizioni dei fallimenti, decisioni di valutazione e prove degli incidenti insieme alle note di implementazione.
I gate CI e i canary colpiscono finestre di fallimento differenti
I gate pre-rilascio bloccano regressioni note, mentre i canary in produzione cercano deterioramenti non innescati da alcuna distribuzione.
La terza fase colloca un dataset sentinella più piccolo nell'integrazione continua. AWS esegue automaticamente questo set dopo le distribuzioni di staging, incluse modifiche a codice, prompt, modelli, strumenti o configurazione.
Il sentinella enfatizza scenari ad alto rischio relativi a qualità, sicurezza, latenza e costo. Viene eseguito più rapidamente del golden set completo, rendendolo adatto a controlli frequenti. Una soglia superata può bloccare la distribuzione.
AWS mantiene sentinelle separate per strumenti, agenti e flussi di lavoro multi-agente. Un rilascio non può superare il controllo soltanto perché il punteggio finale dell'agente sembra accettabile. Una regressione in uno strumento critico può arrestare autonomamente la promozione.
L'azienda descrive una modifica alla normalizzazione dei dati che ha influenzato la risoluzione dei nomi dei clienti. Lo strumento ha restituito entità non risolte per determinati formati e l'agente ha ipotizzato un cliente corrispondente. Questo comportamento rischiava di restituire dati accurati relativi all'account sbagliato.
Un caso deterministico di risoluzione delle entità ha rilevato il problema prima della produzione. Questo esempio mostra perché il test degli agenti debba guardare oltre il testo finale. Una risposta fluida può comunque essere funzionalmente errata.
La quarta fase amplia il controllo di rilascio in un gate di qualità completo. AWS valuta il candidato rispetto al golden set completo e utilizza risposte degli strumenti congelate per isolare il comportamento dell'agente.
Questo design di replay rimuove dalla comparazione la disponibilità degli strumenti in tempo reale e la variabilità dei dati sorgente. Ogni candidato riceve gli stessi output degli strumenti già validati. Le differenze di punteggio dovrebbero quindi riflettere il ragionamento dell'agente anziché la variazione ambientale.
AWS afferma che il suo gate end-to-end include 200 domande trattenute. Un candidato fallisce se il suo punteggio aggregato regredisce, non raggiunge la baseline di produzione oppure lascia troppe domande individuali sotto soglia.
Quest'ultima condizione impedisce alle medie di nascondere danni concentrati. Un modello potrebbe migliorare sulle domande comuni diventando però inaffidabile per una regione, una tipologia di cliente o un formato di richiesta.
La quinta fase cambia contesto. Un canary viene eseguito in produzione su traffico reale e casi sintetici, alla ricerca di fallimenti causati da dipendenze esterne o cambiamenti nei dati.
AWS ha scelto finestre di valutazione di 30 minuti. Afferma che finestre di 15 minuti generavano falsi allarmi eccessivi, mentre finestre di 60 minuti ritardavano la conferma di un calo reale.
Una finestra fallita rimane un segnale operativo. AWS avvisa il proprio team reperibile soltanto dopo che tre finestre consecutive superano la soglia. Un'esecuzione giornaliera separata valuta l'intero golden set alle soglie del gate di rilascio.
Questo design cerca di bilanciare sensibilità e affaticamento da allarmi. Il canary dovrebbe rilevare perdite di qualità persistenti senza abituare gli ingegneri a ignorare notifiche rumorose.
AWS offre un esempio relativo all'aggiornamento di un indice di retrieval. Lo strumento aggiornato restituiva passaggi ampiamente correlati anziché il contesto preciso richiesto dalla domanda.
I parametri dell'infrastruttura apparivano normali. La latenza restava entro le aspettative e il tasso di errori tecnici rimaneva pari a zero. L'agente continuava a produrre risposte rifinite basate su evidenze più deboli.
Il canary ha rilevato un grounding e una precisione del retrieval inferiori durante la prima finestra di valutazione. Una traccia ha poi collegato il punteggio scarso allo strumento di retrieval.
Questo è il capovolgimento centrale del framework. Una richiesta riuscita può rappresentare un fallimento del prodotto, mentre una dipendenza tecnicamente sana può comunque ridurre la qualità delle risposte.
Un'implementazione separata di AWS e Motorway fornisce un altro riferimento concreto. Il suo blueprint di produzione riporta che i risultati di ricerca errati sono diminuiti da una query su otto a una su 50.
L'agente di Motorway aiuta i concessionari a cercare l'inventario dei veicoli attraverso il linguaggio naturale. La sua pipeline di valutazione controlla l'uso degli strumenti, il ragionamento e la qualità dell'output in esecuzioni ripetute. AWS afferma che il rilevamento dei problemi è passato da ore a minuti.
I due casi non sono direttamente confrontabili. Coinvolgono utenti, dataset, definizioni di fallimento e architetture differenti. Insieme, tuttavia, mostrano perché i test di rilascio e la valutazione in produzione risolvono problemi distinti.
La valutazione live espone i limiti dei set di test statici
Un golden set protegge dai fallimenti già noti, ma gli utenti reali producono continuamente input che i suoi progettisti non avevano previsto.
La fase sei affronta il comportamento avversariale. AWS applica controlli su input e output per filtrare le richieste, proteggere i dati sensibili e rilevare tentativi di manipolare le istruzioni dell'agente.
Il framework usa Bedrock Guardrails per il filtraggio dei contenuti e il rilevamento degli attacchi ai prompt. AWS afferma che questi controlli coprono tutto il traffico in modo sincrono prima che una risposta raggiunga l'utente.
Il modello di minaccia include tentativi diretti di jailbreak e istruzioni nascoste nei documenti recuperati. Comprende anche i tentativi di estrarre prompt interni o esporre dati al di fuori dell'autorizzazione dell'utente.
AWS osserva correttamente che la sicurezza non è confinata a una sola fase. Le policy vengono definite nelle fondamenta, testate durante l'integrazione e il deployment, quindi applicate in produzione. La fase sei rende esplicito il livello avversariale.
La fase sette mira al drift, ovvero a un cambiamento persistente del comportamento rispetto alla baseline stabilita. Il drift può derivare da aggiornamenti dei dati, cambiamenti nel comportamento degli utenti, assunzioni obsolete o richieste a coda lunga assenti dal golden set.
AWS afferma di campionare il 10 percento del traffico live per la valutazione online. I punteggi di qualità, latenza e costo alimentano un calcolo dello stato di qualità usando la stessa struttura di finestre di 30 minuti.
Un esempio interno riguardava l'identificazione dei clienti. I test sintetici coprivano varianti dei nomi, controllate e abbreviazioni. Gli utenti reali fornivano inoltre simboli ticker, nomi abbreviati ed errori di battitura.
L'accuratezza riportata è scesa dal 98 percento durante una finestra all'81 percento, quindi all'80 percento nelle due finestre successive. CloudWatch ha avvisato il team reperibile dopo il superamento della soglia mobile.
AWS afferma che le tracce hanno evidenziato la gestione di ticker e abbreviazioni come principale fonte di fallimento. Il team ha aggiornato la propria logica di normalizzazione e promosso le sessioni con punteggi bassi nel golden set.
Secondo quanto riportato, l'accuratezza è tornata alla baseline nel ciclo di valutazione successivo. Anche in questo caso, si tratta di un risultato operativo riportato da AWS e non di una conclusione riprodotta in modo indipendente.
La fase sette supporta inoltre un'esposizione controllata al traffico live. Dopo che un candidato supera il gate offline, un gateway instrada una parte delle richieste tra le versioni attuale e proposta.
Il candidato deve eguagliare o superare la versione in produzione nelle dimensioni selezionate. La valutazione offline verifica casi noti, mentre il confronto live introduce formulazioni e comportamenti non familiari.
Questo processo ricorda i canary software consolidati e il monitoraggio dei modelli, ma gli agenti ampliano l'oggetto della misurazione. I team devono valutare traiettorie, chiamate agli strumenti, contesto recuperato, risposte finali ed esiti delle sessioni.
Questa superficie più ampia crea un problema di misurazione. I giudici basati su LLM possono non essere d'accordo, ereditare bias del modello o premiare caratteristiche stilistiche che non riflettono la correttezza per il business. Anche le rubriche possono diventare obsolete con il cambiamento di prodotti e utenti.
Il campionamento introduce un'altra limitazione. Valutare il 10 percento del traffico riduce la spesa di elaborazione, ma fallimenti rari e dannosi potrebbero restare fuori dal campione. I punteggi aggregati possono inoltre nascondere gruppi di utenti con basso volume.
Privacy e governance dei dati richiedono pari attenzione. Le tracce di produzione possono contenere prompt, documenti recuperati, output degli strumenti, identificatori di account e altro contesto sensibile. I controlli di conservazione e accesso devono corrispondere ai dati coinvolti.
Il framework riconosce la sicurezza e il controllo operativo, ma la qualità dell'implementazione dipende comunque da ciascuna organizzazione. AgentCore fornisce l'infrastruttura di valutazione. Non può definire comportamenti accettabili o una verità di riferimento affidabile per conto del cliente.
Cosa il framework di Amazon non può ancora dimostrare
Il caso di Amazon sostiene la valutazione continua, ma non dimostra che i valutatori automatizzati possano misurare pienamente la fiducia.
La prima limitazione riguarda l'indipendenza delle evidenze. Il framework principale, l'implementazione e i risultati delle prestazioni provengono da AWS. L'azienda gestisce il sistema e vende la piattaforma di supporto.
Questa relazione non invalida i risultati. Significa però che i lettori dovrebbero considerare i miglioramenti riportati come risultati di un caso di studio, non come benchmark neutrali rispetto a stack di valutazione concorrenti.
La seconda limitazione riguarda la validità dei valutatori. Un punteggio è utile solo quando correla con il comportamento che gli utenti apprezzano realmente. Una dashboard precisa può creare falsa fiducia se la sua rubrica misura l'esito sbagliato.
AWS cerca di ridurre questo rischio partendo dagli obiettivi aziendali e combinando valutatori deterministici, personalizzati e basati su modelli. I team devono comunque validare ogni giudice rispetto alla revisione di esperti umani.
L'accordo tra valutatori sarebbe un segnale prezioso. Se valutatori, esperti di dominio e utenti divergono spesso, il punteggio automatizzato non dovrebbe da solo controllare i deployment. Il post di AWS non fornisce quei dati di accordo.
La terza limitazione è la copertura. Il framework verifica categorie di fallimento note e incorpora nel tempo nuovi casi di produzione. Non può garantire il rilevamento di ogni comportamento nuovo prima che si verifichino danni.
Un golden set rischia inoltre di diventare ottimizzato indirettamente. Ripetute modifiche a prompt e modelli possono migliorare i punteggi su esempi familiari senza offrire un'affidabilità più ampia. Casi tenuti separati e dataset aggiornati periodicamente possono ridurre questo rischio.
La quarta limitazione è il costo. La valutazione continua aggiunge chiamate ai modelli, archiviazione delle tracce, elaborazione dei dati, dashboard e lavoro ingegneristico. AWS monitora il costo per query e il costo per risposta riuscita, ma non pubblica un totale completo di implementazione.
Un team più piccolo potrebbe non aver bisogno subito di tutte e nove le fasi. Potrebbe iniziare con una tassonomia dei fallimenti specifica del dominio, test deterministici per i fatti critici, un gate di rilascio e una revisione campionata in produzione.
La quinta limitazione è l'autorità di remediation. La fase nove può generare raccomandazioni per system prompt e descrizioni degli strumenti a partire da tracce fallite. Le raccomandazioni non equivalgono a modifiche autonome sicure.
Una revisione suggerita del prompt può risolvere un fallimento introducendone un altro. Dovrebbe ripercorrere la stessa sequenza di esperimento, merge, gate e canary prima di un deployment esteso.
Anche il rollback automatizzato richiede confini accurati. Ripristinare un prompt o un modello è relativamente circoscritto. Annullare un'azione dell'agente in un sistema aziendale può riguardare pagamenti, messaggi, record o autorizzazioni.
Queste preoccupazioni separano la valutazione dalla governance. La valutazione stima se l'agente si è comportato bene. La governance determina cosa l'agente può fare, quali evidenze devono essere conservate e dove l'approvazione umana resta obbligatoria.
La più ampia guida AgentOps di AWS colloca la valutazione accanto a sicurezza, artefatti versionati, osservabilità e revisione umana. Questo inquadramento è più credibile del trattare un singolo punteggio come un certificato di fiducia.
La fiducia non è una proprietà che AgentCore può attribuire a un agente. È un giudizio accumulato basato su esiti, controlli, gestione degli incidenti e trasparenza. La valutazione contribuisce con evidenze a quel giudizio.
Per gli acquirenti, la domanda giusta non è quindi se una piattaforma offra valutazioni. La domanda più difficile è se le sue misurazioni coprano i costi reali dei fallimenti dell'organizzazione e restino credibili nel cambiamento.
Tre segnali mostreranno se il ciclo chiuso funziona
Il valore del framework dipenderà dalla credibilità dei valutatori, dall'adozione in produzione e dall'evidenza che il feedback migliori i casi non familiari.
Il primo segnale è la validazione indipendente dei valutatori automatizzati. Le aziende dovrebbero osservare confronti pubblicati tra i punteggi di AgentCore, i giudizi degli esperti di dominio e gli esiti reali per gli utenti.
Un elevato accordo rafforzerebbe l'affermazione di AWS secondo cui le valutazioni possono governare i rilasci. Un disaccordo persistente indebolirebbe i gate automatizzati e aumenterebbe la necessità di revisione umana.
Il confronto dovrebbe coprire più della semplice utilità generale. Dovrebbe verificare la risoluzione delle entità, i limiti di autorizzazione, la selezione degli strumenti, i calcoli fondati, gli esiti delle sessioni e la sintesi multi-agente.
Il secondo segnale è l'adozione oltre gli esempi scritti da AWS. I report di produzione da settori regolamentati, grandi fornitori software e piccoli team di ingegneria rivelerebbero quanto sia portabile il modello a nove fasi.
I report utili dovrebbero divulgare costruzione dei dataset, tassi di campionamento, falsi allarmi, incidenti mancati, tempi di remediation e overhead di valutazione. Un miglioramento percentuale senza questi dettagli offre indicazioni limitate.
La configurazione online di AgentCore può elaborare continuamente tracce da un endpoint dell'agente o da gruppi di log CloudWatch selezionati. I controlli di valutazione online supportano inoltre valutatori configurabili, campionamento e stato di esecuzione.
La metrica di adozione importante non è il numero di configurazioni abilitate. È se i team rilevano fallimenti semantici prima che gli utenti li segnalino e li risolvono senza creare nuove regressioni.
Il terzo segnale è la performance del ciclo chiuso sul traffico non osservato. AWS afferma che il suo sistema di raccomandazione può analizzare le tracce e suggerire prompt rivisti o descrizioni degli strumenti più chiare.
In un esempio riportato, valori codificati rigidamente all'interno di esempi few-shot apparivano in risposte non correlate. AWS ha sostituito tali valori con segnaposto e ha osservato meno allucinazioni e un grounding più solido.
Il test successivo consiste nel verificare se raccomandazioni simili migliorino interazioni tenute separate e live, non soltanto le tracce che le hanno generate. Ogni raccomandazione dovrebbe passare attraverso il ciclo di valutazione originale.
La fase otto fornisce la base operativa per quel test. AgentCore Observability registra dati strutturati di esecuzione tramite OpenTelemetry, uno standard aperto per tracce, metriche e log.
AWS afferma che le sue dashboard collegano un allarme alla traccia dell'agente pertinente, inclusi ordine degli strumenti, input, output, latenza e uso dei token. I risultati dei valutatori seguono una pipeline separata verso CloudWatch e l'archiviazione a più lungo termine.
L'azienda riporta che il tempo medio di rilevamento è sceso da giorni o settimane a meno di quattro ore. Mira inoltre al rilevamento automatizzato prima che i reclami degli utenti diventino il principale segnale di incidente.
Questi risultati catturano la promessa più difendibile del framework. Le valutazioni di Amazon AgentCore non garantiscono che un sistema autonomo risponderà sempre correttamente. Rendono il deterioramento silenzioso sufficientemente osservabile da poter essere indagato, bloccato o invertito.
Gli sviluppatori dovrebbero iniziare identificando la risposta errata che potrebbe arrecare il danno maggiore. Gli acquirenti enterprise dovrebbero chiedere ai fornitori come tale fallimento venga misurato prima del rilascio e rilevato in seguito.
I knowledge worker dovrebbero restare cauti quando un agente sembra sicuro di sé. Un linguaggio fluente non garantisce comunque che dietro la risposta vi siano lo strumento, il cliente, il periodo o la fonte corretti.
La prossima generazione di piattaforme per agenti competerà su più fronti rispetto al solo accesso ai modelli e all’orchestrazione. Competerà sulla capacità dei team di spiegare gli errori, riprodurli e impedirne il ripetersi.
Se la vostra organizzazione utilizza già degli agenti, esaminate l’ultimo incidente che ha raggiunto un utente. Il monitoraggio della latenza o degli errori lo avrebbe rilevato? In caso contrario, questa lacuna è il punto di partenza per un vero contratto di valutazione.
