How to Solve AI's Biggest Problem | Atin Sanyal, Galileo

How do you know whether an AI agent is doing its job or quietly failing in production?

Galileo is building the trust layer for AI. Its evaluation and observability platform is how enterprises measure whether the output of an LLM or an agent is good or bad.

Galileo started before "LLM" was even a word. When Atin showed his prototype to Stanford's Chris Ré, his own first question was "what is a language model?" Today its customers include Reddit, Airbnb, P&G, Comcast, and six of the Fortune 50. 

Atin spent a decade in big tech before co-founding Galileo with Vikram Chatterji in early 2021. He worked on the knowledge graphs behind Siri at Apple, then became one of the leads and architects of Michelangelo, Uber's AI platform, that hosts thousands of models across pricing, ETA, and demand.

That Uber experience taught him the lesson the whole company is built on; that in AI, observability and evaluation are the real bottleneck, and bad data is catastrophic.

As ChatGPT turned every AI output into something a user sees directly, the measurement problem went from academic to mission-critical. So Atin made a contrarian bet: instead of using giant LLMs to judge other LLMs, Galileo built Luna, small 1-3B parameter models that run evals at breakthrough latencies of 100 milliseconds and below.

If you are excited about how AI actually gets shipped, trusted, and controlled inside real enterprises, this episode is for you.

00:00 - Trailer
01:14 - From India to Apple, Uber, and Galileo
01:34 - Where the name "Galileo" came from
02:38 - Building Siri's early knowledge graphs at Apple
03:29 - Becoming an architect of Uber's Michelangelo
05:15 - Why every AI output is now mission-critical
06:45 - How Atin and Vikram zeroed in on Galileo
07:42 - "What is a language model?"
09:38 - Building the world's first feature store at Uber
11:27 - Language models and tokens, explained simply
14:19 - Where the observability insight came from
15:53 - Quantifying uncertainty and hallucinations
16:36 - The first customers and first use case
19:15 - How the product evolved from a data scientist tool
23:18 - Why ChatGPT changed everything for Galileo
23:57 - The enterprise AI adoption curve, 2021 to 2026
26:35 - Why they built the Luna model
28:32 - Turning LLM "writers" into "calculators"
28:51 - Attacking the latency problem
31:48 - Luna: the modeling and infrastructure innovation
33:09 - What evals are, and why they blew up
34:26 - The case for small language models
36:58 - What "general reasoning" really means
40:39 - AI usage is exploding — and why that matters
43:08 - Online vs offline: the "it worked on my machine" problem
44:33 - The evals flywheel and evals-driven development
46:56 - Galileo in a nutshell
47:39 - What real agents in production look like today
49:30 - A sales intelligence platform, powered by Galileo
50:47 - The agent control product
52:12 - Building GTM as a hardcore engineer from India
54:43 - Garbage in, garbage out: nailing the ICP
55:42 - How the pitch changed from customer 1 to 20
57:27 - Why Atin switched from CTO to CPO

-------------
India’s talent has built the world’s tech—now it’s time to lead it.

This mission goes beyond startups. It’s about shifting the center of gravity in global tech to include the brilliance rising from India.
What is Neon Fund?

We invest in seed and early-stage founders from India and the diaspora building world-class Enterprise AI companies. We bring capital, conviction, and a community that’s done it before.

Subscribe for real founder stories, investor perspectives, economist breakdowns, and a behind-the-scenes look at how we’re doing it all at Neon.
-------------
Check us out on:
Website: https://neon.fund/
Instagram: https://www.instagram.com/theneonshoww/
LinkedIn: https://www.linkedin.com/company/beneon/
Twitter: https://x.com/TheNeonShoww

Connect with Siddhartha on:
LinkedIn: https://www.linkedin.com/in/siddharthaahluwalia/
Twitter: https://x.com/siddharthaa7
-------------
This video is for informational purposes only. The views expressed are those of the individuals quoted and do not constitute professional advice.

Transcript

SPEAKER_01 0:00

The cost of bad data in AI systems is the next 10 years. 99% of the world's data does not live in tables. The question is, how do you get data that's ready for models? Trust is a big problem in machine learning and it is unsolved. Even simple models like XGBoot, the output of a model, which is a decision, how do you know whether it's good or not? Kind of became one of the leads and architects of Uber's entire AI fleet. Michelangelo, Uber's AI platform, which hosts thousands of models, became a brand in the AI infraspace. When software has become tokens, what is the final definition of a great product? That's a great question. I was figuring that out on my way here, and the day before that, and the week before that. That's pretty much all I think about.

SPEAKER_00 0:51

Hi, this is Siddhartha Lualiya, your host at Neon Show and managing partner at Neon Fund, a fund that invests in some of the best enterprise AI companies, start from India and building globally like Atomic Works, Spot Draft CloudSec. Today I have with me Atan Sanyar. Atan, welcome on the Neon Show.

SPEAKER_01 1:08

Thank you so much for having me. I'm super excited to chat.

SPEAKER_00 1:11

Atan, your journey has been so inspiring, right? You have been a researcher, right? Came from India, came to do your master's here. Then you were a part of the Michelangelo team at Uber, right? And then you started Galileo. So there is very similarities, Michelangelo, Galileo. Did the name for Galileo get inspired from your project at Uber?

SPEAKER_01 1:32

That's a great question. So the story goes that I was at Uber working on Michelangelo, and I had met my co-founder who Vikram? Vikram, who Vikram was at Google, and he was working on like um finance systems like Google Pay, and then did a bunch of AI work. And um he sent me this WhatsApp of a diagram he drew on a whiteboard of a dashboard, you know, so we saw charts, etc. And at the top, he just wrote Galileo. And I asked him, What is Galileo? Like, uh, did you just already come up with the name of the company? He's like, No, I just threw in some similar medieval character like Michelangelo. And uh was like, I love the name, so it kind of became a thing. And uh, but turned out Michelangelo, the real person, died the same year that Galileo was born. And I found that out two years later. So funny coincidence.

SPEAKER_00 2:35

And which was your first job after UCLA?

SPEAKER_01 2:38

So I joined a very early post-acquisition Siri team at Apple, and it the team was about 30-35 people, still the founders were there, and um I ended up, it was a long story to join that team, but I ended up working there for uh uh a good number of years, about five years, where I worked on the early knowledge graphs that Siri was built on. And uh it was kind of in the era where of early deep learning models were being experimented. It was still very expensive to run it in production, uh, but I kind of saw the whole arc of how do you build knowledge graphs and language learning systems without these models, and then saw models kind of become a thing.

SPEAKER_00 3:21

Got and and then how did uh you know Uber happen for you?

SPEAKER_01 3:26

