Construindo uma base de analytics agêntica no lakehouse

Autoria: Databricks · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Building an Agentic Analytics Foundation on the Lakehouse · Canal: Databricks · 12:22 · Assistir no YouTube

Tópicos: Agentes de IA, Dados, bancos de dados e embeddings, Privacidade e proteção de dados

Resumo

O vídeo apresenta uma arquitetura para analytics agêntica na plataforma Databricks, com foco em precisão, acesso seguro e escalabilidade. A Genie ontology combina semântica definida no Unity Catalog com conhecimento inferido de padrões de uso, ajudando os agentes a interpretar conceitos de negócio e calcular métricas corretamente. O exemplo da empresa fictícia Brick Commerce mostra como agentes Genie, Genie One e ferramentas de terceiros podem consultar dados governados. O Unity Gateway complementa a arquitetura com controles de acesso, políticas, limites de uso e proteções para modelos.

Pontos-chave

Agentes sem contexto semântico e controles adequados podem produzir respostas incorretas, acessar dados indevidamente ou enfrentar problemas de escala.
A base proposta organiza dados tratados em camadas e enriquece os ativos com semântica por meio da Genie ontology.
Domínios e subdomínios ajudam a organizar os ativos; páginas definem conceitos de negócio e metric views especificam cálculos.
A Genie ontology reúne semântica explícita do Unity Catalog e conhecimento aprendido a partir dos padrões de uso dos dados.
Agentes Genie atendem a perguntas dentro de um domínio, enquanto Genie One pode combinar fontes confiáveis entre domínios.
A integração via MCP permite que ferramentas de terceiros usem o mesmo contexto semântico.
O Unity Gateway governa o acesso a modelos com políticas, limites de uso, observabilidade de custos e guardrails.
O compute gerenciado da Databricks dá suporte a consultas analíticas em tempo real e à escala.

Capítulos

Início	Capítulo	Resumo
00:00	O que é analytics agêntica	O apresentador descreve os riscos de precisão, acesso e escala e apresenta os pilares da base proposta.
03:05	Arquitetura e dados da demonstração	A arquitetura é ilustrada com dados da empresa fictícia Brick Commerce, organizados em camadas no lakehouse.
05:07	Semântica de negócio na Genie ontology	Páginas e metric views definem conceitos e cálculos, complementados por conhecimento aprendido dos padrões de uso.
07:13	Agentes Genie e raciocínio entre domínios	A demonstração mostra agentes específicos de domínio e Genie One usando ativos confiáveis para responder a perguntas.
09:18	Integração e governança de modelos	Ferramentas de terceiros acessam o contexto semântico via MCP, enquanto o Unity Gateway aplica políticas e guardrails.
11:20	Síntese e próximos passos	O vídeo relaciona a ontology à precisão, a governança ao acesso seguro e o compute gerenciado à escala.

Citações

Sem a base certa, esses agentes só produzem respostas erradas com mais rapidez e confiança. — 00:00

Você pode pensar nelas como uma wiki governada para os conceitos do seu negócio. — 05:07

Ele não precisa improvisar. — 06:10

O Unity Gateway é o painel único para governar o acesso aos seus modelos de linguagem. — 11:20

Conceitos e entidades

Databricks (empresa): Plataforma apresentada no vídeo para construir uma base de analytics agêntica sobre o lakehouse.
agentic analytics (conceito): Abordagem em que agentes raciocinam sobre dados, fazem consultas e podem executar ações.
Genie ontology (conceito): Camada que combina semântica de negócio definida explicitamente e conhecimento aprendido a partir do uso dos dados.
Unity Catalog (ferramenta): Componente usado para governar os dados e definir semânticas de negócio.
Unity Gateway (ferramenta): Camada que governa o acesso a modelos com políticas, controles, limites de uso e guardrails.
Genie One (ferramenta): Interface que coordena agentes Genie e ativos confiáveis para responder a perguntas que podem atravessar domínios.
Genie agents (ferramenta): Interfaces conversacionais configuradas para responder a perguntas dentro de um domínio específico.
MCP (conceito): Protocolo mencionado como meio de conectar agentes e ferramentas de terceiros à base semântica.
Metric Views (conceito): Ativos que definem medidas, campos, junções e filtros para calcular métricas de forma consistente.
OntoRank (conceito): Algoritmo citado como mecanismo para ponderar a autoridade dos ativos consultados pela Genie ontology.
Brick Commerce (empresa): Empresa fictícia de comércio eletrônico usada para demonstrar a arquitetura.
Justin Kolb Peck (pessoa): Arquiteto de soluções sênior da Databricks que apresenta o vídeo.

