La valutazione di Amazon Bedrock AgentCore trasforma le regressioni degli agenti in pull request non superate

Amazon ha trasformato la valutazione di Amazon Bedrock AgentCore in un controllo di qualità operativo in GitHub Actions, sostituendo le verifiche soggettive degli agenti con quattro test valutati.

La pipeline di riferimento distribuisce un agente AI e un server Model Context Protocol protetto da OAuth, quindi richiama l'agente con prompt rappresentativi. Valuta le tracce risultanti e fa fallire la pull request quando una metrica richiesta scende sotto una soglia configurata.

Questo cambia il dibattito sui test degli agenti. La sfida immediata non è AWS contro un altro provider cloud. È la valutazione automatizzata e ripetibile contro i controlli manuali a campione che molti team di sviluppo usano ancora prima di unire le modifiche agli agenti.

Amazon ha pubblicato l'implementazione l'8 settembre 2026. La pipeline di valutazione collega AgentCore Runtime, AgentCore Evaluations, Amazon Cognito, CloudWatch, AWS CDK e GitHub Actions.

Il risultato importante non è un'altra dashboard di test. Una risposta non superata può ora trasformarsi in una build software non superata, prima che il comportamento modificato dell'agente raggiunga un ambiente condiviso o la produzione.

La valutazione di Amazon Bedrock AgentCore diventa un controllo per il merge

AWS ha trasformato la qualità degli agenti da un'opinione espressa in fase di revisione a una condizione per la pull request.

Il flusso di lavoro di riferimento viene eseguito quando una pull request diretta al branch principale modifica il codice dell'agente, il codice del server MCP, l'infrastruttura o gli script di valutazione. Crea uno stack di sviluppo temporaneo contenente due runtime AgentCore.

Un runtime ospita un agente basato su Strands. L'altro ospita un server MCP, che espone strumenti tramite un protocollo standard per collegare applicazioni AI a capacità esterne.

Un pool di utenti Amazon Cognito condiviso protegge entrambi i runtime. Il flusso di lavoro distribuisce questa infrastruttura tramite AWS Cloud Development Kit, quindi legge gli identificatori dei runtime e gli endpoint di autenticazione dagli output della distribuzione.

GitHub Actions ottiene credenziali AWS temporanee tramite federazione OpenID Connect. OIDC consente a GitHub di scambiare un token di identità a breve durata con un ruolo AWS, evitando una chiave di accesso AWS permanente nei segreti del repository.

Il flusso di lavoro conserva comunque l'ARN del ruolo AWS come segreto GitHub. Tuttavia, le credenziali AWS risultanti sono temporanee e vincolate dalle policy di trust e autorizzazione del ruolo. GitHub documenta questo modello di sicurezza OIDC.

Dopo la distribuzione, la pipeline attende che entrambi i runtime siano pronti. Questa pausa è operativamente significativa perché un runtime appena creato non può accettare immediatamente richieste.

AWS afferma che una chiamata iniziale restituisce una risposta 424 Failed Dependency. Il flusso di lavoro fornito interroga il servizio di controllo AgentCore e riscalda il server MCP prima di avviare l'esecuzione dei test.

La pipeline recupera quindi un token di accesso OAuth e invia prompt di test all'endpoint HTTPS dell'agente. Ogni prompt riceve un identificatore di sessione distinto, consentendo al processo di valutazione di associare le tracce emesse all'interazione corretta.

Il dataset di esempio copre diversi tipi di comportamento. Chiede all'agente di calcolare una semplice somma, restituire l'ora UTC corrente, trovare il prezzo di un'azione Apple e recuperare il numero di dipendenti.

Questi esempi verificano più della formulazione delle risposte. Testano capacità integrate, strumenti MCP pubblici, strumenti aziendali protetti, selezione degli strumenti e parametri passati a ciascuno strumento selezionato.

Lo script di valutazione applica quattro valutatori integrati:

• GoalSuccessRate chiede se la sessione ha soddisfatto l'obiettivo dell'utente.

• Correctness confronta la risposta con aspettative o contesto disponibili.

• ToolSelectionAccuracy verifica se l'agente ha scelto uno strumento appropriato.

• ToolParameterAccuracy verifica se l'agente ha fornito argomenti adeguati.

La configurazione di riferimento usa 0.8 su una scala da zero a uno come soglia di accettazione. Se un punteggio richiesto scende sotto tale soglia, lo script termina senza successo e GitHub contrassegna il job come non superato.

