Gli agenti in release vogliono trajectory gate

Rilasciare un agente non significa rilasciare una semplice risposta in chat. Quando il sistema può chiamare tool, leggere record, aggiornare ticket, attivare workflow o combinare più passaggi, la domanda di release cambia. Non basta più chiedere: “La risposta finale sembra corretta?” Bisogna chiedere: “L’agente ci è arrivato con un percorso accettabile?”

La differenza è concreta. Una risposta plausibile può nascondere una traiettoria pericolosa. Un agente può sintetizzare correttamente un account cliente dopo aver interrogato prima il sistema sbagliato. Può produrre una raccomandazione elegante saltando il recupero delle prove. Può funzionare in demo perché usa troppi tool, poi fallire in produzione per limiti, costi o permessi. Può rispondere bene al primo turno e degradare in una conversazione più lunga.

La tesi per chi costruisce prodotto è semplice: gli agenti in release vogliono trajectory gate. Non gate che congelano ogni passaggio di ragionamento, e non test fragili che puniscono la flessibilità utile. Un trajectory gate definisce il percorso operativo atteso, la varianza tollerata intorno a quel percorso, e le soglie di release per qualità della risposta, groundedness, safety, uso dei tool e regressioni.

Anche il lessico degli eval sta andando in questa direzione. La documentazione di Google Agent Development Kit descrive criteri per tool trajectory, response matching, groundedness tramite controlli di hallucination, safety, successo multi-turn e qualità dell’uso dei tool. Il criterio di tool trajectory supporta matching exact, in-order e any-order, cioè il vocabolario pratico che serve ai team quando vogliono validare il comportamento dei tool senza fingere che ogni task abbia un solo percorso valido. Il riferimento è nei criteri di valutazione di Google ADK.

Perché gli eval sulla sola risposta non bastano

Un eval sulla risposta è utile, ma incompleto quando l’agente usa davvero i tool. Ti dice se l’output visibile assomiglia alla risposta di riferimento, oppure se un giudice lo considera accettabile. Non ti dice se l’agente ha usato la sorgente dati giusta, se ha evitato un’azione vietata, se ha preservato gli argomenti obbligatori, o se ha seguito il workflow che prodotto e operations hanno deciso di supportare.

Immagina un agente di supporto che può leggere lo stato di abbonamento, controllare le ultime fatture e preparare una richiesta di credito. Il messaggio finale al cliente può essere cortese e accurato. La release dovrebbe comunque fallire se l’agente ha saltato il controllo fattura prima di preparare il credito, se ha chiamato una API di scrittura quando era permessa solo la lettura, o se ha inventato una motivazione di policy non presente nel contesto recuperato.

Per questo la traiettoria va messa accanto alla qualità della risposta. L’output è ciò che vede l’utente. La traiettoria è ciò che l’azienda deve potersi permettere di fidarsi.

Lo stesso principio vale in altri lavori di prodotto AI. Gli eval AI vogliono budget di errore perché una media generale nasconde i rischi davvero importanti. Per gli agenti, il caso di errore spesso non è una frase scritta male. È una sequenza inaccettabile di chiamate ai tool.

Cosa deve contenere un trajectory gate?

Un trajectory gate utile ha cinque elementi.

Primo, nomina il task rischioso. Non partire da tutto l’agente. Scegli il task in cui un percorso sbagliato crea il costo più alto: approvare un rimborso, modificare un account, classificare un caso compliance, preparare un deploy, instradare un lead, raccogliere dati sensibili, riconciliare una posizione finanziaria. Il gate deve essere abbastanza stretto da permettere esempi concreti.

Secondo, definisci il percorso tool atteso. Questo non significa registrare il ragionamento nascosto del modello. Significa elencare operazioni osservabili: recupera account, recupera policy, confronta eleggibilità, chiedi conferma, crea bozza, registra decisione. Il percorso deve usare gli stessi nomi che compaiono in trace e log, così engineering può testarlo e prodotto può revisionarlo.

Terzo, definisci la varianza tollerata. Qui molti team si oppongono ai gate perché temono che un test deterministico renda l’agente meno utile. La risposta non è evitare i controlli di traiettoria. La risposta è scegliere il giusto livello di rigidità. Alcuni percorsi richiedono matching exact. Uno storno di pagamento può dover usare gli stessi tool, nello stesso ordine, senza extra. Altri task richiedono matching in-order. Un assistente di ricerca può fare ricerche aggiuntive, ma deve recuperare prove prima di produrre la raccomandazione. Altri task possono accettare any-order. Se varie chiamate di arricchimento sono indipendenti, il gate può interessarsi al fatto che siano avvenute, non all’ordine.

