Context layer
Il layer condiviso di definizioni metriche, semantica di business e lineage che permette a umani e agenti AI di ottenere risposte affidabili dai dati.
Il context layer è il layer condiviso di contesto per i dati strutturati: definizioni delle metriche, semantica di business, lineage e documentazione, organizzati in modo che sia gli umani sia gli agenti AI possano porre domande di business e ricevere risposte affidabili. Il termine e la tesi sono di Tristan Handy, fondatore di dbt Labs e presidente della combinata Fivetran + dbt Labs, in un’intervista del luglio 2026 al Data Analysis Journal di Olga Berezovsky: il contesto è “il prossimo problema dei dati”, perché i modelli AI migliorano più in fretta delle informazioni che le aziende sanno fornire loro.1
Il problema che risolve
Un agente può generare una query SQL sintatticamente valida, ma non sa: quale campo di revenue è quello di cui la finanza si fida, se un abbonamento cancellato resta attivo fino a fine periodo, quali account di test vanno esclusi, perché due dashboard usano definizioni diverse di “customer attivo”. Sono problemi di conoscenza organizzativa, non di SQL, e il context layer li affronta dando all’agente la definizione giusta al momento giusto.1
I due lavori: accuratezza e costo
Handy assegna al context layer due compiti. Il primo è l’accuratezza: fornire all’agente definizioni e dati fidati. Il secondo è il costo: ridurre la quantità di contesto irrilevante che l’agente processa. L’accesso grezzo non è contesto efficiente (“raw access is not the same as efficient context”): collegare un agente direttamente a un sistema come Gong e fargli leggere i transcript delle chiamate costa migliaia di token per chiamata, mentre caricare le chiamate nel warehouse e pulirle e riassumerle con dbt produce un dataset piccolo e interrogabile. L’obiettivo è la quantità più piccola di contesto fidato necessaria a rispondere.1
Il parallelo con la storia dell’analytics
Per Handy il ciclo è già stato visto: dare a tutti accesso alle tabelle di produzione non ha mai creato self-service analytics; sono serviti modelli puliti, definizioni condivise, accesso governato. L’AI ripete lo stesso ciclo più in fretta e a costo più alto: gli agenti non dovrebbero ricostruire ogni sistema di record da zero a ogni domanda.1
Agents Schema: la materializzazione
La proposta operativa, annunciata con la fusione dbt-Fivetran del giugno 2026, si chiama Agents Schema: uno standard open source per memorizzare definizioni di metriche, modelli semantici, lineage e documentazione di business in tabelle SQL che gli agenti possono interrogare. Il contesto smette di essere una feature nascosta dentro un singolo strumento di BI o AI e diventa infrastruttura, la stessa scommessa con cui dbt aveva reso infrastruttura le pratiche dell’analytics engineering.1
Una versione convergente della stessa idea viene dall’interno di Meta: Shridhar Iyer descrive l’evoluzione dello stack dati in tre passi, prima tipizzare tutto (schematize), poi unificare motori e catalogo (unify), infine aggiungere il layer semantico e di conoscenza per l’AI (add meaning).2
Voci correlate
- Analytics engineering — il ruolo che si espande dal codice al contesto
- Data warehouse — il sistema su cui il context layer si appoggia
- The post-literate engineer — il paradosso: infrastruttura iper-documentata, umani che leggono meno
- Data engineer come product owner — chi possiede il prodotto-dato nell’era degli agenti
- Portale: Data engineering
Bibliografia e sitografia
- Olga Berezovsky, When AI Builds the Data Models, What Happens to Analytics Engineering? (intervista a Tristan Handy), Data Analysis Journal, numero 326, 29 luglio 2026.
- Data lessons from inside Meta (intervista a Shridhar Iyer), The Analytics Engineering Podcast, dbt Labs, 30 luglio 2026.