1
00:00:00,000 --> 00:00:03,200
Your organization invests in automation with one assumption.

2
00:00:03,200 --> 00:00:04,520
It saves time.

3
00:00:04,520 --> 00:00:09,160
Fewer manual tasks, faster processes, less operational drag.

4
00:00:09,160 --> 00:00:10,440
But here's what actually happens.

5
00:00:10,440 --> 00:00:13,480
You end up with dozens of disconnected scripts scattered

6
00:00:13,480 --> 00:00:14,840
across different environments.

7
00:00:14,840 --> 00:00:17,760
You have different owners and different failure modes.

8
00:00:17,760 --> 00:00:21,000
When the person who wrote the script leaves the process breaks,

9
00:00:21,000 --> 00:00:23,400
when you try to scale it, the whole thing fractures.

10
00:00:23,400 --> 00:00:26,320
And somehow, the automation you built to save time

11
00:00:26,320 --> 00:00:29,200
now consumes more time than the manual work it replaced.

12
00:00:29,200 --> 00:00:32,680
Most organizations treat automation as a series of hero scripts.

13
00:00:32,680 --> 00:00:35,200
One person builds something to solve an immediate problem

14
00:00:35,200 --> 00:00:36,480
and it works for a while.

15
00:00:36,480 --> 00:00:37,680
Then it becomes a liability.

16
00:00:37,680 --> 00:00:40,440
It stays un-maintained, undocumented, and fragile.

17
00:00:40,440 --> 00:00:43,360
When you add that to 50 other scripts in the same environment,

18
00:00:43,360 --> 00:00:45,080
you create a technical debt problem.

19
00:00:45,080 --> 00:00:48,240
It doesn't show up in your budget until the day it completely breaks.

20
00:00:48,240 --> 00:00:50,160
This isn't about writing better power shell.

21
00:00:50,160 --> 00:00:52,640
This isn't about finding the right connectors.

22
00:00:52,640 --> 00:00:55,040
This isn't about scheduling tasks more efficiently.

23
00:00:55,040 --> 00:00:57,000
This is about recognizing a shift.

24
00:00:57,000 --> 00:01:00,120
By 2026, the organizations actually winning aren't the ones

25
00:01:00,120 --> 00:01:01,480
with the fastest scripts.

26
00:01:01,480 --> 00:01:04,000
They're the ones with platforms that don't require heroes.

27
00:01:04,000 --> 00:01:06,080
They are the ones that shifted from fragile point-to-point

28
00:01:06,080 --> 00:01:08,800
automation to orchestrated, governed, autonomous systems.

29
00:01:08,800 --> 00:01:11,320
The difference between these two approaches is not incremental.

30
00:01:11,320 --> 00:01:12,920
It's architectural.

31
00:01:12,920 --> 00:01:16,160
Let's start by diagnosing where your organization actually is.

32
00:01:16,160 --> 00:01:17,400
The maturity trap.

33
00:01:17,400 --> 00:01:19,200
There's a common assumption about automation.

34
00:01:19,200 --> 00:01:20,720
It follows a linear progression.

35
00:01:20,720 --> 00:01:22,080
You start with manual work.

36
00:01:22,080 --> 00:01:25,240
Then you write a script, then you schedule it, then you integrate it.

37
00:01:25,240 --> 00:01:26,520
And then you're done.

38
00:01:26,520 --> 00:01:27,440
That's the theory.

39
00:01:27,440 --> 00:01:30,040
In reality, it's a trap.

40
00:01:30,040 --> 00:01:33,120
Most organizations are stuck in the script consolidation phase.

41
00:01:33,120 --> 00:01:35,760
They have dozens of power shell scripts running across on-premises

42
00:01:35,760 --> 00:01:39,000
infrastructure, Azure, task schedulers, and logic apps.

43
00:01:39,000 --> 00:01:41,160
They use power automate alongside legacy tools,

44
00:01:41,160 --> 00:01:43,240
but nobody actually knows which ones are still being used.

45
00:01:43,240 --> 00:01:44,560
Nobody knows who owns them.

46
00:01:44,560 --> 00:01:46,080
And when something breaks at 2 a.m.,

47
00:01:46,080 --> 00:01:49,200
the organization reaches out to the person who wrote it three years ago.

48
00:01:49,200 --> 00:01:51,080
That is assuming that person still works there.

49
00:01:51,080 --> 00:01:52,440
This isn't a technology problem.

50
00:01:52,440 --> 00:01:53,880
It's an architecture problem.

51
00:01:53,880 --> 00:01:56,080
The five levels of automation maturity exist,

52
00:01:56,080 --> 00:01:58,080
but they're not sequential in most enterprises.

53
00:01:58,080 --> 00:01:59,320
They exist concurrently.

54
00:01:59,320 --> 00:02:00,840
You're running all five at the same time,

55
00:02:00,840 --> 00:02:03,360
and that creates fragmentation and operational chaos.

56
00:02:03,360 --> 00:02:06,120
Manual work still happens because the automated solution broke

57
00:02:06,120 --> 00:02:07,520
or was never documented.

58
00:02:07,520 --> 00:02:09,160
Scripts exist in repositories.

59
00:02:09,160 --> 00:02:10,840
Nobody can find running on servers.

60
00:02:10,840 --> 00:02:11,960
Nobody remembers.

61
00:02:11,960 --> 00:02:13,840
Integration attempts have created dependencies

62
00:02:13,840 --> 00:02:15,400
that nobody fully understands.

63
00:02:15,400 --> 00:02:17,960
So what's actually happening is the model is failing.

64
00:02:17,960 --> 00:02:21,000
Organizations that have moved past this phase look different.

65
00:02:21,000 --> 00:02:24,120
They're not the ones with the most developers or the fastest code.

66
00:02:24,120 --> 00:02:27,160
They are the ones treating automation as a strategic capability

67
00:02:27,160 --> 00:02:28,480
instead of a collection of scripts.

68
00:02:28,480 --> 00:02:30,600
They move three times faster than everyone else.

69
00:02:30,600 --> 00:02:32,360
Not because their individual scripts are better,

70
00:02:32,360 --> 00:02:34,560
but because their system's thinking is better.

71
00:02:34,560 --> 00:02:36,360
The diagnostic question separates them.

72
00:02:36,360 --> 00:02:37,680
Do we have orchestration?

73
00:02:37,680 --> 00:02:40,080
Orchestration means when one process completes,

74
00:02:40,080 --> 00:02:41,520
the next one knows it completed.

75
00:02:41,520 --> 00:02:42,880
It means when something fails,

76
00:02:42,880 --> 00:02:45,000
the failure is visible and recoverable.

77
00:02:45,000 --> 00:02:47,000
It means when you add a new integration,

78
00:02:47,000 --> 00:02:49,520
you're not creating another point-to-point cable.

79
00:02:49,520 --> 00:02:51,040
You're plugging into an existing fabric.

80
00:02:51,040 --> 00:02:52,880
Most organizations don't have that fabric.

81
00:02:52,880 --> 00:02:54,280
They have a collection of cables.

82
00:02:54,280 --> 00:02:55,840
Each one was added independently.

83
00:02:55,840 --> 00:02:57,840
Each one requires its own maintenance.

84
00:02:57,840 --> 00:02:59,440
Each one fails independently.

85
00:02:59,440 --> 00:03:02,680
The cost of fragmentation stays invisible until you try to scale.

86
00:03:02,680 --> 00:03:04,040
That's when it becomes catastrophic.

87
00:03:04,040 --> 00:03:06,280
50 scripts can survive through heroic effort,

88
00:03:06,280 --> 00:03:08,160
but 500 scripts cannot.

89
00:03:08,160 --> 00:03:10,960
The only path forward is rebuilding the foundation.

90
00:03:10,960 --> 00:03:13,160
Organizations at that breaking point face a hard choice.

91
00:03:13,160 --> 00:03:14,720
You can keep patching the script model

92
00:03:14,720 --> 00:03:16,480
or you can rebuild around platforms.

93
00:03:16,480 --> 00:03:19,440
The shift isn't about faster scripts or more connectors.

94
00:03:19,440 --> 00:03:22,360
It's about adopting a different mental model entirely,

95
00:03:22,360 --> 00:03:24,160
understanding where you are is the first step.

96
00:03:24,160 --> 00:03:26,840
The second is understanding what orchestration actually means

97
00:03:26,840 --> 00:03:28,720
in the Microsoft ecosystem.

98
00:03:28,720 --> 00:03:30,520
What orchestration actually means?

99
00:03:30,520 --> 00:03:31,880
Orchestration isn't a tool.

100
00:03:31,880 --> 00:03:33,120
It's a pattern.

101
00:03:33,120 --> 00:03:34,440
In the Microsoft ecosystem,

102
00:03:34,440 --> 00:03:37,400
orchestration means that graph becomes your central nervous system.

103
00:03:37,400 --> 00:03:39,480
This isn't because graph is special or proprietary.

104
00:03:39,480 --> 00:03:41,200
It's special for one specific reason.

105
00:03:41,200 --> 00:03:42,680
It is the only unified interface

106
00:03:42,680 --> 00:03:45,440
for your Microsoft 365 data and identity.

107
00:03:45,440 --> 00:03:48,320
Everything you use, exchange, sharepoint, teams, one drive

108
00:03:48,320 --> 00:03:50,120
and enter ID is accessed right there.

109
00:03:50,120 --> 00:03:51,920
When you build a script that reads from exchange

110
00:03:51,920 --> 00:03:53,160
and writes to sharepoint,

111
00:03:53,160 --> 00:03:55,320
you are just creating a point-to-point connection.

112
00:03:55,320 --> 00:03:56,800
Data flows in one direction.

113
00:03:56,800 --> 00:03:59,280
Two systems have to know about each other directly.

114
00:03:59,280 --> 00:04:01,040
But when you build an orchestration layer

115
00:04:01,040 --> 00:04:03,080
that roots that same data through graph,

116
00:04:03,080 --> 00:04:04,640
you create something different.

117
00:04:04,640 --> 00:04:06,600
Now the systems don't need to know about each other.

118
00:04:06,600 --> 00:04:08,960
They only need to know about the orchestration layer.

119
00:04:08,960 --> 00:04:10,240
The difference isn't academic.

120
00:04:10,240 --> 00:04:12,120
It's operational.

121
00:04:12,120 --> 00:04:13,800
A point-to-point connection breaks the moment

122
00:04:13,800 --> 00:04:14,840
and endpoint changes.

123
00:04:14,840 --> 00:04:17,320
If the exchange API changes, your script breaks

124
00:04:17,320 --> 00:04:19,080
and if the SharePoint API changes,

125
00:04:19,080 --> 00:04:20,440
your script breaks again,

126
00:04:20,440 --> 00:04:22,360
an orchestration layer survives those changes

127
00:04:22,360 --> 00:04:24,680
because the layer itself becomes the contract.

128
00:04:24,680 --> 00:04:25,960
The endpoints can change.

129
00:04:25,960 --> 00:04:27,520
But the interface between the system

130
00:04:27,520 --> 00:04:29,720
and the orchestration layer stays the same.

131
00:04:29,720 --> 00:04:31,560
Here's what that looks like in practice.

132
00:04:31,560 --> 00:04:33,400
Imagine a workflow that needs to react

133
00:04:33,400 --> 00:04:34,880
when a new email arrives.

134
00:04:34,880 --> 00:04:35,960
In the old script model,

135
00:04:35,960 --> 00:04:37,240
you write a scheduled task

136
00:04:37,240 --> 00:04:39,720
that pulls exchange every five minutes.

137
00:04:39,720 --> 00:04:41,400
The system asks if anything changed.

138
00:04:41,400 --> 00:04:43,400
Five minutes pass and nothing happens.

139
00:04:43,400 --> 00:04:45,520
Five more minutes pass and it's still quiet.

140
00:04:45,520 --> 00:04:46,920
Then an email finally arrives,

141
00:04:46,920 --> 00:04:49,560
but the system only finds out about it five minutes later.

142
00:04:49,560 --> 00:04:50,560
If you are lucky.

143
00:04:50,560 --> 00:04:51,720
In the orchestration model,

144
00:04:51,720 --> 00:04:53,760
you create a graph subscription instead.

145
00:04:53,760 --> 00:04:55,680
You tell the system to let you know the second

146
00:04:55,680 --> 00:04:56,640
an email arrives.

147
00:04:56,640 --> 00:04:58,440
The system doesn't guess and it doesn't pull.

148
00:04:58,440 --> 00:04:59,720
When that email hits the inbox,

149
00:04:59,720 --> 00:05:01,200
the system knows immediately.

150
00:05:01,200 --> 00:05:02,720
But here is what most people miss.

151
00:05:02,720 --> 00:05:04,200
The subscription alone isn't enough.

152
00:05:04,200 --> 00:05:06,040
Subscriptions can expire or be missed

153
00:05:06,040 --> 00:05:09,080
and they often fail silently without anyone noticing.

154
00:05:09,080 --> 00:05:11,560
So the orchestration layer does something counterintuitive.

155
00:05:11,560 --> 00:05:14,440
It pairs the subscription with a Delta query

156
00:05:14,440 --> 00:05:16,680
that periodically reconciles the state.

157
00:05:16,680 --> 00:05:18,440
You schedule it to run once a day

158
00:05:18,440 --> 00:05:20,280
and the Delta query asks SharePoint

159
00:05:20,280 --> 00:05:21,920
what changed since the last check.

160
00:05:21,920 --> 00:05:23,520
If the subscription missed something,

161
00:05:23,520 --> 00:05:25,040
the Delta query catches it

162
00:05:25,040 --> 00:05:27,080
and if the subscription failed entirely,

163
00:05:27,080 --> 00:05:28,720
the Delta query is your backup.

164
00:05:28,720 --> 00:05:29,800
This isn't redundancy.

165
00:05:29,800 --> 00:05:31,440
This is resilience.

166
00:05:31,440 --> 00:05:33,520
You get the speed of an event-driven architecture

167
00:05:33,520 --> 00:05:36,720
combined with the reliability of a batch reconciliation.

168
00:05:36,720 --> 00:05:38,280
This pattern is now the standard.

169
00:05:38,280 --> 00:05:40,480
In 2026, the organizations that are winning

170
00:05:40,480 --> 00:05:41,960
understand this distinction.

171
00:05:41,960 --> 00:05:43,560
They aren't building faster scripts.

172
00:05:43,560 --> 00:05:45,520
They are building systems that remain reliable

173
00:05:45,520 --> 00:05:46,560
when things break.

174
00:05:46,560 --> 00:05:48,240
The shift from scripts to orchestration

175
00:05:48,240 --> 00:05:50,640
is really a shift in how you think about causality.

176
00:05:50,640 --> 00:05:53,760
In a script, you are saying, "Do this, then do that."

177
00:05:53,760 --> 00:05:56,120
You execute step one, wait for it to finish

178
00:05:56,120 --> 00:05:57,720
and then execute step two.

179
00:05:57,720 --> 00:05:59,200
In an orchestration, you are saying,

180
00:05:59,200 --> 00:06:01,480
"When this happens, the system responds."

181
00:06:01,480 --> 00:06:02,840
The system becomes an actor.

182
00:06:02,840 --> 00:06:04,360
It observes, it reacts.

183
00:06:04,360 --> 00:06:06,760
It doesn't wait for someone to tell it what to do next.

184
00:06:06,760 --> 00:06:09,440
This matters because it changes who is responsible.

185
00:06:09,440 --> 00:06:11,720
In a script model, the person who wrote the code

186
00:06:11,720 --> 00:06:13,280
is responsible for what it does.

187
00:06:13,280 --> 00:06:15,520
When something goes wrong, you have to call that person.

188
00:06:15,520 --> 00:06:18,760
In an orchestration model, the system itself is responsible.

189
00:06:18,760 --> 00:06:21,680
The person becomes the architect who designed the system.

190
00:06:21,680 --> 00:06:23,560
Not the operator who has to maintain it.

191
00:06:23,560 --> 00:06:24,920
That's why this shift is hard.

192
00:06:24,920 --> 00:06:26,480
It requires organizations to admit

193
00:06:26,480 --> 00:06:28,640
that the hero script model doesn't scale anymore.

194
00:06:28,640 --> 00:06:30,440
It requires rebuilding the foundation

195
00:06:30,440 --> 00:06:33,080
and thinking about systems instead of individual tasks.

196
00:06:33,080 --> 00:06:34,840
But this is also why the organizations doing this

197
00:06:34,840 --> 00:06:36,240
are moving so much faster.

198
00:06:36,240 --> 00:06:38,520
Once the foundation is solid, adding new capabilities

199
00:06:38,520 --> 00:06:39,480
becomes trivial.

200
00:06:39,480 --> 00:06:41,240
You aren't writing new scripts.

201
00:06:41,240 --> 00:06:43,840
You are just adding new rules to an existing fabric.

202
00:06:43,840 --> 00:06:45,560
Understanding the pattern is one thing,

203
00:06:45,560 --> 00:06:47,800
but implementing it requires knowing what infrastructure

204
00:06:47,800 --> 00:06:49,120
actually supports it.

205
00:06:49,120 --> 00:06:52,200
We need to talk about what that looks like in 2026.

206
00:06:52,200 --> 00:06:54,720
The infrastructure layer, choosing your foundation.

207
00:06:54,720 --> 00:06:57,800
By 2026, the infrastructure choices have consolidated.

208
00:06:57,800 --> 00:07:00,120
You aren't choosing between dozens of options anymore.

209
00:07:00,120 --> 00:07:02,080
You're choosing between two different patterns.

210
00:07:02,080 --> 00:07:04,800
And each one has clear economic and operational trade-offs.

211
00:07:04,800 --> 00:07:06,960
The first choice is about where you orchestrate.

212
00:07:06,960 --> 00:07:08,800
Do you want to do it at the workflow level

213
00:07:08,800 --> 00:07:10,160
or the compute level?

214
00:07:10,160 --> 00:07:11,720
Workflow level orchestration means

215
00:07:11,720 --> 00:07:14,000
you are using logic apps or power automate.

216
00:07:14,000 --> 00:07:15,840
You define processes visually

217
00:07:15,840 --> 00:07:18,440
and use pre-built connectors to get things moving.

218
00:07:18,440 --> 00:07:21,080
You're thinking in terms of steps and conditional branches,

219
00:07:21,080 --> 00:07:23,000
you drop a trigger, add your actions,

220
00:07:23,000 --> 00:07:24,440
and wire everything together

221
00:07:24,440 --> 00:07:26,320
without writing a single line of code.

222
00:07:26,320 --> 00:07:28,880
Compute level orchestration means

223
00:07:28,880 --> 00:07:31,360
you are using Azure Functions or Durable Functions.

224
00:07:31,360 --> 00:07:33,720
You're writing code and thinking in terms of algorithms

225
00:07:33,720 --> 00:07:34,760
and state machines.

226
00:07:34,760 --> 00:07:36,240
You are optimizing for performance

227
00:07:36,240 --> 00:07:38,560
and controlling your costs at a very granular level.

228
00:07:38,560 --> 00:07:39,800
These aren't equivalent choices.

229
00:07:39,800 --> 00:07:42,440
They are different answers to different problems.

230
00:07:42,440 --> 00:07:44,160
And organizations frequently choose wrong

231
00:07:44,160 --> 00:07:46,000
because they don't understand the distinction.

232
00:07:46,000 --> 00:07:48,320
If your automation is mostly about connecting systems,

233
00:07:48,320 --> 00:07:49,920
reading from one transforming data

234
00:07:49,920 --> 00:07:52,400
and writing to another, workflow level orchestration

235
00:07:52,400 --> 00:07:54,440
is faster to set up.

236
00:07:54,440 --> 00:07:56,040
A logic app that reads from SharePoint

237
00:07:56,040 --> 00:07:58,200
and writes to Dataverse is straightforward

238
00:07:58,200 --> 00:07:59,400
because you don't write code.

239
00:07:59,400 --> 00:08:00,680
You just wire connectors.

240
00:08:00,680 --> 00:08:02,120
A function that does the same thing

241
00:08:02,120 --> 00:08:05,040
requires actual development, testing, and deployment cycles.

242
00:08:05,040 --> 00:08:07,360
But if your automation is about computation,

243
00:08:07,360 --> 00:08:10,080
complex business logic or high volume processing,

244
00:08:10,080 --> 00:08:12,400
compute level orchestration is more cost effective.

245
00:08:12,400 --> 00:08:13,720
You aren't paying for every step.

246
00:08:13,720 --> 00:08:15,800
You're paying for the actual execution time.

247
00:08:15,800 --> 00:08:17,760
But here is what most organizations miss.

248
00:08:17,760 --> 00:08:19,000
The choice isn't binary.

249
00:08:19,000 --> 00:08:22,080
The winning architecture in 2026 uses both.

250
00:08:22,080 --> 00:08:23,640
You use logic apps for orchestration

251
00:08:23,640 --> 00:08:25,440
and functions for computation.

252
00:08:25,440 --> 00:08:26,960
The logic app defines the workflow

253
00:08:26,960 --> 00:08:28,560
and acts as the conductor.

254
00:08:28,560 --> 00:08:30,520
While the function handles the heavy lifting

255
00:08:30,520 --> 00:08:31,520
like an instrument,

256
00:08:31,520 --> 00:08:33,320
this hybrid approach gives you the maintainability

257
00:08:33,320 --> 00:08:35,480
of visual workflows with the power of custom code.

258
00:08:35,480 --> 00:08:37,200
The cost implications are significant.

259
00:08:37,200 --> 00:08:40,360
A logic app that does heavy computation is expensive

260
00:08:40,360 --> 00:08:42,040
because you're paying for every action,

261
00:08:42,040 --> 00:08:44,280
including every loop and every retry.

262
00:08:44,280 --> 00:08:45,960
Each iteration costs you money.

263
00:08:45,960 --> 00:08:47,960
A function doing that same work is cheap

264
00:08:47,960 --> 00:08:50,240
because you only pay for the actual compute time.

265
00:08:50,240 --> 00:08:52,080
If you are processing a million records,

266
00:08:52,080 --> 00:08:55,880
the difference between $5,000 and $500 is catastrophic.

267
00:08:55,880 --> 00:08:58,000
This is where the distinction between an algorithm

268
00:08:58,000 --> 00:08:59,920
and a process map becomes critical.

269
00:08:59,920 --> 00:09:01,280
If you're building a process map

