Read the full episode transcript
Generated from the exported YouTube subtitle track. Timestamps appear roughly once per minute and link back to that point on YouTube.
Today, I'm joined by Claire Gouze and Christoph Blefari, the founders of Nowlabs, a YC Combinator by company building an open source framework for agentic analytics. Claire is the co-founder and CEO of Now. Before starting company, she worked as a data scientist at BCG Gamma and later as head of data at Sunday, bringing together both the technical and business sides of analytics. Christoph is the co-founder and CTO of Now. He has spent years deep in the data world as a staff data engineer, consultant, writer and community builder, including work of companies like Freenow, Blavlakar and Kanto. Together they're building Now, which as I mentioned before, is an open source analytics agent framework that helps data teams create the context, semantic layer rules,
metadata interfaces needed for people to actually chat with and run analytics on their company data. Guys, thanks for joining today. And I guess the first question I sort of want to dive right into is one thing that I noticed looking at your story is that you both indicate that you were doing consulting before. And if you look at a lot of good tech companies start as consultancies. I think a lot of people here know DBT, for example, started as an analytics consulting company and through their experience of clients, they sort of figured out the product that was necessary and then they built it and pushed it out. So I was kind of wondering, what was your journey like? How did that go with the consulting
when you guys were doing this? And what were sort of the signals that you saw that prompted you to say, we need to build a product? Yeah, well, I can start on that. I think it's not only just consultant work, but it's being an operator in the data field, being in, yeah, consulting and then head of data. Like the thing I've noticed is every time data teams quite feel like a bottleneck. So like business teams often complain that the data team is not fast enough or available enough. And on the Aussie side, the data team feels very pressurized, like always busy. So that's, I think the moment where we saw it like, there's an issue about efficiency here.
And if we can use all these new AI tools that are created for the data team specifically, then we can make the situation better, especially because I think Christophe and I started thinking about building a company two years ago. So even before like Kerstar was saying, like it was just the start I would say of OpenAI as we know it today. So yeah. And on my side, like just AFox first. And then yeah, on my side, it's been like almost 12 years I'm working. So two years of now and before like 10 years of doing stuff like in companies. But like all in one, I've started as a consultant.
Like when I got out of school, like for two years and half, then I went like into like a data engineers in companies. And then I did five years of freelancing, which was like also consulting and stuff like this. So yeah, in my life I've done like a lot of stuff that is related to consulting. But in a sense, I would say that data ecosystem or doing data job is mainly like consulting. When you look at it, it's like in a lot of company support team in the whole company. And that tries to do like consulting and pushing ideas, pushing stakeholders to take decision to look at the right data, to do stuff, to move further with the company, drive profit, whatever.
You find the optimization that you want to find. And when you look at it, it's like consulting whether like from the outside or from the inside. But this is the stuff that you have to do when you are like in a data team most of the time. And even in this, I am a data engineer, I would say professionally, because when I got out of school, I did data engineering. And data engineers are even consultants within the data team to data scientists and data analysts. And this is the stuff that I've been doing like 10 years before governing now. I was building stuff for data scientists and data analysts to be more efficient in their job. I was trying to find the right tools,
find the right way to build a data platform for data analysts to be efficient, to be able to ingest data, transform data, this kind of stuff. And this is the stuff I like to do. And when we started exploring ideas with Claire, I was like, yeah, I'm good to build data tools for data people because this is the stuff I've been doing for 10 years. Interesting. I'm kind of curious. You probably have some interesting advice for this for the people that are currently trying to build a company. Like how does the process of finding a co-founder look like? I think mine was more chaotic than Christophe. I think it's really different for everyone.
Like on my side, I think I spent like one year searching for co-founders who I actually already knew. But basically I would say like, either you know someone that you've always known you wanted to build a company with, like maybe an ex colleague or a friend, and that's easy to find. And that's easy. Or you don't, which was my case. And then like, I just tried to meet a lot of people. I use the YC Find Your Co-founder platform to meet a lot of people, friends of friends, friends of colleagues. Like I met a hundred people, I think. And then none of that while I was working. So I was like, I want to build something in data. Who would be the
perfect person to talk to? And I thought of Christophe. And that's actually how we started like talking about ideas. I mean, it's important. I mean, it's important I would say. And on my side, it was not this way. I was like doing freelance for five years. And I was like a bit bored about freelancing because freelancing is like a solo adventure most of the time. And I wanted like to move to something that brings more social in the professional life. Like with other people, working on a project like every day and not just jumping into project from project, stuff like this. And I started to talk with Claire. And yeah, then we first just chatted.
And then at some point we said, okay, let's try something together. Interesting. I'm always really curious about like the people that decide to go and start their own company and like what brings them to that. Maybe a little bit of a crazy people, but before I forget this one, I've been thinking a lot of what types of tasks data teams should fully delegate to AI and what types of tasks humans like actually do by themselves. And I do think because of the product that both of you are building, you might have an interesting perspective on this. (audio cuts out) I think my spoiler first, and then I let Claire jump into it. I would say everything that needs creativity needs to be done by a human
and the rest can be automated. And the automation can be like AI or no AI, but like that's like the too long done rate for me. (laughs) Yeah, I would say then maybe like the two ends of the spectrum, I would agree with Christophe like creative stuff, you still need to do it because AI is never going to invent a new fresh angle on what you're doing. But I would say the thing I see is data teams are moving from being analysts to really being like context engineers. If they build strong foundations for the agent to work on, then they don't have to do all the low level analysis, data extract, et cetera. So I think we started working on data foundations
more and more with analytics engineer. And I think those same people that are analytics engineer, maybe they will become like more globally like context engineers. And then their two tasks go like building context and then only working on analysis that would require creativity as Christophe said. I say creatively, it's not like just drawing something on the page. When you look at what data analysts or data scientists have to do, it's like someone asked me a question first. And first thing, I have to understand the question. Most of the time the question asked is not the thing that the person want to get as an answer. Sometimes like the real question is not this one.
So first I have to be creative to understand the question, understand like what is the deep thing in it. And once I got the question, I have to be pretty creative in the leads, in the paths that I have to take to find like something interesting, to deep dive into the data. And then once I got all my analysis done, I have to be creative in the way to show the information for the people to understand the information and take decision on top of it. I would say this is like a lot of survey game or you're like an investigator and all the small decisions that you take as an analyst has to be creative, as to you have to see
the data in some way. And this is the same for data science, I would say the same in software engineering, the same in data engineering. Like when you have, when you are working on a feature, you have a bug and then you have to be creative in the way to understand the bug, to find the lead, to fix it and so on. And yeah, this is the part that makes us human. And I would say like there are like a lot of creativitin in the stuff that we do. The rest is like can be automated. Just to clarify, when you talk about creativity and you still want to delegate that to humans, is it because humans are better at it
or is there some sort of moral thing of like we shouldn't give away what makes us human, which is a little bit of what you mentioned at the end?
I think at the moment like AI is bad at it. It's more this way, not that human are better or are doing it the best way. I would say AI cannot do it. It's more this way. So is your perspective going to change in a few years when AI is better of creative tasks? If we have like other kind of models, but in the current state of the models, it's impossible. Like this is like with LLM, I would say it's not possible. It's hard to predict these things, but I guess the common thread I'm hearing
from both of your stories, so you call this security of the Polaris topic of context engineering. I guess a lot of these concepts are sort of hitting on the same vernacular when it comes to really the role for human in shaping decision-making, understanding what needs to be done. And that's something I want to focus on a little bit more on later, but just to bring it back to something more concrete and close to how work is done today. What I'm seeing a lot with companies I'm working with is sort of this inverse relationship between as you see like the use of agents go up and people sort of self-serving through Clod and attached to a database and a semantic layer,
you kind of see dashboard usage going down. So do you think dashboards are a dying breed for data people?
I think there are, I mean, I think static for protein is kind of dying. Like maybe we used to do like 80% of work on that. Like the dashboard should cover like 80% of answers. That's a lot of dashboards, a lot of context dashboards. And I think we should reverse that trend and be more like, okay, the global reporting we want to look at every day, well, maybe that's just like 10% of the data assets we're going to build. And then there's going to be a huge tale of FML dashboards because maybe you analyze this new feature and you want to build
this whole like dashboard because you can just like vibe code it in like one minute now. So I think we are going more into like FML analytics, FML dashboards, and then the static reporting becomes very easy. Also, I think because of the BI model and when I say BI model, like the BI tool model, it forced us in the past to use dashboard as a solution for a lot of questions. Like, I want to see the revenue, I want to see this, I want to see just yesterday performance, stuff like this. Or I want just to answer one question. It forced us because it was like the tool that we had to create a lot of noise for one answer to one question
that is just a number and stuff like this. So in a sense, for a lot of use cases, dashboards are over complicated, I would say. And so it's not because you use an AI to get to pull that number quickly, that it means that you're going to like remove all the dashboards. I think dashboards are useful in a lot of use cases, but there are like a lot of other use cases that we use dashboard for that are not the right solution in a sense, like for the whole surf serve and stuff, you cannot predict the full surf serve use cases that people will have. So in the past, we were like creating a lot of dashboards to be sure to answer all the questions
that they might have. So we got dashboard symmetry, a lot of dashboard and use and stuff like this. Now it's a chance to repair this and get just all the static dashboard that are necessary to see like the company performance, that is like the top down stuff that is super important to align the company. And then all the rest can be like just FMRO, like Claire said, I think it's like one time BI can be not named different way, but. What you're saying really is we've been over focusing on BI tools out of necessity, not because they were the best solution to what people are actually needing from the data. And what you mentioned, Claire's, you know, a BI dashboard
can almost be instantaneous with Claude. Now, I guess this kind of hits to a different conversation. Let's say data professionals or context engineers or whatever we're going to market ourselves as in the coming years are going to have of companies, which is they see, I can create a dashboard, I can pull data with Claude, I can do a whole analysis of Claude. How do I as a data person then say, look, but you do need a semantic layer, you do need some structure, you do need all these things. So we would get back to this age old question of explaining the value of data work in a way that companies do want to invest in that and work with you on this.
So how have you seen this play out with your clients and in your experience? I see like it's very easy to prove and I always try to compare to, you know, like companies before AI, they would just like plug their BI tool to the production database. And then at some point that's just like realize it's just a mess because everyone is looking at metrics in different ways. And it's like this whole machine that has like 300 long queries and that's just not working. And so like the business can realize that it's not working and that they need like this, like before ETL layer and now the context layer to make it work.
And I think today it's same, like we see teams that just like plug Claude to the warehouse and CP directly. And then they end up having bad numbers. And then they asked the data team to put something better and more curated with data co-vergence. And also I think this is more like organizational. If for the last 40 years we converged into having a data team that is doing stuff that is taking all this governance, thinking about data models, thinking about this, this is for a reason. Because the data people are the only people in the organization that want to do this ugly job that has to be done. Like understanding like all the businesses that are like saying, oh, this is the revenue is this,
revenue is this, revenue is this, blah, blah, blah and so on. And so because we converged in this, I think data model at the middle, I think it's not because we have AI that we will remove this kind of statue core in a sense. Job will evolve the way we do data modeling with will evolve and so on. But if we need this central piece of knowledge that align everyone at the company and yeah. I agree with you. There's definitely gonna be the need for that work. I think what we're seeing right now is sort of this people see AI creating magic really quickly and they're like, oh my God, I can solve everything. I don't need anybody, right? And there's usually a
lot of years of struggle, whether it's data teams or software teams or any technical role or the business is like, we need this and they're like, we need three months. And they say, I don't have three months. And now they're like, I can do this in two days. I don't wanna work with you anymore because you always used to take three months to do it. I think that Dosto probably said a little bit as some sort of the overhive goes down, I guess right now we're sort of in this time where we're kind of in agent shovel selling. So it's like, oh, we're just gonna stick as many agents as possible into every process that we can. In a way it's similar to the dashboard
she mentioned, right? Like, instead of being like, we're gonna create old dashboards. Now it's like, here's hundreds of agents.
So do you think we're gonna have an agent cemetery at some point, you know, what once the dust settles?
Agents are the new dashboards you heard that first year. The way you frame it, like, if we take now, you don't create an agent for everything that you have to do. It's more like you have conversation, you have like an analysis, you have one agent that fits everything. And when you take cloud code, most of the companies say don't create like a lot of agents to do this, this, this, this, it's more like, will we have artifact symmetries?
That's, I would say more the question about the symmetries, not agent symmetries, but more like artifacts, automations that runs and that no one, yeah, manage or own. Maybe this is the thing that we will face. And in a sense, if I just go back to what I just said, like who in the company wants to spend his mental load to just manage that stuff, it's data people. So even if you have stakeholders that are less saying, oh yeah, I can do my DBT myself, I can do my dogs, I can do whatever, I can do my automation. Who will wake up in the night, in the weekend to fix this? It's not the stakeholder, the stakeholder will never do this.
Like it's only data people that are like this kind of mental like strengths to do it. I like this concept of human curation because one of the way we talk about self-service, it comes from this idea of like the ultimate goal is to build a chatbot that answers all of the questions. But I do think that even in the future, there's gonna be room for people to, like data people to come up to stakeholders and say, hey, you didn't know you wanted to ask these questions, but these are the things that you should be seeing. It's similar to how you get the Spotify summaries and it's not something that you ask for, but it kind of makes your day. I could imagine us like coming back again
to curativity and to human curation. There's gonna be some room for us to come up with these creative approaches and like, you don't know you need to ask this to an LLM, but here is a dashboard with some cool insights that are gonna be helpful. That could be done by data and by agents too. Like if you prompt them well and I've explained them to the area where they can find insight, yes. Also in this, a funny pattern that we've seen and I've chatted with someone today about this. So we released automation and now, so now you can like have an automation that we run like at the schedule that you decide, whatever. And one of the first questions that I got asked was,
how can I run the same SQL query every day or can like be the output the same? Yeah, for sure. It's like a dog like we did in the past actually. But yeah, actually in the end, you want like every day or every week you wanna see the same format, you wanna see the same SQL query that you have validated. You don't want like an agent to like every day change the SQL query because whatever reason. So in the end, we come back and voice them to that engineering like we used to do. Cool seeing a lot of different companies now pick up, agentic workflows and put it into their process. Whenever I read some of the blogs, I kind of feel a lot of
people are going through the same learnings at the same time. You know, like let's say something like agents become smitcherer and there's like 50 companies that all start from the same point. They start building the same thing and then you read the 40 same blog posts of them figure out the same things, having built the agents. I mean, obviously you guys have done a lot on this front and helped a lot of companies build out these systems. What are some of the unexpected findings you found when deploying these systems? Like some complexities or problems that you didn't anticipate beforehand when working on this? I think for me it's not unexpected, but the main cause of like that agent performance is data modeling.
So yeah, I would say like 80% of context engineering work is actually like going back to doing data modeling. So yeah, I think that's the such truth behind all of this. I don't know if I have something in mind specifically. Yeah, don't have any answer right now. The second thing also that I see is that I think a lot of people just worry way too much about the semantic layer stuff. Like I think they have really like, I think like blocking them, they're all like, oh, before I build my analytics agents, I need to build a semantic layer. And I don't know where they got that from, but I mean, probably from some vendors that like preach for that, but like building a semantic
layer is like a lot of work. So then it just delays all the projects and I think they just like a comment straight that I see among all the teams. They just like, so like asking there are some questions around this. It's not about only the vendors, like just the community as a whole for like years said, you have to build a semantic layer to align everyone. And then when the agent came out, like everyone was saying like, oh, a agent works super well with semantic layers because it doesn't hallucinate and so on and so on. So this is like the thing that we are like in term of just the community converged on this, like for the last year,
I would say, but yeah. I'm afraid of like going too fast and I've heard many iterations of this, like no, no, no, we need to make a plan first. We need to work on the governance first. We need to do the whole data model before we ingest it. And I do think that semantic layers have like that role in the modern AI world. It's the kind of like the mental safety net of like, hold on, I need to slow things down and this is the way that I'm gonna create a bit of friction because yeah, like Claire said, people is gonna take a lot of work and you could start doing it. Of course your results are probably gonna improve
once you've finished it, but it's not per se like a full 100% blocker not having a full semantic layer. But I think that's something I don't really understand because like for me, when you want to start a project, you just need to build your baseline. Like you need to understand what you're working with currently. And when I think that when I was working in data science, like before building a data science model, my first step would not be like building a random forest with like good feature engineering, like no, like my first step was like building a model that predicts sales of this year is sales of last year. And then how good is that? And when I have this baseline,
then I start working on like improving it because then I see how it actually improves my baseline. And I think for me it's the same, like before building a semantic layer, just try to make an agent work with whatever you have. Like if you don't have a documentation, just like the schema of your data and see like how the agent figures it out with just the schema and then build on top like documentation and maybe semantic layer if it's worth it. But at least like just start with what you have. Love the messaging you have here. And it is so interesting because it is so contradictory to indeed like what a lot of the noises in a data world now
is we need to build semantic layers and these foundations and these standards and all of this work, preparatory work to get some work done. And essentially what you were saying is like, take a look at what's already out there and start building, start building something small and start getting it out there, start making progress. What will be some other practical tips you'd give people to getting from like a company that's using AI not at all or very like inconsistently, like people just using chat GPT here and there to a company running a couple agents in production doing something useful. My advice usually is to really be focused on specific use cases. So for example, if you think about like, I mean, if you build a lot of agents
and don't really build each agent right then they will all be kind of mediocre and have not very good context. Well, if you just like focus on one use case and like every time you do this use case, you improve the memory, give more context to the agent so that he gets better with time, then you'll get a good agent. And it's kind of the same we do with data agent. Like our advice is usually just like choose a data domain or a use case that you often do and make it very good instead of just like plugging your agent to the thousand tables you have in your warehouse and just like let it figure out. So yeah. It is definitely something
that I've also encountered with clients where, you know, you start small and at some point either you have like one agent that's handling too much scope or you have like a hundred agents that are all handling a small amount of scope but it's very hard to then route requests to the right agent at the right time. So at any point, like once you start build this complexity it's complex no matter how you spin it. So you're gonna have to have some techniques and some ways of maintaining it. What I'm really curious about, obviously you guys are building company in the space and you have an open source framework. I guess many people could argue, well, I don't need a framework.
I can kind of start building things based on what I have in my company. And that's maybe a good starting point but when should they reach out for a framework like yours? And like, in what use case does that sort of make sense for a team and a company to adopt? Maybe as a short reminder, both of us know what you guys are up to but I don't know if the people listening know what's product you're building and what it's also. Feel free to introduce it as you answer Tony's question. So I can like jump on this. So we are building now and now is an open source analytics agent. It contains two parts. The first part is a context engineering library
that helps you like from the CLI to just pull the metadata and all the contexts that you need from your database, your documentation, your repository, whatever you have. And we pull this context and we structure it as a file system that is easily searchable and browsable in an agentic manner. And once you have done this context engineering part, we give you the second part, which is an agent through a web UI, through Slack, through MCP that can look for the context and then answer a question by generating SQL queries or whatever stuff that needs to be done to answer the question. And just to give a precision, it's not really a framework.
Maybe just like the context engineering part is a bit of a framework because it's opinionated in the way we structure the context and we pull the metadata. But it's more like an out of the box tool to do like, agentic analytics or chat with your data. Depends like the vocabulary that you want to put in. It's more like tool on the shelf that you take and you deploy the company to do it. To be honest, it's not like marketing way to do it, but in five minutes, you can pull the data and then answer your first question. And this is the way now works. You do peeping store now core, and then it just works. And at the moment, we have some companies
that are trying to build this by themselves. So we have a framework like Langshain, there are a few out there. On this, I would say, don't do it. Even if I was like a data engineer myself, I would maybe do it, but I'm saying like, don't do it because building a chart application is such a pain in the ass. Because you have so much stuff to think about when today you are building a chart application. Like, how do we handle the streaming? How do we handle all the model routing? How do we handle the context engineering? And when I say context engine
ering, like the context window, the caching, how do you invalidate the tools? What tools do you decide to pick?
What is the same problem? What is all this stuff? It's really great like frontend skills to develop this kind of stuff. So I would say if this is not the core of your company, or you're not like a large company with people that are paid to do nothing, this is not like something that you have to enter in, I would say. That's funny because probably a lot of your clients, they need a few months after they hear what you guys do realize that doing it is not that simple before like they actually come back and like, okay, fine. That's something I could build in and out. Funny that they need to first experience that it's not as simple as it sounds.
Good intention because I think like in maybe last year, like people were more like trying to buy stuff, like buy a BI tool that is like AI native or like text-to-sql tools. And they realized that it was not working because it's really not flexible into in terms of like what you can personalize, customize the model is a black box. So you don't really know why it's not working. And so then the new trend was like building stuff, but the conviction that we have is that the added value of the data team is building the context and not building the harness for the agent. So that's why our context layer just like helps you build the context however you want to build it,
but we take care of all the agent loop that you don't want to rebuild. Well, there is a bit of illusion of vibe coding in a sense that with like cloud code, whatever cursor, you can build it by yourself and then maintain it and move on. Like this is, I would say a new illusion a bit because in the end, someone gonna need to maintain it. And maybe it's an agent that will maintain it like in the long term. I don't know, but I'm not sure it's a good idea. It's a trap that a lot of people are falling into. Now it's like going overdrive mode and building all this pent up demand and features that everyone wanted for like years
because implementation was slow and they kind of overreach and they build like this huge code base that have so much surface area that no matter what agent you throw at that, they're just gonna have a really hard time maintaining it. So I guess what you're saying there, which makes a lot of sense is it's about the long-term maintenance, but also like where do you cut and where do you add? Like what is like the core tenants of what you need in a system like that? And that's something that makes sense to buy. Also like creating a good UX and UI to chat with stuff, the feeling is getting higher and higher every day because like there is cloud, there is T
and if you build it inside your company, you will compete with these tools. And because you will have stakeholders that use T for some stuff, or they will use cloud for some stuff, they will expect an experience. And then you build it like by yourself by putting the thing like in a few week or in a week and then you release it and then you say, oh, that's the chat with your data for the company. Like this is the best way to fail because you're gonna provide like a bad chat with data experience. And people will say, it doesn't work. I will not use it. I will like plug my cloud to the Snowflake MCP or whatever. And then like it's the
best way to fail in a sense. So yeah, humans have always been, well humans, let's call it engineers have always been very bad at determining what needs to be building house and what you should like pay get us out or something. But you're right, Christophe, like it's only in the last few years that we had another dimension, which is the illusion that I could buy code is. So that makes the whole question of should we build it in house again a bit more difficult. But I think also, I think we are also like in a time where data teams want to learn about like agent to clips. Like I think that's also why they want to be in the house
because it's actually very interesting to learn like how to build an agent. And it's like a first great use case to build a analytics agent. So I think that's the upside of the things is like by building that they understand like how the agent works with tools, context, MCP skills and all. So maybe that's actually a good thing. And then like we'll eventually realize that it's not scalable in the future. But I think there's also this that makes people want to build in house. Problem making something because it feels fun rather than because it's useful or it makes it. The issue we see, but I understand the feeling. I want to add to that. It's just fun. It's also the ability to
develop your own experience and career, right? Like this is something I've been telling to all the junior engineers I've ever trained. There is always a Venn diagram of like stuff you want to build and learn and stuff the company needs to have built. And that overlap is usually quite small or big, depending on where you work, but people like to shoehorn like that whole left side of the Venn diagram, like everything they want to learn into the company, just so they can put it as a CV item. Like I did this at company X and I know how to do this now, which a grantedly is a fair reason to do it. But I would argue you can do those things if like projects
and portfolio things and all sorts of manners that don't interfere with like company operations. But I guess the more interesting question that comes out of that is then what would be the opportunities for professionals, whether they're consultants or data professionals working within companies, what will be the opportunities for them to like focus on with agents, you know, outside of building them, obviously in a company, like what would be sensible strategies from a career perspective to like focus on the next couple of years to kind of fit in that ecosystem? The thing on this, it continues like the thing that we were saying, like when you look at just before AI in a sense, like data and data teams and other people always add this
identity crisis with like, what is the ROI of the data team? How can you make data team like cost efficient, whatever? Can you justify the salaries that are like super expensive that we pay you? And so we always add this identity crisis in data teams. And the reason we had this identity crisis is because we didn't found what is like the product, what is the value that the data team brings to stakeholders and stuff like this. And so we always try to find stuff to justify our salaries and so on. So it's a bit like what we were just saying. I think as data professional, like going further in your career, what you have to chase is how can you
shine to people at the company? Or can you bring stuff to people at the company for them to be most more efficient? You have to empower people at the company with data. That is your mission as a data professional. You have to empower people to be more educated, to have people more educated on the data, to be more relevant when you look at the data. It's like very important, like this is data transformation in a sense. And this is the stuff that you have to do. And this is because Claire and I, we are coming from data teams. We don't want to replace data people. We want to help data people shine in the company by bringing a tool that people will love at the company.
This is the stuff that we are chasing for. Like we want them to think in the company as a team that you can count on, that can shine in the company and that people will trust, work with and so on. Because they bring this tool that people will love. This is like... If it answers the question, I guess. I don't know. I think another topic that people can really build experiments on is like context engineering as we were discussing it, because like if you look around you, like there are so many open questions on what you put in the context of your agent. Well, we talked about like, should you build a semantic layer?
Should you put some example of queries? Should you like restrict to 100 table or can you put like southern table? Like, I think we all ask this question, which means like there is no like market consensus on that yet. So if some people are able to experiment, build conviction, build an expertise on that, then they will be able to sell it to other companies. So yeah, I think there's a real expertise to build from scratch today on that. So beautiful narrative that you can take out of what you guys are saying, which is you should really be focused on providing outsized value to other people, making them look better, making them be more efficient, making their company work better.
And really, if we think about this, if you look at, you know, the progression from, let's say, junior, senior to a staff engineer, really, the big difference has always been enabling other people in the team. That's what it's always been about. And what I'm hearing from your stories, that hasn't really changed. That's still the goal, essentially. Provide way more outsized value to, you know, your company, the people around you, the community you're in, like what you guys are doing with the open source framework and all the community events. This is something we see repeatedly coming across with multiple guests in the data domain when it comes to moving the needle. I think a lot of people get sort of short-sighted,
so I want to achieve this shiny, you know, target right now, like how do I get there as quickly as possible without sort of considering the process. That's what you guys described. You've been like building a company for a couple of years, but it's really now after you've done all of that sort of foundational work that you're sort of seeing that play out into more adoption and more engagement and outsized value. Thank you. [Laughter] You mean to rethink a lot of the incentive with which you do things, because, well, indeed, a lot of things that you do because they're fun, they're useful for your career. You also think, like, no, the objective is to build something that is useful for the company,
but I also really enjoy, and that's something that is going to stick with me from this conversation, that you can actually build software to help the data to improve their value. And that sounds like a very synergistic thing where you're not like, I don't know, automating them out of the whole value chain, but actually putting them in the center. You should look at it. Oh, go ahead. I was going to say, like, small anecdote, like, I think how poor users, like, they all have a story of their CEO is like, I love now, like, I could do this analysis in one minute in my phone. And that's really cool for the data team to have, like, their CEO being really
happy about the tool that they, like, championed in the company. So I think that's proving that you can shine with, like, the tools you put in place. That's a good note to ask. What is next for now? What is next for you guys? Can people find you? What should we expect coming out of now? Like, what's in peto for the future? Go ahead, Risaf. She wants you to talk. Yeah, on this, I can just say, go and get up and give us a start. This is the first thing. That's our future. Yet now slash now, this is open source. You can see everything that we are building, like, in the open. Because, and to be honest, like, we are, like, the only company doing this kind of
tool, like, in the open. So, and the thing we are building, we don't sell tokens. We don't sell this kind of stuff. This is, like, fully transparent the way the stuff and the context is managed. So this is, like, we love to do this because this is, like, super interesting. And we have, like, different kind of conversations with people then. And what is the future from now? This is, like, more companies using it, building, like, this community around agentic analytics. Because we think that having data people, and when I say data people, I say data analysts and data scientists, in a sense, being equipped with their agentic tool to go faster, deeper on the stuff that they do.
This is, like, the future, in a sense. And in terms of features, we are, like, super cool stuff that is coming. I don't know when the podcast will be out, so I'm not, like, saying any feature. But we have, like, cool stuff, and we have, like, super ideas to make, like, the future agentic. So, yeah. Listening in. Now we're just going to spend 10 minutes talking about features. So, yeah. [LAUGHTER] Some stuff to add, Claire? No, I think pretty much everything. I think now what we're trying to work on is re-scaling that to enterprise setup as well.
I think the open source side really helps, because then it's very easy for big enterprise to deploy in their company, but there's also a lot of challenges of, like, data governance, permissions, et cetera, which are also challenged with AI. So that's also what we're solving at the moment. I mean, just give Claude unlimited access to your whole data warehouse. That's the solution. Of course. [LAUGHTER] We all see the names every now and then of, like, oh, sorry, I deleted all of the rows, even though you told me that, too. This is, like, this is a joke, but this is, like, a cool architectural question. Like, do an agent that runs from, like, an analyst or a stakeholder has to impersonate
the person that runs it? Like, in terms of, like, the enterprise context, are the actions taken by the agents owned by the human that owns the agent, or is it owned by the general API key, an API key that corresponds to the group of people or the domain? This is, like, a cool question, and companies have different answers to this, I would say. Such an interesting area. There's a whole philosophical debate toward a legal boundary lie of this, and I think you're at the question right on there. That's going to be very interesting in the coming years. I don't think anybody knows. It's a bit of the Wild West out there still.
Kind of fun. We're all just shooting our agents around, and we'll see what sticks. There is the model, the use for all sorts of perspectives in which you can dissect this. Well, I would like to thank you again, guys, for joining. This was a wonderful conversation. This has definitely been the most educational when it comes to building agents for analytics that we've had so far. So, thank you again, and we'll make sure that everyone can find all of your stuff in the links down below. And, yeah, we'll catch you around.