Tradução completa (pt-BR)

00:00 [música] >> Toda organização quer agents de IA que raciocinem sobre seus dados. Mas, sem a base certa, esses agents apenas produzem respostas erradas mais rapidamente e com mais confiança. Neste vídeo, vou mostrar como criar uma base robusta de analytics agêntica na plataforma Databricks, que garante que seus agents sejam precisos, seguros e estejam prontos para escalar. Olá, meu nome é Justin Kolb Peck. Sou arquiteto sênior de soluções aqui na Databricks. Vamos começar. Então, o que é analytics agêntica? Analytics agêntica é a próxima evolução da

00:32 pilha moderna de dados. Estamos passando de dashboards que as pessoas leem para agents capazes de raciocinar, consultar e agir, e a semântica é absolutamente fundamental para que essa mudança funcione. Se você já trabalhou com dados, já viu esse problema. As equipes de dados estão sobrecarregadas, e cada pergunta para a qual alguém na organização precisa de uma resposta vira um novo chamado. Felizmente, os agents podem eliminar esse gargalo, mas somente se a base estiver correta. Porque, quando você deixa agents à solta nos dados corporativos sem as proteções adequadas, expõe você e sua organização a três

01:03 riscos reais. O primeiro é a precisão. Os agents não sabem que, na sua organização, receita significa receita líquida, nem que cliente ativo tem uma definição muito específica. Então, eles escrevem SQL que parece correto, mas dão a resposta errada. O segundo é o acesso. Os agents muitas vezes operam em silos porque não têm acesso seguro e governado aos sistemas apropriados, no momento certo. E, por fim, a escala. Mais consultas de mais usuários humanos e agênticos podem causar problemas de desempenho em maior escala se

01:34 não forem gerenciadas adequadamente. Na Databricks, resolvemos isso com nossa base de analytics agêntica e abordamos esses problemas em três áreas distintas. A primeira é o contexto: dar aos agents o conhecimento de que precisam para responder às perguntas com precisão. Isso inclui o comportamento aprendido com base em como sua organização usa os dados, além da semântica modelada, em que você define formalmente suas métricas e conceitos de negócio. A Databricks disponibiliza tudo isso por meio da Genie ontology. A segunda é a conectividade. Conecte-se com segurança aos agents onde quer que o trabalho aconteça, seja por meio da nossa copiloto de IA, Genie 1, de agents personalizados que você criou com Agent bricks ou de qualquer outro agent de terceiros que se conecte via MCP, como o Claude code. E, por fim, a computação. A computação do Lakehouse é a infraestrutura de computação subjacente para executar consultas analíticas em tempo real com o menor TCO possível, e foi projetada para escalar. Veja como tudo se integra. Começa com a base de dados. Os dados são ingeridos e transformados usando Lake flow até que você tenha conjuntos de dados limpos e selecionados na camada gold.

02:04 Esses conjuntos de dados são então enriquecidos com semântica por meio da Genie ontology. Isso inclui definições de métricas e conceitos de negócio, além do conhecimento aprendido sobre como sua organização realmente usa os dados. Tudo isso é governado pelo Unity Catalog. A partir daí, os agents não acessam esses dados diretamente. Eles passam pelo Unity Gateway, que governa o acesso a modelos, MCPs e muito mais por meio de políticas de orçamento, controles de acesso e proteções. Com essa base estabelecida, você obtém acesso preciso e seguro à IA por meio de quatro