So Uber was an interesting opportunity that that came to my plate. Uh at Apple, I had worked towards the end of my stint at Apple. I was working on some streaming machine learning-based uh systems, more from an infra standpoint. And uh Uber was starting out this team. Uh, it was supposed to be the foundational AI team, and they required uh engineers who had worked on uh scaling streaming systems because streaming ML was very new. This is back in like 2016, 17. So I decided to talk to them, and they were very interested in getting me to solve that particular problem. And then over time, I kind of became one of the uh leads and architects of Uber's entire AI fleet. So, Michelangelo, for those who don't know, uh, is Uber's AI platform, which hosts thousands of models across demand pricing, ETA prediction, any AI feature that you're using across any Uber's product today is powered by that platform. But back then it was very zero-to-one. We barely had any uh any models running. And Uber's machine learning uh fabric was just a bunch of data scientists training their own models. So it seemed like a really exciting opportunity. And I also love that Uber was one of the first systems that truly worked on very mission-critical machine learning because you're putting two people inside an enclosed box, and there's you know safety issues and um uh a lot of new challenges that the world had not seen before the uh the the um uh what's it called, the the marketplace economy had had come. So it seemed like a very exciting technical challenge. But over time, Michelangelo kind of became a brand in the AI infraspace. Even today, I get emails and in mails from folks talking about uh you know how they're still using the Michelangelo Blueprint to build their internal AI system. And uh just the name is enough, at least in the community. It's I feel it's the most underrated team because it was a team of absolute superstars, some of the best in the world AI experts. And it gave me the foundations on how to think in systems and how to really build world-class software. So I owe a lot to my experience at Uber, and uh, it was kind of the foundations of not only me personally starting Galileo, but also learning how observability and evaluations is such a big problem in machine learning. So even though the workflows have changed today, the the fundamentals still remain the same. The problems that people are facing on how do I know whether the output of a machine learning or an AI system is good or bad. They were the same challenges we were trying to solve. And the but the mission criticality of it is higher than ever because I think it's the first time in human history that AI has become the face of the product. A user is directly talking to an AI and working with an AI. So every output of an AI system is mission critical. And with agents doing actions and making critical decisions, the stakes cannot be higher.

SPEAKER_00 6:42

And and how did uh you and Vikram zero in on the idea of Galileo?

SPEAKER_01 6:48

That was a long story. So we uh were discussing on what to build. Uh, Vikram was certainly very gung-ho about um starting a company, and uh I was deeply in the AI space. So I knew that AI is the future, and I was very excited to build something in that. Uh, he also saw the same sort of vision. Uh, we initially started off working on uh some data infrastructure for machine learning systems. And while we were ideating and building, we realized that trust is a big problem in machine learning and it is unsolved. So we started building a trust layer of every machine learning workflow. How do you uh quantify whether an output of an ML model is good or bad? And one thing led to another, and I created a prototype. We met a professor at Stanford, Chris Ray, who we knew through one of Vikram's friends uh who had recently sold a company that Chris Ray was involved in. So I showed him this little demo of a Jupyter notebook where you the user publishes a model, and before the model gets productionized, it would do these bunch of checks. And Chris Ray saw it and he's like, this is a great idea. We'll do it for language models. And my only question to Chris was, what the hell is a language model? Right? Because LLMs were not a you know a word back then. And of course, I knew NLP systems and stuff, but uh um this idea of running language models at scale was so alien and so new.

SPEAKER_00 8:20

This is 2021.

SPEAKER_01 8:21

This is early 2021, so late 2020. Uh uh, but it seemed like unstructured data AI is the future. And I realized that because even in my time at Uber, we were slowly productionizing more and more deep learning models. I still remember a moment at Uber where we productionized the first deep learning model, and we saw that it's kind of giving the same results as a an XG Boost classifier, but it's so prohibitively expensive with GPUs. And uh, so we realized at least for some classical use cases like demand pricing and those kind of tasks, it's not really needed. It's like using a fancy pen when a pencil would work. But over time, the cost of running these models in production went lower and lower. And that was kind of my main uh aha moment, where uh it was clear to me that the next 10 years, 99% of the world's data does not live in tables, in cells. Uh, it takes a lot of machinery to get data into a clean format. Uh, and um for me, it was a personal realization because we had worked on the feature store at Uber and we had built the world's first feature store, and we literally a feature store for uh for the audience, especially, is think of it as a database of data that's ready for models. The question is, how do you get data that's ready for models? Uh, it's it's a long, um, arduous process of doing ETLs on raw data, which is very messy, very raw. And you set up these pipelines which converts that raw data into very specific um ML data, which is ready for a model to consume. Uh, features are uh essentially the data points that go into a model. An example of a feature, say in Uber's case, would be the number of rides taken by a user in one week. Now that value is changing as the days go by. So there's this whole rolling aggregation that you have to do to constantly keep that feature updated. And because a stale feature, if it goes into a model and a model makes a decision on that stale data point, it's the wrong decision. So a feature store is essentially this whole data management system which abstracts all this away. You simply define a feature and then you you you give it some configurations and it just makes it ready for you, and you can just consume it via API. So this idea of building this uh you know data ready for machine learning systems really blew up. Uh, but I realized that uh the the cost of bad data in AI systems is catastrophic. It leads to wrong decisions, and those wrong decisions percolate to downstream systems, and you end up with an answer that the user sees that makes absolutely no sense.

SPEAKER_00 11:25

Got it. And let's say when you heard in uh about 2021 about language models, can can you share in now that they are popular, but to our audience, what does language of model mean back then? How do you understand to a layman?

SPEAKER_01 11:39

Absolutely. So uh funny enough, the the definition of a language model hasn't really changed much over the years. So to dumb it down, uh a language model is uh a machine learning model. And uh machine learning is of course, uh when I say a machine learning model, it is essentially a deep neural net. Uh so all these models like OpenAI, uh OpenAI's models, anthropics models, if you shine a magnifying glass on them, they're essentially a deep neural network uh which is which has very specific architectures behind the scenes. But what they really are are any deep neural network is essentially a memory machine. And the whole process of training a model is making the model remember patterns in the data. But um uh data to a model is just ones and zeros. So you can feed it language, you can feed it images, and it makes no difference to a model. It will just remember the patterns and make predictions based on that. So a language model, in the in the more modern sense, is what used to be called as a seek-to-seek model, which is uh the output of this neural net is essentially one token generation after another in sequence. How do you define it? Okay, a token is a uh for simplicity, it think of it as a word. Uh so if you have a sentence, uh say how are you, the three tokens or four tokens in them are how are you, and then the question mark. Um, that's the simple definition. In reality, uh what a model does is it breaks down these words into subtokens and multiple tokens, but that's you know that that's essentially machine learning language, which is abstracted away from the user. Um, but that that's the reason why you see uh any LLM basically spit out one token at a time. And that's why you see the streaming. It's essentially at each decision, at each token, it's making a choice of what token to spit out next. And that choice is essentially a probability distribution of all of vocabulary. So think of the entire English uh dictionary. That's whatever, uh half a million to a million tokens. So at each decision point, the model is choosing what's the next best word, but based on the previous word using techniques like attention and a few other uh concepts. Uh, but it's really just choosing one word and the choosing the next best word to say after each previous word.

