Il livello di contesto agente per agenti dati affidabili

Perché “interagire con i dati” è ormai il minimo indispensabile, e perché a vincere sarà chi costruisce il contesto, non solo i modelli
Per chi lavora nel mondo dei dati da decenni, il recente interesse verso i “context layer” è al tempo stesso una conferma e un fenomeno affascinante. Non si tratta di concetti nuovi: sono principi fondamentali dell’informatica. Il ritorno dei livelli semantici nasce da una realtà scomoda che molte aziende stanno scoprendo: i modelli sembrano intelligenti, ma continuano a produrre risposte sbagliate con grande sicurezza.
Questo tipo di errore non dipende tanto dai limiti di ragionamento dei modelli, che stanno migliorando rapidamente e continueranno a farlo; il vero collo di bottiglia sarà il contesto giusto.
In una demo controllata, un agente può sembrare brillante. In azienda, invece, deve operare in un contesto in cui i concetti di business sono frammentati, le regole sono implicite, la storia è incompleta e la “verità” è spesso oggetto di interpretazioni diverse tra sistemi.
Il lavoro reale di un analista è multistep, trasversale ai domini e spesso anche politico. I leader aziendali chiedono “perché” e “cosa”, non solo query SQL:
“Individua cosa è cambiato, spiegane le cause e suggerisci le azioni da intraprendere.”
“Confronta due definizioni, risolvi le incongruenze e costruisci una narrazione pronta per il board.”
“Analizza un’anomalia e collegala agli eventi operativi che l’hanno generata.”
È qui che emerge la complessità del contesto aziendale:
Significato frammentato: “Cliente” può avere significati diversi a seconda del sistema.
Manca il perché: I data warehouse registrano lo stato, ma non le decisioni e le discussioni che lo hanno determinato.
Regole implicite: Calendari fiscali, criteri di idoneità, policy di approvazione e metriche vietate sono spesso dispersi e non formalizzati.
Verità in conflitto: Finance e CRM possono essere entrambi “affidabili” e comunque non concordare.
La domanda quindi non è più “Un modello può generare SQL?”, ma “Un agente è in grado di operare nel contesto di significati, policy e storia della tua azienda, e dimostrare come lo ha fatto?”
Definizioni: il vocabolario minimo per agenti affidabili
Partiamo da alcuni concetti chiave:
Modello semantico analitico: Un’interfaccia per l’analisi che definisce metriche, dimensioni ed entità, mappate ai dati fisici, così che gli utenti non debbano conoscere schemi o SQL.
Livello di relazioni e identità (spesso chiamato “ontologia” in ambito enterprise): Una rappresentazione leggibile dalle macchine di concetti, relazioni e regole tra domini, insieme alla risoluzione delle identità, alla gestione dei sinonimi e ai vincoli, per rendere sicura ed esplicita l’integrazione cross-domain. (Può trattarsi di OWL/RDF, di un grafo di join curato o di associazioni tra concetti e data product governati.)
Procedure aziendali: Playbook operativi versionati che definiscono come svolgere il lavoro, inclusi instradamento, approvazioni, eccezioni e applicazione delle policy.
Evidenza e provenienza: La tracciabilità dietro una risposta, incluse le fonti utilizzate, le trasformazioni applicate, la lineage delle fonti dati e il motivo per cui fonti concorrenti sono state accettate o scartate.
Policy e autorizzazioni: Regole applicabili automaticamente che determinano cosa un utente (o un agente che agisce per suo conto) può recuperare, calcolare e condividere.
Semantica e contesto degli agenti: idee consolidate, nuova urgenza
I modelli semantici e le ontologie non sono una novità. Da decenni le aziende cercano di definire significati coerenti attraverso livelli semantici per la BI, Master Data Management (MDM), cataloghi e knowledge graph. Le ontologie si sono evolute anche in ambiti come life sciences e sanità, dove concetti biomedici complessi e terminologie cliniche standardizzate creano naturalmente strutture a grafo. È evidente anche che l’interesse per livelli semantici e ontologie sta crescendo rapidamente (vedi figura 1).