270
00:09:01,280 --> 00:09:03,560
where each step is about rooting or transformation,

271
00:09:03,560 --> 00:09:05,160
logic apps are the right choice.

272
00:09:05,160 --> 00:09:06,480
You aren't doing complex math.

273
00:09:06,480 --> 00:09:07,440
You're orchestrating,

274
00:09:07,440 --> 00:09:08,800
but if you're building an algorithm

275
00:09:08,800 --> 00:09:10,840
that requires loops and heavy logic functions

276
00:09:10,840 --> 00:09:13,960
are the way to go, you're computing, not orchestrating.

277
00:09:13,960 --> 00:09:15,680
Most organizations get this backwards.

278
00:09:15,680 --> 00:09:17,880
They build complex algorithms in logic apps

279
00:09:17,880 --> 00:09:19,160
because that is what they know

280
00:09:19,160 --> 00:09:20,680
and then they are shocked by the bill.

281
00:09:20,680 --> 00:09:22,720
They see the cost and realize they should have written

282
00:09:22,720 --> 00:09:23,800
a function instead.

283
00:09:23,800 --> 00:09:25,160
The diagnostic is simple.

284
00:09:25,160 --> 00:09:27,200
Understand what you are actually building.

285
00:09:27,200 --> 00:09:28,600
Are you orchestrating a workflow

286
00:09:28,600 --> 00:09:29,960
or are you computing a result?

287
00:09:29,960 --> 00:09:31,640
The answer changes everything

288
00:09:31,640 --> 00:09:33,760
about how you architect the solution.

289
00:09:33,760 --> 00:09:36,080
The infrastructure choice is between workflow level

290
00:09:36,080 --> 00:09:37,920
and compute level orchestration.

291
00:09:37,920 --> 00:09:39,880
Workflow level is faster to implement

292
00:09:39,880 --> 00:09:41,600
but gets expensive at scale.

293
00:09:41,600 --> 00:09:43,440
While compute level requires more code,

294
00:09:43,440 --> 00:09:45,560
but saves money on actual computation.

295
00:09:45,560 --> 00:09:48,240
The winning 2026 architecture uses both.

296
00:09:48,240 --> 00:09:50,360
This hybrid approach is now the standard practice.

297
00:09:50,360 --> 00:09:52,160
Organizations that understand this distinction

298
00:09:52,160 --> 00:09:54,400
are building systems at scale efficiently.

299
00:09:54,400 --> 00:09:56,800
While those that don't are just accumulating technical debt

300
00:09:56,800 --> 00:09:58,600
with every new automation they add,

301
00:09:58,600 --> 00:10:00,680
choosing the right infrastructure is half the battle.

302
00:10:00,680 --> 00:10:02,320
The other half is making sure it's reliable.

303
00:10:02,320 --> 00:10:04,280
That means understanding how things fail

304
00:10:04,280 --> 00:10:05,520
and building for recovery.

305
00:10:06,160 --> 00:10:07,680
The reliability problem.

306
00:10:07,680 --> 00:10:09,880
Why most integrations fail silently?

307
00:10:09,880 --> 00:10:11,400
Here is a scenario that plays out

308
00:10:11,400 --> 00:10:13,240
in enterprise environments every single day.

309
00:10:13,240 --> 00:10:16,120
Almost nobody notices it until the damage is already done.

310
00:10:16,120 --> 00:10:17,160
You build an integration.

311
00:10:17,160 --> 00:10:19,000
It works perfectly for six months.

312
00:10:19,000 --> 00:10:20,640
Everything runs smoothly.

313
00:10:20,640 --> 00:10:23,160
Then one day, without a single warning or notification,

314
00:10:23,160 --> 00:10:24,200
it just stops.

315
00:10:24,200 --> 00:10:25,240
It isn't an obvious crash.

316
00:10:25,240 --> 00:10:27,400
There is no error message for anyone to see.

317
00:10:27,400 --> 00:10:28,440
It just goes quiet.

318
00:10:28,440 --> 00:10:30,680
Three weeks pass by, nobody's looking at the output.

319
00:10:30,680 --> 00:10:32,280
Then someone finally realizes

320
00:10:32,280 --> 00:10:34,880
that critical data hasn't moved in 21 days.

321
00:10:34,880 --> 00:10:36,880
This happens constantly because most integrations

322
00:10:36,880 --> 00:10:38,560
are built without a reconciliation layer.

323
00:10:38,560 --> 00:10:39,560
There is no verification.

324
00:10:39,560 --> 00:10:41,640
There is no source of truth to check against.

325
00:10:41,640 --> 00:10:43,160
The assumption baked into these systems

326
00:10:43,160 --> 00:10:46,560
is that if something fails, someone will notice.

327
00:10:46,560 --> 00:10:49,040
In reality, nobody notices.

328
00:10:49,040 --> 00:10:51,760
A web hook that stops being delivered

329
00:10:51,760 --> 00:10:53,360
doesn't send you an error message.

330
00:10:53,360 --> 00:10:55,240
A scheduled task that gets disabled

331
00:10:55,240 --> 00:10:58,120
doesn't trigger an alert that anyone is actually monitoring.

332
00:10:58,120 --> 00:11:00,280
A connection that times out doesn't log an event

333
00:11:00,280 --> 00:11:02,680
in a place where the right person will ever see it.

334
00:11:02,680 --> 00:11:05,160
The only way to actually know if an integration is working

335
00:11:05,160 --> 00:11:07,800
is to verify its output against something authoritative.

336
00:11:07,800 --> 00:11:08,800
You have to check the work.

337
00:11:08,800 --> 00:11:10,360
You cannot just assume it happened.

338
00:11:10,360 --> 00:11:11,760
This is what reconciliation does.

339
00:11:11,760 --> 00:11:12,960
It isn't about optimization.

340
00:11:12,960 --> 00:11:14,240
It isn't about redundancy.

341
00:11:14,240 --> 00:11:17,440
It is failure detection built into the architecture itself.

342
00:11:17,440 --> 00:11:19,360
Here is how this looks in practice.

343
00:11:19,360 --> 00:11:20,600
You create a graph subscription

344
00:11:20,600 --> 00:11:22,800
that watches for new files in a SharePoint library.

345
00:11:22,800 --> 00:11:24,920
When a file is created, the web hook triggers

346
00:11:24,920 --> 00:11:26,400
a function that processes it.

347
00:11:26,400 --> 00:11:28,720
The web hook is fast, the response is immediate.

348
00:11:28,720 --> 00:11:30,200
The system processes the file.

349
00:11:30,200 --> 00:11:32,160
Everything works except web hooks fail.

350
00:11:32,160 --> 00:11:34,680
They get missed, they expire, they time out silently.

351
00:11:34,680 --> 00:11:36,080
So alongside that web hook,

352
00:11:36,080 --> 00:11:38,480
you schedule a Delta query to run once a day.

353
00:11:38,480 --> 00:11:41,240
The Delta query asks SharePoint directly.

354
00:11:41,240 --> 00:11:43,560
What files have been created since my last check?

355
00:11:43,560 --> 00:11:45,080
If the web hook missed something,

356
00:11:45,080 --> 00:11:46,440
the Delta query catches it.

357
00:11:46,440 --> 00:11:48,240
If the web hook failed entirely,

358
00:11:48,240 --> 00:11:49,800
the Delta query is your backup.

359
00:11:49,800 --> 00:11:51,360
If both failed at the same time,

360
00:11:51,360 --> 00:11:54,000
you would know because the reconciliation would report a gap.

361
00:11:54,000 --> 00:11:56,600
The cost of running a daily Delta query is negligible.

362
00:11:56,600 --> 00:11:58,480
You are talking about a few dollars per month,

363
00:11:58,480 --> 00:12:00,320
but the cost of discovering three weeks later

364
00:12:00,320 --> 00:12:02,120
that critical business data hasn't moved

365
00:12:02,120 --> 00:12:03,040
is catastrophic.

366
00:12:03,040 --> 00:12:05,120
Or does get delayed, compliance gets missed,

367
00:12:05,120 --> 00:12:06,320
revenue gets lost.

368
00:12:06,320 --> 00:12:08,600
The math isn't even close.

369
00:12:08,600 --> 00:12:10,280
Yet most organizations don't do this.

370
00:12:10,280 --> 00:12:12,560
They build the web hook, they test it in staging,

371
00:12:12,560 --> 00:12:13,640
they deploy it to production,

372
00:12:13,640 --> 00:12:15,120
they assume it will keep working,

373
00:12:15,120 --> 00:12:16,720
then they are shocked when it doesn't.

374
00:12:16,720 --> 00:12:19,440
The diagnostic question for your organization is straightforward.

375
00:12:19,440 --> 00:12:21,320
For each of your critical integrations,

376
00:12:21,320 --> 00:12:22,840
do you have a reconciliation mechanism,

377
00:12:22,840 --> 00:12:24,240
not a HopetWorks plan,

378
00:12:24,240 --> 00:12:26,800
an actual mechanism that verifies the work happened?

379
00:12:26,800 --> 00:12:29,200
If the answer is no, your integrations are fragile.

380
00:12:29,200 --> 00:12:31,640
The shift from HopetWorks to Verify it works,

381
00:12:31,640 --> 00:12:33,800
is the shift from scripts to platforms.

382
00:12:33,800 --> 00:12:35,240
Scripts assume success.

383
00:12:35,240 --> 00:12:36,480
They are built with the expectation

384
00:12:36,480 --> 00:12:38,440
that everything will function as designed.

385
00:12:38,440 --> 00:12:40,360
Platforms are built with the opposite assumption,

386
00:12:40,360 --> 00:12:41,440
things will fail,

387
00:12:41,440 --> 00:12:43,560
and you need to detect and recover from those failures.

388
00:12:43,560 --> 00:12:45,840
This architectural difference is why organizations

389
00:12:45,840 --> 00:12:49,400
with platforms are more reliable than organizations with scripts.

390
00:12:49,400 --> 00:12:51,200
It isn't because their code is better written,

391
00:12:51,200 --> 00:12:53,440
it isn't because their developers are smarter.

392
00:12:53,440 --> 00:12:55,440
It's because their systems account for failure

393
00:12:55,440 --> 00:12:57,320
as a first class design requirement.

394
00:12:57,320 --> 00:12:58,840
Silent failures are expensive.

395
00:12:58,840 --> 00:13:00,440
The organizations that have figured this out

396
00:13:00,440 --> 00:13:03,800
have built infrastructure that makes silent failures impossible.

397
00:13:03,800 --> 00:13:06,560
The identity, heartbeat, why managed identities

398
00:13:06,560 --> 00:13:07,800
are non-negotiable.

399
00:13:07,800 --> 00:13:09,440
Every automation system has a pulse,

400
00:13:09,440 --> 00:13:11,960
it is the rhythm at which credentials refresh.

401
00:13:11,960 --> 00:13:13,200
Permissions get verified,

402
00:13:13,200 --> 00:13:15,200
and the system confirms it still has the ability

403
00:13:15,200 --> 00:13:16,760
to do what it was built to do.

404
00:13:16,760 --> 00:13:20,080
In 2026, that pulse is approximately 45 days.

405
00:13:20,080 --> 00:13:22,960
That is the rotation cycle for Azure Managed Identities.

406
00:13:22,960 --> 00:13:25,680
Here's what that means in practice, every 45 days.

407
00:13:25,680 --> 00:13:27,840
Azure automatically creates a new credential

408
00:13:27,840 --> 00:13:30,000
for your managed identity and revokes the old one.

409
00:13:30,000 --> 00:13:31,800
The system doesn't ask for permission first,

410
00:13:31,800 --> 00:13:33,840
it doesn't send you a notification, it doesn't wait,

411
00:13:33,840 --> 00:13:34,680
it just does it.

412
00:13:34,680 --> 00:13:37,080
And if your automation isn't designed to handle that rotation,

413
00:13:37,080 --> 00:13:39,920
it will break silently, this isn't a bug, this is a feature.

414
00:13:39,920 --> 00:13:42,160
Static credentials are a security liability

415
00:13:42,160 --> 00:13:44,280
if you have a credential that never changes.

416
00:13:44,280 --> 00:13:45,880
And someone steals it that compromise

417
00:13:45,880 --> 00:13:47,640
credential remains valid forever.

418
00:13:47,640 --> 00:13:48,920
An attacker has permanent access

419
00:13:48,920 --> 00:13:51,360
and if you have a credential that rotates every 45 days,

420
00:13:51,360 --> 00:13:53,200
a stolen credential has an expiration window,

421
00:13:53,200 --> 00:13:55,720
the exposure is bounded, this is security by design,

422
00:13:55,720 --> 00:13:56,800
not by hope.

423
00:13:56,800 --> 00:13:58,920
The operational consequence is significant.

424
00:13:58,920 --> 00:14:01,200
Your automation cannot store credentials in code,

425
00:14:01,200 --> 00:14:03,160
it cannot keep them in configuration files,

426
00:14:03,160 --> 00:14:06,000
it cannot persist them anywhere that requires manual intervention

427
00:14:06,000 --> 00:14:09,480
to update because if the credential rotates automatically,

428
00:14:09,480 --> 00:14:13,600
but your system is still using the old one, the connection dies.

429
00:14:13,600 --> 00:14:16,000
This is where managed identities become essential.

430
00:14:16,000 --> 00:14:18,960
A managed identity is an identity managed by Azure itself.

431
00:14:18,960 --> 00:14:21,000
You don't create the credential, you don't rotate it,

432
00:14:21,000 --> 00:14:23,760
you don't delete it, as your handles the entire life cycle,

433
00:14:23,760 --> 00:14:25,440
your code simply uses it.

434
00:14:25,440 --> 00:14:27,040
The pattern is straightforward,

435
00:14:27,040 --> 00:14:30,280
your functional logic app authenticates with a managed identity.

436
00:14:30,280 --> 00:14:33,440
That identity has the specific permissions it needs to do its work

437
00:14:33,440 --> 00:14:34,760
when the credential rotates,

438
00:14:34,760 --> 00:14:36,720
the system automatically uses the new one,

439
00:14:36,720 --> 00:14:39,320
your code doesn't know rotation happened, it doesn't care.

440
00:14:39,320 --> 00:14:40,600
It keeps working.

441
00:14:40,600 --> 00:14:43,520
But most organizations miss the mental shift this requires.

442
00:14:43,520 --> 00:14:44,880
With traditional service accounts,

443
00:14:44,880 --> 00:14:46,840
you create an account, assign permissions,

444
00:14:46,840 --> 00:14:48,480
and then manage it for years.

445
00:14:48,480 --> 00:14:50,800
The account stays the same, the permissions stay the same,

446
00:14:50,800 --> 00:14:53,160
you control it entirely, with managed identities,

447
00:14:53,160 --> 00:14:55,600
you create the identity, assign its permissions,

448
00:14:55,600 --> 00:14:58,640
and then as your takes over, you don't control the credentials anymore,

449
00:14:58,640 --> 00:14:59,720
the system does.

450
00:14:59,720 --> 00:15:01,680
This feels like losing control to organizations

451
00:15:01,680 --> 00:15:03,440
are custom to managing infrastructure.

452
00:15:03,440 --> 00:15:05,040
It is actually the opposite.

453
00:15:05,040 --> 00:15:07,720
You are trading away the burden of credential management

454
00:15:07,720 --> 00:15:09,240
for genuine reliability.

455
00:15:09,240 --> 00:15:12,120
The system handles the complexity that humans invariably mess up.

456
00:15:12,120 --> 00:15:14,360
Rotation schedules, secure credential storage,

457
00:15:14,360 --> 00:15:16,520
renewal before expiration.

458
00:15:16,520 --> 00:15:19,280
The trade-off is precision, with a service account.

459
00:15:19,280 --> 00:15:20,600
You might assign it broad permissions

460
00:15:20,600 --> 00:15:22,160
because you are managing it anyway.

461
00:15:22,160 --> 00:15:25,240
The risk feels acceptable since you know what the account can access.

462
00:15:25,240 --> 00:15:29,120
With a managed identity, you have to assign exactly the permissions it needs,

463
00:15:29,120 --> 00:15:31,680
no extras, no it might need this later.

464
00:15:31,680 --> 00:15:33,320
Because you aren't managing it anymore.

465
00:15:33,320 --> 00:15:35,760
The system is, and the system enforces boundaries.

466
00:15:35,760 --> 00:15:38,720
This constraint forces a discipline most organizations lack.

467
00:15:38,720 --> 00:15:40,640
It forces you to think about least privilege.

468
00:15:40,640 --> 00:15:44,000
It forces you to ask exactly what each automation is allowed to do.

469
00:15:44,000 --> 00:15:44,880
Nothing more.

470
00:15:44,880 --> 00:15:47,760
This security discipline doesn't come from policy or training.

471
00:15:47,760 --> 00:15:49,360
It comes from the architecture itself.

472
00:15:49,360 --> 00:15:50,800
The diagnostic is direct.

473
00:15:50,800 --> 00:15:54,240
Do any of your automations use stored credentials or connection strings?

474
00:15:54,240 --> 00:15:56,880
Do they read passwords from configuration files or key vault?

475
00:15:56,880 --> 00:15:58,040
If the answer is yes.

476
00:15:58,040 --> 00:15:59,680
Those automations are fragile.

477
00:15:59,680 --> 00:16:02,720
They are built on the assumption that credentials stay static forever.

478
00:16:02,720 --> 00:16:04,480
They are not ready for 2026.

479
00:16:04,480 --> 00:16:06,280
The fundamental shift here is moving from

480
00:16:06,280 --> 00:16:09,360
we manage credentials to the system manages credentials.

481
00:16:09,360 --> 00:16:11,360
The first model creates operational overhead.

482
00:16:11,360 --> 00:16:13,200
Every rotation is a manual event.

483
00:16:13,200 --> 00:16:16,240
Every compromise requires investigation and a credential reset.

484
00:16:16,240 --> 00:16:19,120
The second model distributes that overhead to infrastructure.

485
00:16:19,120 --> 00:16:21,400
It handles it automatically and consistently.

486
00:16:21,400 --> 00:16:23,800
Organizations making this transition discover something.

487
00:16:23,800 --> 00:16:24,920
They aren't losing control.

488
00:16:24,920 --> 00:16:25,680
They are gaining it.

489
00:16:25,680 --> 00:16:27,520
The system becomes more reliable.

490
00:16:27,520 --> 00:16:30,400
Automations stay functional across credential rotations.

491
00:16:30,400 --> 00:16:33,600
Security posture improves because credentials change constantly.

492
00:16:33,600 --> 00:16:36,080
The only thing humans have to do differently is think more carefully

493
00:16:36,080 --> 00:16:38,480
about what permissions each automation actually needs.

494
00:16:38,480 --> 00:16:41,160
Credentials are just the entry point to the identity layer.

495
00:16:41,160 --> 00:16:44,640
The larger architecture question is how you govern who gets to create

496
00:16:44,640 --> 00:16:46,160
automations in the first place

497
00:16:46,160 --> 00:16:49,120
and what they are allowed to touch with those automations.

498
00:16:49,120 --> 00:16:52,160
Governance as infrastructure, the policy as code shift.

499
00:16:52,160 --> 00:16:56,000
Most organizations fail to scale automation because of one uncomfortable truth.

500
00:16:56,000 --> 00:16:57,720
They think governance is a document.

501
00:16:57,720 --> 00:17:01,560
They treat it like a list of rules that someone writes down and everyone eventually ignores.

502
00:17:01,560 --> 00:17:04,360
But in reality, governance is infrastructure.

503
00:17:04,360 --> 00:17:07,200
By 2026, the companies with governance that actually works

504
00:17:07,200 --> 00:17:09,000
are the ones that started treating it as code.

505
00:17:09,000 --> 00:17:12,320
They moved away from policy documents and review committees that just check boxes.

506
00:17:12,320 --> 00:17:14,920
Instead, they build actual infrastructure that makes certain mistakes

507
00:17:14,920 --> 00:17:16,720
impossible to commit in the first place.

508
00:17:16,720 --> 00:17:18,480
This might sound like more bureaucracy.

509
00:17:18,480 --> 00:17:19,320
But here's the problem.

510
00:17:19,320 --> 00:17:20,400
It's actually the opposite.

511
00:17:20,400 --> 00:17:23,760
When you want to build a new automation, you don't fill out a form and wait for a committee

512
00:17:23,760 --> 00:17:24,760
to give you the green light.

513
00:17:24,760 --> 00:17:27,720
You can't even try to break the rules because the system won't let you.

514
00:17:27,720 --> 00:17:30,600
The guardrails are baked into the technical environment itself,

515
00:17:30,600 --> 00:17:33,320
making the gates technical rather than administrative.

516
00:17:33,320 --> 00:17:37,360
Suppose you have a policy stating that no automation can use a service account

517
00:17:37,360 --> 00:17:39,000
with access to production data.

518
00:17:39,000 --> 00:17:42,560
In the old model, this was just a sentence in a PDF that a tired employee

519
00:17:42,560 --> 00:17:44,840
had to manually check for every single project.

520
00:17:44,840 --> 00:17:48,240
Eventually, that person misses something, automation slipped through

521
00:17:48,240 --> 00:17:50,160
and the rule becomes a total fiction.

522
00:17:50,160 --> 00:17:53,840
In the new model, the system simply blocks you from creating that automation.

523
00:17:53,840 --> 00:17:57,200
If you try to assign the wrong permissions, the system rejects it immediately.

524
00:17:57,200 --> 00:18:01,240
It isn't possible to bypass the rule because there is no workaround or exception process.

525
00:18:01,240 --> 00:18:04,400
The architecture enforces the rule so people don't have to.

526
00:18:04,400 --> 00:18:05,680
This sounds restrictive.

527
00:18:05,680 --> 00:18:08,080
But in practice, it's liberating.

528
00:18:08,080 --> 00:18:10,760
Once those guardrails are active, you can move at high speed

529
00:18:10,760 --> 00:18:13,640
without asking for permission or waiting for a compliance meeting.

530
00:18:13,640 --> 00:18:16,520
You can build whatever you want within the bounds the system allows,

531
00:18:16,520 --> 00:18:19,320
knowing it's compliant because the system literally won't let you

532
00:18:19,320 --> 00:18:20,720
build it any other way.

533
00:18:20,720 --> 00:18:24,160
This is the shift from governance as a constraint to governance as enablement.

534
00:18:24,160 --> 00:18:25,720
The guardrails don't slow you down.