SPEAKER_00 14:16

So, where did this insight come from? That hey, uh obviously you worked at Michael Angelo, that observability uh for these large language models and AI in production could be the future.

SPEAKER_01 14:30

So I realized that AI has always had a measurement problem. And this goes far before language models were even a thing. Even simple models like XGBoos, decision tree classifiers, it was always hard to quantify good or bad. The output of a model, which is a decision, how do you know whether it's good or not? Except in the previous world, when we used these simpler models, the input to them was uh uh these features that we were talking about. And often it's easy to do certain basic correlations to really dig into why a model chose a particular uh decision. The whole ballgame is different with language models because language models are uh these token spewing memory machines, which is essentially there's so much randomness and probability in them. It's very hard to say that this was the final answer based on that. You know, why did the model say what it did? It's a hard problem, and that makes observability of these newer systems even harder. But that was the original problem that we were chasing. Like, can we dive deeper into these models and really understand why a model chooses the next word to say? And a lot of our initial algorithms that we had built in the early days of Galileo was essentially using math and statistics to quantify uncertainty. So, uncertainty uh is another technical word, but it's really to in simple words, it's how sure was the model that the next word is the right thing to say.

SPEAKER_02 16:06

Okay.

SPEAKER_01 16:07

So and there's some signals you can get from these models. So we took that, the the seed of that idea and built some algorithms to give you whether, you know, how certain was the model in its answer. And from there, we've done other more advanced methods to really quantify hallucinations and some of the more advanced issues we see. But it really comes down to this whole idea of uncertainty. How do you quantify uncertainty in these models?

SPEAKER_00 16:33

Who are your first customers and what's the first use case that you solved for the first 10 customers?

SPEAKER_01 16:39

Yeah, so given we started before LLMs were a thing, a lot of the workflows, especially in the enterprise, was driven around fine-tuning uh some of the smaller language models. So for those who've only learned of language models after Chat GPT, they wouldn't know about the erstwhile models. But these models were already there. In fact, even before GPT 3.5, you had GPT 2 and GPT 1, which were essentially similar architectures as ChatGPT, the modern Chat GPT, except the number of um the size was much lower and smaller. And in in the AI world, we measure the size of the models through what we call the number of parameters. So if you ever hear people say, Oh, I have a 500 billion parameter model, they are basically saying they have a really large model. So coming back to the workflows, folks were working with much smaller models back then, typically in the 100 to 400 million parameter range. So very small size. It's so small that in theory you could run them on CPUs. Okay. They would be slow because it's sequential. Um, but the GPU infrastructure also needed to serve these models was much less uh uh resource intensive. Uh and the workflows back then were primarily around contact center AI and uh entity detection, and these were this is what we call tasks. So entity linking, entity detection, classification, these were standard language modeling tasks that enterprises were doing. And our first product was uh essentially trying to make these uh the model decisioning of these tasks much higher in quality. And we realized that the main determinant of that is the data that you feed into the model. Because the model is really just an equation. There's not much you can tune to it except a few hyperparameters, but that's not the real fuel that you need to improve the quality of the model. Uh, and our first customers were mostly um uh innovative startups and mostly in the contact center AI space or similar thereabouts. I remember our first big customer um was a very large bank in the US. And they had many contact center AI teams. They were also building their native chatbots. But this was again in the previous era before LLMs, and all those teams have now shifted to LLMs uh and they continue to be our customers because we've moved with them. And and how did the product evolve since then? We've had a very interesting journey with our product given we've seen the entire arc of language models for the last six years. We uh originally had this product, which uh essentially was a data scientist tool. And data scientists are folks who train and evaluate models and uh they really understand the depths of these uh model architectures. And the main thing they actually work on, though, is curating data. Because at the end of the day, you're not really uh uh a scientist sitting building new model architectures. Most data scientists are essentially data curators, is our realization. So data was the biggest leverage, biggest bottleneck. And we built a platform that would essentially hook into these model training jobs and detect issues in your data using the same sort of statistical modeling techniques. Uh, and that became quite a popular tool, which many of the data scientists in our early customers really loved because they saw 60 to 70 percent improvements in their model quality in a single shot simply by using our product, versus it would take them.

SPEAKER_00 20:32

Because your product could produce better quality of data?

SPEAKER_01 20:35

No, so uh well, yes. Uh but the main thing our product did was detect issues in the user's data, including label issues, including data issues, in a single shot. So you could essentially just grab all the data that you have, pass it through our system, and we would tell you exactly what the high-quality data you should train your models with. So it became this pass-through filter, uh, which saved weeks and months of work that data scientists were originally doing.

SPEAKER_00 21:08

But what were data scientists at these enterprises back in 21-22 working on such cutting-edge problems? Like they were trying to train their data like models using clean data?

SPEAKER_01 21:18

That's a good question. Uh, there were some cutting-edge teams who were working on not the generative type of models. That's a whole different uh part of our story. And we did get into generative model even before ChatGPT, uh, because there were far and few teams who were doing these sort of pre-Chat GPT generative model but uh use cases. But those use cases were far and few. The main use cases were kind of these models acted as behind the scenes decision makers. Uh, but the the traditional chatbot systems usually had a business logic and code that would power them. And that code would use the Decisions from the models, but the model's output would never reach the user. And then there were maybe 1% of our customers were doing seek-to-seek modeling. Now, seek-to-seek modeling is the token generation modeling, which today is known as LLMs. But they were very far and few because this whole use case around, hey, I'm going to use a small model and fine-tune it and make it spew out tokens to generate a sentence. The quality of the sentence generation was very poor. In fact, you can go to Hugging Face and try out some of these older models. And I assure you, for anyone who's only worked with ChatGPT, they'll be shocked. In 2020, I think at OpenAI, they had done a lot of experiments on sort of having step function increases in the parameter size. That's what led to these models actually constructing coherent sentences. But for the vast majority of the world, these generative models could barely talk. They were like a baby. They would say some random English sentences, which would not make sense. And there's a lot of old videos on Twitter you can see. But those were not our primary use cases. That's why it got really exciting when ChatGPT happened for us, because we've spent all these years working on language model research. How can we keep our research DNA but apply it to the newer cutoff models? And now we actually have real businesses who are very excited about using this technology. So it was around 2023 or late 2022, early 23 is when we are like, man, this could be a really big business.

