1
00:00:07,799 --> 00:00:09,679
Speaker 1: What's going on? Warren? How are you?

2
00:00:09,679 --> 00:00:12,000
Speaker 2: You know? I was so totally unprepared for that question.

3
00:00:12,199 --> 00:00:13,359
I don't know what I thought you were going to

4
00:00:13,400 --> 00:00:15,599
say to start off the episode, but of all the

5
00:00:15,599 --> 00:00:18,839
things you could have picked, it was not that right.

6
00:00:19,359 --> 00:00:22,559
Speaker 1: Just what a jerk asking someone how they are? That's

7
00:00:23,760 --> 00:00:25,399
oh man. I can't remember who it was. We had

8
00:00:25,399 --> 00:00:28,559
a I can't remember who the guest was, but I said,

9
00:00:28,600 --> 00:00:31,920
you know, there's no like stump the chump or surprise questions.

10
00:00:32,280 --> 00:00:34,960
And my first question what tour was how she's doing?

11
00:00:35,399 --> 00:00:37,000
And she's like I thought you said the would be

12
00:00:37,000 --> 00:00:38,039
no trick questions.

13
00:00:39,880 --> 00:00:42,439
Speaker 2: That was Adriana. She was just on here, you know.

14
00:00:45,039 --> 00:00:48,799
Speaker 1: Cool. So today we're gonna be talking about AI ready

15
00:00:48,880 --> 00:00:52,000
data and AI governance, and to help us through that conversation,

16
00:00:52,640 --> 00:00:57,600
we have Ina tokodev Sela from a Lumex. You know,

17
00:00:57,719 --> 00:00:58,520
welcome to the show.

18
00:00:59,320 --> 00:01:01,119
Speaker 3: Thank you so much. Will happy to be here.

19
00:01:02,119 --> 00:01:04,400
Speaker 1: I'm excited to have you here. So give us a

20
00:01:04,480 --> 00:01:07,640
little bit about your background and what led you to

21
00:01:09,200 --> 00:01:12,319
creating because you're the CEO and founder of alumin X

22
00:01:12,599 --> 00:01:14,920
or Alumax, So give us a little bit about how

23
00:01:14,959 --> 00:01:15,680
you got there.

24
00:01:17,159 --> 00:01:20,640
Speaker 3: It was a long passway, but also happy about the

25
00:01:20,680 --> 00:01:24,280
way you know that my career took me. I started

26
00:01:24,359 --> 00:01:30,760
an enterprise, SAP, a huge German software company, and I

27
00:01:30,799 --> 00:01:33,519
think this is the you know, the most hidden choose

28
00:01:33,519 --> 00:01:36,640
about enterprise. You can actually have quite an adventure and

29
00:01:36,680 --> 00:01:39,239
then you can build stuff, big stuff right and switch

30
00:01:39,280 --> 00:01:42,560
careers within. So I spent twelve years at SAP, starting

31
00:01:42,640 --> 00:01:47,200
as an architect and then basing evolving into a customer

32
00:01:47,239 --> 00:01:50,040
facing role as a partner manager and then a head

33
00:01:50,040 --> 00:01:52,680
of pen Alpha video analytics units. So quite in the

34
00:01:52,760 --> 00:01:56,799
journey and quite a privilege to work with the world

35
00:01:56,840 --> 00:02:01,640
biggest company. Think about the worldmar builder buying and so

36
00:02:01,640 --> 00:02:05,480
on and so forth, so really washing companies and boarding to

37
00:02:05,560 --> 00:02:09,159
the cloud journey, and then machine learning and then you know,

38
00:02:09,680 --> 00:02:14,199
neural and augentic as well. And then I continued my

39
00:02:14,240 --> 00:02:17,759
career to license as business intelligence vendor and then understood

40
00:02:18,159 --> 00:02:23,000
what an underserved segment of business users actually are. You know,

41
00:02:23,039 --> 00:02:25,400
after building all these analytics for all those years, you

42
00:02:25,599 --> 00:02:27,919
know you're speaking to to the actual users and some

43
00:02:28,000 --> 00:02:30,479
of them are CEOs of the companies, and they still

44
00:02:30,479 --> 00:02:34,199
cannot get the hands on the actual self service analytics.

45
00:02:34,199 --> 00:02:38,159
So this has really moved me to build a company

46
00:02:38,680 --> 00:02:43,719
which creates a space where data could be recognized and

47
00:02:45,280 --> 00:02:48,840
meaningful semantically and business wise to the business users to

48
00:02:49,000 --> 00:02:52,240
enable them to self service analytics and data access. Right.

49
00:02:52,280 --> 00:02:55,639
Speaker 1: And so whenever you're thinking about self service data, one

50
00:02:55,680 --> 00:02:59,719
of the challenges I've had in the past is self

51
00:02:59,759 --> 00:03:04,520
service sometimes means guiding yourself to the wrong answer. And like,

52
00:03:04,599 --> 00:03:07,759
one specific example I have is I was working for

53
00:03:07,800 --> 00:03:11,000
a company. It was like, how many how many users

54
00:03:11,039 --> 00:03:14,560
do we have using our app each month? It's like, oh,

55
00:03:14,599 --> 00:03:18,599
that seems like a pretty straightforward question, right, But turns

56
00:03:18,599 --> 00:03:21,879
out it wasn't because then, oh, when I meant monthly

57
00:03:21,919 --> 00:03:25,319
active users, I actually meant people who weren't on the

58
00:03:25,400 --> 00:03:28,080
trial and had converted to paid, but you know, they

59
00:03:28,080 --> 00:03:30,560
were like using it at least three times a week,

60
00:03:30,680 --> 00:03:33,280
not just once a month. And so, like a really

61
00:03:33,360 --> 00:03:37,120
relatively simple question turned out to be coming with a

62
00:03:37,120 --> 00:03:38,800
lot of constraints. So how do you deal with that

63
00:03:38,840 --> 00:03:39,840
in a self service world?

64
00:03:40,000 --> 00:03:44,439
Speaker 3: It's perfect question for status data has to be you know,

65
00:03:44,599 --> 00:03:47,560
the state that you can actually create analytics on scale

66
00:03:47,560 --> 00:03:50,919
for many users. So when let's speak about highly curated

67
00:03:51,039 --> 00:03:54,879
dishboards in your intelligence tool. It's no brainer because you

68
00:03:54,919 --> 00:03:57,879
can sell specific data sets which you go to specific

69
00:03:57,919 --> 00:04:01,240
report and make sure that the hecks actually have decent quality.

70
00:04:01,919 --> 00:04:05,400
For companies to have self service on scales and need

71
00:04:05,479 --> 00:04:10,280
to make sure that any potential question could be answered

72
00:04:10,319 --> 00:04:14,039
with a high quality data, you first need to get

73
00:04:14,080 --> 00:04:17,439
your data in order to be able to provide this

74
00:04:17,560 --> 00:04:19,720
kind of service. And the second one is as you're

75
00:04:19,759 --> 00:04:23,480
right to mention single source of truth, right, So definition

76
00:04:23,600 --> 00:04:26,160
what active user is, so how many users do we

77
00:04:26,319 --> 00:04:30,959
have could be defined in dozens of different ways in organization.

78
00:04:31,120 --> 00:04:33,680
If you speak to someone from product departments, they will

79
00:04:33,680 --> 00:04:36,160
go for the active users to actually, you know, use

80
00:04:36,160 --> 00:04:38,959
a product. And maybe if you speak to your financial departments,

81
00:04:39,000 --> 00:04:41,639
it will go to someone who actually signed the contract

82
00:04:41,639 --> 00:04:45,560
with you. So the different ways of calculators things, and

83
00:04:45,680 --> 00:04:49,079
especially for self service, again you're asking about things which

84
00:04:49,160 --> 00:04:52,639
might have different meaning. You have to have governance actually

85
00:04:53,120 --> 00:04:58,759
understanding semantic business definitions of business matchakes and business terms.

86
00:04:59,079 --> 00:05:01,639
Speaker 2: I feel like that's a bit of a moving target

87
00:05:01,720 --> 00:05:03,519
from what I've seen in my experience. Like I was

88
00:05:03,519 --> 00:05:06,199
remember in an organization where I'm like, we figured it out,

89
00:05:06,279 --> 00:05:08,439
you know, we we managed to get a single source

90
00:05:08,480 --> 00:05:10,959
of truth for even what a user is. Like, you know,

91
00:05:11,000 --> 00:05:13,720
there's a lot of identity aspects for a user, but

92
00:05:13,759 --> 00:05:15,959
then there's also a lot of business aspects to it,

93
00:05:16,279 --> 00:05:19,959
and like how great of a customer are they repeat customer,

94
00:05:20,399 --> 00:05:23,120
how much they've spent and then you know individual events

95
00:05:23,199 --> 00:05:25,959
related to it, and trying to get a single identity

96
00:05:26,000 --> 00:05:28,079
for that was always potentially a problem. And then you

97
00:05:28,079 --> 00:05:30,639
you know, every team in your organization has their own

98
00:05:30,720 --> 00:05:32,720
idea of what a user is and probably has their

99
00:05:33,120 --> 00:05:36,399
each organization has their own user management service with his

100
00:05:36,480 --> 00:05:40,279
own special data. And I just I wonder how possible,

101
00:05:40,279 --> 00:05:41,879
like if it like if there is a company out

102
00:05:41,920 --> 00:05:45,199
there that actually has good, good data, you know, high

103
00:05:45,240 --> 00:05:49,800
marks on health Scorecard for their data management, Like what

104
00:05:49,839 --> 00:05:51,800
does that look like? You know, is that actually do

105
00:05:51,800 --> 00:05:53,160
you actually see that in practice?

106
00:05:53,600 --> 00:05:57,319
Speaker 3: So I would say again, because we're operating in the space,

107
00:05:57,360 --> 00:06:01,639
so naterally it's possible. Otherwise it wouldn't have any customers.

108
00:06:01,720 --> 00:06:01,879
Speaker 1: Right.

109
00:06:03,360 --> 00:06:08,000
Speaker 3: On the other hand, this is truly changed for many organizations.

110
00:06:08,399 --> 00:06:13,319
And I would also say that agentic practice, so generally

111
00:06:13,319 --> 00:06:16,959
to BI it's another silo, right, So because usually data

112
00:06:17,000 --> 00:06:19,680
management departments that have their own single source of truths

113
00:06:19,759 --> 00:06:24,519
may be implemented in the data pipelines, ls so, calculated

114
00:06:24,560 --> 00:06:26,439
fields and so on and so force, and then analytics

115
00:06:26,439 --> 00:06:29,199
department have their own single source of truth which is

116
00:06:29,240 --> 00:06:32,480
probably in the bi to feature store, metric store, what

117
00:06:32,600 --> 00:06:32,839
have you.

118
00:06:33,279 --> 00:06:36,000
Speaker 2: That's an interesting point because we already see that with

119
00:06:36,120 --> 00:06:38,639
the public agents that are out there, they're trained up

