Text to Data Products: Kaarvi’s End-to-End AI for Ingestion, Quality, and Dashboards

Tobias Macey: Hello and welcome to the Data Engineering Podcast, the show about modern data management. This episode is sponsored by DataDriven IO, the free data engineering interview prep platform built by data engineers for data engineers. Have you ever walked into a data engineering interview and gotten a question that has nothing to do with real data engineering work? Interviewing is its own skill separate from the job. Watch your code, execute live, inspect spark internals and whiteboard your data models and pipelines and defend your decisions. Unlike, um, SQL only or Python only, practice DataDrivenIO covers the full interview. Star schemas, slowly changing dimensions, grain and fact, table design, item potency, watermarks, dead letter queues change, data capture and backpressure. Every question comes from real data engineer interview loops at Google, Amazon, Meta Stripe, Databricks, Netflix and airbnb. Go to dataengineeringpodcast.com datadriven today to start practicing. Your host is Tobias Maci and today I'm interviewing Sravan Gunda about building an agent driven data platform at Carvey. So Siobhan, can you start by introducing yourself?

Shravan Gunda: Hi, my name is Shravan Gunda. I am the CEO, uh, and founder of Carvey, uh, Carvey AI and it's nice to have here. Yeah.

Tobias Macey: And do you remember how you first got started working in data?

Shravan Gunda: Yeah, it's um, I think 20, 21 years ago I worked for HPE where um, we were doing this massive migration from old HP12K and HP24K luns to their new 3 par, HP3 parlance that they got on and we were moving live production data and uh, that was a very critical project. So I got introduced to Data World. There, uh, the data problems, what organizations deals, uh, uh, every day they deal with so much of data problems. And that, that was a very, I think realistic on my face view of okay, this is how the data world looks like because before that it was all application perspective where everything is nice and clean. But when you go into the backend, actual data works I think, um, yeah, it's totally a different.

Tobias Macey: And so now digging into Carvey itself, can you give a bit of an overview about what it is that you're building and some of the story about how you decided that this is where you wanted to spend your time and focus.

Shravan Gunda: So I worked as a vice president for a, uh, known oil and gas company in the past and also for a prominent financial company where all we were doing was building complex architectures and also solutions to deal with data again from end to end process, right from ingestion to where it gets out as A transformed uh, desired uh, output. So there was this complex, I mean millions of dollars and also headache to just maintain and support those new technology pipelines, ETL pipelines that we built and every asset that we dealt with required like thousands and hundreds of solutions. And merging them, uh, making sure what the desired output looks like was a huge, complex issue. I think that's where the idea started for Carvey, where um, you know, we, we deal with multiple different platforms for making data ready. And when I'm talking about data ready, uh, for example, if you want to ingest data from a SQL database, you write thousands of SQL code depending on what dataset you're dealing with. And from there, um, you're talking quality issues, uh, profiling and fixing and anomalies. So every process here, we just spoke about three of them, but uh, then go into um, transformations, then talk about lineage governance. So everything here requires data readiness, uh, for an application solutions perspective. Because these solutions are out there, but those are all siloed into their own capability perspective. Like, oh one, one application only deals with um, transformations. The other one deals with governance, kind of. So where you spend 80% of your time in data readiness rather than spending on actual uh, creating value. So most of the data engineers that I saw were doing general work, uh, rather than doing what they're supposed to do. Uh, and in the past too, I, I mean this is my team, um, whenever we introduced a solution which could uh, ease up their janitorial work, which I just spoke about, uh, they were very happy. So. And as a vice president I was actually also concerned from the business perspective where if the overall project value was um, uh, let's say a hundred dollars, 80 were going just for the data readiness. And that's how much m wastage we had in a project timeline. So that was the main idea for Carvey, where you have so much of AI, uh, agentic AI, uh, at this time where you can offload your other work of data readiness and make sure you are focusing on what insights you want to build. So that was the main idea.

Tobias Macey: And so now digging more into the core premise of carve being this AI native data platform. AI as a category has been used for a huge number of different considerations over the years as the capabilities improved. When you say AI to somebody today, most likely they're going to think of one of these generative transformer models, whether it's an LLM or a multimodal generative model. But for something like a, uh, data engineering pipeline, there are a lot of different types of ML M and AI that can be beneficial, whether it's just a straightforward classifier that you want to execute quickly in a loop or, or if you want to use some of the more agentic LLM style capabilities of some of the modern frontier models. And I'm just wondering if you can give a little bit of disambiguation about the types of AI that you're using in carve and how you think through those different use cases of what category and size and capability of model you want to use for those different junctures of data flow.