02:35 áreas principais de acesso. Genie 1, seu copiloto de IA, que raciocina sobre todo o seu patrimônio de dados; agents de programação, aos quais você pode se conectar por meio de servidores MCP; agents personalizados ou Genie que você criou para um domínio específico; e Genie code, nosso assistente de programação integrado para engenheiros. Essa é a arquitetura. Agora, vamos ver como ela funciona na prática. Antes de começarmos a demonstração, deixe-me apresentar a Brick Commerce. A Brick Commerce é uma empresa fictícia de comércio eletrônico que criamos para esta demonstração.

03:05 Vamos mostrar como usuários humanos e agents podem aproveitar os dados corporativos da Brick Commerce usando essa base de analytics agêntica que acabamos de descrever. Certo, estamos na interface do Databricks e vamos começar pelo ponto de partida de toda base de analytics: os dados. Neste caso, a Brick Commerce recebe dados de sistemas transacionais, processadores de pagamento e outros sistemas. LakeFlow reúne todos esses dados e os processa por uma arquitetura medalhão, para que você tenha conjuntos de dados nas camadas bronze, silver e, por fim, gold, selecionados e prontos para análise.

03:35 Aqui, estamos vendo especificamente os ativos da camada gold do domínio de vendas. Esta é a tabela fato de vendas, nossa tabela fato no nível gold, e aqui podemos ver alguns dados de exemplo que usaremos no restante da demonstração. Ter dados limpos é absolutamente necessário, mas não é suficiente. Se um agent, ou mesmo uma pessoa, encontrar centenas de tabelas com nomes enigmáticos, não terá ideia de por onde começar a análise. Por isso, organizamos os ativos de dados em domínios e subdomínios no Unity Catalog. Para fazer isso, vamos até a interface do Genie

04:06 1. Vamos clicar na aba de descoberta. A partir daqui, posso pesquisar todos os domínios que podem ser relevantes para meu caso de uso. Vou digitar Brick Commerce. Aqui veremos o domínio Brick Commerce, com todos esses subdomínios que correspondem a conceitos de negócio, como vendas, estoque, pagamentos e crédito. Vamos examinar mais de perto o subdomínio de vendas. A partir daqui, podemos ver todos os diferentes ativos de dados relacionados a vendas. Por exemplo, temos páginas, agents Genie, visualizações de métricas e outros ativos.

04:36 Vamos analisar cada um desses ativos, começando pelas páginas. Saber onde procurar não é o mesmo que saber o que as coisas significam, e é aí que entram as páginas. Você pode pensar nelas como uma wiki governada para os conceitos de negócio. Esta é uma página chamada Forge Desk. Forge Desk é um canal de vendas específico que opera na Brick Commerce, e esta página fornece a definição oficial do que é Forge Desk. Nesta página, você pode ver que definimos um responsável, sinônimos e uma descrição, mas, o mais importante, uma definição precisa de Forge Desk. Neste caso, Forge Desk

05:07 é o canal de vendas diretas da Brick Commerce e, nos dados, é definido por este filtro específico. Esse é o tipo de contexto que determina se um agent será preciso ou não. Depois de definirmos o significado dos nossos conceitos no contexto do negócio, também precisamos definir como eles são calculados. É aí que entram as visualizações de métricas. As visualizações de métricas são sua fonte de verdade para definir medidas, campos, junções e filtros. Vamos ver nosso exemplo aqui, na área de vendas. Aqui, podemos ver todas as medidas e todos os campos que definimos. Assim, quando um agent perguntar,

05:39 “Qual é a porcentagem da taxa de aprovação?”, ele não precisa improvisar. Ele consultará aqui a definição precisa de como calculamos esse valor, com base na expressão apresentada aqui. Certo. Vamos recapitular até aqui. Domínios e subdomínios dizem aos agents onde encontrar ativos organizados em torno de termos de negócio, como vendas. As páginas dizem aos agents o que significam seus conceitos de negócio, e as visualizações de métricas dizem como calculá-los. Juntos, esses elementos formam o que chamamos de parte de semântica do Unity Catalog na Genie Ontology. São os elementos que você define e seleciona explicitamente.

