Una discovery riuscita non produce entusiasmo, produce criteri: enunciati che qualcuno potrà verificare fra tre mesi senza chiamarti. Anthropic non pubblica una metodologia di discovery né modelli di SLA, e conviene dirlo apertamente al cliente invece di spacciare una prassi generica per prescrizione del fornitore. Quello che la documentazione offre è più utile di un modulo: criteri di successo, rubriche valutabili, la soglia oltre la quale conviene complicare l’architettura e i numeri reali di capacità su cui costruire una promessa sostenibile.

Prima domanda: serve davvero un agente?

La prima uscita di una discovery seria è spesso un «no». «Building effective agents» consiglia di cercare la soluzione più semplice possibile e di aumentare la complessità solo quando serve, «This might mean not building agentic systems at all», perché «for many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough». La regola che porti in riunione è la stessa pagina a formularla: aggiungere complessità «only when it demonstrably improves outcomes».

C’è anche il costo da dichiarare subito: «Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense». I workflow offrono prevedibilità e coerenza su compiti ben definiti; gli agenti servono dove servono flessibilità e decisione guidata dal modello su larga scala. Sono due impegni economici diversi, e vanno messi per iscritto prima del progetto pilota, non dopo il primo consuntivo.

Trasformare i desideri in criteri misurabili

La guida allo sviluppo dei test dà la griglia: criteri specifici, misurabili, raggiungibili e pertinenti. La differenza fra «output sicuri» e «meno dello 0,1 per cento degli output su 10.000 prove segnalati come tossici dal filtro di contenuto» non è pedanteria: è la sola versione che qualcuno potrà contestare o confermare. La stessa guida ricorda che «Most use cases need multidimensional evaluation along several success criteria»: accuratezza, tossicità, gravità dell’errore residuo, tempo di risposta convivono nello stesso accordo.

Le rubriche di Managed Agents mostrano lo stesso principio in forma eseguibile. Quando definisci un outcome, la piattaforma assegna un valutatore che giudica l’artefatto rispetto a una rubrica, in una finestra di contesto separata per non essere influenzato dalle scelte implementative dell’agente. Il consiglio su come scrivere i criteri è la miglior regola di stesura dei requisiti che troverai in tutta la documentazione: usa criteri espliciti e valutabili, «The CSV contains a price column with numeric values» invece di «The data looks good», perché criteri vaghi producono valutazioni rumorose.

user.define_outcome      descrizione + rubrica (testo o file), max_iterations
                         opzionale: default 3, massimo 20
esiti possibili          satisfied | needs_revision | max_iterations_reached | failed
"failed"                 la rubrica non si applica ai deliverable, per esempio
                         quando descrizione e rubrica si contraddicono

Quell’ultima riga è un regalo per la discovery: un requisito che contraddice l’obiettivo dichiarato non è un dettaglio da chiarire in corso d’opera, è una condizione che fa fallire la valutazione.

Il materiale grezzo sono i fallimenti reali

I requisiti migliori non si raccolgono in astratto: si estraggono da ciò che oggi va storto. La guida Anthropic sulle valutazioni per agenti raccomanda di partire piccolo — «20-50 simple tasks drawn from real failures is a great start» — e di farlo presto, perché «Evals are especially useful at the start of agent development to explicitly encode expected behavior». Codificare il comportamento atteso è, letteralmente, raccolta di requisiti.

Sul come condurre l’intervista, c’è uno strumento spesso ignorato. Claude pone domande di chiarimento tramite lo strumento AskUserQuestion, con una a quattro domande per chiamata e due a quattro opzioni ciascuna; la documentazione osserva che sono particolarmente frequenti in plan mode, «This makes plan mode ideal for interactive workflows where you want Claude to gather requirements before making changes». Usare l’agente stesso per esplorare il sistema esistente e proporre le domande che non sapevi di dover fare è una tecnica di discovery, non una scorciatoia — a patto di verificare le risposte con chi conosce il dominio.

I requisiti non funzionali che nessuno porta spontaneamente

Qui si separa l’architetto dal presentatore. Sui limiti di frequenza, la documentazione è esplicita: «All limits described here represent maximum allowed usage, not guaranteed minimums». Limiti in richieste al minuto e token in ingresso e in uscita al minuto, definiti per organizzazione e per modello, con caching che alleggerisce la contabilità perché sui modelli più recenti i token letti dalla cache non contano verso il limite di ingresso. Chi promette un carico di picco senza aver letto questa pagina promette a nome di qualcun altro.

Sulla capacità garantita, il fatto scomodo va detto per primo: gli impegni di Priority Tier «are no longer available for purchase», restano validi per chi li ha già e per capacità garantita si passa dal team commerciale. Il numero che circola nelle presentazioni — Priority Tier «targets 99.5% uptime with prioritized computational resources» — descrive quindi un contratto esistente, non un’opzione che puoi promettere oggi in una discovery.

Chiudi con la parte umana. Le organizzazioni che riescono nella trasformazione, racconta Anthropic, «start with concrete business problems» e «measure what matters»: guadagni di produttività, tempo risparmiato, qualità. Metriche concrete sono ciò che trasforma una demo memorabile in un caso difendibile davanti a chi firma.