رونوشت کامل Beyond the Chatbot: Practical Frameworks for Agentic Capabilities in SaaS

thinking organizations that are revolutionizing 26 00:02:12.260 --> 00:02:14.020 their data engineering with Bruin. 27 00:02:14.260 --> 00:02:18.100 Get started today at aiengineeringpodcast.com/bruin. 28 00:02:18.100 --> 00:02:46.190 And for dbt cloud customers, enjoy a $1,000 credit to migrate to Bruin Cloud. Your host is Tobias Maci, and today I'm interviewing Preeti Shukla about the process for identifying weather and how to add agentic capabilities to your SaaS platform. So, Preeti, can you start by introducing yourself?  29 00:02:46.270 --> 00:02:54.535 Absolutely, Tobias. Thank you so much for having me today. It's my pleasure. A little bit about myself. I'm a product and engineering leader with, twenty years building and scaling b to b and enterprise grade products, mostly SaaS products. I have led products and teams across three major transitions of industry. I started my career in on premise enterprise SaaS, moved on to 30 00:02:54.855 --> 00:02:55.655 SaaS 31 00:02:55.815 --> 00:03:02.695 products, you know, and then off late more recently, I've been working on Geni and agentic products, navigating teams and products 32 00:03:03.255 --> 00:03:10.510 into shifting into navigating this very transitional time of our industry. And that's the lens I bring to this conversation today. 33 00:03:11.390 --> 00:03:13.310 And in that context, 34 00:03:13.310 --> 00:03:17.950 what was your introduction into this overall space of AI 35 00:03:17.950 --> 00:03:23.405 and just some of the background that you bring to your perspective perspective on on it? It? Absolutely. 36 00:03:23.405 --> 00:03:26.845 So I got little exposure to classical 37 00:03:26.845 --> 00:03:39.050 machine learning. You know, when I was an engineering leader at Workday, we were building financial applications and working on credit scoring for the customers. But this was mostly pre AI era 2015. 38 00:03:39.050 --> 00:03:45.530 I would say that I really immersed myself into AI when I did my own startup, which was an AI powered, a two sided platform, 39 00:03:45.530 --> 00:03:55.584 and that's where we actually built a recommendation engine. So I think that was my first AI native experience when it comes to building the products. And after that, I have had opportunities 40 00:03:55.584 --> 00:03:56.944 to lead various 41 00:03:56.944 --> 00:04:00.385 traditional SaaS enterprise and b to b companies into 42 00:04:00.625 --> 00:04:03.504 mostly Geni and agentic products. 43 00:04:04.640 --> 00:04:09.520 And so in this context of SaaS platforms, 44 00:04:09.599 --> 00:04:10.320 obviously, 45 00:04:11.120 --> 00:04:12.720 really iconified 46 00:04:12.720 --> 00:04:21.985 maybe the past fifteen years worth of Internet focused business. And And I'm wondering if you can talk to some of the ways that the introduction 47 00:04:21.985 --> 00:04:22.705 of 48 00:04:22.865 --> 00:04:24.545 agentic capabilities 49 00:04:24.705 --> 00:04:28.625 and AI powered features just changes the requirements 50 00:04:28.625 --> 00:04:30.865 around the technical considerations. 51 00:04:32.290 --> 00:04:33.730 Yeah. Absolutely. 52 00:04:33.970 --> 00:04:36.210 I mean, to understand about, 53 00:04:36.530 --> 00:04:43.090 SaaS businesses, which most of us do is they operate under certain constraints and expectations. 54 00:04:43.090 --> 00:04:48.485 SaaS fundamentally is a delivery model. And you basically deliver the same software 55 00:04:48.565 --> 00:04:51.845 in a repetitive fashion at scale to multiple customers. 56 00:04:51.925 --> 00:05:04.710 And certain SaaS artifacts and metrics like service level agreements, pricing tiers, MRR, churn, those things become really important and that's what differentiates SaaS businesses from traditional softwares. 57 00:05:04.710 --> 00:05:05.990 An AI agent, 58 00:05:06.150 --> 00:05:09.350 thus has to operate within those bounds. 59 00:05:09.430 --> 00:05:13.645 If for example, if an agent is displaying high latency behavior, 60 00:05:13.805 --> 00:05:22.525 that will directly and negatively impact the SLAs that SaaS provider has committed to its customer. You know? Similarly, if an agent is mixing 61 00:05:22.699 --> 00:05:25.340 variable compute on a fixed subscription, 62 00:05:25.580 --> 00:05:29.820 that will again negatively impact the unit economics of the SaaS itself. 63 00:05:29.979 --> 00:05:34.220 So I would say just to sum that up, considering both business and technical considerations, 64 00:05:34.220 --> 00:05:34.700 latency, 65 00:05:35.660 --> 00:05:37.020 cost, customer satisfaction, 66 00:05:37.485 --> 00:05:44.285 data privacy, tenant isolation. You know, these are some of the core traits of what an AI agent has to 67 00:05:44.525 --> 00:05:49.485 deliver at at a very high level in order to be instrumental when it comes to, 68 00:05:49.805 --> 00:05:52.764 being a core feature of AI SaaS business products. 69 00:05:54.560 --> 00:05:55.920 If I can characterize 70 00:05:55.920 --> 00:06:06.560 the overall space of SaaS, which is a very broad range, I would say that some of the key elements are economies of scale and 71 00:06:05.485 --> 00:06:12.365 the ability to rapidly deploy changes without having to wait for the distribution 72 00:06:12.365 --> 00:06:22.860 of physical media that was the hallmark of the nineties and early two thousands where you had to wait until you got a new CD to install the latest version of whatever the system is and 73 00:06:23.180 --> 00:06:25.660 being more subscription based versus 74 00:06:25.660 --> 00:06:29.020 a flat fee for purchase of a physical medium. 75 00:06:29.260 --> 00:06:32.675 And with the fact that these businesses 76 00:06:32.914 --> 00:06:37.475 do focus a lot on that unit economics of delivery for that software, 77 00:06:37.955 --> 00:06:44.754 how does the introduction of agentic capabilities and agentic use cases change those ROI calculations, 78 00:06:45.050 --> 00:06:50.090 particularly given the highly variable nature of a