SPEAKER_00 23:43

So observability, uh you got this insight with the launch of Chat GPT in 2023 that it could become a very large business.

SPEAKER_01 23:54

That's right.

SPEAKER_00 23:56

But what about the enterprise adoption? How how fast or slow were these enterprises from 2021 till 2026 early, right? On on like if you have to lay out the adoption curve?

SPEAKER_01 24:10

Yeah, that's a great question. So I think my observation just looking at uh the our customers, our users, has been that there's in many of the enterprises, especially FSI, you know, banks, telecom, they have AI centers of excellence, and many follow this hub and spoke model where you'd have one AI team that would build out the tools and the technologies for other others to consume. Yeah. And so that model still existed back then. It was just that the AI centers of excellence um were filled with very uh niche-skilled data scientists who likely had PhDs and were very good at unstructured modeling. Because a lot of uh AI back then was essentially based on structured data. And uh while there were those teams, the use cases were very different, at least for us. And we only wanted to work on unstructured AI use cases, be it uh language, voice, images. Uh so a lot of those teams were very specialized teams, uh, often research labs that would you know hire PhDs only who have worked on this stuff. And it was a very niche skill. Um, that I think led to teams moving slow in general. One, it's hard to hire these people. And two, a lot of these people would want to join a Google or some big tech sort of fang-like company who would pay more. Uh, so there were all these challenges. Ever since Chat GPT, I've seen the adoption of AI in enterprises increase its velocity manifold. And the reason is because the niche skill has been commoditized. Now you have a black box, and the whole point is how do you build a software and infrastructure layer around this black box that can make it more predictable, you can control it better. That's uh that's not a modeling problem, that's a software engineering problem. So, banks and telecom companies and healthcare companies, while their engineering and innovation has stepped up in its velocity, the main bottleneck now is compliance, security, and just general resilience. How do you build reliable AI? Which is the hot question, and that puts us in the eye of the storm as a company.

SPEAKER_00 26:32

And uh, you know, uh Luna one was your first model uh that you built. Why did you build a model in the first place?

SPEAKER_01 26:43

Yes, so our Luna story is fascinating. So for those who don't know Luna, Luna is a small language model, yeah, which is specifically designed to solve the evaluation problem in AI. So, how do you know whether you know an output is good or bad, or an input has some PII or any security issues? So these are very specific uh uh tasks which Luna is designed to solve for. So by default, the size of the Luna model is much smaller. It is orders of magnitude smaller than, say, a general LLM, which is out there. Uh, in fact, our latest Luna models, which are some of our largest, they are the they typically range from one from one to three billion parameters, which is minuscule compared to some of the larger foundational models out there. Um, Luna came into the picture when we realized that LLMs as judges, which was the traditional way that people were using to evaluate, and that has a whole history of it, um, they don't scale. They don't scale in production, they don't allow you to do full scale observability, which means intercepting every single input and output of these AI systems. They simply choke. They are very expensive and they're highly unoptimized to solve for the latency and cost problem. So we took this problem and kind of came back to the drawing board saying that, hey, how do we distill all this intelligence and reasoning abilities of LLMs and bring it down to a much smaller particular set of tasks? Essentially converting these writers, like these LLMs are basically token spewers and writers into calculators. Got it. That's the difference between uh that the main difference between Luna and a general LLM is that Luna is optimized for a very limited space problem and it solves that really well, versus uh LLMs are optimized for general reasoning and uh general uh generation capabilities.

SPEAKER_00 28:49

Got it. So so stepping back, you know, um uh one of the core areas for for you also became during the course uh that uh latency has been a big issue, right? And for you working for the future also until now, how did you attack this problem of latency?

SPEAKER_01 29:09

We saw it firsthand that when you make a call to an LLM, yeah, it takes many seconds. So 15 to 20 seconds, 15 to 20 seconds, sometimes even higher if you're in thinking mode and you're so you know, trying to or deep research takes or deep research takes, of course, minutes. And uh we knew that if enterprises and businesses are gonna adopt this technology, they're not gonna sit and uh wait for for for for 20, 15, 20 seconds, yeah, especially for observability, where time is of the essence in observability. Latency is one of the top three things you solve when you build an observability system. The whole point of observability is detecting an issue right when it happens and signaling it back to the user. So you there's this is a solid problem in traditional software. Yeah, SRE has been doing it for the decades. SRE's have been doing it for decades. The template is out there, there's many unicorns and billion-dollar companies which have you know come out in the observability space. Splunk, one of them. Splunk is one of them, yes. And um uh so it has always been a critical mission critical problem. But the key factor there is every observability system has to be low latency. Yeah, because latency is the number one killer. Yeah, uh, there's no point of observing something when it's already done and it's been 20 seconds. So that's the key insight that we found as a team that hey, these LLM systems are pretty nuanced and complex. The outputs of these are very hard to quantify objectively, whether they're good or bad. So you have to somehow use this technology itself to do evals and observability. And we wrote a whole paper on this, on how you use other LLMs to judge the outputs of LLMs. But the uh the simple paradigm of making another LLM call to evaluate a different LLM simply won't scale. So that was kind of the the aha moment for us to come back to the drawing board and really figure out how do we build low latency systems in this era. And that is one of the things that has become the topmost problem for you know the Fortune 500 and beyond. Every leader is figuring out how do I productionize my agents today. And I'm not gonna fly blind. So no one's gonna put an agentic system, especially if they do actions and tasks, they're not gonna do it without any kind of observability. And if the entire observability playbook fails, that worked for traditional applications, it fails in the new era. What tools do I have to observe, observe these agents? Uh, that's the kind of that's the key gap that we fill. And that is the problem that we've been working on, uh, especially focusing on production, because production is a bit of an infrastructure problem.

SPEAKER_02 32:00

Yeah.

SPEAKER_01 32:00

Uh Luna is, of course, one of the key ingredients. And I think there's two parts to Luna's innovation. There's the modeling side, which is how do you tame the intelligence of LLMs into smaller models and use small models efficiently. But a vast majority of the performance games and latency gains that we see is on the infrastructure side, which are these uh AI platforms and LLM inference platforms that allow us to host Luna. So, for example, we've built our own in-house LLM inference engine, which is designed to host small language models. So they're not designed to host the larger models. We've done tons of optimizations, including techniques like low-rank adaptation that allows us to run many Luna models under a single foundational base. So you need only a single GPU. But NetNet, it allows us to build these evals which can run at breakthrough latencies, 100 milliseconds and below, which has not been seen by the world. And they are actually capable of evaluating a complex end-to-end interaction between a human and an agent. So that was the key unlock for Galileo.