535
00:18:25,720 --> 00:18:28,640
They let you move without friction because you know you're always safe.

536
00:18:28,640 --> 00:18:31,640
In a real world setup, you define these policies as code using tools

537
00:18:31,640 --> 00:18:36,040
like Azure Policy for Infrastructure or EntraID Conditional Access for Identity.

538
00:18:36,040 --> 00:18:39,520
You might use PerView for data boundaries, but the specific tool matters less

539
00:18:39,520 --> 00:18:41,560
than the fact that the system is doing the enforcing.

540
00:18:41,560 --> 00:18:45,080
For example, a policy might require a data owner to approve any

541
00:18:45,080 --> 00:18:47,320
automation accessing customer info.

542
00:18:47,320 --> 00:18:49,760
In the old model, a human checks for that approval.

543
00:18:49,760 --> 00:18:51,840
In the new model, the system won't trigger the automation

544
00:18:51,840 --> 00:18:55,040
until the automated workflow notifies the owner and they click a button.

545
00:18:55,040 --> 00:18:56,240
This isn't a manual review.

546
00:18:56,240 --> 00:18:58,840
It's automated governance.

547
00:18:58,840 --> 00:19:00,280
Setting this up is difficult.

548
00:19:00,280 --> 00:19:03,120
It forces you to think deeply about which policies you actually need

549
00:19:03,120 --> 00:19:05,520
versus what just sounds nice to have.

550
00:19:05,520 --> 00:19:08,280
You have to build the enforcement layer and change how your entire team

551
00:19:08,280 --> 00:19:09,600
thinks about the work.

552
00:19:09,600 --> 00:19:11,840
But the payoff is massive once it's running.

553
00:19:11,840 --> 00:19:14,880
Your automation becomes trustworthy because the system guarantees it

554
00:19:14,880 --> 00:19:17,800
and your security team can finally sleep because certain mistakes

555
00:19:17,800 --> 00:19:19,400
are now physically impossible.

556
00:19:19,400 --> 00:19:23,360
The organization's winning in 2026 didn't get faster by having fewer rules.

557
00:19:23,360 --> 00:19:25,320
They got faster because their rules are automated.

558
00:19:25,320 --> 00:19:27,760
The system handles the compliance so the people can handle the

559
00:19:27,760 --> 00:19:29,800
innovation governance is the foundation.

560
00:19:29,800 --> 00:19:33,040
But the real power shows up when you layer orchestration and reliability

561
00:19:33,040 --> 00:19:35,960
on top of it to create a platform that scales without collapsing.

562
00:19:35,960 --> 00:19:38,560
The agent layer from automation to autonomous systems.

563
00:19:38,560 --> 00:19:41,200
By 2026, the conversation has fundamentally shifted away

564
00:19:41,200 --> 00:19:42,720
from how we automate a task.

565
00:19:42,720 --> 00:19:44,520
Now the only question that matters is,

566
00:19:44,520 --> 00:19:46,000
how do we make the system autonomous?

567
00:19:46,000 --> 00:19:49,280
The difference is profound and it changes everything about how you design

568
00:19:49,280 --> 00:19:50,080
your systems.

569
00:19:50,080 --> 00:19:53,080
Automation means you are telling the system exactly what to do.

570
00:19:53,080 --> 00:19:56,320
You script out every step telling it to read a file, process the data

571
00:19:56,320 --> 00:19:57,400
and write a report.

572
00:19:57,400 --> 00:20:00,480
It executes those steps in order and does exactly what it's told.

573
00:20:00,480 --> 00:20:01,720
Nothing more.

574
00:20:01,720 --> 00:20:05,840
Autonomy means the system decides what to do based on the context it sees.

575
00:20:05,840 --> 00:20:08,920
It observes the situation, reasons through the problem and takes action

576
00:20:08,920 --> 00:20:11,440
without waiting for a human to prompt the next step.

577
00:20:11,440 --> 00:20:13,880
The system becomes an agent that acts on your behalf.

578
00:20:13,880 --> 00:20:15,560
This is where real agents come in.

579
00:20:15,560 --> 00:20:19,280
I'm not talking about fancy names for scheduled tasks or complex scripts.

580
00:20:19,280 --> 00:20:22,960
I mean systems that can understand a situation and decide on a course of action

581
00:20:22,960 --> 00:20:24,320
entirely on their own.

582
00:20:24,320 --> 00:20:27,080
The infrastructure making this possible is agent 365,

583
00:20:27,080 --> 00:20:29,680
which hit general availability in May of 2026.

584
00:20:29,680 --> 00:20:34,960
Agent 365 acts as the control plane for agents across the entire Microsoft ecosystem.

585
00:20:34,960 --> 00:20:37,320
It's where you register them, manage their permissions

586
00:20:37,320 --> 00:20:39,520
and monitor their behavior to keep them under control.

587
00:20:39,520 --> 00:20:41,080
But here's the part most people miss.

588
00:20:41,080 --> 00:20:43,040
Agent 365 isn't the agent itself.

589
00:20:43,040 --> 00:20:46,240
It is the infrastructure that makes those agents safe to use.

590
00:20:46,240 --> 00:20:49,040
Think of it as the operating system for autonomous systems.

591
00:20:49,040 --> 00:20:51,440
An agent without governance is a massive liability.

592
00:20:51,440 --> 00:20:54,120
It's a black box that does things without anyone knowing why,

593
00:20:54,120 --> 00:20:56,160
making it impossible to audit or trace.

594
00:20:56,160 --> 00:20:59,320
But an agent with governance is different because the system knows exactly

595
00:20:59,320 --> 00:21:00,960
what it did and why it did it.

596
00:21:00,960 --> 00:21:05,040
In practice, these agents operate with specific identities and very tight permissions.

597
00:21:05,040 --> 00:21:08,000
An agent designed to process orders cannot delete customer records

598
00:21:08,000 --> 00:21:10,960
because the system enforces those boundaries at the architectural level.

599
00:21:10,960 --> 00:21:13,600
This is like managed identities for your automations,

600
00:21:13,600 --> 00:21:16,680
but you're managing the entire life cycle over thinking system.

601
00:21:16,680 --> 00:21:20,600
By 2026, the winning organizations are treating agents as first-class citizens

602
00:21:20,600 --> 00:21:21,920
in their infrastructure.

603
00:21:21,920 --> 00:21:23,360
They aren't experiments or toys.

604
00:21:23,360 --> 00:21:26,760
They are actual workers doing critical high stakes work every single day.

605
00:21:26,760 --> 00:21:29,680
This requires a total shift in your mental model.

606
00:21:29,680 --> 00:21:32,880
You have to anticipate what an agent could do wrong, build safeguards

607
00:21:32,880 --> 00:21:35,240
and monitor its behavior every second it's running.

608
00:21:35,240 --> 00:21:37,760
You need a plan to shut it down instantly if things go sideways,

609
00:21:37,760 --> 00:21:40,920
planning for agent failure the same way you plan for a server going down.

610
00:21:40,920 --> 00:21:44,320
Once that infrastructure is solid, the productivity gains are staggering.

611
00:21:44,320 --> 00:21:47,400
An agent that can process an order, check inventory and root fulfillment

612
00:21:47,400 --> 00:21:51,000
without a human involved is worth millions in operational efficiency.

613
00:21:51,000 --> 00:21:54,320
The shift from automation to autonomy is really a shift from tools to workers.

614
00:21:54,320 --> 00:21:56,520
You aren't building a script that performs a task.

615
00:21:56,520 --> 00:21:59,320
You are building a system that works, observes and reports.

616
00:21:59,320 --> 00:22:02,880
Agents are the new frontier, but before you can deploy them safely,

617
00:22:02,880 --> 00:22:06,360
you need a foundation of orchestration and reliability that actually works.

618
00:22:06,360 --> 00:22:09,440
Let's look at what that foundation looks like in a real organization

619
00:22:09,440 --> 00:22:12,560
dealing with real business pressure, the architecture and practice,

620
00:22:12,560 --> 00:22:13,920
a real world blueprint.

621
00:22:13,920 --> 00:22:16,760
Let's take these pieces and look at how they actually work together

622
00:22:16,760 --> 00:22:19,080
in a system that's running in production right now.

623
00:22:19,080 --> 00:22:21,240
Most organizations face a common problem

624
00:22:21,240 --> 00:22:24,080
where customer orders arrive from too many different places.

625
00:22:24,080 --> 00:22:27,080
Some come through the website, others through a partner API

626
00:22:27,080 --> 00:22:29,320
and some even arrive via email.

627
00:22:29,320 --> 00:22:32,120
You need to validate every single one against your inventory,

628
00:22:32,120 --> 00:22:35,400
root it to the right fulfillment center and update the ERP system.

629
00:22:35,400 --> 00:22:37,760
Usually this is handled by four different scripts

630
00:22:37,760 --> 00:22:41,240
running on four different schedules owned by different people and failing independently.

631
00:22:41,240 --> 00:22:42,240
But here's the problem.

632
00:22:42,240 --> 00:22:44,360
When one script breaks, the whole chain stops

633
00:22:44,360 --> 00:22:46,720
and nobody knows why until a customer complains.

634
00:22:46,720 --> 00:22:49,480
Here is how you architect this using the platform model.

635
00:22:49,480 --> 00:22:53,120
First, you set up graph subscriptions to watch your primary data sources.

636
00:22:53,120 --> 00:22:56,080
When a new order hits the CRM, the subscription fires.

637
00:22:56,080 --> 00:22:58,560
When one arrives in the web API or the email system,

638
00:22:58,560 --> 00:22:59,840
other subscriptions fire.

639
00:22:59,840 --> 00:23:01,920
These subscriptions aren't doing the heavy lifting.

640
00:23:01,920 --> 00:23:02,760
They are just signals.

641
00:23:02,760 --> 00:23:05,000
They tell the orchestration layer that something happened.

642
00:23:05,000 --> 00:23:07,200
When a subscription fires, it triggers a logic app.

643
00:23:07,200 --> 00:23:08,880
The logic app is your conductor.

644
00:23:08,880 --> 00:23:12,320
It acts as the process map that orchestrates the entire workflow.

645
00:23:12,320 --> 00:23:16,160
It reads the incoming order, extracts the customer info and formats the data

646
00:23:16,160 --> 00:23:17,880
so it looks the same every time.

647
00:23:17,880 --> 00:23:19,000
Then it calls a function.

648
00:23:19,000 --> 00:23:20,840
That function is where the complexity lives.

649
00:23:20,840 --> 00:23:23,200
It validates the order against inventory rules

650
00:23:23,200 --> 00:23:26,080
and checks stock levels across different warehouses.

651
00:23:26,080 --> 00:23:29,280
It handles the messy edge cases and the pure computation.

652
00:23:29,280 --> 00:23:31,200
The logic app doesn't care how the math works.

653
00:23:31,200 --> 00:23:33,440
It just knows that when it sends an order to this function,

654
00:23:33,440 --> 00:23:35,280
it gets back a result or an error.

655
00:23:35,280 --> 00:23:38,000
If the validation passes, the logic app roots the order

656
00:23:38,000 --> 00:23:40,480
to the right fulfillment center and updates the ERP.

657
00:23:40,480 --> 00:23:43,440
It sends the customer a confirmation and logs the status in the CRM.

658
00:23:43,440 --> 00:23:46,960
Every single one of these steps is protected by a managed identity.

659
00:23:46,960 --> 00:23:49,440
This identity can read orders and write instructions,

660
00:23:49,440 --> 00:23:52,080
but it can't delete data or touch payment info.

661
00:23:52,080 --> 00:23:55,360
The system enforces these boundaries because you define them during setup,

662
00:23:55,360 --> 00:23:57,520
making them permanent and unyielding.

663
00:23:57,520 --> 00:23:59,040
But you don't stop at the subscription.

664
00:23:59,040 --> 00:24:01,120
You also schedule a daily delta query.

665
00:24:01,120 --> 00:24:04,880
It asks your systems what orders arrived that haven't been processed yet.

666
00:24:04,880 --> 00:24:08,240
If a subscription expired or a web hook failed while the logic app was down,

667
00:24:08,240 --> 00:24:09,680
the delta query finds the gap.

668
00:24:09,680 --> 00:24:12,800
It reprocesses any missed orders, so the business doesn't have holes.

669
00:24:12,800 --> 00:24:14,640
The system is resilient by design.

670
00:24:14,640 --> 00:24:16,320
All of this is governed by policy.

671
00:24:16,320 --> 00:24:19,440
You can't create a logic app that bypasses the validation function

672
00:24:19,440 --> 00:24:21,360
because the infrastructure prevents it.

673
00:24:21,360 --> 00:24:24,160
You can't give the orchestration identity permissions it doesn't need

674
00:24:24,160 --> 00:24:26,720
because the governance policies will reject the assignment.

675
00:24:26,720 --> 00:24:28,640
The system enforces the rules you set.

676
00:24:28,640 --> 00:24:30,080
You've also set up monitoring.

677
00:24:30,080 --> 00:24:32,640
You're watching the subscriptions to confirm their delivering

678
00:24:32,640 --> 00:24:35,360
and checking the function to ensure its processing correctly.

679
00:24:35,360 --> 00:24:38,000
If any step fails, you get an alert immediately.

680
00:24:38,000 --> 00:24:40,560
It's not a silent failure discovered three weeks later.

681
00:24:40,560 --> 00:24:42,000
It's an immediate notification.

682
00:24:42,000 --> 00:24:44,320
Now, look at what happens when things change.

683
00:24:44,320 --> 00:24:45,440
Someone leaves the organization.

684
00:24:45,440 --> 00:24:47,440
The person who knew everything about these systems

685
00:24:47,440 --> 00:24:50,400
and built the original scripts years ago takes a job elsewhere.

686
00:24:50,400 --> 00:24:52,240
In the old model, that's a disaster.

687
00:24:52,240 --> 00:24:54,000
In this model, the system keeps working.

688
00:24:54,000 --> 00:24:55,200
It doesn't depend on a person.

689
00:24:55,200 --> 00:24:56,720
It depends on infrastructure.

690
00:24:56,720 --> 00:24:58,960
The business might change its fulfillment rules.

691
00:24:58,960 --> 00:25:01,040
If the validation logic needs to be different,

692
00:25:01,040 --> 00:25:02,400
you just change the function.

693
00:25:02,400 --> 00:25:04,080
You test it and deploy the new version.

694
00:25:04,080 --> 00:25:06,160
The logic app doesn't even know anything changed.

695
00:25:06,160 --> 00:25:07,600
It just keeps calling the function.

696
00:25:07,600 --> 00:25:09,200
The orchestration stays the same.

697
00:25:09,200 --> 00:25:10,960
You didn't have to rebuild the infrastructure.

698
00:25:10,960 --> 00:25:12,400
You only changed the code.

699
00:25:12,400 --> 00:25:14,640
If you need to add a new data source for orders,

700
00:25:14,640 --> 00:25:16,800
you just create a new subscription for that source.

701
00:25:16,800 --> 00:25:19,840
It triggers the same logic app and the same validation function.

702
00:25:19,840 --> 00:25:21,680
You aren't writing a new script from scratch.

703
00:25:21,680 --> 00:25:24,560
You're just plugging a new input into an existing fabric.

704
00:25:24,560 --> 00:25:27,680
This system is more complex than those four original scripts.

705
00:25:27,680 --> 00:25:30,320
It requires more infrastructure thinking at the start.

706
00:25:30,320 --> 00:25:32,080
But it survives things the scripts couldn't.

707
00:25:32,080 --> 00:25:33,360
It survives people leaving,

708
00:25:33,360 --> 00:25:35,360
requirements changing and systems breaking.

709
00:25:35,360 --> 00:25:37,360
This is the shift from scripts to platforms.

710
00:25:37,360 --> 00:25:40,160
The complexity is upfront, the payoff is continuous.

711
00:25:40,160 --> 00:25:42,800
The migration path from scripts to platforms,

712
00:25:42,800 --> 00:25:44,720
every organization that has built automations

713
00:25:44,720 --> 00:25:46,320
eventually asks the same question.

714
00:25:46,320 --> 00:25:48,480
They want to know how to get from where they are

715
00:25:48,480 --> 00:25:50,000
to where they need to be.

716
00:25:50,000 --> 00:25:51,920
The worst answer is to rebuild everything.

717
00:25:51,920 --> 00:25:54,000
That is the path that kills projects.

718
00:25:54,000 --> 00:25:56,080
It means shutting down your existing scripts

719
00:25:56,080 --> 00:25:58,080
and trying to start over from scratch.

720
00:25:58,080 --> 00:25:59,680
You'll discover midway through that,

721
00:25:59,680 --> 00:26:00,880
you missed something critical.

722
00:26:00,880 --> 00:26:02,160
The business depends on.

723
00:26:02,160 --> 00:26:04,560
Then you'll scramble to put the old system back into production

724
00:26:04,560 --> 00:26:06,480
while the new system sits there incomplete.

725
00:26:06,480 --> 00:26:08,720
The path that actually works is incremental.

726
00:26:08,720 --> 00:26:10,560
You keep your current system running

727
00:26:10,560 --> 00:26:12,720
while you build the platform alongside it.

728
00:26:12,720 --> 00:26:14,720
You migrate one automation at a time,

729
00:26:14,720 --> 00:26:17,040
learning from each move and improving the process.

730
00:26:17,040 --> 00:26:18,160
Then you do the next one.

731
00:26:18,160 --> 00:26:20,160
This takes longer than a big bang rewrite.

732
00:26:20,160 --> 00:26:22,640
But it's the only approach that doesn't break the business.

733
00:26:22,640 --> 00:26:24,000
Phase one is the assessment.

734
00:26:24,000 --> 00:26:26,480
You need to inventory every automation you have right now.

735
00:26:26,480 --> 00:26:28,400
You identify which ones are critical

736
00:26:28,400 --> 00:26:31,520
and which ones would tank the business if they stopped working.

737
00:26:31,520 --> 00:26:33,360
You need to understand how they fail

738
00:26:33,360 --> 00:26:35,840
and how often people have to step into fix them.

739
00:26:35,840 --> 00:26:37,760
You're measuring their actual reliability

740
00:26:37,760 --> 00:26:39,520
not just what people think is happening.

741
00:26:39,520 --> 00:26:41,360
This phase takes weeks, not months.

742
00:26:41,360 --> 00:26:42,880
You aren't looking for perfection here.

743
00:26:42,880 --> 00:26:44,560
You're just building a map of the landscape.

744
00:26:44,560 --> 00:26:47,280
You have to know what you have before you can move it.

745
00:26:47,280 --> 00:26:48,800
Phase two is foundation building.

746
00:26:48,800 --> 00:26:51,120
This is where you stop touching the automations themselves.

747
00:26:51,120 --> 00:26:53,120
Instead, you build the infrastructure around them.

748
00:26:53,120 --> 00:26:55,840
You set up managed identities for your critical systems

749
00:26:55,840 --> 00:26:57,840
and implement basic governance policies.

750
00:26:57,840 --> 00:27:00,880
You set up monitoring and alerting that actually watches the traffic.

751
00:27:00,880 --> 00:27:02,800
The automations stay exactly as they are.

752
00:27:02,800 --> 00:27:04,480
You aren't changing their behavior yet.

753
00:27:04,480 --> 00:27:06,720
You're just building the platform layer underneath.

754
00:27:06,720 --> 00:27:08,400
This phase also takes a few weeks.

755
00:27:08,400 --> 00:27:09,840
You aren't doing any migration yet.

756
00:27:09,840 --> 00:27:11,120
You're just preparing the ground.

757
00:27:11,120 --> 00:27:13,600
Phase three is where the actual migration happens.

758
00:27:13,600 --> 00:27:15,680
You take your most critical automation.

759
00:27:15,680 --> 00:27:17,680
The one that would hurt the most if it failed.

760
00:27:17,680 --> 00:27:19,680
And you rebuild it using the platform model.

761
00:27:19,680 --> 00:27:21,760
You create the subscriptions, build the logic app,

762
00:27:21,760 --> 00:27:22,880
and write the function.

763
00:27:22,880 --> 00:27:24,880
You test it thoroughly in a staging environment

764
00:27:24,880 --> 00:27:27,280
to verify it's more reliable than the original.

765
00:27:27,280 --> 00:27:28,560
Then you do something important.

766
00:27:28,560 --> 00:27:30,160
You run both versions at the same time.

767
00:27:30,160 --> 00:27:32,000
The old script runs on its original schedule

768
00:27:32,000 --> 00:27:34,400
while the new platform automation runs in parallel.

769
00:27:34,400 --> 00:27:36,640
Both are processing work and both are writing results.

770
00:27:36,640 --> 00:27:39,200
You compare the outputs and watch for any discrepancies.

771
00:27:39,200 --> 00:27:41,360
You monitor this for days or even weeks.

772
00:27:41,360 --> 00:27:42,880
Only when you are completely confident

773
00:27:42,880 --> 00:27:44,880
that the new version works do you switch over.

774
00:27:44,880 --> 00:27:47,280
Only then do you decommission the old script.

775
00:27:47,280 --> 00:27:49,760
You don't do all 50 of your automations this way.

776
00:27:49,760 --> 00:27:52,480
You do the critical one first and document what worked.

777
00:27:52,480 --> 00:27:54,640
You improve your process based on those lessons.

778
00:27:54,640 --> 00:27:55,920
Then you move to the second one.

779
00:27:55,920 --> 00:27:57,840
The second migration is always faster

780
00:27:57,840 --> 00:27:59,600
because you've already learned the pattern.

781
00:27:59,600 --> 00:28:01,920
By the 10th automation you've refined the approach

782
00:28:01,920 --> 00:28:04,240
enough that new migrations move very quickly.

783
00:28:04,240 --> 00:28:06,160
Phase 4 is optimization.

784
00:28:06,160 --> 00:28:08,720
Once you have several automations running on the platform,

785
00:28:08,720 --> 00:28:10,160
patterns will start to emerge.

786
00:28:10,160 --> 00:28:11,680
You'll see that multiple automations

787
00:28:11,680 --> 00:28:13,040
need the same validation logic

788
00:28:13,040 --> 00:28:14,560
so you build a shared function.

789
00:28:14,560 --> 00:28:16,960
You'll see that they follow the same orchestration pattern

790
00:28:16,960 --> 00:28:18,400
so you create a template.