lot of these generative AI systems? 79 00:06:50.410 --> 00:06:51.370 Absolutely. 80 00:06:51.450 --> 00:07:09.555 That's a great question. And I'm gonna start by saying that at the intersection of AI agents and SaaS, we are seeing very interesting pricing already. You know, SaaS was long known for seed based pricing that gave SaaS providers very predictable revenue. 81 00:07:09.794 --> 00:07:19.800 What has happened off late is we are seeing variations on those pricing, outcome based pricing, credit based pricing. These are really AI agent introduction 82 00:07:19.800 --> 00:07:23.639 or I would say, like, transformation of the traditional SaaS pricing. 83 00:07:23.720 --> 00:07:28.280 And, you know, it is necessary. You know, if we think from a business ROI 84 00:07:28.715 --> 00:07:30.635 and if I put it very 85 00:07:30.955 --> 00:07:31.755 simply, 86 00:07:32.395 --> 00:07:35.595 the total cost of all the features 87 00:07:35.754 --> 00:07:37.435 and or workflows 88 00:07:37.675 --> 00:07:40.955 that a SaaS provider is providing to a customer 89 00:07:41.350 --> 00:07:42.870 should not exceed 90 00:07:43.270 --> 00:07:46.870 the subscription price that customer is paying to the SaaS provider. 91 00:07:46.950 --> 00:07:49.030 And it was kind of simple, 92 00:07:49.110 --> 00:07:53.110 know, relatively simpler to price that model and to get that 93 00:07:53.525 --> 00:08:02.085 predictable revenue on a monthly and an annual basis. But now what has happened, is the point I was alluding to before. 94 00:08:02.245 --> 00:08:05.125 There is a lot of mixing between variable compute. 95 00:08:05.490 --> 00:08:07.010 So if your workflow 96 00:08:07.010 --> 00:08:08.370 really involves 97 00:08:08.450 --> 00:08:21.885 moral goals, which they almost always do, you know, so now we are talking about a variable compute and we have to be very careful when we do cost estimation and to ensure that agents are not out costing the unit economics 98 00:08:21.885 --> 00:08:22.685 itself. 99 00:08:23.245 --> 00:08:24.125 Another 100 00:08:24.125 --> 00:08:26.845 factor of relying on 101 00:08:27.085 --> 00:08:29.165 model providers specifically 102 00:08:29.165 --> 00:08:38.450 is that it brings with it a certain amount of platform risk where you're depending on the capabilities of that system to deliver on its functionality 103 00:08:38.690 --> 00:08:41.010 for you to be able to serve your customers. 104 00:08:41.570 --> 00:08:42.530 And so 105 00:08:42.850 --> 00:08:45.490 particularly large and technically forward 106 00:08:45.865 --> 00:09:10.160 companies will maybe opt to self host some of those models or for purposes of being able to bring it in for fine tuning and drive some of those costs down or improve the predictability of cost. And I'm wondering what you're seeing as some of the tactical elements of how companies are thinking about that question of which models should I be using, which providers should I be relying on, and how do I develop 107 00:09:10.160 --> 00:09:11.760 some of that confidence 108 00:09:12.065 --> 00:09:13.265 in the 109 00:09:13.425 --> 00:09:20.625 capabilities of that model, particularly if you're using one of the hosted providers such as Anthropic, OpenAI, 110 00:09:20.625 --> 00:09:21.265 Google, 111 00:09:21.584 --> 00:09:29.100 where the actual model might change under the covers without you knowing it because they're not necessarily going to advertise every incremental update? 112 00:09:29.740 --> 00:09:35.020 I guess there are two ways I look at it. So there are two frameworks that can be applied. 113 00:09:35.340 --> 00:09:36.380 One is 114 00:09:36.540 --> 00:09:37.980 most widespread 115 00:09:37.980 --> 00:09:54.610 is segmenting the market based on what kind of SaaS businesses they are, and that roughly correlates to the kind of use cases they have. So I'm talking in terms of b to c SaaS, b to b SaaS, enterprise SaaS. So, you know, and that roughly correlates to b to c SaaS 116 00:09:54.770 --> 00:09:56.450 having simpler 117 00:09:56.530 --> 00:10:08.035 workflows, mostly Geni dominated. And, of course, there are exceptions. But but in this really, you know, like, easier to understand framing really correlate b to b and enterprise SaaS 118 00:10:08.115 --> 00:10:09.394 with more complexity. 119 00:10:09.475 --> 00:10:11.954 So b to c SaaS at the lower spectrum, 120 00:10:12.035 --> 00:10:13.555 more generally dominated 121 00:10:13.634 --> 00:10:29.750 where front end models do great. Front end models will continue to do great on those. There is not really a lot of requirement to fine tune those, you know, prompt, a well written production prompt with a few short learning, many short learning, those kind of things still help. 122 00:10:29.990 --> 00:10:34.470 But when we are talking about b to b SaaS and enterprise SaaS, that's where complexity comes. 123 00:10:35.135 --> 00:10:39.935 You are talking about multi agent, complicated orchestration, 124 00:10:40.335 --> 00:10:47.295 more token utilization that really skyrockets the cost, governance and compliance. You know? And and this complex 125 00:10:47.610 --> 00:10:52.010 these complex workflows and scenarios, they really call for more sophisticated 126 00:10:52.570 --> 00:10:59.529 strategies on which models to use, whether to self host, and usually, it is use case driven. If your workflow 127 00:10:59.529 --> 00:11:00.330 requires 128 00:11:00.975 --> 00:11:07.135 anything with respect to natural language processing, still front end models do great, but there are strategy 129 00:11:07.774 --> 00:11:11.055 there are techniques to use cheaper models for classification 130 00:11:11.055 --> 00:11:18.730 or for labeling. So there is capability routing based on the capability of the model itself. There are other techniques like RAG, 131 00:11:18.889 --> 00:11:28.329 such that your prompt doesn't become too bloated. You you can ground your agentic behavior into enterprise documents. So I think those are

some of the strategies. 132 00:11:28.655 --> 00:11:29.855 And observability 133 00:11:29.855 --> 00:11:31.775 and evaluation strategies, 134 00:11:31.775 --> 00:11:32.895 they continue. 135 00:11:33.055 --> 00:11:39.215 I guess we are going to hear more and more about them. I'm already hearing a lot in tech circles, 136 00:11:39.215 --> 00:11:40.095 conversations, 137 00:11:40.175 --> 00:11:45.340 you know, that I'm part of in big conferences. Everybody is talking about evaluations and guardrails. 138 00:11:45.660 --> 00:11:51.820 Irrespective of the workflow complexity for any production grade software observability platforms are 139 00:11:51.980 --> 00:11:55.820 playing a big instrumental role in helping providers 140 00:11:56.334 --> 00:11:58.095 navigate these challenges. 141 00:11:58.415 --> 00:12:06.815 And real real quick, you know, I I said there are two frameworks. So the other framework that I will quickly talk about is irrespective of the market segmentation, 142 00:12:06.815 --> 00:12:13.090 what is the complexity of automation itself? And we can think about rule based automation, the the simple automation. 143 00:12:13.650 --> 00:12:18.530 And then the next is intelligent automation. So now give your automation some brains, 144 00:12:18.690 --> 00:12:21.410 you know, give that LLM, 145 00:12:21.490 --> 00:12:29.735 some memory, some tools, and, you know, that's that is going to deliver a lot of value over a rule based automation. And then really the third, 146 00:12:30.055 --> 00:12:31.335 frontier is 147 00:12:31.575 --> 00:12:32.455 self 148 00:12:32.615 --> 00:12:34.215 autonomous agents, 149 00:12:34.855 --> 00:12:46.550 which as all of us know, they are yet to be seen deployed widely on production. So really the sweet spot is b to b SaaS medium complexity intelligent automation that most 150 00:12:46.790 --> 00:12:48.710 production agents are capable of. 151 00:12:49.830 --> 00:12:54.995 And there's also a wide degree of variability in terms of the 152 00:12:55.155 --> 00:12:56.115 presentation 153 00:12:56.115 --> 00:13:00.755 of those agents where some of them might be something where it's a chat focused 154 00:13:00.835 --> 00:13:09.635 interaction where I, as a customer of the SaaS platform, am going to go and maybe there's some text input or some document upload capability 155 00:13:09.879 --> 00:13:11.800 that will then trigger a workflow 156 00:13:11.959 --> 00:13:17.399 versus an agentic capability that is entirely invisible to me as a customer, but facilitates 157 00:13:17.959 --> 00:13:30.035 the operation of the platform and maybe power some of the actual feature set that I am interacting with, but I don't know that it's necessarily an agentic loop that's running in the background to perform those activities. 158 00:13:30.515 --> 00:13:33.395 And I'm wondering how you're seeing 159 00:13:33.715 --> 00:13:35.235 SaaS systems 160 00:13:35.715 --> 00:13:37.395 determine what are the 161 00:13:38.079 --> 00:13:41.920 integration points and exposure points that are most useful 162 00:13:42.160 --> 00:13:42.959 for 163 00:13:43.360 --> 00:13:50.000 agentic use cases and whether and when to expose that to the customer versus keeping it internal 164 00:13:50.405 --> 00:13:58.645 and some of the trade offs of those decisions as far as the appearance of being sophisticated and capable versus 165 00:13:58.885 --> 00:13:59.765 preventing 166 00:13:59.925 --> 00:14:06.085 the customer from getting stuck in the heightened expectations of, oh, well, they have an AI, so that means they can do anything. 167 00:14:07.100 --> 00:14:08.220 Absolutely. 168 00:14:08.220 --> 00:14:15.020 I would say that the most successful transformations I've seen are that start with internal adoption first 169 00:14:15.420 --> 00:14:23.075 and then moving it on to making them customer facing features, you know, as as we serve them in a SaaS bundle. 170 00:14:23.395 --> 00:14:31.155 But I think companies that are embracing AI culture first, they also adopt AI the first and that kind of 171 00:14:31.475 --> 00:14:34.755 brings everybody on the board, you know, leadership, 172 00:14:34.755 --> 00:14:35.555 sponsors, 173 00:14:35.555 --> 00:14:36.675 teams, leaders. 174 00:14:37.300 --> 00:14:38.580 And when 175 00:14:38.580 --> 00:14:40.580 they have really worked, 176 00:14:40.900 --> 00:14:48.020 especially especially with AI agents, they very well know the limitations of it, you know. And I think that helps them empathize 177 00:14:48.340 --> 00:14:53.635 when we will be ready to really make it into a customer facing feature. 178 00:14:53.875 --> 00:14:58.995 So I think that's really the first step that I've seen. First internal adoption happens 179 00:14:59.395 --> 00:15:05.315 and then when customer adoption happens. And even when it comes to customer adoption 180 00:15:05.480 --> 00:15:18.120 even internal adoption for that matter, there are some low hanging fruits, you know, as as we were talking about. Again, going back to the complexity or using a b to c kind of simpler side of the spectrum 181 00:15:18.405 --> 00:15:19.285 chatbot, 182 00:15:19.285 --> 00:15:21.365 know, maybe one one agent is, 183 00:15:21.685 --> 00:15:24.885 good enough because it's just one workflow 184 00:15:25.285 --> 00:15:28.485 that you need and it's a simple workflow. 185 00:15:28.485 --> 00:15:32.639 And then, you know, one agent with with good enough capabilities 186 00:15:32.720 --> 00:15:37.439 with some simple memory management and having tool access like Gmail, 187 00:15:37.439 --> 00:15:38.320 Gcal, 188 00:15:38.560 --> 00:15:40.720 a notetaker is good enough. 189 00:15:40.959 --> 00:15:50.695 But when it again comes to more complex use cases, that's where my recommendation is that it's good to start with a graduated autonomy, 190 00:15:50.695 --> 00:15:53.655 you know, when it comes to rolling out AI 191 00:15:53.655 --> 00:15:58.295 agentic features. Use cases that are well known and documented use