SPEAKER_00 33:15

And if you have to explain, because evals have become really popular in basic uh you know terminology, what are evals and why they have become so popular?

SPEAKER_01 33:23

Yes, so eval stands for evaluations. And uh an evaluation is essentially a metric or a signal that you need to judge whether the output of an LLM is good or bad. That's the simplest definition. The question is how you do it. Um, of course, eval spreads into input. There's all different components to an uh an LLM request, especially if you're building an application for the app developers out there, they would know that in order to build even a simple application that uses LLMs, there's some sort of a database lookup, you'll have to set up a vector store, uh, and you'll have some system of record. So there's many different components, and one small issue in any of them can lead to a bad output. So the whole discipline of evals is how do you prevent bad outputs from going back to the user that can be catastrophic for a business.

SPEAKER_00 34:28

And uh you have been a big proponent of small language models, right?

SPEAKER_02 34:32

Yes.

SPEAKER_00 34:32

Why is that? Whereas uh, you know, today uh the earlier the uh the gap was that uh LLMs are hallucinating, right? And they can't be as accurate as small language models, but the way LLMs are getting better every day, they'll outpace LMs.

SPEAKER_01 34:51

That's a very interesting point and an interesting thought. Um you're right that LLMs are not only getting smarter, but they're also getting cheaper to deploy.

SPEAKER_00 35:03

Yeah, yeah. Every year the cost of uh uh LLMs is reducing by 80%.

SPEAKER_01 35:08

That's correct. So they are reducing by 80%, and these models are getting smarter, but there's a few factors at play here. One is, of course, latency.

SPEAKER_00 35:19

And and I assume latency they'll also solve uh with time, right? Uh now, even if you throw complex queries to Clot today, uh the results are usually under a minute.

SPEAKER_01 35:30

No, that's uh that's totally fair. So all these factors are going down, but despite that, there's some nuances in the in the economics of this, which you'll see that it's despite these improvements, the the challenges around evals will still remain. The first reason for that is the more the usage of LLMs in the enterprise and the more Gen AI adoption, uh the infrastructural challenges will keep growing. Because even if the per you know unit latency reduces, more traffic means you're just uh subjecting the system to more tokens and just more data. And all that really brings the system down. That's one. Uh number two is agent interactions are getting more and more complex. So even at a unit level, if if say you apply some magical engineering and solve the problem of, hey, I reduced a 10-second, 15-second complex generation to one second, agentic interactions will compound.

SPEAKER_00 36:33

Yeah.

SPEAKER_01 36:34

Because it's not about a single request. And the software that we are building, the new era of agentic software, they're gonna get more and more sophisticated, more and more nuanced. That will just keep widening the gap.

SPEAKER_00 36:47

Yeah, you are right. The the kind of complexity they're following every day is is increasing.

SPEAKER_01 36:53

Exactly. And the complexity of the use cases are increasing, and really the the the thing that LLM providers are optimizing for, the number one thing they're optimizing for, is general reasoning and making the intelligence of these models better.

SPEAKER_00 37:12

Uh what do you mean by general reasoning?

SPEAKER_01 37:14

Uh, every new model that comes out, you publish new academic benchmarks and you see that you know it's it's able to achieve a higher score on a particular benchmark. And that just means that it's able to solve general purpose problems better.

SPEAKER_02 37:28

Okay.

SPEAKER_01 37:28

And that makes sense for the hyperscalers. And even if they're you know getting into enterprises, which we've seen a lot of hyperscalers are solving for enterprise use cases, uh, the the general techniques that they're the innovations that they're doing on the modeling side, uh there's a bit of innovators, uh the little bit of uh, what do you say, like push and pull between um, hey, I want to solve a very specific banking use case, uh, but I also want this model to be you know much better at other things. So you're gonna throw more data into it, you're gonna have more fine-tuned, and yes, you're gonna increase the size of these models. But despite that, there's many variables which are not in the control of these LLM providers. Yeah. One is the data. You have no control over the use cases, and data is gonna change, and it'll be like it's like a fingerprint, right? It's different for uh different people. So one of the things that we do with SLMs is not only is it small, so the net economics of it is just disproportionately smaller, right? It is uh it is so uh cheap to run a single inference on an SLM versus an LLM. So that gap will always be there. We are kind of solving the opposite problem of hey, let the models get better, let the cost of intelligence reduce over here. It is in our favor because some of the base models we are using are getting more in. What we are doing is we are adding a layer on top of it which leverages the specificity of the customer data, and that becomes a very big competitive mode. Um, and then there's the question of privacy. There's a lot of hesitation on sending very key proprietary data. It has always been the point. And even though there's a lot of cloud adoption, uh, the fear of AI is 10x, the fear of putting data on the cloud. People have a lot of trepidations around what is are they training on my data? And I don't want to send my data to an AI. It's such a black box. So that fear is gonna be there. Hopefully, it will subside over the next maybe 10 years. But even today, 10 years after the you know, the whole cloud revolution, there's still questions around, you know, people still talk about data privacy and uh there's all these compliances, etc. So there's all these different motions at play. We feel like if you really focus on the fundamental problem that, hey, evaluations for language models is a very task-specific, constraint problem, and it does not require you to use uh, you know, general purpose reasoning for that. And then there's fine-tuning you can do on the proprietary data, you can achieve really high accuracy with very low resources. I feel like that's a headwind that will always rather that's a tailwind that's always in your favor, no matter how cheaper the models get, there will always be better models. Uh, but one thing is a fact that there will be more AI usage over the next many years. People are adopting it, just the numb net usage of these AI systems is going crazy. We already know uh OpenAI and Anthropic, their revenues have just catapulted in the last few months and it just goes up.

SPEAKER_00 40:50

Anthropic is at 40 billion dollars of run rate, right?

SPEAKER_01 40:53

Right, and they they they they were valued at uh 18 billion from you know maybe a year and a half ago, and from there they're uh almost a trillion dollars. Almost a trillion dollars, and and the revenues have kind of seen the same level. So this will keep going up. Uh the technology is very real and everyone realizes it. Yeah, that'll increase the traffic. Uh so it's smart to think about evals and observability in a much more constrained way, and how do you solve it cheaply? Because it's the cheap and efficient uh uh ability of these SLMs that can really help it scale no matter how much the AI footprint is.

SPEAKER_00 41:32

So you are saying uh there's a huge opportunity building first of all in SLMs for domain specificity, and then building evals for those uh SLMs.

SPEAKER_01 41:44