Il flusso di lavoro può anche pubblicare i risultati della valutazione nella pull request. I revisori vedono il fallimento misurato insieme alla modifica del codice, invece di ricostruire il comportamento dell'agente dai log o dalle conversazioni locali.

Infine, il passaggio di pulizia viene eseguito anche quando la valutazione fallisce. Distrugge lo stack CDK temporaneo affinché le pull request non superate non lascino runtime di sviluppo attivi indefinitamente.

Questa sequenza crea la tensione centrale. I test manuali possono rivelare un problema evidente, ma raramente forniscono una regola riproducibile che ogni pull request pertinente deve soddisfare.

Perché i test manuali degli agenti sono ora sotto pressione

La pipeline mette sotto pressione i team che trattano la risposta di un agente come qualcosa da ispezionare, anziché come un artefatto che la distribuzione software deve convalidare.

I test delle applicazioni tradizionali hanno output chiari. Una funzione restituisce il valore previsto, un'API rispetta uno schema oppure un'operazione sul database preserva un invariante.

Gli agenti AI complicano questo modello. Le loro risposte possono variare e una frase finale corretta non dimostra che l'agente abbia seguito un percorso accettabile.

Un agente che usa strumenti potrebbe selezionare il servizio sbagliato, divulgare un risultato non autorizzato o inviare parametri malformati. Potrebbe anche arrivare a una risposta plausibile attraverso una sequenza di chiamate costosa o non sicura.

Le modifiche ai prompt creano un altro problema. Un piccolo aggiustamento alle istruzioni di sistema può alterare la scelta degli strumenti, il comportamento di rifiuto, il dettaglio della risposta o il completamento dell'attività in scenari non correlati.

Gli aggiornamenti dei modelli e le modifiche alle dipendenze introducono rischi simili. I test unitari convenzionali possono confermare che l'applicazione funziona, ma non rilevare un significativo deterioramento del comportamento.

I team spesso compensano con set di prompt manuali. Uno sviluppatore inserisce diverse domande familiari, legge le risposte e integra le modifiche quando nulla appare palesemente errato.

Questo metodo offre una copertura limitata e un giudizio incoerente. Produce inoltre poche evidenze su quale comportamento sia cambiato tra due revisioni.

La pipeline AWS aggiunge un percorso di valutazione comune a ogni pull request pertinente. Distribuisce il codice proposto, esercita quel codice, raccoglie telemetria e applica gli stessi valutatori.

AgentCore lavora con span OpenTelemetry, ovvero record strutturati di chiamate al modello, attività degli strumenti e altre operazioni all'interno di un'interazione. AgentCore Observability invia queste tracce a CloudWatch.

Per la valutazione on-demand, la pipeline seleziona gli span di una determinata sessione e li passa al servizio di valutazione. Le modalità di valutazione includono anche il monitoraggio online e l'analisi batch asincrona.

Questa distinzione è importante per i team di distribuzione. La valutazione on-demand si adatta a una pull request perché mira a un insieme piccolo e controllato di interazioni e restituisce punteggi dettagliati.

La valutazione online ha uno scopo diverso. Campiona il traffico distribuito e monitora il comportamento dopo il rilascio, quando utenti reali producono richieste che un dataset di test non aveva previsto.

La valutazione batch elabora raccolte più ampie di sessioni. È più adatta ai confronti con una baseline, agli audit periodici e all'analisi prima e dopo le modifiche.

Il controllo sulle pull request non sostituisce queste modalità. Sposta il primo punto di controllo misurabile più vicino alla modifica del codice.

Questo approccio cambia anche chi deve reagire a una regressione. Senza un controllo, i team di qualità o gli utenti spesso scoprono il problema dopo la distribuzione.

Con un controllo GitHub obbligatorio, l'autore deve risolvere il comportamento non superato prima del merge. Il feedback arriva mentre il codice pertinente e le decisioni sui prompt sono ancora recenti.

Questo è particolarmente utile per i team che gestiscono agenti condivisi. Una modifica a una risposta che sembra accettabile per uno sviluppatore può compromettere un flusso di strumenti di proprietà di un altro gruppo.

Un dataset di valutazione curato può preservare queste aspettative. Diventa una registrazione eseguibile delle attività che l'agente deve continuare a svolgere.

Gli sviluppatori hanno comunque bisogno di accedere al contesto di supporto alla base di tali aspettative. Una knowledge base ingegneristica può aiutare i team a collegare i casi di valutazione a specifiche, incidenti e decisioni progettuali.