791
00:28:18,400 --> 00:28:20,720
You build shared monitoring and create documentation

792
00:28:20,720 --> 00:28:22,320
that helps new teams move faster.

793
00:28:22,320 --> 00:28:23,760
This entire path takes years.

794
00:28:23,760 --> 00:28:26,080
It might take a year to get through all four phases

795
00:28:26,080 --> 00:28:28,240
for your first set of critical automations.

796
00:28:28,240 --> 00:28:30,560
It might take another year to migrate the second wave.

797
00:28:30,560 --> 00:28:32,640
By year three, you're deep into optimization

798
00:28:32,640 --> 00:28:35,360
and building new capabilities instead of just migrating the old ones.

799
00:28:35,360 --> 00:28:36,320
But here's what matters.

800
00:28:36,320 --> 00:28:38,640
During all of this, the business keeps running.

801
00:28:38,640 --> 00:28:42,000
You aren't asking the organization to accept downtime while you rebuild.

802
00:28:42,000 --> 00:28:44,400
You aren't asking people to work without their tools

803
00:28:44,400 --> 00:28:45,840
while you figure out the new system.

804
00:28:45,840 --> 00:28:47,040
You're asking them to keep going

805
00:28:47,040 --> 00:28:48,960
while you build something better in parallel.

806
00:28:48,960 --> 00:28:52,000
Organizations that fail at this try to do it differently.

807
00:28:52,000 --> 00:28:53,600
They decide to migrate everything at once

808
00:28:53,600 --> 00:28:54,960
and shut down the old system.

809
00:28:54,960 --> 00:28:57,760
Then they discover they missed a detail and the business breaks.

810
00:28:57,760 --> 00:28:59,600
They panic and go back to the old system

811
00:28:59,600 --> 00:29:01,360
and the new system gets abandoned.

812
00:29:01,360 --> 00:29:03,680
Everyone gets frustrated and two years later

813
00:29:03,680 --> 00:29:05,520
they're still running the same old scripts.

814
00:29:05,520 --> 00:29:08,640
The organizations that succeed are the ones that accept the pace.

815
00:29:08,640 --> 00:29:11,920
They understand that moving slower means arriving intact.

816
00:29:11,920 --> 00:29:15,120
Incremental change provides higher confidence than a revolution.

817
00:29:15,120 --> 00:29:17,920
Keeping the business running while you rebuild is not slow.

818
00:29:17,920 --> 00:29:19,840
It's the only way to actually finish.

819
00:29:19,840 --> 00:29:22,720
The business case, why this costs less than you think.

820
00:29:22,720 --> 00:29:26,400
The first question every CFO asks about rebuilding automation is simple.

821
00:29:26,400 --> 00:29:27,920
How much is this going to cost?

822
00:29:27,920 --> 00:29:29,760
The honest answer makes them uncomfortable

823
00:29:29,760 --> 00:29:31,360
because the cost is visible

824
00:29:31,360 --> 00:29:32,960
but the savings are invisible.

825
00:29:32,960 --> 00:29:35,360
You're likely paying more right now than you realize.

826
00:29:35,360 --> 00:29:37,040
Think about your organization today.

827
00:29:37,040 --> 00:29:39,040
You have 50 critical automations running.

828
00:29:39,040 --> 00:29:41,360
Some are PowerShell scripts, some are Logic Apps,

829
00:29:41,360 --> 00:29:44,480
others are just schedule tasks or power automate flows.

830
00:29:44,480 --> 00:29:45,840
None of them are built the same way.

831
00:29:45,840 --> 00:29:47,360
You have no way to reconcile them.

832
00:29:47,360 --> 00:29:48,240
You have no governance.

833
00:29:48,240 --> 00:29:49,440
You have no real monitoring.

834
00:29:49,440 --> 00:29:51,040
When a process breaks at 3am,

835
00:29:51,040 --> 00:29:53,680
someone has to wake up, hunt through logs and fix it manually.

836
00:29:53,680 --> 00:29:56,080
You won't find the price of this mess on a single budget line.

837
00:29:56,080 --> 00:29:56,960
It's hidden.

838
00:29:56,960 --> 00:29:59,280
It's spread across every department in the company.

839
00:29:59,280 --> 00:30:02,400
It's the hours your operations team wastes on troubleshooting.

840
00:30:02,400 --> 00:30:04,400
It's the business impact of a missed event

841
00:30:04,400 --> 00:30:06,560
that nobody noticed until it was too late.

842
00:30:06,560 --> 00:30:08,880
It's the security risk of unmanaged identities

843
00:30:08,880 --> 00:30:12,000
and the compliance gaps that exist because there's no audit trail.

844
00:30:12,000 --> 00:30:13,760
Let's put a number on that invisible drain

845
00:30:13,760 --> 00:30:18,080
in a mid-sized company that overhead easily hits $500,000 a year.

846
00:30:18,080 --> 00:30:19,520
That's a conservative estimate.

847
00:30:19,520 --> 00:30:20,960
Now, look at the platform model.

848
00:30:20,960 --> 00:30:23,360
Your infrastructure costs about 50,000 a year

849
00:30:23,360 --> 00:30:26,720
for things like Logic Apps, Functions and Storage.

850
00:30:26,720 --> 00:30:29,200
You spend another 200,000 on labor

851
00:30:29,200 --> 00:30:31,840
to have someone design the system and guide the migration.

852
00:30:31,840 --> 00:30:34,160
Your total is $250,000.

853
00:30:34,160 --> 00:30:36,080
On paper, you just cut your costs in half.

854
00:30:36,080 --> 00:30:36,960
But here is the problem.

855
00:30:36,960 --> 00:30:39,680
The 250,000 is a visible line item.

856
00:30:39,680 --> 00:30:40,960
Everyone sees it.

857
00:30:40,960 --> 00:30:43,680
The 500,000 you were spending before was invisible.

858
00:30:43,680 --> 00:30:44,640
No one was tracking it.

859
00:30:44,640 --> 00:30:45,840
No one knew it existed.

860
00:30:45,840 --> 00:30:48,720
They just knew things kept breaking and people kept fixing them.

861
00:30:48,720 --> 00:30:50,960
This is why leadership struggles with the investment.

862
00:30:50,960 --> 00:30:53,440
A CFO looks at the budget and sees a quarter million dollars

863
00:30:53,440 --> 00:30:54,480
going to a new project.

864
00:30:54,480 --> 00:30:55,920
That feels like new spending.

865
00:30:55,920 --> 00:30:57,600
The fact that you were already burning twice

866
00:30:57,600 --> 00:30:59,280
that amount on operational friction

867
00:30:59,280 --> 00:31:02,080
doesn't register because the old system never captured the data.

868
00:31:02,080 --> 00:31:04,240
But after the first year, the math gets even better.

869
00:31:04,240 --> 00:31:05,600
Your infrastructure stays the same,

870
00:31:05,600 --> 00:31:07,040
but your labor costs drop.

871
00:31:07,040 --> 00:31:08,240
You aren't migrating anymore.

872
00:31:08,240 --> 00:31:09,040
You're just maintaining.

873
00:31:09,040 --> 00:31:11,360
You might spend 50,000 a year to keep the platform

874
00:31:11,360 --> 00:31:12,880
running and onboard new ideas.

875
00:31:12,880 --> 00:31:15,600
Now, your total cost is $100,000.

876
00:31:15,600 --> 00:31:17,920
You've cut the original spend by 80%.

877
00:31:17,920 --> 00:31:19,600
But even that isn't the real win.

878
00:31:19,600 --> 00:31:21,120
The real return is speed.

879
00:31:21,120 --> 00:31:22,480
Once the platform exists,

880
00:31:22,480 --> 00:31:25,280
adding a new automation takes days instead of weeks.

881
00:31:25,280 --> 00:31:26,640
When the business needs a solution,

882
00:31:26,640 --> 00:31:28,560
you can deliver it in seven days.

883
00:31:28,560 --> 00:31:29,680
Under the old model,

884
00:31:29,680 --> 00:31:30,960
you'd quote them three weeks

885
00:31:30,960 --> 00:31:33,680
and then spend the fourth week explaining why it's delayed.

886
00:31:33,680 --> 00:31:34,560
Now you can experiment.

887
00:31:34,560 --> 00:31:36,000
You can respond to competitors.

888
00:31:36,000 --> 00:31:36,880
You can actually move.

889
00:31:36,880 --> 00:31:38,160
That's where the ROI lives.

890
00:31:38,160 --> 00:31:40,160
It's not just about saving money on scripts.

891
00:31:40,160 --> 00:31:42,480
It's about making the entire business more responsive.

892
00:31:42,480 --> 00:31:43,840
The business case is simple.

893
00:31:43,840 --> 00:31:45,280
If you're honest about the numbers,

894
00:31:45,280 --> 00:31:47,760
you are going to pay for automation one way or another.

895
00:31:47,760 --> 00:31:50,000
You can pay for it invisibly through overhead,

896
00:31:50,000 --> 00:31:51,760
where people are constantly fighting fires

897
00:31:51,760 --> 00:31:53,520
and troubleshooting broken scripts.

898
00:31:53,520 --> 00:31:55,760
Or you can pay for it visibly through a platform.

899
00:31:55,760 --> 00:31:57,280
The visible option is cheaper.

900
00:31:57,280 --> 00:31:59,200
If you want to test this in your own office,

901
00:31:59,200 --> 00:32:00,400
track one month of time,

902
00:32:00,400 --> 00:32:02,640
spend fixing and maintaining your current scripts,

903
00:32:02,640 --> 00:32:05,360
calculate that labor cost and multiply it by 12.

904
00:32:05,360 --> 00:32:06,640
That is what you are already spending.

905
00:32:06,640 --> 00:32:08,800
Once you see that number, the conversation changes.

906
00:32:08,800 --> 00:32:11,440
It's no longer a question of if you should build a platform.

907
00:32:11,440 --> 00:32:13,040
It's a question of who is going to run it.

908
00:32:14,400 --> 00:32:16,400
The operational model, who does what?

909
00:32:16,400 --> 00:32:19,280
Most organizations fail even after they commit to the platform.

910
00:32:19,280 --> 00:32:22,080
They build the tech, but they don't change how people work.

911
00:32:22,080 --> 00:32:24,480
In the old script model, ownership was easy.

912
00:32:24,480 --> 00:32:26,800
The team that needed the automation wrote the code.

913
00:32:26,800 --> 00:32:28,240
They owned it, they maintained it.

914
00:32:28,240 --> 00:32:30,480
If it broke in the middle of the night, they got the call.

915
00:32:30,480 --> 00:32:34,240
The responsibility was clear because it was tied to one person or one desk.

916
00:32:34,240 --> 00:32:36,160
But the platform model doesn't work that way.

917
00:32:36,160 --> 00:32:38,720
Individual teams can't own the shared infrastructure.

918
00:32:38,720 --> 00:32:41,040
They can't manage the global security policies

919
00:32:41,040 --> 00:32:43,520
or the monitoring layer that watches the whole environment.

920
00:32:43,520 --> 00:32:44,720
You need a new structure.

921
00:32:44,720 --> 00:32:46,240
First, you need a platform team.

922
00:32:46,240 --> 00:32:47,760
These people own the foundation.

923
00:32:47,760 --> 00:32:50,960
They manage the identities, the governance and the reconciliation tools.

924
00:32:50,960 --> 00:32:53,600
They aren't responsible for every individual automation.

925
00:32:53,600 --> 00:32:56,800
They are responsible for the system that makes those automations possible.

926
00:32:56,800 --> 00:32:58,000
They are the architects.

927
00:32:58,000 --> 00:33:00,640
They design the world, but they don't live in every house.

928
00:33:00,640 --> 00:33:02,240
Next, you need automation teams.

929
00:33:02,240 --> 00:33:04,960
These are the people who understand the business logic.

930
00:33:04,960 --> 00:33:08,480
They know which systems need to talk and why the process matters to the company.

931
00:33:08,480 --> 00:33:11,360
They work within the guardrails, the platform team setup.

932
00:33:11,360 --> 00:33:12,720
When they build something new,

933
00:33:12,720 --> 00:33:14,160
they don't start from a blank page.

934
00:33:14,160 --> 00:33:15,120
They use the templates.

935
00:33:15,120 --> 00:33:16,400
They follow the patterns.

936
00:33:16,400 --> 00:33:18,000
Finally, you need a governance committee.

937
00:33:18,000 --> 00:33:20,320
This isn't a group that just says yes to everything.

938
00:33:20,320 --> 00:33:24,160
It's a decision-making body with people from IT, security and compliance.

939
00:33:24,160 --> 00:33:27,440
When a team wants to automate something involving sensitive data,

940
00:33:27,440 --> 00:33:29,360
this committee asks the hard questions.

941
00:33:29,360 --> 00:33:31,440
They decide if the risk is worth the reward.

942
00:33:31,440 --> 00:33:33,440
This is a big shift for most companies.

943
00:33:33,440 --> 00:33:37,200
Usually, IT owns the hardware and business teams own the apps.

944
00:33:37,200 --> 00:33:39,600
A dedicated automation platform team is a new concept.

945
00:33:39,600 --> 00:33:40,880
And yes, there is a cost to this.

946
00:33:40,880 --> 00:33:42,480
You have to assign people to these roles.

947
00:33:42,480 --> 00:33:45,360
You need experts who understand monitoring and governance.

948
00:33:45,360 --> 00:33:47,760
But the benefit is that the finger pointing stops.

949
00:33:47,760 --> 00:33:49,600
If a managed identity expires,

950
00:33:49,600 --> 00:33:50,560
that's a platform issue.

951
00:33:50,560 --> 00:33:52,080
If the business logic is wrong,

952
00:33:52,080 --> 00:33:53,280
that's an automation team issue.

953
00:33:53,280 --> 00:33:54,880
If there's a question about data access,

954
00:33:54,880 --> 00:33:56,000
that's a governance issue.

955
00:33:56,000 --> 00:33:57,200
Everything has a home.

956
00:33:57,200 --> 00:33:59,040
When this works, the flow is seamless.

957
00:33:59,040 --> 00:34:02,000
A business unit identifies a process that needs to be faster.

958
00:34:02,000 --> 00:34:04,640
They talk to the automation team to design the logic.

959
00:34:04,640 --> 00:34:06,240
Then they check with the platform team

960
00:34:06,240 --> 00:34:08,240
to see what infrastructure is required.

961
00:34:08,240 --> 00:34:11,040
The platform team sets up the identity and the monitoring.

962
00:34:11,040 --> 00:34:13,680
The automation team builds the flow using the approved framework.

963
00:34:13,680 --> 00:34:15,840
The governance committee reviews the access levels

964
00:34:15,840 --> 00:34:16,960
and gives the green light.

965
00:34:16,960 --> 00:34:17,760
Then it goes live.

966
00:34:17,760 --> 00:34:21,520
If something fails, the automation team checks their code first.

967
00:34:21,520 --> 00:34:22,720
If the problem is structural,

968
00:34:22,720 --> 00:34:24,640
like a failed reconciliation mechanism,

969
00:34:24,640 --> 00:34:26,320
the platform team steps into fixing it.

970
00:34:26,320 --> 00:34:28,480
This is the only model that actually scales.

971
00:34:28,480 --> 00:34:30,880
It's the model where the business can move fast

972
00:34:30,880 --> 00:34:33,360
because the infrastructure is designed to support them

973
00:34:33,360 --> 00:34:34,320
not get in their way.

974
00:34:34,320 --> 00:34:36,480
The operational model isn't about the software you buy.

975
00:34:36,480 --> 00:34:38,240
It's about the people and the process.

976
00:34:38,240 --> 00:34:39,920
The model defines how you work.

977
00:34:39,920 --> 00:34:42,480
But the real impact happens at the technical level.

978
00:34:42,480 --> 00:34:44,960
Let's look at what that actually looks like in practice.

979
00:34:44,960 --> 00:34:46,400
The technical execution.

980
00:34:46,400 --> 00:34:48,480
Building your first platform automation.

981
00:34:48,480 --> 00:34:51,760
Let's get concrete about how you actually build your first platform automation.

982
00:34:51,760 --> 00:34:53,600
This is in theory. This is the real sequence.

983
00:34:53,600 --> 00:34:55,120
Step one is candidate selection.

984
00:34:55,120 --> 00:34:58,080
You aren't looking for the most complex automation in your backlog.

985
00:34:58,080 --> 00:35:01,200
You're looking for one that meets four specific criteria.

986
00:35:01,200 --> 00:35:03,120
First, it has to be critical enough

987
00:35:03,120 --> 00:35:05,440
that people actually care if it works.

988
00:35:05,440 --> 00:35:07,280
It can't be a nice to have background process

989
00:35:07,280 --> 00:35:08,480
that nobody notices.

990
00:35:08,480 --> 00:35:11,040
Second, it has to be simple enough to build in a few weeks.

991
00:35:11,040 --> 00:35:14,080
If you pick a project that takes four months just to understand

992
00:35:14,080 --> 00:35:15,840
you're going to lose all your momentum.

993
00:35:15,840 --> 00:35:17,280
Third, it has to be self-contained.

994
00:35:17,280 --> 00:35:19,680
You don't want crazy dependencies on five other systems

995
00:35:19,680 --> 00:35:21,280
that might change while you're building.

996
00:35:21,280 --> 00:35:22,640
Finally, it has to be measurable.

997
00:35:22,640 --> 00:35:25,280
You need to know for a fact whether it's working or not.

998
00:35:25,280 --> 00:35:27,680
A great candidate is something like syncing employee data

999
00:35:27,680 --> 00:35:30,320
from HR into active directory when a new hire starts.

1000
00:35:30,320 --> 00:35:32,160
Everyone understands what the outcome should be.

1001
00:35:32,160 --> 00:35:34,560
If the sync breaks, people notice immediately.

1002
00:35:34,560 --> 00:35:37,440
It isn't a trivial task because you're dealing with multiple systems

1003
00:35:37,440 --> 00:35:39,040
but it isn't rocket science either.

1004
00:35:39,040 --> 00:35:41,360
You can wrap your head around the whole thing in about a week.

1005
00:35:41,360 --> 00:35:42,480
Step two is flow design.

1006
00:35:42,480 --> 00:35:43,680
Don't write any code yet.

1007
00:35:43,680 --> 00:35:44,720
Don't even open your ID.

1008
00:35:44,720 --> 00:35:45,840
Draw a diagram.

1009
00:35:45,840 --> 00:35:48,480
Map out the entire flow from the input to the output.

1010
00:35:48,480 --> 00:35:49,600
What triggers the process?

1011
00:35:49,600 --> 00:35:50,800
What happens next?

1012
00:35:50,800 --> 00:35:53,040
What decisions does the system need to make?

1013
00:35:53,040 --> 00:35:54,720
Where does the data actually go?

1014
00:35:54,720 --> 00:35:56,080
This diagram is your blueprint.

1015
00:35:56,080 --> 00:35:58,240
Everything that comes after this is just translating

1016
00:35:58,240 --> 00:36:00,000
that blueprint into infrastructure.

1017
00:36:00,000 --> 00:36:02,720
For that HR sync, your diagram might look like this.

1018
00:36:02,720 --> 00:36:04,800
A new hire arrives in the HR system

1019
00:36:04,800 --> 00:36:06,320
which triggers a graph subscription.

1020
00:36:06,320 --> 00:36:08,560
A logic app reads that data and validates it

1021
00:36:08,560 --> 00:36:10,160
against your domain requirements.

1022
00:36:10,160 --> 00:36:12,240
Then a function creates the AD account

1023
00:36:12,240 --> 00:36:14,080
in the logic app sensor confirmation.

1024
00:36:14,080 --> 00:36:15,920
Once a day, a Delta query runs to check

1025
00:36:15,920 --> 00:36:17,440
if any new hires were missed.

1026
00:36:17,440 --> 00:36:19,280
Step three is infrastructure setup.

1027
00:36:19,280 --> 00:36:21,040
This is where you start touching Azure.

1028
00:36:21,040 --> 00:36:23,920
You create the managed identities for each component.

1029
00:36:23,920 --> 00:36:27,360
The logic app gets an identity to read from HR and write to AD

1030
00:36:27,360 --> 00:36:29,440
while the function gets an identity specifically

1031
00:36:29,440 --> 00:36:30,480
to create accounts.

1032
00:36:30,480 --> 00:36:33,520
You set up monitoring dashboards to watch these components.

1033
00:36:33,520 --> 00:36:35,760
You create the logic app and the function containers

1034
00:36:35,760 --> 00:36:37,600
but you don't put the real logic in yet.

1035
00:36:37,600 --> 00:36:39,040
You're just building the boxes.

1036
00:36:39,040 --> 00:36:40,560
Step four is testing and staging.

1037
00:36:40,560 --> 00:36:44,080
You create test data like a fake hire in the test HR system.

1038
00:36:44,080 --> 00:36:45,760
You trigger the subscription manually

1039
00:36:45,760 --> 00:36:47,600
and watch it flow through the logic app.

1040
00:36:47,600 --> 00:36:49,520
You confirm the function gets the right data

1041
00:36:49,520 --> 00:36:51,280
and verify the AD account is created.

1042
00:36:51,280 --> 00:36:53,920
You check the monitoring to make sure it captured the event.

1043
00:36:53,920 --> 00:36:55,200
Then you test the failures.

1044
00:36:55,200 --> 00:36:57,680
What happens if the AD account already exists?

1045
00:36:57,680 --> 00:36:59,440
What if the HR data is malformed?

1046
00:36:59,440 --> 00:37:00,880
You aren't looking for perfection here.

1047
00:37:00,880 --> 00:37:02,960
You're looking to make sure that when things fail,

1048
00:37:02,960 --> 00:37:05,520
those failures are visible and easy to understand.

1049
00:37:05,520 --> 00:37:07,840
Step five is the daily reconciliation test.

1050
00:37:07,840 --> 00:37:10,240
You run that delta query against your test data.

1051
00:37:10,240 --> 00:37:11,520
You intentionally inject records

1052
00:37:11,520 --> 00:37:13,040
that the subscription might miss.

1053
00:37:13,040 --> 00:37:14,640
You confirm the query finds them

1054
00:37:14,640 --> 00:37:16,720
and that they get reprocessed correctly.

1055
00:37:16,720 --> 00:37:19,120
You're verifying that your safety net actually works.

1056
00:37:19,120 --> 00:37:20,720
Step six is parallel operation.