06:10 Mas há um segundo lado da Genie Ontology: o conhecimento inferido ou aprendido. Na realidade, nem tudo pode ser selecionado manualmente de antemão. Sua organização tem centenas de padrões implícitos na maneira como as pessoas realmente usam os dados. A Genie aprende com esses padrões de uso para organizar um mapa do que chamamos de snippets. Os snippets incluem elementos como definições de métricas, fontes oficiais e regras de negócio. Vamos mostrar um exemplo. Aqui, estamos vendo uma definição de métrica inferida pela Genie Ontology, que esclarece como as métricas de desempenho dos vendedores devem ser categorizadas. Então, a

06:42 Genie Ontology é, na verdade, composta por duas partes que trabalham juntas: a semântica do Unity Catalog, que são os elementos que você define explicitamente, e o conhecimento aprendido, que é aquilo que o sistema capta da maneira como sua organização realmente trabalha com os dados. Agora que temos uma base semântica sólida com a Genie Ontology, tudo o que vamos mostrar a seguir se apoia nela. Certo. Agora, vamos ver isso em ação. Começaremos pelos agents Genie. Os agents Genie são interfaces conversacionais limitadas a um único domínio. Neste caso, vamos analisar Brick Commerce Sales, que é ajustado especificamente para vendas. Ele conhece as tabelas, as métricas e o contexto de negócio. Então, vamos perguntar: “Qual é a tendência mensal do GMV aprovado?” Talvez GMV não seja óbvio, mas o agent Genie tem todo o contexto sobre o que é o valor bruto de mercadorias e sobre a visualização de métricas específica usada para calculá-lo. Vamos aguardar a resposta. Ótimo, temos a resposta aqui. Posso rastreá-la até a fonte e ver que ela usou a visualização de métricas de vendas. E usou esta expressão SQL para definir o GMV. Portanto, é rápido, direcionado e preciso dentro do escopo de vendas. Mas,

07:13 A Genie Ontology é realmente composta por duas partes que trabalham juntas. A semântica do Unity Catalog, que são as coisas definidas explicitamente por você, e o conhecimento aprendido, que é o que o sistema assimila pela forma como a sua organização realmente trabalha com dados. Agora que temos uma base semântica sólida com a Genie Ontology, tudo o que vamos mostrar daqui em diante se apoia nela. Certo. Agora, vamos ver isso em ação. Vamos começar com os agentes Genie. Os agentes Genie são interfaces conversacionais limitadas a um único domínio. Neste caso, vamos analisar as vendas da Brick Commerce, e este agente é ajustado especificamente para vendas. Ele conhece as tabelas, as métricas, o contexto

07:44 de negócios. Então, vamos perguntar: “Qual é a tendência mensal do GMV aprovado?” Talvez o GMV não seja óbvio, mas o agente Genie tem todo o contexto sobre o que é o valor bruto de mercadorias e sobre a visualização de métricas específica para calculá-lo. Vamos aguardar a resposta. Ótimo, temos a resposta aqui. Posso rastrear a origem e ver que ele usou a visualização de métricas de vendas. E usou esta expressão SQL para definir o GMV. Portanto, é rápido, focado e preciso dentro do escopo de vendas. Mas,

08:16 E quanto às perguntas que atravessam domínios? É aí que entra o Genie One. O Genie One encaminha a pergunta ao agent Genie certo, mas também considera outros recursos confiáveis em toda a organização, como dashboards ou visualizações de métricas. Ele usa a ontologia completa do Genie, tanto as semânticas definidas no Unity Catalog quanto o conhecimento aprendido. Para mostrar isso, vamos criar um novo chat. Vou fazer uma pergunta como: “Analise as vendas mensais no ForgeDesk.” Isso não pode ser respondido usando apenas um agent Genie. O Genie One precisa entender o que significa “vendas”, mas também