Il cambiamento più ampio è organizzativo. La qualità dell'agente diventa parte della definizione di una modifica integrabile, anziché una revisione facoltativa condotta quando qualcuno ha abbastanza tempo.

OAuth rende i test end-to-end più difficili dell'assegnazione di un punteggio

La parte difficile non è richiedere un punteggio di valutazione. È riprodurre il percorso completo degli strumenti di un agente protetto all'interno di un runner CI headless.

L'architettura di riferimento colloca sia l'agente sia il server MCP dietro Cognito. Gli utenti interattivi si autenticano tramite un flusso authorization-code e ricevono token contenenti scope e claim di ruolo personalizzati.

Questi ruoli determinano a quali strumenti MCP un utente può accedere. Un utente dell'area finanziaria e uno delle risorse umane non dovrebbero ricevere automaticamente le stesse capacità aziendali.

GitHub Actions non ha un utente interattivo. Non può aprire una schermata di consenso, completare un accesso tramite browser e trasportare il contesto di ruolo di una persona attraverso il test.

AWS presenta tre modi per gestire questa discrepanza. Ciascuno convalida una parte diversa del sistema.

Il primo approccio valuta le tracce archiviate. Un processo di staging richiama l'agente in anticipo, acquisisce telemetria rappresentativa e salva tali tracce come fixture di test.

I job delle pull request valutano le fixture senza chiamare un agente o un server MCP attivo. Questo approccio è prevedibile ed evita il problema di autenticazione nella CI.

Presenta anche una limitazione seria. I punteggi descrivono il comportamento acquisito in precedenza, non necessariamente il codice dell'agente nella pull request corrente.

Le tracce archiviate possono convalidare le modifiche ai valutatori o preservare una baseline storica. Non possono dimostrare che il codice runtime appena modificato produca ancora la traiettoria prevista.

Il secondo approccio usa un account di servizio dedicato. Un operatore completa una volta l'autorizzazione interattiva e memorizza il suo refresh token in un gestore di segreti.

La CI può quindi agire come un utente noto con ruoli definiti. Ciò rende possibile testare i confini di autorizzazione e l'accesso agli strumenti per un'identità specifica.

I refresh token scadono o diventano non validi. I team hanno bisogno di rotazione, nuova autorizzazione e controllo accurato dei privilegi dell'account.

L'implementazione AWS sceglie una terza strada: l'autenticazione machine-to-machine. Cognito emette un token tramite il grant OAuth client_credentials.

Lo script di valutazione invia l'ID client, il segreto client e lo scope richiesto all'endpoint token di Cognito. Quindi richiama AgentCore Runtime tramite HTTPS con il bearer token restituito.

Il middleware MCP distingue questi token dai token utente. I token macchina hanno scope ma nessun claim di ruolo personalizzato, quindi l'esempio consente loro di raggiungere ogni strumento.

I token interattivi continuano a contenere ruoli e il server MCP applica restrizioni a livello di strumento per tali utenti. Lo stesso pool Cognito supporta quindi sia l'accesso CI sia l'autorizzazione umana.

Questo progetto consente test live end-to-end del codice nella pull request. L'agente può chiamare il server MCP distribuito e produrre nuove tracce per la valutazione.

Tuttavia, non testa l'applicazione dei ruoli. L'identità CI aggira tali controlli di ruolo per progettazione.

Questa distinzione è l’avvertenza più importante dell’architettura. Una pipeline che supera i controlli dimostra che l’identità macchina può completare le attività valutate. Non dimostra che FinanceUser e HRUser ricevano risultati autorizzati differenti.

I team che necessitano di entrambe le forme di garanzia devono aggiungere test di autorizzazione separati. Possono utilizzare account di servizio con ruoli specifici o test diretti sul middleware MCP.

Anche la credenziale della macchina diventa una risorsa sensibile. AWS afferma che solo la pipeline CI e il runtime dell’agente dovrebbero poterla ottenere.

Questa affermazione dipende dai dettagli di implementazione. Permessi del repository, approvazioni dei workflow, policy IAM, esposizione dei segreti, comportamento dei fork e redazione dei log influenzano tutti il reale confine di sicurezza.

La connessione OIDC di GitHub protegge il lato AWS dalle credenziali del repository a lunga durata. Non elimina ogni segreto, perché il client OAuth utilizza ancora un client secret.