120
00:06:38,680 --> 00:06:41,040
to you know, if we're lucky, even six months ago,

121
00:06:41,600 --> 00:06:44,360
and especially things in a business context are rolling very

122
00:06:44,439 --> 00:06:48,319
quickly what the principles of the organization are, or you know,

123
00:06:48,399 --> 00:06:51,360
what features need to be implemented for customers. Those things

124
00:06:51,360 --> 00:06:55,519
are iterating very quickly, and so you know, I'm know,

125
00:06:55,600 --> 00:06:57,800
I'm this is a new problem that I actually hadn't

126
00:06:57,800 --> 00:07:01,560
considered before, and it means models are fundamentally always out

127
00:07:01,600 --> 00:07:04,800
of date. Do the just like your documentation and our

128
00:07:04,839 --> 00:07:07,560
source code, right, it's all legacy as soon as it's made.

129
00:07:08,439 --> 00:07:12,839
Does does RAG resource augmented generation help here to reduce

130
00:07:13,000 --> 00:07:15,639
the changing nature of those things because you can point

131
00:07:15,639 --> 00:07:19,319
to potentially the production data store or is there something

132
00:07:19,319 --> 00:07:24,360
else going on where that realistically you're copying that data

133
00:07:24,399 --> 00:07:27,959
is RAGGED being used against stale data sources anyway, like

134
00:07:27,959 --> 00:07:29,480
you're not using the production database.

135
00:07:30,240 --> 00:07:33,879
Speaker 3: It's a fair point if ROG is a separate silo

136
00:07:34,120 --> 00:07:37,240
in the system and you just you know, keep fitting

137
00:07:37,279 --> 00:07:41,079
it with examples which all of the outdated when they created.

138
00:07:41,399 --> 00:07:45,000
So no, RUG is not actually solving the problem. If

139
00:07:45,040 --> 00:07:49,000
you have started site you know as a sidecarrent data science,

140
00:07:49,040 --> 00:07:51,319
it will never leave up to that. But if you

141
00:07:51,319 --> 00:07:56,360
combine metadata management your business ontology and use it for

142
00:07:56,399 --> 00:07:58,959
your gentic properties, is exactly what can be up to

143
00:07:59,040 --> 00:08:00,720
date that point of time.

144
00:08:01,759 --> 00:08:04,040
Speaker 1: So the level of overhead to pull that off seems

145
00:08:04,079 --> 00:08:09,000
pretty significant. Everyone feels these pains, But what at what

146
00:08:09,040 --> 00:08:12,279
point do you hit the scale or the quantity of

147
00:08:12,399 --> 00:08:16,040
data where it actually seems like a worthwhile exercise to

148
00:08:16,120 --> 00:08:16,639
implement this.

149
00:08:17,920 --> 00:08:21,079
Speaker 3: I guess it's a healthy practice for any size of

150
00:08:21,240 --> 00:08:28,040
organization unless you know, we just want to rely on

151
00:08:28,040 --> 00:08:32,120
on the one developer who maintains your snowflake what have you,

152
00:08:33,039 --> 00:08:35,840
which is which is fine, okay, But but I think

153
00:08:35,919 --> 00:08:39,879
like Organizational Knowledge Way and its documentation was always a

154
00:08:39,960 --> 00:08:43,919
challenge for any size of organizations. To me, it's it's

155
00:08:43,919 --> 00:08:46,519
a healthy habit to actually have it from starters, to

156
00:08:46,679 --> 00:08:52,279
have the you know, knowledge graphts about you different data

157
00:08:52,279 --> 00:08:55,279
structures and the different data sources created from day one

158
00:08:55,320 --> 00:08:58,519
when you actually have data stores. But alway said organizations

159
00:08:58,519 --> 00:09:02,320
which just have one database, so one warehouse, a small one,

160
00:09:02,559 --> 00:09:05,639
I would not necessarily invest in that, despite the fact

161
00:09:05,639 --> 00:09:08,559
that I think it's not a good practice, because right

162
00:09:08,600 --> 00:09:12,519
now we will see flourish of agentic workflows where different

163
00:09:12,600 --> 00:09:15,240
agents going to communicate with each other and they have

164
00:09:15,320 --> 00:09:18,480
to have shared context and reasoning. And the shared context

165
00:09:18,519 --> 00:09:21,840
and reasoning is exactly this knowledge which you should document

166
00:09:21,919 --> 00:09:25,679
about your organization, right so we become more more and

167
00:09:25,759 --> 00:09:28,759
more automated, and we should and this is also a

168
00:09:28,759 --> 00:09:33,559
differentiation business differentiation between companies like if you actually advanced

169
00:09:33,679 --> 00:09:37,919
in keeping your knowledge and building agents around that or

170
00:09:38,000 --> 00:09:38,279
you're not.

171
00:09:38,840 --> 00:09:42,240
Speaker 1: Do are there out of the box agents to help

172
00:09:42,279 --> 00:09:47,240
with this or is it completely built custom for everyone.

173
00:09:47,679 --> 00:09:50,279
Speaker 3: I don't think it's feasible to really, you know, make

174
00:09:50,320 --> 00:09:54,919
it a max employment manual for any size of organization,

175
00:09:55,000 --> 00:09:57,840
because you know, data is exploding even for smaller companies.

176
00:09:58,279 --> 00:10:04,039
We got this approach of actual predefining ontologies for different

177
00:10:04,080 --> 00:10:07,320
particles and different lines of business and then automated way

178
00:10:07,399 --> 00:10:11,759
to simple metadata from different data sources. Don't stand with

179
00:10:12,360 --> 00:10:16,600
what the specific logic changes for different systems and basically

180
00:10:16,639 --> 00:10:20,759
automatically creates business autology. But I must say to your

181
00:10:20,799 --> 00:10:24,480
previous points, what we discovered as automated on boarding, which

182
00:10:24,519 --> 00:10:26,639
is like a few hours a few days, is that

183
00:10:27,919 --> 00:10:30,759
there are many proflicts of definitions. You might not aware

184
00:10:30,799 --> 00:10:33,960
about that now, but you have ten different views in

185
00:10:34,000 --> 00:10:37,200
your power bi tool where you have the same metric

186
00:10:37,279 --> 00:10:39,840
defined in different ways based on different data sources, and

187
00:10:39,879 --> 00:10:40,840
this is what we discover.

188
00:10:41,159 --> 00:10:43,759
Speaker 1: Yeah, that makes sense. I can see it going horribly

189
00:10:43,799 --> 00:10:47,440
wrong asking your technical people about the quality of the data.

190
00:10:50,080 --> 00:10:53,639
Speaker 3: We're all technical people, but I guess if you want

191
00:10:53,720 --> 00:10:58,080
to have a business logic, let's say, all those agents

192
00:10:58,080 --> 00:11:01,440
which automate customer support and so forth to be automated

193
00:11:01,480 --> 00:11:06,480
top your data, there should be aligned to sign organizational knowledge,

194
00:11:06,519 --> 00:11:09,080
which is not necessarily on technical size. It's an operational

195
00:11:09,120 --> 00:11:12,559
size side, so it's coming from those departments, not from

196
00:11:12,879 --> 00:11:14,200
us technical people.

197
00:11:14,399 --> 00:11:16,879
Speaker 2: Maybe to make this a little bit more concrete, do

198
00:11:16,919 --> 00:11:20,720
you have like some canonical examples of what businesses are

199
00:11:20,759 --> 00:11:24,440
trying to often answer with the storage of their data.

200
00:11:24,559 --> 00:11:28,000
Speaker 3: So I would say again, there is no business case

201
00:11:28,320 --> 00:11:32,399
a solid for automation as agentic as, also data compilots

202
00:11:32,399 --> 00:11:35,000
and ergentic and automation workflows, because if you do not

203
00:11:36,000 --> 00:11:39,960
inspired to automation, why would you sort out your data

204
00:11:40,240 --> 00:11:42,879
or why would you sort out your governance? Right if

205
00:11:42,919 --> 00:11:45,279
you don't have automation, like this is a killer use case.

206
00:11:45,679 --> 00:11:48,440
But when you have the CERO killer use case, usually

207
00:11:48,440 --> 00:11:51,919
companies tend to start with more like a knowledge center

208
00:11:51,960 --> 00:11:58,120
and discoveries so basically search right all the customer support

209
00:11:58,200 --> 00:12:02,240
functions on one site. On the site. We also have

210
00:12:02,399 --> 00:12:07,320
like companies and pharma for example Holiday building the digital

211
00:12:07,360 --> 00:12:12,240
health platforms with agents. We have customers and financial services industry,

212
00:12:12,440 --> 00:12:16,200
which which implemented self service quotation for serve party brokers.

213
00:12:16,720 --> 00:12:19,720
So basically is the use case would be always shortening

214
00:12:19,799 --> 00:12:24,279
the time and increasing conversion rates. So there are always

215
00:12:24,480 --> 00:12:28,200
business or metrics for implementing those use cases in the

216
00:12:28,240 --> 00:12:32,440
first place, but internal use cases first and then sell

217
00:12:32,559 --> 00:12:33,399
customer facing.

218
00:12:34,039 --> 00:12:36,080
Speaker 2: And just thinking back to all the times that I

219
00:12:36,120 --> 00:12:39,039
was working at companies and they were saying how valuable

220
00:12:39,080 --> 00:12:43,720
their data would be and collected everything just waste and

221
00:12:43,799 --> 00:12:48,759
storage and building up internal tables of just garbage from

222
00:12:48,840 --> 00:12:52,159
years and years back, and realistically, I'm still waiting for

223
00:12:52,200 --> 00:12:54,840
the point where we could be utilizing tools to even

224
00:12:54,879 --> 00:12:59,399
evaluate that effectively, because is there something to this, Is

225
00:12:59,440 --> 00:13:02,000
there an area where it's like, oh no, actually, this

226
00:13:02,720 --> 00:13:06,240
probably highly useless data does turn around and solve a

227
00:13:06,240 --> 00:13:10,399
critical need for the company today with the advent of

228
00:13:11,399 --> 00:13:13,759
agents that can potentially utilize it in a much more

229
00:13:13,799 --> 00:13:17,840
effective way than humans can, or shortly down the road five.

230
00:13:17,720 --> 00:13:22,360
Speaker 3: Ten years, Yeah, yeah, I believe so, because most of

231
00:13:22,480 --> 00:13:26,240
organizational data is unutilized, as I mentioned, so we see

232
00:13:26,279 --> 00:13:31,120
that even most advanced companies use mainly twenty percent of

233
00:13:31,159 --> 00:13:35,240
that data on you know, relatively frequent cadence and the

234
00:13:35,360 --> 00:13:41,600
res is unutilized basically, and for that data, AIO readiness

235
00:13:41,919 --> 00:13:45,840
also means that you actually understand few of the health

236
00:13:45,840 --> 00:13:50,159
core components. So startus if it's duplicated, if it's used,

237
00:13:50,240 --> 00:13:54,960
and if it's used by which applications, and if it's sensitive. Right,