Shravan Gunda: That's a great question. So to start with AI again, this was a buzzword in the past from 2018 when we were dealing with a, um, huge uh, NOCs who sell their automation as AI. So most of the NOCs were uh, applications that were sold to NOCs, national oil companies. In this case the buzzword was AI. So if you go and if you, if you present them in automation, I'm not saying they're dumb, but it's basically saying the word AI was abused in a point where you just present an automation and say this is something AI driven. That was like a wow factor in the past. I'm talking 2019 before all this crazy agentic AI came in. Right? So what's the difference at this point of time? And you know, Anthropic or uh, OpenAI or all these major companies that are actually competing with uh, and you see a model being deployed every two weeks, three weeks these days and there is an enhancement again. So rebuilding the whole wheel was not an option anyway because in the past we were actually dealing with uh, regenerative neural Networks. That's in 2019. Right now that's gone. We are talking agent tech, which is basically halfway there on the LLM side where you can actually utilize. But today the main challenge with any LLM uh, in the market is they are 67%, 64% accurate. What do you mean by that? Is, um. So if you ask um, uh, LLM chatbot, just upload your data set and ask any question, the reliability of the answer that you get is basically 60% or 64%. And if you are a, um, heavy LLM or agent, uh, user, uh, you would know that after certain iterations it goes into its own loop and it starts answering uh, the same answer no matter what the question is. So, so it's basically unreliable. I wouldn't say unreliable at 100% but at least that 40% unreliability is there. So what we did for a carvey perspective is we are using again we didn't want to rebuild the whole uh wheel so we have our proprietary coding that we did. But what happens is we are using around 7 LLMs, uh in the back end where when your query is processed or your request is processed, uh, each again we want to keep it completely agentic. We didn't want it to again these uh, days like I said, agentic AI models get updated every two, three weeks. So the challenge with the keeping traditional coding route is basically you have to update your application every two, three weeks to match that level of enhancement. And you know that those companies spend billions of dollars, millions of dollars on development and when you come to the traditional uh, startups like us, we cannot keep up with that development. So it's better, we thought it's better to incorporate those LLMs but have a uh, uh process of the main challenge was reliability, right? How do we get the reliable 100%, 200% accurate answer when you ask a query or request a process. So for that reason we went with this parallel regression where a query gets executed via uh, seven LLM models at the same time and compare their value with actual. I'm just taking an example, you're asking a SQL query question. So the training was done for almost two and a half years on this perspective where how to get the reliable answer where traditional SQL query was running in parallel, where you get the accurate answer in the real time um world. But again compare every LLM that has uh, processed our own uh, so we spin up our agents and those agents were getting trained on the actual process that was happening uh, from the traditional code perspective. So that's how they got trained. And at this point of time if you go log into Carvey with your uh, personal email, which you can do today and try out the answers that you would get, you wouldn't see any fault because of that reason the more training it went and these traditional agentic AI uh chat, I mean the agents that are sitting and serving um, uh, Karve are also learning while we are operating. And you know that loop we generate right? So basically our traditional code base is executing, taking, taking use cases that every day that's happening and training our agent models. So that's how we are keeping up with the development process. Uh, again it's very hard and these days to go the traditional route. So that's why we opted out this route to train our models. And before I think even speak about our models and agentic features, I would talk, I would love to talk about the features that carvey offers today. So just to give you a brief on what Carve it as. Again I spoke about Carvey as a platform not a product and we always wanted to keep that as a standard. So what's the difference between a product and platform in my view is product gives you. Let's say you got your uh, Apple AirPods. So they're only going to serve as a audio uh rather than anything else. So that's a product. But if you go buy a laptop again you can see the possibilities there. Right. So the basically it can be treated as a platform where you build stuff. It goes same with our current applications too. The ones that I love are uh, Facebook and Amazon. The, the, the way they have the flexibility to build a product on their platform. So we, we treated Carvey while developing Carvey. The main idea was to build a platform. So today Carvey uh, deals with end to end data management. What do you mean by that? Is no code zero code ingestion. Uh and it has 300 uh, it supports around 300 um ingestion types at this point of time along with drag and drop for um, managers who doesn't really know how to even connect a database at this point of time you can drag and drop your SQL sorry uh, uh Excel or CSVs. It takes it in from that to connect your databases to API ingestions to cloud ingestions. So any cloud storage you can ingest, any API ingestion you can directly ingest, you can connect any live database or you can drag and drop your CSV. That's the ingestion part. But once you get there you'll quickly get a um, preview of what your data is. So the current state of data will be, will be clearly in depth. You'll get an in depth view of what your current status look like. Like current state of data look like. We also have Synthetic Data generator which actually supports uh test uh generating edge cases on the go. And at this point of time we are supporting million rows and 150 columns and uh, that's how much not just the Synthetic Data Generator but the whole platform. So what Synthetic Data generator has uh, the unique feature that, that is uh Carvey serving is basically you know you can generate your edge cases with any prompt these days uh any using any chatbot like OpenAI or LLM. But end of the day you have to keep fighting or refining your uh prompt to get your actual data set that you desire. Right. So that problem is solved in Karby where you can refer a data set original data set and mention how many rows you want and how many columns you want. It's going to generate exact replica of that original data set with random uh, numbers in it. So that, and, and, and it's going to copy the type too. Like if the column is text or boolean to integer to uh, string to whatever that reference is, it's going to copy exactly that type of data into the test data. And you'll. There you go. I mean with the click of a button you'll have a test edge case to test. Right? Um, you don't have to fight with it m the prompts to keep refining it. And the other thing is you can generate and quickly import like save to catalog where we have this catalog where you can get to go. So it's not like okay, I'm generating a test use case on another platform which again there are hundreds of applications that support that. And the problem is how to inject is there that that test data uh into, into your production or the platform where it actually tests. So you want to test it. So uh, even those uh, direct push to database, push to API, push to export to cloud or download as a CSV Excel is also provided. So that's synthetic data generator. So we have just spoke about exploration how uh, your current data state looks like and also synthetic data generated that supports edge cases. Now we are going to profile and fix where you can profile your data, find quality issues, fix those quality issues with AI. So what it does is it's going to list out all your quality issues, categorize them into different issues, uh, the various types of issues that you got and then bundle them and you can take them and fix them using AI. And it's going to show you a preview of before and after before applying the preview so that you know exactly what you're uh, after preview after a fix would look like you're happy with it. Uh, click on Apply Fix and it's going to do it like. So we followed this process where we have so we, we use JIRA and project management to track our uh, tasks and if you are a big project management user. And so we compared with a Sprint, like if any task that is taking a Sprint, which is two weeks, uh, which is traditionally eight days of work, you can do that in four hours on carve. And that was the goal that we wanted to achieve on carvey. And that's huge right when compared to eight days to four hours. So that's the quality and fix. And then you can go into validation, Carvey supports, validations, cross Field validations to anything to do with validations. So you can go ahead and we have like um, I think 10 kinds of validations that we support and I would love you guys to check it out and then you can jump into uh, anomalies so quality issues, fixed validation is done. Now you have anomalies in your database, a data set run through AI, it's going to find it out. And if you don't trust AI at this point of time, like some people doesn't really trust AI to go fix, manipulate the data you can. We also provide manual, uh, um, methods to fix your quality issues, anomalies and validations. So all of them has manual approach. All you have to do is click the tab manual and then um, do your stuff there. And from there we are also providing temporal intelligence which is basically any trend, degradation, sudden spikes, sudden drops in your data set, you can live monitor them. And whenever there is that, uh, you get notified and it tracks and it keeps a track, uh, of 30 days, uh, 90 days and 180 days at this point of time. Uh, you can also subscribe to Enterprise and get your uh, and now we are talking about just uh, quality and fix.