cases that have actually 192 00:15:58.850 --> 00:16:03.890 proven ROI on the production. Those are the ones we start with, be it internal or be it SaaS. 193 00:16:04.050 --> 00:16:05.250 And they are usually 194 00:16:05.490 --> 00:16:09.410 in level one and two automation, like intelligent automations. 195 00:16:09.570 --> 00:16:13.090 But and then gradually moving it on to 196 00:16:13.435 --> 00:16:18.395 to, like, the more complex use cases where you might need more r and d focus. 197 00:16:18.635 --> 00:16:35.100 I'll also, you know, take take this moment to something that I hear a lot, what is the perfect use use case for When not to use AI agent? Because we are kind of in discussing that. So I think one thing is, like, even before we get into what are the use cases of AI agent, 198 00:16:35.339 --> 00:16:44.075 I think we need to do a binary check whether we we need AI agents for that or not. So unless your workflow is really multi step, repetitive, 199 00:16:44.315 --> 00:16:45.515 needs autonomy, 200 00:16:45.834 --> 00:16:50.954 and has a clear goal, you know, that's where an AI agent consideration makes sense. 201 00:16:51.355 --> 00:16:59.840 There are some examples where your classical there are some use cases where your classical ML will continue to do just fine. You know, if you're talking about prediction, 202 00:17:00.400 --> 00:17:02.480 time time series forecasting, 203 00:17:02.960 --> 00:17:23.150 classical ML will continue to do well there. If you're talking about a Geni natural language processing like extraction summarization and that doesn't have any complex workflow just to that. Of course, you know, Geni capabilities continue to work fine. And then really when it comes to multiple flow, multi step, repetitive steps where you need autonomy, 204 00:17:23.150 --> 00:17:24.749 that's where you really consider 205 00:17:24.910 --> 00:17:31.950 AI agents. And once you establish that, then there are various use cases on what models to use, what what use cases to make. 206 00:17:32.750 --> 00:17:40.255 For companies that are incorporating some of these AI focused use cases, particularly with these generative AI platforms, 207 00:17:40.575 --> 00:18:02.345 what are some of the ways that you are seeing them address some of that confidence building where you mentioned they might start as an internal proof of concept. But what are the signals that give them the what are the signals that let them know that this is ready to actually put in front of customers and expose and advertise around and some of the ways that they 208 00:18:02.505 --> 00:18:09.304 need to change some of their operational maturity around things like testing and evaluation 209 00:18:09.784 --> 00:18:16.820 beyond just the ability to run a software system because of the fact that these AI platforms are 210 00:18:16.980 --> 00:18:24.179 so dramatically different from traditional software of I can run a web application and keep it stable and scalable. 211 00:18:24.500 --> 00:18:27.860 Now I need to make sure that it's actually able to sustain 212 00:18:28.325 --> 00:18:31.524 the load of nonhuman entities interacting with it. 213 00:18:32.245 --> 00:18:33.845 Yes. Absolutely. 214 00:18:33.925 --> 00:18:40.805 So the challenge is really AI agents in a SaaS context are expected to display deterministic 215 00:18:40.805 --> 00:18:41.684 behavior 216 00:18:41.845 --> 00:18:44.900 while they are, you know, like, undeterministic. 217 00:18:44.900 --> 00:18:50.260 And I think one thing there are a few things that a team have to do groundwork upon. 218 00:18:50.340 --> 00:18:52.980 Will this SaaS flow respect the latency? 219 00:18:53.060 --> 00:18:54.900 Will will this flow 220 00:18:54.900 --> 00:18:59.184 respect the unit economics and most importantly, 221 00:18:59.665 --> 00:19:02.945 the technical aspect of reliability and predictability? 222 00:19:03.265 --> 00:19:07.345 And and there are certain strategies as we talk evaluation, 223 00:19:07.345 --> 00:19:12.270 you know, so what I'm seeing is that teams are really experimenting 224 00:19:12.270 --> 00:19:16.830 with a layered evaluation strategy approach. So it's not just one score 225 00:19:16.910 --> 00:19:21.389 or it's not just one test that you embed it embed in your CICD pipeline. 226 00:19:21.710 --> 00:19:23.790 But there is whole evaluation engineering. 227 00:19:24.455 --> 00:19:29.175 And, like, to to, you know, like, to be more specific about that, there are deterministic 228 00:19:29.175 --> 00:19:33.255 checkpoints as part of evaluation at the base level, schema 229 00:19:33.255 --> 00:19:34.134 validation, 230 00:19:34.135 --> 00:19:35.335 policy validation. 231 00:19:35.575 --> 00:19:36.535 Really the cheap ones, 232 00:19:37.170 --> 00:19:41.170 low cost test. And then moving on to more advanced 233 00:19:41.170 --> 00:19:43.170 outcome based test, 234 00:19:43.330 --> 00:19:44.450 GOLDEN datasets. 235 00:19:44.690 --> 00:19:47.330 So these are the standard datasets 236 00:19:47.410 --> 00:19:49.730 that will help catch any regressions, 237 00:19:50.005 --> 00:20:04.164 you know, because moral changes, workflow changes, but these are standards that will always ensure that you are getting same expected output over a period of time. One more strategy I've seen is when fuzzy logic is involved, 238 00:20:04.245 --> 00:20:07.710 LLM as a judge. So let's say you have a chat bot and, 239 00:20:08.670 --> 00:20:15.790 you have to monitor what's the performance of it or when it is safe to rule out to customers. And I'm I'm assuming 240 00:20:15.790 --> 00:20:34.629 that all of all of this is done in pilot first. You know. So you have a POC first, but then you have a pilot with one or two beta tenant before you really roll it out to production. So when it's still in pilot phase where you have access to some real tenanted data, you know, these are the evaluations and checks. So these LLMS 241 00:20:34.870 --> 00:20:37.109 judges are really