238
00:13:55,080 --> 00:13:58,559
so then cent also the risk factors as well. And

239
00:13:58,600 --> 00:14:01,559
then a last but not least, I think it's even

240
00:14:01,600 --> 00:14:04,519
the most important one is what is the semantic meaning

241
00:14:04,559 --> 00:14:09,279
of that? What's actually hidden in this data? Right? And

242
00:14:09,320 --> 00:14:13,600
then that's why knowledge graphs become handy because knowledge graphs

243
00:14:13,600 --> 00:14:16,360
they create or suggested connections. Say, oh, did you know

244
00:14:16,519 --> 00:14:20,960
that additional feature of your conversion score might come from

245
00:14:21,000 --> 00:14:24,759
this customer demographic exparamitter like such and such, Right, so

246
00:14:24,799 --> 00:14:29,519
it's kind of giving you related a data which you

247
00:14:29,600 --> 00:14:33,120
might not encounter so far, like by your experience. But

248
00:14:33,279 --> 00:14:36,039
it's in there. The thing is in there right now

249
00:14:36,159 --> 00:14:39,679
is not covered. So companies usually do not index to

250
00:14:39,759 --> 00:14:43,200
catalog data, which is not used actively for applications. Again

251
00:14:43,279 --> 00:14:47,639
because cataloging was used for compliance and insurance sor to say,

252
00:14:48,159 --> 00:14:51,519
for governance, and now cataloging is small, or we should

253
00:14:51,639 --> 00:14:56,600
use cataloging indexing to actually for discovery. Discovery is semantic mapping,

254
00:14:56,840 --> 00:15:02,000
risk mapping and risk management. And of course also by definition,

255
00:15:02,360 --> 00:15:07,240
agents are better than humans to understand those relations on scale.

256
00:15:07,480 --> 00:15:11,759
I'm also like on scale, say, and then they see

257
00:15:11,960 --> 00:15:14,759
humans us as moderators.

258
00:15:14,960 --> 00:15:17,039
Speaker 2: So you mentioned like twenty to thirty percent of the

259
00:15:17,120 --> 00:15:21,320
data is being utilized, So seventy percent is you know,

260
00:15:21,480 --> 00:15:24,519
not utilized. Is that because of the lack of value

261
00:15:24,519 --> 00:15:28,559
in it, lack of it being categorized effectively? Is there

262
00:15:28,559 --> 00:15:31,919
another bucket that I'm missing here? Something there could be

263
00:15:31,960 --> 00:15:34,159
something interesting in it, but no one's taking the time to

264
00:15:34,240 --> 00:15:37,559
actually understand it. Because I get the sense that the

265
00:15:37,600 --> 00:15:39,759
agents aren't going to be able to just see this

266
00:15:39,879 --> 00:15:43,519
uncategorized data and magically pop up an answer of how

267
00:15:43,519 --> 00:15:46,120
it could be valuable there still requires a human to

268
00:15:46,320 --> 00:15:49,960
evaluate it and know that there is something valuable in there.

269
00:15:50,639 --> 00:15:52,600
How it could be utilized still has to be done

270
00:15:52,639 --> 00:15:53,120
by a human.

271
00:15:53,519 --> 00:15:57,399
Speaker 3: Yes, it's a good point. So in the databases which

272
00:15:57,519 --> 00:15:59,759
only have some analytics on them and so on, so

273
00:15:59,799 --> 00:16:02,720
first the role of the agent could be suggesting additional

274
00:16:02,759 --> 00:16:08,559
features to look at to take into consideration in databases

275
00:16:08,559 --> 00:16:10,919
where you do not have analytics at all. So, for example,

276
00:16:10,919 --> 00:16:15,159
we have this discussion with the company which never introduced

277
00:16:15,200 --> 00:16:18,399
and this is a huge company which never introduced analytics

278
00:16:18,440 --> 00:16:21,840
for people's departments. There are not dashboards for people's departments

279
00:16:21,960 --> 00:16:24,240
right now. They want to skip the stage of bi

280
00:16:24,399 --> 00:16:27,679
tools and go to self service data copilots to actually

281
00:16:27,720 --> 00:16:30,320
create this analytics to kind of scape the stage. Right,

282
00:16:30,720 --> 00:16:33,759
So in this case the data is supervalable. Of course,

283
00:16:33,759 --> 00:16:36,480
it does have to, you know, to go through automated

284
00:16:36,559 --> 00:16:39,840
labeling and reconciliation and semantic definitions and all of that,

285
00:16:39,879 --> 00:16:42,679
and you know, centrally, we have tools for that now,

286
00:16:43,600 --> 00:16:47,000
but here the case is you had unutilized data not

287
00:16:47,080 --> 00:16:48,000
for the right reasons.

288
00:16:48,440 --> 00:16:52,200
Speaker 1: So do you find that after going through this process

289
00:16:52,240 --> 00:16:57,080
that companies actually have less data storage concerns? Because, like

290
00:16:57,360 --> 00:16:59,120
you know, we talk about a single source of truth

291
00:16:59,159 --> 00:17:02,720
and a lot of times I seen where everyone claims

292
00:17:02,840 --> 00:17:05,440
theirs is the single source of truth. So they want

293
00:17:05,480 --> 00:17:08,880
their own copy, their own database servers, their own storage

294
00:17:08,880 --> 00:17:11,640
system because they don't want anyone else polluting it. So

295
00:17:11,799 --> 00:17:14,440
after you go through this exercise, do you find that

296
00:17:14,480 --> 00:17:16,440
a lot of those can be decommissioned and you actually

297
00:17:16,519 --> 00:17:19,240
end up with less data storage overall?

298
00:17:20,880 --> 00:17:23,000
Speaker 3: Just a question because single source of just has to

299
00:17:23,039 --> 00:17:26,160
be virtual, so it's kind of a virtual layer which

300
00:17:26,160 --> 00:17:30,160
connects to your operational data source, analytic data sources, and

301
00:17:30,200 --> 00:17:33,680
even applications because there's lots of business logic and application side,

302
00:17:34,240 --> 00:17:38,039
so it's always virtualized. And then the question is do

303
00:17:38,079 --> 00:17:43,960
you even need aggregating layers like warehouses? You know, we

304
00:17:44,000 --> 00:17:48,240
see this question popping up more and more and we say, okay,

305
00:17:48,319 --> 00:17:51,039
so there are probably going to be stages, right, so

306
00:17:51,680 --> 00:17:55,000
some companies are going to reduce Companies like in IoT

307
00:17:55,319 --> 00:17:58,519
your manufacturing space. They might want to reduce the size

308
00:17:58,559 --> 00:18:02,000
of the data to to some warehouse to basically have

309
00:18:02,200 --> 00:18:06,839
more focused use cases, right, more focused and sculpt use

310
00:18:06,920 --> 00:18:11,279
cases cheaper for processing. Right. And some companies who might

311
00:18:11,400 --> 00:18:15,119
have less data will just you know, goal result any

312
00:18:15,160 --> 00:18:18,880
aggregation toll. And what I'm saying less data is because

313
00:18:18,920 --> 00:18:20,759
the storage is not expensive anymore.

314
00:18:21,200 --> 00:18:23,599
Speaker 2: I mean, I feel like there's a whole systems thinking

315
00:18:23,720 --> 00:18:25,920
problem here, which is just because it would be better

316
00:18:25,960 --> 00:18:28,319
to have a single sources. Truth, it doesn't automatically make

317
00:18:28,359 --> 00:18:31,160
the organizations you know, migrate to that. I do see

318
00:18:31,200 --> 00:18:35,279
the the XKCD article on the number of number of sources.

319
00:18:35,400 --> 00:18:37,039
I mean it says standards, right, you know, we have

320
00:18:37,119 --> 00:18:41,160
three three databases with user identity, user tracking metrics data

321
00:18:41,240 --> 00:18:43,519
in it, and oh we should have one you know,

322
00:18:43,680 --> 00:18:48,200
unified answer, one perfect database that is sanitized, that is

323
00:18:48,240 --> 00:18:51,640
categorized correctly. And the result is now we have four

324
00:18:51,799 --> 00:18:54,359
user databases, you know, with all the data in it,

325
00:18:55,079 --> 00:18:57,960
and and you know, someone still utilizing those old ones

326
00:18:58,119 --> 00:19:01,359
and to your point of storage still getting cheaper for us.

327
00:19:01,839 --> 00:19:04,759
There is no justifier, and it takes effort, you know,

328
00:19:04,880 --> 00:19:08,839
human time and resources to actually decommission a database. I

329
00:19:08,920 --> 00:19:12,000
can see that just not being encouraged to even happen.

330
00:19:12,200 --> 00:19:14,240
What if there's some something we missed in there that's

331
00:19:14,240 --> 00:19:17,559
still valuable that we could be utilizing to increase our

332
00:19:18,000 --> 00:19:20,480
business even by you know, a couple of percentage points.

333
00:19:21,680 --> 00:19:25,279
Speaker 3: So I guess it's a virtualized ontology which lies knowledge

334
00:19:25,319 --> 00:19:27,519
craft which you can connect to many data sources and

335
00:19:27,680 --> 00:19:30,680
indicate which data source and which table call you need

336
00:19:30,759 --> 00:19:34,400
to use for specific vision. To me, is something that

337
00:19:34,680 --> 00:19:39,079
can with the time help you to decommission specific data source.

338
00:19:39,880 --> 00:19:43,079
All in migrating you know, systems to new storages. And

339
00:19:43,680 --> 00:19:48,119
I heard this talk at Gardner last year when someone

340
00:19:48,279 --> 00:19:52,799
was comparing hadup to data lakes or data lake houses

341
00:19:52,920 --> 00:19:54,519
and all of that. Because if you do not have,

342
00:19:54,720 --> 00:19:58,319
like the semantic layer, the business understanding of what's in it,

343
00:19:59,200 --> 00:20:02,920
this big store of data doesn't really solve your problem.

344
00:20:03,000 --> 00:20:06,720
Speaker 1: So what's the biggest driver for this is it does

345
00:20:06,799 --> 00:20:10,119
it typically come to you from the business side or

346
00:20:10,279 --> 00:20:14,519
from the technical side customer?

347
00:20:15,720 --> 00:20:18,200
Speaker 3: Yeah, I think it's good news for the whole industry

348
00:20:19,160 --> 00:20:25,079
that everything about Argentic is coming from the business side.

349
00:20:27,000 --> 00:20:30,559
And yeah, it's a good position to be in because

350
00:20:30,640 --> 00:20:32,960
this is where money is, right, it's where decision power

351
00:20:33,119 --> 00:20:34,720
is and so on the first and you don't need

352
00:20:34,799 --> 00:20:38,079
to explain the technology anymore, right, you don't need to

353
00:20:38,160 --> 00:20:43,039
explain yourself anymore, because you know, I think it's the

354
00:20:43,119 --> 00:20:46,039
same that what happened with the Internet, and you know

355
00:20:46,319 --> 00:20:48,960
early two thousands with the dot com boom, that the

356
00:20:49,359 --> 00:20:52,680
business side were like super inspired to create e commerce