Tobias Macey: And so with the AI driven design of the platform, obviously that changes a lot of the assumptions about the nature of the work to be done, how you would approach that overall work, and the utilities and technologies that you would bring to bear on the problem. So setting aside the technologies piece for a minute, when you talk to a data engineer and say, hey, I have this particular use case, I need to be able to do analytics on the number of customers who abandoned their shopping cart over the course of a given time period. Whether that's days, weeks, months. They're going to have some ideas of, okay, well I need to collect this data. I need to make sure that I have this modeled in this particular fashion. I need to wire this up. I have these assumptions about data quality. I need to ask these business users these questions for clarifying what constitutes a customer, what constitutes abandonment, et cetera. And if you are using the AI as the core loop of the implementation, how does that change that overall approach for the data engineer? What are the pieces that get obviated because of the fact that the AI can do some of that discovery on its own? What are the pieces that become more important because the human needs to make sure that the problem is actually solving the business case, etc.

Shravan Gunda: That's a great question actually. So there are two approaches on Carvey that you can do. One is, hey, carvey the other one is Transformations. So a data engineer traditionally had to follow your route like what you just explained. Right. On Carvey, we support, in transformations, we support something very interesting, which is you have to articulate your requirement and it's going to build a pipeline for you. It has something called code block. So what do you mean by that? Is it's going to write its own, own code for filling up the gaps. So what do you mean by that? Is basically once you said, okay, hey, I need to find and this is the exact pipeline that we're building. Actually that's pretty interesting. So our, uh, cmo, he came up with this use case where he uh, wanted to track any customer that was spending more than $5,000 and were also not regular and try to lure them with 50% discounts. Right. The coupon only for those people. Now there was this huge data set where we had to filter out. First thing is filter out the $5,000 spent on a month monthly basis and then make sure all the data was intact. So every, every column has had a first name, last name, email and all those data. You know, the reliable reliability of the data and then quick validations. And then, um, we had to, you know, write the ETL pipelines to transform all these requirements and then kind of feed that into a notification system which actually, which is basically a CRM, uh in CRM out. And then from there you, you are actually talking to your hotspot or some kind of, uh, platform which is communicating with your, um, you know, customers. Correct. So all this happened. Usually a data engineer would do all this, but, uh, surprisingly in Karve, you can actually articulate the requirement. And um, the transformations module, there is this canvas which actually resembles INIT in kind of, you know, the, the flexibility of moving the front end, um, visualizations, if you already used init and then you could visualize and compare it actually builds the whole pipeline for you. All you have to do is map the output and test it out. So now if, if you miss anything. So if you see. Oh, now. Oh, uh, okay, I missed this part which my requirement was this. But you couldn't. This. It actually goes and recorrects it. And again, this would sound like a magic. But this is possible today, uh, with Karvi, where data engineers doesn't have to do all that like the traditional route that you just explained, they can articulate in plain English in transformations module of Carvey. And it's going to build ETL pipelines for you on the go if you want to do it yourself. You can still do it. Again. We gave a code blog which supports Python and SQL. You can write your own mappings, all kinds of transformations, but you can also ask AI to do it. And it's going to do it if that answers your question. And you should really check that out. That's you know, magic I would say. And I spoke about. Hey Carvey. This is for more because I was a manager, uh, people manager and I know the pain of uh, other managers who had to go through it to get what they want. Uh, we built this hey Carvey chat again, not just analytics, we support transformations. So basically you can ask your um, data admins to give you access to the database or you have that access to the database. All you have to do is import again with no code, low code two, uh, hundred percent, no code actually, and then select the data set and keep chatting. You can ask. Hey Karvi. Hey. I want customers uh, who are spending $5,000 every month to list it out. It's going to go get those customers put. So it's going to give you three outputs. One is uh, articulation in English of what that output looks like. Next thing is the visualization part. It's going to build custom visualizations for you and then it also going to transform and give you a whole table which is ready to export. So you're chatting to the data, it's going to get all the customers list with first name, last name, email or whatever your requirements is, along with the criteria that, okay, they are spending $5,000 a month because that's the use case and from there you can actually have an export for that particular table you can export. So this is also possible via uh, hey Carvey. So two kinds of methods you can follow