1057
00:37:20,720 --> 00:37:22,640
Don't switch over from the old system yet.

1058
00:37:22,640 --> 00:37:24,080
Run them both side by side.

1059
00:37:24,080 --> 00:37:26,000
The old sync method creates the accounts

1060
00:37:26,000 --> 00:37:28,000
and your new platform automation does too.

1061
00:37:28,000 --> 00:37:29,520
You aren't creating duplicate accounts

1062
00:37:29,520 --> 00:37:32,160
because you're running the new system against test data

1063
00:37:32,160 --> 00:37:33,840
while the old one handles production.

1064
00:37:33,840 --> 00:37:36,080
But you're running it live at the same frequency,

1065
00:37:36,080 --> 00:37:37,040
hitting the same systems.

1066
00:37:37,040 --> 00:37:37,920
You watch it for days.

1067
00:37:37,920 --> 00:37:38,880
You compare the outputs.

1068
00:37:38,880 --> 00:37:42,720
You verify the new system handles every scenario the old one did.

1069
00:37:42,720 --> 00:37:44,400
Step seven is the cutover.

1070
00:37:44,400 --> 00:37:46,240
You switch the new automation to production.

1071
00:37:46,240 --> 00:37:48,800
You keep the old system running as a backup for one week.

1072
00:37:48,800 --> 00:37:49,840
Then you decommission it.

1073
00:37:49,840 --> 00:37:51,440
This whole process takes time.

1074
00:37:51,440 --> 00:37:53,600
Maybe three or four weeks for a straightforward process.

1075
00:37:53,600 --> 00:37:54,880
But by the time you're finished,

1076
00:37:54,880 --> 00:37:57,120
you have total confidence that it works.

1077
00:37:57,120 --> 00:37:59,040
And you've built the foundation for the next one.

1078
00:37:59,040 --> 00:38:00,640
The second automation takes two weeks

1079
00:38:00,640 --> 00:38:02,480
because you've already solved the hard problems.

1080
00:38:02,480 --> 00:38:03,680
The third takes ten days.

1081
00:38:03,680 --> 00:38:05,360
By the fifth one, you're down to five days

1082
00:38:05,360 --> 00:38:06,640
because you've learnt the patterns.

1083
00:38:06,640 --> 00:38:07,680
The first one takes weeks.

1084
00:38:07,680 --> 00:38:08,880
The second one takes days.

1085
00:38:08,880 --> 00:38:10,320
This is what scaling looks like.

1086
00:38:10,320 --> 00:38:12,480
Scaling the platform from one to many.

1087
00:38:12,480 --> 00:38:14,480
You've finished your first platform automation.

1088
00:38:14,480 --> 00:38:15,040
It's working.

1089
00:38:15,040 --> 00:38:16,640
It's more reliable than the old script.

1090
00:38:16,640 --> 00:38:17,600
It's maintainable.

1091
00:38:17,600 --> 00:38:19,600
And you understand how the pieces fit together.

1092
00:38:19,600 --> 00:38:20,000
Now what?

1093
00:38:20,000 --> 00:38:21,200
Now you build the next one.

1094
00:38:21,200 --> 00:38:22,320
And the one after that.

1095
00:38:22,320 --> 00:38:23,200
But here's the shift.

1096
00:38:23,200 --> 00:38:26,640
The second automation is faster than the first.

1097
00:38:26,640 --> 00:38:28,080
The third is faster than the second.

1098
00:38:28,080 --> 00:38:29,680
By the time you've finished five,

1099
00:38:29,680 --> 00:38:31,920
you're moving at a completely different speed.

1100
00:38:31,920 --> 00:38:34,560
By ten adding new automations is almost trivial.

1101
00:38:34,560 --> 00:38:36,960
You've built the infrastructure that does the heavy lifting.

1102
00:38:36,960 --> 00:38:39,920
This is where the real ROI of the platform finally shows up.

1103
00:38:39,920 --> 00:38:42,720
In the old script model, every automation is an island.

1104
00:38:42,720 --> 00:38:44,880
You write a script, you test it, and you deploy it.

1105
00:38:44,880 --> 00:38:46,160
Then you move to the next one.

1106
00:38:46,160 --> 00:38:47,280
There's no leverage there.

1107
00:38:47,280 --> 00:38:50,000
There's no sharing components or reusing patterns.

1108
00:38:50,000 --> 00:38:53,040
The fifth-year script takes just as much effort as the first one.

1109
00:38:53,040 --> 00:38:54,400
You aren't accelerating.

1110
00:38:54,400 --> 00:38:55,920
You're just repeating yourself.

1111
00:38:55,920 --> 00:38:59,120
In the platform model, every automation builds on the last one.

1112
00:38:59,120 --> 00:39:01,440
You aren't writing the orchestration layer again.

1113
00:39:01,440 --> 00:39:03,440
You aren't setting up the monitoring from scratch.

1114
00:39:03,440 --> 00:39:05,760
You aren't spending weeks on governance policies.

1115
00:39:05,760 --> 00:39:08,800
You're just building the specific logic for this one process.

1116
00:39:08,800 --> 00:39:10,080
Everything else is already there.

1117
00:39:10,080 --> 00:39:13,200
This is the move from linear cost to exponential leverage.

1118
00:39:13,200 --> 00:39:15,840
The first automation might cost 50,000 to build.

1119
00:39:15,840 --> 00:39:19,040
The second costs 40,000 because the infrastructure is already there.

1120
00:39:19,040 --> 00:39:21,440
The third costs 35,000 by the tenth one.

1121
00:39:21,440 --> 00:39:23,760
You're down to 20,000 per automation.

1122
00:39:23,760 --> 00:39:25,360
But it isn't just about the money.

1123
00:39:25,360 --> 00:39:27,920
The quality of what your building goes up every time.

1124
00:39:27,920 --> 00:39:31,360
After five automations, you'll notice a pattern, a subscription fires,

1125
00:39:31,360 --> 00:39:34,080
a logic app reads data, a function validates it,

1126
00:39:34,080 --> 00:39:35,840
and a reconciliation check runs.

1127
00:39:35,840 --> 00:39:37,440
The pattern is identical every time.

1128
00:39:37,440 --> 00:39:38,240
So you codify it.

1129
00:39:38,240 --> 00:39:39,360
You create a template.

1130
00:39:39,360 --> 00:39:40,960
Now, when a team wants to build something new,

1131
00:39:40,960 --> 00:39:42,400
they don't start with a blank page.

1132
00:39:42,400 --> 00:39:44,560
They start with the template and just fill in the blanks.

1133
00:39:44,560 --> 00:39:45,760
The business logic goes here.

1134
00:39:45,760 --> 00:39:47,280
The validation rules go there.

1135
00:39:47,280 --> 00:39:49,120
What used to take a month now takes a week.

1136
00:39:49,120 --> 00:39:52,320
After 10 automations, a library of functions has emerged.

1137
00:39:52,320 --> 00:39:53,680
Need to validate customer data?

1138
00:39:53,680 --> 00:39:54,800
But there's a function for that.

1139
00:39:54,800 --> 00:39:55,760
Need to check inventory.

1140
00:39:55,760 --> 00:39:57,040
There's a function for that.

1141
00:39:57,040 --> 00:39:58,160
You aren't writing them again.

1142
00:39:58,160 --> 00:39:59,440
You're just composing them.

1143
00:39:59,440 --> 00:40:02,640
After 20 automations, your team has deep expertise.

1144
00:40:02,640 --> 00:40:05,280
They can spot architectural flaws before they happen.

1145
00:40:05,280 --> 00:40:08,400
They can suggest optimizations that save thousands in costs.

1146
00:40:08,400 --> 00:40:11,680
They know where the pitfalls are because they've walked the path 20 times.

1147
00:40:11,680 --> 00:40:13,760
They know which shortcuts are actually shortcuts

1148
00:40:13,760 --> 00:40:15,120
and which ones are just traps.

1149
00:40:15,120 --> 00:40:16,480
This is how platforms scale.

1150
00:40:16,480 --> 00:40:19,440
It isn't about hiring more people or buying more tools.

1151
00:40:19,440 --> 00:40:21,200
It's about building better infrastructure.

1152
00:40:21,200 --> 00:40:23,600
It's about compounding the value of every system

1153
00:40:23,600 --> 00:40:25,440
into the foundation for the next one.

1154
00:40:25,440 --> 00:40:26,880
The cost trajectory flips.

1155
00:40:26,880 --> 00:40:29,120
In year one, you're investing heavily in infrastructure

1156
00:40:29,120 --> 00:40:31,120
with only one automation to show for it.

1157
00:40:31,120 --> 00:40:32,880
In year two, you have five automations

1158
00:40:32,880 --> 00:40:34,320
and the foundation is solid.

1159
00:40:34,320 --> 00:40:36,240
By year four, you have 40 automations

1160
00:40:36,240 --> 00:40:38,320
and the platform is basically running itself.

1161
00:40:38,320 --> 00:40:39,920
Your team isn't just building anymore.

1162
00:40:39,920 --> 00:40:40,720
They're guiding.

1163
00:40:40,720 --> 00:40:41,760
They're optimizing.

1164
00:40:41,760 --> 00:40:43,920
This is the difference between a project and a product.

1165
00:40:43,920 --> 00:40:45,520
A project ends.

1166
00:40:45,520 --> 00:40:47,360
A platform evolves.

1167
00:40:47,360 --> 00:40:50,080
Evolving requires thinking about what changes over time.

1168
00:40:50,080 --> 00:40:51,680
It requires building for adaptation,

1169
00:40:51,680 --> 00:40:53,120
not just for today's requirements.

1170
00:40:54,080 --> 00:40:55,760
Evolution and adaptation.

1171
00:40:55,760 --> 00:40:57,040
Building for change.

1172
00:40:57,040 --> 00:40:59,920
Most platform projects die because of one uncomfortable reality.

1173
00:40:59,920 --> 00:41:02,800
The platform you build today will be useless by 2027.

1174
00:41:02,800 --> 00:41:04,000
It's not because you failed.

1175
00:41:04,000 --> 00:41:06,000
It's not because your architects weren't smart enough.

1176
00:41:06,000 --> 00:41:07,520
It's because the business evolves.

1177
00:41:07,520 --> 00:41:08,400
Technology shifts.

1178
00:41:08,400 --> 00:41:10,160
Requirements change in ways you can't predict

1179
00:41:10,160 --> 00:41:11,600
while you're still laying the foundation.

1180
00:41:11,600 --> 00:41:13,120
The organizations that actually win

1181
00:41:13,120 --> 00:41:14,720
don't try to predict the future.

1182
00:41:14,720 --> 00:41:15,360
They build for it.

1183
00:41:15,360 --> 00:41:16,720
This means accepting a new truth.

1184
00:41:16,720 --> 00:41:18,720
Your platform is not a fixed architecture.

1185
00:41:18,720 --> 00:41:19,840
It's a living system.

1186
00:41:19,840 --> 00:41:20,960
You're constantly refining it.

1187
00:41:20,960 --> 00:41:22,000
You're adding capabilities.

1188
00:41:22,000 --> 00:41:23,440
You're taking lessons from what fails

1189
00:41:23,440 --> 00:41:26,480
and integrating those insights back into the infrastructure itself.

1190
00:41:26,480 --> 00:41:29,920
Most people try to future-proof by guessing every possible requirement.

1191
00:41:29,920 --> 00:41:30,880
But that's where it breaks.

1192
00:41:30,880 --> 00:41:33,040
You end up with bloated over-engineered systems

1193
00:41:33,040 --> 00:41:34,720
that do everything nobody needs.

1194
00:41:34,720 --> 00:41:36,480
And nothing anybody actually uses.

1195
00:41:36,480 --> 00:41:38,000
Instead, you build for flexibility.

1196
00:41:38,000 --> 00:41:40,880
You design components that can be combined in different ways.

1197
00:41:40,880 --> 00:41:42,480
You create patterns that can be extended

1198
00:41:42,480 --> 00:41:44,880
without having to rip out the whole thing and start over.

1199
00:41:44,880 --> 00:41:46,400
And you invest in your team.

1200
00:41:46,400 --> 00:41:48,240
They aren't just maintaining what exists.

1201
00:41:48,240 --> 00:41:50,080
They're experimenting with new approaches

1202
00:41:50,080 --> 00:41:51,920
and thinking about how emerging tech applies

1203
00:41:51,920 --> 00:41:53,120
to your specific build.

1204
00:41:53,120 --> 00:41:54,800
This isn't slack in your budget.

1205
00:41:54,800 --> 00:41:56,160
It's how you stay relevant.

1206
00:41:56,160 --> 00:41:57,920
Look at how this played out in practice.

1207
00:41:57,920 --> 00:42:01,760
In May of 2026, agent 365 became generally available.

1208
00:42:01,760 --> 00:42:03,360
This was a brand new capability

1209
00:42:03,360 --> 00:42:06,000
that didn't even exist when most platforms were being designed.

1210
00:42:06,000 --> 00:42:08,320
Organizations with rigid platforms couldn't touch it.

1211
00:42:08,320 --> 00:42:09,840
It didn't fit their architecture.

1212
00:42:09,840 --> 00:42:11,200
It was a square peg.

1213
00:42:11,200 --> 00:42:13,600
To make it work, they would have had to tear out their foundation.

1214
00:42:13,600 --> 00:42:14,560
So they did nothing.

1215
00:42:14,560 --> 00:42:16,720
They watched the world move forward while they stayed still.

1216
00:42:16,720 --> 00:42:20,240
But organizations with flexible platforms had a different experience.

1217
00:42:20,240 --> 00:42:21,600
They looked at agent 365

1218
00:42:21,600 --> 00:42:24,000
and realized it fit naturally into their model.

1219
00:42:24,000 --> 00:42:27,120
Because they viewed agents as just another automated system,

1220
00:42:27,120 --> 00:42:29,280
they could use the same governance and identity layers

1221
00:42:29,280 --> 00:42:30,800
they already had in place.

1222
00:42:30,800 --> 00:42:33,360
Within a few weeks, they had agents running in production.

1223
00:42:33,360 --> 00:42:34,480
They weren't rewriting code.

1224
00:42:34,480 --> 00:42:35,920
They were just extending the system.

1225
00:42:35,920 --> 00:42:37,440
The cost difference here is massive.

1226
00:42:37,440 --> 00:42:39,760
The rigid organization has to choose between spending months

1227
00:42:39,760 --> 00:42:42,000
on a re-architecture or falling behind.

1228
00:42:42,000 --> 00:42:43,920
The flexible organization just has to decide

1229
00:42:43,920 --> 00:42:45,360
how fast they can get these tools

1230
00:42:45,360 --> 00:42:46,720
into the hands of their business teams.

1231
00:42:46,720 --> 00:42:49,280
This is the difference between building to last

1232
00:42:49,280 --> 00:42:50,240
and building to scale.

1233
00:42:50,240 --> 00:42:51,920
Platforms built to last are rigid.

1234
00:42:51,920 --> 00:42:54,560
They work perfectly for one specific set of tasks.

1235
00:42:54,560 --> 00:42:55,280
They're optimized.

1236
00:42:55,280 --> 00:42:56,320
They're efficient.

1237
00:42:56,320 --> 00:42:58,320
But the moment the business changes direction,

1238
00:42:58,320 --> 00:42:59,120
you're exposed.

1239
00:42:59,120 --> 00:43:00,320
You have to rebuild.

1240
00:43:00,320 --> 00:43:02,080
Platforms built to scale are different.

1241
00:43:02,080 --> 00:43:03,920
They aren't optimized for one single thing.

1242
00:43:03,920 --> 00:43:06,000
They're designed so new capabilities can be bolted

1243
00:43:06,000 --> 00:43:07,840
on without breaking what's already working.

1244
00:43:07,840 --> 00:43:08,960
When the business changes,

1245
00:43:08,960 --> 00:43:09,680
you extend.

1246
00:43:09,680 --> 00:43:10,960
You don't rebuild.

1247
00:43:10,960 --> 00:43:13,520
Building for adaptation costs more on day one.

1248
00:43:13,520 --> 00:43:15,120
You spend more time on the architecture

1249
00:43:15,120 --> 00:43:16,560
and less time on flashy features.

1250
00:43:16,560 --> 00:43:18,320
You focus on abstraction and boundaries

1251
00:43:18,320 --> 00:43:20,080
instead of squeezing every drop of value

1252
00:43:20,080 --> 00:43:21,520
out of a single line of code.

1253
00:43:21,520 --> 00:43:24,400
But the payoff is that your platform never becomes a liability.

1254
00:43:24,400 --> 00:43:25,520
It stays an asset.

1255
00:43:25,520 --> 00:43:27,920
It stays flexible enough to grab new opportunities.

1256
00:43:27,920 --> 00:43:29,920
Your team stops fighting the infrastructure

1257
00:43:29,920 --> 00:43:31,920
and the infrastructure starts enabling them.

1258
00:43:31,920 --> 00:43:33,520
The organizations that get this

1259
00:43:33,520 --> 00:43:35,680
are moving three times faster than everyone else.

1260
00:43:35,680 --> 00:43:37,280
Not because they're typing faster,

1261
00:43:37,280 --> 00:43:40,320
but because they aren't rebuilding what they already bought.

1262
00:43:40,320 --> 00:43:43,040
Evolution isn't something that happens to your platform.

1263
00:43:43,040 --> 00:43:45,280
It's something you design for from the very first day.

1264
00:43:45,280 --> 00:43:47,920
The future layer, agents,

1265
00:43:47,920 --> 00:43:49,920
MCP and autonomous systems.

1266
00:43:49,920 --> 00:43:52,240
By 2026, the conversation changed.

1267
00:43:52,240 --> 00:43:55,040
We stopped asking how do we automate this task

1268
00:43:55,040 --> 00:43:58,000
and started asking how do we make this system intelligent.

1269
00:43:58,000 --> 00:43:59,600
The infrastructure is already moving.

1270
00:43:59,600 --> 00:44:01,840
Agent 365 acts as the control plane.

1271
00:44:01,840 --> 00:44:04,240
The model context protocol, or MCP,

1272
00:44:04,240 --> 00:44:06,400
is the connectivity layer that lets agents work

1273
00:44:06,400 --> 00:44:08,800
across systems without moving data around.

1274
00:44:08,800 --> 00:44:10,400
Graph stays the unified interface,

1275
00:44:10,400 --> 00:44:11,840
but while the tech is ready,

1276
00:44:11,840 --> 00:44:13,360
the organizations are lagging.

1277
00:44:13,360 --> 00:44:15,120
Here's what's actually happening right now.

1278
00:44:15,120 --> 00:44:17,760
Companies are building agents that can look at a situation

1279
00:44:17,760 --> 00:44:20,480
reason through the context and take action on their own.

1280
00:44:20,480 --> 00:44:22,160
This isn't a theory, it's in production.

1281
00:44:22,160 --> 00:44:25,680
An agent can process orders from five different sources,

1282
00:44:25,680 --> 00:44:27,680
flag an exception when the warehouse is low

1283
00:44:27,680 --> 00:44:28,880
and coordinate the fulfillment.

1284
00:44:28,880 --> 00:44:31,840
All without a human telling it what to do next.

1285
00:44:31,840 --> 00:44:34,320
It works because the infrastructure underneath is solid,

1286
00:44:34,320 --> 00:44:35,920
but here's the problem most people miss.

1287
00:44:35,920 --> 00:44:38,560
Without governance, these agents are liabilities.

1288
00:44:38,560 --> 00:44:40,400
An autonomous system doing the wrong thing

1289
00:44:40,400 --> 00:44:42,080
is worse than no automation at all.

1290
00:44:42,080 --> 00:44:43,840
It's doing the wrong thing at scale,

1291
00:44:43,840 --> 00:44:46,160
with total confidence and without asking permission.

1292
00:44:46,160 --> 00:44:47,840
But an agent with constraints is different,

1293
00:44:47,840 --> 00:44:50,640
it has a defined identity, it has limited permissions.

1294
00:44:50,640 --> 00:44:52,240
Every action it takes is auditable.

1295
00:44:52,240 --> 00:44:54,160
You know exactly what it did and why it did it.

1296
00:44:54,160 --> 00:44:56,480
That's when autonomy becomes an asset instead of a risk.

1297
00:44:56,480 --> 00:44:57,680
Look at the timeline.

1298
00:44:57,680 --> 00:45:00,000
In 2026, agents became a standard tool.

1299
00:45:00,000 --> 00:45:02,080
The companies with solid foundations moved fast

1300
00:45:02,080 --> 00:45:04,320
while the one still managing individual scripts fell behind.

1301
00:45:04,320 --> 00:45:06,160
By 2027, the agents got smarter.

1302
00:45:06,160 --> 00:45:08,880
They started handling complex business critical processes

1303
00:45:08,880 --> 00:45:10,800
instead of just small pilots.

1304
00:45:10,800 --> 00:45:12,640
The gap between the platform companies

1305
00:45:12,640 --> 00:45:14,560
and the legacy companies became a canyon.

1306
00:45:15,360 --> 00:45:18,160
Now look at 2028, that's less than two years away.

1307
00:45:18,160 --> 00:45:20,160
Agents will be genuinely autonomous by then.

1308
00:45:20,160 --> 00:45:21,520
They won't just follow your steps.

1309
00:45:21,520 --> 00:45:22,960
They'll make decisions you didn't predict.

1310
00:45:22,960 --> 00:45:25,280
They'll handle edge cases without asking for help.

1311
00:45:25,280 --> 00:45:27,200
They'll run 24/7 without oversight.

1312
00:45:27,200 --> 00:45:28,640
If you have a governance model,

1313
00:45:28,640 --> 00:45:30,640
these agents become your competitive advantage.

1314
00:45:30,640 --> 00:45:33,920
If you don't, you'll still be debating if they're safe to use.

1315
00:45:33,920 --> 00:45:36,000
The winners aren't the ones with the newest toys.

1316
00:45:36,000 --> 00:45:37,360
They are the ones with the infrastructure

1317
00:45:37,360 --> 00:45:39,280
ready to use the toys when they arrive.

1318
00:45:39,280 --> 00:45:40,560
The organization's winning right now

1319
00:45:40,560 --> 00:45:42,560
treat this prep work as non-negotiable.

1320
00:45:42,560 --> 00:45:44,160
They aren't waiting for agents to be perfect.

1321
00:45:44,160 --> 00:45:45,440
They're building the foundation today

