Smetti di eseguire nuovi benchmark sui modelli e inizia a osservare il tuo agente mentre cerca di annullare un abbonamento. Il divario tra queste due attività è il luogo in cui i sistemi in produzione falliscono. Un test a turno singolo può dirti se una risposta suona piacevole. Non può dirti se l'agente ha appena rimborsato il cliente sbagliato, è entrato in un loop quattordici volte contro un'API di calendario o ha deciso di saltare completamente il controllo frodi. Il testo è la cosa meno pericolosa che un agente produce. I rischi reali si nascondono negli strumenti che tocca, nei dati che muta e nei momenti in cui avrebbe dovuto chiedere aiuto ma ha continuato ad andare avanti.

Perché i benchmark testuali falliscono in produzione

Gli alti punteggi nei benchmark standard sono diventati una forma fuorviante di conforto. Un agente che scrive prosa elegante potrebbe comunque rappresentare un rischio operativo. Quando il tuo sistema prenota appuntamenti, modifica record nel database o apre ticket di supporto, il testo generato è solo la superficie visibile del workflow. Sotto la superficie, l'agente prende decisioni concrete su quale endpoint colpire, quale payload inviare e quando fermarsi. Può scalare le classifiche di comprensione del testo pur costandoti denaro a causa di doppie prenotazioni di risorse, mutazioni della riga sbagliata o fuga di stati sensibili in un file di log. Devi verificare la meccanica del lavoro, non solo la rifinitura dell'output. Se un agente riesce a ottenere un buon punteggio in un test QA offline ma fallisce comunque il tuo workflow entrando in loop o usando impropriamente uno strumento, la tua valutazione si sta concentrando sui segnali sbagliati.

Mappare le cinque dipendenze

Il team di Van Data Team inizia ogni valutazione mappando cinque specifici punti di controllo. Questo cambia completamente la questione. Smetti di chiederti se un modello sia più intelligente di un altro. Inizi a chiederti se l'agente sia effettivamente in grado di completare un compito in produzione sotto i tuoi vincoli reali.

Risultati aziendali. Definisci cosa significa "fatto" in termini di dollari e impatto sul cliente. Un compito non è completo solo perché l'agente ha emesso un riepilogo. È completo quando il record dell'inventario è accurato, l'appuntamento è confermato e il cliente ha ricevuto un numero di tracciamento valido.

Stato mutabile. Sappi esattamente cosa è consentito cambiare all'agente. Quali tabelle, quali stati, quali flag dell'account? Se l'agente può emettere rimborsi, riprogrammare lavori o aggiornare gli indirizzi di fatturazione, devi fare l'inventario di ogni campo che tocca.

Permessi degli strumenti. Sii esplicito su quali endpoint API e funzioni sono in ambito. Un agente con accesso a uno strumento di ricerca, uno di scrittura e uno di notifica farà confusione se i confini sono sfumati. Mappa ogni permesso a una specifica necessità operativa.

Recupero dai guasti. Decidi cosa succede quando l'API del calendario va in timeout, restituisce un errore 500 o restituisce un JSON malformato. L'agente non deve andare nel panico, allucinare un messaggio di successo o riprovare all'infinito. Ha bisogno di un percorso di fallback chiaro.

Gate di revisione umana. Identifica i momenti in cui una persona deve dare l'approvazione prima che l'agente proceda. Questo non è un segno di debolezza dell'automazione. È una valvola di sicurezza per i cambiamenti ad alto impatto e una fonte di etichette ground-truth per le tue rubriche.

Come appare un vero piano di valutazione

Una volta mappate le dipendenze, hai bisogno di un piano di valutazione che rispecchi il disordine della produzione. Le metriche da slide-deck non ti aiuteranno in questo caso.

Crea set di test basati su reali fallimenti in produzione, non su banche di domande sintetiche. Se il tuo agente ha fallito martedì scorso confondendo due SKU simili, quella stessa confusione dovrebbe diventare un caso di test permanente. La tua suite di valutazione dovrebbe crescere ogni volta che un incidente ti insegna qualcosa di nuovo.

Scrivi rubriche che definiscano il completamento con successo in termini operativi. Criteri vaghi come "utile" o "accurato" sono inutili. Una rubrica utile stabilisce che un compito di rimborso ha successo solo se viene fatto riferimento all'ID di pagamento originale, l'importo corrisponde alla richiesta, viene messa in coda un'e-mail di conferma e l'ID della transazione viene registrato nei log.

Definisci specifiche di tracciamento (trace specs) per le chiamate agli strumenti e i tentativi di riproporre (retries). Hai bisogno di osservabilità su ciò che l'agente ha pianificato, ciò che ha effettivamente chiamato, quante volte ha riprovato e se la strategia di retry era appropriata. Una traccia senza granularità a livello di strumento è solo un bel racconto.

Stabilisci policy su quando avvisare un essere umano. L'agente dovrebbe conoscere i propri limiti. Se una richiesta supera una soglia monetaria, fa riferimento a un account VIP o incontra uno stato che non ha mai visto prima, dovrebbe effettuare un'escalation invece di tirare a indovinare.

Install release gates to block bad model upgrades. A new model is only an upgrade if it improves your specific outcomes. If it hallucinates tool arguments more often, increases latency, or introduces new safety risks, it does not ship. The gate keeps production stable even when the base model vendor ships a new version.

Runtime Grading: Watching the Agent Work

Anthropic has been pushing the industry to move beyond offline tests toward runtime grading. Instead of judging a transcript after the fact, runtime grading lets a system judge the agent's work while the task is still in flight. This creates a chance to catch errors before they harden into real problems.

Adding a grader costs tokens and latency. You cannot afford to grade every tiny step. The placement of each grader is a design decision. Put them where the mistakes are expensive. The most valuable checkpoints sit just before committing a state change to a database, just before capturing a payment, and just before sending a message to a customer. These are the moments where a bad decision becomes an irreversible action.

Watch out for a specific blind spot. If the same model performs the work and also grades the work, it may miss the same mistakes. The reasoning that produced an error can easily rationalize that error away during review. For high-impact tasks, keep human review inside the loop. Let people validate the grader's own judgment, especially when money or customer trust is on the line.

The goal here is operational control. Connect your incident data, your task rubrics, and your runtime traces into one feedback cycle. Evaluate the whole path: the plan, the tool use, the recovery behavior, and the final result. Use offline tests to catch known, reproducible errors before release. Use runtime traces to find the new failures you did not anticipate. Use human review to discover where your rubrics are naive and need tightening.

So ask yourself: where would you put a runtime grader in your workflow? Before a tool call, after a tool call, or only before a risky change? Most teams start too broad, grading everything, and then grind to a halt under the cost. Start narrow. Pick the one action that would hurt the most if it went wrong. Put a grader there first.

Start With One Expensive Mistake

Operational evaluation is not a research exercise. It is a way to sleep better once the agent is live. You do not need a perfect framework on day one. You need a single, well-defined workflow, a rubric written in plain business terms, and a grader placed at the exact moment where an error becomes expensive. Get that right, and you have a foundation you can actually trust.

If you want to dig deeper into agent evaluation and runtime grading with a community of practitioners, you can find the GyaanSetu learning community at https://t.me/GyaanSetuAi.