Tobias Macey: and digging into the infrastructure and design of the platform, wondering if you can talk through some of the overall system structure and the decision process about which pieces you can pull off the shelf from various open source components and what are the elements that you decided needed to be core to the platform offering and engineered from the ground up with this AI focused use case, the

Shravan Gunda: whole platform was built with wipe coding actually from ground up. We didn't, did not use any open source. I mean the initial idea, four years ago when this idea started we had multiple, I would say open source platforms that were actually serving as you know, fillers I would say, or ground up where we can start building on those. But when we started building this and as the uh, AI advanced so well, we actually wipe coded 60% of the platform from scratch. There is nothing that we used from open source. I would say in Transformations module we have multiple features like you can publish the pipeline that you built with AI or manually as an API. You can also publish that as a dashboard. So it also serves as a visualization, so the output can be a dashboard. So it actually builds gadgets on the go where it's, it's there. Right? So those converters, we used it from multiple uh, outsourcing, you know, open source, uh there where we are converting the actual pipeline into an API. Those converters were actually open source, but other than that everything is wipe code. The other uh, great feature that we have is um, you know, people, uh, most of the managers, again we are talking about not the technical side of the world where everyone understands how to build. I mean the technical world understands how to deal with data, but the, the huge gap between the data uh world and the manager world is basically the technology. Right? So the, so for those guys we built um, your text to dashboard so you can actually map your data set and ask what you want to see or what dashboard you want. And it's going to build the dashboard. If you don't give anything, it's going to build a dashboard for all of it. So those converter is those converter, the converter that I used to build this was also uh, open source.