Anche il ruolo IAM dovrebbe seguire il principio del privilegio minimo. Un accesso di deployment troppo ampio a Cognito, ECR, risorse CDK, Bedrock e AgentCore può conferire più autorità di quella necessaria a un normale job di pull request.

Le protezioni dell’ambiente possono ridurre il rischio. I team possono limitare quali branch e workflow assumono il ruolo, richiedere approvazione per modifiche non attendibili e separare i ruoli di deployment dalle identità di valutazione.

L’architettura testa quindi insieme il comportamento dell’agente e l’integrazione CI. La correttezza dell’autorizzazione resta un obiettivo di accettazione separato.

Il Quality Gate valuta le tracce, non solo le risposte

La valutazione di Amazon Bedrock AgentCore è importante perché può giudicare il percorso dell’agente attraverso un’attività, non soltanto il suo testo finale.

Lo script di valutazione usa lo starter toolkit di AgentCore per raccogliere le tracce CloudWatch pertinenti. Applica quindi i valutatori alla sessione selezionata.

L’API Evaluate grezza accetta sessionSpans, una raccolta di span di telemetria appartenenti a una sessione. AWS avverte che mescolare span di più sessioni produce un errore di convalida.

Questo confine di sessione consente al valutatore di ricostruire un’interazione. Può ispezionare l’input dell’utente, l’output del modello, gli strumenti selezionati, i parametri degli strumenti e la risposta risultante.

GoalSuccessRate opera a livello di sessione. Chiede se l’interazione completa ha ottenuto ciò che l’utente aveva richiesto.

Correctness esamina la risposta a livello di traccia. Può utilizzare una risposta attesa quando il test ne fornisce una.

ToolSelectionAccuracy e ToolParameterAccuracy operano a livello di chiamata dello strumento. Distinguono la scelta dell’operazione corretta dall’esecuzione corretta di tale operazione.

Questa separazione ha prodotto un risultato istruttivo nel test di regressione deliberata di AWS. Gli autori hanno modificato il prompt di sistema affinché l’agente restituisse sempre un rifiuto inutile.

GoalSuccessRate è sceso a 0.0. Anche Correctness ha ottenuto 0.0, così come ToolParameterAccuracy.

ToolSelectionAccuracy ha comunque ottenuto 1.0. L’agente poteva apparentemente identificare uno strumento appropriato pur fallendo la richiesta complessiva.

Ecco perché una singola misura aggregata può nascondere problemi. Valutatori diversi catturano dimensioni indipendenti e un punteggio positivo non può compensare ogni comportamento fallito.

Dopo che gli autori hanno ripristinato il prompt di sistema previsto, GoalSuccessRate è tornato a 1.0. Correctness ha raggiunto 0.9, mentre entrambe le misure degli strumenti hanno raggiunto 1.0.

Tutti e quattro hanno quindi superato la soglia di esempio pari a 0.8. GitHub ha sbloccato la pull request.

AgentCore accetta anche input di riferimento per i test che richiedono un comportamento atteso. Questi input possono includere una risposta attesa, asserzioni in linguaggio naturale o una traiettoria attesa degli strumenti.

Una traiettoria descrive la sequenza di strumenti che un agente dovrebbe chiamare. AWS offre valutatori per ordine esatto, in ordine e in qualunque ordine, per diversi vincoli di workflow.

Un test in ordine esatto è adatto a un processo in cui ogni passaggio dipende dal precedente. Un test in qualunque ordine è adatto a operazioni di recupero indipendenti, la cui sequenza non influisce sulla correttezza.

Il servizio supporta anche valutatori personalizzati. I team possono definire le proprie istruzioni, il modello giudice e la scala di punteggio per requisiti specifici del dominio.

I valutatori basati su codice offrono un’opzione più deterministica. Invocano una funzione AWS Lambda in grado di controllare schemi, pattern, parole chiave o regole di business.

Questa combinazione è importante perché non ogni requisito necessita di un giudice basato su modello. Validità JSON, campi vietati, numero massimo di chiamate e identificatori esatti possono spesso utilizzare codice ordinario.

Secondo la guida ai valutatori personalizzati, i valutatori possono operare a livello di sessione, traccia o chiamata dello strumento. La logica personalizzata può utilizzare un modello o una funzione Lambda.

Un gate pratico dovrebbe associare il tipo di valutatore al requisito. Il punteggio basato su modello è adatto a qualità semantiche quali rilevanza, successo dell’attività o fedeltà.

Il codice deterministico è adatto a vincoli binari. I controlli della traiettoria degli strumenti sono adatti alla struttura di workflow prevista.