08:48 precisa entender o que é o ForgeDesk. Podemos ver como ele percorre as etapas do raciocínio. Ele vai consultar a ontologia usando nosso algoritmo OntoRank para avaliar a autoridade de cada recurso. Por exemplo, uma visualização de métricas certificada terá prioridade sobre um notebook ad hoc. Certo, ótimo. Aqui está o resultado. Podemos ver a resposta, claro, mas, mais importante, podemos ver de onde ela veio. Ao pesquisar na ontologia do Genie, vemos que ele consultou aquela página do ForgeDesk que vimos antes, além deste trecho da ontologia que ele inferiu a partir dos dados.

09:18 Assim, cada número remete a uma definição governada, e podemos atravessar domínios usando o Genie One. Agora, talvez eu faça meu trabalho do dia a dia no Cloud Desktop, mas ainda queira todo esse contexto da ontologia. É aí que entra o Genie One MCP. Você pode se conectar ao Genie One na ontologia do Genie usando suas ferramentas de terceiros favoritas. Vamos dar uma olhada: vou acessar a opção de personalização. Em Conectores, vejo que registrei o Genie 1 MCP do Cloud Desktop aqui. Agora, vou fazer a mesma pergunta de antes: analise as tendências mensais de vendas no Forge

09:48 Desk. Podemos ver que ele está usando os mesmos recursos da ontologia de antes e, no fim, chega à mesma resposta. Portanto, quer você use a interface do Genie 1 ou um agent de terceiros, como o Cloud Desktop, pode aproveitar a mesma base semântica. Os agents também precisam de acesso governado a LLMs. Neste caso, estou me conectando a um modelo Claude registrado no Unity Gateway, que oferece governança de modelos, observabilidade de custos e proteções. É isso que o UG Claude representa aqui. Agora, aqui podemos ver como registrei o Claude para apontar para o Unity Gateway. Sempre que eu fizer uma

10:19 pergunta, a solicitação será governada pelos limites de taxa, pelas políticas e pelas proteções configuradas no Gateway. Vou fazer uma pergunta como: “Quem são nossos 10 principais executivos de contas?” Neste caso, por acaso, nossa organização tem uma política que impede os usuários de fazer perguntas como essa, que buscam informações sobre o desempenho de outros colaboradores individuais. Por isso, a solicitação é bloqueada. Vamos ver como isso é implementado no Gateway. Para isso, voltaremos à interface do Databricks. Vamos clicar em Unity Gateway aqui, que

10:50 nos levará ao serviço de modelos. Esse serviço de modelos foi configurado para fornecer acesso a LLMs ao Cloud Desktop, como acabamos de ver. Aqui, podemos definir o acompanhamento de uso, tabelas de inference para registrar solicitações e respostas, limites de taxa e, claro, políticas, como a que acabamos de ver em ação. Vamos conferir nossa política de tópicos permitidos, que define quais tópicos são permitidos e quais são proibidos. Aqui, podemos ver que qualquer conteúdo sobre métricas de colaboradores individuais será sinalizado. Além da proteção personalizada que

11:20 vimos, o Databricks Unity Gateway inclui proteções integradas para detectar dados confidenciais, conteúdo inseguro, tentativas de jailbreak e alucinações. Em resumo, o Unity Gateway é o painel único para governar o acesso aos seus LLMs. Certo, vamos juntar tudo isso. Percorremos um exemplo completo de como criar uma base de analytics agentic no Databricks. Começamos ingerindo dados no lakehouse e definindo um contexto semântico detalhado com a ontologia do Genie. Vimos como essa ontologia permite obter respostas precisas em várias interfaces.