Tobias Macey: With the fact that you're building it all from the ground up, there are obviously a lot of existing patterns. A lot of the open source and commercial offerings in the ecosystem have been battle tested over numerous years. And so given the fact that you are re engineering this from scratch, what are some of the ways that you've approached that confidence building aspect of knowing that you have accounted for these various error conditions and edge cases that a lot of these other platforms have been investing in addressing for all of this time as well as ensuring that you're going to be able to interoperate with all of the rest of the ecosystem because not everybody is going to immediately drop everything that they've got and move wholesale onto Carvey. They're going to do it in an incremental fashion. And there are also going to be elements around the periphery of what Carvey is executing that still need to be integrated with. So I'm just wondering how you manage that scale of complexity when you're starting from scratch.

Shravan Gunda: That's a great question. So like I mentioned in the past, we had this traditional route where we were building an application. We're using uh, open source, but we were also training our uh, agents in parallel with the traditional route. Right. So those agents got trained on the actual application. Like traditional route application. That was, that was a norm in the past. So I'm talking four years ago. You don't, you didn't had this kind of technology in hand to build anything from scratch, like on wipe coding. Correct. I mean end of the day you would end up with multiple issues and you're wasting time. Uh, so we followed the traditional route to build but using open source. Uh, we built that training, I would say sandbox for the agents to get trained. And I think I already mentioned that we have been training these agents from past two and a half, three years. Um, so those agents got trained on those. So if you go and check the patents that currently Carvey has, you would see more kind of an agentic AI, proprietary agent, AI agent of Carvey doing stuff and you would see more kind of um, LLM calls parallel multiple single shot. So these kind of patents and what we got is again the process like text to dashboard. There is this uh, companies who are like huge, who got patented on certain processes. But you know intelligence, when you come to the intelligence that you got out there today that can support your dash, uh development process, it's super. I would say the method that we are using is not being used anywhere else. So but it was battle tested by the methods that already existed, if that made sense. So it actually tested, battle tested on the uh, open source processes or applications out there. But um, we had to customize it enough to add our flavor and um, I would say what carve we stands like the platform. Right. So we had, even though our agents were training on those particular solutions, they were always contributing towards the platform as an end to end platform rather than um, a product. So I would say we only got enhanced with what's out there rather than building it from. So when, when I say building it from scratch, we still considered all the standards that is required to build that solution, but thousand times more on, on the capability side and that's how we

Tobias Macey: got there from a design standpoint. AI is obviously a force multiplier, but it is also inherently probabilistic and not going to be deterministic without a lot of extra effort. And there are definitely elements of the entire data engineering process that need to be deterministic and repeatable and reliable. And so I'm curious how you thought through the appropriate roles of AI in that end to end lifecycle and where it should live within the Carby architecture and also how to manage some of the concerns around data privacy. And data access for somebody who is relying on Carvey and providing access to the organizational data to these different models, et cetera.

Shravan Gunda: It's a great question again so I came, my background is from oil and gas, right? So you know when I say that that means we, and we built predictive analytics and data uh, analytics applications in the past. So the main problem was sharing data. No company wants to share data outside their ecosystem. So we built Karvey for um with two flexibilities. One is basically you can install Carvey on your environment. So there is no SaaS there. It becomes your own product and the solution that builds and it runs on your private subnets. No uh, Internet needed to run Carvey, so there is no Internet access. Uh, we only wanted uh, uh to have a billing API access. And that's a put it to get the validations. That's a solution for people who doesn't like to share Data with uh, SAS. And uh, the other one is the traditional SaaS model where you are okay to share your Data with the SaaS platform but end of the day you get your own container. Right. So basically the architecture part of ty. So these days all the tasks that run on Carvey is encrypted. When I say we took that extra measure of security because I'm um, I'm also an AWS architect, a uh, solutions architect professional. I come from the background of Linux. I grew up with designing infrastructures for enterprises. So that's my core mentality where you come in to build a solution. So uh, we are having multiple password encryptions. You can actually set passwords, you can publish those APIs with tokens that gets uh, you know, changed every or replaced every three days. Custom like you can actually set a custom time to expire. Nothing lives out of your control. As a admin or a uh user yourself controls all processor platforms. Like who can see what you can actually share to a particular user. If you're building a solution you can only share that. So from the architecture standpoint once your user, you, your organization gets created, it lives in that container. Nothing leaves that container and no Internet access is required to run the CAR View application. Again if you're not comfortable with SaaS, you can deploy Carvey on any virtual environment. Hyper VMware, uh, even Proxmox, any kind of virtual environment, we support that. So we have our um, images we can deploy and everything comes with that image. But the only, I would say a hiccup or the things to consider when you're using an on prem is Basically you won't have those um, updates that you get on SaaS. Right? So that's the trade off. Uh, but you have everything to run and um, we also have a mechanism to keep your on prem updated but not as live as SaaS that you would see. So that's an interesting architectural design we took for uh, customers who doesn't like to share data out of their organization.