Il segnale migliore deriva dalla combinazione di questi metodi. Una risposta può essere semanticamente corretta pur violando uno schema, e uno schema valido può comunque contenere una risposta irrilevante.

Anche la ground truth merita un uso attento. Non ogni risposta accettabile ha una formulazione esatta, soprattutto per riassunti o analisi aperte.

Le asserzioni possono esprimere i fatti o i comportamenti che devono comparire senza imporre una sola risposta. Le traiettorie attese possono specificare il comportamento degli strumenti indipendentemente dallo stile della prosa.

Questo trasforma il set di test in qualcosa di più di una raccolta di prompt. Ogni scenario può indicare cosa significa successo a livello di risposta, attività e strumenti.

Un punteggio positivo conserva comunque dei punti ciechi

Il gate intercetta regressioni definite, ma la sua affidabilità dipende dalla copertura dei test, dalla stabilità dei punteggi, dalla progettazione delle identità e dalle tempistiche operative.

AWS afferma che la pipeline completa richiede circa 10 minuti. Deployment, avvio del runtime, propagazione delle tracce e valutazione basata su modello contribuiscono a questa durata.

Questa tempistica è accettabile per molte pull request. È troppo lenta per un controllo locale pre-commit e può diventare costosa nei repository con aggiornamenti frequenti.

La disponibilità delle tracce aggiunge incertezza. AWS ha osservato ritardi di propagazione da 30 a 90 secondi dopo l’invocazione dell’agente.

Lo script di riferimento riprova ogni 30 secondi per un massimo di 10 minuti. Interrogare CloudWatch immediatamente può quindi produrre un apparente fallimento prima che la traccia esista.

L’architettura del runtime crea un ulteriore ostacolo di implementazione. AgentCore Runtime richiede immagini di container ARM64, mentre i runner standard ospitati da GitHub usano processori x86-64.

Il workflow utilizza QEMU e Docker Buildx per la costruzione di immagini multipiattaforma. Questo requisito aumenta il tempo di build e introduce un ulteriore possibile punto di fallimento non correlato alla qualità dell’agente.

La limitazione più rilevante deriva dal giudizio basato su modello. Un valutatore LLM può assegnare punteggi leggermente diversi quando valuta la stessa traccia più di una volta.

Una soglia rigida può quindi creare pull request instabili vicino al limite. Un’esecuzione può superare il controllo con 0.81, mentre un’altra fallisce con 0.79 senza una differenza significativa nel codice.

AWS raccomanda di lasciare margine tra la soglia di accettazione e l’obiettivo di affidabilità desiderato. I team dovrebbero inoltre misurare la varianza del valutatore prima di rendere obbligatorio un controllo.

Esecuzioni ripetute possono stimare tale varianza, ma aumentano anche l’utilizzo delle valutazioni. L’esempio di riferimento utilizza quattro valutatori su cinque prompt, producendo 20 chiamate al modello giudice per una pull request.

La fonte non assegna un prezzo a queste chiamate. Consiglia però ai team di monitorare l’utilizzo di Bedrock man mano che repository e dataset crescono.

La copertura dei test presenta un problema noto ma più netto. Un quality gate misura soltanto gli scenari inclusi nel suo dataset.

Quattro o cinque prompt comodi non possono rappresentare ogni richiesta di produzione, stato di autorizzazione, modalità di errore, lingua o input avversario.

Il token macchina dell’esempio può accedere a ogni strumento. Di conseguenza, l’esecuzione end-to-end non dimostra che gli strumenti vincolati dai ruoli rimangano protetti dagli utenti ordinari.

Un punteggio ampio può anche nascondere prestazioni disomogenee. Una media complessiva può superare il controllo mentre uno scenario critico fallisce.

Le attività ad alto rischio dovrebbero prevedere requisiti a livello di scenario. Un’azione sulla busta paga, l’eliminazione di un account o la ricerca di dati personali non dovrebbe ottenere successo grazie a diversi semplici prompt aritmetici.

Anche le metriche necessitano di responsabilità. Gli sviluppatori devono sapere chi approva le modifiche alle soglie, aggiunge nuovi scenari e indaga sui disaccordi tra valutatori.

Altrimenti, un gate che fallisce può creare pressione per abbassare la soglia. L’organizzazione preserva allora la velocità di delivery indebolendo la misurazione.

La falsa fiducia è un altro rischio. Un controllo verde indica che la versione testata ha soddisfatto criteri specificati in un determinato momento.