1322
00:45:45,440 --> 00:45:46,640
so they can deploy tomorrow.

1323
00:45:46,640 --> 00:45:47,840
They have the identities ready.

1324
00:45:47,840 --> 00:45:49,360
They have the policies defined.

1325
00:45:49,360 --> 00:45:51,040
They have the monitoring systems built

1326
00:45:51,040 --> 00:45:52,640
to watch autonomous behavior.

1327
00:45:52,640 --> 00:45:54,160
The organizations that are behind

1328
00:45:54,160 --> 00:45:57,120
are still arguing about whether their scripts are reliable.

1329
00:45:57,120 --> 00:45:58,880
They aren't thinking about agents yet.

1330
00:45:58,880 --> 00:46:00,240
They aren't preparing for systems

1331
00:46:00,240 --> 00:46:01,600
that make their own decisions.

1332
00:46:01,600 --> 00:46:03,280
By the time they realize they need them,

1333
00:46:03,280 --> 00:46:04,880
they'll be scrambling to build a foundation

1334
00:46:04,880 --> 00:46:06,320
that should have been finished years ago.

1335
00:46:06,320 --> 00:46:07,360
This is the frontier.

1336
00:46:07,360 --> 00:46:09,040
The barrier isn't building the agent.

1337
00:46:09,040 --> 00:46:10,400
We've figured that part out.

1338
00:46:10,400 --> 00:46:12,000
The barrier is having the infrastructure

1339
00:46:12,000 --> 00:46:13,120
to govern them safely.

1340
00:46:13,120 --> 00:46:14,880
The diagnostic for your team is simple,

1341
00:46:14,880 --> 00:46:15,680
but it's brutal.

1342
00:46:15,680 --> 00:46:17,040
If you aren't ready for agents,

1343
00:46:17,040 --> 00:46:18,720
you aren't ready for 2028

1344
00:46:18,720 --> 00:46:20,320
and you're running out of time to get ready.

1345
00:46:20,320 --> 00:46:21,840
Transition.

1346
00:46:21,840 --> 00:46:24,160
This is the frontier of what's coming.

1347
00:46:24,160 --> 00:46:26,640
But it's entirely built on the foundation

1348
00:46:26,640 --> 00:46:28,480
we've been discussing throughout this conversation.

1349
00:46:28,480 --> 00:46:30,160
Let's assess whether your organization

1350
00:46:30,160 --> 00:46:31,360
is actually ready for it.

1351
00:46:31,360 --> 00:46:33,760
Readiness assessment.

1352
00:46:33,760 --> 00:46:35,360
Are you ready for the platform?

1353
00:46:35,360 --> 00:46:36,560
Here is the honest question

1354
00:46:36,560 --> 00:46:38,400
your organization needs to answer.

1355
00:46:38,400 --> 00:46:39,680
Are you ready to build a platform?

1356
00:46:39,680 --> 00:46:41,360
The answer isn't as simple as or no.

1357
00:46:41,360 --> 00:46:42,080
It is a score.

1358
00:46:42,080 --> 00:46:44,480
It is a measure of whether you have the foundation in place

1359
00:46:44,480 --> 00:46:46,560
to actually execute on what we have been discussing.

1360
00:46:46,560 --> 00:46:48,080
Because you can have all the right ideas

1361
00:46:48,080 --> 00:46:49,840
about orchestration and autonomous systems.

1362
00:46:49,840 --> 00:46:51,360
But if your foundation isn't solid,

1363
00:46:51,360 --> 00:46:52,720
the technology doesn't matter.

1364
00:46:52,720 --> 00:46:54,000
Let me give you 10 questions.

1365
00:46:54,000 --> 00:46:55,200
Answer them honestly.

1366
00:46:55,200 --> 00:46:57,440
Do you have a clear picture of your critical automations?

1367
00:46:57,440 --> 00:46:59,200
Not a guess or a rough sense.

1368
00:46:59,200 --> 00:47:00,960
But do you actually know what they do

1369
00:47:00,960 --> 00:47:03,440
why they matter and what breaks if they stop working?

1370
00:47:03,440 --> 00:47:05,840
Do you have real monitoring on those critical automations?

1371
00:47:05,840 --> 00:47:08,080
I'm not talking about someone checking logs once a week.

1372
00:47:08,080 --> 00:47:10,320
I mean automated alerts that tell you immediately

1373
00:47:10,320 --> 00:47:11,680
when something goes wrong.

1374
00:47:11,680 --> 00:47:13,360
Do you have a reconciliation mechanism

1375
00:47:13,360 --> 00:47:14,480
for the critical ones?

1376
00:47:14,480 --> 00:47:16,800
You need a way to verify they are actually working

1377
00:47:16,800 --> 00:47:18,560
instead of just assuming they are.

1378
00:47:18,560 --> 00:47:20,720
Are your automations using managed identities

1379
00:47:20,720 --> 00:47:22,240
instead of stored credentials?

1380
00:47:22,240 --> 00:47:24,240
If you are still hard-coding connection strings

1381
00:47:24,240 --> 00:47:26,720
or relying on service accounts that never change,

1382
00:47:26,720 --> 00:47:27,680
that is a red flag.

1383
00:47:27,680 --> 00:47:28,800
Do you have governance policies

1384
00:47:28,800 --> 00:47:31,280
that actually constrain what automations can do?

1385
00:47:31,280 --> 00:47:33,840
Or can anyone create an automation that touches anything?

1386
00:47:33,840 --> 00:47:37,280
Is there a dedicated team that owns the automation platform itself?

1387
00:47:37,280 --> 00:47:39,200
Or is automation just something IT handles

1388
00:47:39,200 --> 00:47:40,480
when they have spare time?

1389
00:47:40,480 --> 00:47:41,840
Do you have a governance committee

1390
00:47:41,840 --> 00:47:44,240
that makes actual decisions about what is allowed?

1391
00:47:44,240 --> 00:47:47,040
Or do individual teams build what they want and hope it works out?

1392
00:47:47,040 --> 00:47:48,800
Do you have templates and shared components

1393
00:47:48,800 --> 00:47:51,120
that make building new automations faster?

1394
00:47:51,120 --> 00:47:53,120
Or does every automation start from zero?

1395
00:47:53,120 --> 00:47:54,800
Is your operational model clear?

1396
00:47:54,800 --> 00:47:55,920
When something breaks?

1397
00:47:55,920 --> 00:47:57,840
Do people know exactly who owns it?

1398
00:47:57,840 --> 00:48:00,240
Is there an actual plan for how your platform evolves

1399
00:48:00,240 --> 00:48:01,680
as technology changes?

1400
00:48:01,680 --> 00:48:03,600
Or are you just trying to keep what you have running?

1401
00:48:03,600 --> 00:48:05,360
Count how many of these you answered yes to?

1402
00:48:05,360 --> 00:48:07,040
Honestly, if you have seven or more

1403
00:48:07,040 --> 00:48:09,120
you have the foundation pieces to build a platform.

1404
00:48:09,120 --> 00:48:12,080
The execution might be messy and there is probably work to do.

1405
00:48:12,080 --> 00:48:13,920
But you have the structural thinking in place.

1406
00:48:13,920 --> 00:48:15,280
If you have fewer than seven

1407
00:48:15,280 --> 00:48:18,080
you are not ready to focus on building new capabilities.

1408
00:48:18,080 --> 00:48:19,760
You are in the foundation building phase.

1409
00:48:19,760 --> 00:48:20,800
The platform can wait.

1410
00:48:20,800 --> 00:48:22,960
What cannot wait is getting basic monitoring,

1411
00:48:22,960 --> 00:48:25,520
managed identities and governance policies in place

1412
00:48:25,520 --> 00:48:27,600
because that is your critical path right now.

1413
00:48:27,600 --> 00:48:30,080
This isn't about shame, this is about clarity.

1414
00:48:30,080 --> 00:48:31,520
Understanding where you actually are

1415
00:48:31,520 --> 00:48:33,760
is the only way to plan where you need to go.

1416
00:48:33,760 --> 00:48:35,920
The organizations that have built successful platforms

1417
00:48:35,920 --> 00:48:37,840
aren't the ones with the fanciest technology.

1418
00:48:37,840 --> 00:48:40,480
They didn't go after the newest tools or the most clever code.

1419
00:48:40,480 --> 00:48:42,960
They are the ones that invested in foundational thinking first.

1420
00:48:42,960 --> 00:48:46,000
They built monitoring because they needed to see what was happening.

1421
00:48:46,000 --> 00:48:47,760
They implemented managed identities

1422
00:48:47,760 --> 00:48:49,840
because credential management was a nightmare.

1423
00:48:49,840 --> 00:48:52,800
And they established governance because chaos was expensive.

1424
00:48:52,800 --> 00:48:54,480
Once the foundation was solid,

1425
00:48:54,480 --> 00:48:56,240
everything else became possible.

1426
00:48:56,240 --> 00:48:59,040
The organizations that failed tried to skip the foundation.

1427
00:48:59,040 --> 00:49:01,120
They wanted to talk about platforms and agents

1428
00:49:01,120 --> 00:49:04,720
and autonomous systems before they had basic monitoring in place.

1429
00:49:04,720 --> 00:49:06,480
They wanted to build complex orchestration

1430
00:49:06,480 --> 00:49:09,040
before they understood what their current automations actually did.

1431
00:49:09,040 --> 00:49:11,120
And they tried to run before they could walk.

1432
00:49:11,120 --> 00:49:14,400
Your diagnostic score tells you which camp you are in.

1433
00:49:14,400 --> 00:49:16,400
If you are in the foundation building phase,

1434
00:49:16,400 --> 00:49:17,760
that is not a failure.

1435
00:49:17,760 --> 00:49:19,760
That is where most organizations are right now.

1436
00:49:19,760 --> 00:49:22,800
The question is whether you are going to actually do the foundation work

1437
00:49:22,800 --> 00:49:24,400
or whether you are going to keep pretending

1438
00:49:24,400 --> 00:49:26,880
that patches and workarounds count as a strategy.

1439
00:49:26,880 --> 00:49:28,480
The ones that do the foundation work

1440
00:49:28,480 --> 00:49:31,200
end up in a completely different place by 2028.

1441
00:49:31,200 --> 00:49:33,440
The ones that don't just end up managing more chaos.

1442
00:49:33,440 --> 00:49:34,640
So where are you?

1443
00:49:34,640 --> 00:49:37,520
Honestly, that score matters more than any technology choice

1444
00:49:37,520 --> 00:49:38,640
you will make this year.

1445
00:49:38,640 --> 00:49:39,920
The starting point.

1446
00:49:39,920 --> 00:49:40,880
Where to begin?

1447
00:49:40,880 --> 00:49:42,400
You have done the diagnostic.

1448
00:49:42,400 --> 00:49:43,600
You know where you stand.

1449
00:49:43,600 --> 00:49:47,120
Now the question shifts from what do we need to what do we do first?

1450
00:49:47,120 --> 00:49:49,120
The biggest mistake organizations make right here

1451
00:49:49,120 --> 00:49:50,320
is obvious in retrospect.

1452
00:49:50,320 --> 00:49:52,080
They decide to build a platform

1453
00:49:52,080 --> 00:49:53,840
and immediately open the IDE.

1454
00:49:53,840 --> 00:49:56,400
They start writing code and designing logic apps

1455
00:49:56,400 --> 00:49:58,320
and then somewhere around week three,

1456
00:49:58,320 --> 00:50:00,640
they realize they don't actually have monitoring in place.

1457
00:50:00,640 --> 00:50:01,840
They don't have a governance model

1458
00:50:01,840 --> 00:50:03,680
or managed identities configured.

1459
00:50:03,680 --> 00:50:05,200
And the infrastructure doesn't exist.

1460
00:50:05,200 --> 00:50:07,920
The code they are building is sitting on top of sand.

1461
00:50:07,920 --> 00:50:08,800
So they panic.

1462
00:50:08,800 --> 00:50:10,320
They try to retrofit all of this.

1463
00:50:10,320 --> 00:50:12,160
The project stretches from months into a year

1464
00:50:12,160 --> 00:50:13,360
and momentum dies.

1465
00:50:13,360 --> 00:50:14,640
Stay cold is getting patient

1466
00:50:14,640 --> 00:50:16,080
and the project gets cancelled.

1467
00:50:16,080 --> 00:50:17,600
And the old scripts just keep running.

1468
00:50:17,600 --> 00:50:20,640
The organizations that actually succeed do something different.

1469
00:50:20,640 --> 00:50:22,800
They accept that the starting point is unglomerious.

1470
00:50:22,800 --> 00:50:24,720
They don't build a platform for six months.

1471
00:50:24,720 --> 00:50:26,000
They build a foundation.

1472
00:50:26,000 --> 00:50:27,760
And then once that foundation is solid,

1473
00:50:27,760 --> 00:50:29,040
the platform builds itself.

1474
00:50:29,040 --> 00:50:30,560
If your diagnostic score was low,

1475
00:50:30,560 --> 00:50:33,200
if you are missing more than three of those foundational pieces.

1476
00:50:33,520 --> 00:50:34,960
Your starting point is simple.

1477
00:50:34,960 --> 00:50:36,080
It isn't complex.

1478
00:50:36,080 --> 00:50:37,200
It is just methodical.

1479
00:50:37,200 --> 00:50:38,960
Month one is pure assessment work.

1480
00:50:38,960 --> 00:50:41,200
You are not touching code or designing architecture.

1481
00:50:41,200 --> 00:50:42,560
You are inventoring what you have

1482
00:50:42,560 --> 00:50:44,880
and documenting every automation that matters.

1483
00:50:44,880 --> 00:50:46,560
You are understanding what each one does

1484
00:50:46,560 --> 00:50:48,560
and identifying the ones that would break the business

1485
00:50:48,560 --> 00:50:49,680
if they stopped working.

1486
00:50:49,680 --> 00:50:52,000
You are measuring how often they currently fail

1487
00:50:52,000 --> 00:50:54,160
and documenting their current failure modes.

1488
00:50:54,160 --> 00:50:55,680
But you aren't fixing anything yet.

1489
00:50:55,680 --> 00:50:57,680
You are just seeing clearly what is actually running.

1490
00:50:57,680 --> 00:50:59,200
Month two is monitoring.

1491
00:50:59,200 --> 00:51:01,280
You set up dashboards and create alerts.

1492
00:51:01,280 --> 00:51:03,120
You instrument your critical automations

1493
00:51:03,120 --> 00:51:04,560
so you can see when they are working

1494
00:51:04,560 --> 00:51:05,760
and when they are not.

1495
00:51:05,760 --> 00:51:07,760
You establish baselines for reliability

1496
00:51:07,760 --> 00:51:09,360
and figure out what normal looks like

1497
00:51:09,360 --> 00:51:11,120
so you can spot when things go wrong.

1498
00:51:11,120 --> 00:51:12,800
This is not optional infrastructure.

1499
00:51:12,800 --> 00:51:14,000
It is the thing that tells you

1500
00:51:14,000 --> 00:51:15,680
whether your platform is actually better

1501
00:51:15,680 --> 00:51:17,040
than what you had before.

1502
00:51:17,040 --> 00:51:18,800
Month three is managed identities.

1503
00:51:18,800 --> 00:51:21,920
You migrate your automations away from stored credentials

1504
00:51:21,920 --> 00:51:23,840
and create system assigned identities

1505
00:51:23,840 --> 00:51:24,960
for each thing that runs.

1506
00:51:24,960 --> 00:51:26,400
You assign those identities

1507
00:51:26,400 --> 00:51:27,920
exactly the permissions they need

1508
00:51:27,920 --> 00:51:29,120
and nothing more.

1509
00:51:29,120 --> 00:51:31,680
This is the work that feels tedious in the moment.

1510
00:51:31,680 --> 00:51:33,200
But it is also the work that prevents

1511
00:51:33,200 --> 00:51:35,360
security incidents 18 months from now.

1512
00:51:35,360 --> 00:51:36,560
Month four is governance.

1513
00:51:36,560 --> 00:51:37,600
You establish the committee

1514
00:51:37,600 --> 00:51:39,200
and define the initial policies.

1515
00:51:39,200 --> 00:51:41,440
You document what automations are allowed to do

1516
00:51:41,440 --> 00:51:42,400
and what they are not.

1517
00:51:42,400 --> 00:51:43,840
You create the approval workflow

1518
00:51:43,840 --> 00:51:46,000
that prevents someone from building an automation

1519
00:51:46,000 --> 00:51:46,960
that shouldn't exist.

1520
00:51:46,960 --> 00:51:48,960
This is the work that feels like bureaucracy.

1521
00:51:48,960 --> 00:51:50,560
But it is actually the infrastructure

1522
00:51:50,560 --> 00:51:52,880
that lets teams move fast without breaking things.

1523
00:51:52,880 --> 00:51:54,240
Month five is templates.

1524
00:51:54,240 --> 00:51:56,560
You take the patterns from your current automations

1525
00:51:56,560 --> 00:51:57,600
and codify them.

1526
00:51:57,600 --> 00:51:59,600
You create a starting point for the next automation

1527
00:51:59,600 --> 00:52:00,720
that someone is going to build.

1528
00:52:00,720 --> 00:52:02,240
It doesn't have to be perfect.

1529
00:52:02,240 --> 00:52:03,520
It just has to save time.

1530
00:52:03,520 --> 00:52:06,160
Month six is your first platform automation.

1531
00:52:06,160 --> 00:52:08,000
Everything before this was preparation.

1532
00:52:08,000 --> 00:52:09,360
Now you actually build something

1533
00:52:09,360 --> 00:52:10,640
using the platform model.

1534
00:52:10,640 --> 00:52:12,160
You use the monitoring you set up.

1535
00:52:12,160 --> 00:52:14,240
You use the managed identities you configured

1536
00:52:14,240 --> 00:52:16,800
and you operate within the governance policies you defined.

1537
00:52:16,800 --> 00:52:18,480
This is your proof of concept.

1538
00:52:18,480 --> 00:52:19,680
And this is where you learn

1539
00:52:19,680 --> 00:52:20,960
whether the foundation you built

1540
00:52:20,960 --> 00:52:22,800
actually supports what you are trying to do.

1541
00:52:22,800 --> 00:52:24,400
This timeline is not arbitrary.

1542
00:52:24,400 --> 00:52:25,840
This sequence is not negotiable.

1543
00:52:25,840 --> 00:52:29,040
If you try to skip to month six without doing months one through five,

1544
00:52:29,040 --> 00:52:29,760
you will fail.

1545
00:52:29,760 --> 00:52:31,360
If you try to do the steps out of order.

1546
00:52:31,360 --> 00:52:32,960
Like building your first automation

1547
00:52:32,960 --> 00:52:34,960
before governance exists, you will fail.

1548
00:52:34,960 --> 00:52:37,680
The sequence matters because each step enables the next one.

1549
00:52:37,680 --> 00:52:39,440
The organizations that get this right

1550
00:52:39,440 --> 00:52:41,280
are the ones that accept this timeline.

1551
00:52:41,280 --> 00:52:42,720
They are not looking for a shortcut

1552
00:52:42,720 --> 00:52:45,280
or trying to compress six months into eight weeks.

1553
00:52:45,280 --> 00:52:46,800
They are doing the work in the right order

1554
00:52:46,800 --> 00:52:48,800
and trusting that the foundation will support everything

1555
00:52:48,800 --> 00:52:49,680
that comes after.

1556
00:52:49,680 --> 00:52:51,040
The starting point is boring.

1557
00:52:51,040 --> 00:52:52,880
It is not where the exciting part is

1558
00:52:52,880 --> 00:52:54,880
but it is where the real work lives and

1559
00:52:54,880 --> 00:52:56,240
measuring success.

1560
00:52:56,240 --> 00:52:57,600
What actually matters.

1561
00:52:57,600 --> 00:52:59,840
The uncomfortable part about building a platform

1562
00:52:59,840 --> 00:53:02,720
is that the metrics most organizations track are useless.

1563
00:53:02,720 --> 00:53:04,000
They measure lines of code.

1564
00:53:04,000 --> 00:53:06,320
The assumption is that more code means more work

1565
00:53:06,320 --> 00:53:08,160
which means more progress except it doesn't.

1566
00:53:08,160 --> 00:53:11,520
A platform with fewer better organized functions

1567
00:53:11,520 --> 00:53:13,920
that do more work is objectively superior

1568
00:53:13,920 --> 00:53:16,720
to a platform with sprawling scripts that do less.

1569
00:53:16,720 --> 00:53:18,320
They measure the number of automations.

1570
00:53:18,320 --> 00:53:19,520
We have 50 automations now.

1571
00:53:19,520 --> 00:53:20,720
We had 30 last year.

1572
00:53:20,720 --> 00:53:21,840
That sounds like progress.

1573
00:53:21,840 --> 00:53:23,760
But if you're building 50 fragile scripts

1574
00:53:23,760 --> 00:53:25,760
instead of five reliable systems

1575
00:53:25,760 --> 00:53:27,520
you've just increased your operational burden.

1576
00:53:27,520 --> 00:53:28,640
You didn't improve anything.

1577
00:53:28,640 --> 00:53:29,840
They measure budget spent.

1578
00:53:29,840 --> 00:53:31,680
How much did we invest in automation?

1579
00:53:31,680 --> 00:53:33,200
$50,000.

1580
00:53:33,200 --> 00:53:33,680
Great.

1581
00:53:33,680 --> 00:53:34,880
Now what did we get for it?

1582
00:53:34,880 --> 00:53:37,040
That's where most organizations go quiet.

1583
00:53:37,040 --> 00:53:38,000
They spent the money.

1584
00:53:38,000 --> 00:53:39,520
But they don't know if it actually mattered.

1585
00:53:39,520 --> 00:53:42,240
None of these metrics tell you whether the platform is actually working.

1586
00:53:42,240 --> 00:53:43,280
Here's what actually matters.

1587
00:53:43,280 --> 00:53:44,320
The first one is time.

1588
00:53:44,320 --> 00:53:45,840
How much manual work has actually gone away?

1589
00:53:45,840 --> 00:53:47,040
Not theoretical time?

1590
00:53:47,040 --> 00:53:48,240
Real time.

1591
00:53:48,240 --> 00:53:49,200
Before the platform,

1592
00:53:49,200 --> 00:53:51,200
someone spent 10 hours a week on a process

1593
00:53:51,200 --> 00:53:52,000
that's now automated