357
00:20:52,839 --> 00:20:56,519
use cases and what have you. And that's what's happening

358
00:20:56,559 --> 00:20:59,599
with Argentic. It's business side. It's already you know, also

359
00:20:59,680 --> 00:21:03,160
inspire art with all the capabilities of this new technologies

360
00:21:03,200 --> 00:21:05,759
that are actually inventing the use cases and the building

361
00:21:06,079 --> 00:21:10,640
you know, business drivers and calculations behind that. This was

362
00:21:10,799 --> 00:21:14,839
usually the prerogative of technical teams, right to come up

363
00:21:14,880 --> 00:21:18,440
with a new technology and then find a compelling business case,

364
00:21:18,519 --> 00:21:21,400
and now it's the other way wrong. On the other hand,

365
00:21:22,480 --> 00:21:26,839
business so technical teams are struggling on the site to

366
00:21:26,960 --> 00:21:29,640
provide this type of service that the business as far

367
00:21:29,680 --> 00:21:33,039
as to because of law data quality, because of low

368
00:21:33,160 --> 00:21:38,640
data readiness, and because of this multiple definitions where if

369
00:21:38,680 --> 00:21:42,319
you connect agents to them, you know it's it's a business.

370
00:21:42,000 --> 00:21:45,079
Speaker 2: Sir, I mean, it really seems like there's the innovation

371
00:21:45,279 --> 00:21:49,680
Here is a fundamental paradigm shift from having business intelligence

372
00:21:49,839 --> 00:21:55,759
and even data centered engineers working within organizations to completely

373
00:21:55,839 --> 00:22:00,119
outsource the handling of any sort of data from your

374
00:22:00,119 --> 00:22:03,000
production systems, because at the end of the day, they

375
00:22:03,039 --> 00:22:05,359
were always sort of a bottleneck for delivering things that

376
00:22:05,440 --> 00:22:07,160
used to be someone's like I need a dashboard for this,

377
00:22:07,319 --> 00:22:08,920
or being able to answer the question of how we

378
00:22:09,000 --> 00:22:11,759
talk about monthly active users, Well, where is that data?

379
00:22:11,839 --> 00:22:14,000
What does it look like, and then figure out utilizing

380
00:22:14,039 --> 00:22:16,359
the tools to actually build the dashboards. Having the data

381
00:22:16,400 --> 00:22:18,400
in a single place all that had to be solved,

382
00:22:18,480 --> 00:22:21,759
whereas now those teams don't necessarily need to be working

383
00:22:21,839 --> 00:22:25,119
on that anymore. The data starts in the original application.

384
00:22:25,200 --> 00:22:28,039
You don't want a middle layer. You want it given

385
00:22:28,119 --> 00:22:31,000
to companies that understand how to sanitize it, what's relevant,

386
00:22:31,359 --> 00:22:34,000
where the insights are, and providing an interface for those

387
00:22:34,079 --> 00:22:37,039
asking the questions to directly interact with the data in

388
00:22:37,160 --> 00:22:40,079
an understandable way, rather than looking at dashboards that are

389
00:22:40,119 --> 00:22:42,960
out of date or configure some ultimately utilizing tools that

390
00:22:43,480 --> 00:22:46,240
just don't really work that well because there's there's too

391
00:22:46,279 --> 00:22:49,279
many degrees of freedom, too many variables, too many columns

392
00:22:49,359 --> 00:22:51,920
or pieces of data that all needs to be displayed

393
00:22:52,079 --> 00:22:53,440
depending on what you're actually looking for.

394
00:22:53,839 --> 00:22:56,559
Speaker 3: Yeah, it's a good point because a majority of foul

395
00:22:56,599 --> 00:23:00,400
decisions are ed HOLC decisions on aed hoc questions. I

396
00:23:00,480 --> 00:23:04,039
do believe that we'll still have space for KPIs and dashboards,

397
00:23:04,200 --> 00:23:06,480
Like I am starting my day with you know, Google

398
00:23:06,519 --> 00:23:11,559
Analytics and Salesforce and all of that, but I also

399
00:23:11,680 --> 00:23:13,960
have like a bunch of questions which are not in

400
00:23:14,079 --> 00:23:17,799
those reports, and it is actually changed with the data

401
00:23:18,000 --> 00:23:19,920
change every day, right, And I would like to have

402
00:23:20,039 --> 00:23:23,960
a tool which can help me with that. And for that,

403
00:23:24,920 --> 00:23:28,200
I think that we could be as practitioners, like as

404
00:23:28,240 --> 00:23:31,880
analytics practitioners, we could be smart about it because if

405
00:23:31,920 --> 00:23:36,519
you actually get monitoring and agentic metadata analytics, you actually

406
00:23:36,759 --> 00:23:39,319
understand what are the interactions of users with the systems,

407
00:23:39,640 --> 00:23:42,200
you will come up with dashboards which are actually useful,

408
00:23:42,920 --> 00:23:46,680
right because the biggest criticism, well from the end user

409
00:23:46,759 --> 00:23:48,440
that you build like a bunch of dashboards that we

410
00:23:48,640 --> 00:23:52,880
didn't ask for. And now when they have this luxury

411
00:23:52,960 --> 00:23:57,480
of asking that questions freely, you can monitor what's asking about, right,

412
00:23:57,799 --> 00:24:01,000
ask asking for and actually create a takes is actually

413
00:24:01,119 --> 00:24:03,720
neat and you know, convert into the dashboards.

414
00:24:04,200 --> 00:24:08,079
Speaker 2: Now, I'm definitely more on the anti dashboard proponent or

415
00:24:08,160 --> 00:24:11,599
I guess dashboard antagonist, Like I find there's something very

416
00:24:12,759 --> 00:24:15,000
like you're utilizing as a crutch and maybe a little

417
00:24:15,000 --> 00:24:18,599
bit lazy as far as not articulating what the challenges

418
00:24:18,720 --> 00:24:20,440
or the question you want answered. It's like, oh, I'll

419
00:24:20,480 --> 00:24:22,599
just look at a dashboard of this information, maybe the

420
00:24:22,640 --> 00:24:24,440
answer will pop out where what you really want to

421
00:24:24,480 --> 00:24:26,119
do is say why am I looking at the dashboard?

422
00:24:26,200 --> 00:24:28,559
What am I really looking for? And have the answer

423
00:24:28,599 --> 00:24:30,680
to your question. You don't care that the number of

424
00:24:30,759 --> 00:24:33,119
monthly active users that is increasing over time, but maybe

425
00:24:33,160 --> 00:24:35,119
you're utilizing that to figure out, well, where are the

426
00:24:35,119 --> 00:24:37,240
biggest jumps? Why was there a jump here and there?

427
00:24:37,559 --> 00:24:39,039
And so the question you want to ask is where

428
00:24:39,039 --> 00:24:41,680
are the biggest jumps and what happened to my organization

429
00:24:41,960 --> 00:24:44,319
or to our customers or competitors or in the global

430
00:24:44,400 --> 00:24:47,400
market that caused the biggest change in the last six months.

431
00:24:47,839 --> 00:24:50,279
And rather than looking at a graph that says that

432
00:24:50,400 --> 00:24:53,759
basically underlying data, you're getting the answer straight away, and

433
00:24:53,839 --> 00:24:56,039
then you can actually take the next step. And I

434
00:24:56,079 --> 00:24:58,720
guess one of the reasons I'm such a dashboard antagonist,

435
00:24:59,119 --> 00:25:01,559
I just coined that to our term right now is

436
00:25:02,839 --> 00:25:05,960
I mean, we focus a lot on high availability systems

437
00:25:06,000 --> 00:25:08,960
and high reliability. You can't know that you're you can't

438
00:25:08,960 --> 00:25:11,000
rely on a dashboard for telling you if your your

439
00:25:11,039 --> 00:25:12,880
system is up or down. Like you need to know

440
00:25:13,519 --> 00:25:16,640
deterministically what the answer is at any single moment. And

441
00:25:16,839 --> 00:25:18,799
I think the only difference is from a business is

442
00:25:19,440 --> 00:25:21,279
it's more long term. Although I think a lot of

443
00:25:21,519 --> 00:25:23,759
companies delude themselves into thinking that it can be a

444
00:25:23,839 --> 00:25:25,720
short term answer, that I can just look at this

445
00:25:25,880 --> 00:25:28,440
right now and automatically know what my next step is

446
00:25:28,519 --> 00:25:30,160
that I should take. And it's a lot more I

447
00:25:30,240 --> 00:25:34,440
feel like deep dive into really understanding the correlations between

448
00:25:34,440 --> 00:25:35,559
the underlying data stores.

449
00:25:36,960 --> 00:25:40,039
Speaker 3: Yeah, I think dashboards is the way that you can

450
00:25:40,119 --> 00:25:44,720
tell the story like in coherent way, like from usually

451
00:25:44,839 --> 00:25:49,000
from the experience, right, and when you just asking questions,

452
00:25:49,200 --> 00:25:52,119
you know, using your slack teams, it could be random

453
00:25:52,240 --> 00:25:55,759
questions without the context and without continuation. It would be

454
00:25:55,880 --> 00:25:59,160
like just party questions. Right. So in those words, usually

455
00:25:59,240 --> 00:26:02,839
when the builds right, it's the best ones, right, not

456
00:26:03,039 --> 00:26:06,400
all of them. You actually have a phenomenon, right, and

457
00:26:06,480 --> 00:26:09,400
measure and then a bunch of which is that explain

458
00:26:09,519 --> 00:26:14,000
like where it's coming from, like segmentation and audiences and

459
00:26:14,079 --> 00:26:16,640
so so so. So basically it's a good way to

460
00:26:16,759 --> 00:26:20,480
visualize changes. But again, this is the way that also

461
00:26:20,640 --> 00:26:24,519
doesn't allow you to recognize new things. It might be

462
00:26:25,160 --> 00:26:29,240
a new factor that affecting what's in your dashboard, and

463
00:26:29,319 --> 00:26:32,480
you will never know that because it's not automatically recognized

464
00:26:32,519 --> 00:26:35,559
and you're not popping up. Whereas when you use authentic

465
00:26:35,720 --> 00:26:37,720
you can know, okay, what are all the factors with

466
00:26:37,880 --> 00:26:41,759
influencing this spike, and then you will actually see like

467
00:26:41,880 --> 00:26:45,079
what is the related features which can affect right, So yeah,

468
00:26:45,200 --> 00:26:47,680
yeah to your point, to me, this world is a

469
00:26:47,680 --> 00:26:50,759
good starting point. It's not an endpoint, but a starting

470
00:26:50,799 --> 00:26:53,799
point where it can actually start your exploration going further.

471
00:26:54,119 --> 00:26:56,839
Everything is going to be data driven, and you know

472
00:26:56,920 --> 00:26:59,960
you don't have to have like myself, fifty different types

473
00:27:00,200 --> 00:27:04,119
open in your browser and this might affecting this upload speed.