your confidence scoring. 242 00:20:37.270 --> 00:20:38.789 And when your confidence 243 00:20:39.270 --> 00:20:45.030 score drops below a certain percentage, like, it's not 80% anymore, that's when you bring human in the loop. 244 00:20:45.825 --> 00:20:51.024 You know? So I guess there are various layered evaluation strategies. There are also techniques that run 245 00:20:51.424 --> 00:20:53.744 that talk about running offline 246 00:20:53.985 --> 00:21:01.639 evaluations in the CICD pipeline, but also more runtime evaluations while the customer is using production. And again, observability platform, 247 00:21:01.720 --> 00:21:05.799 play a big role. So I would say really the decision comes down to 248 00:21:06.120 --> 00:21:09.080 when is your AI pilot implementation 249 00:21:09.559 --> 00:21:15.325 passing your cutoffs or benchmarks that you have set via these evals and guardrails. 250 00:21:15.565 --> 00:21:16.364 And 251 00:21:16.765 --> 00:21:20.764 build versus buy is the perennial challenge in technology. 252 00:21:20.924 --> 00:21:25.960 I'm curious what your thoughts are on that equation for 253 00:21:25.960 --> 00:21:27.240 teams that are 254 00:21:27.560 --> 00:21:30.280 planning on implementing an agentic capability 255 00:21:30.280 --> 00:21:36.440 in their SaaS platform. Should they just buy an off the shelf system that handles a lot of the 256 00:21:36.735 --> 00:21:38.175 rag and evaluation 257 00:21:38.175 --> 00:21:46.654 and LLM serving and load balancing around that so that they can just plug in their system and get some of the out of the box behaviors or 258 00:21:46.815 --> 00:21:52.010 because of the fact that maybe it is a business critical capability, is that worthwhile 259 00:21:52.010 --> 00:21:58.809 having your own team own the end to end capability and maybe what are the gradations along that continuum? 260 00:21:59.370 --> 00:22:00.409 Yeah. 261 00:22:00.409 --> 00:22:01.129 Absolutely. 262 00:22:01.370 --> 00:22:22.799 I think the debate has been there since long, even pre AI, you know, whether you build or or you buy a product. And I think I kind of agree to how you framed your question and, you know, that had kind of answer to that as well. It all comes down to business capability. You know, if this is something that is truly tied to ROI of your SaaS business, 263 00:22:23.120 --> 00:22:31.120 that is core part of your business or core workflow of your business, that's where you should build it. And something which is infrastructure 264 00:22:31.120 --> 00:22:38.834 related, something which is peripheral in nature like a vector database. There are so much work happening. There are cloud providers 265 00:22:38.835 --> 00:22:45.154 also that continue to offer newer AI infrastructure that will help SaaS softwares, 266 00:22:45.475 --> 00:23:01.600 improve their capabilities over a period of time. So, you know, so I think that's the general guidance that still holds true in my opinion. So, you know, it comes down to what is the business capability. Now I will also say that there are some exceptions to it, you know, and, we are talking about 267 00:23:01.924 --> 00:23:09.524 enterprises that work with federal data or government data, and they have to work in more stricter, like more stringent 268 00:23:09.525 --> 00:23:12.884 compliance laws, regulations laws, data residency, 269 00:23:12.965 --> 00:23:28.060 or they have a military contract. So they have to operate under certain constraints that might kind of make building a better choice for them. But but for most of us, for for the rest of us, that guidance on build versus buy still hold true. 270 00:23:30.075 --> 00:23:35.674 And then the other piece of this too is that AI systems are very data hungry, 271 00:23:35.915 --> 00:23:37.434 and that requires 272 00:23:37.755 --> 00:23:45.299 a separate set of technical and operational maturity for being able to manage a lot of those data flows. 273 00:23:45.460 --> 00:23:45.940 And 274 00:23:46.340 --> 00:24:00.695 many businesses, particularly if they're on the smaller end of the spectrum, aren't necessarily going to invest in headcount for data engineers and AI engineers in addition to the software engineers that are focused on the core product delivery. 275 00:24:00.855 --> 00:24:03.735 And I'm wondering how you're seeing teams 276 00:24:03.975 --> 00:24:07.095 address some of that increased operational 277 00:24:07.095 --> 00:24:09.255 maturity requirement 278 00:24:08.640 --> 00:24:17.840 to be able to provide all of the data and context to these AI systems to make sure that they're able to operate effectively 279 00:24:18.000 --> 00:24:22.880 and have appropriate grounding for the operations 280 00:24:22.880 --> 00:24:23.760 that they're providing? 281 00:24:25.045 --> 00:24:25.845 Absolutely. 282 00:24:25.925 --> 00:24:30.565 So data is the real mode in AI era. You know? 283 00:24:30.805 --> 00:24:33.125 I think we have learned this 284 00:24:33.365 --> 00:24:36.485 that the data continue. And this also 285 00:24:36.725 --> 00:24:39.125 comes down to which 286 00:24:39.580 --> 00:24:42.460 company is going to run with a successful AI product. 287 00:24:42.860 --> 00:24:48.140 As they say garbage in garbage out, you know. So if if teams don't have access to 288 00:24:48.460 --> 00:24:51.420 write, sanitize, accurate data, 289 00:24:51.740 --> 00:24:57.715 that means they have to do work on the data pipeline first because AI doesn't really fix 290 00:24:58.195 --> 00:25:15.279 workflows that are already broken, you know, or workflows that don't operate with good data. So I think that's definitely there. If companies have access, so there are various startups, you know, so I'm gonna first talk about startups because that might be more challenging for for startups who are trying 291 00:25:15.520 --> 00:25:23.455 who are new AI comers. They might have access to data. In some cases, they don't have to data. So either they're operating 292 00:25:23.775 -->

00:25:26.174 as an AI infra startup or 293 00:25:26.575 --> 00:25:27.695 they're operating 294 00:25:27.695 --> 00:25:29.135 as a SaaS application, 295 00:25:29.135 --> 00:25:32.015 you know, where they are using existing frontier models 296 00:25:32.175 --> 00:25:33.295 for their use cases. 297 00:25:33.850 --> 00:25:38.729 So I would say that the way AI infra providers have enabled 298 00:25:39.049 --> 00:25:39.849 startups 299 00:25:40.009 --> 00:25:48.345 during the cloud era, they will continue to do that. But again, it comes down to individual use cases. For a very small startup 300 00:25:48.345 --> 00:26:08.470 for which they really don't need to own AI infra and they can operate off, let's say, data provided by Apple watches. Let's say they are a consumer apps. So I think they have to abide by data privacy laws but I think they can still work with this big ecosystem where there are enablers, 301 00:26:08.630 --> 00:26:09.909 you know, like AI, 302 00:26:10.309 --> 00:26:21.754 in fact, providers are big four companies that have access to the data. And then the second type we are talking about is companies that themselves are, like an AI data platform company, 303 00:26:21.755 --> 00:26:25.674 you know. So that's where they have to do more rigor on 304 00:26:25.915 --> 00:26:28.315 making sure that they have the right resources 305 00:26:29.040 --> 00:26:30.720 to sanitize the data, 306 00:26:30.960 --> 00:26:37.680 get the right team structure for promoting that AI data before they can really incorporate that as an AI product. 307 00:26:39.040 --> 00:26:43.565 And then on as a corollary to that data requirement 308 00:26:43.565 --> 00:26:53.965 is the challenge of the I've seen it phrased as the confident idiot where the AI will very certainly give you an answer that is unequivocally wrong. 309 00:26:54.660 --> 00:26:57.700 But if it passes it off with enough 310 00:26:57.860 --> 00:26:58.820 confidence, 311 00:26:58.820 --> 00:27:02.580 then people will accept that as wrong, and that can lead to a lot of problems. 312 00:27:02.820 --> 00:27:03.380 And 313 00:27:03.700 --> 00:27:06.260 what are some of the ways that you're seeing teams 314 00:27:06.260 --> 00:27:12.524 try to address that challenge and identify some of these confident falsehoods 315 00:27:12.684 --> 00:27:23.644 and steer the AIs in the appropriate direction. And because of the fact that that is a never ending battle, what are some of the systems that they need to have in place to be able to 316 00:27:24.090 --> 00:27:25.529 identify and, 317 00:27:25.929 --> 00:27:26.730 correct 318 00:27:26.730 --> 00:27:27.369 those 319 00:27:27.530 --> 00:27:28.809 decision making 320 00:27:28.970 --> 00:27:32.570 steps that the AI might lead you down the wrong path towards? 321 00:27:33.210 --> 00:27:34.169 Absolutely. 322 00:27:34.410 --> 00:27:53.610 And I would say, like, those are the most dangerous ones, you know, the silent failures or the most confident failures that just cash