Tobias Macey: One of the other pieces of the overall AI landscape is that there are cases where a foundation model is just fundamentally not going to have enough domain expertise to be able to make appropriate decisions for particular data cleaning. What are the rules around a particular structure? Some of that can be addressed through things like knowledge retrieval from rag or knowledge graph patterns. But there are also cases where you're going to be best suited particularly from a cost and performance standpoint by using a fine tuned model. And obviously there are cases where maybe the organization doesn't want to provide some of that data to a paid platform to be able to execute that fine tuning. And so I'm wondering how you're thinking about some of those aspects of control and what are some of the escape hatches for your customers to be able to provide some of that customized logic or customized models to be able to execute within the actual carby platform. Also mitigating any potential risks or liabilities that you're subject to by running somebody else's models and information in your platform

Shravan Gunda: at this point of time for the on prem delivery system uh, that we have, you can always have so you have 100% control on the technology that comes with the on prem. But um, for um, the one to train your own models at this point of time for SaaS I don't think we have that ability. The fine tuning comes with, I think the process that we want to follow uh, for this solution or we are in the process of following is basically dedicating hntic based uh, solution by organization. So if you're an individual user you get your own agent and that you can actually train by yourself and it is your agent. No one else is going to train or use that part of the technology. So uh, that's the road we want to go. By end of 2026 you will see that coming up.

Tobias Macey: And as you have been building and operating this system obviously there are numerous edge cases that come up. There are, there is a huge amount of ongoing work that you need to do as new models come about, as you add new tools, as you add new context. And I'm wondering what has been your overall approach and how have you thought about the core investment of being able to evaluate the effectiveness of the various AI and the different use cases that you're employing it for to ensure that it is operating, operating as effectively as possible and that you can evolve the system with confidence?

Shravan Gunda: Correct. And um, that was our core problem to start with. Right. So that's why we were like okay, how do I solve the reliability issue? Because today AI, ah, when we started at least the AI was not 50% reliable. At that point of time it was still in 30s. So the process has been always stick to the core, stick to the basics, train your models based on uh, based on those basics. Rather than going now I have an A.I. lLM uh, that I can just import, uh, or get an API access and start building an application on it. That was not at all the approach to start with. The we followed the basics 100% basics. We built the basics where AI can operate as an additional force multiplier rather than, rather than okay, now things happen on AI 100%. The output that you get is um, what do you call the. Processed at the speed of light by AI agents. But they all got trained on the traditional route. So if you ask them to do some kind of a task, it's going to first check its traditional routes and it's going to give you options where you choose which option to execute. So that's the carvey route. Rather than saying hey, I executed this now this is your only option. This is the answer that you deal with now go deal with this output. Right. It doesn't do that. It actually gives you options and then you can always. It's like a. I'm sure most of the uh, listeners here would have dealt with uh, training ML models in the past where you have to reiterate it trade to get, to get the model output in carve. That's possible. The same approach is possible because go it with quality or uh, anomalies or building transformations or dashboards or just chatting with it. All you have to do is refer to that data, data set and keep asking questions, right? And you can keep the iterations going on until you get what you have. So that's the beauty of carve like you and, and it happens, it eliminates all the janitorial work like I said and all the additional traction that you have to spend so it, you can focus on that output. So this is the output I want and I know that and you can keep doing until you get that out. And again the testing that we are doing in the past in the, in the back end we are only targeting. So there, there is a dedicated testing team or I would say process for each lateral, let's say oil and gas. So there are agents that are getting trained on only oil and gas data. So when you are signing up and you start uploading oil and gas and the uh, back end sees, or the AI sees that it's well ID or some kind of reservoir name or something, it's going to call those agents. So there are agents that are dedicated and if it sees finance, so those agents come into play and if you see anything to do with um, pii and that's a huge thing, right. So there are agents that got trained on piipi, they don't do anything else. So the architecture is in such a way that it intelligently routes orchestrates that particular task to those dedicated agents. So it's, that solves the problem of now there is a uh, there is, there is new lateral that comes in where we had to train. I think we will at this point of time. But we covered most of the, what do you call the market data uh that's available, the open source data. The open data we are available. They got trained and they got trained on I think we, we ran around um, I think 11 petabytes of data per lateral. And um, uh, when I say lateral I'm talking domain, each domain. And those were like huge, uh, multiple thousands I would say of use cases that they got trained on. So that's, that was the route.