474
00:27:05,039 --> 00:27:06,359
Speaker 2: Yeah, just fifteen.

475
00:27:07,000 --> 00:27:08,079
Speaker 1: Those are rookie numbers.

476
00:27:09,519 --> 00:27:12,039
Speaker 3: Yeah, so so I guess we'll not have to use

477
00:27:12,079 --> 00:27:15,160
so many applications for ever saying and you know, learning

478
00:27:15,200 --> 00:27:18,440
all those applications. It's it's about experience. I have a question,

479
00:27:18,599 --> 00:27:20,880
I have a task. I want to complete that, and

480
00:27:20,960 --> 00:27:24,680
I don't really care which applications and data is involved.

481
00:27:25,039 --> 00:27:26,680
Speaker 2: Right, it's so so optimistic.

482
00:27:27,880 --> 00:27:29,559
Speaker 3: You don't think five years is realistic.

483
00:27:30,640 --> 00:27:33,839
Speaker 2: I think that because of competition, there are always and

484
00:27:34,079 --> 00:27:37,240
the segmenting of data, availability of data in the market,

485
00:27:37,319 --> 00:27:40,000
Like there's no public Internet anymore, We've already seen the

486
00:27:40,119 --> 00:27:43,640
closing off of available data sources. Every single one of

487
00:27:43,680 --> 00:27:46,319
these applications is going to have access to just smaller

488
00:27:46,519 --> 00:27:48,680
pieces of data that are more focused, and you're still

489
00:27:48,680 --> 00:27:50,480
going to have to go from app to app to

490
00:27:50,839 --> 00:27:54,279
get these questions answered. And I think some companies are

491
00:27:54,319 --> 00:27:57,160
trying to push forward some way of still having like

492
00:27:57,200 --> 00:28:01,279
a single pane of glass to interact through utilizing MCP,

493
00:28:01,440 --> 00:28:04,559
the Model Context Protocol or a A two a agent

494
00:28:04,599 --> 00:28:06,559
to agent. Thank you Google for you know, coming up

495
00:28:06,599 --> 00:28:09,680
with something different. And you know even that, you know

496
00:28:09,839 --> 00:28:12,880
we can't even standardize you know, a single you know,

497
00:28:13,000 --> 00:28:17,319
paradigm for a protocol to communicate between agents. So you know,

498
00:28:17,799 --> 00:28:19,960
I don't I think we failed up to this point,

499
00:28:20,039 --> 00:28:21,960
you know, in the air twenty twenty five for humans

500
00:28:22,000 --> 00:28:25,720
to you know, have one agreed upon answer. I just

501
00:28:25,799 --> 00:28:28,519
don't see it happening unless you know, fundamentally your daily

502
00:28:28,680 --> 00:28:31,640
driver changes. And I know on the software engineering side

503
00:28:31,920 --> 00:28:34,799
we try to make it be the ide of choice,

504
00:28:35,279 --> 00:28:38,000
but even that still, like, I don't think everyone is

505
00:28:38,000 --> 00:28:40,200
spending all of their time just in that one tool.

506
00:28:40,519 --> 00:28:43,319
You're still switching back and forth to different communication tools

507
00:28:43,359 --> 00:28:43,839
and whatnot.

508
00:28:44,519 --> 00:28:46,960
Speaker 1: No, No, I'm just thinking like everyone's in favor of

509
00:28:47,000 --> 00:28:49,440
a single plane of glass as long as I'm the

510
00:28:49,519 --> 00:28:51,039
provider of a single pane of glass.

511
00:28:51,440 --> 00:28:53,440
Speaker 2: I think that sort of maybe brings in a question

512
00:28:53,599 --> 00:28:56,960
the Risondet like of the existence of the company, like

513
00:28:57,079 --> 00:28:59,839
what what are they doing that is fundamental? Like what

514
00:29:00,119 --> 00:29:01,720
is it that they're really trying to sell? And I

515
00:29:01,799 --> 00:29:04,079
feel like a lot of companies out there they just

516
00:29:04,200 --> 00:29:07,160
copy each other, like they're not creating something unique there.

517
00:29:07,240 --> 00:29:10,400
So I still see there always being an opportunity to

518
00:29:11,000 --> 00:29:12,880
own the data and sell it. And I think maybe

519
00:29:12,920 --> 00:29:15,599
this goes back to the question of if you're not

520
00:29:15,680 --> 00:29:19,400
providing something unique, then other companies can spin up and

521
00:29:19,559 --> 00:29:21,480
still own the data, and why not you pay some

522
00:29:21,640 --> 00:29:25,119
company to provide you with the answers to questions and

523
00:29:25,279 --> 00:29:27,480
manage all the data. And I think this has been

524
00:29:27,640 --> 00:29:30,839
a model that has existed in certainly with like a

525
00:29:31,039 --> 00:29:35,799
user research groups for instance, think tanks, consulting companies that

526
00:29:35,920 --> 00:29:38,240
come and tell you how to just do your business

527
00:29:38,440 --> 00:29:41,559
exactly what the data should be in everything. So I

528
00:29:42,079 --> 00:29:44,559
don't know, like even if in your own company you

529
00:29:44,680 --> 00:29:46,240
have a lot of data and you're like, we know

530
00:29:46,359 --> 00:29:48,720
how to utilize the data most effectively. We can go

531
00:29:49,039 --> 00:29:51,519
and hire an engineering team to go create that single

532
00:29:51,640 --> 00:29:54,359
pane of glass. Eventually you're like, well, other companies can

533
00:29:54,480 --> 00:29:56,359
use that pane of glass too, We'll start selling it.

534
00:29:56,400 --> 00:29:58,240
And then that company becomes just the seller of a

535
00:29:58,279 --> 00:30:00,200
pane of glass. So you know that's It's like I

536
00:30:00,279 --> 00:30:02,119
was just going to keep on going, but it really

537
00:30:02,160 --> 00:30:04,519
does bring up to the point where if another company

538
00:30:04,559 --> 00:30:07,880
can answer all of your business questions for you, oh

539
00:30:08,039 --> 00:30:11,480
what is there left to still be able to do uniquely?

540
00:30:13,880 --> 00:30:18,279
Speaker 3: So every organization has the old prietary data based on

541
00:30:18,359 --> 00:30:21,200
the nature of business and the customer base, and even

542
00:30:21,359 --> 00:30:24,519
someone comes and says, okay, right now, we are going

543
00:30:24,599 --> 00:30:27,799
to bring you into standards about how to make business.

544
00:30:27,960 --> 00:30:31,119
You'll still customize it what they only have like this

545
00:30:31,279 --> 00:30:35,160
is your advantage on one side. On the other side, yeah,

546
00:30:35,200 --> 00:30:38,400
if you have very special data and you want to

547
00:30:38,480 --> 00:30:41,079
sell it, you might want to sell it in machine

548
00:30:41,119 --> 00:30:44,119
readable format which is not reverse engineered. Right, So you

549
00:30:44,200 --> 00:30:49,000
do not sell data buy tables like they kills, right,

550
00:30:49,880 --> 00:30:53,920
but you sell your data as an en semantic meeting

551
00:30:54,039 --> 00:30:57,960
so so basically as machine readable format, so other algorithmsave

552
00:30:57,960 --> 00:31:01,759
agents can use it, but they cannot decipher that, right.

553
00:31:03,680 --> 00:31:06,160
I think it's actually the most secure way right to

554
00:31:06,279 --> 00:31:08,440
share data for specific use.

555
00:31:08,880 --> 00:31:12,720
Speaker 1: Speaking of which, what are the security concerns that you

556
00:31:13,400 --> 00:31:15,880
deal with whenever you have an agent that has access

557
00:31:15,920 --> 00:31:17,440
to all of these different data sources.

558
00:31:18,920 --> 00:31:23,759
Speaker 3: So in our organization, we actually choose to separate data

559
00:31:23,839 --> 00:31:28,039
values from data concepts from agents, so agents only have

560
00:31:28,400 --> 00:31:31,960
access to data concepts and then when the care is generated,

561
00:31:32,119 --> 00:31:35,079
it runs in separate environment on the data values and

562
00:31:36,400 --> 00:31:39,359
ELMACS does not ever touch data values of our customers

563
00:31:39,640 --> 00:31:42,759
just displayed in the customers applications, So we have total

564
00:31:42,799 --> 00:31:47,559
separation between agents and the data values themselves. So this

565
00:31:47,680 --> 00:31:51,160
approach actually allows you not to be concerned about the

566
00:31:51,400 --> 00:31:55,559
data leakage on a thing like that. I think every

567
00:31:55,599 --> 00:31:58,640
company will decide for themselves this you know on premisey

568
00:31:58,640 --> 00:32:02,920
deployment is right. I would never actually vote for that

569
00:32:03,119 --> 00:32:07,400
because models investings so fast and you have limited capability

570
00:32:07,440 --> 00:32:09,680
to upgrade them if you go for the own premisey

571
00:32:09,680 --> 00:32:12,960
deployment rather than just using APIs which always go forwards

572
00:32:13,000 --> 00:32:15,359
and so on. So firce. But you know, everyone will

573
00:32:15,440 --> 00:32:19,680
will make the choices again based on sensitivity and bright

574
00:32:19,839 --> 00:32:21,559
in nature of the data is probably going to be

575
00:32:21,680 --> 00:32:24,480
leveled some way that we have a you know, cloud

576
00:32:25,119 --> 00:32:29,079
storage with on premise and you know, different governance practices.

577
00:32:29,119 --> 00:32:31,640
It's going to to be the same for Augentic. Right now,

578
00:32:31,720 --> 00:32:36,000
it's more and modransparency about what's moving there, and the

579
00:32:36,400 --> 00:32:39,759
more punish about from the company side, like what's critical

580
00:32:39,839 --> 00:32:43,240
and what's sensitive for them to basically send to serve

581
00:32:43,319 --> 00:32:45,839
parties or what could be kept inside.

582
00:32:46,720 --> 00:32:49,359
Speaker 2: I really, I really like that perspective. If it was

583
00:32:49,720 --> 00:32:52,559
ever true in the past, where you could be profitable

584
00:32:52,680 --> 00:32:55,000
with an on prem data center storing all your data

585
00:32:55,079 --> 00:32:58,200
and running all your compute, that must be less and

586
00:32:58,319 --> 00:33:01,359
less true every day, and you'd have to be doing

587
00:33:01,400 --> 00:33:03,720
something very special for you to find value in that

588
00:33:03,759 --> 00:33:08,079
because technology is iterating even faster now, right like any

589
00:33:08,279 --> 00:33:10,039
argument you would have had in the past is now

590
00:33:10,400 --> 00:33:12,720
no longer valuable. And so like I'm totally with you.

591
00:33:12,839 --> 00:33:15,000
I don't I don't understand even ten years ago how

592
00:33:15,039 --> 00:33:19,480
people were justifying on prem solutions and now it's like

593
00:33:20,160 --> 00:33:21,440
even even less of the case.

594
00:33:22,799 --> 00:33:25,440
Speaker 3: It's cost prohibitive to move data to AI. You need