Well, I'm actually mostly referring to evals and observability, but but you're right. There's uh there's many instances where uh you can actually train and fine-tune an SLM and uh use that for say generational capabilities. Uh, but uh for me that's uh it's a non-issue in the sense that, hey, you can continue using newer models, and you should, because they are genuinely better and they will get better and better at doing more advanced things. So you should not come back to the drawing board and use smaller models for those. If it suits you for your use case, then perhaps, but that's a decision you should make. Uh, but generally, if you're building any kind of general application system that's solving real problems, say CRM or uh you know any kind of end-to-end workflow, you should try to disrupt it with these newer models. So, my my contention is go ahead, use the best models. But observability is a bit of a different ballgame because it has a different set of challenges. It's an infrastructural problem and latency and cost and quality. Those are the three things, and they are a bit of uh opposing forces with each other. Uh, it's like this triad of you know, low cost, low latency, high quality. It's you can only get two of the three if you use traditional techniques. So uh it's very important to you know find that equilibrium where how can you leverage high accuracy of evaluations and observability at low cost and low latency.

SPEAKER_00 43:14

God. And and today, let's say if your revenue is X, how much of it comes from observability versus evals?

SPEAKER_01 43:22

Um so it's kind of the whole online offline uh disparity, right? Like uh um, and this has been there since in since the dawn of machine learning. And one of the key problems is online offline parity. That hey, I built my agent in my experimental uh environment and now I put it into production and it's not behaving the way I tested it. You know, it it worked on my local host, is the is the famous saying.

SPEAKER_00 43:48

The open cloud works on my machine.

SPEAKER_01 43:50

Exactly. Exactly, exactly. It worked on my machine, is the last thing they said before it all blew up.

SPEAKER_02 43:55

Yeah.

SPEAKER_01 43:56

So it's a common problem. It has been there for years. It's Only a bigger problem with agents because they are harder to evaluate. So coming back to your question, there's evals. Evals is kind of the foundations of it, but uh offline evaluation is what we call it, which is the whole experimental setup to get to a first version of your agent that you are confident of. And then there's online observability, which is how do you measure in real-time in production, either uh across your enterprise or at your client's destination. Exactly. Exactly. Uh, one of our realizations, and and and we were early to realize this at Galileo, is that online and offline observability are two parts of the same coin. In fact, it's not a point-in-time workflow that you do, they are this connected flywheel. And I'll explain to you what this means. So, say you're an app builder, you build an agent, and you test your agent on a local host. Uh, what you should do, what is good practice, is define the behavior of your agent. What all do you want it to do well? And what does good mean? What does bad mean? Define them in the form of evals, is what we call it. So, an eval is this entity which is giving you a quantified output of good or bad. Uh, so you build a bunch of these evals and let those evals fail. In fact, you build the evals before you build the app.

SPEAKER_02 45:25

Yeah.

SPEAKER_01 45:26

Uh that kind of becomes that's why people say that, hey, evals is the new uh weapon for product managers because they are the ones who are defining the app's behavior. So there's this notion of evals-driven development in the offline setting where an app builder is building their app and let the evals fail. Let the product managers or the builder themselves set up these evals and let them all be red. And as you build, let them auto-turn green. And once they're all green, you know that you have some quantified sense of hey, this is a version of the app that I'm confident of. Then you ship it to production. The production will likely meet some of the eval criteria you had, but it will very likely meet newer criteria which you did not test on. In Galileo, we call them unknown unknowns. So your agents will fail in nuanced ways where you didn't expect it. That's where the discipline of catching these unknown unknowns and creating new evals and bringing them back to the offline testing environment, that's what creates the flywheel. And there's many other elements to this flywheel where you have to collect the data and look at the traces and evaluate them, perhaps manually through a subject matter expert, but you can also use offline judges to evaluate them. And these are workflows that we are seeing already in banks, in telecom companies, in consumer goods, healthcare. They are all starting to build these individual workflows, but it's all disconnected. That is the problem. And that is specifically the problem that we've solved at Galilee. Okay, how do you build this connective tissue of doing evals, then measuring new evals or unknown unknowns, which are fodder for the new evals, and then you do more testing and then release, and then catch issues that are false positives in your evals and have human feedback in the loop. And then as you scale your agent, you know these evals, which are LLM judges, they will not scale, then collect the data as the foundational training data for these SLMs, and then you compare the SLM performance with the LLM judge performance, and then once you see parity, then you productionize the SLM, and now you have full-scale observability at throwaway cost. This is this whole loop. This is Galileo in a nutshell.

SPEAKER_00 47:45

And can you name me uh like uh without sharing the name of the customer, like one one industry or one specific customer from an industry where you saw like you know uh agents in production that that are doing autonomous tasks across various uh verticals or various various use cases using Galileo?

SPEAKER_01 48:10

That's a great question. Um, certainly I can say uh the bad news is that the reality is it's still very early. Yeah, even in the enterprise, folks are building simple agents. Uh the enterprise kind of evolved from building sort of knowledge worker workflows back in 2024, 2025. What is a knowledge worker workflow? Like internal tools that make employees more efficient. So having, you know, kind of like uh a company's like Glean, right? Yeah, internal search for everyone. Internal search. So that's been kind of the hot use case for most companies. But that was an old hot use case. It's an old hot use case. So now we've evolved into one, how do you make these use cases more agentic?

SPEAKER_02 48:50

Yeah.

SPEAKER_01 48:50

It's still internal tools, but they do more things than just QA lookups, uh, like creating a graph or you know, creating a presentation. That's the new sort of internal efficiency workflows. But uh there are a set of customers who are sort of living on the edge. Of course, you can put beta stamps and stuff in your product, which they do uh for AI features. Uh, but a lot of the the some of the more cutting-edge companies that use Galileo, uh, the use cases I've seen are um uh these these agents that take you know use tool calls and take action and get data from different APIs and really surface much more nuanced actionable information to the user. Uh, and that's really baked into the product. Um, without naming a customer specific example, there's a sales intelligence platform that uses Galileo for observability. And the the platform, what it does is it gives you uh uh sort of enterprise customer intelligence. It's mainly for uh go-to-market teams to discover customers. And they've built this beautiful QA chatbot-like system where the interface is still language, but it's doing a lot more things than just answering questions from a database. It's going into um, you know, using various APIs and open source CRM tools to get information from you know about the you know what employees are doing and the you know what they're posting on social media, all this very interesting information. And you can auto-create these sort of sales battle cards and you know, save them and bookmark them. And it's really easy to use and very intuitive. I really love that product. But behind the scenes, they're running all these autonomous agents. Uh, so this is one example. Other examples are like AI SRE. That's another very hot use case on detecting root cause RCA issues for traditional applications. Uh, so they use us as sort of their monitoring their agents. Um, the most cutting-edge use cases I've seen, they use our agent control uh product.

SPEAKER_00 51:00

What's an agent control product?