teams off guard. What I've seen working is that there is definitely the implementation part of that and there's a validation part of that and then monitoring. So if you really break break down, 323 00:27:53.930 --> 00:27:55.530 into implementation 324 00:27:55.530 --> 00:28:06.570 versus validation versus monitoring then there are certain tried and tested strategies that work. I think we can start with the basis like a good well written production grade prompt. 325 00:28:07.054 --> 00:28:11.134 I think that at the base level ensures that 326 00:28:11.535 --> 00:28:14.494 your AI solution doesn't hallucinate, 327 00:28:14.735 --> 00:28:16.414 breaking down structures, 328 00:28:16.414 --> 00:28:20.414 breaking down prompt still works. I think that that's still a very effective strategy. 329 00:28:20.890 --> 00:28:26.809 What I encourage my engineers to do is and I do it myself. It's like go go read production level prompts. 330 00:28:27.049 --> 00:28:39.225 And I think it it needs some training because sometimes to ask appears very simple. You know? Like, summarize this data. But when you really think through that and when you start observing agentic behavior or LLM behavior, 331 00:28:39.465 --> 00:28:44.904 you will start to see a pattern of the mistake it does, you know, and and then you might want to give it a structure, 332 00:28:45.145 --> 00:28:46.184 summarize this 333 00:28:46.429 --> 00:28:49.629 in four sections. Talk about an introduction, 334 00:28:49.710 --> 00:28:59.390 then talk about a hook, and then end with the conclusion. So I think I highly encourage that. It's a low hanging fruit. It still works effectively. 335 00:29:00.045 --> 00:29:04.685 Second, I would say is more for b to b SaaS and enterprise grade software. 336 00:29:04.765 --> 00:29:06.765 Rag is number one. 337 00:29:07.565 --> 00:29:13.085 I I still believe it to be number one most effective technique when it comes to grounding 338 00:29:13.519 --> 00:29:14.879 AI output 339 00:29:14.960 --> 00:29:15.839 into 340 00:29:16.159 --> 00:29:23.120 truth. So you can have your enterprise policy documents, you can have your HR policy documents, customer success. 341 00:29:23.120 --> 00:29:28.965 It could also be something very specific to your domain, like a medical chatbot or like a legal chatbot. 342 00:29:28.965 --> 00:29:31.364 I think they can definitely be given 343 00:29:31.765 --> 00:29:33.445 loads of information 344 00:29:33.445 --> 00:29:39.660 that that can be fed. So I think these two or three strategies really help minimize hallucination. 345 00:29:39.660 --> 00:29:54.605 Now we all know that that's not enough at this point of time, you know, because AI solutions are still improving and that's where validation comes into the picture, you know, and I guess all the evaluation strategies that I was sharing with you before, they they play a crucial role. 346 00:29:55.005 --> 00:29:57.965 And as as I was saying, there are various sophisticated 347 00:29:57.965 -->

00:30:02.845 ways of grading an output. You know? You can use LLM as a judge. You can use golden datasets. 348 00:30:03.260 --> 00:30:06.060 You can also do path evaluation. 349 00:30:06.060 --> 00:30:09.660 I I think this one specifically because you set the confident ones. 350 00:30:09.820 --> 00:30:21.154 So, you know, the confident ones and the most tricky ones to capture are the ones that slowly improve the latency. They are those agents or those AI solutions are doing multiple retries. 351 00:30:21.155 --> 00:30:24.355 You know? And they might end up giving you the right answer, 352 00:30:24.595 --> 00:30:26.115 but only in certain 353 00:30:26.275 --> 00:30:35.469 production cases you would see that. So I guess past level evaluation is where you really see not just the answer, but the behavior of the AI agent. 354 00:30:35.710 --> 00:30:41.869 So I think that is also something that I found very effective. And then really the third part is the monitoring 355 00:30:42.029 --> 00:30:57.045 part, you know, where observability platform. If you're talking in context of SaaS, it's really a cost controlling per tenant or monitoring per tenant. I would also say that stepwise budgeting or stepwise monitoring 356 00:30:57.045 --> 00:31:03.765 is because you're also looking at the whole, but you also want to look at the sum of all parts or, like, parts of all sums. 357 00:31:05.740 --> 00:31:08.700 And I think that's another element 358 00:31:08.700 --> 00:31:29.114 of the decision for whether you use a managed API only service for the model versus run it yourself is because of the ability to expose and act upon the log probability scores of the outputs to be able to see, oh, well, the model phrased this very confidently, but the log probability is actually fairly low. 359 00:31:29.514 --> 00:31:39.239 So I'm going to take a second pass to evaluate this output versus if it's an API response, you lose that insight into the inner workings of the model to determine 360 00:31:39.400 --> 00:31:41.480 what is its confidence score. 361 00:31:41.799 --> 00:31:54.325 And I'm wondering how you're seeing teams think about that as part of the overall equation of where and how to run these models and how to hook into some of those confidence metrics that the model itself generates? 362 00:31:54.485 --> 00:31:55.445 Absolutely. 363 00:31:55.845 --> 00:32:11.610 So one thing that I find more effective is monitoring at the model level, but also at the workflow level. Because what you're monitoring at the model level is just one part of the workflow. So in this model, so 5.1 364 00:32:11.610 --> 00:32:16.730 was giving me this particular summary and this is the prompt that worked with 5.1. 365 00:32:17.105 --> 00:32:19.025 But after 5.2, 366 00:32:19.105 --> 00:32:23.424 the same prompt doesn't work. So nothing has changed, but but still things have changed 367 00:32:23.745 --> 00:32:31.505 drastically, you know, like those kind of errors. So, you know, so I think when we monitor at the model level and when you write evaluations, 368 00:32:32.200 --> 00:32:39.799 you basically write it at the unit level. So I think of moral level validation as unit level test and workflow 369 00:32:40.200 --> 00:32:47.904 level test as more end to end system test or integration test. So I think that's a very rough analogy. But I think definitely monitoring 370 00:32:47.904 --> 00:32:50.464 morals output and behavior 371 00:32:50.625 --> 00:32:52.784 at an individual step level, 372 00:32:52.945 --> 00:32:54.864 but then also seeing it holistically 373 00:32:55.024 --> 00:33:00.690 that this moral output was supposed to return me summary such that 374 00:33:01.010 --> 00:33:06.049 next agent or this tool was supposed to pass it to this next API. 375 00:33:06.049 --> 00:33:14.130 You know? So I guess that's the whole flow where evals can really help you understand what part of the equation broke, why, 376 00:33:14.485 --> 00:33:31.489 and what kind of effect model changes have. Do we need to version our models? So I think that is also one more effective strategy that teams are becoming more and more aware that more upgrade may or may not help, you know. So I think by default upgrading tomorrow might not be a good strategy 377 00:33:31.650 --> 00:33:34.769 until you have really solid task. So I think definitely 378 00:33:35.809 --> 00:33:37.409 running the model changes 379 00:33:37.570 --> 00:33:39.730 in a sandbox environment first 380 00:33:40.105 --> 00:33:43.945 using things like Android deployment to slowly graduate 381 00:33:44.184 --> 00:33:51.065 the new model to your existing code code base just to do do this in a very controlled and and in a very graduated fashion. 382 00:33:53.559 --> 00:33:58.200 Going back to the multi tenant nature of these SaaS platforms, 383 00:33:58.279 --> 00:34:00.679 that also brings up the question of 384 00:34:00.760 --> 00:34:01.640 attribution 385 00:34:01.640 --> 00:34:05.799 and identity management for these autonomous actors. 386 00:34:05.880 --> 00:34:23.710 And I'm wondering how you're seeing the platform owners of these SaaS systems think about the types of additional security controls and identity frameworks that they need to have in place to be able to allow these agents to operate on behalf of the various customers 387 00:34:23.710 --> 00:34:24.430 and 388 00:34:24.589 --> 00:34:33.310 manage their either isolation within tenant boundaries or how to think about whether and when they can operate across tenant boundaries 389 00:34:33.575 --> 00:34:43.655 because of the fact that one of the core promises of these SaaS systems is that each tenant will only ever be able to access their own resources and never be able to span across them. 390 00:34:43.975 --> 00:34:44.775 Yes. 391 00:34:44.775 --> 00:34:48.055 Absolutely. I think some of the existing techniques 392 00:34:48.570 --> 00:34:55.770 AI agents have to abide by and some of the newer challenges that that come with AI agent