11:51 Agents Genie para domínios específicos, Genie 1 para raciocínio entre domínios e agents de programação por meio do MCP. E mostramos como o Unity Gateway mantém tudo governado e seguro com proteções e políticas. Lembram-se dos três riscos que mencionamos no início? Precisão, resolvida pela ontologia do Genie, que fornece aos agents o contexto semântico para gerar consultas corretas, fundamentadas em definições confiáveis. Acesso, resolvido pela governança do Unity Catalog e pelas proteções do Unity Gateway, garantindo que os agents só apresentem informações que devem apresentar.

12:22 E, por fim, escala, resolvida pela camada de computação gerenciada do Databricks, que dá aos agents acesso a dados em tempo real com controles de custo integrados. Então, aqui vai o convite: experimente criar sua própria base de analytics agentic usando a plataforma Databricks. Incluímos na descrição abaixo toda a documentação e os guias para começar de que você precisa. Obrigado por assistir.

Transcrição original

[00:00] [music] >> Every organization wants AI agents that reason over their data. But without the right foundation, those agents just produce faster, more confident, wrong answers. In this video, I’ll show you how to build a robust agentic analytics foundation on the Databricks platform that ensures your agents are accurate, secure, and ready to scale. Hi, my name is Justin Kolb Peck. I’m a senior solutions architect here at Databricks, and let’s get into it. So, what is agentic analytics? Agentic analytics is the next evolution of the

[00:32] modern data stack. We’re moving from dashboards that humans read to agents that can reason, query, and act, and semantics are absolutely pivotal in making that shift work. If you’ve worked in data, you’ve seen this problem before. Data teams are buried, and every question that anyone in the organization needs an answer to becomes a new ticket. Thankfully, agents can break that bottleneck, but only if the foundation is right. Because when you turn agents loose on enterprise data without the proper guardrails, you’re exposing yourself and your organization to three

[01:03] real risks. The first is accuracy. Agents don’t know that revenue means net revenue in your organization or that active customer has a very specific definition. So, they write SQL that looks right, but gives you the wrong answer. The second is access. Agents often operate in silos because they don’t have the right secure, governed access to the appropriate systems at the right time. And lastly, scale. More queries from more human and agentic users can cause performance issues at larger scale if

[01:34] not managed properly. At Databricks, we solve for that with our agentic analytics foundation, and we address these problems in three separate areas. The first is context, giving agents the knowledge that they need to answer questions accurately. That’s learned behavior from how your organization uses data, plus modeled semantics where you formally define your metrics and your business concepts. Databricks makes these available through Genie ontology. The second is connectivity. Securely connect to agents wherever the

[02:04] work is happening, whether it’s through our AI co-worker, Genie 1, custom agents that you’ve built with Agent bricks, or any other third-party agent that connect via MCP, for example, Claude code. And lastly, compute. Lakehouse compute is the underlying compute to run analytical queries in real time with lowest TCO possible, and it’s built for scale. Here’s how it all comes together. It starts with the data foundation. Data is ingested and transformed using Lake flow until you have clean, curated gold layer data sets.

[02:35] Those data sets then get enriched with semantics through the Genie ontology. These are things like metric and business concept definitions, as well as learned knowledge about how your organization actually uses its data. All of this is governed through Unity Catalog. From there, agents don’t hit this data directly. They go through the Unity Gateway, which governs access to models, MCPs, and more through budget policies, access controls, and guardrails. With that foundation in place, you get accurate, secure AI access through four

[03:05] primary surface areas. Genie 1, which is your AI co-worker that reasons across your entire data estate, coding agents, which you can connect to via MCP servers, custom or Genie agents that you’ve built for a specific domain, and Genie code, which is our built-in coding assistant for engineers. So, that’s the architecture. Now, let’s see how this works in practice. Before we get into the demo, let me first introduce you to Brick Commerce. Brick Commerce is a fictional e-commerce company that we’ve created for the purposes of this demonstration.

[03:35] We’ll showcase how both human users and agents can leverage Brick Commerce’s enterprise data using this agentic analytics foundation that we just described. Okay, so here we are in the Databricks UI, and we’re going to start where every analytics foundation starts, with the data. In this case, Brick Commerce has data coming in from transactional systems, payment processors, and other systems. LakeFlow takes all that data, moves it through a medallion architecture, so you have your bronze, your silver, and finally your gold layer data sets that are curated and ready for analysis.