595
00:33:25,519 --> 00:33:27,400
to bring AI to data and if your data is

596
00:33:27,440 --> 00:33:29,400
on premise, it means you need to bring a I

597
00:33:29,480 --> 00:33:32,799
on premise. And this is like, you know, complicated and

598
00:33:33,599 --> 00:33:36,440
not very efficient to deal with things. But you know,

599
00:33:36,680 --> 00:33:38,839
you make your decision by some risk management. I guess

600
00:33:39,200 --> 00:33:40,119
the aw US.

601
00:33:40,079 --> 00:33:44,519
Speaker 2: Has the snowmobile, uh that you you know, just transfer

602
00:33:44,640 --> 00:33:46,799
the you know, get the USB sticks on a giant

603
00:33:46,839 --> 00:33:49,000
truck and you know, fly to the data center. And

604
00:33:50,359 --> 00:33:51,640
you know, I think I think that can work out.

605
00:33:51,720 --> 00:33:54,079
I mean, I think if anything, now, it's less about

606
00:33:54,200 --> 00:33:56,240
like it must be less about the amount of data

607
00:33:56,319 --> 00:33:59,839
you have and the rate of data creation. And I

608
00:34:00,200 --> 00:34:02,960
can see that with the number in a manufacturing plant

609
00:34:03,119 --> 00:34:06,119
or in healthcare, like the number of sensors increasing every

610
00:34:06,359 --> 00:34:08,920
all the time. You know, I'm wearing one here and

611
00:34:08,920 --> 00:34:12,159
I'm thinking about getting another one, and they're just going

612
00:34:12,199 --> 00:34:15,000
to increase more and more, and so with that increase

613
00:34:15,039 --> 00:34:17,079
you need to be able to handle it much more effectively.

614
00:34:18,119 --> 00:34:20,960
I think storage costs coming down at the cloud providers

615
00:34:21,079 --> 00:34:23,679
is probably the next innovation that will happen there. We

616
00:34:23,800 --> 00:34:28,239
just saw aws's as three one zone drastically reduced by

617
00:34:28,320 --> 00:34:30,559
like eighty five percent costs there, and I think we'll

618
00:34:30,559 --> 00:34:33,239
continue to see that as storage costs decrease over time,

619
00:34:33,280 --> 00:34:34,920
so it would just become more and more feasible to

620
00:34:34,960 --> 00:34:38,039
put data in the cloud closer to the agents.

621
00:34:38,679 --> 00:34:42,360
Speaker 3: Yeah, processing is always a bigger concerns. That's storage for

622
00:34:42,480 --> 00:34:45,000
many many years now. And I think this is also

623
00:34:45,239 --> 00:34:51,920
something that many of us in the news line what

624
00:34:52,079 --> 00:34:54,360
it was like last months, two months ago about deep six,

625
00:34:54,519 --> 00:34:58,599
So how much ability costs to actually train model. We

626
00:34:58,880 --> 00:35:02,920
actually have a in inference running, So the costs of

627
00:35:03,119 --> 00:35:08,119
processing is shifting from training to use of the models

628
00:35:08,320 --> 00:35:10,920
to the inference itself, and that's where I see that

629
00:35:11,199 --> 00:35:13,800
the majority of funds is going to be spent actually

630
00:35:13,920 --> 00:35:17,840
using AGENTIC on the data. And again, if it's more

631
00:35:17,880 --> 00:35:22,119
efficient on the cloud on data centers, I would say

632
00:35:22,280 --> 00:35:24,559
it's going to be more efficient in the cloud because

633
00:35:25,039 --> 00:35:27,559
especially if you're not locked into specific provider, is going

634
00:35:27,599 --> 00:35:31,760
to be more and more competition than that, and especially

635
00:35:31,880 --> 00:35:34,679
when you can recognize what data is garbage and what's

636
00:35:34,760 --> 00:35:38,480
not and kind of limit the footprints, so everything, all

637
00:35:38,559 --> 00:35:41,079
the costs are going to be down a thing. Right now,

638
00:35:41,280 --> 00:35:44,800
we spent lots of money already on the data pipelines

639
00:35:45,400 --> 00:35:49,239
which are duplicated to each other and not always feeding

640
00:35:49,320 --> 00:35:52,920
information that we actually use an application. But because companies

641
00:35:52,960 --> 00:35:56,400
do not monitor the metadata, they don't know what's in

642
00:35:56,599 --> 00:35:59,760
use and what's not right, so we already have like

643
00:36:00,159 --> 00:36:03,880
to spend which is pretty defined, and you paid anyhow

644
00:36:04,119 --> 00:36:06,320
if you use your dish verse, if you use applications,

645
00:36:06,320 --> 00:36:10,320
So if you're not, you're still paying the data vibelines

646
00:36:10,480 --> 00:36:13,920
that you have. So gente tick might replace as habits

647
00:36:14,280 --> 00:36:18,840
by actually invoking information and processing that you use and

648
00:36:19,159 --> 00:36:22,400
not which is pretty defined for you by someone assumption.

649
00:36:25,880 --> 00:36:28,480
Speaker 1: This is probably an unpopular opinion, but I think we're

650
00:36:28,519 --> 00:36:32,159
going to look back decades from now and say that

651
00:36:32,880 --> 00:36:36,239
making storage costs so inexpensive was the worst mistake we

652
00:36:36,320 --> 00:36:36,760
ever made.

653
00:36:37,119 --> 00:36:40,760
Speaker 2: I mean, as Gavin's paradox, right. I mean, anything anything

654
00:36:40,800 --> 00:36:43,159
that we don't want to have, we should not make

655
00:36:43,280 --> 00:36:48,400
more efficient because we will eventually over overutilize that thing. Yeah,

656
00:36:48,400 --> 00:36:50,719
I mean that it happened in I think really the

657
00:36:51,199 --> 00:36:56,599
industrial age, in especially England with coal mining. Yeah, I mean,

658
00:36:56,920 --> 00:37:02,119
for sure people are are utilizing or systems and it's

659
00:37:02,119 --> 00:37:06,280
abusing ways. Cloud providers have to have a strategy for

660
00:37:06,519 --> 00:37:09,800
dynamically swapping out hard drives as they fail because we

661
00:37:09,880 --> 00:37:12,199
haven't improved the reliability of them, just.

662
00:37:13,039 --> 00:37:13,679
Speaker 1: Just the size.

663
00:37:14,159 --> 00:37:17,280
Speaker 2: Yeah. Right, and you know that's sort of a problem.

664
00:37:17,320 --> 00:37:19,199
I mean, I think it's a science fiction ideal that

665
00:37:19,400 --> 00:37:22,599
we figure out how to inscribe and write and utilize

666
00:37:22,679 --> 00:37:26,159
data and sort of like a pure energy e lertromagnetic

667
00:37:26,320 --> 00:37:30,360
you know, constrained field inside like diamonds or something. I mean,

668
00:37:30,400 --> 00:37:33,239
it'd be nice, honestly. Well you're going to start working

669
00:37:33,280 --> 00:37:34,880
on that, Yeah?

670
00:37:34,920 --> 00:37:35,280
Speaker 1: Probably not.

671
00:37:40,679 --> 00:37:41,599
Speaker 2: Where are the customers?

672
00:37:42,159 --> 00:37:44,800
Speaker 3: Where are the customers? Well, my next gig is going

673
00:37:44,880 --> 00:37:48,400
to be in logivity for sure. I think it's fascinating fields,

674
00:37:48,480 --> 00:37:50,719
and I think we have one more data to actually

675
00:37:51,239 --> 00:37:54,159
have a breastrow sense fields. But yeah, yeah, I think

676
00:37:54,280 --> 00:37:57,719
data volumes are not necessarily a bad thing. But it's

677
00:37:57,760 --> 00:38:01,519
not about data ballis. It's about data variety. I wouldn't

678
00:38:01,559 --> 00:38:05,079
say like, actually have big data is advantage, but actually

679
00:38:05,199 --> 00:38:07,280
have rich data. Right.

680
00:38:07,519 --> 00:38:10,719
Speaker 2: So that's a really good point actually that I don't

681
00:38:10,719 --> 00:38:13,239
think anyone's brought up on the show before. I actually

682
00:38:13,280 --> 00:38:16,800
have a colleague that looked into the connections between networks

683
00:38:16,960 --> 00:38:19,639
human networks. But I think it applies here that as

684
00:38:19,679 --> 00:38:21,599
you said, it's not about the volume the amount that

685
00:38:21,639 --> 00:38:24,960
you have, but there's some arbitrary aspect of the of

686
00:38:25,039 --> 00:38:27,440
the data that's like super critical here, which is the

687
00:38:27,760 --> 00:38:31,559
say connectivity, but also the sparseness of it. How how,

688
00:38:32,760 --> 00:38:34,360
I don't think it's a metric for that for for

689
00:38:34,519 --> 00:38:36,719
what that is. Maybe maybe you're calling it something special.

690
00:38:37,199 --> 00:38:40,360
Speaker 3: We call it interoperability, maybe not the best word for

691
00:38:40,440 --> 00:38:45,000
that Internet, but it means it's actually like for data

692
00:38:45,039 --> 00:38:49,239
assets like table you can have different types of analysis

693
00:38:49,519 --> 00:38:52,280
or for analysis you can use like different assets to

694
00:38:52,360 --> 00:38:56,679
fit it in. So interoperability is the ability to to

695
00:38:56,880 --> 00:39:02,199
match different features between different sources, and that is a complimentary.

696
00:39:03,079 --> 00:39:05,559
Speaker 2: Yeah. So okay, so I have to ask about this.

697
00:39:06,119 --> 00:39:08,440
Some of the marketing for your company says that you

698
00:39:08,599 --> 00:39:13,159
don't have any hallucinations, and so we know that hallucinations

699
00:39:13,199 --> 00:39:17,119
are coupled to utilizing a straight transformer architecture. You know,

700
00:39:17,480 --> 00:39:19,880
if you're using transfer architecture, you must have hallucinations. So

701
00:39:20,199 --> 00:39:23,880
you must be doing something special that other companies aren't utilizing,

702
00:39:23,880 --> 00:39:26,599
you know, different from what the lms are are building.

703
00:39:27,320 --> 00:39:28,360
Is that something you can talk about?

704
00:39:29,360 --> 00:39:33,679
Speaker 3: Yeah? Sure. So our approach is to ground a single

705
00:39:33,760 --> 00:39:36,679
source of choice in your knowledge graph, right in your

706
00:39:36,719 --> 00:39:40,239
business intology, which is transparent right as businesstology is represented

707
00:39:40,320 --> 00:39:43,280
this knowledge graph of semantic embeddings. So for starters, we

708
00:39:43,360 --> 00:39:48,800
allly have kind of organizational agreements on what business logic is. Yeah,

709
00:39:49,039 --> 00:39:53,199
and in addition to that, we actually ground your experience

710
00:39:53,639 --> 00:39:56,960
only to the business ontology, right, So we degree we