themselves. 393 00:34:55.770 --> 00:34:58.090 So so when I think about existing 394 00:34:58.170 --> 00:35:18.680 techniques, I would say that tenant isolation is something that continues to be supported by a successful AI agent. And the tenant isolation we are talking about is through the entire workflow of the AI agent. You know? So think in terms of memory, there should be a tenant isolation at the memory level, at the two level, 395 00:35:19.080 --> 00:35:27.240 at the database level, at the vector database level. So I think an agent should always be able to 396 00:35:27.720 --> 00:35:35.474 track on whose tenant the agent is taking an action because this is also needed for audit purposes. 397 00:35:35.474 --> 00:35:42.355 In most of the SaaS businesses, you need to be able to see who ran what, which tenant ran what 398 00:35:42.730 --> 00:35:44.730 in their isolated environment, 399 00:35:44.730 --> 00:36:06.755 what was the role agent had because an agent doesn't have an identity of itself and it runs for SaaS. It it is run for a tenant and for a user. Another technique is definitely about RBAC role, you know, role based access control that also continues to be highly relevant in in context of AI agent still. An AI agent should only be able to 400 00:36:07.075 --> 00:36:09.954 run the feature set or responsibilities 401 00:36:09.954 --> 00:36:15.619 that the role that has been given to it allows and not outside of this. So I think at a high level, 402 00:36:15.940 --> 00:36:17.700 think the tenant scoping 403 00:36:17.700 --> 00:36:28.735 and, you know, at the middle layer, I see the role scoping and really at the bottom layer is the user scoping. So I think that that framework still holds true. Some of the newer challenges with AI 404 00:36:28.735 --> 00:36:31.775 agents are of that of interoperability, 405 00:36:32.015 --> 00:36:34.255 and I would think MCP 406 00:36:34.335 --> 00:36:37.455 because an agent is calling tools, 407 00:36:37.950 --> 00:36:41.310 but I think we really wanna make sure that there are enough 408 00:36:41.390 --> 00:36:49.390 guardrails in place such that accidentally an AI agent doesn't get access to across tenanted information 409 00:36:49.630 --> 00:36:56.925 while it's calling tools. So I think tool boundaries are something to really watch out for and that's why guardrails become very, 410 00:36:57.725 --> 00:37:03.885 you know, like effective in terms of who is the agent calling, what tools are they calling and are they still maintaining the scope. 411 00:37:04.930 --> 00:37:09.410 And in your work of building these SaaS platforms, 412 00:37:09.810 --> 00:37:10.610 incorporating 413 00:37:10.610 --> 00:37:12.050 agented capabilities, 414 00:37:12.050 --> 00:37:21.005 working with other companies that are going through that same journey, what are some of the most interesting or innovative or unexpected ways that you've seen these agented capabilities incorporated 415 00:37:21.005 --> 00:37:22.525 into SaaS products? 416 00:37:23.085 --> 00:37:24.045 Absolutely. 417 00:37:24.125 --> 00:37:35.350 I mean, I think it goes without saying that the most innovative ones I've seen are not the most autonomous ones. So I not seeing that teams are really deriving 418 00:37:35.350 --> 00:37:37.990 value by making them truly autonomous. 419 00:37:37.990 --> 00:37:58.415 There is almost always a human in the loop layer for critical business use cases. There is confidence scoring. I think those things are there for sure. Some of the interesting ways I have seen is, you know, like one particular implementation I've seen where the entire multi agent framework is deployed on an on a MCP server. 420 00:37:58.495 --> 00:38:02.975 And that multi agent solution has become client agnostics. 421 00:38:03.055 --> 00:38:05.375 And that back end is via 422 00:38:05.750 --> 00:38:07.350 various front end, 423 00:38:07.910 --> 00:38:22.309 you know, so the product has its own front end, but the product, the backend product can also be served via standard MCP client like Claude. So I think that was very interesting to me, you know, because we have always talked about 424 00:38:21.405 --> 00:38:29.725 decoupling UI from the back end. But I think AI agents, especially the MCP layer is facilitating that in very interesting ways. 425 00:38:29.965 --> 00:38:35.245 So using a standard MCP client like Claude and others, you can basically interact. 426 00:38:35.740 --> 00:38:44.780 This was a chatbot. This was a salon based product. And with the standard Claude UI, you can actually talk to the AI agent, 427 00:38:45.180 --> 00:38:46.300 which is basically 428 00:38:46.380 --> 00:38:47.820 master orchestrated 429 00:38:48.095 --> 00:39:07.750 multi agent orchestration system, and you can basically ask where is the salon opening, when is the salon closing, and all sorts of things, which I think was very cool and very effective. Some of the other things I've seen and I'm sure, you know, like, these are not as unique, but I feel they're very effective is agents as code. So in order to really use 430 00:39:07.750 --> 00:39:11.030 and really make data analyst life easy, 431 00:39:11.110 --> 00:39:16.310 agents generate code on the fly using Panda libraries, using Python, 432 00:39:16.310 --> 00:39:23.545 and then you can really analyze data on the fly. What I like about these agents is that because it's non deterministic 433 00:39:23.545 --> 00:39:35.600 code, it is not good for shipping production unless you really harness that with Evasse, Godreel but it makes for a very useful use case when it comes to just analyzing data. So so I see 434 00:39:35.920 --> 00:39:47.215 this code is like using through code, but nonetheless very valuable. You know? And then one last implementation I would talk about is that we know that b two b SaaS and enterprise are mostly experimenting 435 00:39:47.215 --> 00:39:49.215 and also deploying to some extent 436 00:39:49.375 --> 00:39:51.295 multi agent systems,

