Anthropic ha ragione: l'agentic analytics non è text-to-SQL. Ecco come abbiamo costruito lo stack intorno.

Il 3 giugno 2026 Anthropic ha pubblicato uno dei resoconti di produzione più onesti sull'agentic analytics che abbia letto: How Anthropic enables self-service data analytics with Claude. Jose Parreño ne ha scritto un'analisi eccellente, incentrata su un punto che vorrei più team si tatuassero sulla roadmap: collegare un LLM al database e fargli domande non è una strategia di analytics.

Parreño chiama il risultato di questa scorciatoia «analytics slop»: risposte sicure di sé, ben formattate, plausibili, che nessuno ha verificato. I numeri di Anthropic spiegano perché. Senza il sistema intorno, Claude non è andato oltre il 21% nelle loro valutazioni interne di analytics. Con il sistema, l'accuratezza è salita oltre il 95% complessivo e intorno al 99% in alcuni domini. Il modello non è cambiato. È cambiato lo stack intorno.

Questa distinzione ci interessa perché è esattamente la scommessa che abbiamo fatto costruendo InsightNarrator. Siamo una piattaforma di Voice of the Customer e CX analytics, il che significa che il nostro «warehouse» contiene i dati più disordinati che esistano: verbatim aperti dei sondaggi, recensioni, ticket di assistenza, menzioni social. Testo non strutturato in cui l'ambiguità non è un caso limite, è la materia prima. Leggere il post di Anthropic è stato come leggere la descrizione dell'architettura a cui eravamo già arrivati da un'altra direzione. Questo articolo sovrappone il loro stack, livello per livello, a ciò che abbiamo costruito, con casi concreti dal nostro prodotto.

La tesi di Anthropic in 60 secondi

Anthropic individua tre modalità di errore che spiegano la maggior parte delle risposte sbagliate:

• Ambiguità di concetti ed entità. «Utenti attivi» o «ricavi» possono corrispondere a decine di campi plausibili. L'agente ne sceglie uno. Spesso è sbagliato, e sembra comunque professionale.
• Dati obsoleti. Schemi, definizioni e regole di business cambiano; la procedura corretta di ieri diventa silenziosamente sbagliata.
• Errore di recupero. La risposta giusta esiste, ma lo spazio di ricerca è così ampio che l'agente costruisce con sicurezza su un risultato quasi giusto.

La loro risposta è uno stack a quattro livelli: fondamenta dei dati (dataset canonici, metadati come prodotto di prima classe), fonti di verità (prima il semantic layer, poi lineage, documenti di riferimento curati), skill (playbook procedurali, non solo prompt) e validazione (eval offline, revisione avversariale, note di provenienza, cicli di correzione). L'SQL viene a valle di tutto questo.

Ecco ora lo stesso stack, così come esiste oggi in InsightNarrator.

Livello 1. Fondamenta dei dati: un dataset canonico, non quaranta candidati

L'errore più comune per Anthropic era l'agente che associava un concetto alla tabella sbagliata tra quasi duplicati. La soluzione: meno modelli logici, governati più rigorosamente.

Il nostro equivalente parte dall'ingestione. Che il feedback arrivi da una piattaforma di sondaggi, da un connettore di recensioni o da un upload CSV, viene normalizzato in un unico formato di dataset canonico, con statistiche per colonna e un report automatico sulla qualità dei dati (completezza, intervalli validi, anomalie) prima che qualsiasi agente lo tocchi. Un agente che chiede dei «commenti dei detrattori» non si trova davanti quaranta tabelle plausibili, ma un unico dataset governato con una granularità documentata: una riga, un feedback del cliente.

È data engineering vecchia scuola, e Anthropic dice esplicitamente che vale ancora. Per il testo non strutturato andremmo oltre: se la tua materia prima è il linguaggio, un dataset canonico e con la qualità verificata è l'unica cosa che separa l'agente dal garbage in, garbage out su larga scala.

Livello 2. Fonti di verità: il Knowledge Pack e documenti di riferimento scritti alla maniera di Anthropic

È il livello in cui la somiglianza è quasi inquietante.

Gli agenti di Anthropic sono obbligati per struttura a consultare prima un semantic layer governato; l'SQL grezzo è il ripiego. Anthropic avverte anche di non lasciare che sia l'LLM a inventare il semantic layer: le definizioni delle metriche generate automaticamente «codificavano proprio le ambiguità che cercavamo di eliminare». La raccomandazione: lascia che Claude scriva la bozza della documentazione, lascia la definizione alle persone.