SPEAKER_01 51:01

So agent control uh is a recent product that Galileo launched. And as the name says, it is to control agents or provide a control plane for you know seeing the agent what the agents are doing at a particular point in time. It is open source. So you can Google uh agent control Galileo, you'll find the open source repo. And what it this does is uh it's meant to design these policies, which you can apply to specific steps of the agent, and those policies will either shut down the agent or make it reroute to a different tool call. And uh what I've seen is it makes the net net agenc experience a lot more reliable and stable. Of course, there's that balance you want to find between, you know, it should not be too unstable and stodgy where it says I don't know to everything. Uh, but uh it's this control plane that allows you to uh control these agents. So some of the more cutting-edge use cases are these long-running agents which are doing longer workflows, like end-to-end. Think of any enterprise workflow, whether it's a financial workflow or a CRM workflow, they're attempting to do those with agents end-to-end. And the agent control serves as the control layer for essentially observing what's happening at each step.

SPEAKER_00 52:19

Uh, your customers include Reddit, Airbnb, PNG, Comcast, and six of the Fortune 50, right? How did you build your GTM? And especially like, you know, um uh all of us like coming from India are hardcore engineers. So we are not really taught sales back in home.

SPEAKER_01 52:37

Absolutely. So I came to the US in 2011 to do research, was in a research lab at UCLA, uh, did my master's there, and like you said, I was a hardcore engineer, uh, loved solving problems, hard problems. Um so spent 10 plus years in big tech before starting the company. Yeah. And I feel like I had to do a lot of unlearning of uh certain habits which I had built while working in big tech because not all problems are Apple and Uber level problems, especially in the enterprise. So, first six to eight months of our journey was talking to hundreds of people, and this is in an era where we did not have granola and note takers and you know voice agents, it was all just taking notes in a diary. Uh, and we would meet people in in uh in coffee shops here in New York, we would fly. So a lot of talking just to really figure out what the problem was. My leverage was that I had built AI systems at scale before and truly had uh built some of the in the foundational infrastructure that defined the MLOps industry itself. So I brought that to the table. Uh, what I had to unlearn was uh how do I build something very simple and very uh narrow that solves a very specific workflow problem. Uh and that is something which I learned over dozens of conversations which we had. So most of our first year was spent just doing this. Yes, we would build some prototypes here and there, but it was mostly throwaway. Once we re-figured out that really the problem of trust in AI is a big problem. And correlating that with hey, it's uh it is very evident that more and more AI systems in the next three to five years are going to be uh unstructured AI-based systems. It really gave us the conviction of the specific problem that machine learning and AI is a garbage in, garbage out problem. So we have to solve the garbage in problem.

SPEAKER_00 54:49

So for example, let's say uh imagine I am a potential customer, right? Uh, who would my ICP be in your earlier days? It would be the CTO, the CIO, or VP engineering in an enterprise.

SPEAKER_01 55:02

So you are the potential customer of Galileo? No, yes, the potential customer of Galileo. So in our case, our ICPs were the VPs of engineering, uh, or rather VPs of data science back in the day. It was a role that apparently is a diminishing breed. Uh, but we would go to these advanced AI teams, mostly at larger uh financial companies and telcos, and we would go to Capital One and talk to data science teams there and really ask them like, what are you doing on a day-to-day? And what is the key problem?

SPEAKER_00 55:36

Got it. And let's say uh initial screening is done, you're you're you're figuring out the problem. Now uh now I'm potentially like the 20th customer of Galileo. How would you your pitch change now?

SPEAKER_01 55:50

Uh that's a good question. I think it uh it it the pitch difference depends on the maturity of the product, of course, but also um the maturity of the the the landscape or the two you know the the the this area is moving so fast that you know between customer one and customer ten and customer twenty, just the the entire wording of the pitch has changed. Uh but what has not changed about the pitch is this core problem of uh hey, I'm building AI systems and agents, and I don't want to fly blind. How do I measure these AI systems effectively? So give me a system to measure good and bad. So that has not changed. And more than us telling the user, it's the users who tell us that, hey, I'm looking for a way to quantify good and bad in my data. And this thing has not changed since day zero of our company when we started early 2021. It's still all about how do you quantify good and bad, even in the era of agents. It's the same pitch where we say, uh, our pitch is we are fortunate enough to have a product which almost needs very little selling as far as the problem is concerned. Because everyone will tell you that, hey, I'm building AI systems, I need a way to measure things. I'm not going to productionize it, I'm flying blind very clearly. The question is how. I think the challenge is how. But it comes back to us being engineers and deep in the systems thinkers, uh, which is a great problem to have. So our main challenge is hey, how do we build a good product that can solve this measurement problem?

SPEAKER_00 57:30

And uh you recently switched roles from CTO to CPO. What's been uh uh behind that transition?

SPEAKER_01 57:37

Yeah, so uh I worked on the technology uh of Galileo. I literally built the first version of Galileo in the earliest days uh during our pre-seed days. And I've always been a builder and engineer and uh led many teams in engineering, always been in the engineering space right from the beginning, especially in the AI space. The new era of software, people are figuring out what it looks like with agents, with gen AI, with tools, and it's just the beginning, right? Uh OpenClaw was one blueprint that was published, and it just blew up because it said that here's one step that I've taken at how to build a long-running agentic system, and uh it's only a blueprint. OpenAI, uh OpenClaw, my apologies, has uh many flaws. And anyone who's worked deeply on the system, it is a brilliant uh idea that's been put out, and it is the the creator of OpenClaw is absolutely fantastic. That said, it can be maneuvered in many ways, and I have seen that personally as I've built out you know on my you know personal uh local host laptop. I've tried a lot of things and I've tried to move things, uh, really break open claw in many ways, and I've seen that it's while it has its flaws and rough corners, it's the first blueprint of what an AI agentic system could look like. So, yes, so um I've played a lot with uh newer Gen AI systems, and I've always been on the cutting edge. The form factor, people are still figuring out of what product in the new age of AI looks like. And there's uh some ideas that yes, you need still some sort of a browser form factor. Uh, some of it is automatable, there's agents in the loop, there's the CLI form factor, which is hot again, and you have cloud code and other sort of CLI applications, there's MCP connectors where you have a chat box. So it's all sort of taken the world by storm that hey, traditional enterprise applications, which used to be a dashboard which would show a chart with squiggly lines on it, all that era is over. Now it's the era of actions and intelligence. So I took on the product uh hat, I wore my product hat because I'm a deep sort of engineer and engineering leader. I've come from this space, I at least understand it from silicon up. So it's a good uh role to take in an era where builders are the kings and queens. And uh, me being just having that builder DNA, I think it helped us uh do more experiments, uh, think about what good product looks like. Because even the observability platform, it is a product and it needs to be built out really well. We we we have this internal term we use called umami, and umami means you know something that just feels so good. Uh, and in an era where you can build in you know a website and a web application with a Postgres database behind in 30 seconds, software is just commoditized, software is just tokens, right? Code is tokens. So, how do you build high-quality product in the new era? Was a key problem that we had to solve, sit, take a step back, think about outside of all the machine learning and AI innovations we do, what is the new product? That was the key question. I took on that role to try to answer that question.

