Building Reliable Agentic AI on Databricks

Key Takeaways

Hi everyone. Can you hear me? Give me a thumbs up if anyone. Awesome. Amazing. The Wi-Fi was generous to us today. Um, thank you so much for joining the session about accelerating Agentic AI with data and AI observability. My name is Bar Moses. I'm the CEO and co-founder of Monte Carlo. I'm really excited to be here today to share the latest and greatest with data and AI observability. I will just start by saying a big thank you to the data bicks team first and foremost for letting us be here uh today but also for awarding us with data bricks partner of the year in data governance. It's been a tremendous pleasure to partner with the data bricks team and we have many uh mutual customers including a few here in the audience. Uh so nice to see you all here and thank you again for your partnership. So a little bit about Swiss Monte Carlo and what do we do? We are the creator and leader of a category called data and AI observability and our mission is to help increase and accelerate the adoption of data and AI by ensuring its quality and trust of data and AI products. So we're fortunate to work with 500 and more organizations all with the same mission of delivering trusted reliable data and AI products. Maybe taking so a little bit of a step back, I'll start with talking a little bit about the latest and maybe not so greatest in AI. So what's happening recently? In 2024, City Bank was fined with a multiundred million um fine for data quality issues. This was not even related to AI, purely for it foundational data quality um uh incidents following a $400 million fine. Fast forward a few years later, a user convinced an agent to actually sell a car, a Chevy Tahoe for $1. Um, obviously both of these things have brand reputational um, and customer trust implications. I was just on a call with the CTO of a Fortune 500 last week and he told me, you know, by the end of this year, I expect over 500 agents to be in production. I have no way to ensure the quality and reliability of what those agents experience will be like with my customers. And so this is, you know, a few couple of examples just recently from the news and some that I experience. But I think this is a shared world, a shared experience that all of us are are facing right now. There's a lot of pressure to build and deliver data and AI products where we're not always sure that we can actually ensure the quality and reliability of those products. But this isn't new. This has been a little bit this has been here for a while. I'll take you back through a little bit through the you know the the era if you will the various eras of the journey. You know we really started sort of in the 1980s with relational databases later with big data and CDWs and sort of with you know data bricks and others helping us usher in this data and AI era. Now throughout this journey what have we done for data quality and reliability? I'm going to make the claim that in the 1980s and 1990s we had some solutions and foratica being sort of the pioneer of that followed by a couple decades of a dumpster fire. We were running around like headless chickens hopes and prayers that things were going to be okay. That was hard. That was really hard. And I think as we look into the next decade as we're thinking about data and AI products, we have to to sort of be at the forefront of that and get ahead of that. And that's really sort of this era that Monte Carlo is bringing forward and pioneering. And so I think the question for us as an industry is how do we avoid another dumpster fire area? What do we need to do different collectively? And that's really where us at Monte Carlo, we spend all of our energy and effort waking every waking up every single day trying to figure out how do we actually ship deliver as a co as an industry reliable products. And so the way to really sort of go around this or kind of to address this, we meet with our customers and speak with our customers all the time. And in the last couple of months, we, you know, I speak with hundreds of customers in the last couple of months. And we've really identified sort of three core patterns for what many data and AI teams are facing. And we sort of organized our roadmap and our thoughts and capabilities around these three problems. You know, the first problem that most data and AI teams are faced with, and this isn't unique to just data and AI teams, every single organization, every single team in organizations are asked to do more with AI to accelerate their ongoing workflows to reimagine them, to re revolutionize them with AI. Data and AI teams are no are no different. They're expected to do more with less with the assistance of AI. The second core problem the data and AI teams have is that they are on the hook to deliver data that is being used by other teams to build AI products. Whether that is the AI team specifically or other domains in the business that data needs to be highly reliable. Why? Because we all have access to the latest and greatest model, the latest and greatest foundational model. Whether it's OpenAI or Enthropic or Llama, it's just one API key click away. The only differentiator between specific organization and another is the enterprise proprietary data that we have that allows us to differentiate and build better customer experiences. So if that data that's the foundation is not reliable, it's very hard to actually build meaningful AI products that have strong adoption. And then the third problem that we're hearing from data and AI teams is that they are on the hook to actually deliver AI applications. Whether that's an agent, an MCP server, a chatbot, whatever it may be, those AI applications actually need to get adopted. And again, they will not be adopted. There will not be an ROI if those are not high quality and and reliable. And so, we think about each of these problems differently, and I think we need to address them differently. I'll touch a little bit on each today. So starting with the first one, how do we leverage AI to make data teams more productive? You know, there's a lot of talk about how software engineering is going to reinvent and reimagine our workflows. So that, you know, in the not tooistant future, engineerings are actually going to be managing or orchestrating a suite of agents to do their work. maybe one agent to um you know write a spec, one agent to build a feature, one agent to to fix a fe to to fix a bug. And so it begs the question, what does that mean for data teams? In the same way, data teams might be managing a suite of agents, one agent to build a pipeline, one agent to fix an issue, one agent to monitor it, and one agent to troubleshoot as well. This is Monte Carlo's first foray into that world. And so we actually released a monitoring agent about a year ago. It's been in production with hundreds of customers. We have a 60% acceptance rate which is quite remarkable. It basically means that 60% of recommended monitors are actually accepted. What does this solve or why the hell should I care about this? Because many data and AI people, many data teams, data stewards, data analysts spend a not insignificant amount of time trying to understand their data and figure out what the hell does the data mean and how do I know when the data is wrong. And so you actually have to go through the manual process of profiling the data, understanding the semantic meaning of the data, the connection of the data, and then try to figure out what to monitor. Our monitoring agent actually mimics exactly that human behavior, does the profiling of the data, infers the meaning of the data, and then makes recommendations for the data team on what to actually apply for a monitoring perspective. And so that's a pretty powerful reduction in terms of time spent. But the thing that I'm really excited about is this troubleshooting agent. That's really, you know, the place where when I saw a troubleshooting agent in production is when I was really um I think I really could see the possibilities of how LLMs can change the way that we work and think. So, I'll tell you a little bit about this agent and you probably have to go see a demo of it. Basically, you know, the in the sort of the the use case of where someone might use a troubleshooting agent is when someone receives an incident. So let's say I'm a data engineer or a data analyst and um you know I get an alert someone from the marketing team tells me there's a problem with the dashboard that I'm looking at or maybe someone pings me and said you know the output of this model kind of doesn't make sense let's look into it as an analyst I now start coming up with a list of hypothesis well maybe the data was wrong well maybe the dashboard didn't refresh well maybe the job upstream failed there could be thousands of things that could go wrong and now I have to start researching each of this hypothesis recursively until I find the root cause. As a former data analyst, I've spent years troubleshooting and trying to figure out when we're wrong. We today can actually use LLM to do exactly that. So, we start with having sort of a main agent that basically um comes up with the list of hypothesis for what could go wrong for a given issue. It then spawns off agents for every single hypothesis and each sub agent basically goes through the process of understanding what is the issue and doing the triage and the root cause per hypothesis and then after each of those sub agents have run and in fact you know we can have up to 200 agents run in parallel in under two minutes. So think about all the hypothesis you can look at and the magic is it's not just per table or per data asset you can look at all the assets that are upstream at the same time. So once all the sub aents have done that sort of research the main agent that orchestrates that takes all of that input and basically comes up with summarization of a TLDDR. Here's the issues that are related to this. Here's the data problems. Here are the code changes. Here are the system fail failures. here are all the reasons for what actually contributed to this incident. And so the time to actually troubleshoot and resolve incidents is dramatically reduced as a result of this. So I'm really cool about what this means for the future of data engineering and in general data and AI teams. There's so much more that we can do. Um and again I think with the troubleshooting a agent, the ability to then follow up with questions like how should I fix this issue or what remediation process would you recommend? or what does this particular um aspect of the incident mean? And being able to ask questions in natural language is really really powerful dramatically changes how we think about the workflows of data and AI teams. One more thing that I'm very excited about on the category of um AI powered observability is the ability to interact with uh data about your data for folks who are more businessoriented and less technical. And you know as you think about the ability to sort of interface and ask questions like what alerts did I receive today? What you know what data assets should I trust? Um what uh you know what particular alerts should I pay attention to and why? The ability to actually do that through an what you see here is um an MCP and an integration with Claude in this particular instance. You can have folks who are more businessoriented actually ask questions about your data quality data observability through claud. So in this example, it says, you know, can you fetch the latest alerts from Monte Carlo? And then every alert has a summary. And so opening up an entire world for more and more users to interact with this data and learn to trust your data and AI products becomes really powerful. So that was just a little bit about this the first kind of problem. How do we serve AI powered observability? And there's a lot more that we can do there. I'll talk a little bit more about the second problem which is how do we provide AI ready data and the truth is you know I will say we aren't sort of the primary expertise or um experts on AI ready data but I think Gardner put together this framework which is pretty helpful and pretty sort of straightforward you know one of the things that you'll notice here is obviously metadata management becomes a lot more important uh data and analytics governance and data observability obviously we focus the most on the right hand side on data observability And I'll talk about sort of two trends that I find really interesting and really cool that have changed how we think about this. So the first is sort of the rise of unstructured data. Obviously unstructured data has been around for a while. 90% of the world's data is unstructured. But the ability to actually process and work with unstructured data is only now economically viable. What's the problem? The problem is that oftentimes we don't know how to work with unstructured data, let alone make sure that it's actually accurate and reliable. And so what you see here is an ability to actually take in customer reviews for a particular dish for a particular restaurant and actually classify that in terms of you know what is the particular dish that's mentioned in this review and do an analysis of that. do an analysis. Um, you can also do an analysis of the sentiment of particular conversations and see if there's drift in the sentiment for support conversations. Um, another cool example that I love is um, we work with a company that's uh, it's called Pilot. It's a truck logistics chain, national truck logistics chain, and um, their drivers oftentime takes pictures of receipts uh, for fuel processing for fuel for billings of fuel. And oftentime if their receipt is crumbled or if there's a hand that sort of covers their receipt, you can't actually uh process that data. And so you need to ensure that the images and the files, the text files, the PDFs that you're working with are actually high quality. And so we've actually at Monte Carlo released the ability to actually specify monitors for unstructured data and make sure that your team know if that data is corrupt or late or inaccurate or mismatching. very very important as we think about AI ready data. The other concept that's very important is actually becoming metadata. It's incredibly hard to do conversational BI and data bricks or otherwise if we don't have the metadata together. Agents are not human beings and so it's hard for them to understand the data if they don't have uh the metadata and the semantic layers um uh structured. And so uh actually one of the things that we're starting to look at is observability for metadata and making sure that um that by itself is a whole sort of body of work uh that we're investing in. So just to wrap up that's sort of on the on the first two kind of core core problems. I'll talk briefly about the third one which I think is probably sort of the the most forward looking here. Again, I think many, you know, data and AI teams that I speak with will either tell me we're building and shipping AI products right now or, you know, we have it on our roadmap. We're partnering with it with our AI team. And so the question becomes, you know, we have a strong understanding of our current data products. Perhaps we have a data mesh framework or strategy. What should be our strategy for AI products? And I think one of the core failure uh modes or one of the big sort of um problems is that people think about AI observability divorced from data observability and actually it's impossible to separate those. So what we're finding is that if AI failed it's oftentimes because of the data not only because of AI and so if we think about AI observability separate from data observability we're really doomed to fail. The only way to really ensure the reliability and the quality of our products is through taking a holistic approach to both of these together. Even that is quite hard to do. And so I'll I'll present sort of a framework for how to think about that. What you see here is basically a very simplified view of what the data in AI estate looks like. So on the left hand side you have data you have transformation in the middle you have a data warehouse a data lakehouse you have ETL orchestration and then on the right hand side you have BI solutions ML solutions and AI applications as well and oftentimes data and AI teams are responsible for the whole endtoend estate however this estate has changed dramatically in the last 5 to 10 years gone are the days when we just have one Oracle instance and we look at it once a quarter and we know the numbers are right and we and we move on. Today this estate is spread across different silos of different teams whether it's data engineering, ML engineering, AI engineering, data analysts, data stewards which all contributes to this confusion. What we found what we found is that um you know looking at sort of working with thousands of of uh organizations we found that across all this sort of various um highly differentiated environments there's actually only four key reasons for why there might be an incident and the four key reasons are as such. The first is there might be a problem with the data. So you might actually have data that's corrupt or late or wrong. The second issue that might happen is you might have a system failure. When I say system, that could be a dbt or an airflow that does a transformation to your data or it could be something like lang chain or lang graph if you're more looking at the AI side of things. The third reason for why things can go wrong is there might be a code change. And when I say code change, that could be either a code that does a transformation itself for your data or it could be the code that your agent is actually running on. It could also be, you know, the prompt itself. One of the biggest issues that people tell us is that, you know, if OpenAI or others actually switch out the model, that's one of the core issues for why these issues fail. You don't always know when the model gets updated. That is a code change that data and AI teams are often not aware of. And then finally, the last reason for why things can go wrong is because the model response is unfit for purpose. What do I mean by that? The context can be perfect, the prompt can be perfect, everything can be perfect, but the response might not be fit. I'll give sort of a blockbuster example, but this went viral on X may maybe a couple months ago. Someone asked, "What should I do if cheese is slipping off my pizza?" And Google responded, "Well, you just got to use organic superglue to put it back on." Now, haha, that's funny. Okay, Google can get away with it, right? Um, uh, probably doesn't suffer brand damage as much, um, as most organization does, but 99% of enterprises can't afford those kind of mistakes. Now, that is a blatant mistake. But what if you're crafting emails for your marketing team to use that need to have a particular tone and and grammar and the particular um dialect? In all of those instances, you can't afford to make a mistake. Or if for example, if you're an analyzing support chat conversations, in all of those instances, actually, you know, the output of the model matters dramatically. And so in order to really understand the obser the the quality, the reliability and the observability of your estate, you need to have coverage across all of this. You need to be able to not only detect issues, you also need to be able to understand which of these are the culprit of the incident, which of these are actually the core issues and be able to troubleshoot and understand how to close the loop with your team. So again I would say if you think about sort of legacy solutions or a legacy approach that has largely been focused on knowing about sort of data issues at a very rudimentary level as I think about us building data and AI products we have to make sure that we have the appropriate coverage which can be drawn to data systems model or code often time more than once and so it's not uncommon that you know a problem with your AI application will actually be due to a code change, a related pull request, which at the same time is related to a DBT job that failed, but also is related at the same time to data that arrive late from meta, for example. It's not uncommon for all of these things to happen at the same time. And so, in order to understand the reliability of the system, we have to think about it end to end. Here's the kicker. This isn't the first time we're thinking about this. Data quality, data issues have happened before. They've come for our dashboards. They've come for our ML. And they're now come coming for our agents, MCP, and AI solutions. I think it's up to us to figure out how do we actually enable ourselves not only to ship data and AI products, but to make sure that we do that as a highquality, reliable way. I don't know about you, I'm excited to live in a world where we ship a lot of data and AI, but also that we can trust it and that we can work with it and that our future can be better as a result. So, I will be at booth 62 to demo all of this if you'd like to see if you have any questions. Um, I'll just say thank you so much for your time. We cannot create the data and AI observability without our customers and our amazing partners. And so, we're very very grateful for everyone in this room that helps us on this journey. Thank you so much.