1594
00:53:52,000 --> 00:53:55,040
which adds up to 500 hours per year of freed up capacity.

1595
00:53:55,040 --> 00:53:57,200
That person can now do work that's actually valuable

1596
00:53:57,200 --> 00:53:58,720
instead of work a script could do

1597
00:53:58,720 --> 00:54:00,560
and because you can track this directly,

1598
00:54:00,560 --> 00:54:01,920
it is not hard to measure.

1599
00:54:01,920 --> 00:54:03,360
The second is reliability.

1600
00:54:03,360 --> 00:54:04,400
Before you had a platform,

1601
00:54:04,400 --> 00:54:06,240
automations were failing silently.

1602
00:54:06,240 --> 00:54:08,320
Things broke and nobody noticed for days.

1603
00:54:08,320 --> 00:54:10,560
Now in something breaks, you know about it in minutes.

1604
00:54:10,560 --> 00:54:12,720
The failure might not be resolved immediately.

1605
00:54:12,720 --> 00:54:13,840
But you know it happened.

1606
00:54:13,840 --> 00:54:16,080
The meantime to detection dropped from days to minutes.

1607
00:54:16,080 --> 00:54:17,840
Reliability became visible,

1608
00:54:17,840 --> 00:54:19,600
which means you can actually improve it.

1609
00:54:19,600 --> 00:54:21,200
The third is speed of response.

1610
00:54:21,200 --> 00:54:23,200
When the business asks for a new automation,

1611
00:54:23,200 --> 00:54:24,720
how long does it take to build it?

1612
00:54:24,720 --> 00:54:26,560
Before the platform, you'd say three weeks.

1613
00:54:26,560 --> 00:54:28,000
After three months of foundation building

1614
00:54:28,000 --> 00:54:29,360
and one completed automation,

1615
00:54:29,360 --> 00:54:30,240
you say one week.

1616
00:54:30,240 --> 00:54:31,680
By month 12, you say three days,

1617
00:54:31,680 --> 00:54:33,440
and that speed difference is worth millions

1618
00:54:33,440 --> 00:54:34,880
in competitive response time.

1619
00:54:34,880 --> 00:54:35,920
And it's completely measurable.

1620
00:54:35,920 --> 00:54:37,040
The fourth is confidence.

1621
00:54:37,040 --> 00:54:38,400
This one's harder to quantify.

1622
00:54:38,400 --> 00:54:39,120
But it's real.

1623
00:54:39,120 --> 00:54:40,160
Before the platform,

1624
00:54:40,160 --> 00:54:41,440
people don't trust automations.

1625
00:54:41,440 --> 00:54:42,720
They double check results.

1626
00:54:42,720 --> 00:54:44,400
They run manual verification.

1627
00:54:44,400 --> 00:54:45,680
They assume something's wrong

1628
00:54:45,680 --> 00:54:47,200
until proven otherwise.

1629
00:54:47,200 --> 00:54:48,320
After the platform,

1630
00:54:48,320 --> 00:54:49,760
people trust that the system works

1631
00:54:49,760 --> 00:54:52,400
because they know it's being monitored and reconciled daily.

1632
00:54:52,400 --> 00:54:54,320
And that shift from doubt to trust

1633
00:54:54,320 --> 00:54:56,320
changes how fast an organization can move.

1634
00:54:56,320 --> 00:54:59,920
When users stop performing secondary verification

1635
00:54:59,920 --> 00:55:01,040
on every output,

1636
00:55:01,040 --> 00:55:02,960
the entire workflow accelerates.

1637
00:55:02,960 --> 00:55:04,480
The last one is growth capacity.

1638
00:55:04,480 --> 00:55:07,040
This is the one that really matters for long term thinking.

1639
00:55:07,040 --> 00:55:09,040
Before the platform, adding a new automation

1640
00:55:09,040 --> 00:55:10,800
required the same effort as before.

1641
00:55:10,800 --> 00:55:12,160
Every single one costs the same.

1642
00:55:12,160 --> 00:55:12,960
You couldn't scale.

1643
00:55:12,960 --> 00:55:15,120
After the platform,

1644
00:55:15,120 --> 00:55:16,640
adding automation becomes trivial

1645
00:55:16,640 --> 00:55:18,160
because you're no longer limited by the effort

1646
00:55:18,160 --> 00:55:19,840
required to build each one.

1647
00:55:19,840 --> 00:55:22,480
But only by how many problems you actually want to solve.

1648
00:55:22,480 --> 00:55:25,840
That's the difference between a constraint on growth

1649
00:55:25,840 --> 00:55:27,200
and unlimited scaling.

1650
00:55:27,200 --> 00:55:29,120
Your measurement framework should be simple.

1651
00:55:29,120 --> 00:55:31,360
How many hours per week of manual work are gone?

1652
00:55:31,360 --> 00:55:32,240
Track it.

1653
00:55:32,240 --> 00:55:34,880
How many automation failures are detected within one hour?

1654
00:55:34,880 --> 00:55:35,280
Track it.

1655
00:55:35,280 --> 00:55:37,440
How long does it take from

1656
00:55:37,440 --> 00:55:38,800
we need to automate this?

1657
00:55:38,800 --> 00:55:40,720
Two, it's running in production.

1658
00:55:40,720 --> 00:55:41,360
Track it.

1659
00:55:41,360 --> 00:55:43,040
Are people trusting the automations?

1660
00:55:43,040 --> 00:55:44,160
Survey your users.

1661
00:55:44,160 --> 00:55:46,240
How many new automations are you able to build per month

1662
00:55:46,240 --> 00:55:47,520
compared to six months ago?

1663
00:55:47,520 --> 00:55:48,160
Track it.

1664
00:55:48,160 --> 00:55:49,600
These are the metrics that matter.

1665
00:55:49,600 --> 00:55:52,560
These are the metrics that tell you whether the platform is working.

1666
00:55:52,560 --> 00:55:54,160
Most organizations won't track these.

1667
00:55:54,160 --> 00:55:55,600
They'll keep measuring lines of code

1668
00:55:55,600 --> 00:55:57,520
and automation count and budget spent.

1669
00:55:57,520 --> 00:55:58,960
They'll feel good about their investment

1670
00:55:58,960 --> 00:56:00,640
because they feel like they're doing something.

1671
00:56:00,640 --> 00:56:02,640
But they won't actually know whether it's working.

1672
00:56:02,640 --> 00:56:05,040
The organizations that win are ruthless about this.

1673
00:56:05,040 --> 00:56:06,240
They define success upfront.

1674
00:56:06,240 --> 00:56:07,680
They measure it continuously.

1675
00:56:07,680 --> 00:56:10,000
They stop doing things that don't move the needle.

1676
00:56:10,000 --> 00:56:11,840
That clarity about what matters is the difference

1677
00:56:11,840 --> 00:56:13,280
between a platform that's real

1678
00:56:13,280 --> 00:56:14,960
and a platform that's theoretical.

1679
00:56:14,960 --> 00:56:16,000
The obstacles.

1680
00:56:16,000 --> 00:56:17,920
What actually stops organizations?

1681
00:56:17,920 --> 00:56:19,840
Here's what actually prevents most organizations

1682
00:56:19,840 --> 00:56:20,960
from building a platform.

1683
00:56:20,960 --> 00:56:21,760
Nothing technical.

1684
00:56:21,760 --> 00:56:23,600
The obstacles are purely organizational.

1685
00:56:23,600 --> 00:56:24,720
They're about comfort.

1686
00:56:24,720 --> 00:56:25,760
They're about inertia.

1687
00:56:25,760 --> 00:56:28,720
They're about the gap between knowing something needs to change

1688
00:56:28,720 --> 00:56:30,800
and actually being willing to do the work to change it.

1689
00:56:30,800 --> 00:56:32,960
The first obstacle is status quo bias.

1690
00:56:32,960 --> 00:56:33,760
Scripts exist.

1691
00:56:33,760 --> 00:56:34,960
They work most of the time.

1692
00:56:34,960 --> 00:56:35,600
They're messy.

1693
00:56:35,600 --> 00:56:36,320
They're fragile.

1694
00:56:36,320 --> 00:56:38,560
They'll break when the person who built them leaves.

1695
00:56:38,560 --> 00:56:39,440
But they're here now.

1696
00:56:39,440 --> 00:56:40,160
They're familiar.

1697
00:56:40,160 --> 00:56:40,960
They have a rhythm.

1698
00:56:40,960 --> 00:56:43,520
The operations team knows how to fix them when they break.

1699
00:56:43,520 --> 00:56:45,920
And while there is an established process for this chaos,

1700
00:56:45,920 --> 00:56:48,720
the reality is that people would rather live with known problems

1701
00:56:48,720 --> 00:56:51,280
than adopt solutions with unpredictable risks.

1702
00:56:51,280 --> 00:56:53,680
Asking an organization to move away from that familiar mess

1703
00:56:53,680 --> 00:56:55,840
requires them to accept short-term friction

1704
00:56:55,840 --> 00:56:58,160
for a long-term benefit they haven't seen yet.

1705
00:56:58,160 --> 00:57:00,320
But here's the thing that usually shifts this.

1706
00:57:00,320 --> 00:57:02,480
It's not the awareness that something's broken.

1707
00:57:02,480 --> 00:57:03,840
It's the experience of total failure.

1708
00:57:03,840 --> 00:57:06,000
When something goes catastrophically wrong,

1709
00:57:06,000 --> 00:57:08,160
that's when organizations get serious about change.

1710
00:57:08,160 --> 00:57:10,960
A critical automation fails and stays broken for days.

1711
00:57:10,960 --> 00:57:11,840
Data is lost.

1712
00:57:11,840 --> 00:57:13,520
A compliance deadline is missed.

1713
00:57:13,520 --> 00:57:15,760
Before that moment platforms are nice to have.

1714
00:57:15,760 --> 00:57:17,920
After that moment, they're non-negotiable.

1715
00:57:17,920 --> 00:57:20,720
The second obstacle is investment required.

1716
00:57:20,720 --> 00:57:21,920
You're going to spend money.

1717
00:57:21,920 --> 00:57:22,640
Real money.

1718
00:57:22,640 --> 00:57:24,720
$250,000 in year one.

1719
00:57:24,720 --> 00:57:25,440
That's visible.

1720
00:57:25,440 --> 00:57:27,200
The CFO sees that number and it's real.

1721
00:57:27,200 --> 00:57:29,600
But what the CFO doesn't see is the $500,000

1722
00:57:29,600 --> 00:57:31,520
you're already spending on operational overhead

1723
00:57:31,520 --> 00:57:32,880
for broken automations.

1724
00:57:32,880 --> 00:57:35,600
That money is invisible because it's spread across multiple budgets,

1725
00:57:35,600 --> 00:57:38,000
lost in firefighting and the cost of people working on problems

1726
00:57:38,000 --> 00:57:39,360
that shouldn't even exist.

1727
00:57:39,360 --> 00:57:40,480
Here's where this gets interesting.

1728
00:57:40,480 --> 00:57:41,920
The organizations that move forward

1729
00:57:41,920 --> 00:57:43,840
are the ones that accept the visible cost

1730
00:57:43,840 --> 00:57:45,440
to eliminate the invisible one.

1731
00:57:45,440 --> 00:57:46,640
The ones that don't.

1732
00:57:46,640 --> 00:57:49,600
Are the ones that keep hoping someone will invent a free platform

1733
00:57:49,600 --> 00:57:51,280
that magically solves everything

1734
00:57:51,280 --> 00:57:53,760
without requiring investment or change.

1735
00:57:53,760 --> 00:57:56,000
The third obstacle is the most serious.

1736
00:57:56,000 --> 00:57:57,760
Organizational change is hard.

1737
00:57:57,760 --> 00:58:00,640
You're asking the platform team to adopt new responsibilities.

1738
00:58:00,640 --> 00:58:03,040
You're asking automation teams to work differently.

1739
00:58:03,040 --> 00:58:04,880
You're asking the governance committee to exist.

1740
00:58:04,880 --> 00:58:07,200
You're asking people to move slower to go faster.

1741
00:58:07,200 --> 00:58:09,520
You're asking security to trust new processes.

1742
00:58:09,520 --> 00:58:12,000
You're asking compliance to validate new models.

1743
00:58:12,000 --> 00:58:13,040
All of that is friction.

1744
00:58:13,040 --> 00:58:14,640
All of that generates resistance.

1745
00:58:14,640 --> 00:58:17,360
When you propose this, you'll hear predictable objections.

1746
00:58:17,360 --> 00:58:18,880
This adds bureaucracy.

1747
00:58:18,880 --> 00:58:20,320
Teams need autonomy.

1748
00:58:20,320 --> 00:58:22,720
The governance committee will slow us down.

1749
00:58:22,720 --> 00:58:24,400
Why do we need all this structure?

1750
00:58:24,400 --> 00:58:26,640
Each of these objections sounds reasonable.

1751
00:58:26,640 --> 00:58:28,400
Each one contains a grain of truth

1752
00:58:28,400 --> 00:58:30,880
and each one is also wrong in the context of scale.

1753
00:58:30,880 --> 00:58:33,360
You can run with autonomy when you have 50 scripts

1754
00:58:33,360 --> 00:58:35,920
but you simply cannot do it when you have 500.

1755
00:58:35,920 --> 00:58:38,400
The governance committee feels like bureaucracy

1756
00:58:38,400 --> 00:58:40,240
until you realize that without it,

1757
00:58:40,240 --> 00:58:42,480
incompatible automation starts getting built

1758
00:58:42,480 --> 00:58:44,160
and they conflict in production.

1759
00:58:44,160 --> 00:58:46,880
Structure feels slow until you realize that without it,

1760
00:58:46,880 --> 00:58:49,120
moving fast means breaking things constantly.

1761
00:58:49,120 --> 00:58:50,880
But the objections feel true in the moment,

1762
00:58:50,880 --> 00:58:51,920
so people don't move.

1763
00:58:51,920 --> 00:58:54,080
The organizations that move are the ones with leadership

1764
00:58:54,080 --> 00:58:56,480
that says, "This is the direction we're going."

1765
00:58:56,480 --> 00:58:57,680
Not because it's comfortable,

1766
00:58:57,680 --> 00:58:59,600
because it's necessary they set the pace.

1767
00:58:59,600 --> 00:59:00,960
They hold people accountable to it.

1768
00:59:00,960 --> 00:59:03,600
They invest in training, so teams understand why the new model works.

1769
00:59:03,600 --> 00:59:05,120
They celebrate early wins,

1770
00:59:05,120 --> 00:59:07,360
so people see that the new way is actually better.

1771
00:59:07,360 --> 00:59:09,120
Without that leadership, the obstacles win.

1772
00:59:09,120 --> 00:59:11,040
The organization stays with scripts.

1773
00:59:11,040 --> 00:59:12,080
They keep adding more.

1774
00:59:12,080 --> 00:59:14,080
They keep hoping someone invents a magic solution

1775
00:59:14,080 --> 00:59:15,360
that requires no change.

1776
00:59:15,360 --> 00:59:18,480
And by 2028, when agents are mandatory infrastructure,

1777
00:59:18,480 --> 00:59:20,000
they're still managing power shell.

1778
00:59:20,000 --> 00:59:22,080
That's not because leadership is incompetent.

1779
00:59:22,080 --> 00:59:24,000
It's because change is genuinely hard.

1780
00:59:24,000 --> 00:59:26,640
But the organizations that accept that difficulty win,

1781
00:59:26,640 --> 00:59:28,320
the ones that try to avoid it lose.

1782
00:59:28,320 --> 00:59:29,680
The obstacle isn't the platform,

1783
00:59:29,680 --> 00:59:31,360
it's the willingness to change.

1784
00:59:31,360 --> 00:59:34,640
CI/CD for PowerShell, engineering standards.

1785
00:59:34,640 --> 00:59:37,440
This is where the shift from scripts to platforms becomes real.

1786
00:59:37,440 --> 00:59:40,480
Most organizations treat power shell scripts like documentation.

1787
00:59:40,480 --> 00:59:41,280
You write them.

1788
00:59:41,280 --> 00:59:42,240
They exist.

1789
00:59:42,240 --> 00:59:43,040
They run.

1790
00:59:43,040 --> 00:59:44,800
But nobody is policing the quality.

1791
00:59:44,800 --> 00:59:46,480
Nobody is checking for standards.

1792
00:59:46,480 --> 00:59:50,320
And nobody is verifying that a stranger could understand that code six months from now.

1793
00:59:50,320 --> 00:59:52,080
This is where enterprises fail at scale.

1794
00:59:52,080 --> 00:59:54,800
The moment you move from individual scripts to a platform,

1795
00:59:54,800 --> 00:59:56,720
your code stops being a quick fix.

1796
00:59:56,720 --> 00:59:58,720
It becomes enterprise infrastructure.

1797
00:59:58,720 --> 00:59:59,760
That isn't a metaphor.

1798
00:59:59,760 --> 01:00:00,640
It's a requirement.

1799
01:00:00,640 --> 01:00:02,800
In a real platform,

1800
01:00:02,800 --> 01:00:04,800
every script repository is version controlled.

1801
01:00:04,800 --> 01:00:05,840
Every change is tracked.

1802
01:00:05,840 --> 01:00:07,280
Every version is retrievable.

1803
01:00:07,280 --> 01:00:09,120
When a script breaks something in production,

1804
01:00:09,120 --> 01:00:10,160
you have a history.

1805
01:00:10,160 --> 01:00:11,920
You can see who changed it when they did it

1806
01:00:11,920 --> 01:00:13,520
and why they thought it was a good idea.

1807
01:00:13,520 --> 01:00:16,240
For anything touching production, this is non-negotiable.

1808
01:00:16,240 --> 01:00:18,080
Version control means you're using Git.

1809
01:00:18,080 --> 01:00:19,120
You're likely on GitHub.

1810
01:00:19,120 --> 01:00:20,560
You're creating branches for changes

1811
01:00:20,560 --> 01:00:23,600
and using pull requests instead of committing directly to the main code.

1812
01:00:23,600 --> 01:00:25,600
A pull request means a second pair of eyes

1813
01:00:25,600 --> 01:00:27,520
reviews the code before it ever runs.

1814
01:00:27,520 --> 01:00:28,560
They check for mistakes.

1815
01:00:28,560 --> 01:00:30,000
They verify standards.

1816
01:00:30,000 --> 01:00:32,480
They catch the small things the original author missed

1817
01:00:32,480 --> 01:00:34,160
because they were too close to the problem.

1818
01:00:34,160 --> 01:00:35,440
If you've never worked this way,

1819
01:00:35,440 --> 01:00:36,880
it feels like bureaucracy.

1820
01:00:36,880 --> 01:00:38,160
It feels like friction.

1821
01:00:38,160 --> 01:00:40,160
But the first time someone makes a breaking change

1822
01:00:40,160 --> 01:00:42,720
and you revert it in 30 seconds because you have a history.

1823
01:00:42,720 --> 01:00:44,320
You finally understand why it matters.

1824
01:00:44,320 --> 01:00:46,640
Enterprise infrastructure also gets tested.

1825
01:00:46,640 --> 01:00:49,360
Not, I ran it once on my machine testing.

1826
01:00:49,360 --> 01:00:50,560
Actual test cases.

1827
01:00:50,560 --> 01:00:52,960
You need unit tests to verify individual functions

1828
01:00:52,960 --> 01:00:55,120
and integration tests to ensure the script

1829
01:00:55,120 --> 01:00:56,800
actually talks to the right systems.

1830
01:00:56,800 --> 01:00:58,320
You have to test against failure.

1831
01:00:58,320 --> 01:00:59,840
What happens when the database is down,

1832
01:00:59,840 --> 01:01:00,960
the network times out

1833
01:01:00,960 --> 01:01:03,040
or the input data is complete garbage?

1834
01:01:03,040 --> 01:01:05,040
In the PowerShell world, this means PESTA.

1835
01:01:05,040 --> 01:01:07,440
PESTA is the framework that verifies your functions,

1836
01:01:07,440 --> 01:01:09,200
work exactly how they're supposed to.

1837
01:01:09,200 --> 01:01:12,080
You run these tests automatically every time someone commits code.

1838
01:01:12,080 --> 01:01:13,920
If the tests fail, the code doesn't merge.

1839
01:01:13,920 --> 01:01:15,840
This is where real quality control happens.

1840
01:01:15,840 --> 01:01:16,960
It's not about testing by hand.

1841
01:01:16,960 --> 01:01:20,080
It's about automated rigor that runs the same way every single time.

1842
01:01:20,080 --> 01:01:23,440
Finally, Enterprise Infrastructure gets released through pipelines.

1843
01:01:23,440 --> 01:01:25,280
You don't copy files to servers.

1844
01:01:25,280 --> 01:01:28,400
A deployment pipeline means you aren't logging into a box to run a script.

1845
01:01:28,400 --> 01:01:30,000
You're triggering an automated process.

1846
01:01:30,000 --> 01:01:32,400
The pipeline pulls the code, runs the tests,

1847
01:01:32,400 --> 01:01:34,800
and if everything passes, it deploys to staging.

1848
01:01:34,800 --> 01:01:37,040
Once you verify it there, it moves to production.

1849
01:01:37,040 --> 01:01:39,280
Every step is logged, every deployment is auditable.

1850
01:01:39,280 --> 01:01:41,440
This requires GitHub actions or Azure DevOps

1851
01:01:41,440 --> 01:01:43,200
to define your deployment as code.

1852
01:01:43,200 --> 01:01:45,600
The process becomes repeatable and consistent.

1853
01:01:45,600 --> 01:01:47,440
It no longer depends on a specific person

1854
01:01:47,440 --> 01:01:49,680
remembering the right way to do it.

1855
01:01:49,680 --> 01:01:52,000
For critical automation, this isn't a luxury.

1856
01:01:52,000 --> 01:01:54,240
It's the infrastructure that lets your team move fast

1857
01:01:54,240 --> 01:01:55,440
without breaking the world.

1858
01:01:55,440 --> 01:01:58,160
The shift from scripts to platforms is a shift in mindset.

1859
01:01:58,160 --> 01:02:00,160
You aren't just writing code anymore.

1860
01:02:00,160 --> 01:02:01,680
You're contributing to infrastructure.

1861
01:02:01,680 --> 01:02:02,640
It means code reviews.

1862
01:02:02,640 --> 01:02:03,840
It means automated testing.

1863
01:02:03,840 --> 01:02:05,520
It means accountability.