Il momento è coerente, perché queste tecnologie completano gli agenti basati su LLM in modi molto specifici. Ad esempio:
Gli LLM interpretano l’intento e ragionano sull’ambiguità, ma spesso non dispongono del contesto aziendale. I modelli semantici e le ontologie codificano quel contesto in forma riutilizzabile.
Gli output degli LLM sono probabilistici; gli artefatti semantici sono fondati e verificabili.
Storicamente, gli artefatti semantici erano costosi da costruire e soggetti a obsolescenza; le interfacce in linguaggio naturale e gli strumenti per agenti rendono oggi più pratico generarli, curarli e mantenerli aggiornati.
Allo stesso tempo, l’“ontologia” non è l’obiettivo. L’obiettivo è un agente dati di alta qualità. Il linguaggio naturale come interfaccia principale cambia ciò che il sistema deve offrire. Non basta più tradurre una domanda in SQL. L’agente ha bisogno di un livello di contesto che includa semantica, identità, vincoli, policy e provenienza.
Questo è il punto di svolta:
i modelli hanno reso plausibile il passaggio “testo → dati”.
Il contesto degli agenti rende affidabile l’analisi agentica.
Un modello semantico analitico è ideale per fornire analisi affidabili all’interno di un dominio, standardizzando metriche e definizioni. Il lavoro cross-domain diventa affidabile quando l’agente dispone anche di uno spazio esplicito di relazioni, risoluzione delle identità, possibilità di join e vincoli, sia che siano implementati come ontologia formale, grafo di join curato o associazioni tra concetti e oggetti analitici.
L’approccio pratico consiste nel prendere il meglio da ontologie e livelli semantici dove utile, ma ottimizzare per ciò di cui gli agenti hanno realmente bisogno per operare efficacemente nel contesto aziendale.
Un’architettura pratica per agenti dati affidabili
Per arrivare a un’analisi agentica affidabile e multistep servono capacità di ragionamento fondate su semantica governata, relazioni esplicite e processi decisionali verificabili. Per un agente di livello enterprise, è necessario che questi livelli lavorino insieme:

Livello analitico
Il livello analitico fornisce metriche, dimensioni ed entità mappate ai dati fisici. Le definizioni delle metriche (filtri, join e formule) sono centralizzate e riutilizzate nelle diverse esperienze con gli agenti. Le viste semantiche fungono da interfaccia curata e governata verso il livello analitico e garantiscono analisi sicure.
Domande in linguaggio naturale come “ricavi” o “NRR” devono essere ricondotte a una definizione metrica precisa, con i filtri corretti (ad esempio “solo Closed Won”), finestre temporali predefinite e granularità consentite.
Question:
“What is NRR for the last two quarters, split by Enterprise vs Commercial?”
Semantic view usage:
- Metric: NRR (definition includes cohort and renewal logic)
- Dimensions: Quarter, Segment
- Default filters: exclude internal/test accounts
- Time logic: last 2 fiscal quarters
Result:
- NRR by quarter and segment
- Metric definition reference (NRR vX)
- Query parameters used (time window, segment mapping)
Livello di relazioni e identità (ontologia): Concetti e associazioni
Questo livello definisce entità canoniche (come Cliente, Account o Incidente) e le relazioni tipizzate tra di esse, insieme ai collegamenti al mondo dei dati (ID, oggetti semantici, tabelle). Include anche la gestione di sinonimi/alias e il mapping delle identità tra sistemi. Le domande cross-domain richiedono spesso di collegare la stessa entità reale tra sistemi con identificatori diversi (ad esempio ID account CRM vs ID supporto). Questo livello fornisce il mapping e la struttura di relazioni necessari per connettere i domini.
In un esperimento interno abbiamo creato un set di query che richiede più viste semantiche per essere risolto. Abbiamo misurato le prestazioni in termini di accuratezza della risposta finale, latenza totale e numero di chiamate agli strumenti. Abbiamo osservato che l’aggiunta al semplice agente di una “data ontology” in testo (chiavi di join, granularità delle tabelle e indicazioni su cardinalità/fanout) ha migliorato l’accuratezza finale del +20%, ridotto il numero medio di chiamate agli strumenti di circa il 39% e migliorato la latenza end-to-end di circa il 20%, rispetto a una baseline best practice.
Ecco il set di query:
Question:
“Show open escalations for accounts in my book of business and the ARR at risk for each.”
Relationship/identity usage:
- Canonical entity: Customer
- CRM mapping: Customer ↔ CRM.AccountId
- Support mapping: Customer ↔ Support.OrgId
- Relationships:
Customer HAS SupportCases
Customer HAS Contracts (with ARR)
Plan:
1) Find accounts in territory (CRM)
2) Map CRM.AccountId → Customer
3) Map Customer → Support.OrgId → open escalations
4) Map Customer → Contract/ARR (finance semantic object)
5) Join results at Customer grain
Playbook operativi (direttive): procedure e instradamento
Si tratta di un insieme gestito di istruzioni che descrivono come l’agente deve gestire determinati intenti: instradamento verso fonti autorevoli, passaggi obbligatori di disambiguazione e controlli richiesti (ad esempio “il pricing deve utilizzare tabelle certificate” o “il win rate non è consentito”).
Alcune domande richiedono una gestione procedurale coerente. I playbook garantiscono un approccio standard tra utenti e canali (agente, assistente BI, app embedded):
Question:
“What is the price for Product X for a customer in EMEA?”
Playbook: Pricing Inquiry
Steps:
1) Confirm context: customer segment, contract type, effective date
2) Route to authoritative pricing semantic object (certified)
3) Apply region/currency rules for EMEA
4) Return price + effective date + source usedProvenienza ed explainability: cosa è stato utilizzato e come
Questo livello fornisce una traccia ispezionabile di come è stata prodotta una risposta: oggetti semantici selezionati, filtri applicati, join eseguiti e timestamp/freschezza dei dati. In caso di conflitti, può indicare quale fonte è stata scelta e in base a quale regola.
Gli utenti spesso pongono domande di approfondimento come “Come è stato calcolato?” o “Perché è diverso da un altro report?” La provenienza offre una base coerente per rispondere:
Question:
“What is churn for Q4, and why does it differ from last week’s report?”
Provenance returned:
- Metric: Churn_Rate (definition v2.4)
- Filters: excludes involuntary churn
- Time window: FYQ4 (fiscal calendar)
- Sources: billing_events (as-of timestamp), customer_status snapshot
- Differences vs last week:
definition changed v2.3 → v2.4
backfill applied to billing_eventsMemoria di eventi e decisioni: stato e motivazioni
Questo livello archivia tracce di eventi e artefatti decisionali collegati alle entità di business: approvazioni, timeline degli incidenti, eventi di modifica e ticket/thread correlati. Questa memoria può essere integrata sotto forma di analisi (ad esempio il modo corretto di eseguire una join), concetti di business (come una modifica nel calcolo di una metrica), riconciliazione (quando fidarsi di determinate informazioni in presenza di conflitti) e altro ancora. Fornisce quindi evidenze per rispondere alle domande sul “perché”. Molti workflow richiedono spiegazioni basate sulla storia operativa, non solo sullo stato attuale.
Question:
“Why was a 20% discount approved for Acme, and who approved it?”
Evidence retrieved:
- approval workflow record (request, approvers, timestamps)
- approver notes / justification field
- linked deal desk ticket
- relevant policy threshold reference (if applicable)
Answer includes:
- approvers + timestamps
- stated justification
- links/IDs to supporting artifactsPerché non si tratta di prompt engineering
È facile pensare che prompt ben progettati possano sostituire un’agentology strutturata. In pratica, i sistemi basati solo su prompt non reggono alla scala: sono opachi, difficili da verificare e tendono a degradarsi nel tempo.
Un approccio basato su agentology consente invece di creare artefatti solidi e governabili:
Controllo delle modifiche, con rilasci versionati e revisionabili
Auditability, con decisioni di instradamento, join e definizioni spiegabili
Interoperabilità, con una base semantica unica per strumenti BI e agenti
Governance, dove le regole diventano vincoli applicabili e non semplici linee guida
Riutilizzabilità, che consente di modellare i concetti una sola volta e riutilizzarli in contesti diversi senza duplicazioni.
Creazione e manutenzione del contesto degli agenti: come l’AI cambia l’economia
Con l’emergere di agenti potenti come Cortex Code, costruire e mantenere il contesto degli agenti è diventato più accessibile. Storicamente, i livelli semantici aziendali erano complessi per ragioni ben note: sono costosi da creare, diventano rapidamente obsoleti e non evolvono al ritmo del business. Con gli agenti AI, però, il processo può essere molto più semplice: gli agenti possono leggere documenti, knowledge graph, ontologie, conversazioni e altri sistemi di record per costruire il contesto e mantenerlo aggiornato.
Un workflow semplice potrebbe essere:
Partire da un agente e da un livello semantico curato (basato su dashboard esistenti e storico delle query)
Aggiungere livelli di contesto da fonti esistenti: metadati delle tabelle, query storiche e pattern di utilizzo, documentazione, playbook, ontologie e pipeline di codice Questo è già sufficiente per creare un agente molto efficace
Apprendere dai pattern di utilizzo reali
Proporre miglioramenti, inclusi sinonimi, mapping e relazioni mancanti
Mantenere il controllo umano nel processo di approvazione
Ridurre continuamente i costi aumentando al contempo la copertura
Previsioni e considerazioni finali
Ecco alcune evoluzioni che prevediamo:
Le architetture vincenti considereranno il “contesto degli agenti”, e non il modello, come elemento centrale, man mano che i modelli diventano commodity
Gli agenti di maggior successo si concentreranno sul problema di business da risolvere, invece che su un singolo artefatto come l’ontologia
I modelli semantici continueranno a essere il punto di riferimento per metriche governate e analisi affidabili per dominio Con gli agenti come principali consumatori di questo contesto, aumenterà la pressione per mantenere questi livelli aggiornati, allineati e leggibili dalle macchine, trasformandoli da documentazione statica a risorse dinamiche e attivamente gestite
Si assisterà a maggiori investimenti nella generazione e nell’evoluzione continua dei livelli di contesto degli agenti, alimentati da agenti AI come Cortex Code
Con l’adozione su larga scala, emergeranno standard per favorire l’interoperabilità tra piattaforme e rendere questi livelli più facilmente interpretabili e utilizzabili dagli LLM in modo coerente tra strumenti ed ecosistemi Iniziative come Open Semantic Interchange (OSI) vanno proprio in questa direzione
Nel complesso, prevediamo un rinnovato interesse per metadati e cataloghi Questi livelli saranno sempre più gestiti congiuntamente da persone e agenti
Continua la conversazione
Se sei un data executive che sta sviluppando agenti con esigenze di contesto complesso e orchestrazione cross-domain, ti invitiamo a esplorare le nostre ultime innovazioni:
- Semantic views: Scopri come costruire le basi per un’orchestrazione cross-domain.
- Snowflake Intelligence: Scopri come integriamo guardrail di business in un livello di intelligence unificato.
Cerchiamo partner di design strategici per collaborare alla prossima generazione di livelli semantici avanzati e Snowflake Intelligence. Se ti interessa sviluppare e iterare sui Cortex Agents insieme a noi, compila questo breve modulo per verificare se il tuo caso d’uso è adatto al programma.



