Prodotto e tecnologia

Il livello di contesto agente per agenti dati affidabili

Image of Snowflake AI Data Cloud icons and grid and bar charts

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).

Chart of Google Trends for Semantic Layer and Ontology showing a large spike in late 2025.
Figure 1: Google trends show rising interest in “semantic views” and “ontologies.”

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:

Diagram showing Agent Context Layers: Semantic models, relationship and identity, operational playbooks, policy & entitlements, provenance explainability, event & decision memory
Figure 2: Layers needed to create context for an enterprise-grade agent.

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 used

Provenienza 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_events

Memoria 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 artifacts

Perché 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:

  1. Partire da un agente e da un livello semantico curato (basato su dashboard esistenti e storico delle query)

  2. 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

  3. Apprendere dai pattern di utilizzo reali

  4. Proporre miglioramenti, inclusi sinonimi, mapping e relazioni mancanti

  5. Mantenere il controllo umano nel processo di approvazione

  6. 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:

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.

Ebook

Top BI Trends and Strategies for 2026

Scopri i principali trend e strategie della BI, con insight di esperti di AWS, Sigma, Snowflake, Tableau (Salesforce) e Microsoft.
Condividi articolo
Data Executive's Guide to Effective AI Report Cover

Experience the future of enterprise data and intelligence

Subscribe to our blog newsletter

Get the best, coolest and latest delivered to your inbox each week

Where Data Does More

  • prova gratuita di 30 giorni
  • nessuna carta di credito
  • annulli quando vuoi