711
00:39:57,159 --> 00:39:59,599
reduce the degrees of freedom of the model not to

712
00:40:00,320 --> 00:40:03,280
to think you know widely about universe, but to think

713
00:40:03,320 --> 00:40:06,159
about your companies in the universe. So when you ask

714
00:40:06,199 --> 00:40:08,760
a questions about active users, it will not think about

715
00:40:08,880 --> 00:40:12,239
Wikipedia definition of active users, will think about your business

716
00:40:12,320 --> 00:40:15,119
matching definition of active user, maybe if coming from your

717
00:40:15,159 --> 00:40:19,760
bi tool, right, So it's really grounding the experience of

718
00:40:19,840 --> 00:40:22,239
the users in the single source of choice of your organization.

719
00:40:22,679 --> 00:40:27,519
In addition, because we always build the synthologies based on

720
00:40:27,559 --> 00:40:31,440
the metadata, we understand the context much better. But do

721
00:40:31,559 --> 00:40:35,079
not only understand the context of user interaction within specific

722
00:40:35,280 --> 00:40:39,880
memory a frame in the copilot. We also understand the

723
00:40:40,000 --> 00:40:42,880
user interactions with any system which is connected to a

724
00:40:42,920 --> 00:40:48,679
remax right, so it's basically previous interactions with operational systems,

725
00:40:48,760 --> 00:40:52,079
with analytics systems. So our context is much wider and

726
00:40:52,280 --> 00:40:54,960
we can have much more personalized experience for the user

727
00:40:55,760 --> 00:40:59,760
based on this metadata access. And the third reason is

728
00:41:00,199 --> 00:41:02,920
because okay, so the first reason was the business ontology

729
00:41:03,079 --> 00:41:06,119
single sos of truths grounding for experience. The second one

730
00:41:06,559 --> 00:41:09,480
is personalization, and the third one because we do have

731
00:41:09,599 --> 00:41:14,360
business atologies which are a complimentary like in the language

732
00:41:14,360 --> 00:41:17,320
and so on and so forth before the customization for

733
00:41:17,400 --> 00:41:23,360
specific company. When users use different language which is different

734
00:41:23,559 --> 00:41:26,960
from the business metrics definitions and the organization, we can

735
00:41:27,079 --> 00:41:31,960
pick it up from our you know, generic contologies about

736
00:41:32,000 --> 00:41:36,159
this vertical because people switch companies, they might use different lingos,

737
00:41:36,199 --> 00:41:40,239
different abbreviations sure which are not necessarily implemented in this company.

738
00:41:40,280 --> 00:41:43,039
And we have not only user context, but we also

739
00:41:43,159 --> 00:41:47,039
have industry contexts so we can pick up this language.

740
00:41:47,400 --> 00:41:52,599
So those three reasons allow us to have much reduced

741
00:41:52,679 --> 00:41:56,159
experience on one side. On the other side, it's a

742
00:41:56,559 --> 00:42:00,440
very very first lace, so you cannot ask. It makes

743
00:42:00,440 --> 00:42:03,360
about whether you can only ask it makes about you

744
00:42:03,559 --> 00:42:06,199
connected data, so you're.

745
00:42:06,079 --> 00:42:11,519
Speaker 2: Not utilizing as much of a probabilistic model as other

746
00:42:11,599 --> 00:42:14,480
companies that have built their own foundational models.

747
00:42:15,400 --> 00:42:18,440
Speaker 3: We haven't built foundational models, but we use dozens of

748
00:42:18,480 --> 00:42:21,440
semantic models and two dozen of graph models for different

749
00:42:21,519 --> 00:42:26,239
tasks from onboarding to the user experience and explainability to

750
00:42:26,360 --> 00:42:30,039
provide this type of experience, and we always keep an

751
00:42:30,079 --> 00:42:33,079
eye on the latest and greatest, so we also when

752
00:42:33,119 --> 00:42:35,320
the new models come out, we test them and see

753
00:42:35,320 --> 00:42:37,880
how we can embed it and now andsemble and it

754
00:42:38,039 --> 00:42:42,039
helps us to you know, increase accuracy over time. But

755
00:42:42,159 --> 00:42:44,280
I think the biggest thing is if we give the

756
00:42:44,400 --> 00:42:47,400
ownership on the context and reasoning for the organization that

757
00:42:47,480 --> 00:42:50,480
we serve, we automatically build it for them and from

758
00:42:50,519 --> 00:42:52,920
now they are the owners of the context and reasoning.

759
00:42:53,320 --> 00:42:55,719
And if they want to plug tomorrow and Vida names

760
00:42:55,719 --> 00:42:58,519
so able as bad Shock, they can use this contexts.

761
00:42:59,079 --> 00:43:02,079
So it's kind of feeling, it's transparent and it's usable.

762
00:43:02,280 --> 00:43:04,000
So for us, this is the biggest benefit.

763
00:43:04,079 --> 00:43:07,800
Speaker 2: Actually, so there's still there's still a chance that it

764
00:43:07,800 --> 00:43:10,199
will hallucinate. It's just very very low and it will

765
00:43:10,280 --> 00:43:13,400
stay within the in the context of the business domain.

766
00:43:13,480 --> 00:43:16,559
Speaker 1: No, no, it's not a hallucination. It's a guide spiritual journey.

767
00:43:20,599 --> 00:43:23,199
Speaker 3: You mean, if you do have many versions of truth.

768
00:43:23,960 --> 00:43:26,599
So for example, Janna is just introduced new definition of

769
00:43:26,679 --> 00:43:29,159
active user and new dishboard. It makes fixed up and

770
00:43:29,360 --> 00:43:32,280
if someone asks about douctive user, we might offer like, okay,

771
00:43:32,400 --> 00:43:35,320
there is new definition in UBI dishboard. Would you like

772
00:43:35,400 --> 00:43:36,480
to get answer on that.

773
00:43:36,960 --> 00:43:40,079
Speaker 2: Wells, as long as there's a probability of how you

774
00:43:40,239 --> 00:43:43,360
generate a solution the answer, there's always a chance for

775
00:43:43,440 --> 00:43:46,320
it to pick it just make something up, even if

776
00:43:47,039 --> 00:43:51,599
you have tried to constrain it by actual definitions. Otherwise,

777
00:43:51,719 --> 00:43:54,920
that's just a fundamental aspect of probabilities. So I mean,

778
00:43:55,079 --> 00:43:58,800
while you can definitely reduce it and eliminate duplicate definitions,

779
00:43:58,960 --> 00:44:01,679
there's a whole other part of the transform architecture which

780
00:44:02,440 --> 00:44:06,079
fundamentally requires the creation of pollutionination. It's like, I know,

781
00:44:06,239 --> 00:44:07,840
you can have a transform architecture without that.

782
00:44:10,039 --> 00:44:13,679
Speaker 3: Again, it's a good point, and we provide explainability about answers,

783
00:44:13,719 --> 00:44:16,519
so it's not likely asking question for U and have

784
00:44:17,199 --> 00:44:20,039
numbers and answers actually provide folks mobility Like this is

785
00:44:20,159 --> 00:44:22,840
how we understand the questions. This is a semantic entity

786
00:44:22,920 --> 00:44:25,039
that we met this question too, and this is logic

787
00:44:25,119 --> 00:44:27,039
and all of that. And if user would like to

788
00:44:27,239 --> 00:44:29,519
to base the answer on different logic as I can

789
00:44:29,599 --> 00:44:33,480
actually choose like this not autopilot mode. And see, okay,

790
00:44:33,679 --> 00:44:36,960
this is the related semantic entities to a question. You know,

791
00:44:37,159 --> 00:44:39,599
you can pick up from them if you'd like to. Really,

792
00:44:39,840 --> 00:44:44,800
like my husband, he drives alpham Mito manual stick right,

793
00:44:44,960 --> 00:44:48,239
so he will always prefer to to have better control.

794
00:44:48,360 --> 00:44:50,960
It just back from Italy. So it's like those are

795
00:44:50,960 --> 00:44:54,360
also created for manual driving. So it's like some data

796
00:44:54,519 --> 00:44:57,800
is created for manual selection. Probably right, If it's like

797
00:44:58,880 --> 00:45:02,639
super A, I see you might want to select it manually,

798
00:45:03,119 --> 00:45:05,559
I would say, lucky. We will. Of course as an industry,

799
00:45:05,639 --> 00:45:08,320
we're going to be more and more automated. You know,

800
00:45:08,440 --> 00:45:10,079
some people just like more control.

801
00:45:11,239 --> 00:45:13,920
Speaker 2: I think it's like the the idea of control more

802
00:45:14,000 --> 00:45:15,760
so than actually in control, like you know, you don't

803
00:45:15,760 --> 00:45:18,400
want you don't want, you don't want the manual stick shift.

804
00:45:18,440 --> 00:45:20,360
You want to be told it's a manual stick shift.

805
00:45:20,400 --> 00:45:21,960
But if you mess up and do the wrong thing,

806
00:45:22,000 --> 00:45:23,039
the right thing is still happen.

807
00:45:24,719 --> 00:45:27,320
Speaker 3: That's choose a choose that always, you know. Yeah, we

808
00:45:27,440 --> 00:45:29,880
have systems like aybeas and all that to keep us safe.

809
00:45:29,960 --> 00:45:30,400
That's true.

810
00:45:32,480 --> 00:45:34,000
Speaker 1: Do you want to shift the gears but you don't

811
00:45:34,000 --> 00:45:34,880
want to dump the clutch?

812
00:45:36,679 --> 00:45:40,079
Speaker 3: Probably awesome, not over like comel like you know, two

813
00:45:40,159 --> 00:45:41,599
hundred meters above the water.

814
00:45:41,519 --> 00:45:47,280
Speaker 1: And no, right, not really awesome. So it feels like

815
00:45:47,360 --> 00:45:49,320
this might be a good place to roll into picks.

816
00:45:49,360 --> 00:45:52,360
What do you think? Okay, let's do it, Warren. Yeah,

817
00:45:52,519 --> 00:45:54,159
you're never gonna guess what's happening next.

818
00:45:54,320 --> 00:45:58,199
Speaker 2: Okay, I'm going first. Yeah, so I got a really

819
00:45:58,239 --> 00:46:02,360
controversial good one here. There's yeah like like, I like,

820
00:46:02,440 --> 00:46:05,440
I like it. So there's this great article that I

821
00:46:06,039 --> 00:46:09,199
read through. It's short, it's short form, so it should

822
00:46:09,199 --> 00:46:12,000
be easy for anyone to get through. It's basically the

823
00:46:12,079 --> 00:46:14,880
idea of how intuition is being used in software engineering

824
00:46:15,000 --> 00:46:18,679
and whether or not lms are capable of intuition and

825
00:46:19,039 --> 00:46:22,239
It is actually a proof that shows we can't have

826
00:46:22,400 --> 00:46:26,280
AGI with transform architecture. Our lms will never be able

827
00:46:26,360 --> 00:46:31,840
to reason. And it utilizes Google's incompletely its theorem the