437 00:39:51.295 --> 00:39:56.015 but these are very complex and these are usually high latency, 438 00:39:56.415 --> 00:39:58.260 high cost solutions. 439 00:39:58.260 --> 00:39:59.540 The more intelligent 440 00:39:59.620 --> 00:40:10.260 an AI agent is, the more costly and high latency behavior that shows. So one of the workaround I've seen is that where some teams have used agents as tools. 441 00:40:10.885 --> 00:40:14.405 So they have just one planner agent 442 00:40:14.565 --> 00:40:17.285 which has access to multiple tools, 443 00:40:17.445 --> 00:40:21.605 but one of the tools or maybe multiple tools are agents. 444 00:40:21.605 --> 00:40:25.525 So this way you avoid the complexity of a multi agent system, 445 00:40:25.605 --> 00:40:31.660 yet you can capture the value of a multi agent systems. So I think that was really interesting and cool. 446 00:40:32.540 --> 00:40:44.555 And in your experience of working in this space and helping to bring helping to bring agentic features to SaaS platforms, What are some of the most interesting or unexpected or challenging lessons that you've learned personally? 447 00:40:44.875 --> 00:40:46.955 I think moral changes, 448 00:40:46.955 --> 00:41:00.329 they fail silently. I think this is something that most of us have felt the pain of it. So I think this is something that we want to upgrade to new models because new models become with great capabilities, 449 00:41:00.329 --> 00:41:02.650 you know, when it comes to frontier models. 450 00:41:02.650 --> 00:41:13.185 But it is still very brittle and, you know, like one small model tweak. This is the scenario that I shared with you where nothing changes, but everything changes 451 00:41:13.345 --> 00:41:19.025 for bad because your workflow is still the same. But, like, you went from five to 5.1, 452 00:41:19.025 --> 00:41:20.305 5.1 to 5.2, 453 00:41:20.610 --> 00:41:29.970 and your prompt is not working anymore. Your your RAG instructions, they need to be fine tuned more. So I think that is keeps on coming. And really the strategy is 454 00:41:30.210 --> 00:41:36.215 relying heavily on evals and also coming up with a policy on when to 455 00:41:36.455 --> 00:41:43.975 deploy newer models. And I think there is a whole CICD paradigm about it. You know? So I guess that's something that 456 00:41:44.375 --> 00:41:45.735 I found interesting. 457 00:41:45.815 --> 00:41:52.600 I would also say that one thing that has taken even great teams aback is the silent retries that I also 458 00:41:52.840 --> 00:42:01.160 mentioned in one of the previous discussions we were having. This is the behavior when the output looks correct. It's it's not in functionality 459 00:42:01.160 --> 00:42:06.885 of the agent you are able to detect problem, but it's in the behavior of the agent. And by that, I mean, 460 00:42:07.045 --> 00:42:14.165 did it really take the shortest path to answering your question, or did it really go to a lot of retries, 461 00:42:14.484 --> 00:42:15.925

lot of to and fro. 462 00:42:16.085 --> 00:42:24.860 You know? So I guess just path level monitoring of an agent is what I feel is the trickiest because in some small use cases on pilot, 463 00:42:25.020 --> 00:42:40.865 you won't catch it because your evals are just looking at the right data functionally and it is giving you that. But it really comes down to production where suddenly you see unexplained latency. And I think that's why path based evaluations are really the most advanced and more sophisticated, 464 00:42:40.865 --> 00:42:44.145 which can prevent such, you know, like surprises on production. 465 00:42:45.105 --> 00:42:53.670 And we touched on this a few times, but what are the situations where you would strongly advise against the adoption of agentic behaviors 466 00:42:53.670 --> 00:42:55.270 for a SaaS platform? 467 00:42:56.150 --> 00:43:06.645 Yeah. I mean, as as we were talking about that, you know I will stress on that AI agents are non deterministic yet in a SaaS context they are expected 468 00:43:06.645 --> 00:43:10.805 to display deterministic behavior and it needs a lot of harnessing, 469 00:43:10.885 --> 00:43:18.070 lot of discipline around that. It is doable, you know, and teams are successfully doing that, but I don't think we should overengineer. 470 00:43:18.150 --> 00:43:24.549 So as we were talking about, there are some use cases, some very standard use cases where Geni, predictive AI, 471 00:43:25.095 --> 00:43:32.215 your classical ML, you know, they will continue to make a lot of sense, and they will completely deliver on the expected ROI. 472 00:43:32.215 --> 00:43:37.575 For AI agent, there has to be really use case where we are talking about multistep, 473 00:43:37.575 --> 00:43:40.500 repetitive step. They should be very action oriented. 474 00:43:40.500 --> 00:43:42.100 If you wanna explore 475 00:43:42.260 --> 00:43:45.780 something, you know, or you want a creative output, 476 00:43:46.100 --> 00:43:55.555 that's where Gen I may be a better solution. So I think those still continue to be my guidelines. So before we start on any agentic eruption, 477 00:43:55.635 --> 00:43:56.595 we should really 478 00:43:56.835 --> 00:43:58.835 map our AI ecosystem 479 00:43:58.995 --> 00:44:13.490 and really see for ourselves like we have this complex AI ecosystem where this will be solved by classical ML, this will be solved by Gen I. And these are the opportunities where I think we can adopt AI agents. 480 00:44:14.050 --> 00:44:15.650 And as 481 00:44:15.650 --> 00:44:16.130 the 482 00:44:16.850 --> 00:44:20.210 capabilities of these models continue to improve, 483 00:44:20.370 --> 00:44:21.970 as we gain 484 00:44:22.130 --> 00:44:28.005 more established patterns and practices around how to build agentic systems and how to 485 00:44:28.245 --> 00:44:29.685 manage them effectively 486 00:44:29.685 --> 00:44:31.365 in production contexts. 487 00:44:31.365 --> 00:44:43.290 What are some of the predictions that you have as far as the role that these agentic systems are going to play in the future of SaaS products, or are SaaS products merely going to fade away in favor of agentic only capabilities? 488 00:44:43.770 --> 00:44:47.130 Yeah. I'm aware that this is a hotly debated 489 00:44:47.930 --> 00:44:50.650 topic over the LinkedIn, you know, and I guess various 490 00:44:51.195 --> 00:44:52.875 LinkedIn influencers 491 00:44:52.875 --> 00:45:24.855 have opined on this and there's a spectrum of I would say there are different schools of thought, you know, so I guess one one school of thought is that thought is that sass is that, you know, and other school of thought is that no sass is here to stay. And really the third school of thought, which is my own thought is that I think in the short term future, and I'm talking about next two or three years, we are going to see SaaS that has AI agent strongly embedded. So both Genai and agent tech AI strongly embedded in the workflows. So I think that's how I see the 492 00:45:24.855 --> 00:45:37.220 industry unfold. And the reason is simple. See, the reason why I think SaaS it's it's very hard to completely take over SaaS is that the moral of the SaaS is that you have to deliver predictability, 493 00:45:37.220 --> 00:45:38.260 reliability, 494 00:45:38.260 --> 00:45:40.580 you know, in a certain repetitive 495 00:45:40.660 --> 00:45:43.700 fashion. And AI being nondeterministic 496 00:45:43.700 --> 00:46:04.450 makes it very hard even now with all the infrastructure and all the support and all the wisdom that we have learned after navigating this, you know, like these products for a few years is not at a place where you can really take over the deterministic form of SaaS. So the way I see it is a very strong hybrid model 497 00:46:04.530 --> 00:46:07.170 and first and foremost we will see 498 00:46:07.570 --> 00:46:10.050 impact on the pricing model itself. 499 00:46:10.050 --> 00:46:24.865 So you know and we kind of talked about that but like one of the disruption I see which is already happening is that SaaS pricing has become more complex and more layered. So if I look at products like Lovable, you know, or similar products, there is a SaaS seat pricing 500 00:46:24.865 --> 00:46:49.205 plus you have credit usage as well. Or I think that will further come down to outcome based pricing because credit usage is not driving a lot of customer satisfaction because you have used your credit but you have to tweak the prompt so many times that you lost all your credit. So I think that's really one disruption I see. Second disruption I see is AI agents playing a significant role in customer onboarding, 501 00:46:49.365 --> 00:46:53.605 which is one of the core flow. So so I see a lot of agentic onboarding, 502 00:46:53.605 --> 00:46:59.070 and I'm really excited about that because traditional SaaS boarding was very template heavy. 503 00:46:59.150 --> 00:47:07.070 Use you install the app. They will ask you a bunch of