Tobias Macey: And as you have been building this platform and working with customers, what are some of the most interesting or innovative or unexpected ways that you've seen Carvee used?

Shravan Gunda: Again, that's a great question. What we are seeing is customers coming up with satisfaction, uh, and also uh, the awe movement where to see the output. They had to again go multiple iterations. Because again when you're trying to convey the requirement to what you want, end product, end result, let's say I'm just taking an example of a power BI route where a whole executive team is dependent on a dashboard that actually requires for them to take a business decision. Um, and this is just one of the very simple use case that you can do on Carvey, but there are like complex things you can do. But I'm taking this for um, everyone to understand. So the traditional route is we scrap all the uh, data sets available from an ERP system, load it up into SQL database, then process it to make sure the reliability of that, the trust you can trust that data. Then you kind of write the transformations, probably use dynamic365 or some kind of power apps to do that. Then write the transformations using um, uh, Azure. So again there is a lot of movement there. And then you feed those transformations into another database. Then from there power bi loads and then shows those dashboards again. Imagine head of uh, operations or a VP asking for a small change in the dashboard that you just got. The whole process repeats again, right? So in this case the text to dashboard conversion where you are uh, feeding your schema and you have multiple dashboards that got ingested, uh, data sets that got ingested and the engineer, data engineer or the head of operations asking Carvey that okay, I want to see a project, a spend from these employees, list all the employees, list all their cost, actual cost, and also list what the forecast, uh, would look like. It happens in minutes. And you can see that output and take a decision and share it. With a click of a uh button you can share the dashboard to anyone you want with a password protection. And also you can download the cool thing again I have to say this is you can export the dashboard as an HTML and that HTML download will stay with you but communicate back to the original dashboard for changes at any given point of time. Imagine you're flying on a flight, you have your dashboard up. As soon as there is a uh, Internet connected, that downloaded HTML file actually goes back, checks and then updates the information. Right? That feature is also there. So I think, I mean these kind of technologies, advancements that we have, I think that's, that's the awe that they see because traditional routes consume time, resources, money and a lot of um, reiterations going back and forth. But on Carve, it's basically things happen in minutes and the user uh, is not a technical guy. That's the beauty of it. So you still can run or get output of whatever you want. Not being a technical person, I think that's the whole point of Carvey, uh, to start with, to build a platform that anyone can use.

Tobias Macey: And as you have been working on this project and platform and business, what are some of the most interesting or unexpected or challenging lessons that you've learned while building this AI native data orchestration system?

Shravan Gunda: Uh, we started, so the start of this whole idea was for oil and gas, um, because I was an oil and gas and also for only finance, we targeted certain domains. But while we are building this solution, we got to know that every domain out there has the same problem. So we had to expand the whole idea of including all the domains, get those agents trained on all the domains uh, data and make sure we incorporate the uh, ease of use. You know that that's the, that was a very big challenge for um, how to um, make sure um, a person who doesn't have any idea to run an ETL pipeline or even never heard of trying or building a pipeline to use Carvey. Because I think any expert from the data world would know how to build an ETL pipeline. And if you are giving them AI, uh, like like 100x support then it's easy for them to figure out how to use that. But if a normal, I would say non technical person to make sure they feel that ease of use on Karvei I think that was a super challenging part. Yeah, I think we achieved that. Uh and that was the goal. That was, that was hard

Tobias Macey: for somebody who is in the process of evolving their data workflows. They're thinking about how to get some of the benefits of AI as an accelerator for data focused work. What are the situations where you would advise against using Carve today?