828
00:46:31,960 --> 00:46:36,239
non computability of intuition and the computability of touring machines,

829
00:46:36,760 --> 00:46:39,320
and just with that we can actually prove fundamentally that

830
00:46:39,400 --> 00:46:41,599
we can have AGI with our current systems. We haven't

831
00:46:41,599 --> 00:46:44,079
gotten any closer to that. So don't don't listen to

832
00:46:44,159 --> 00:46:48,800
the lies that people have been sharing from massive quote

833
00:46:48,880 --> 00:46:52,840
unquote AI companies, because the real argument here is that

834
00:46:53,440 --> 00:46:57,000
in order for us to have a GI, you need

835
00:46:57,039 --> 00:46:59,480
to introduce intuition, and that's the exact thing that's lacking

836
00:46:59,639 --> 00:47:01,400
in turning machines.

837
00:47:02,440 --> 00:47:03,559
Speaker 3: Question too, are you born?

838
00:47:04,679 --> 00:47:05,880
Speaker 2: Yeah, well there there is the.

839
00:47:07,440 --> 00:47:09,239
Speaker 3: Just answer that if you're not born.

840
00:47:10,280 --> 00:47:12,519
Speaker 1: Answer the question Warren, Yeah.

841
00:47:12,639 --> 00:47:16,679
Speaker 4: It means experience really so yeah, yeah, I mean it's

842
00:47:16,679 --> 00:47:21,039
really hard to identify even what happens as an individual,

843
00:47:21,280 --> 00:47:23,920
let alone if we can believe it on an external system.

844
00:47:24,079 --> 00:47:28,039
Speaker 2: Luckily, the Turing Turing machines we know, you know are

845
00:47:28,119 --> 00:47:29,679
are are our closed systems.

846
00:47:29,719 --> 00:47:29,880
Speaker 3: There.

847
00:47:30,119 --> 00:47:32,719
Speaker 2: I I likened it to this great quote which will

848
00:47:32,760 --> 00:47:35,440
be a future pick of in a in a future episode.

849
00:47:35,800 --> 00:47:39,679
A parrot reciting Shakespeare. That's that's l MS today. And

850
00:47:40,159 --> 00:47:42,079
you would never claim that that a parrot, you know,

851
00:47:42,119 --> 00:47:45,559
would fully understand you know what it's reciting there. Uh,

852
00:47:45,840 --> 00:47:49,159
And that's that's unfortunately the extent of our technology. That's

853
00:47:49,199 --> 00:47:50,559
my pick right.

854
00:47:50,599 --> 00:47:52,519
Speaker 1: Ina, you're upe, what did you bring for a pick.

855
00:47:54,079 --> 00:47:59,719
Speaker 3: Per pack? Well, I wasn't for that, but I must

856
00:47:59,760 --> 00:48:03,480
say yeah, So let's speak about AGI as well. I

857
00:48:04,079 --> 00:48:07,159
do not believe in AGI in the next five to

858
00:48:07,239 --> 00:48:11,719
ten years, at least, just the fact that these humans

859
00:48:11,800 --> 00:48:16,639
be capable of applying context from one experience to different experience.

860
00:48:17,199 --> 00:48:19,199
So I do not call it intuition because intuition, to

861
00:48:19,280 --> 00:48:23,000
me is just experience. But our ability to merge contexts

862
00:48:23,159 --> 00:48:29,719
which are vividly not connected is whereas the humans park

863
00:48:30,000 --> 00:48:32,559
is and to me, AGI is not going to be

864
00:48:32,719 --> 00:48:36,519
near that in the overseable future, let's say ten years.

865
00:48:37,320 --> 00:48:40,880
So think about you can apply your knowledge from cooking

866
00:48:41,360 --> 00:48:43,519
to your knowledge of right now, you know, coding or

867
00:48:43,559 --> 00:48:45,480
something like that, like what the ingredients and so on

868
00:48:45,519 --> 00:48:49,239
and so first, so our associations work differently than machine association,

869
00:48:49,400 --> 00:48:55,000
and this context merge from unrelated experiences something that machines

870
00:48:55,000 --> 00:48:55,559
are not good with.

871
00:48:56,440 --> 00:48:59,119
Speaker 2: I like how you went to the philosophy side of this,

872
00:48:59,440 --> 00:49:01,159
you know, our you know, there's this idea that the

873
00:49:01,320 --> 00:49:04,480
universe is deterministic and that everything is connected through the

874
00:49:04,559 --> 00:49:07,199
collapse of the you know, Shirtinger's equation, the wave function,

875
00:49:07,519 --> 00:49:08,079
and uh.

876
00:49:08,079 --> 00:49:09,599
Speaker 3: It's called religion. Yeah.

877
00:49:10,159 --> 00:49:11,960
Speaker 2: Oh I was ready to go there.

878
00:49:12,880 --> 00:49:17,320
Speaker 3: Yeah, yeah, I do.

879
00:49:17,440 --> 00:49:19,840
Speaker 2: I do agree. You know, fundamentally, there's something missing from

880
00:49:20,199 --> 00:49:23,639
the computing systems that we build today in order to

881
00:49:23,840 --> 00:49:25,280
actually achieve AGI.

882
00:49:25,920 --> 00:49:28,960
Speaker 1: My pick's going to take this down a whole big

883
00:49:29,119 --> 00:49:33,159
notch because you know, we were talking about having the

884
00:49:33,280 --> 00:49:35,239
number of the number of tabs that you have open

885
00:49:35,320 --> 00:49:37,599
in your browser. For the last couple of months, I've

886
00:49:37,639 --> 00:49:41,800
been using the ARC browser and specifically that conversation. One

887
00:49:41,840 --> 00:49:44,199
of the things ARC does is any tab that you

888
00:49:44,320 --> 00:49:47,719
haven't touched in the last thirty days, it just closes.

889
00:49:47,320 --> 00:49:47,760
Speaker 3: It for you.

890
00:49:48,639 --> 00:49:50,880
Speaker 1: And I used to have a bunch of tabs open,

891
00:49:50,960 --> 00:49:52,519
and I was like, Okay, I'm going to try this.

892
00:49:52,599 --> 00:49:54,039
I'm gonna hate it. I'm going to figure out how

893
00:49:54,079 --> 00:49:55,639
to turn that feature off, or I'm going to quit

894
00:49:55,760 --> 00:49:59,760
using it. After several months it's closed. Probably hundreds of

895
00:49:59,800 --> 00:50:04,480
t as for me and I've not noticed. So go

896
00:50:04,639 --> 00:50:06,960
try out the ARC browser. You don't need all those tabs.

897
00:50:07,360 --> 00:50:10,599
Speaker 2: I think I'm having a little bit of a neurological

898
00:50:10,679 --> 00:50:13,239
meltdown just at hearing about that feature.

899
00:50:13,360 --> 00:50:19,920
Speaker 1: Well, right, it's panic inducing, Yeah, for sure, definitely.

900
00:50:20,400 --> 00:50:22,679
Speaker 2: I mean there are tabs that I actually leave there,

901
00:50:22,760 --> 00:50:25,239
that I know are there and I don't want them

902
00:50:25,280 --> 00:50:25,920
to go away.

903
00:50:28,960 --> 00:50:31,400
Speaker 1: Cool. I have a follow up question for you, Warren.

904
00:50:31,480 --> 00:50:34,719
Though you mentioned that you wear you're currently wearing one

905
00:50:34,840 --> 00:50:38,079
IoT device and you're thinking about getting another one. What

906
00:50:38,199 --> 00:50:39,719
are you wearing and what are you thinking about getting?

907
00:50:40,039 --> 00:50:42,079
Speaker 2: Yeah, so this isn't my pick, but I'm wearing the

908
00:50:42,199 --> 00:50:46,480
Google pixel Watch too. I would definitely not recommend anyone

909
00:50:46,639 --> 00:50:51,639
to get a smart watch ever. So that's one. So

910
00:50:51,679 --> 00:50:53,760
I want to replacement. This thing disturbs me while I'm

911
00:50:53,800 --> 00:50:56,480
sleeping and I would really like to get my sleep metrics,

912
00:50:56,559 --> 00:51:01,440
and so I've been looking at alternatives there. I the

913
00:51:01,559 --> 00:51:04,000
number one one is the ORR ring. I think they're

914
00:51:04,039 --> 00:51:06,280
on edition four, but it's a subscription based thing and

915
00:51:06,840 --> 00:51:09,079
that really rose me the wrong way. So I'm not

916
00:51:09,199 --> 00:51:12,880
I'm not interested in that realistically. But that's why I'm

917
00:51:12,880 --> 00:51:15,400
hoping for a good ring without a subscription to show

918
00:51:15,480 --> 00:51:17,039
up that I think I'd be okay wearing a bed.

919
00:51:17,800 --> 00:51:21,639
Speaker 1: No, I was just curious, curious I have for my watch.

920
00:51:21,679 --> 00:51:25,280
I have a Garment Phoenix, which is technically a smart watch,

921
00:51:25,320 --> 00:51:28,400
but I have everything turned off on it. The only

922
00:51:28,480 --> 00:51:31,679
thing I use it for is heart rate and uh

923
00:51:31,800 --> 00:51:34,880
metrics whenever I'm out for a run. And I had

924
00:51:34,920 --> 00:51:39,320
an or a ring for a while and same same

925
00:51:39,360 --> 00:51:40,679
with you, is like, I don't want to pay a

926
00:51:40,760 --> 00:51:43,800
subscription for it. And I know a lot of people

927
00:51:43,840 --> 00:51:49,039
who use the Whoop Band, but it's another subscription based service.

928
00:51:49,360 --> 00:51:52,079
But they're like, just let me, let me buy it

929
00:51:52,119 --> 00:51:53,719
and go on with my life. Is that cool with you?

930
00:51:54,320 --> 00:51:57,679
But trying to push updates out onto devices that people

931
00:51:58,599 --> 00:52:02,440
that people you don't have act ys too, Like, that's

932
00:52:02,639 --> 00:52:05,239
not a fun place to be. Even from my days

933
00:52:05,280 --> 00:52:08,320
of supporting mobile apps, just trying to get people to

934
00:52:08,440 --> 00:52:14,480
update it was frustrating, all right, you know, thank you

935
00:52:14,559 --> 00:52:16,119
so much for joining us today. This has been a

936
00:52:16,159 --> 00:52:16,639
lot of fun.

937
00:52:17,639 --> 00:52:20,119
Speaker 3: Likewise, I really enjoyed the composites.

938
00:52:19,880 --> 00:52:23,480
Speaker 1: Orren as always, Thank you, appreciate you being on the show. Yeah,

939
00:52:23,519 --> 00:52:27,599
of course, and to all the listeners, thank you very

940
00:52:27,760 --> 00:52:31,199
very much because you're kind of the reason that we

941
00:52:31,320 --> 00:52:33,840
do this, so hopefully you enjoyed this. If not, you

942
00:52:33,920 --> 00:52:35,719
know how to find us and let us know, and

943
00:52:35,880 --> 00:52:36,599
you see always