SPEAKER_00 1:01:15

So, when software has become tokens, what does what is the final definition of a great product be?

SPEAKER_01 1:01:22

That's a great question. I was figuring that out on my way here, and the day before that, and the week before that. That's pretty much all I think about. I can certainly share my I guess my learnings till now. Uh, it is um, there's no uh no one knows the right answer per se. Uh, it is what I've realized that is that you have to meet people and workflows where they are, because it's not a clean sweep, clean canvas. Right? There's software is pretty hairy if you really look at what goes on behind the scenes. There's a lot of traditional software that's already in place which solves really hard problems. So we have to fit into that and then evolve the form factor. Uh, the easiest thing to disrupt is what a good UI looks like in the new era. And I can certainly tell you about um in the observability and eval space, what is the problem that any observability tool really solves, whether it's AI or not AI? It's the hey, what's wrong question. Like you ask a system, hey, what's wrong, and then you take 50 steps to figure out what's wrong. Uh traditionally, we have solved that through statistics, through charts, through drift, through all kinds of mathematical paradigms that we put into a software and that shows up like a chart, and that's what developers do. But now you're in the era where you can ask a question and get an answer, and there's all these steps in the middle which requires reasoning. You don't have to build custom business logic for that. And the primary interface for this question, hey, what's wrong, can be voice and can be language, text, because those are the primary modes of human interaction. So it all starts with that, and then from there you trigger this workflow where your little agents who are the little workers, they do their things and they bring you the results. So what's in between is still to be figured out. Uh, what I know is that the current form factor has to fit into the existing form factors, which is some sort of a browser, some sort of an application. There is a case to be made for a natural language-based interface, whether it's voice and or or language. Certainly, a lot of voice-based interfaces are also getting really popular. We're seeing this movement of voice interfaces becoming the standard as the quality of you know voice models uh are getting better. You're talking to one of my friends uh later on who is uh uh running a pioneering company in voice. And uh a lot of these businesses are doing really well for this reason that voice quality is so good. So, in the end, we'll enter an era where we'll talk to software and software will do work for us. And everything in the middle is a means to an end. Whether it's a blue button on the top right, or whether it's a chat chatbot or chat GPT-like interface, it will likely be some sort of a hybrid where a button makes sense, we don't want to replace it. Uh, but ideally, maybe 10 years down the line, or perhaps five to ten years down the line, uh, if we can build a system which is completely headless, where you just talk kind of going back to Iron Man, right? Where you just talk to the walls and they answer you and they get stuff for you. That's the ideal thing. And they and then what take taking it one step further, actually fixing issues for you. Um, so we are going towards that trend, but it's gonna be meeting the world where it is and taking it's like ship of thesis, replacing one brick at a time.

SPEAKER_00 1:04:57

And uh you know, last of all, uh big congratulations uh on the exit, uh right. Our monumental life journey, you know, and wirestone, the life of a founder, right? Uh and getting acquired by let's say a Fortune 50 company uh like Cisco, which has been a leader for the last many decades. Uh right. So, how did the the marriage with Cisco happen? Can you share the process? Whatever is shareable.

SPEAKER_01 1:05:24

Absolutely. Um so uh the uh you know the work with Cisco that we were doing even before uh we got acquired by Cisco was super interesting. Uh so we really met them much before today. And uh the the relationship kind of evolved into that it really makes sense for for them to acquire us. Uh we started maybe a year and a half ago working on uh certain interesting sort of future facing problems on how do you define agent to agent interactions and you know in the era. Of when A2A and these protocols. Well, MCP is one stab at solving a very specific problem of agent interactions, which is tools selecting the right tools and uh sort of automating that process. There's a lot more to be solved.

SPEAKER_02 1:06:15

Yeah.

SPEAKER_01 1:06:16

It's a drop in the ocean of the overall set of interactions. So, anyway, there were some open source efforts, uh, specifically agency that we partnered with them on and did a bunch of other sort of similar things. So, we knew the team. Uh, Splunk, particularly, it was acquired by Cisco a couple of years ago, and they are an absolute beast. They are kind of running the data systems of the world. They have thousands and thousands of enterprise customers who use them as a telemetry logging system. But also over the years, they've built out this amazing observability stack, which is kind of silicon up. They have observability at each layer. Uh no, Cisco is traditionally known for uh networking and security, but they have really honed in on application observability in the last decade. And the gap was agents. So now, you know, traditional applications will move. I said, right, software is just tokens now. So everything is just gonna change very quickly. So that kind of shows you the sense of urgency. That's why we are such a clean fit into you know Splunk's uh overall stack. But not just that, uh Cisco is one of the fewest companies in the world, which is treating observability and security as two sides of the same coin. They have products such as AI Defense, which is Solving Core Security, they have network security uh companies, acquisitions that they've made, like Thousand Eyes in the past, App Dynamics, uh of course Splunk. Uh so they've filled out a lot of these gaps that they they had and they've built this beautiful stack on top of their federated data metrics. Um, so we are sort of their agentic observability and security uh play. So that's how it kind of happened. We uh I feel like looking at the five-year journey, going back to the first day, I mean, I can't even recognize the company that it is because the whole world has changed four times over in the last five, six years. Uh, so firstly, thank you for the wishes. It certainly means a lot as a founder to see the company succeed and seeing all the employees, all the work that our engineers, our product teams, our GTM teams, all the work they've done, you know, come to fruition. But it's really not the end of the Galileo story. We will continue the Galileo story just within Cisco, except now we have the rocket fuel of unimaginable proportions. So I'm personally super excited. A company which was literally started in my garage with a little table and there was a heater because the garage was too cold, going from there to hopefully the next five years. Yeah, Cisco serves 80% of the world's internet. And they it's just unfathomable the scale at which they operate. Uh, they're a phenomenal company, they're the top 25 companies in the world. And to see Galileo be the agentic fabric for any application that's on the Cisco stack, I mean it's a dream come true.

SPEAKER_00 1:09:24

Yeah, yeah, absolutely, absolutely. Congratulations again, Athena. Thank you. And thank you so much again for the podcast. Thank you for having me. This was such a pleasure. I think this was one of the most beautiful conversations uh that I ever had.

SPEAKER_02 1:09:36

Thank you.