Shravan Gunda: You can get started by checking out our website uh Carve AI and you can get started with your um, Gmail quickly test. You get 600 credits to start with. That's the uh, and that's pretty much enough for testing out all the platform. And also I would say try out, don't hesitate on trying out AI agentic AI features that we are actually providing because you don't have to upload your any proprietary data. We have our own synthetic data generator where you can give a prompt and it's going to generate your test data and try all the agentic features. And you love it because what you would see is 80 to. I would not exaggerate but 60 to 80% of time saved resources. You don't really have to depend on most of the traditional route that you take and you'll see the faster results with 200% accuracy. And that's I think the potential of Carve is so tremendous. Why? Because of um. Even like I said in Transformations we added a code block and there is an AI processor. Right. So the main idea was that to promote Carvey as now you have your data, you have your flow, now you can add your custom code. That means you are actually building an application that can be published as a dashboard and share it with your customers. Right. That was the main idea. Like that was that was also that could also be achieved and that that is being tested right now to use Carvey and that's the potential of Carve is what I'M saying, so you guys should test those out. And I was amazed with what we can do with Carvey, uh, because the idea started pretty simple, but today I'm sure it's going to be uh, you know, ease. The 100% ease of use of Carvey, Uh, anyone can use that. And democratizing AI, I mean that's a huge project and everyone is trying to do that. But I think Harvey achieved it, um, is what I would say.

Tobias Macey: And as you continue to build and iterate on the platform and the business, what are some of the things you have planned for the near to medium term or any particular capabilities that you're excited to explore?

Shravan Gunda: That's again a great question. So we wanted to build a community that can again with this AI boom. Everyone is so worried about what the future would look like. So today, um, in the very near future we want to have AI Marketplace, uh, Carve marketplace where you can build your pipelines or you know, whole process of ETL pipelines or any process that you want to, that you think can add value to the customers and publish there and the customers can directly import those uh, solutions into Carvey and start using them. So we want to build that whole ecosystem and I'm pretty excited for that marketplace to come go live where the feedback loop, right. So it's not just taking from the society, but also giving back to the society with marketplace where uh, solutions provider who publish solutions get paid with um, uh, ease of our customers not to even build that pipeline. I mean it's readily available for them to use. You don't have to waste or juggle on building the same again, uh, the same process. And these pipelines or marketplace solutions, we are targeting SMEs like real uh, domain experts to build those um, solutions. So uh, those won't be any less than a masterpiece, those solutions, I mean those kind of approach we are taking. And also in very near future you'll see uh, domain, sorry, desktop, uh, application for Carvey where you can install carvey on, on your laptop, uh, and start using it as a siri, uh, you can call it hey Carvey. And it's going to assist you with talk to talk to operations. So those are some pretty exciting roadmap we got.

Tobias Macey: All right, well for anybody who wants to get in touch with you and follow along with the work that you and your team are doing, I'll have you add your preferred contact information to the show notes. And as uh, the final question, I'd like to get your perspective on what you see as being the biggest gap in the tooling or technology that's available for data and AI management today.

Shravan Gunda: Yeah, the biggest uh, gap that I saw is, um, what I just um, explained last 10 minutes is uh, the technology gap the technology world lifts in its technology world and the business world. It doesn't really share a common platform. There is that gap where business world has to depend on technology. I mean the core technical guys to get insights and you know, the translational requirements might get lost. So we, we want to bridge that gap with Carvey, where anyone um, feels very comfortable to use Carvey. I think the bringing, like I said, democratizing AI for data management, uh, is the goal. So we will make sure that that happens in a very smooth, uh, and comfortable way for all users, all kinds of users.

Tobias Macey: Uh, well, thank you very much for taking the time today to join me and share the work that you've been doing on Carve and the ways that you've implemented AI as the core loop of driving the overall data workflow. Because the definitely a very tedious process for large chunks of that. So being able to offload a lot of that to these tireless agents to handle some of that heavy lifting and freeing up the humans to focus more on the actual business cases is definitely a very interesting and worthwhile endeavor. So I appreciate the time and energy you're putting into that and I hope you enjoy the rest of your day.

Shravan Gunda: Uh, same here. I had a blast of the conversation and again, focusing on technical side of Carvey was very interesting and the questions that we discussed were very apt to what we are doing. Thank you so much for having me here.

Tobias Macey: Thank you for listening and don't forget to check out our other shows. Podcast.net covers the Python language, its community and the independent, innovative ways it is being used. And the AI Engineering Podcast is your guide to the fast moving world of building AI systems. Visit the site to subscribe to the show. Sign up for the mailing list and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hostsatangineeringpodcast.com with your story. Just to help other people find the show, please leave a review on Apple Podcasts and tell your friends and co workers.