Quarto, definisci accettazione della risposta e delle prove. Un trajectory gate deve comunque controllare l’output finale. La risposta deve soddisfare il task, riferirsi al contesto usato quando serve, ed evitare affermazioni non supportate. Per agenti basati su retrieval, la groundedness non è un dettaglio. È la differenza tra usare il contesto e mascherare un’ipotesi con prosa fluente.

Quinto, definisci soglie di safety e regressione. La safety deve coprire sia risposta finale sia comportamento dei tool. La regressione deve confrontare la nuova build con casi rischiosi già noti. Una release non dovrebbe passare perché l’happy path migliora mentre un edge case conosciuto si rompe in silenzio.

Quanto deve essere rigido il gate?

Il gate deve essere rigido dove il processo aziendale è rigido, e flessibile dove il problema utente è flessibile.

Usa gate exact quando il task ha una sequenza operativa canonica. Esempi: verifica identità prima di modificare un account, retrieval della policy prima di una decisione di entitlement, approvazione umana prima di un’azione irreversibile, validazione prima di una chiamata di scrittura. In questi casi la varianza non è creatività. È rischio.

Usa gate in-order quando il task consente esplorazione ma ha milestone obbligatorie. Un agente sales research può chiamare diversi tool di arricchimento, ma non dovrebbe scrivere il razionale di outreach prima di aver controllato account e interazioni recenti. Un assistente di coding può ispezionare file in ordini diversi, ma dovrebbe eseguire i test concordati prima di dichiarare pronto il cambiamento. È la stessa logica di controllo dietro L’AI coding ha bisogno di checkpoint di ambiguità: la flessibilità è utile solo quando i checkpoint sono espliciti.

Usa gate any-order quando la sequenza non è materiale. Se tre fonti read-only contribuiscono alla stessa vista di eleggibilità, il gate può accettare qualsiasi ordine, purché tutte le chiamate richieste siano presenti e nessuna chiamata vietata compaia.

La regola pratica è questa: non mettere sotto gate il ragionamento privato del modello. Metti sotto gate gli impegni osservabili che impattano utenti, dati, costi, compliance o team a valle.

Dove entra nel rituale di release?

Un trajectory gate deve stare prima del rollout, non dopo l’incident review. Inseriscilo nella stessa conversazione di release in cui discutete criteri di accettazione, analytics, osservabilità, permessi e rollback.

Per una nuova funzionalità agentica, PM e tech lead dovrebbero scrivere insieme un gate. Il PM nomina task, promessa utente, rischio di business e outcome inaccettabili. Il tech lead mappa percorso tool atteso, campi di trace, tipo di matching, fixture e soglia. Se la funzionalità dipende da permessi, il gate deve confermare che l’agente non possa raggiungere tool fuori dal suo ruolo. Quel confine operativo è vicino all’argomento di Agenti AI: servono permessi, non accesso totale: un agente va valutato dentro l’autorità che gli è consentito esercitare.

Una buona review di release dovrebbe rispondere a queste domande senza improvvisare:

• Qual è il task più rischioso abilitato da questa release?
• Quali chiamate ai tool devono avvenire?
• Quali chiamate sono vietate?
• Quali parti del percorso possono variare?
• Quale soglia di qualità della risposta deve passare?
• Quale controllo di groundedness o prove deve passare?
• Quali regressioni note sono state rieseguite?
• Quale segnale runtime ci dirà che il gate sta fallendo in produzione?

L’ultima domanda conta perché i gate pre-release non sono guardrail runtime. Riducano la probabilità di rilasciare un comportamento sbagliato, ma la produzione ha comunque bisogno di monitoraggio, trace, code, corsie di escalation e kill switch. Un trajectory gate è il contratto che testi prima della release. I controlli runtime sono il modo in cui applichi e migliori quel contratto dopo la release.

Scrivi un gate prima della prossima release

Non provare a valutare tutto l’agente in una volta sola. È così che i team finiscono con fogli pieni di score vaghi e nessuna decisione di release.

Prima della prossima release, scegli il task più rischioso e scrivi un trajectory gate. Nomina il percorso tool atteso. Scegli matching exact, in-order o any-order. Definisci la varianza tollerata. Aggiungi soglie di groundedness, safety e regressione. Decidi cosa blocca la release e cosa apre solo un’investigazione.

L’obiettivo non è rendere meccanici gli agenti. L’obiettivo è rendere rilasciabile la flessibilità. Se l’agente può prendere molti percorsi validi, dichiara quali percorsi sono validi. Se alcuni passaggi sono obbligatori, rendili visibili. Se alcune chiamate ai tool sono inaccettabili, fai fallire la build prima che siano gli utenti a scoprire il confine.