Non certifica ogni risposta, non elimina il prompt injection e non convalida l’infrastruttura esterna allo stack di test distribuito. Non sostituisce inoltre una revisione della sicurezza.

La telemetria di produzione resta essenziale perché gli utenti troveranno combinazioni che un dataset curato ha mancato. La valutazione online di AgentCore può campionare sessioni live e pubblicare risultati in CloudWatch.

La documentazione sui risultati afferma che i punteggi online appaiono come metriche CloudWatch. Gli eventi di valutazione dettagliati vengono archiviati in gruppi di log dedicati.

La valutazione batch può quindi confrontare finestre più ampie prima e dopo modifiche al modello, al prompt o agli strumenti. Tale confronto offre una baseline più solida rispetto a una sola esecuzione di pull request.

Un sistema maturo dovrebbe collegare queste fasi. I fallimenti in produzione dovrebbero diventare nuovi scenari di valutazione, e i ripetuti fallimenti CI dovrebbero orientare la progettazione dell’agente.

Il quality gate è più credibile quando il suo dataset evolve insieme agli incidenti. Un benchmark statico finisce per premiare la familiarità con il test anziché un comportamento affidabile.

Cosa osservare dopo il primo gate GitHub Actions

Il prossimo test è capire se i team possono rendere questi gate sufficientemente stabili, attenti alla sicurezza e rappresentativi da diventare controlli obbligatori.

Il primo segnale è l’adozione di valutazioni ground-truth e deterministiche nei workflow di pull request. Le quattro metriche integrate offrono un utile punto di partenza, ma non esprimono ogni regola di business.

Osservate se i team aggiungono risposte attese, asserzioni e traiettorie degli strumenti per scenari ad alto valore. Un maggiore utilizzo di controlli basati su Lambda dimostrerebbe che la valutazione degli agenti sta diventando normale verifica del software.

Questo sviluppo rafforzerebbe le ragioni a favore della valutazione Amazon Bedrock AgentCore. Ridurrebbe la dipendenza da un unico modello giudice e renderebbe alcuni fallimenti più facili da riprodurre.

Il secondo segnale è la copertura CI consapevole dei ruoli. AWS identifica apertamente la limitazione del token macchina, poiché il flusso scelto aggira i controlli sui ruoli utente.

I team dovrebbero pubblicare pattern che testino identità utente distinte senza creare fragili operazioni sui refresh token. Account di servizio, test diretti di autorizzazione e tenant di test isolati sono percorsi plausibili.

Se i controlli specifici per ruolo diventeranno comuni, l’architettura si avvicinerà a una garanzia end-to-end completa. Se resteranno separati o assenti, un punteggio verde dell’agente dirà poco sulla correttezza dell’autorizzazione.

Il terzo segnale è il collegamento tra i gate delle pull request e i risultati di produzione. Un piccolo dataset di sviluppo non può restare rappresentativo senza feedback dalle sessioni reali.

Osservate workflow che promuovono tracce di produzione con punteggio basso a casi di regressione revisionati. Il monitoraggio online dovrebbe scoprire i fallimenti, mentre i test CI curati dovrebbero impedire che tali fallimenti si ripresentino.

Anche il tooling di AWS per la valutazione dei dataset è uno sviluppo rilevante. I suoi dataset runners possono invocare agenti, attendere la telemetria e valutare scenari tramite un processo coordinato.

Un’adozione più ampia ridurrebbe l’orchestrazione personalizzata oggi visibile nel workflow di riferimento. Renderebbe inoltre più semplice mantenere set di valutazione più grandi e versionati.

Per gli sviluppatori, la domanda pratica non è più se le risposte degli agenti debbano essere testate. È quali comportamenti debbano bloccare un merge, quali richiedano monitoraggio e quali impongano un’applicazione deterministica.

Partite dai fallimenti che causerebbero un rollback, un incidente di sicurezza o l’interruzione di un flusso di lavoro aziendale. Assegnate a ciascuno uno scenario esplicito e un metodo di valutazione proporzionato al rischio.

Poi mandate deliberatamente l’agente in errore e verificate che il gate fallisca per il motivo previsto. Un controllo diventa affidabile solo dopo aver intercettato una regressione nota.

Amazon ha fornito un percorso credibile dai test sui prompt ai controlli di stato GitHub obbligatori. Il passo successivo spetta ai team di engineering: definire i comportamenti che rifiutano di distribuire, codificarli e mantenere aggiornata tale definizione.