questions. You have to toggle. Yes. No. Yes. No. I really feel that with AI agenting 504 00:47:07.070 --> 00:47:14.025 and general AI capabilities, we are talking about a seamless, let's say, voice onboarding, you know, or a text onboarding where you 505 00:47:14.185 --> 00:47:37.140 where AI is intelligent enough to kind of extract your configuration and you and you don't have to go with that, like, twenty ten, twenty, thirty step five on onboarding that we are so used to in in SaaS world. So I feel in nutshell that AI and AI agents in particular are going to empower SaaS by taking away the workflow complexities, 506 00:47:37.220 --> 00:47:39.860 making UI more visually appealing, 507 00:47:40.100 --> 00:47:47.485 less template heavy, less configuration heavy, and with an interesting mix of pricing models that we are already seeing. 508 00:47:48.285 --> 00:47:50.845 Are there any other aspects of 509 00:47:51.005 --> 00:47:54.365 bringing Agenta capabilities into SaaS systems, 510 00:47:54.365 --> 00:48:04.760 the overall economy of SaaS and the impacts of AI on that, or just your own experience of working in this space that we didn't discuss yet that you'd like to cover before we close out the show? 511 00:48:05.240 --> 00:48:25.005 I mean, I think we have talked about most of it. Thanks for the great questions and thoughtful questions that you have asked me but I think one thing I would like to say is that I think there are still some gaps in the industry you know and I guess there are two or three things which will help our industry as a whole that make AI 512 00:48:24.549 --> 00:48:29.990 adoption easier and successful. It's not a good place to be where leading research 513 00:48:30.069 --> 00:48:43.475 studies are publishing that ninety five percent of Gen I pilots fail or by 2027 fifty fifty percent of it of agent AI pilots will fail. I think what we need is there are ways to make agent work on complex 514 00:48:43.635 --> 00:49:00.250 production environment, but it needs a lot of plumbing. It needs a lot of discipline and all the strategies that we have talked about. And I'm hoping that more and more platforms will come which will productize this approach. It doesn't have to live in minds of few leaders or few researchers 515 00:49:00.330 --> 00:49:06.650 who have figured this out. So I'm already seeing a lot of job made easy by observability 516 00:49:06.650 --> 00:49:10.555 platforms where you can track costs, where you can track latency, 517 00:49:10.555 --> 00:49:34.609 but estimation still continues to be a challenge. You know, we talk a little about how do we estimate, you know, because that's the first step. And I think if there are more and more products that can make it easier for leaders to estimate and to ensure that this project is going to to return the ROI that business expects. I think that that will go a long way. So I think that is definitely something. I would also say that interoperability 518 00:49:34.609 --> 00:49:42.095 between agent is still being figured out. Now there are new protocols, you know, like a two a is not new anymore, 519 00:49:42.175 --> 00:49:57.150 but there there is a payment protocol as well that has come. But I think a lot of work needs to be done, and it will happen, you know, because things are so new that that we are still living in a relatively nascent world when it comes to interoperability 520 00:49:57.150 --> 00:50:25.220 that is going to really enable that enterprise level success of AI agent agentic solutions on production. So I think those are definitely two things where I guess one last thing is when it comes to scalability because if you're talking about production and enterprise scale we have to think about what kind of AI infra exist And I guess one thing that is becoming very apparent is that our regular AI infra tools to scale auto scalings, 521 00:50:25.220 --> 00:50:33.335 they are not very friendly towards AI native solutions. I mean, you can of course use a Lambda to scale. You can of course containerize 522 00:50:33.335 --> 00:50:36.375 and put your AI agents in Dockers and 523 00:50:36.535 --> 00:50:37.734 deploy that on 524 00:50:38.214 --> 00:51:14.595 EC2 with auto scaling. AI agents need a lot of memory, you know, and in most situations we see time out. So I think one more improvement that I'm hoping to see in the AI infra industry is that ability to have AI agents scale more more seamlessly. So I think those are the top two or three things that are in my mind that still need to be solved for. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And as the final question, I'd like to get your perspective on what you see as being the biggest gaps in the tooling technology or human training that's available for AI systems today. 525 00:51:15.290 --> 00:51:16.250 Absolutely. 526 00:51:16.330 --> 00:51:19.290 So I think I kind of talked about the gaps and challenges 527 00:51:19.450 --> 00:51:20.490 in the previous 528 00:51:20.730 --> 00:51:21.530 discussion, 529 00:51:21.530 --> 00:51:26.490 but I think human training, yes. I think this also goes back to why I feel that 530 00:51:26.730 --> 00:51:33.875 SaaS cannot be completely overtaken by agents is because there is a real lack of resources. 531 00:51:33.875 --> 00:51:35.795 There is real lack of talent 532 00:51:36.115 --> 00:51:41.715 when it comes to leadership or even engineers who are navigating this transition. 533 00:51:42.035 --> 00:51:42.755 And 534 00:51:43.250 --> 00:51:44.690 it is ironic, 535 00:51:44.930 --> 00:51:52.770 you know, that there are so many AI native startups in past two years, but there is not enough talent to supply that 536 00:51:53.010 --> 00:51:56.525 because there are limited people with research background. 537 00:51:56.525 --> 00:52:03.805 And if you're really looking for industry experts on this, I think we need to do more trainings. And I know that there are 538 00:52:04.205 --> 00:52:05.565 trainings provided 539 00:52:05.565 --> 00:52:07.805 by Deep Learning, Coursera, 540 00:52:07.805 --> 00:52:08.685 Udemy, 541 00:52:08.845 --> 00:52:17.640 Maven. You know, I'm a big part of those communities as well and I definitely keep myself updated, but I'm hoping that training becomes more democratized 542 00:52:17.720 --> 00:52:19.400 because that's what we need. 543 00:52:20.119 --> 00:52:28.295 Because most of the startups I talked to, they are trying to figure out they have a prototype, but they don't have the confidence to take it to production. And that shows me that 544 00:52:28.855 --> 00:52:30.775 there's a real gap on 545 00:52:31.015 --> 00:52:37.895 production grade skills. And I'm hoping that there are more and more courses, more and more leaders there often mentoring 546 00:52:38.214 --> 00:52:41.734 to be leaders and engineers who can really navigate the shift. 547 00:52:42.750 --> 00:52:57.310 Alright. Well, thank you very much for taking the time today to join me and share the work that you've been doing on this challenge of bringing agent to capabilities into SaaS platforms and the economics and technical challenges associated 548 00:52:57.390 --> 00:53:02.735 with that. So I appreciate all the time and energy you're putting into helping other companies 549 00:53:02.974 --> 00:53:05.535 address that challenge and modernize 550 00:53:05.535 --> 00:53:10.575 at the rapid pace that things are changing. So thank you again for that, and I hope you enjoy the rest of your day. 551 00:53:11.380 --> 00:53:14.740 Thank you, Tobias, so much, and that was such a great conversation. 552 00:53:17.220 --> 00:53:25.495 Thank you for listening. Don't forget to check out our other shows. The data engineering podcast covers the latest on modern data management, and podcast.init 553 00:53:25.495 --> 00:53:29.575 covers the Python language, its community, and the innovative ways it is being used. 554 00:53:29.895 --> 00:53:40.465 Visit the site to subscribe to the show, sign up for the mailing list, read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hosts@aiengineeringpodcast.com 555 00:53:40.465 --> 00:53:41.185 with your story.