Il Knowledge Pack di InsightNarrator è esattamente quel contratto. Ogni workspace ha una knowledge base curata di voci tipizzate:

• metrics: metriche di business approvate con le loro formule SQL esatte
• glossary: cosa significano qui «NPS», «churn» o «cliente attivo»
• rules: vincoli che l'agente deve rispettare («escludi le risposte di test», «il mese scorso è l'ultimo mese solare completo»)
• caveats: trappole dei dati documentate
• example queries: coppie di riferimento domanda-SQL
• reference docs: documentazione per ogni dataset

Due meccanismi rispecchiano direttamente le indicazioni di Anthropic. Primo: quando un dataset finisce l'elaborazione, un LLM scrive in automatico la bozza del suo documento di riferimento, con una struttura fissa di Business Context, Entity Grain, Standard Hygiene Filter, Dimensions, Key Columns, Gotchas. Siamo arrivati a queste sezioni in modo indipendente; il post di Anthropic usa quasi alla lettera lo stesso schema. Secondo, ed è il punto su cui Anthropic insiste, la bozza resta fuori dal contesto dell'agente finché una persona non la approva. Le voci seguono un ciclo di vita draft → approved / needs_review. Il modello scrive la documentazione; il significato appartiene alla persona.

E la difesa contro l'obsolescenza: quando lo schema di un dataset cambia, il suo documento di riferimento viene rigenerato e marcato needs_review. Il documento può disallinearsi per un giorno, ma non può restare sbagliato in silenzio; c'è sempre un punto di controllo visibile, in mano a una persona.

Livello 3. Skill: tool pack e playbook, non prompt eroici

Il salto di accuratezza più grande per Anthropic, dal 21% a oltre il 95%, è venuto dalle skill: conoscenza procedurale su come lavorare, non solo su quali dati esistono.

Il nostro agente, Scoty, segue lo stesso principio. Non riceve una connessione grezza al database e una preghiera. Riceve tool pack dedicati per le operazioni comuni (esplorazione dei dataset, risultati delle analisi, topic e rischi) che restituiscono risultati strutturati e governati. L'SQL libero esiste, ma come ripiego esplicitamente sconsigliato: in sola lettura, limitato a una allowlist di tabelle dati, usato solo quando nessun tool dedicato copre la domanda. È lo schema di Anthropic «prima il semantic layer, SQL grezzo come ripiego», imposto a livello di descrizione dei tool invece che per convenzione.

Per il lavoro più approfondito c'è una pipeline multi-agente: nove agenti specializzati (Data, Domain, Sentiment, Themes, Trends, Segments, Risk, Synthesis e un agente QA finale), ciascuno con un budget di iterazioni limitato, che si passano i risultati. Gli oltre 30 tipi di analisi predefiniti (driver analysis, segnali di churn, estrazione dei temi e così via) sono, nel vocabolario di Anthropic, playbook di analisi codificati: la procedura di un senior CX analyst, resa riproducibile.

Livello 4. Validazione: revisione avversariale e una nota di provenienza su ogni risposta

La validazione online di Anthropic si basa su due idee che abbiamo implementato con lo stesso spirito.

Revisione avversariale. Prima che una risposta venga consegnata, un passaggio di revisione opzionale mette in discussione l'SQL della bozza e le sue ipotesi: la stessa disciplina del «non autocertificarsi» del sub-agente obbligatorio sql-reviewer di Anthropic, che ha portato loro un +6% di accuratezza a un costo reale di latenza. Noi l'abbiamo resa un interruttore, così gli utenti scelgono domanda per domanda se la posta in gioco giustifica il passaggio in più. E l'agente QA alla fine della pipeline svolge lo stesso ruolo per le analisi lunghe: i risultati vengono messi in discussione prima di essere salvati.

Nota di provenienza. Ogni risposta di Scoty porta con sé un registro di provenienza salvato: da quale livello di fonte attinge (knowledge_pack o raw_exploration), un livello di confidenza derivato da quel livello, l'SQL effettivamente eseguito con il numero di righe e i tempi, e quanto sono aggiornati i dati sottostanti. L'impostazione di Anthropic è esattamente quella giusta: non rende la risposta più corretta, dice a chi legge quanto fidarsi. Una risposta «raw exploration, aggiornamento sconosciuto» è un segnale per verificare prima di inoltrarla al management. In un contesto CX, dove un numero sbagliato può indirizzare un budget, quella nota non è decorazione.

