Beyond the Chatbot: Practical Frameworks for Agentic Capabilities in SaaS

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 12/29/2025 00:36:12
Duration: 3226.941
Channels: 1
1
00:00:05.120 --> 00:00:08.000
Hello, and welcome to the AI Engineering Podcast,
2
00:00:08.000 --> 00:00:12.160
your guide to the fast moving world of building scalable and maintainable AI systems.
3
00:00:19.285 --> 00:00:24.325
When ML teams try to run complex workflows through traditional orchestration tools, they hit walls.
4
00:00:24.940 --> 00:00:35.020
Cash App discovered this with their fraud detection models. They needed flexible compute, isolated environments, and seamless data exchange between workflows, but their existing tools couldn't deliver.
5
00:00:35.500 --> 00:00:37.420
That's why Cash App relies on Prefect.
6
00:00:38.055 --> 00:00:44.455
Now their ML workflows run on whatever infrastructure each model needs across Google Cloud, AWS, and Databricks.
7
00:00:44.855 --> 00:00:46.775
Custom packages stay isolated.
8
00:00:46.855 --> 00:00:49.335
Model outputs flow seamlessly between workflows.
9
00:00:50.170 --> 00:00:54.409
Companies like Whoop and 1Password also trust Prefect for their critical workflows,
10
00:00:54.410 --> 00:00:56.170
but Prefect didn't stop there.
11
00:00:56.489 --> 00:00:58.570
They just launched FastMCP,
12
00:00:58.570 --> 00:01:01.129
production ready infrastructure for AI tools.
13
00:01:01.530 --> 00:01:07.105
You get Prefect's orchestration plus instant OAuth, serverless scaling, and blazing fast Python execution.
14
00:01:07.745 --> 00:01:14.785
Deploy your AI tools once. Connect to Claude, Cursor, or any MCP client. No more building off flows or managing servers.
15
00:01:15.440 --> 00:01:17.760
Prefect orchestrates your ML pipeline.
16
00:01:17.760 --> 00:01:20.560
FastMCP handles your AI tool infrastructure.
17
00:01:20.960 --> 00:01:27.200
See what Prefect and FastMCP can do for your AI workflows at aiengineeringpodcast.com/prefect
18
00:01:27.200 --> 00:01:27.600
today.
19
00:01:28.315 --> 00:01:33.275
Unlock the full potential of your AI workloads with a seamless and composable data infrastructure.
20
00:01:33.674 --> 00:01:40.955
Bruin is an open source framework that streamlines integration from the command line, allowing you to focus on what matters most, building intelligent systems.
21
00:01:41.670 --> 00:01:49.829
Write Python code for your business logic and let Bruin handle the heavy lifting of data movement, lineage tracking, data quality monitoring, and governance enforcement.
22
00:01:50.310 --> 00:01:57.524
With native support for ML and AI workloads, Bruin empowers data teams to deliver faster, more reliable, and scalable AI solutions.
23
00:01:58.085 --> 00:02:04.165
Harness Bruin's connectors for hundreds of platforms, including popular machine learning frameworks like TensorFlow and PyTorch.
24
00:02:04.485 --> 00:02:08.485
Build end to end AI workflows that integrate seamlessly with your existing tech stack.
25
00:02:08.980 --> 00:02:12.260
Join the ranks of forward 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.