[04:06] Here, we’re looking at the gold layer assets specifically for the sales domain. So, fact sales, this is our gold level fact table, and here we can see some of the sample data that we’ll use for the rest of the demo. Having clean data is absolutely necessary, but it’s not sufficient. If an agent or even a human sees hundreds of tables with cryptic names, they’re not going to have any idea where to start their analysis. That’s why we organize data assets using domains and subdomains in Unity Catalog. To do that, we’ll head over to the Genie

[04:36] 1 UI. We’ll click on the discover tab. And from here, I can search for all the domains that might be relevant for my use case. I’ll type in Brick Commerce. And here we’ll see the Brick Commerce domain with all of these subdomains that map to business concepts, like sales, inventory, payments, and credit. We’ll take a closer look at the sales subdomain. And from here, we can see all the different data assets that are related to sales. For example, we have pages, Genie agents, metric views, and other assets as well.

[05:07] Let’s drill into each of these assets, starting with pages. Knowing where to look isn’t the same as knowing what things mean, and that’s where pages come in. You could think about them as a governed wiki for your business concepts. Here’s a page called Forge Desk. Now, Forge Desk is a specific sales channel that operates within Brick Commerce, and this page provides the authoritative definition for what Forge Desk is. On this page, you can see we’ve defined an owner, synonyms, a description, but most importantly, a precise definition for Forge Desk. In this case, Forge Desk

[05:39] is Brick Commerce’s direct sales channel, and in the data, it’s defined by this specific filter. This is the kind of context that makes or breaks agent accuracy. Once we define what our concepts mean in terms of the business context, we also need to define how they’re calculated. That’s where metric views come in. Metric views are your source of truth for defining measures, fields, joins, and filters. Let’s take a look at our example here and the sales. Over here, we can see all of the measures and all the fields we’ve defined. So, when agent comes and asks,

[06:10] “What is the approval rate percentage?” It doesn’t need to improvise. It’ll go here and reference the precise definition for how we calculate that based on the expression provided right here. All right. Let’s review where we’re at so far. So, domains and subdomains tell agents where to find assets organized around business terminology like sales. Pages tell agents what your business concepts mean, and metric views tell agents how to calculate them. Together, these form what we call the Unity Catalog Semantics portion of the Genie Ontology. These are the things that you explicitly define and curate.

[06:42] But, there’s a second side to the Genie Ontology, inferred or learned knowledge. In reality, not everything can be hand-curated upfront. Your organization has hundreds of implicit patterns in how people actually use the data. Genie learns from these usage patterns to curate a map of what we call snippets. Snippets include things like metric definitions, authoritative sources, business rules. Let’s show an example here. Here, we’re looking at a metric definition that Genie Ontology inferred, and it clarifies how seller performance metrics should be categorized. So, the

[07:13] Genie Ontology is really two halves working together. Unity Catalog Semantics, the things that you explicitly define, and learned knowledge, what the system picks up from how your organization actually works with data. Now that we have a strong semantic foundation with Genie Ontology, everything we’re about to show builds further on this. All right. Now, let’s see this in action. We’ll start with Genie agents. Genie agents are conversational interfaces that are scoped to a single domain. In this case, we’ll look at Brick Commerce Sales, and this one is tuned specifically for sales. It knows the tables, the metrics, the business

[07:44] context. So, we’ll go ahead and ask, “What is the monthly trend of approved GMV?” GMV might not be obvious, but the Genie agent has full context on what gross merchandise value is and the specific metric view for how to calculate it. Wait for our answer. Great, we got our answer here. I can trace this back to the source and see that it used the metric view for sales. And it used this SQL expression to define GMV. So, fast, focused, and accurate within the scope of sales. But,