Tre casi concreti

Caso 1. ABSA sui verbatim NPS: significato governato per il testo non strutturato. Un team CX esegue una Aspect-Based Sentiment Analysis su 40.000 verbatim di sondaggi. L'errore che Anthropic chiama ambiguità dei concetti qui ha un cugino più insidioso: un LLM senza vincoli inventa categorie di aspetti, plausibili, incoerenti e diverse a ogni esecuzione, e il confronto tra un'ondata e l'altra perde senso. La nostra risposta è la tassonomia curata: il modello può assegnare solo categorie ed etichette che esistono nella tassonomia approvata del workspace, mai inventate liberamente. La tassonomia è il semantic layer del testo. Le definizioni appartengono alle persone; il modello mappa un linguaggio disordinato su un significato governato. Quando arriva l'ondata 2, «Prezzo» significa ancora «Prezzo».

Caso 2. C-Risk sui ticket di assistenza: trovare dove nasce il churn. Un'organizzazione di assistenza applica il Complaint-Risk scoring alle conversazioni dei ticket. I fattori di rischio vengono dalla tassonomia governata, incrociati con il sentiment per categoria e sottocategoria, così invece di un generico «sentiment negativo in aumento del 12%» il team vede che Fatturazione → Ritardo nel rimborso è la cella specifica che questo mese genera reclami ad alto rischio, con livelli di gravità calcolati dai dati, non a sensazione. Il risultato alimenta le dashboard e, poiché ogni risultato di analisi finisce nella Libreria condivisa, diventa una prova che l'analisi successiva può citare invece di uno screenshot nelle slide di qualcuno.

Caso 3. Scoty risponde a «cosa sta spingendo i detrattori in questo trimestre?». Uno stakeholder fa a Scoty il tipo di domanda che di solito produce analytics slop. Scoty consulta prima il Knowledge Pack: il documento di riferimento approvato per il dataset NPS, la definizione approvata di «detrattore», la regola del workspace su cosa significa «questo trimestre». Solo allora interroga i dati. La risposta torna marcata knowledge_pack, con confidenza alta, con l'SQL esatto e l'aggiornamento dei dati allegati. Se la knowledge base non copre la domanda, ripiega sulla raw exploration, e la nota di provenienza lo dice, come a dire a chi legge: verificami prima di ripetermi. Quell'onestà è il punto.

Dove siamo onesti sul divario

Il post di Anthropic è anche una checklist utile di ciò che non abbiamo finito. Un harness formale di eval offline (coppie domanda/risposta ancorate alla ground truth, eseguite in CI a ogni modifica delle skill) è nella nostra roadmap, non in produzione. La raccolta automatica delle correzioni (trasformare «no, quella è la tabella sbagliata» in una patch della knowledge base) oggi è un flusso di lavoro umano, non un agente pianificato. Preferiamo dirlo chiaramente piuttosto che rivendicare un 95% finito. La storia di drift della stessa Anthropic, un 95% sceso al 65% in un mese senza manutenzione, è il miglior argomento per dire che questi cicli non sono facoltativi, e sta orientando la nostra roadmap come ha orientato la loro.

In sintesi

La frase più utile del post di Anthropic è la più semplice: il text-to-SQL è una capacità di esecuzione, non il prodotto. Il prodotto è il sistema che riduce l'ambiguità a un significato governato prima che la query venga scritta, rende trovabile la risposta giusta e segnala quando l'una o l'altra è diventata obsoleta.

Per i dati di Voice of the Customer quel sistema non è un nice-to-have. È la differenza tra un'AI che ti dice cosa hanno detto i tuoi clienti e una che ti racconta una storia che per caso suona bene. Abbiamo costruito InsightNarrator come la prima.

Se ti occupi di VoC o CX e vuoi vedere com'è un'agentic analytics governata sui tuoi dati di feedback, prova InsightNarrator.

Riferimenti

• How Anthropic enables self-service data analytics with Claude, Anthropic, 3 giugno 2026
• Jose Parreño, Anthropic is telling you that Agentic Analytics is not just text-to-SQL, Medium
• Building effective agents, Anthropic

Pubblicato per la prima volta su LinkedIn il 4 agosto 2026.