1864
01:02:05,520 --> 01:02:06,960
It's uncomfortable at first.

1865
01:02:06,960 --> 01:02:08,880
But once you've built a platform this way,

1866
01:02:08,880 --> 01:02:11,200
you can't imagine going back to the old model.

1867
01:02:11,200 --> 01:02:12,800
Organizations with real platforms

1868
01:02:12,800 --> 01:02:14,880
have professional engineering practices.

1869
01:02:14,880 --> 01:02:17,920
Organizations that are just managing scripts don't.

1870
01:02:17,920 --> 01:02:19,760
That's the difference.

1871
01:02:19,760 --> 01:02:20,720
Transition.

1872
01:02:20,720 --> 01:02:23,280
Professional engineering requires the right tools,

1873
01:02:23,280 --> 01:02:24,960
but it also requires one more thing.

1874
01:02:24,960 --> 01:02:26,880
Understanding how your code actually fails

1875
01:02:26,880 --> 01:02:28,960
when it's running at scale.

1876
01:02:28,960 --> 01:02:31,360
Secrets management and key vault integration

1877
01:02:31,360 --> 01:02:33,920
manage identities solve a huge problem.

1878
01:02:33,920 --> 01:02:37,120
Your functions and logic apps don't need to store credentials anymore.

1879
01:02:37,120 --> 01:02:39,200
But the moment your code runs outside Azure,

1880
01:02:39,200 --> 01:02:39,840
things break.

1881
01:02:39,840 --> 01:02:41,440
Maybe it's an on-premises server.

1882
01:02:41,440 --> 01:02:43,840
Maybe it's a third-party tool or a GitHub action.

1883
01:02:43,840 --> 01:02:45,840
Suddenly, you're back to managing secrets.

1884
01:02:45,840 --> 01:02:47,520
And that's where most platforms collapse.

1885
01:02:47,520 --> 01:02:49,200
Here is what happens in reality.

1886
01:02:49,200 --> 01:02:52,000
A developer needs an API key for an external service.

1887
01:02:52,000 --> 01:02:53,280
They put it in a config file.

1888
01:02:53,280 --> 01:02:54,720
They check that file into Git.

1889
01:02:54,720 --> 01:02:57,840
Six months later, someone finds that key in the history

1890
01:02:57,840 --> 01:02:59,680
and uses it to compromise the service.

1891
01:02:59,680 --> 01:03:00,560
Or worse.

1892
01:03:00,560 --> 01:03:02,560
They find it after the damage is already done.

1893
01:03:02,560 --> 01:03:05,120
This happens because people treat secrets like configuration.

1894
01:03:05,120 --> 01:03:06,080
They aren't the same.

1895
01:03:06,080 --> 01:03:07,840
Configuration changes.

1896
01:03:07,840 --> 01:03:09,440
But secrets rot.

1897
01:03:09,440 --> 01:03:12,080
The longer a secret exists, the more vulnerable it becomes

1898
01:03:12,080 --> 01:03:14,640
to being leaked, sold, or accidentally exposed.

1899
01:03:14,640 --> 01:03:17,680
The platform approach treats secrets as managed infrastructure.

1900
01:03:17,680 --> 01:03:18,800
You never store them in code.

1901
01:03:18,800 --> 01:03:20,240
You never check them into Git.

1902
01:03:20,240 --> 01:03:21,760
You store them in Azure Key Vault.

1903
01:03:21,760 --> 01:03:24,000
Your applications fetch them only when they need them.

1904
01:03:24,000 --> 01:03:25,520
Key Vault handles the security.

1905
01:03:25,520 --> 01:03:26,720
You handle the policy.

1906
01:03:26,720 --> 01:03:29,120
This requires a pattern most developers aren't used to.

1907
01:03:29,120 --> 01:03:31,520
When your code starts, it doesn't read a local file.

1908
01:03:31,520 --> 01:03:34,400
It authenticates to Key Vault using a managed identity.

1909
01:03:34,400 --> 01:03:35,360
It fetches the secret.

1910
01:03:35,360 --> 01:03:36,000
It uses it.

1911
01:03:36,000 --> 01:03:38,880
And it never keeps that secret in memory longer than it has to.

1912
01:03:38,880 --> 01:03:40,240
In a logic app, this is easy.

1913
01:03:40,240 --> 01:03:41,760
You use the Key Vault action

1914
01:03:41,760 --> 01:03:43,520
and reference the secret by name.

1915
01:03:43,520 --> 01:03:45,440
In a function, you use the Azure identity

1916
01:03:45,440 --> 01:03:48,080
and Key Vault packages to create a client and pull the value.

1917
01:03:48,080 --> 01:03:50,000
It's a standard, repeatable code pattern.

1918
01:03:50,000 --> 01:03:52,320
But the operational side is where this gets interesting.

1919
01:03:52,320 --> 01:03:54,160
Someone has to manage the life cycle.

1920
01:03:54,160 --> 01:03:55,120
Secrets expire.

1921
01:03:55,120 --> 01:03:55,920
They rotate.

1922
01:03:55,920 --> 01:03:57,520
Occasionally, they get compromised.

1923
01:03:57,520 --> 01:03:59,040
Here is the model that actually works.

1924
01:03:59,040 --> 01:04:00,560
When you create a secret in Key Vault,

1925
01:04:00,560 --> 01:04:02,000
you set an expiration date.

1926
01:04:02,000 --> 01:04:04,160
90 days is standard for critical keys.

1927
01:04:04,160 --> 01:04:06,240
30 days if you're touching regulated data.

1928
01:04:06,240 --> 01:04:07,600
Key Vault sends a notification

1929
01:04:07,600 --> 01:04:09,360
when that secret is about to die.

1930
01:04:09,360 --> 01:04:10,880
Your team can rotate it manually,

1931
01:04:10,880 --> 01:04:12,320
or better yet, automated.

1932
01:04:12,320 --> 01:04:14,080
You can use a function to update the secret

1933
01:04:14,080 --> 01:04:16,640
in the external system and then update Key Vault.

1934
01:04:16,640 --> 01:04:17,920
It sounds manual at first,

1935
01:04:17,920 --> 01:04:20,880
but once the pattern exists, it's fully automatable.

1936
01:04:20,880 --> 01:04:22,320
A function can call an API

1937
01:04:22,320 --> 01:04:24,000
to generate a new credential,

1938
01:04:24,000 --> 01:04:25,680
update the Vault and test the new key

1939
01:04:25,680 --> 01:04:27,360
before it ever kills the old one.

1940
01:04:27,360 --> 01:04:29,680
Organizations with real platforms automate this.

1941
01:04:29,680 --> 01:04:31,200
The ones managing secrets manually

1942
01:04:31,200 --> 01:04:33,200
spend hours every quarter rotating keys.

1943
01:04:33,200 --> 01:04:34,800
The ones with automation spend nothing.

1944
01:04:34,800 --> 01:04:36,080
Then there's access control.

1945
01:04:36,080 --> 01:04:38,320
Not everyone on the team should see production secrets.

1946
01:04:38,320 --> 01:04:40,480
Key Vault has fine-grained control built in.

1947
01:04:40,480 --> 01:04:42,640
You can allow a managed identity to read secrets

1948
01:04:42,640 --> 01:04:44,080
while allowing a user to rotate them

1949
01:04:44,080 --> 01:04:45,280
without ever seeing the value.

1950
01:04:45,280 --> 01:04:47,120
You can audit every single access.

1951
01:04:47,120 --> 01:04:49,840
You can revoke access the second someone leaves the company.

1952
01:04:49,840 --> 01:04:52,480
Without this, secrets are a governance nightmare.

1953
01:04:52,480 --> 01:04:54,480
When someone leaves, you don't know what they copied.

1954
01:04:54,480 --> 01:04:56,400
You have to rotate everything just to be safe.

1955
01:04:56,400 --> 01:04:58,240
Without Key Vault, you're doing that manually

1956
01:04:58,240 --> 01:04:59,520
for dozens of systems.

1957
01:04:59,520 --> 01:05:02,240
With Key Vault, you manage it through one interface.

1958
01:05:02,240 --> 01:05:04,240
The shift from storing credentials and files

1959
01:05:04,240 --> 01:05:07,680
to managing them in Key Vault is the shift from operational risk.

1960
01:05:07,680 --> 01:05:09,200
To operational control,

1961
01:05:09,200 --> 01:05:12,000
event-driven architectures and graph subscriptions.

1962
01:05:12,000 --> 01:05:13,360
Everything we've built so far.

1963
01:05:13,360 --> 01:05:14,880
The managed identities, the governance,

1964
01:05:14,880 --> 01:05:16,240
the reconciliation layers,

1965
01:05:16,240 --> 01:05:17,600
and that's just the foundation.

1966
01:05:17,600 --> 01:05:19,120
But what actually uses that foundation?

1967
01:05:19,120 --> 01:05:22,080
In 2026, the answer is event-driven architecture.

1968
01:05:22,080 --> 01:05:24,160
Moving from scripts to platforms is really a shift

1969
01:05:24,160 --> 01:05:25,200
in how you think about time.

1970
01:05:25,200 --> 01:05:26,880
In the old model, you think in batches.

1971
01:05:26,880 --> 01:05:28,160
You do work on a schedule.

1972
01:05:28,160 --> 01:05:30,560
Run the sync every hour, process the queue every night,

1973
01:05:30,560 --> 01:05:32,080
reconcile the state every week.

1974
01:05:32,080 --> 01:05:33,120
But this creates a gap.

1975
01:05:33,120 --> 01:05:35,680
A customer places an order at 247 pm.

1976
01:05:35,680 --> 01:05:38,480
Your system doesn't even see it until the 3 pm batch run.

1977
01:05:38,480 --> 01:05:40,320
The delay is built into the design.

1978
01:05:40,320 --> 01:05:43,120
In the event-driven model, you respond the moment it happens.

1979
01:05:43,120 --> 01:05:45,120
The customer orders at 247 pm.

1980
01:05:45,120 --> 01:05:47,040
Your system knows about it three seconds later.

1981
01:05:47,040 --> 01:05:48,320
This matters more than it sounds.

1982
01:05:48,320 --> 01:05:50,720
A 30-minute delay seems small on its own.

1983
01:05:50,720 --> 01:05:53,360
But when you multiply that across thousands of processes,

1984
01:05:53,360 --> 01:05:54,400
things start to break.

1985
01:05:54,400 --> 01:05:55,600
Data gets out of sync.

1986
01:05:55,600 --> 01:05:56,720
Assumptions fail.

1987
01:05:56,720 --> 01:05:59,680
Work just sits there waiting for a batch that hasn't started yet.

1988
01:05:59,680 --> 01:06:01,920
This is where graph subscriptions become critical.

1989
01:06:01,920 --> 01:06:05,440
A subscription means that when something changes in Microsoft 365,

1990
01:06:05,440 --> 01:06:07,520
your system hears about it immediately.

1991
01:06:07,520 --> 01:06:08,560
A new email arrives.

1992
01:06:08,560 --> 01:06:09,600
A file gets updated.

1993
01:06:09,600 --> 01:06:10,960
A user is created in Android.

1994
01:06:10,960 --> 01:06:13,520
The subscription fires and your system responds in seconds

1995
01:06:13,520 --> 01:06:15,440
instead of waiting for a clock to hit the hour.

1996
01:06:15,440 --> 01:06:17,600
But immediate response creates a new problem.

1997
01:06:17,600 --> 01:06:19,840
What happens when a thousand events arrive at once

1998
01:06:19,840 --> 01:06:21,200
and your system isn't ready?

1999
01:06:21,200 --> 01:06:22,240
The answer is a queue.

2000
01:06:22,240 --> 01:06:24,080
Events hit your subscription endpoint.

2001
01:06:24,080 --> 01:06:25,920
But your logic app doesn't process them yet.

2002
01:06:25,920 --> 01:06:27,680
It drops them into a service bus queue.

2003
01:06:27,680 --> 01:06:30,960
Then a separate system drains that queue at whatever pace it can actually handle.

2004
01:06:30,960 --> 01:06:32,800
Spikes and activity don't crash your system

2005
01:06:32,800 --> 01:06:34,640
because the queue absorbs the shock.

2006
01:06:34,640 --> 01:06:36,800
Your system just keeps processing steadily,

2007
01:06:36,800 --> 01:06:38,480
no matter how many events are piling up.

2008
01:06:38,480 --> 01:06:40,240
This is where platform thinking gets interesting.

2009
01:06:40,240 --> 01:06:42,480
You aren't processing things one to one anymore.

2010
01:06:42,480 --> 01:06:44,080
You're moving to an asynchronous model

2011
01:06:44,080 --> 01:06:46,000
where the queue provides the resilience.

2012
01:06:46,000 --> 01:06:48,880
If your processing system goes down, the queue stays up.

2013
01:06:48,880 --> 01:06:50,320
When the system comes back online,

2014
01:06:50,320 --> 01:06:52,880
it just picks up where it left off and clears the backlog.

2015
01:06:52,880 --> 01:06:55,680
The Delta query we talked about earlier fits right into this.

2016
01:06:55,680 --> 01:06:57,280
It isn't just for reconciliation.

2017
01:06:57,280 --> 01:06:59,920
It's the safety net for when a subscription misses an event.

2018
01:06:59,920 --> 01:07:01,920
The subscription handles the real-time flow.

2019
01:07:01,920 --> 01:07:04,960
The Delta query runs once a day to catch the gaps.

2020
01:07:04,960 --> 01:07:07,760
Your processing system doesn't care where the data came from.

2021
01:07:07,760 --> 01:07:09,760
It just sees work in the queue and does it.

2022
01:07:09,760 --> 01:07:11,200
Real enterprise work is messy.

2023
01:07:11,200 --> 01:07:12,400
An order arrives.

2024
01:07:12,400 --> 01:07:14,400
You have to read it, check inventory,

2025
01:07:14,400 --> 01:07:16,960
call a fulfillment system, update a database,

2026
01:07:16,960 --> 01:07:18,240
and send a confirmation.

2027
01:07:18,240 --> 01:07:20,640
If the fulfillment system is down, does the whole thing stop?

2028
01:07:20,640 --> 01:07:21,680
Does it just fail?

2029
01:07:21,680 --> 01:07:23,600
The platform pattern breaks this into steps.

2030
01:07:23,600 --> 01:07:26,320
The subscription triggers and queues the order for validation.

2031
01:07:26,320 --> 01:07:29,520
A function validates it and either moves it to the next queue

2032
01:07:29,520 --> 01:07:31,520
or sends it to an error log.

2033
01:07:31,520 --> 01:07:34,560
The fulfillment function then picks it up and updates the database.

2034
01:07:34,560 --> 01:07:36,560
At every step, the failure is isolated.

2035
01:07:36,560 --> 01:07:39,360
A problem with fulfillment doesn't stop the validation step.

2036
01:07:39,360 --> 01:07:41,760
A system being down doesn't break the entire pipeline.

2037
01:07:41,760 --> 01:07:43,520
We call this event choreography.

2038
01:07:43,520 --> 01:07:45,680
Systems don't just follow a list of instructions.

2039
01:07:45,680 --> 01:07:46,960
They react to each other.

2040
01:07:46,960 --> 01:07:49,680
It works like a conversation instead of a rigid procedure.

2041
01:07:49,680 --> 01:07:52,960
The organization's building real platforms have made this mental shift.

2042
01:07:52,960 --> 01:07:54,720
They don't ask how do I call this system.

2043
01:07:54,720 --> 01:07:58,240
They ask how does this system emit events that others can react to?

2044
01:07:58,240 --> 01:08:00,400
It's a different way of working, but once you have it,

2045
01:08:00,400 --> 01:08:01,680
scaling becomes manageable.

2046
01:08:01,680 --> 01:08:03,840
You aren't building brittle connected pipes.

2047
01:08:03,840 --> 01:08:06,800
You're building a fabric where systems talk through events.

2048
01:08:06,800 --> 01:08:10,160
AI enhanced workflows and the 2026 landscape.

2049
01:08:10,160 --> 01:08:12,160
The infrastructure we've been talking about.

2050
01:08:12,160 --> 01:08:14,080
The subscriptions, the queues, the governance.

2051
01:08:14,080 --> 01:08:15,760
These aren't just nice to have.

2052
01:08:15,760 --> 01:08:18,160
They are the only reason AI works at scale.

2053
01:08:18,160 --> 01:08:22,000
Most companies are treating AI the same way they treated automation back in 2020.

2054
01:08:22,000 --> 01:08:22,960
They see a new tool.

2055
01:08:22,960 --> 01:08:23,920
They want the results.

2056
01:08:23,920 --> 01:08:25,120
So they build something fast.

2057
01:08:25,120 --> 01:08:27,040
And then the problem start.

2058
01:08:27,040 --> 01:08:30,000
Data governance breaks because the AI is touching systems

2059
01:08:30,000 --> 01:08:31,520
with no permission models.

2060
01:08:31,520 --> 01:08:34,400
Security is at risk because there are no audit trails.

2061
01:08:34,400 --> 01:08:36,480
Costs explode because nobody realized what happens

2062
01:08:36,480 --> 01:08:38,080
when you run a million operations.

2063
01:08:38,080 --> 01:08:40,320
The platform approach stops this before it starts.

2064
01:08:40,320 --> 01:08:41,520
Look at a real scenario.

2065
01:08:41,520 --> 01:08:44,240
You want to use generative AI to help your support team.

2066
01:08:44,240 --> 01:08:46,560
The plan is to feed customer data to an LLM,

2067
01:08:46,560 --> 01:08:49,120
get a suggested response, and let the agent send it.

2068
01:08:49,120 --> 01:08:50,240
The benefit is clear.

2069
01:08:50,240 --> 01:08:51,840
Your team handles twice the tickets.

2070
01:08:51,840 --> 01:08:54,400
In an unmanaged model, you just connect the API and go.

2071
01:08:54,400 --> 01:08:55,280
You pass the data.

2072
01:08:55,280 --> 01:08:56,160
You get the answer.

2073
01:08:56,160 --> 01:08:57,040
You're done.

2074
01:08:57,040 --> 01:08:58,480
But the problems show up later.

2075
01:08:58,480 --> 01:09:00,640
You realize sensitive data is leaving your network

2076
01:09:00,640 --> 01:09:02,000
and going to an external model.

2077
01:09:02,000 --> 01:09:03,280
That's a compliance failure.

2078
01:09:03,280 --> 01:09:05,760
The model hallucinates and gives a customer bad advice.

2079
01:09:05,760 --> 01:09:06,880
That's a brand failure.

2080
01:09:06,880 --> 01:09:09,040
Then you see the bill is $50,000 a month.

2081
01:09:09,040 --> 01:09:10,080
That's a budget failure.

2082
01:09:10,080 --> 01:09:11,360
The platform approach is different.

2083
01:09:11,360 --> 01:09:14,160
The AI isn't connected directly to the support tool.

2084
01:09:14,160 --> 01:09:16,000
It's connected through your orchestration layer.

2085
01:09:16,000 --> 01:09:18,640
Only safe classified data ever reaches the model.

2086
01:09:18,640 --> 01:09:19,840
Every response is logged.

2087
01:09:19,840 --> 01:09:21,120
Every sentence is monitored.

2088
01:09:21,120 --> 01:09:23,360
If the cost hits a limit, the system automatically

2089
01:09:23,360 --> 01:09:24,640
scales back the feature.

2090
01:09:24,640 --> 01:09:26,480
This requires real infrastructure.

2091
01:09:26,480 --> 01:09:29,440
You need a governance layer to decide what data can leave.

2092
01:09:29,440 --> 01:09:32,560
You need a monitoring layer to track what the AI is actually doing.

2093
01:09:32,560 --> 01:09:35,360
You need a reconciliation loop to catch the hallucinations.

2094
01:09:35,360 --> 01:09:37,760
It's more complex than just plugging in an API.

2095
01:09:37,760 --> 01:09:40,560
But it's the difference between a system you can trust

2096
01:09:40,560 --> 01:09:42,880
and a security incident waiting to happen.

2097
01:09:42,880 --> 01:09:45,360
By 2006, the companies winning with AI

2098
01:09:45,360 --> 01:09:47,600
are the ones who built this foundation first.

2099
01:09:47,600 --> 01:09:48,960
The ones moving fast

2100
01:09:48,960 --> 01:09:51,280
are the ones who will have to rebuild everything later

2101
01:09:51,280 --> 01:09:52,560
at a much higher cost.

2102
01:09:52,560 --> 01:09:54,720
Or worse, they'll have an incident that forces them

2103
01:09:54,720 --> 01:09:56,000
to shut the whole thing down.

2104
01:09:56,000 --> 01:09:58,240
The agents we discussed earlier aren't a separate thing.

2105
01:09:58,240 --> 01:10:00,320
They are an extension of the same pattern.

2106
01:10:00,320 --> 01:10:02,800
When an agent creates a record or updates a system,

2107
01:10:02,800 --> 01:10:05,040
it flows through the same orchestration layer.

2108
01:10:05,040 --> 01:10:06,320
The same governance applies.

2109
01:10:06,320 --> 01:10:08,560
The same audit trail records the action.

2110
01:10:08,560 --> 01:10:09,840
This is why platforms matter.

2111
01:10:09,840 --> 01:10:10,960
It's not about being elegant.

2112
01:10:10,960 --> 01:10:13,280
It's about being operationally survivable.

2113
01:10:13,280 --> 01:10:15,120
You can use the most advanced tools in the world

2114
01:10:15,120 --> 01:10:17,280
without creating a risk your company can't handle.

2115
01:10:17,280 --> 01:10:19,040
The real value isn't the AI itself.

2116
01:10:19,040 --> 01:10:22,320
It's the infrastructure that makes the AI safe to use.

2117
01:10:22,320 --> 01:10:23,840
Stop thinking about the next script.

2118
01:10:23,840 --> 01:10:25,520
Stop thinking about the next automation.

2119
01:10:25,520 --> 01:10:27,840
Start thinking about the infrastructure beneath it.

2120
01:10:27,840 --> 01:10:30,800
Because by 2028, the winners won't be the ones with the most tools.

2121
01:10:30,800 --> 01:10:32,800
They'll be the ones with the strongest platforms.

2122
01:10:32,800 --> 01:10:34,000
Your mandate is clear.

2123
01:10:34,000 --> 01:10:36,720
Build that foundation now before it becomes a crisis.