Name: Introducing D3: The First Agentic Analytics Platform Built on a Universal Semantic Layer
Uploaded: 2025-06-25T17:23:13.012Z
Duration: 1 h 48 s
Description: Introducing D3: The First Agentic Analytics Platform Built on a Universal Semantic Layer

Transcript for "Introducing D3: The First Agentic Analytics Platform Built on a Universal Semantic Layer": Hey, everybody. Yeah. Good morning or or good afternoon, whatever time zone you're in. Happy to see you all join us today. I've got 11:00 here in the lovely central time zone. So I'm gonna give everyone maybe another minute before we get started. But, yeah, just to make sure you're in the right place, you are, you are joining the CUBE team today on our webinar about d three, our, agentic analytics platform. So we will give folks, let's say, maybe another thirty or forty five seconds, and then, we're gonna go ahead and get started. Thanks. Okay. I'm looking at the attendee list, and there's there's already a lot of folks filing in. So, let's go ahead and get started. Ardem and I both have a a lot of content for you today, so I, I wanna make sure we've got enough time. As I said earlier, yeah. Hey. Thanks for joining us. You're on with the CUBE team today, and, today's webinar is introducing d three or or cube d three, which is, our Agintiq analytics platform, which is the the first AgenTic analytics platform built on a universal semantic layer. Some of you are are probably maybe new to Cube, so we're gonna we're gonna talk about Cube, and we're also gonna talk about the the new features today. Let's go ahead and get into it. As for your speakers today, you've got myself. I am Brian Bickell, VP of strategy and alliances here at Cube. You've also got, Artem Keydunov, who's the CEO and cofounder of Cube, one of the original, developers and cofounders of the the open source project and and leads the company today. So very happy to have Artyom on stage with me today, and I'm gonna kinda get into things about about what is Cube, and then I'm gonna let him pick up the the majority of the heavy lifting on this webinar telling you about our our new features with Cube d three. So to take a look at the agenda, as I mentioned, we're gonna do do intro, talk about Cube Cloud and the existing Symantecular platform we have, what's new with d three, talk about our thoughts on a Genesys analytics and where we think the the ball is going here. And then Artyom's gonna spend a lot of time in product today, demoing, where we are with d three and our and our progress. And then finally, we're gonna wrap up with a q and a. So if you have any questions, you can go ahead and either type them in the chat, type them in the q and a. You can type them as they come to you. You can hang on to them, but, we will batch all those and answer them in the last, last fifteen minutes or so of the session today. And we are planning to go for the full hour, depending on how many questions we've got. So, yeah. If you got questions, please go ahead and go ahead and ask them. And with that, I'm gonna get into, the intro about exactly what Cube Cloud is and and about universal semantic layers as a as an idea. I know that, you know, a lot of you in the in the list, of attendees here are are probably familiar with Cube, but I suspect that, you know, by marketing and and by advertising a a Genesys analytics platform, we're we're probably reaching some people that are maybe not as familiar with the idea of a semantic layer. So I wanna start by maybe explaining what what Cube is today and then and then Artyom will pick up with with what we're adding to the product. So for those unfamiliar with the idea of a universal semantic layer, one of the big, sets of problems that that we're solving is helping customers consolidate business logic and business metrics, dimensions, measures, metrics, things like that into a single place where they can be confident in their analytical decision making process on top of that data and also use that data in many different downstream, applications. That could be use cases like, business intelligence and, spreadsheets, which are a very common Cube cloud use cases. It could be embedded analytics and building data applications, which are also very common use cases. But increasingly, we're seeing, interest in AI use cases, which, again, is what we're all here to talk about today with, with d three, our agentic analytics platform. I'm kinda going a little bit out of order here, but we're we're gonna go from the from the right to the left this time. And, yeah, I mean, if you think about the use cases first and how Cube and the universal semantic layer powers those, the four pillars as we talk about them in the box of of Cube cloud are the ideas of of data modeling, access control, caching, and API endpoints. Cube data modeling is is done in either JavaScript or YAML. Both, are are interoperable and, deliver the same functionality. It's a, primarily code based experience or a code first experience with a visual editor if you wanna use that. Very easy to version control it and, to do, multiplayer development, very easy for teams to collaborate on their their shared data models. The access control in Cube gives us things like, row level security, member level filtering, column masking, things like that. Also gives us very strong multi tenancy for situations where maybe you're doing an embedded, application or you're you're doing AI and you you just wanna make sure that, you know, individual users that should have different access levels to data or or different granularities or different, member sets, are are are, you know, being able to respect those security, guidelines as you've set them up. But we have caching in the product, which is a pre aggregation engine that's very powerful. It's built on Apache, Data Fusion. It's in Rust, scales super well for pre aggregations and roll ups. And finally, we make all of our data available via series of APIs. That's REST and GraphQL that supports the embedded analytics use case. That's SQL, MDX, and DAX, which supports our traditional BI and spreadsheet use case. And, yeah. Really, d three is kind of the star of the show today, so I'm gonna I'm gonna get beyond the, the platform introduction. That's probably got you oriented well enough, and we're gonna get into d three. Cube d three is our, agentic analytics platform built on top of Cube Cloud. So it is a a product feature within the platform, and it's a little bit of a departure for Kube because, traditionally, we have not supplied, what you would think of as an analytics front end in the product. I look after alliances here. So, you know, a lot of the time I spent here at Cube has been really, helping make sure that whatever BI tool or spreadsheet or or other platform that our customers want to use Cube with, that we can we can go out and make that happen. But d three is a little bit different. It's an analytics product, within the Cube cloud platform. And, yeah, we're really excited about this launch. So, let's talk about maybe what we're adding to the product. We talked about these kind of core capabilities of kube cloud, which is data modeling, access control, caching, APIs, our long list of cloud data platforms and relational databases and other sources we connect to. What we're adding is really everything here on the right, which is the whole Agenstic analytics platform. And RDM is gonna go into much more detail, in the demo about how we bring that to life with these ideas of, you know, things like memories and certified queries and rules and agents and skill sets that that, you know, we've sort of worked through, really with the goal of of bringing the highest accuracy that we can, in the agentic analytics experience. And, you know, how we're able to do that is is with the the semantic power, of the Cube cloud platform. So with that, I'm gonna go ahead and get out of here, and I'm gonna let Artyom take over. Thank you, Brian. Hi, everyone. It's, it's good to be today here with you. I'm excited to tell you more about what we are building with our agentic analytics product. My name is Artyom, cofounder and CEO at Cube. Started it in 2019 as an open source project coming from software data engineering background, and then in 2020, build a company around it. So let's jump into d three, our agentic analytics platform. And I will start with, sort of why we're building it. Right? Like, what is what is the thesis we have and what is the product region we have here for our agentic analytics product. So the first thesis is that we believe that the future of workspace is agentic. Meaning that for every function and role in organization, we'll have AI teammates to augment humans, to help humans be more productive. We already see it happening with sales, legal, accounting, especially with software engineering. I believe that what is happening in software engineering today with tools like Corserve, WinServe, Replit, and others, it's a preview of what is going to happen to the whole industry and into different domains in two, three, four years. And data and analytics is not exception. We'll have tools to help data consumers, data stewards to be more productive, to augment data consumers and data stewards experiences and day to day work. The other thesis that we are building on top of is about semantic layers, of course. We believe that semantic layer is essential for data and analytics, AI agents. So unlike software engineering, collegial, for example, where the main asset we work in Greece is text, and you can put that text into the context window. We can turn that text into embeddings and store in the vector database to perform the similarity search later and then supply that back into the context. It's not possible to directly do this with structured data. When we deal with structured data, we need this extra metadata layer or semantic layer. Some people would call it a knowledge graphs or ontologies. But at the end of the day, we need a way to manage the context about our data. We need a way that humans can understand and create context, but also AI agents can read and write that context together because we are talking about augmentation. Right? We need a shared medium that we can use to reason about context for structured data, and that is semantic layer. And, if we do a quick Google search, it feels like that the whole industry is building consensus around that idea. If you go online, on LinkedIn, Internet, everyone is talking about, oh, you need a semantic layer for AI. Every vendor has their different opinion, the different take on that, but I think the consensus is pretty pretty universal. We need a semantic layer to make AI work. Now let's come back to Cube and our story and our past to agentic analytics. Cube started in GitHub as an open source project late twenty, '18. And in 2019, that was a real year when we started to to gain traction. Then we started a company and raised, some financing. As you can see here, our latest financing was, 25,000,000 last year. But, also, what important happened, and you can see that here on a history that is not directly related to Cube, but ChargeGPT was released, and it was late twenty twenty two. And, when we when that happened, a lot of people started to think about, okay, how we can use, you know, like, LLMs applied to to our industries. And we started to look a lot into that, you know, like, to see the rate of improvement in LLMs. And by 2024, we got very convinced that that's the future, and we started to work on on the d tree because we felt that we had this history of being in a semantic layer business. We have a lot of open source users, a big community. The semantic layer was pretty mature, and the semantic layer is really the key ingredient in making agentic analytics work. So we filed who is not not a cube, then who is going to build the agentic analytics product because we have that probably the most ingredients already in place. So we jump into that, and now we're introducing Cube d three. That's still in process. We're still building that. We have been working with a really group good group of our customers in the last, six months is now we're opening it to bigger audience and then onboarding more customers, but we're just getting started. We have a vision to make it publicly available as part of our Cube cloud for every company later this year, but right now, it's it's based on the wait list while we're still building the product. So if you look at the whole vision here is and what kind of use cases this platform can serve, I break them down into three pieces, The internal BI, embedded analytics, and multi agent architectures. The internal BI here, we, serve, you know, business users, data analysts, data engineers, your common BI users. Right? And I will cover the use cases for all these users just in a second. Embedded analytics, that's the bread and butter of Cube to some extent because Cube historically been used in a lot of embedded analytics projects to power custom apps. So we just double and down on what we've been doing for a while and just offering the same embedded analytics capabilities, but with AI on top of that and and some visualizations. And then finally, multi agent architectures. We believe that it may be a small use case today, but it's one that is very exciting and growing fast. I speak with many organizations and many of them building their own agents. Maybe internal agents, maybe agents for, communicate with customers, partners, externally, but these agents can do a lot of different things. They may be domain specific, specific to organizations, but as they do the work, in many cases, they need to access into data and analytics. So I see the world where we'll have multiple agents doing different things and communicating with each other. So to support this, architecture, we are building fundamental blocks in our Cube d three product like MCP a to a integrations. So So if you're building your own agent, you can connect that agent to our platform. So speaking of the internal BI use case and the personas I mentioned here, I have business user, data analyst, and data engineer. And inside the application that we're building and the one I'm going to show you later today at the demo, we have a goal to serve these three personas. So for business users who are commonly asking questions about the data, sending request, try to slice and dice data, we offer analytics chat. And the one I show you today where they can just ask questions, get answer back, ask a follow-up question, maybe drill down into specific number. We will have upcoming data apps that are not available in the product yet, but they will be used for the business users as well. Let me go down to the next persona, data analyst. Data analyst usually explore data in more details, run a deeper analysis, cue create calculated fields. So they curate findings. They create things like workbooks, which is a common in tools like Tableau. For that, to support that experience, we offering workbooks and then the ability to package the findings, the package, the insights, and expose them as a data apps. And everything is AI driven. Right? Like, for every work here that whether you're exploring the data through analytics shot or curating or book or building a, data app, we believe in a world where, like, AI helps humans and document humans to be more productive. And then finally, data engineers. Right? We're in business of semantic layer. Data engineers, it usually people who build semantic layers. That same here true. We're offering some experience in our product to help data engineers to build data models more efficiently. We're, like, AI can act as a copilot and, you know, like, do a pair of programming with you on your semantic model, optimize model, supplies row level, column level, access policies, create the whole cubes and views from scratch. And for data engineers, we have workbooks and a semantic modeling as well as, interfaces or core experiences. So that's it. I'd like to keep the my decks short, so the demo is the most fun part of it. I'm going to share my screen right now and jump into demo. And as Brian mentioned in the beginning, feel free to ask your questions in a in a chat. We'll batch all the questions, and then answer them at the end. So going to share my screen now. Alright. So I'm here in our demo t three demo instance. Before I jump into the meat of the demo, I wanted to show a few important configuration, settings. And one is how we deal with, and what kind of LLMs we support. So current we do not add queue. We do not train or fine tune any LLM. We just run on top of the best latest model from major labs. That allows us to get to the best model the moment they've been released. It's not slowing us down to fine tune or train and do all the expensive work, but also it allows you to bring your own model. So as of today, we support in Zentropic and OpenAI models. We're planning to bring Gemini. We're open to bring Clamo once it gets better and on par with Zentropic. So we would we are open to any major models as long as they perform well. And the customers can bring their own models, which is helpful if your compliance or privacy concerned, and then you would like to have direct relationship with your model providers or inference providers. Now let's jump into the meat of the demo. I'm going to try to highlight the major, features around our platform as as well as major differences from maybe other solutions. And, I will start my demo with this very simple thing. Just we can see the whole flow, and then I will build complexity as we go. For me, revenue numbers. Very simple question. I'm using analytics chart, as I mentioned. We'll get to workbook and semantic modeling later. We're not going to cover data apps today, but we'll cover a lot of features in analytics chart, workbook, and semantic modeling. So what is happening here, as you can see, the first, we had some reasoning trace, and, the reason because we're using entropic model here. So entropic model is thinking model, so we also expose the reasoning trace to users so they can see that. Then the next step with model did, it's search within a semantic model, and it found the definition. In our case, again, we're starting very simple. We'll add more as we go. But, in our case, we just search for revenue, and we have revenue definition in our orders view, which is, cube semantic model primitive. The views are being sort of, like, multidimensional cubes that agents or systems can query. And what has happened here, the next step, is that agent created what we call a semantic SQL. That's where I wanna stop and highlight our difference from maybe some other platforms use a demo text to SQL demos. So Qube is not doing text to SQL. We're not doing that. Agents of AI never generate a SQL that is going to be executed in your warehouse. If we would try to use term text to SQL, I would rather call it text to semantic SQL because that what is happening here. So if I go on this slide, and that illustrates the whole flow very well, is we take the semantic layer, we use definitions from semantic layer, we give them to agent, then agent generate what we call a semantic SQL, and then we send the semantic SQL to our semantic layer run time. And then our semantic layer run time deterministically generates the warehouse SQL. So coming back here, as you can see, I have a very simple semantic SQL statement. If I go to Cube semantic, query history view and let me refresh that one here just to see the latest query in. That's it. So as you can see, that's a query that AI sent to, Cube semantic layer. Now but that's a very simple query that using the measure definition. Right? The I would say one of the major differences between semantic SQL and a Postgres dialect, and we're using Postgres dialect for the Symantec SQL, is the sort of, like, addition of this measure function. So we extended Postgres SQL to introduce some analytical concepts including the measure function. So what what happened is that our agent generated a SQL to query this revenue metric and that SQL was sent to Qube. Now what cube did is that it took that SQL and generated a bigger or I would say real SQL for our Snowflake instance. We use Snowflake instance for this demo. So as you can see, even for very small query, the final SQL is pretty big that includes joints, calculations, avoiding fan outs, and things like that. So that's very important distinguish between Cube and other systems is that we do not let agents generate queries for your warehouse. So you never can run into drop table or something. Right? Maybe that's exaggeration to some extent, but you know what I'm talking about. Right? Like, when agents generate Snowflake SQL or BigQuery SQL and we execute this SQL directly in database, they're we only can hope that it's a correct SQL. We only can hope that, you know, like, the agent got all the instructions right. But what we have in here, it's a way to have a proxy or deterministic guardrail between agent and a Snowflake and a fully controlled execution environment. So agent can theoretically generate wrong SQL, but that wrong SQL is going to be executed in cubes. So the wrong SQL is never going to make it to your Snowflake. And, also, that's a place where we can enforce all row level or column level securities. Okay. Now one can question is that, okay, what if we only query semantic layer? Does it mean that it restricts us to only metrics that we have here? What if we don't have a metric in our semantic model? What happened? And that's a very common problem. Right? Even if, even without AI. Right? Like, if you're using any tool like maybe Looker and you don't know how to change look AML or you don't have, permissions to change look AML, you would be like, oh, yeah. But it all looks great, but I need that new metric. And what what would you do? Right? You would go to your data team and data engineering team and to ask to to add new dimension, to add new measure. And that's getting a little bit trickier if you need to make all these changes. And semantic layer is never going to cover all the possible permutations of metrics and type of analysis that you need to do. But the beauty of semantic SQL is that it's still SQL. You yes. You're querying your measures. You're querying the dimensions. You cannot go and query the raw data, but you still can build on top of that. You can take one existing metric and build a new one. So for our example here, let's ask AI to do add monthly breakdown first. That's easy. And then let's do add prior months revenue and months over month growth. So as you can see, I don't have prior month's revenue or month over month growth inside, inside my semantic layer model. Right? But what is going to happen is that AI is going to use, SQL function to calculate prior months and then to calculate months over month draws. And the reason because, that's at the end of the day, Symantec SQL is a SQL, and that's the reason why AI could do that. Right? As we can see it using the lag function, That's how I would do that. If you would ask me to calculate the prior month's revenue, and then it just using that results to get to the month over month's gross rate. So it's still building on top of existing metrics. It's still building on top of existing dimensions inside this data model, but it's creating few metrics on a fly as it go. And that opens a lot of flexibilities. It can do a different analysis. It can try different things. It can create multiple queries and then kind of summarize the results back to user. So that concept that we're still using the governed layer, but we can extend that governed layer. Think about it as, like, a semantic layer just like an onion, right, with multiple layers. It all starts with your database, then maybe d b t transformation or something else transformation. Then you have a semantic layer, and then you have just in time or, like, a query time, run time kind of modeling. Right? When on a report level, you can build some calculations on top of that. And we'll get to a point how you can promote this calculation to your semantic model with AI in a few minutes. But I think that's the idea of, like, creating multilayer semantic model and letting AI to help drive the last mile analysis is really powerful. Now I wanted to talk a little bit about the context. As you can see, this query says certified. So what does it mean? What is certified queries? In Cube, we're thinking a lot about the context because we believe that context is key for the success with AI. So we're not in we're not building our own models as I mentioned. Right? Really, what we're doing, we obviously building the best in the world semantic layer. But other than that, we're also curating the context and orchestrating all LLMs to give the right context in right time to the LOM. And when we think about the context, we break it down into several things. So it all starts with your data in your cloud data warehouse. You we let agents search values in a cloud data warehouse. Right? How do you how do you record the state? How do you record the name of the customer? Is there any specific, you know, like, formatting issues? Are you using underscores? Are you using dashes? Is it a snake case, camel case? So, like, it's always so many kind of details how you record things in a in a database. So AI needs to be able to look inside and understand what you have in there. Then the semantic layers come in. That's where we provide a lot of context, especially if we let AI also create a piece of semantic layer. AI can be really good and be very sort of, like, explicit and expressive to some extent. We know that AI do that, so adding a lot of comments, adding a lot of descriptions. So using AI to create additional context for AI itself is really good practice. Then on top of that, we have features like we we call them domain knowledge. So it features like certified queries, the one I just showed you, the rules, and the queries from workbooks. So we take all this content inside d three, and we provide that content. We curate and provide it with specific heuristics and rules to to AI. But at the end of the day, AI will see specific context as a domain knowledge during the query time to understand how to query data. Is there any, you know, like, specific tips and tricks how to query data? Is there any specific filter needs to be applied all the time? That's a really good place to provide this knowledge to AI. And then finally, we have memories. So AI in q d three, it has memories, and the memories are being shared across conversations. And as you can see here, it refers to memory in the reasoning good thinking trace. So it said, oh, I remember that question was asked before already, so I will use that memory. So this way it helps, AI to understand what performing well and, you know, like, if it's a good memory and then just reuse that. Memories are connected to reinforcement learning. So users can tell that is a good query, that is a not good query. That can be done through thumbs up, thumbs down, but also we just get we can just tell AI that's wrong calculation. Let's try a different calculation. And, my cofounder, actually, he did a lot of LinkedIn post on the memory and how we think about it. So if you really wanna go into details, how we technically implement it, his LinkedIn is a good place, to check it out. So let's move to, let let me actually show you as part of the context as how we can, search within, cloud data warehouse, and then I will we will switch to the workbooks. So revenue in I'll do the monthly revenue in California for cameras. So that could be a common use case where, like, someone is trying to search for specific number or build a specific chart, but wanna filter by a multiple fields. So in that case, agent can search how we actually record, the dimension values. So as you can see, what is happening in here is that, first, our agent is looking at, just in general semantic model, what we are talking about. Right? We're talking about revenue, orders, California, product categories. Then the agent will look at how do we exactly encode customer state, and we'll see that in a second. And then how do we exactly encode product category because it understands the cameras is related to product category. And then if you check our semantic SQL, it created the correct, predicate here, the where statement. And cameras are easy. You just need to use a capital c for that. But then California is a little tricky. Right? Like, so you maybe not the first, you know, like, idea how you would record California in your database. So but the ability to search within dimension values allowed AI to generate the correct query in here. And it gave us a nice line chart here, and, that's where I, like, I wanted to just show you how you can control the churning capabilities in analytics chart, and then we jump into workbooks. So in, AI can generate a charts for you, and you can really tell what kind of, color you can do, what kind of things you can do. Make it a bar chart and make charts, nice and pink. My daughter is going to like that chart, but, we can use any color of your preference. And in workbook, I actually going to show you how then you can change that yourself if you would like to change the color by hand. But let's see. Let's check our pin bar charts. Okay. So we actually, we didn't get any oh, this time it changed the California. Let's go into the here and use workbook for that right now. And I'm going to show you how to use workbook in here and change the color of the chart in a workbook. So Well, the workbook interface is, similar to, maybe, like, workbooks from Tableau, or similar AI, similar BI products where you can have tabs and each tab represent a single chart with a query attached to it. You can change that on the right hand. But the major difference between workbooks in q d three and other BI tools is that it's all AI first and AI driven. Meaning that what AI creates here for you, then you can change as a human. So if you wanna go from California maybe to different state here, we can just click at that, and it updates automatically. So you don't need to ask AI to change, your chart to change your result to something different. So you can go and click around and make changes as, as you want. You can also ask AI to, you know, like, maybe add a new filter. Say, we wanna like, I don't like state. I remove the state filter in here and, still a line chart, and then maybe I can say filter down to Austin. So AI can create a filter and add that filter to me right now. So that's where how we think about the workbook. It's, it's a bidirectional between user and AI. So AI can make some changes to your reports, to your charts, and then user can make some changes as well. And then we can synchronize. Meaning that maybe, you know, like, you don't wanted to build your new report from scratch. But once it gets you this new report, do you really need to ask AI to update Austin to Chicago? Probably not. It's easier to click. So we wanted to build an experience where users can ask AI to do a lot of things, but then at the same time, click around, drill down, create filters, remove filters to pivot operations, and things like that. And it's the same true with the chart. So if I got my pink chart in here finally with, nice pink bars, but then say I don't like that pink bar, maybe I want a green one and I wanna, an area chart instead. So I can just click around and do that. So that's fully integrated and with AI and humans can work together. So now let me show you how you can create a custom metric on a fly. I already show you that with the prior month's revenue. But this time, we'll first create a new metric, and then we'll use that metric to save the data model. Create me a report with average order value and break it down by, product category product category and filter to California. That's an example where, I don't wanna, like, click around and do all the filtering. It's a maybe, like, a longer query. I wanted to just ask AI to do that, especially because I don't have average order value, calculated. But it's easy to calculate. Right? It just we need to take a revenue and an account measure and get to that, calculation of the average order value. But instead of us typing the calculation, maybe Excel formula or semantic SQL, we can just get to that point. So we got exactly what we asked for. As we can see here on the screen, we got it filtered down to California, correct filter. We got a broke breakdown by product category, and we have average order value here. So what is really interesting here is that when we look at the average order value, we see that it's being green here. Green meaning that it's not coming from a semantic model. It's a calculated field being built on a fly. So we see measures. We see dimensions in here as selected, and they have the same color coding. They're coming from our semantic model. The green means they're calculated on a fly. If I click a semantic SQL here, I can see that calculation in here. So now what if I want to promote or save that, average order value to my semantic model? I can do that with AI. So if I go in here, I can say, save my average order value collation to orders cube. And that will illustrate how we can use, AI to make changes to the data model as well. So AI can not only create a new measure for you, a new dimension, but it also can bootstrap the whole cubes, the whole views. It can create you a cube from just a simple SQL query. So you can send a SQL query to, AI here and say, hey. Build me a new cube from that. So let's look at that. As you can see, we got it to our average order value here. We got some nice description here, average order value, how it's being calculated. So now we can use it in our data model. So let me go and refresh the page here. I will go and create a new report. As you can see, I got it right here, average order value. We didn't say that before because we didn't have it in our semantic model. Now I can click here, and then I can click on a product category. I'm trying to recreate the same query we had before. Right? Right here, it's still using the kind of on the fly calculation, but now we can filter it down by customer state. As I mentioned before, you can do all point and click, so you don't need to ask AI to do that. But for complex queries or, you know, like, if you don't feel like you wanna click around, you definitely can use Ask AI to do that. So we got to the same query, two four one one six, and, I think that was cameras, and then we got it. So that's our calculation in here. We saved it to data model. Let's I think that's where we can wrap up. We are almost at nine forty five mark. We wanted to save some, room for the questions. As a reminder, app builder is coming that will enable, take all your reports from workbooks and package them together as React apps and, share with the world. Just say, hey. Build me, you know, like, think about it like wipe coding tools, but for your dashboards. Build me my dashboard with tabs and pages out of all these reports I have here. So that's not available yet. We'll have a separate webinar to cover that. We'll have more features in a semantic model, how to manage more complicated use cases of a semantic modeling. But as of today, that's it. Thank you, everyone. And I'm going to stop sharing right now, and we'll move to the q and a. Great. Hey. Thanks, Artyom. Yeah. Hi, everybody. So as Artyom said, looks like we've got about fifteen more minutes in the session. I do see a lot of questions rolling in, via the chat and via the q and a. So glad to hear that, you have a a lot of a lot of questions, and hopefully that that translates into a lot of interest in what we're building. So, I'm gonna read through some of these and and get Artyom started on answering, one, and then I will kinda start processing the rest of them. The first one, or, again, I'm gonna hand this question to you. There there's a viewer out there that asks, if we are building an embedded chatbot UX, how can we take advantage of d three? Great question. I think there are multiple ways you can, take advantage of d three here. So if you're building your own chatbot or agent and you're building it with your own back end and agentic logic, maybe using LandGraph or True or using your own, like, framework. But if you have an actual agent that is doing a lot of things and then you you know, like, that agent is communicating with your front end, I would recommend using MCP a to a integration for Qube. In that way is your agent will call Cube d three agents through MCP tool call or a to a, and then this can be used, you know, like, for agent to retrieve some data, for your agent to retrieve some data, and then do some action on top of that. If you're not you building your own agent, you can use our streaming API. We have, we have examples on a GitHub and, we again, the whole platform is still on a wait list. So these examples, we share them with everyone who is, working in g three. But once it's, publicly available, the examples will be publicly available as well. But we have examples where a simple Next. Js application and we use our streaming API to create this sort of like a chatbot experience. I've got kind of a longer question here. I'm gonna try to summarize it as best I can, but but there is there is a user, asking about providing, detailed, domain instructions to the LLM. Am I right in that we can handle some of this via, the agent workspaces and some kinda custom agent directions? This this viewer is asking about, you know, sending along some domain knowledge, that goes even deeper than maybe the the semantic layer. Yeah. Maybe maybe I yeah. Maybe I can just quickly share my screen here and just do that. So that would be possible to do through rules. And I I covered rules in my deck, but we just didn't cover them in a UI. So if we go into spaces here and rules, they live on a space level because space is think about space as a collection of agents. So you might have different agents, but they all share the same rules. So we have two types of the rules. One rule that is always being applied. Think about it. We add it to the system prompt all the time. The other is agent requested. That when agent can search, description and to see if that's relevant to use that rule based on description. So that would be possible to use rules to add more context to the, for agents that we we we usually recommend using rules for the things that see it's across the semantic layer. So in a semantic layer, in the model itself, you can use description to provide context for specific dimension or specific measure. But if you wanna, like, provide rules that are more holistic to the whole, semantic model, that would rules would be a good place to do that. Yeah. Makes sense. We did have a a viewer out there asking us to, you know, provide some commentary on on how Cube Cloud and and Cube D Three compare to open source text to SQL approaches like RIN AI and Vana AI. And I I think I think I know the answer to this, and I think Artyom kinda gave you the answer already, which is, you know, we don't really think of d three as text to SQL. We think, you know, text to semantic layer is a is an entirely different different animal. Artyom, I think I think you gave you gave some slides on this, but, I mean, if you have any other commentary about, you know, semantic SQL or what we're doing, then, yeah, go for it. Yeah. Again, semantic SQL is Postgres compatible SQL that is being used to query our data model. Right? We believe that, that that's a unique kind of capability to add a layer of context on top of the raw data. We will expose querying the raw data inside d three as well with the genetic analytics, but that would be mostly useful for, building the data models itself. So currently inside workbook, you can only query semantic player. We will allow to query source data as well, but that would be helpful if, for example, your data steward, your data engineer, you wanna build a new semantic model. And then, you wanna quickly prototype that calculation first, with a raw SQL, source SQL, and then you can use AI to help you write create that. But then you can say, oh, I like that query. Turn that query into a cube data model, then it can do that. But, overall, we believe that kind of querying semantic SQL, especially for the end user, makes a lot of sense for us in going to source SQL directly. Here's a, kind of a a good a good, observation and technical question that I think is interesting. There's a a viewer out there that asks, does the semantic model change in d three automatically trigger a redeploy? They noticed that they they didn't see it being committed and synced. So what is what is that process gonna look like? Yeah. We I entered development mode. When we enter the development mode of Cube spin ups, think about your semantic model is is is a server. So we run that server and it may run-in a production, but when we go into development mode, we spin up the semantic model server, and it's sort of like a development instance that has slightly less resource capacity, but it's still it's still semantic model. Right? And then it restarts all the time, so you didn't need to commit and say kind of changes to it. So you can test it internally, but it's only available in the development mode. And development mode is scoped to a specific user. So my development mode would be different from Brian's development mode. Think about it as like your local computer. Right? You develop software, you run it locally, you test it, you know, like, it looks good, then you publish it and promote to production. There is a viewer out there that asked, they mentioned that they have a data lake which has a lot of different sources. They, right now, mainly use Power BI to build dashboards and daily reports. They ask, where do you think d three fits in so that users can self-service using AI capabilities? Great question. So as I showed in, in my demo presentation, we believe that analytics shot could be a good place for maybe less technical users to self serve. I didn't show that today, but there is a kind of capability to search within existing workbooks, to find existing content, to, you know, like, obviously, slice and dice data so that would could be good for existing users. Maybe more advanced users can, use workbooks to do self serve. We also plan to integrate with well, we we already integrate with Power BI. Right? It means that Power BI can query cubes to monitor, but we will build some integrations with d three where, some of the work that had been done in cube d three would be it would be possible to ask for that outside of Power BI. So we believe while d three could provide a really superior experience, AI first experience to end users, we understand that, you know, like, the reality that organization is using multiple BI tools, and that's not going to change. So we would like to integrate, with existing tools like Power BI as well. Yeah. I think maybe to add a little bit to Artyom's, point here, you know, we we didn't really get into, like, a full demo of the the capabilities of Cube cloud as a universal semantic layer. But but one of the big selling points is, you know, we already support something like 35 different data sources at a at a very high degree of complexity. So, you know, anything that's in your your data lake or your cloud data warehouse estate or relational databases, those are probably already connectors that Cube cloud has today, and and d three will work right on top of all of them. So I think that's that's kinda compelling from a value prop perspective compared to other, agentic analytics platforms, which which are gonna have to catch up in terms of the number of data sources they they, support. And then as Artyom mentioned, we also, you know, have this high degree of support for existing BI tools and spreadsheets. So if you're in this period where you're adopting AI but you have to also, tie out results to other applications, Cube is is very well situated to do that. Let's see. We got about got about seven minutes left. Let's see. There's a viewer out there that asked, for queries that added ad hoc syntax in Symantec SQL, how would that look like in the workbook? So you just wanna maybe talk about how, like, what ad hoc process looks like a little bit more? Yeah. I think I showed some of that in my demo. They looked, sort of like a green. I can try to go back. Yeah. I I noticed that in this demo, and I I never noticed it before, but it it looks like we sort of borrowed the the standard Tableau coloring for these things where where blue is a blue is a dimension and and green is a calculation. Like, I I I just noticed that for the first time. Well, I mean, I assume a lot of people in this live environment. 70% maybe is the safe path, like, ever worked with Tableau. Right? So we don't wanna, like, change the coloring scheme that people are used to. So, just to save time, I'm not going to share my screen again, but the calculations are going to appear as green in in a table result. I didn't show that capability because it's not there yet, but it would be possible to save some calculations on a workbook level. So think about it like you may have a calculation that AI first created on report, then you can sort of, like, save it on a workbook level and keep it on workbook level for quite some time. And then if you're ready, you can kind of bring it into the data model. So once they save on a workbook level, they will be available on the data pane as a green calculations. Yeah. Kinda continuing along with that that line of, you know, how metrics are explained and how they're calculated. There's a viewer out there that asks, can d three explain how metrics are calculated in detail to business stakeholders? Yeah. Yeah. I I didn't show that, but there is a tab called description. So if you remember in my demo analytics shot, so you have six semantic SQL tab, you have results, you have chart, and then the results of description, and the description exactly contains this. It's just a step to step. Like, I took that number, you know, divided by that number, calculated the previous period. So it's kind of description of the calculation for the metrics. Let's see what else we got. There's a We also have some questions from LinkedIn live, I see. Yeah. There are there are a lot of questions. So I'm gonna I'm just gonna fish something up here. Well, there's a there's a there's a question that's been asked a few times. So I'm just gonna give you this one. I already know the answer, but, there are a couple people that are are are cube core users and the the open source version of cube user. And so they're they're curious about d three and its its prospects for making it to open source. Yeah. Well, that I think just from architecture perspective, d three, think about it as, like, your business intelligence, agentic analytics platform that is built on top of cube core. Right? Like, the we use Cube core semantic modeling. Everything is a Cube core. Right? But the things that we build around it, that's part of the commercial product. So we are not open sourcing that sort of, like, thing that it build on top of Cube, on top of Cube core. The Cube core remains open source and we continue to develop it. We're not changing license, so everything remains the same. But the the old platform, we're not going to open source that platform. We will going to provide some sort of, low entrance, sort of, like, cloud offering. So in a way that you can just start month to month so you don't need to, you know, like, commit to the higher amount if you're a small company or, you know, like a solid developer. It's going to be, like, a low entrance, pricing tier, for, Qubectree in future once we stabilize major features. Yeah. Makes sense. We did have a couple other questions from, from LinkedIn. I know we're also restreaming this on LinkedIn. So if you're if you're watching on LinkedIn live, you know, hey. It's great to great to have you here. There's a question from from that chat where somebody asks I guess I'm gonna characterize this by about, like, the collaboration and sharing features. They ask, can you share workbooks with coworkers and widen collaboration with AI to more team members? Yeah. You can share workbooks with coworkers. We will later add a possibility to share analytics shot as well, but, yes, we can share workbooks with coworkers. Think about it's normal, like, permission and level is coming from Tableau. Right? Like, you can give people just to view your workbook or you can allow them to edit your workbooks as well. And that it would be especially useful once we build the data apps because data apps are going to be connected to workbooks. So in many scenarios, you might wanna only share the data app that is built on top of your workbook so people can work with that data app. But workbook itself, you know, like, you don't wanna, like, let people edit it. But then in some cases, you won't wanna give the full access, to to workbook. Yeah. And there's another question here from LinkedIn live. Somebody asks, will there be the ability to prompt d three using API calls from other systems? I actually assume this is probably a to a and MCP, but, yeah, I'm curious your take. Yeah. I I think the closest functionality wise and use case wise that comes to mind is MCP or use case where you can, kind of, prompt d three agent through, say, MCP call and then, you know, and get a response back. But, again, we're also offering the streaming KPI, so it doesn't have to be MCP and a two a, so you can just call the streaming. It's an HTTP streaming endpoint. Right? So you just send HTTP payload, and then you got a streaming structured response back. Okay. We're we're we're one minute to go. I'm gonna I'm gonna ask the last question here. There's a a viewer out there that asks about if there's any ability to configure something like token limits since we're doing, you know, bring your own LLM. You currently, you can configure that on on your inference site provider. You might expose it, if that's would be, you know, like, a common feature request. It's just not a technical, limitation. But our current users, customers who are using their own model, they just do the stock and limit on their inference site. K. Makes sense. Well, we are at at ten Pacific, twelve central. So, yeah, I think we we've had a had a packed webinar and had a lot of questions here. So happy to happy to get those answered for you guys. I think we're gonna go ahead and wind it down, but if you are interested in d three, yeah, you can check us out at, Cube.dev. Hit us up on the contact us form. I'm sure that we'll be sending out some follow-up emails. I actually don't know what the marketing outreach is, but you you guys probably know how to find us. If if nothing else, yeah, contact us form on on the Cube.dev website. And, yeah, thanks for being here today. And, yeah, everybody have a good day. Thank you. Yeah. Cheers.