[08:16] what about questions that cut across domains? That’s where Genie One comes in. Genie One routes to the right Genie agent, but also considers other trusted assets across the organization, things like dashboards or metric views. It uses the full Genie ontology, both Unity catalog defined semantics and learned knowledge. So, to show this, we’ll head over to create a new chat. I’ll ask a question like, “Please analyze monthly sales in ForgeDesk.” Now, this can’t be answered just by using one Genie agent. Genie One needs to understand what sales means, but it

[08:48] also needs to understand what ForgeDesk actually is. We can see how it traces through the reasoning. It’s going to consult the ontology using our OntoRank algorithm to weigh the authority of each asset. For example, a certified metric view will outrank an ad hoc notebook. Okay, great. Here’s the result. We can see the answer, of course, but more importantly, we can see where it got its answer from. Searching the Genie ontology, we can see that it referenced that ForgeDesk page we looked at before, as well as this ontology snippet that it inferred from the data.

[09:18] So, every number traces back to a governed definition and we’re able to cut across domains by using Genie One. Now, maybe I run my day-to-day from Cloud Desktop, but I still want all that ontology context. That’s where the Genie One MCP comes in. You can connect to Genie One in the Genie ontology from your favorite third-party tools. Take a look, we’ll go over to customize. Connectors, I can see I’ve registered the Genie 1 MCP from Cloud Desktop here. Now, I’ll go ahead and ask the same question that we asked before. Analyze monthly sales trends in Forge

[09:48] Task. We can see that it’s leveraging the same ontology assets as before and it ultimately arrives at the same answer. So, whether you’re consuming through the Genie 1 UI or a third-party agent like Cloud Desktop, you’re able to leverage the same semantic foundation. Agents also need governed access to LLMs. In this case, I’m connecting to a Claude model registered in the Unity Gateway, which provides model governance, cost observability, and guardrails. That’s what UG Claude here represents. Now, over here we can see how I’ve registered Claude to point to the Unity Gateway. Now, whenever I ask a

[10:19] question, the request is going to be governed by the rate limits, policies, and guardrails that have been set in the Gateway. I’ll go ahead and ask a question like, “Who are our top 10 account executives?” In this case, it just so happens that our organization has a policy that restricts users from asking questions like this, where it’s inquiring about the performance of other individual contributors. And as a result, the request is blocked. Let’s take a look to see how this is implemented on the Gateway side. So, for that, we’ll head back to the Databricks UI. We’ll click on Unity Gateway here, which

[10:50] will bring us to our model service. This model service has been configured to provide large language model access to Cloud Desktop, like we just saw. Over here, we can define usage tracking, inference tables for logging requests and responses, rate limits, and of course, policies, like we just saw in action. Here, we’ll take a look at our allowed topics policy, which defines which topics are allowed and which topics are off-limits. Here, we can see that anything about individual contributors metrics are going to be flagged. In addition to the custom guardrail we

[11:20] saw, Databricks Unity Gateway has built-in guardrails for sensitive data detection, unsafe content, jailbreak, and hallucination. In short, the Unity Gateway is the single pane of glass to govern access to your large language models. Okay, so let’s bring this all together. We’ve walked through an end-to-end example of how you can build an agentic analytics foundation on Databricks. We started by ingesting data into the lakehouse and defining rich semantic context with the Genie ontology. We saw how that ontology powers accurate answers across multiple surface areas.

[11:51] Genie agents for scope domains, Genie 1 for cross-domain reasoning, and coding agents through MCP. And we showed how the Unity Gateway keeps everything governed and secure with guardrails and policies. Remember those three risks that we started with? Accuracy, solved by the Genie ontology, which gives agents the semantic context to write correct queries grounded in authoritative definitions. Access, solved by Unity Catalog governance and Unity Gateway guardrails, ensuring agents only surface information that they should.

[12:22] And finally, scale, solved by Databricks managed compute layer, giving agents access to real-time data with cost controls built in. So, here’s your call to action. Try building your own agentic analytics foundation using the Databricks platform. We’ve linked all the documentation and getting started guides you need in the description below. Thanks for watching.