Your PowerShell Scripts Are Obsolete

1
00:00:00,000 --> 00:00:02,400
Your PowerShell scripts are about to become a liability.

2
00:00:02,400 --> 00:00:03,960
This isn't because PowerShell is dying

3
00:00:03,960 --> 00:00:05,360
or because your code is bad.

4
00:00:05,360 --> 00:00:08,040
The problem is that the assumptions you used to build them

5
00:00:08,040 --> 00:00:10,800
no longer match how modern enterprises actually function.

6
00:00:10,800 --> 00:00:12,240
You design those scripts for a world

7
00:00:12,240 --> 00:00:15,120
that doesn't exist anymore, where problems were predictable,

8
00:00:15,120 --> 00:00:17,880
inputs were clean, and every decision tree could fit

9
00:00:17,880 --> 00:00:19,080
on a single whiteboard.

10
00:00:19,080 --> 00:00:20,200
By the end of this video,

11
00:00:20,200 --> 00:00:22,760
you will understand how to evolve your entire script library

12
00:00:22,760 --> 00:00:24,320
into something completely different.

13
00:00:24,320 --> 00:00:25,880
We aren't talking about a replacement,

14
00:00:25,880 --> 00:00:28,280
but an evolution into a fleet of thinking workers.

15
00:00:28,280 --> 00:00:29,800
These agents authenticate themselves,

16
00:00:29,800 --> 00:00:31,360
reason about their environment,

17
00:00:31,360 --> 00:00:34,280
and execute tasks autonomously using Microsoft Graph

18
00:00:34,280 --> 00:00:36,000
as their single source of truth.

19
00:00:36,000 --> 00:00:38,120
You will see why semantic kernel is much more than a wrapper

20
00:00:38,120 --> 00:00:41,200
for PowerShell, acting instead as an orchestration engine

21
00:00:41,200 --> 00:00:44,000
that teaches models when and why to use your tools.

22
00:00:44,000 --> 00:00:47,440
The stakes are very real for your career and your organization.

23
00:00:47,440 --> 00:00:50,440
Companies that fail to operationalize this shift by 2026

24
00:00:50,440 --> 00:00:52,920
will find themselves at a massive disadvantage.

25
00:00:52,920 --> 00:00:55,640
While they are still writing manual conditional logic,

26
00:00:55,640 --> 00:00:57,480
their competitors will be deploying agents

27
00:00:57,480 --> 00:01:00,200
that adapt to variations without a single code change.

28
00:01:00,200 --> 00:01:02,600
One team will be stuck managing permanent service accounts

29
00:01:02,600 --> 00:01:04,200
with dangerous tenant-wide access,

30
00:01:04,200 --> 00:01:05,600
while the other users just in time

31
00:01:05,600 --> 00:01:07,800
identity scope to specific tasks.

32
00:01:07,800 --> 00:01:09,600
This is not a theoretical exercise or a vision

33
00:01:09,600 --> 00:01:10,760
of the distant future.

34
00:01:10,760 --> 00:01:13,360
We are taking the CMD-LEDs you already use every day,

35
00:01:13,360 --> 00:01:16,120
like GetMuser and UpdateMuser mailbox settings,

36
00:01:16,120 --> 00:01:18,120
and plugging them into a reasoning layer.

37
00:01:18,120 --> 00:01:20,000
This layer decides when to call them,

38
00:01:20,000 --> 00:01:21,640
determines the correct sequence,

39
00:01:21,640 --> 00:01:24,760
and figures out how to recover when things go sideways.

40
00:01:24,760 --> 00:01:26,280
The assumption that broke,

41
00:01:26,280 --> 00:01:29,000
the assumption that is currently breaking your automation

42
00:01:29,000 --> 00:01:31,400
is that your enterprise environment is predictable

43
00:01:31,400 --> 00:01:33,120
and unchanging.

44
00:01:33,120 --> 00:01:34,720
Think about how you build a script today.

45
00:01:34,720 --> 00:01:36,440
You start by defining the happy path,

46
00:01:36,440 --> 00:01:37,640
which is the perfect scenario

47
00:01:37,640 --> 00:01:39,520
where everything goes exactly as planned.

48
00:01:39,520 --> 00:01:41,840
The user exists, the license is available,

49
00:01:41,840 --> 00:01:44,760
and there are no strange edge cases to worry about.

50
00:01:44,760 --> 00:01:46,360
You write your steps in a linear order,

51
00:01:46,360 --> 00:01:48,520
so step one checks the account status,

52
00:01:48,520 --> 00:01:50,120
step two applies the license,

53
00:01:50,120 --> 00:01:51,880
and step three sends a notification.

54
00:01:51,880 --> 00:01:53,440
You test it and deploy it,

55
00:01:53,440 --> 00:01:56,080
and it works perfectly until a user has special characters

56
00:01:56,080 --> 00:01:59,840
in their name or Microsoft Changes and API response format.

57
00:01:59,840 --> 00:02:01,160
When those failures happen,

58
00:02:01,160 --> 00:02:04,360
you start adding conditional branches to handle the mess.

59
00:02:04,360 --> 00:02:07,000
You add error handling to catch missing users,

60
00:02:07,000 --> 00:02:08,240
or log license failures,

61
00:02:08,240 --> 00:02:10,200
and your logic begins to accumulate.

62
00:02:10,200 --> 00:02:11,840
The script grows longer and more complex,

63
00:02:11,840 --> 00:02:14,880
making it harder to follow, test, and maintain over time.

64
00:02:14,880 --> 00:02:16,800
But here's the thing that nobody wants to admit.

65
00:02:16,800 --> 00:02:18,560
You aren't actually solving the core problem

66
00:02:18,560 --> 00:02:19,760
by adding more code.

67
00:02:19,760 --> 00:02:22,640
You're just building a massive pile of if-then-else blocks

68
00:02:22,640 --> 00:02:25,600
that represent one person's guess about what might go wrong.

69
00:02:25,600 --> 00:02:28,000
Tomorrow, something you never predicted will happen,

70
00:02:28,000 --> 00:02:29,600
like a mailbox migration getting stuck

71
00:02:29,600 --> 00:02:31,040
in a state you've never seen before.

72
00:02:31,040 --> 00:02:33,000
Maybe the graph API throttles your requests

73
00:02:33,000 --> 00:02:35,040
because they are hitting the limit too fast,

74
00:02:35,040 --> 00:02:37,120
or an error message comes back in a format

75
00:02:37,120 --> 00:02:38,520
your rejects can't read.

76
00:02:38,520 --> 00:02:39,600
Every time this happens,

77
00:02:39,600 --> 00:02:41,120
someone has to open the script,

78
00:02:41,120 --> 00:02:42,280
remember how it works,

79
00:02:42,280 --> 00:02:43,840
add another branch, and redeploy it.

80
00:02:43,840 --> 00:02:45,880
That is a massive amount of maintenance debt

81
00:02:45,880 --> 00:02:47,960
that most teams never bother to track.

82
00:02:47,960 --> 00:02:51,240
Every new scenario requires a full cycle of revision and testing,

83
00:02:51,240 --> 00:02:54,040
creating constant friction for the smallest changes.

84
00:02:54,040 --> 00:02:56,560
Real enterprises are messy and unpredictable.

85
00:02:56,560 --> 00:02:59,280
User requests vary wildly from one day to the next,

86
00:02:59,280 --> 00:03:02,120
and error conditions branch out in ways you can't foresee.

87
00:03:02,120 --> 00:03:04,320
Business logic shifts the moment an organization

88
00:03:04,320 --> 00:03:06,640
reorganizes or adopts a new tool.

89
00:03:06,640 --> 00:03:08,480
A simple ticket about shared drive access

90
00:03:08,480 --> 00:03:10,160
could mean 15 different things,

91
00:03:10,160 --> 00:03:13,120
and each one requires a different diagnostic path to fix.

92
00:03:13,120 --> 00:03:15,000
The failing assumption is that you can predict

93
00:03:15,000 --> 00:03:17,000
every single one of these variations

94
00:03:17,000 --> 00:03:18,600
and encode them into a script.

95
00:03:18,600 --> 00:03:19,800
You can't do it profitably,

96
00:03:19,800 --> 00:03:22,040
and you certainly can't do it in a way that scales.

97
00:03:22,040 --> 00:03:23,880
The real issue isn't the script itself,

98
00:03:23,880 --> 00:03:25,200
but the architecture behind it.

99
00:03:25,200 --> 00:03:28,360
Scripts are deterministic engines that follow a set sequence,

100
00:03:28,360 --> 00:03:31,240
and they are excellent at doing exactly what they are told.

101
00:03:31,240 --> 00:03:34,600
However, they have no ability to reason about what they are doing.

102
00:03:34,600 --> 00:03:36,000
They can't look at a ticket and realize

103
00:03:36,000 --> 00:03:38,320
it's a licensing issue rather than an access problem.

104
00:03:38,320 --> 00:03:40,680
They can't read an error and decide to wait 30 seconds

105
00:03:40,680 --> 00:03:41,800
before trying again.

106
00:03:41,800 --> 00:03:44,080
That gap between what the script is programmed to do

107
00:03:44,080 --> 00:03:45,880
and what the situation actually requires

108
00:03:45,880 --> 00:03:47,280
is where the friction lives.

109
00:03:47,280 --> 00:03:48,960
This gap is growing wider,

110
00:03:48,960 --> 00:03:51,800
as environments become more complex and less predictable.

111
00:03:51,800 --> 00:03:53,160
This is where the architecture breaks,

112
00:03:53,160 --> 00:03:55,120
and it's why we need a new approach.

113
00:03:55,120 --> 00:03:56,920
Where automation hits its ceiling.

114
00:03:56,920 --> 00:03:59,320
Automation is powerful, but it has a hard limit.

115
00:03:59,320 --> 00:04:01,680
That limit is exactly where scripts start to break.

116
00:04:01,680 --> 00:04:03,280
We know that automation works brilliantly

117
00:04:03,280 --> 00:04:05,160
when three specific things are true.

118
00:04:05,160 --> 00:04:06,720
First, the input has to be structured,

119
00:04:06,720 --> 00:04:08,720
meaning you know exactly what you are going to receive

120
00:04:08,720 --> 00:04:10,400
and what format it will be in.

121
00:04:10,400 --> 00:04:12,400
Second, the decision tree must be finite,

122
00:04:12,400 --> 00:04:14,120
so you can map out every possible path

123
00:04:14,120 --> 00:04:15,600
and turn it into code.

124
00:04:15,600 --> 00:04:17,920
Third, the outcomes have to be deterministic.

125
00:04:17,920 --> 00:04:20,320
The same input should always produce the same output.

126
00:04:20,320 --> 00:04:23,120
If you run a script to set up a user with a specific name,

127
00:04:23,120 --> 00:04:25,360
that user gets created the same way every single time.

128
00:04:25,360 --> 00:04:27,480
But in reality, IT tickets do not arrive

129
00:04:27,480 --> 00:04:28,720
in a structured format.

130
00:04:28,720 --> 00:04:31,080
They show up as messy, natural language

131
00:04:31,080 --> 00:04:32,760
with a lot of hidden context.

132
00:04:32,760 --> 00:04:34,600
Someone sends an email saying their email is not

133
00:04:34,600 --> 00:04:37,480
syncing on their laptop, they cannot access the shared folder,

134
00:04:37,480 --> 00:04:39,800
and for some reason this only happens on Tuesdays.

135
00:04:39,800 --> 00:04:41,480
That is one single ticket, but it contains

136
00:04:41,480 --> 00:04:42,840
at least three separate problems.

137
00:04:42,840 --> 00:04:44,600
The person writing it does not understand

138
00:04:44,600 --> 00:04:46,560
how those issues relate to each other,

139
00:04:46,560 --> 00:04:49,240
and the ticket does not tell you if it is a network issue,

140
00:04:49,240 --> 00:04:51,520
a device problem, or a permission error.

141
00:04:51,520 --> 00:04:54,600
The real context is buried deep inside the description.

142
00:04:54,600 --> 00:04:56,240
Here is what actually happens today.

143
00:04:56,240 --> 00:04:58,080
The ticket lands in your queue and you read it

144
00:04:58,080 --> 00:04:59,920
and then you have to stop and think.

145
00:04:59,920 --> 00:05:02,200
You ask yourself, what is actually happening here,

146
00:05:02,200 --> 00:05:04,720
whether this is a networking problem or an identity problem,

147
00:05:04,720 --> 00:05:07,360
and if you should check the device or the cloud first.

148
00:05:07,360 --> 00:05:09,400
You have to figure out which questions will narrow down

149
00:05:09,400 --> 00:05:12,160
the cause so you run diagnostics and look at error messages

150
00:05:12,160 --> 00:05:14,040
to build a mental model of the problem.

151
00:05:14,040 --> 00:05:16,520
Only after all that thinking do you know which script to run,

152
00:05:16,520 --> 00:05:18,320
or if a script will even help at all.

153
00:05:18,320 --> 00:05:20,280
That entire middle part is the thinking part,

154
00:05:20,280 --> 00:05:23,640
and that is where the real bottleneck lives in your organization.

155
00:05:23,640 --> 00:05:25,840
The delay is not in the execution of the fix,

156
00:05:25,840 --> 00:05:29,000
it is in the diagnosis, the triage, and the decision making.

157
00:05:29,000 --> 00:05:30,360
This is why traditional automation

158
00:05:30,360 --> 00:05:32,360
has hit a ceiling in IT operations.

159
00:05:32,360 --> 00:05:34,640
Scripts handle the execution phase beautifully,

160
00:05:34,640 --> 00:05:36,080
but they cannot handle the reasoning

161
00:05:36,080 --> 00:05:38,440
that has to happen before the execution starts.

162
00:05:38,440 --> 00:05:40,320
A script cannot read a ticket and realize

163
00:05:40,320 --> 00:05:42,720
that because a mailbox and a device are both involved,

164
00:05:42,720 --> 00:05:44,560
it needs to check Azure AD health

165
00:05:44,560 --> 00:05:46,480
before looking at device compliance.

166
00:05:46,480 --> 00:05:47,880
It cannot see an error message

167
00:05:47,880 --> 00:05:49,560
and suggest that it looks like a caching issue

168
00:05:49,560 --> 00:05:51,800
that should be cleared before escalating to support.

169
00:05:51,800 --> 00:05:53,480
It cannot ask a user for more details

170
00:05:53,480 --> 00:05:55,560
when a ticket is too vague to understand.

171
00:05:55,560 --> 00:05:58,400
What organizations do instead is keep a human in the loop

172
00:05:58,400 --> 00:06:00,000
to act as the brain.

173
00:06:00,000 --> 00:06:01,880
The script handles the predictable steps,

174
00:06:01,880 --> 00:06:03,680
but the human has to handle the reasoning

175
00:06:03,680 --> 00:06:06,520
by reading the ticket and deciding what to do next.

176
00:06:06,520 --> 00:06:08,160
The human is the reasoning engine,

177
00:06:08,160 --> 00:06:10,120
while the script is just the executor,

178
00:06:10,120 --> 00:06:11,920
and this makes the human the bottleneck

179
00:06:11,920 --> 00:06:14,000
because people are slower than code.

180
00:06:14,000 --> 00:06:15,840
Humans get tired, they miss small details,

181
00:06:15,840 --> 00:06:17,800
and they are incredibly expensive to scale

182
00:06:17,800 --> 00:06:18,880
as the workload grows.

183
00:06:18,880 --> 00:06:20,840
You have probably noticed this in your own work,

184
00:06:20,840 --> 00:06:22,520
the fastest part of closing a ticket

185
00:06:22,520 --> 00:06:24,200
is not running the actual fix,

186
00:06:24,200 --> 00:06:26,920
but rather understanding what the problem is in the first place.

187
00:06:26,920 --> 00:06:28,800
You spend 90% of your cognitive effort

188
00:06:28,800 --> 00:06:31,280
figuring out which tool to use or which assumption to test

189
00:06:31,280 --> 00:06:33,480
while the actual command only takes a second.

190
00:06:33,480 --> 00:06:36,200
That fast part is the only thing scripts currently handle,

191
00:06:36,200 --> 00:06:38,200
so the ceiling we are hitting is not a limitation

192
00:06:38,200 --> 00:06:40,280
of power shell or any other language.

193
00:06:40,280 --> 00:06:42,680
It is a limitation of the architecture itself.

194
00:06:42,680 --> 00:06:45,040
Scripts are designed to be deterministic executors,

195
00:06:45,040 --> 00:06:47,200
which means they are not built to understand context

196
00:06:47,200 --> 00:06:49,360
or handle the ambiguity of a human request.

197
00:06:49,360 --> 00:06:51,240
They are not designed to look at a complex situation

198
00:06:51,240 --> 00:06:52,920
and ask what is actually going on.

199
00:06:52,920 --> 00:06:55,120
This is where the issue stops being about technology

200
00:06:55,120 --> 00:06:56,600
and starts being about architecture.

201
00:06:56,600 --> 00:06:58,120
You need a reasoning layer that can read

202
00:06:58,120 --> 00:07:00,680
an unstructured ticket, understand the context,

203
00:07:00,680 --> 00:07:02,560
and decide which diagnostics to run.

204
00:07:02,560 --> 00:07:04,400
You need something that can interpret results

205
00:07:04,400 --> 00:07:06,560
and decide on the next execution steps,

206
00:07:06,560 --> 00:07:08,520
even if that involves branching or backtracking

207
00:07:08,520 --> 00:07:09,600
when things go wrong.

208
00:07:09,600 --> 00:07:11,160
You need something that can think,

209
00:07:11,160 --> 00:07:13,360
and that is exactly where autonomous agents

210
00:07:13,360 --> 00:07:16,600
change the game as soon as the authentication paradox.

211
00:07:16,600 --> 00:07:18,360
There is a massive security problem

212
00:07:18,360 --> 00:07:19,800
that nobody is talking about,

213
00:07:19,800 --> 00:07:21,480
and it is baked directly into how

214
00:07:21,480 --> 00:07:23,280
power shell automation works right now.

215
00:07:23,280 --> 00:07:25,320
When you write a script, the very first thing you do

216
00:07:25,320 --> 00:07:26,840
is authenticate by running a command

217
00:07:26,840 --> 00:07:28,960
like connect migraph with a service principle.

218
00:07:28,960 --> 00:07:30,040
The script gets a token,

219
00:07:30,040 --> 00:07:32,040
and that token stays active for the entire time

220
00:07:32,040 --> 00:07:33,040
the script is running.

221
00:07:33,040 --> 00:07:34,720
If the process takes an hour to finish,

222
00:07:34,720 --> 00:07:37,920
that token remains valid and usable for that entire hour,

223
00:07:37,920 --> 00:07:40,440
even if the script needs to call the Microsoft Graph

224
00:07:40,440 --> 00:07:41,680
50 different times.

225
00:07:41,680 --> 00:07:44,000
On the surface, this seems fine because it is efficient.

226
00:07:44,000 --> 00:07:45,960
There is no obvious reason to authenticate

227
00:07:45,960 --> 00:07:48,880
multiple times when you can just do it once at the start,

228
00:07:48,880 --> 00:07:50,040
but here is the paradox.

229
00:07:50,040 --> 00:07:52,360
You have essentially created a permanent access key

230
00:07:52,360 --> 00:07:53,520
to your entire tenant.

231
00:07:53,520 --> 00:07:54,680
The moment that script starts,

232
00:07:54,680 --> 00:07:56,400
it has broad access to everything

233
00:07:56,400 --> 00:07:57,920
it was granted permission to do,

234
00:07:57,920 --> 00:08:00,040
and it keeps that access until it finishes.

235
00:08:00,040 --> 00:08:01,880
If something goes wrong in the middle of the run,

236
00:08:01,880 --> 00:08:03,800
or if an error causes the script to behave

237
00:08:03,800 --> 00:08:05,200
in a way you did not intend,

238
00:08:05,200 --> 00:08:06,840
that token is still live.

239
00:08:06,840 --> 00:08:09,000
That is still full unrestricted access.

240
00:08:09,000 --> 00:08:11,520
Now consider what happens if that script gets compromised.

241
00:08:11,520 --> 00:08:13,680
If someone injects malicious code into your script

242
00:08:13,680 --> 00:08:15,360
or hacks your code repository,

243
00:08:15,360 --> 00:08:17,640
they can add a single line to steal your data.

244
00:08:17,640 --> 00:08:19,480
The attacker now owns that token,

245
00:08:19,480 --> 00:08:21,440
and they have access to your entire tenant

246
00:08:21,440 --> 00:08:23,080
for the rest of the tokens life.

247
00:08:23,080 --> 00:08:25,600
By default, that gives them 60 minutes to do whatever they want

248
00:08:25,600 --> 00:08:28,000
inside your Microsoft 365 environment,

249
00:08:28,000 --> 00:08:29,160
and here is the kicker.

250
00:08:29,160 --> 00:08:31,120
In most companies, that service principle

251
00:08:31,120 --> 00:08:32,880
has incredibly broad permissions.

252
00:08:32,880 --> 00:08:35,520
It might have the power to reset passwords, manage groups,

253
00:08:35,520 --> 00:08:37,320
and read every mailbox in the organization

254
00:08:37,320 --> 00:08:38,200
all at the same time.

255
00:08:38,200 --> 00:08:40,040
One compromised script means an attacker

256
00:08:40,040 --> 00:08:42,640
gets all of those permissions at once across the whole tenant,

257
00:08:42,640 --> 00:08:44,280
which makes your automation service account

258
00:08:44,280 --> 00:08:46,440
a high-value target for any hacker.

259
00:08:46,440 --> 00:08:48,000
This is the standard practice today,

260
00:08:48,000 --> 00:08:49,760
and it usually works because the threats

261
00:08:49,760 --> 00:08:52,760
that actually exploit these gaps are still relatively rare.

262
00:08:52,760 --> 00:08:53,720
But this is a ticking clock,

263
00:08:53,720 --> 00:08:55,200
and as automation becomes more common,

264
00:08:55,200 --> 00:08:56,840
and more people have access to scripts,

265
00:08:56,840 --> 00:08:58,800
the surface area for an attack grows,

266
00:08:58,800 --> 00:09:00,480
eventually something is going to break.

267
00:09:00,480 --> 00:09:02,680
The security model for 2026

268
00:09:02,680 --> 00:09:04,280
inverts this logic completely.

269
00:09:04,280 --> 00:09:07,040
Instead of using one permanent token with broad permissions,

270
00:09:07,040 --> 00:09:10,040
you get a unique token for every single individual task.

271
00:09:10,040 --> 00:09:12,920
The token is issued just in time, right when you need it,

272
00:09:12,920 --> 00:09:15,160
and it is scope to do exactly one thing.

273
00:09:15,160 --> 00:09:17,960
It might allow you to reset a password for one specific user

274
00:09:17,960 --> 00:09:19,640
or get the settings for one mailbox,

275
00:09:19,640 --> 00:09:21,120
but it cannot do anything else.

276
00:09:21,120 --> 00:09:23,320
Once that specific task is finished,

277
00:09:23,320 --> 00:09:25,440
the token expires immediately.

278
00:09:25,440 --> 00:09:27,600
Think about how much this changes your risk profile.

279
00:09:27,600 --> 00:09:30,240
If a script is compromised, an attacker might get a token,

280
00:09:30,240 --> 00:09:33,000
but that token was only issued for one tiny operation.

281
00:09:33,000 --> 00:09:35,600
It cannot be used to look at every user in your directory,

282
00:09:35,600 --> 00:09:37,680
it cannot be used to read other mailboxes,

283
00:09:37,680 --> 00:09:40,680
and it definitely cannot be used to create new admin accounts.

284
00:09:40,680 --> 00:09:43,120
The blast radius shrinks from the entire tenant

285
00:09:43,120 --> 00:09:45,080
down to just one single task.

286
00:09:45,080 --> 00:09:46,880
The architectural shift here moves us away

287
00:09:46,880 --> 00:09:49,040
from permanent admin keys and to a just in time

288
00:09:49,040 --> 00:09:51,160
identity scope to a single operation.

289
00:09:51,160 --> 00:09:53,480
An external policy engine decides if an agent is

290
00:09:53,480 --> 00:09:56,760
allowed to do a task right now by checking the risk and the context.

291
00:09:56,760 --> 00:09:59,680
It issues a token that is only valid for 30 or 60 seconds,

292
00:09:59,680 --> 00:10:01,480
which is just long enough to get the job done

293
00:10:01,480 --> 00:10:03,320
before it is revoked automatically.

294
00:10:03,320 --> 00:10:05,040
This is vital for autonomous agents

295
00:10:05,040 --> 00:10:06,960
because those agents will be running constantly.

296
00:10:06,960 --> 00:10:10,120
They will be processing tickets and executing workflows all day long,

297
00:10:10,120 --> 00:10:13,040
and the old security model simply cannot scale to meet that demand.

298
00:10:13,040 --> 00:10:16,080
You cannot give an agent a permanent tenant-wide key

299
00:10:16,080 --> 00:10:18,480
and expect your environment to stay secure.

300
00:10:18,480 --> 00:10:21,680
Autonomous reasoning requires autonomous authentication,

301
00:10:21,680 --> 00:10:23,360
which means using a different identity

302
00:10:23,360 --> 00:10:25,880
for every single decision the system makes.

303
00:10:25,880 --> 00:10:28,200
Semantic kernel as the reasoning layer.

304
00:10:28,200 --> 00:10:30,760
We need to talk about how you actually build this reasoning layer.

305
00:10:30,760 --> 00:10:32,560
This is where semantic kernel comes in,

306
00:10:32,560 --> 00:10:35,160
but I want to be clear about what this tool actually is

307
00:10:35,160 --> 00:10:36,680
because most people get it wrong.

308
00:10:36,680 --> 00:10:38,400
Semantic kernel isn't just a wrapper,

309
00:10:38,400 --> 00:10:41,480
it isn't a library that makes it easier to call PowerShell from your code.

310
00:10:41,480 --> 00:10:42,880
It's something fundamentally different.

311
00:10:42,880 --> 00:10:47,320
It's an orchestration engine designed to teach large language models how to use tools.

312
00:10:47,320 --> 00:10:51,360
The kernel sits directly between the LLM and your PowerShell functions.

313
00:10:51,360 --> 00:10:54,800
It manages the conversation, it interprets what the model decides to do.

314
00:10:54,800 --> 00:10:56,400
It executes those decisions,

315
00:10:56,400 --> 00:10:58,160
and it feeds the results back to the model

316
00:10:58,160 --> 00:11:00,080
so the AI can decide what to do next.

317
00:11:00,080 --> 00:11:01,640
The core concept is simple.

318
00:11:01,640 --> 00:11:03,960
The kernel decides when to call PowerShell,

319
00:11:03,960 --> 00:11:05,440
not just how to call it.

320
00:11:05,440 --> 00:11:08,520
You describe your PowerShell functions to the kernel in plain language.

321
00:11:08,520 --> 00:11:09,960
You explain what each function does,

322
00:11:09,960 --> 00:11:12,920
what parameters it needs, and what kind of results it returns.

323
00:11:12,920 --> 00:11:16,800
The kernel then presents these functions to the LLM as a set of available tools.

324
00:11:16,800 --> 00:11:20,200
The model reads those descriptions, it understands the purpose.

325
00:11:20,200 --> 00:11:22,600
It reasons about when a specific tool should be used.

326
00:11:22,600 --> 00:11:24,240
Should I call this function now?

327
00:11:24,240 --> 00:11:25,680
Or should I call a different one?

328
00:11:25,680 --> 00:11:28,200
What parameters should I pass to get the right result?

329
00:11:28,200 --> 00:11:30,280
What will the output tell me about the next step?

330
00:11:30,280 --> 00:11:34,240
This is the shift from deterministic execution to adaptive reasoning.

331
00:11:34,240 --> 00:11:37,960
A traditional script says, "Do this, then do that, then do the other thing."

332
00:11:37,960 --> 00:11:40,920
The agent says, "Here is my goal, these are the tools I have,

333
00:11:40,920 --> 00:11:44,000
and here is what I should do first based on what I know right now."

334
00:11:44,000 --> 00:11:47,480
Semantic kernel supports three main ways to integrate your tools.

335
00:11:47,480 --> 00:11:49,080
First, you have native plugins,

336
00:11:49,080 --> 00:11:51,800
where you write C-Pars code and decorate methods with attributes

337
00:11:51,800 --> 00:11:53,680
to compile them into your agent.

338
00:11:53,680 --> 00:11:57,960
Second, you can use OpenAPI imports to point the kernel at a specification

339
00:11:57,960 --> 00:12:00,680
and automatically expose those endpoints as tools.

340
00:12:00,680 --> 00:12:02,760
Third, it supports MCP servers,

341
00:12:02,760 --> 00:12:07,360
which are model context protocol servers that standardize how tools are shown to AI systems.

342
00:12:07,360 --> 00:12:11,880
For PowerShell specifically, the native plug-in pattern is the most direct way to get started.

343
00:12:11,880 --> 00:12:15,800
You create a .NET class and write methods that call your PowerShell CMDlets.

344
00:12:15,800 --> 00:12:17,800
Each method should do one specific thing.

345
00:12:17,800 --> 00:12:20,440
Maybe one method retrieves a user from Microsoft Graph

346
00:12:20,440 --> 00:12:23,080
while another resets a password or checks mailbox permissions.

347
00:12:23,080 --> 00:12:25,640
You decorate each method with a kernel function attribute,

348
00:12:25,640 --> 00:12:27,400
so the kernel knows it's a tool.

349
00:12:27,400 --> 00:12:31,440
Then you add a description attribute that explains what the function does in plain English.

350
00:12:31,440 --> 00:12:34,640
When you register this class, the kernel passes every single description.

351
00:12:34,640 --> 00:12:36,240
It learns the purpose of every function.

352
00:12:36,240 --> 00:12:38,440
It understands the parameters you defined.

353
00:12:38,440 --> 00:12:41,840
It creates an internal map of the tools, the data they need,

354
00:12:41,840 --> 00:12:43,480
and the results they produce.

355
00:12:43,480 --> 00:12:47,120
Now, when you ask the model to solve a problem, it doesn't just see your question.

356
00:12:47,120 --> 00:12:50,400
It sees your question alongside a structured list of available tools.

357
00:12:50,400 --> 00:12:52,640
It reasons about which tools are relevant to the problem.

358
00:12:52,640 --> 00:12:53,800
It builds a plan.

359
00:12:53,800 --> 00:12:58,120
The model tells the kernel, "I need to call the get user function with the username jsmith."

360
00:12:58,120 --> 00:12:59,440
The kernel runs the code.

361
00:12:59,440 --> 00:13:00,720
The model sees the result.

362
00:13:00,720 --> 00:13:02,600
Then it decides if the goal is finished,

363
00:13:02,600 --> 00:13:05,280
or if it needs to call another function to keep going.

364
00:13:05,280 --> 00:13:07,240
This is why your descriptions matter so much.

365
00:13:07,240 --> 00:13:10,440
If you write a description that says resets a user's password,

366
00:13:10,440 --> 00:13:12,680
the model understands exactly when to use it.

367
00:13:12,680 --> 00:13:15,480
But if your description is vague like "updates user account",

368
00:13:15,480 --> 00:13:16,680
the model gets confused.

369
00:13:16,680 --> 00:13:20,000
It won't know if that function is for passwords, licenses, or something else.

370
00:13:20,000 --> 00:13:21,920
And it might make the wrong choice.

371
00:13:21,920 --> 00:13:26,120
The kernel uses these descriptions to teach the model the "why" behind the tool.

372
00:13:26,120 --> 00:13:28,720
This allows the LLM to compose multi-step workflows

373
00:13:28,720 --> 00:13:31,080
instead of just running one command at a time.

374
00:13:31,080 --> 00:13:33,120
The model doesn't follow a fixed sequence.

375
00:13:33,120 --> 00:13:34,880
It reads a ticket, understands the goal,

376
00:13:34,880 --> 00:13:37,080
and chains tools together to reach that goal.

377
00:13:37,080 --> 00:13:38,760
If something unexpected happens,

378
00:13:38,760 --> 00:13:41,760
like a user missing or a permission failing, the model adapts.

379
00:13:41,760 --> 00:13:44,640
It tries a different approach because it can reason about what went wrong.

380
00:13:44,640 --> 00:13:45,520
This is orchestration.

381
00:13:45,520 --> 00:13:47,080
It's not just execution.

382
00:13:47,080 --> 00:13:49,240
Microsoft Graph as the data fabric.

383
00:13:49,240 --> 00:13:51,120
The kernel now knows how to orchestrate PowerShell,

384
00:13:51,120 --> 00:13:53,080
but PowerShell needs something to talk to.

385
00:13:53,080 --> 00:13:54,680
It needs access to data.

386
00:13:54,680 --> 00:13:56,560
That's where Microsoft Graph enters the picture.

387
00:13:56,560 --> 00:14:01,480
Microsoft Graph is the unified API layer for every Microsoft 365 workload.

388
00:14:01,480 --> 00:14:05,200
It covers mail, teams, SharePoint, and user identities in Azure AD.

389
00:14:05,200 --> 00:14:09,520
It handles device management through Intune, Planet tasks, and OneNote notebooks.

390
00:14:09,520 --> 00:14:13,360
Instead of learning a dozen different APIs for a dozen different services you go through Graph.

391
00:14:13,360 --> 00:14:16,680
One interface, one way to authenticate, one consistent data model.

392
00:14:16,680 --> 00:14:19,320
For autonomous agents, Graph is more than just an API.

393
00:14:19,320 --> 00:14:22,320
It's the source of truth for the entire state of your organization.

394
00:14:22,320 --> 00:14:25,480
When an agent needs to know something about your enterprise, it goes to Graph.

395
00:14:25,480 --> 00:14:26,600
Is this user licensed?

396
00:14:26,600 --> 00:14:27,880
Is this device compliant?

397
00:14:27,880 --> 00:14:31,120
What are the email forwarding rules on this specific mailbox?

398
00:14:31,120 --> 00:14:32,840
Graph knows the answer to all of those.

399
00:14:32,840 --> 00:14:34,240
This changes how you work.

400
00:14:34,240 --> 00:14:37,880
Right now, when you write a script, you manually craft every single query.

401
00:14:37,880 --> 00:14:39,240
You decide what information you need.

402
00:14:39,240 --> 00:14:42,360
You run a command like GetMJuser, and you look at the properties.

403
00:14:42,360 --> 00:14:45,400
You see a value and decide whether to move to the next step.

404
00:14:45,400 --> 00:14:47,120
You read the error message if it fails.

405
00:14:47,120 --> 00:14:48,680
You interpret what that error means.

406
00:14:48,680 --> 00:14:52,720
The script is just a sequence of manual queries where you encoded every decision point

407
00:14:52,720 --> 00:14:53,720
up front.

408
00:14:53,720 --> 00:14:54,960
An agent doesn't work that way.

409
00:14:54,960 --> 00:14:59,720
The agent queries graph receives the data and analyzes the results to decide the next move.

410
00:14:59,720 --> 00:15:04,080
It makes decisions based on what actually happened, not what you predicted would happen.

411
00:15:04,080 --> 00:15:07,680
If a mailbox is in a strange state you've never seen before, the agent doesn't panic,

412
00:15:07,680 --> 00:15:12,560
it reads the state, understands the implications, and reasons about what fix makes sense.

413
00:15:12,560 --> 00:15:16,200
It might try one approach, see it didn't work, and then try something else.

414
00:15:16,200 --> 00:15:18,680
The power of this is obvious in complex workflows.

415
00:15:18,680 --> 00:15:22,200
Suppose you're diagnosing why a user can't access a shared document.

416
00:15:22,200 --> 00:15:26,200
The problem could be the user, the device, the network, or the permissions.

417
00:15:26,200 --> 00:15:28,880
An autonomous agent works through this systematically.

418
00:15:28,880 --> 00:15:32,760
It checks the identity in Azure AD and the device compliance in Intune.

419
00:15:32,760 --> 00:15:36,680
It looks at the sharing permissions in SharePoint and checks for conditional access policies.

420
00:15:36,680 --> 00:15:39,720
Then it correlates all that data to build a hypothesis.

421
00:15:39,720 --> 00:15:42,040
This is where agents become force multipliers.

422
00:15:42,040 --> 00:15:45,800
A human doing this investigation might take an hour to click through all those screens.

423
00:15:45,800 --> 00:15:49,240
An agent does it in seconds because it can query all these systems at once without getting

424
00:15:49,240 --> 00:15:50,240
distracted.

425
00:15:50,240 --> 00:15:51,960
But we have to talk about security.

426
00:15:51,960 --> 00:15:55,840
If permissions must be scoped to the specific task, not the whole tenant, this goes back

427
00:15:55,840 --> 00:15:58,320
to our talk about just-in-time identities.

428
00:15:58,320 --> 00:16:01,520
An agent that resets passwords doesn't need to read your email.

429
00:16:01,520 --> 00:16:04,480
An agent that checks device compliance doesn't need to write to groups.

430
00:16:04,480 --> 00:16:07,960
Each agent gets only the graph permissions it actually needs to do the job.

431
00:16:07,960 --> 00:16:09,840
The policy engine enforces this.

432
00:16:09,840 --> 00:16:14,040
When an agent requests a token for a task, that token only has the permissions required

433
00:16:14,040 --> 00:16:15,480
for that one moment.

434
00:16:15,480 --> 00:16:19,960
Graph gives agents access to the entire enterprise data fabric in a structured way, but that

435
00:16:19,960 --> 00:16:22,200
access is always controlled and auditable.

436
00:16:22,200 --> 00:16:24,600
The agent sees what it needs to see and nothing more.

437
00:16:24,600 --> 00:16:27,480
That is how you scale these operations safely.

438
00:16:27,480 --> 00:16:30,200
Headless authentication and identity governance.

439
00:16:30,200 --> 00:16:33,280
Headless means the agent runs without any user interaction at all.

440
00:16:33,280 --> 00:16:36,600
There is no human sitting at a keyboard and there is no browser window popping up to

441
00:16:36,600 --> 00:16:37,880
ask for MFA.

442
00:16:37,880 --> 00:16:41,760
The agent has to prove who it is and get access to do its work, but it does all of that

443
00:16:41,760 --> 00:16:45,040
automatically in the background, without anyone getting involved.

444
00:16:45,040 --> 00:16:48,880
This is fundamentally different from how you probably use Microsoft 365 today.

445
00:16:48,880 --> 00:16:51,080
When you open Outlook, you authenticate yourself.

446
00:16:51,080 --> 00:16:54,240
The browser might ask for your password or your Authenticator app and you respond to get

447
00:16:54,240 --> 00:16:55,240
logged in.

448
00:16:55,240 --> 00:16:56,800
That is called delegated authentication.

449
00:16:56,800 --> 00:17:00,560
It uses your identity, your credentials and your permissions because you are the actor

450
00:17:00,560 --> 00:17:02,480
and the system is responding to you.

451
00:17:02,480 --> 00:17:03,680
Agents cannot work that way.

452
00:17:03,680 --> 00:17:07,720
An agent that needed to prompt for credentials would just hang there waiting forever.

453
00:17:07,720 --> 00:17:11,760
It cannot interact with an MFA app and it cannot click approval buttons, so it has to

454
00:17:11,760 --> 00:17:14,040
authenticate in a way that is fully automated.

455
00:17:14,040 --> 00:17:15,400
This is app-only authentication.

456
00:17:15,400 --> 00:17:19,400
The agent has a credential, which is usually a certificate or a client secret stored somewhere

457
00:17:19,400 --> 00:17:24,840
secure and it uses that to request access tokens from Azure AD with no human involved.

458
00:17:24,840 --> 00:17:27,720
But this is where 2026 changes the model entirely.

459
00:17:27,720 --> 00:17:32,160
The traditional approach is to issue one credential to the service principle, store it somewhere,

460
00:17:32,160 --> 00:17:33,800
and use it for every single task.

461
00:17:33,800 --> 00:17:37,160
The agent runs and authenticates with that static credential to get a token that is valid

462
00:17:37,160 --> 00:17:38,160
for an hour or more.

463
00:17:38,160 --> 00:17:40,480
It uses that same token for everything it does.

464
00:17:40,480 --> 00:17:44,400
If someone needs to change what the agent can do, they have to update the credential storage,

465
00:17:44,400 --> 00:17:46,800
the app registration and redeploy the whole thing.

466
00:17:46,800 --> 00:17:50,520
The shift we are seeing now is to what just in time token issuance, instead of one permanent

467
00:17:50,520 --> 00:17:54,600
credential that the agent uses to get its own tokens, the agent requests a token from

468
00:17:54,600 --> 00:17:57,080
a policy engine whenever it needs to do work.

469
00:17:57,080 --> 00:18:01,160
The policy engine looks at what the agent is trying to do and checks a specific policy

470
00:18:01,160 --> 00:18:05,320
to decide if this agent should be allowed to perform this specific task right now.

471
00:18:05,320 --> 00:18:09,480
If the answer is yes, it issues a token scope exactly to that one task.

472
00:18:09,480 --> 00:18:11,800
That token might be valid for only 60 seconds.

473
00:18:11,800 --> 00:18:15,960
It can only be used to reset one user's password or read one mailbox or update one device's

474
00:18:15,960 --> 00:18:17,800
configuration and then it expires.

475
00:18:17,800 --> 00:18:19,320
This is the big architectural shift.

476
00:18:19,320 --> 00:18:23,680
We are moving from a permanent identity credential that unlocks everything to time limited, task-specific

477
00:18:23,680 --> 00:18:25,840
tokens issued by a policy engine.

478
00:18:25,840 --> 00:18:28,520
The policy engine is the new component in the setup.

479
00:18:28,520 --> 00:18:32,360
It is an external service that understands your organization's risk posture, your security

480
00:18:32,360 --> 00:18:34,800
policies, and your operational context.

481
00:18:34,800 --> 00:18:38,320
When an agent wants to do something, it goes to the policy engine and the engine starts

482
00:18:38,320 --> 00:18:39,320
asking questions.

483
00:18:39,320 --> 00:18:42,720
Does this task allowed, has this agent done this task before successfully?

484
00:18:42,720 --> 00:18:44,360
Is there unusual activity happening?

485
00:18:44,360 --> 00:18:48,000
Only if the answers to all these questions support the request, does the policy engine issue

486
00:18:48,000 --> 00:18:49,200
a token?

487
00:18:49,200 --> 00:18:51,120
Managed identity is another piece of this puzzle.

488
00:18:51,120 --> 00:18:55,320
If your agent runs inside Azure, like in a function app or a container, that agent can

489
00:18:55,320 --> 00:18:57,640
use Azure's managed identity system.

490
00:18:57,640 --> 00:18:59,680
The agent does not store any credentials at all.

491
00:18:59,680 --> 00:19:03,680
It simply proves that it is running in that specific Azure resource and Azure issues

492
00:19:03,680 --> 00:19:05,280
it a token automatically.

493
00:19:05,280 --> 00:19:08,560
You configure the managed identity with exactly the permissions it needs.

494
00:19:08,560 --> 00:19:12,280
And when the credentials need to rotate, Azure handles that in the background.

495
00:19:12,280 --> 00:19:16,000
You are not manually rotating secrets or storing credentials in code because the system

496
00:19:16,000 --> 00:19:17,960
handles identity automatically.

497
00:19:17,960 --> 00:19:20,440
But there is one more layer to consider.

498
00:19:20,440 --> 00:19:25,080
Continuous access evaluation or CAE is how Microsoft revokes access immediately if something

499
00:19:25,080 --> 00:19:26,080
changes.

500
00:19:26,080 --> 00:19:30,600
Normally, a token issued at 2pm stays valid until 3pm, even if something bad happens at

501
00:19:30,600 --> 00:19:31,600
2.30pm.

502
00:19:31,600 --> 00:19:32,920
CAE changes that logic.

503
00:19:32,920 --> 00:19:36,880
If a risk signal triggers during your tokens lifetime, like an impossible travel alert

504
00:19:36,880 --> 00:19:40,280
or a policy violation, CAE revokes your token immediately.

505
00:19:40,280 --> 00:19:42,000
Your access stops within seconds.

506
00:19:42,000 --> 00:19:44,160
For autonomous agents, this is absolutely essential.

507
00:19:44,160 --> 00:19:48,600
An agent that has been compromised or starts acting abnormally should lose its access immediately

508
00:19:48,600 --> 00:19:51,080
rather than waiting for the next token refresh.

509
00:19:51,080 --> 00:19:55,160
The continuous evaluation of risk means the policy engine can revoke a token and prevent

510
00:19:55,160 --> 00:19:59,000
further damage before the compromised agent even realises what is happening.

511
00:19:59,000 --> 00:20:04,000
This is why autonomous agents actually need tighter identity boundaries than humans do.

512
00:20:04,000 --> 00:20:05,000
Humans have judgment.

513
00:20:05,000 --> 00:20:08,800
You can see a prompt that looks suspicious and choose to ignore it, but agents do not have

514
00:20:08,800 --> 00:20:09,800
that ability.

515
00:20:09,800 --> 00:20:14,080
An agent just follows its logic, so the system has to make sure the agent's identity gives

516
00:20:14,080 --> 00:20:17,640
it access to do exactly what it is supposed to do and nothing else.

517
00:20:17,640 --> 00:20:21,600
Just in time tokens, continuous evaluation and immediate revocation are the pillars of

518
00:20:21,600 --> 00:20:25,400
an identity architecture that supports secure operation at scale.

519
00:20:25,400 --> 00:20:27,680
Rapping PowerShell as semantic kernel plugins.

520
00:20:27,680 --> 00:20:31,600
Now let's talk about the mechanics of actually connecting PowerShell to semantic kernel.

521
00:20:31,600 --> 00:20:34,840
This is the moment where the reasoning layer meets the execution layer and it is

522
00:20:34,840 --> 00:20:37,240
actually much simpler than you might expect.

523
00:20:37,240 --> 00:20:39,400
The process follows three basic steps.

524
00:20:39,400 --> 00:20:44,480
First, you identify which PowerShell CMD lets your agent actually needs to function.

525
00:20:44,480 --> 00:20:47,680
You are not wrapping every command in the library because you want to be deliberate.

526
00:20:47,680 --> 00:20:52,320
If your agent handles password resets, you would need "GetMGuser" to find the user and

527
00:20:52,320 --> 00:20:56,320
reset "MGuser Authentication Method" passed by order to change the password.

528
00:20:56,320 --> 00:20:59,520
You would also need sent "MGuserMail" to notify them of the change.

529
00:20:59,520 --> 00:21:03,480
That is your CMDL at list which might only be a dozen functions total.

530
00:21:03,480 --> 00:21:06,320
Did you create a .NET class that wraps these CMDellets?

531
00:21:06,320 --> 00:21:10,440
This is straightforward, C# code where each method in the class calls one or more PowerShell

532
00:21:10,440 --> 00:21:11,440
CMDL.

533
00:21:11,440 --> 00:21:16,200
A method named FindUser by email calls "GetMGuser" and a method named ResetUserParsword

534
00:21:16,200 --> 00:21:18,040
calls the ResetCemDL.

535
00:21:18,040 --> 00:21:20,720
Each method does one thing and performs one clear action.

536
00:21:20,720 --> 00:21:24,040
Third, you decorate these methods with two specific attributes.

537
00:21:24,040 --> 00:21:28,040
The kernel function attribute tells semantic kernel that this method is a "Calible" tool.

538
00:21:28,040 --> 00:21:31,320
While the description attribute contains a plain English explanation of what the function

539
00:21:31,320 --> 00:21:32,320
does.

540
00:21:32,320 --> 00:21:34,840
It is the critical part that most people underestimate.

541
00:21:34,840 --> 00:21:37,320
Here is why those descriptions matter so much.

542
00:21:37,320 --> 00:21:41,080
When you register your plugin with the kernel, the kernel does not actually execute your

543
00:21:41,080 --> 00:21:42,080
code yet.

544
00:21:42,080 --> 00:21:45,400
It reads those descriptions and builds an internal model of what is available.

545
00:21:45,400 --> 00:21:50,160
It notes that there is a function called ResetUserParsword that needs a user ID and a temporary

546
00:21:50,160 --> 00:21:51,160
password.

547
00:21:51,160 --> 00:21:54,840
The kernel communicates this to the LLM and the model reads these descriptions to learn

548
00:21:54,840 --> 00:21:55,840
how to use them.

549
00:21:55,840 --> 00:21:59,920
Now when you ask the agent to solve a problem, the model has all this information ready.

550
00:21:59,920 --> 00:22:03,520
It knows what each function does and understands when each function is relevant to the task

551
00:22:03,520 --> 00:22:04,520
at hand.

552
00:22:04,520 --> 00:22:07,280
It reasons about whether to use that function based on the goal.

553
00:22:07,280 --> 00:22:11,960
This is why a description like ResetUserParsword is completely different from something vague

554
00:22:11,960 --> 00:22:14,760
like "Modify's user account settings".

555
00:22:14,760 --> 00:22:18,560
The first one tells the model exactly what the function is for while the second one leaves

556
00:22:18,560 --> 00:22:19,840
the model guessing.

557
00:22:19,840 --> 00:22:22,880
You should also document the side effects and the prerequisites.

558
00:22:22,880 --> 00:22:26,800
If your Reset function requires the user to have a mailbox, you need to say that.

559
00:22:26,800 --> 00:22:30,600
If it sends a notification automatically or logs the action to an audit system, that is

560
00:22:30,600 --> 00:22:32,240
important context for the agent.

561
00:22:32,240 --> 00:22:35,920
The model needs to understand not just what the function does, but what happens as a result

562
00:22:35,920 --> 00:22:36,920
of calling it.

563
00:22:36,920 --> 00:22:39,560
If it is a high-risk operation, you should say that explicitly.

564
00:22:39,560 --> 00:22:42,440
A good description for a password Reset function might look like this.

565
00:22:42,440 --> 00:22:46,320
It resets a user's password to a temporary value and sends that new password to their

566
00:22:46,320 --> 00:22:47,720
registered email address.

567
00:22:47,720 --> 00:22:51,440
It requires that the user exists in Azure AD and has an active mailbox.

568
00:22:51,440 --> 00:22:55,280
It also triggers an audit log entry and returns true if successful or false if the mailbox

569
00:22:55,280 --> 00:22:56,280
is unreachable.

570
00:22:56,280 --> 00:22:57,280
That is specific.

571
00:22:57,280 --> 00:23:01,040
The model reads that and knows exactly what the function does, what could go wrong and

572
00:23:01,040 --> 00:23:02,720
what the result will be.

573
00:23:02,720 --> 00:23:06,600
When the model encounters a ticket about someone unable to access their account, it sees

574
00:23:06,600 --> 00:23:10,280
this function description and realises it is the right tool for the job.

575
00:23:10,280 --> 00:23:14,320
The kernel passes these descriptions and uses them to teach the model how to reason about

576
00:23:14,320 --> 00:23:15,320
your tools.

577
00:23:15,320 --> 00:23:17,800
It is not magic, but rather a form of structured learning.

578
00:23:17,800 --> 00:23:21,720
The model studies the descriptions, the parameters and the expected outputs to learn patterns

579
00:23:21,720 --> 00:23:24,120
about when each tool is actually valuable.

580
00:23:24,120 --> 00:23:27,840
This is why good descriptions are the difference between an agent that makes smart decisions

581
00:23:27,840 --> 00:23:29,400
and one that makes random ones.

582
00:23:29,400 --> 00:23:33,680
An agent that understands the purpose and the implications of each tool can chain them together

583
00:23:33,680 --> 00:23:34,880
intelligently.

584
00:23:34,880 --> 00:23:38,440
An agent given vague descriptions will just stumble around trying different functions at

585
00:23:38,440 --> 00:23:40,200
random until something works.

586
00:23:40,200 --> 00:23:44,080
So when you wrap your PowerShell CMDlets, you should treat the descriptions like documentation

587
00:23:44,080 --> 00:23:46,040
written specifically for the AI.

588
00:23:46,040 --> 00:23:47,520
Be explicit and be specific.

589
00:23:47,520 --> 00:23:51,640
Describe not just what the function does, but why someone would want to use it and what

590
00:23:51,640 --> 00:23:53,760
the final result actually means.

591
00:23:53,760 --> 00:23:58,840
This is how static PowerShell CMDs finally become intelligent, reasoning agents.

592
00:23:58,840 --> 00:24:00,840
Designing function signatures for reasoning.

593
00:24:00,840 --> 00:24:03,960
Now that you understand the description layer, we need to talk about the actual shape

594
00:24:03,960 --> 00:24:05,520
of your functions.

595
00:24:05,520 --> 00:24:08,640
Descriptions are known aren't enough to guide an agent because the structure of your functions

596
00:24:08,640 --> 00:24:13,360
how you define parameters and what you return all dictate how well an LLM can reason about

597
00:24:13,360 --> 00:24:14,360
them.

598
00:24:14,360 --> 00:24:17,280
The core principle here is single-purpose design.

599
00:24:17,280 --> 00:24:21,800
One function should do exactly one thing, which means one clear and specific action.

600
00:24:21,800 --> 00:24:25,080
This isn't just a suggestion for clean code, it's how agents think.

601
00:24:25,080 --> 00:24:29,640
When you build functions for an agent to call, every parameter you add increases the cognitive

602
00:24:29,640 --> 00:24:30,920
load on the model.

603
00:24:30,920 --> 00:24:35,240
Every possible return state creates a new layer of ambiguity that the agent has to navigate.

604
00:24:35,240 --> 00:24:38,680
The narrower and more focused your function is, the clearer the model's decision making

605
00:24:38,680 --> 00:24:39,680
becomes.

606
00:24:39,680 --> 00:24:43,560
A function that takes 15 parameters with 10 optional branches is a puzzle that forces

607
00:24:43,560 --> 00:24:47,640
the model to reason about parameter combinations that might not even make sense together.

608
00:24:47,640 --> 00:24:52,280
On the other hand, a function that takes two required parameters and returns one simple result

609
00:24:52,280 --> 00:24:53,280
is transparent.

610
00:24:53,280 --> 00:24:56,760
So the model understands exactly what happens when it triggers that call.

611
00:24:56,760 --> 00:24:58,960
Let's look at a concrete example of bad design.

612
00:24:58,960 --> 00:25:03,160
You might write a function that takes a JSON blob as input to handle multiple tasks.

613
00:25:03,160 --> 00:25:07,680
This JSON could contain a user ID to reset a password, a group ID to add a member, or even

614
00:25:07,680 --> 00:25:10,120
a device ID to trigger compliance checks.

615
00:25:10,120 --> 00:25:14,400
The function reads the JSON, figures out what action to perform, and then executes it.

616
00:25:14,400 --> 00:25:18,600
While this saves you from code duplication and feels efficient to write, it's actually terrible

617
00:25:18,600 --> 00:25:19,840
for agent reasoning.

618
00:25:19,840 --> 00:25:23,400
The model sees this function and starts guessing what should go in the JSON or what might

619
00:25:23,400 --> 00:25:24,400
come out of it.

620
00:25:24,400 --> 00:25:28,360
Because the input is ambiguous, the model might construct a JSON object that doesn't make

621
00:25:28,360 --> 00:25:30,440
sense for the operation it's trying to perform.

622
00:25:30,440 --> 00:25:34,960
It might pass fields that the function doesn't use, or it might misrequire fields entirely.

623
00:25:34,960 --> 00:25:38,720
You've essentially made the model's job harder by trying to make your own code simpler.

624
00:25:38,720 --> 00:25:41,480
Good design separates these into three distinct functions.

625
00:25:41,480 --> 00:25:46,120
One function finds a user by email, another resets that uses password, and a third notifies

626
00:25:46,120 --> 00:25:47,320
them of the change.

627
00:25:47,320 --> 00:25:51,400
Each function has a clear purpose and takes only the parameters it actually needs to function.

628
00:25:51,400 --> 00:25:55,040
This ensures each function returns exactly what the model needs to know to decide what

629
00:25:55,040 --> 00:25:56,440
to do next.

630
00:25:56,440 --> 00:25:59,200
Parameters should always be explicit and strongly typed.

631
00:25:59,200 --> 00:26:01,880
Don't accept generic strings that could mean multiple things.

632
00:26:01,880 --> 00:26:06,360
If you need a user ID, you should accept a GUID, and if you need a temporary password,

633
00:26:06,360 --> 00:26:07,840
you should accept a secure string.

634
00:26:07,840 --> 00:26:11,360
If you need a mailbox address, you should accept an email address and validate the format.

635
00:26:11,360 --> 00:26:15,480
Strong typing prevents the model from passing invalid data, and it tells the model exactly

636
00:26:15,480 --> 00:26:17,520
what kind of data the function expects.

637
00:26:17,520 --> 00:26:20,800
The model reasons better with narrow, well-defined tools because it doesn't have to figure

638
00:26:20,800 --> 00:26:22,400
out whether its input is valid.

639
00:26:22,400 --> 00:26:26,120
It doesn't have to guess what the function will do because the contract is clear.

640
00:26:26,120 --> 00:26:27,840
Return values should also be structured.

641
00:26:27,840 --> 00:26:31,200
Don't just return a string, return a JSON object instead.

642
00:26:31,200 --> 00:26:35,640
If you're checking whether a user exists, return a structured object like Psa, Tsa, Tsa,

643
00:26:35,640 --> 00:26:43,360
Tsa exists, true, user ID, ABC1023 on display name, John Smith, is rather than a simple true

644
00:26:43,360 --> 00:26:44,760
or false.

645
00:26:44,760 --> 00:26:49,960
If you're attempting a password reset, return, success, true, temporary, password, null

646
00:26:49,960 --> 00:26:53,920
notification, send, true, errors.

647
00:26:53,920 --> 00:26:58,000
Instead of just the word success, this matters because the agent needs to pass the result

648
00:26:58,000 --> 00:26:59,640
and decide on the next move.

649
00:26:59,640 --> 00:27:02,800
If you return a plain string, the model has to interpret what that string means, which

650
00:27:02,800 --> 00:27:06,000
leads to questions about whether it's an error or a success.

651
00:27:06,000 --> 00:27:10,400
If you return a structured object with explicit fields for success, status and errors encountered,

652
00:27:10,400 --> 00:27:12,160
the model knows exactly what happened.

653
00:27:12,160 --> 00:27:14,360
It can reason clearly about what to do next.

654
00:27:14,360 --> 00:27:16,840
Structured returns also make you logging much easier.

655
00:27:16,840 --> 00:27:20,600
You can serialize the return object directly to create an audit trail that shows exactly

656
00:27:20,600 --> 00:27:22,120
what each function returned.

657
00:27:22,120 --> 00:27:25,840
This allows you to analyze patterns in agent behavior because the data remains consistent

658
00:27:25,840 --> 00:27:27,320
across every execution.

659
00:27:27,320 --> 00:27:30,360
Think about function design as teaching the model a new language.

660
00:27:30,360 --> 00:27:34,520
Each function is a word, the signature is the definition of that word, and the parameters

661
00:27:34,520 --> 00:27:36,320
are what the word needs to work.

662
00:27:36,320 --> 00:27:38,200
Return values are what the word produces.

663
00:27:38,200 --> 00:27:42,080
If your words are vague and overloaded, the sentences won't make sense, but if your words

664
00:27:42,080 --> 00:27:45,200
are precise and single purpose, thoughts flow clearly.

665
00:27:45,200 --> 00:27:49,120
An agent that calls a dozen narrow well-defined functions will reason circles around an agent

666
00:27:49,120 --> 00:27:51,400
that calls three kitchen sink functions.

667
00:27:51,400 --> 00:27:55,240
Every time you remove complexity from a function, you make the agent smarter.

668
00:27:55,240 --> 00:27:57,320
The plan execute refined loop.

669
00:27:57,320 --> 00:27:58,840
This is where everything changes.

670
00:27:58,840 --> 00:28:01,800
Up until now, we've been talking about the building blocks like the reasoning engine,

671
00:28:01,800 --> 00:28:03,800
the data access, and the function design.

672
00:28:03,800 --> 00:28:07,400
Now we're going to talk about the actual workflow that ties it all together, and it's

673
00:28:07,400 --> 00:28:09,800
radically different from how scripts work.

674
00:28:09,800 --> 00:28:12,200
Standard scripts work in a linear deterministic way.

675
00:28:12,200 --> 00:28:15,640
They go from step one to step two to step three, and then they're done.

676
00:28:15,640 --> 00:28:17,560
They execute a predetermined sequence.

677
00:28:17,560 --> 00:28:20,960
And if an unexpected condition occurs, they either handle it with predefined logic or

678
00:28:20,960 --> 00:28:21,960
they fail.

679
00:28:21,960 --> 00:28:25,960
There's no adaptation and no recovery path except for what you explicitly programmed into

680
00:28:25,960 --> 00:28:27,200
the code.

681
00:28:27,200 --> 00:28:31,280
It works differently by following a cycle of thinking, acting, evaluating, and adjusting.

682
00:28:31,280 --> 00:28:35,080
The agent reads the ticket and builds a plan, then it decides what steps are needed based

683
00:28:35,080 --> 00:28:36,560
on the current context.

684
00:28:36,560 --> 00:28:40,440
After it executes those steps, it looks at what happened to see if the plan worked.

685
00:28:40,440 --> 00:28:43,800
If the goal wasn't achieved, the agent asks what went wrong and what that means for the

686
00:28:43,800 --> 00:28:44,960
next attempt.

687
00:28:44,960 --> 00:28:47,640
Then it goes back to planning and tries a different approach.

688
00:28:47,640 --> 00:28:51,480
This is the core agent workflow, plan, execute, and refine.

689
00:28:51,480 --> 00:28:55,400
The key insight is that all three stages happen inside the agent's reasoning loop.

690
00:28:55,400 --> 00:28:58,680
The agent isn't just following a script you wrote, it's building a mental model of the

691
00:28:58,680 --> 00:29:02,120
problem, and updating that model based on what it learned.

692
00:29:02,120 --> 00:29:03,680
Step one is the planning phase.

693
00:29:03,680 --> 00:29:07,480
The agent reads the incoming ticket and extracts the key information to understand what the

694
00:29:07,480 --> 00:29:08,760
user is trying to accomplish.

695
00:29:08,760 --> 00:29:12,720
It looks at its available tools, which are all those power shell functions you wrapped and

696
00:29:12,720 --> 00:29:14,160
builds a sequence of actions.

697
00:29:14,160 --> 00:29:16,600
But it doesn't execute yet because it needs to think first.

698
00:29:16,600 --> 00:29:20,720
It reasons about the order, asking if it makes sense to check if the user exists before

699
00:29:20,720 --> 00:29:22,280
resetting their password.

700
00:29:22,280 --> 00:29:26,280
The agent realizes it shouldn't notify the user before confirming the reset succeeded,

701
00:29:26,280 --> 00:29:28,160
so it builds a plan based on that logic.

702
00:29:28,160 --> 00:29:29,480
Step two is execution.

703
00:29:29,480 --> 00:29:33,080
Now the agent actually calls those power shell functions in the sequence it planned.

704
00:29:33,080 --> 00:29:36,760
It passes the right parameters and gets back structured results.

705
00:29:36,760 --> 00:29:39,520
Step three is refinement, and this is where it gets interesting.

706
00:29:39,520 --> 00:29:42,760
The agent looks at what came back to see if the first function succeeded.

707
00:29:42,760 --> 00:29:46,920
If it did, the agent confirms that and moves to the next step in the plan.

708
00:29:46,920 --> 00:29:50,360
But what if the function returned, exists, false?

709
00:29:50,360 --> 00:29:52,920
It wasn't in the plan, but the agent doesn't panic.

710
00:29:52,920 --> 00:29:54,600
It recalculates.

711
00:29:54,600 --> 00:29:58,440
If the user doesn't exist, the agent might assume the email address in the ticket is wrong

712
00:29:58,440 --> 00:30:00,040
or contains a typo.

713
00:30:00,040 --> 00:30:04,160
It might decide to search for users with a similar name, or it might ask the original request

714
00:30:04,160 --> 00:30:05,640
of a clarification.

715
00:30:05,640 --> 00:30:09,240
The plan adapts based on what actually happened in the environment.

716
00:30:09,240 --> 00:30:11,960
This is not linear execution, it's adaptive reasoning.

717
00:30:11,960 --> 00:30:16,040
This matters because in real enterprise work, things rarely go exactly as planned.

718
00:30:16,040 --> 00:30:20,080
A user might have a weird permission state you never anticipated, or a power shell function

719
00:30:20,080 --> 00:30:22,480
might return an error you didn't write logic to handle.

720
00:30:22,480 --> 00:30:25,520
Sometimes a prerequisite isn't met or an API call times out.

721
00:30:25,520 --> 00:30:27,760
Scripts fail on these issues, but an agent adapts.

722
00:30:27,760 --> 00:30:29,200
Here's a concrete example.

723
00:30:29,200 --> 00:30:32,560
An agent receives a ticket saying, "I can't log into my laptop."

724
00:30:32,560 --> 00:30:35,840
The agent plans the diagnosis by getting the device from Azure AD,

725
00:30:35,840 --> 00:30:38,480
checking compliance, and verifying the user's license.

726
00:30:38,480 --> 00:30:39,640
The plan is reasonable.

727
00:30:39,640 --> 00:30:43,560
It executes and calls the device "lookup function" which works perfectly.

728
00:30:43,560 --> 00:30:46,720
Then it calls the compliance check, but the device is non-compliant.

729
00:30:46,720 --> 00:30:49,280
The plan was based on the assumption that the device was compliant

730
00:30:49,280 --> 00:30:50,720
and that assumption just broke.

731
00:30:50,720 --> 00:30:52,320
The agent recalculates.

732
00:30:52,320 --> 00:30:56,160
If the device is non-compliant, the issue might not be about licensing,

733
00:30:56,160 --> 00:30:58,960
it might be that conditional access is blocking the login.

734
00:30:58,960 --> 00:31:03,440
The agent loops back to planning and creates a new plan to check the conditional access policies.

735
00:31:03,440 --> 00:31:06,960
It executes the new plan and evaluates the result success.

736
00:31:06,960 --> 00:31:09,960
The agent found the specific policy that's blocking the login.

737
00:31:09,960 --> 00:31:11,360
Now it needs to decide what to do.

738
00:31:11,360 --> 00:31:15,600
It probably shouldn't fix this autonomously because changing a conditional access policy is high risk.

739
00:31:15,600 --> 00:31:18,320
This is a decision point where the agent needs human judgment,

740
00:31:18,320 --> 00:31:21,200
so it builds a structured proposal instead of executing a fix.

741
00:31:21,200 --> 00:31:24,720
It tells an IT manager what the issue is and asks if it should apply the fix.

742
00:31:24,720 --> 00:31:28,080
The manager approves it in Teams and then the agent executes.

743
00:31:28,080 --> 00:31:30,880
This is the plan "execute refine loop in action".

744
00:31:30,880 --> 00:31:33,200
The agent isn't following a predetermined script.

745
00:31:33,200 --> 00:31:36,160
It's building a mental model and adjusting based on what it learns.

746
00:31:36,160 --> 00:31:39,440
When things go sideways, it doesn't fail. It adapts.

747
00:31:39,440 --> 00:31:41,280
Orca-strating multi-step workflows.

748
00:31:41,280 --> 00:31:44,000
Now we need to look at what actually makes this useful for real work,

749
00:31:44,000 --> 00:31:47,200
because the reality is that IT tickets are almost never simple.

750
00:31:47,200 --> 00:31:49,920
They don't just show up as a clean request to reset a password.

751
00:31:49,920 --> 00:31:53,280
Instead, they arrive as a messy tangle of interconnected problems

752
00:31:53,280 --> 00:31:55,200
that touch five different systems at once.

753
00:31:55,200 --> 00:31:58,240
Take a common ticket like user can't access Teams.

754
00:31:58,240 --> 00:32:00,080
On the surface, that sounds like a single problem,

755
00:32:00,080 --> 00:32:01,760
but in reality, it's a dozen.

756
00:32:01,760 --> 00:32:03,360
To figure out what's actually happening,

757
00:32:03,360 --> 00:32:05,680
you have to check if the user exists in Azure AD,

758
00:32:05,680 --> 00:32:06,960
verify their Teams license,

759
00:32:06,960 --> 00:32:09,280
and see if the service is even enabled for the company.

760
00:32:09,280 --> 00:32:11,120
Then you have to look at their device compliance,

761
00:32:11,120 --> 00:32:12,400
check for network blocks,

762
00:32:12,400 --> 00:32:14,080
investigate mailbox sync states,

763
00:32:14,080 --> 00:32:15,840
and confirm they're in the right groups.

764
00:32:15,840 --> 00:32:18,800
That isn't a two-step process. It's a 10-step investigation,

765
00:32:18,800 --> 00:32:20,320
where the order of operations matters.

766
00:32:20,320 --> 00:32:23,600
You can't check for a license if you haven't confirmed the user exists yet,

767
00:32:23,600 --> 00:32:25,600
and you can't verify device compliance

768
00:32:25,600 --> 00:32:28,000
if you don't even know which hardware they're using.

769
00:32:28,000 --> 00:32:29,760
Some of these checks are prerequisites,

770
00:32:29,760 --> 00:32:30,720
some are fallbacks,

771
00:32:30,720 --> 00:32:33,280
and others only matter if the first three things fail.

772
00:32:33,280 --> 00:32:36,000
A traditional script tries to hard-code this entire sequence

773
00:32:36,000 --> 00:32:37,600
from step one to step 10.

774
00:32:37,600 --> 00:32:38,720
If anything goes sideways,

775
00:32:38,720 --> 00:32:40,400
the script relies on conditional logic

776
00:32:40,400 --> 00:32:42,400
that you had to anticipate months ago,

777
00:32:42,400 --> 00:32:43,760
but you can't predict everything.

778
00:32:43,760 --> 00:32:45,680
Maybe a serial number is missing from the ticket,

779
00:32:45,680 --> 00:32:47,120
or an API call times out,

780
00:32:47,120 --> 00:32:48,720
or the mailbox is in a weird state

781
00:32:48,720 --> 00:32:50,640
that your code wasn't built to handle.

782
00:32:50,640 --> 00:32:52,720
When that happens, the script either hits a dead end,

783
00:32:52,720 --> 00:32:53,840
or it just fails.

784
00:32:53,840 --> 00:32:56,240
An agent doesn't follow a hard-coded map.

785
00:32:56,240 --> 00:32:57,360
It reads the ticket,

786
00:32:57,360 --> 00:33:00,000
and decides what needs to happen next based on the evidence.

787
00:33:00,000 --> 00:33:02,480
It understands that the first logical move

788
00:33:02,480 --> 00:33:04,080
is to confirm the user exists,

789
00:33:04,080 --> 00:33:06,240
so it makes that decision and executes it.

790
00:33:06,240 --> 00:33:07,520
When the result comes back,

791
00:33:07,520 --> 00:33:10,320
that data either confirms or destroys the next assumption,

792
00:33:10,320 --> 00:33:12,560
and the agent adjusts its plan accordingly.

793
00:33:12,560 --> 00:33:14,480
Watch how this workflow actually unfolds.

794
00:33:14,480 --> 00:33:16,720
The agent reads a ticket from JSmith@Company,

795
00:33:16,720 --> 00:33:18,160
comes saying they can't get into teams.

796
00:33:18,160 --> 00:33:20,880
The agent plans to check the user's state and the service state,

797
00:33:20,880 --> 00:33:22,640
so it calls the lookup function first.

798
00:33:22,640 --> 00:33:24,720
The result shows the user exists with ID,

799
00:33:24,720 --> 00:33:26,400
ABC123.

800
00:33:26,400 --> 00:33:28,480
Next, it checks the license and sees its active.

801
00:33:28,480 --> 00:33:30,080
It checks if the service is enabled,

802
00:33:30,080 --> 00:33:31,520
and the answer is yes.

803
00:33:31,520 --> 00:33:32,560
Then it hits a snag.

804
00:33:32,560 --> 00:33:34,320
It needs to check the device state,

805
00:33:34,320 --> 00:33:36,960
but the ticket doesn't say which device is the problem.

806
00:33:36,960 --> 00:33:39,120
The agent sees two registered devices

807
00:33:39,120 --> 00:33:40,720
and realizes it can't move forward

808
00:33:40,720 --> 00:33:42,240
without knowing which one is failing.

809
00:33:42,240 --> 00:33:44,640
It leaves a note for the human asking for clarification,

810
00:33:44,640 --> 00:33:46,160
but it doesn't just stop there.

811
00:33:46,160 --> 00:33:48,400
It keeps digging and finds a conditional access policy

812
00:33:48,400 --> 00:33:50,880
that's currently blocking all unmanaged devices.

813
00:33:50,880 --> 00:33:52,320
Now the agent has the full picture.

814
00:33:52,320 --> 00:33:54,320
The likely culprit is that one of the user's devices

815
00:33:54,320 --> 00:33:55,120
isn't managed,

816
00:33:55,120 --> 00:33:56,880
and the security policy is doing its job.

817
00:33:56,880 --> 00:33:58,000
The agent decides on a fix,

818
00:33:58,000 --> 00:34:00,400
like enrolling the device or creating an exception,

819
00:34:00,400 --> 00:34:02,400
but it knows these are high-risk moves.

820
00:34:02,400 --> 00:34:04,160
It won't act autonomously here.

821
00:34:04,160 --> 00:34:07,360
Instead, it builds a structured proposal for an IT manager.

822
00:34:07,360 --> 00:34:10,320
The manager gets a notification in teams with a clear breakdown.

823
00:34:10,320 --> 00:34:12,800
The user is blocked on an unmanaged device.

824
00:34:12,800 --> 00:34:14,640
And here are the three ways to fix it.

825
00:34:14,640 --> 00:34:17,040
The manager clicks "Approve for device enrollment"

826
00:34:17,040 --> 00:34:18,880
and the agent handles the rest.

827
00:34:18,880 --> 00:34:21,360
It runs the enrollment, verifies the fix,

828
00:34:21,360 --> 00:34:23,440
and tells the user they're good to go.

829
00:34:23,440 --> 00:34:25,440
This entire loop, the diagnosis,

830
00:34:25,440 --> 00:34:26,800
the adaptation, the escalation,

831
00:34:26,800 --> 00:34:28,160
and the final execution

832
00:34:28,160 --> 00:34:30,240
is what a multi-step workflow looks like.

833
00:34:30,240 --> 00:34:31,680
The agent decided the sequence

834
00:34:31,680 --> 00:34:33,680
and adapted when it hit a gap in the data.

835
00:34:33,680 --> 00:34:36,160
It didn't break just because a condition was unexpected.

836
00:34:36,160 --> 00:34:37,360
It reasoned its way through.

837
00:34:37,360 --> 00:34:38,800
A hard-coded script fails here

838
00:34:38,800 --> 00:34:41,440
because the person writing it couldn't predict every single variable.

839
00:34:41,440 --> 00:34:43,920
You can only code for the problems you've already thought of.

840
00:34:43,920 --> 00:34:46,800
An agent reasons about what matters based on the live ticket,

841
00:34:46,800 --> 00:34:48,160
deciding what to query,

842
00:34:48,160 --> 00:34:50,560
and in what order based on what it learns at every step.

843
00:34:50,560 --> 00:34:52,400
This is why agents handle variety

844
00:34:52,400 --> 00:34:54,640
without needing a script rewrite every week.

845
00:34:54,640 --> 00:34:57,200
The human in the loop isn't a feature you bolt on later.

846
00:34:57,200 --> 00:34:58,480
It's built into the logic.

847
00:34:58,480 --> 00:35:01,200
The agent knows exactly when it's moving from looking at data

848
00:35:01,200 --> 00:35:02,560
to changing things.

849
00:35:02,560 --> 00:35:05,200
And it stops to ask for permission before it crosses that line.

850
00:35:05,200 --> 00:35:07,840
Error handling and fallback strategies.

851
00:35:07,840 --> 00:35:09,600
We have to be honest about scripts.

852
00:35:09,600 --> 00:35:10,880
They are incredibly brittle.

853
00:35:10,880 --> 00:35:12,320
The moment an error happens,

854
00:35:12,320 --> 00:35:13,600
the whole thing stops,

855
00:35:13,600 --> 00:35:14,960
an exception is thrown,

856
00:35:14,960 --> 00:35:16,720
and the process dies.

857
00:35:16,720 --> 00:35:18,640
Then a human has to step in to find the bug,

858
00:35:18,640 --> 00:35:19,760
edit the code, test it,

859
00:35:19,760 --> 00:35:21,040
and redeploy the whole thing.

860
00:35:21,040 --> 00:35:23,520
That recovery cycle is slow, manual, and expensive.

861
00:35:23,520 --> 00:35:25,040
Agents have to work differently.

862
00:35:25,040 --> 00:35:26,080
When a problem pops up,

863
00:35:26,080 --> 00:35:28,080
they shouldn't just quit and report a failure.

864
00:35:28,080 --> 00:35:29,920
They need to recover, try a new path,

865
00:35:29,920 --> 00:35:31,040
and stay resilient.

866
00:35:31,040 --> 00:35:32,320
The difference is in the logic.

867
00:35:32,320 --> 00:35:33,200
A script says,

868
00:35:33,200 --> 00:35:34,480
"Do this and if it fails, stop."

869
00:35:34,480 --> 00:35:36,640
An agent says, "Try this."

870
00:35:36,640 --> 00:35:39,440
And if it fails, let's look at why and try the next best thing.

871
00:35:39,440 --> 00:35:40,880
Let's look at a password reset.

872
00:35:40,880 --> 00:35:42,400
The agent calls the reset function,

873
00:35:42,400 --> 00:35:44,960
but the system returns an error saying the user wasn't found.

874
00:35:44,960 --> 00:35:47,680
A standard script would just stop and escalate to a human.

875
00:35:47,680 --> 00:35:49,360
The agent, however, reads that error

876
00:35:49,360 --> 00:35:51,520
and thinks about what it actually means.

877
00:35:51,520 --> 00:35:53,680
Maybe the user exists in a different directory,

878
00:35:53,680 --> 00:35:55,840
or perhaps their name was misspelled in the ticket.

879
00:35:55,840 --> 00:35:56,800
Instead of quitting,

880
00:35:56,800 --> 00:35:58,560
the agent tries a different angle.

881
00:35:58,560 --> 00:36:00,240
It might search by a partial name,

882
00:36:00,240 --> 00:36:01,040
a phone number,

883
00:36:01,040 --> 00:36:02,880
or look for recently updated accounts.

884
00:36:02,880 --> 00:36:04,960
It can loop through these fallback strategies

885
00:36:04,960 --> 00:36:07,120
until it finds a match that works.

886
00:36:07,120 --> 00:36:09,440
The secret is that the agent has to be able to classify

887
00:36:09,440 --> 00:36:10,880
what kind of error it's looking at.

888
00:36:10,880 --> 00:36:12,480
Not all errors are created equal.

889
00:36:12,480 --> 00:36:15,360
A temporary error might be a service throttling your requests,

890
00:36:15,360 --> 00:36:18,080
which just means you need to wait 30 seconds and try again.

891
00:36:18,080 --> 00:36:20,400
A permanent error is something like a deleted account

892
00:36:20,400 --> 00:36:22,960
where no amount of retrying is going to help.

893
00:36:22,960 --> 00:36:24,160
Then you have recoverable errors

894
00:36:24,160 --> 00:36:26,080
like a missing user that might be found elsewhere

895
00:36:26,080 --> 00:36:28,240
and fatal errors like a lack of permissions.

896
00:36:28,240 --> 00:36:30,080
An agent that understands these categories

897
00:36:30,080 --> 00:36:32,000
can handle them with some intelligence.

898
00:36:32,000 --> 00:36:33,040
If it's temporary,

899
00:36:33,040 --> 00:36:35,520
it uses an exponential back-off to retry.

900
00:36:35,520 --> 00:36:38,160
If it's permanent, it skips to the next logical step.

901
00:36:38,160 --> 00:36:40,480
If it's recoverable, it tries a different tool.

902
00:36:40,480 --> 00:36:41,680
And if it's truly fatal,

903
00:36:41,680 --> 00:36:42,960
it stops and asks for help.

904
00:36:42,960 --> 00:36:46,080
In practice, this looks like an agent handling an access ticket.

905
00:36:46,080 --> 00:36:48,400
It tries the email address and gets nothing.

906
00:36:48,400 --> 00:36:50,400
That's a failure for that specific tool.

907
00:36:50,400 --> 00:36:52,640
But the agent knows it's a recoverable situation.

908
00:36:52,640 --> 00:36:54,400
It tries searching by the display name,

909
00:36:54,400 --> 00:36:56,320
finds the right person, and keeps moving.

910
00:36:56,320 --> 00:36:58,000
If every single search method fails,

911
00:36:58,000 --> 00:37:00,080
the agent finally stops and tells the human

912
00:37:00,080 --> 00:37:02,320
that the user doesn't exist anywhere in the system.

913
00:37:02,320 --> 00:37:03,440
When the human gets that message,

914
00:37:03,440 --> 00:37:05,760
they have all the context they need to make a fast call.

915
00:37:05,760 --> 00:37:07,840
They can see it's a typo or a new hire

916
00:37:07,840 --> 00:37:09,200
that hasn't been onboarded yet.

917
00:37:09,200 --> 00:37:10,800
Because the agent did the legwork,

918
00:37:10,800 --> 00:37:12,560
the human isn't starting from scratch.

919
00:37:12,560 --> 00:37:14,240
The goal here is graceful degradation.

920
00:37:14,240 --> 00:37:16,240
If the agent can't solve the whole ticket on its own,

921
00:37:16,240 --> 00:37:17,600
it doesn't just crash.

922
00:37:17,600 --> 00:37:18,960
It hands the problem to a human

923
00:37:18,960 --> 00:37:20,800
and explains exactly how far it got,

924
00:37:20,800 --> 00:37:22,880
what it tried, and what finally blocked it.

925
00:37:22,880 --> 00:37:25,520
The human isn't wasting time on diagnostics anymore.

926
00:37:25,520 --> 00:37:26,960
They're just the tiebreaker.

927
00:37:26,960 --> 00:37:27,680
To make this work,

928
00:37:27,680 --> 00:37:29,680
you have to build explicit error classification

929
00:37:29,680 --> 00:37:30,960
into your functions.

930
00:37:30,960 --> 00:37:33,760
You can't just return a success or fail flag.

931
00:37:33,760 --> 00:37:35,120
You need to provide enough data,

932
00:37:35,120 --> 00:37:37,520
so the agent can decide if there's a recovery path

933
00:37:37,520 --> 00:37:39,200
or if it's time to escalate.

934
00:37:39,200 --> 00:37:41,280
Resilient systems are designed for failure.

935
00:37:41,280 --> 00:37:42,960
You have to expect that things will break

936
00:37:42,960 --> 00:37:45,760
and give your agent the tools to try a plan B.

937
00:37:45,760 --> 00:37:48,480
By letting the agent navigate these small hurdles on its own,

938
00:37:48,480 --> 00:37:49,760
you keep the workflow moving

939
00:37:49,760 --> 00:37:52,400
instead of letting every minor error turn into a manual task

940
00:37:52,400 --> 00:37:53,280
for your team.

941
00:37:53,280 --> 00:37:54,880
Human in the loop approval gates,

942
00:37:54,880 --> 00:37:56,640
you need to draw a very clear line.

943
00:37:56,640 --> 00:37:59,600
On one side, you have things an agent can decide on its own.

944
00:37:59,600 --> 00:38:02,480
On the other, you have things that require a human judgment call.

945
00:38:02,480 --> 00:38:04,080
Getting this boundary right is the difference

946
00:38:04,080 --> 00:38:06,800
between a helpful tool and one that goes rogue.

947
00:38:06,800 --> 00:38:08,400
Not every decision should be autonomous.

948
00:38:08,400 --> 00:38:09,520
Some actions are low risk

949
00:38:09,520 --> 00:38:11,360
because they don't actually change anything.

950
00:38:11,360 --> 00:38:13,280
If an agent wants to pull a list of users,

951
00:38:13,280 --> 00:38:14,880
check forwarding rules on a mailbox

952
00:38:14,880 --> 00:38:17,280
or look at device compliance data, that's safe.

953
00:38:17,280 --> 00:38:19,760
It can do those things without asking for permission,

954
00:38:19,760 --> 00:38:21,200
but other actions are high risk.

955
00:38:21,200 --> 00:38:22,400
Deleting a user account,

956
00:38:22,400 --> 00:38:24,800
resetting MFA or changing access permissions

957
00:38:24,800 --> 00:38:26,640
can break someone's entire workday.

958
00:38:26,640 --> 00:38:28,800
These actions change the state of your environment

959
00:38:28,800 --> 00:38:30,800
and could even create a security hole.

960
00:38:30,800 --> 00:38:32,480
Because of that, you need a human to say yes

961
00:38:32,480 --> 00:38:33,920
before the agent pulls the trigger.

962
00:38:33,920 --> 00:38:36,720
The best practice for 2026 is simple.

963
00:38:36,720 --> 00:38:38,960
Agents propose and humans approve.

964
00:38:38,960 --> 00:38:41,840
The agent does all the heavy lifting during the diagnostic phase

965
00:38:41,840 --> 00:38:44,320
that gathers the context, looks at the situation,

966
00:38:44,320 --> 00:38:46,480
and reaches a conclusion about what needs to happen,

967
00:38:46,480 --> 00:38:49,120
but it doesn't execute high risk changes on its own.

968
00:38:49,120 --> 00:38:50,880
Instead, it creates a structured proposal

969
00:38:50,880 --> 00:38:53,120
that explains what it found, what it wants to do,

970
00:38:53,120 --> 00:38:54,960
and why it thinks that's the right move.

971
00:38:54,960 --> 00:38:56,880
Then it waits.

972
00:38:56,880 --> 00:38:59,200
The word "structured" is the most important part here.

973
00:38:59,200 --> 00:39:02,240
The proposal isn't just a big block of text that's hard to read.

974
00:39:02,240 --> 00:39:05,200
It's a specific object with clear fields like the proposed action,

975
00:39:05,200 --> 00:39:07,440
the reason, the risk level, and the potential impact.

976
00:39:07,440 --> 00:39:10,160
It shows which checks passed and if there are any blockers.

977
00:39:10,160 --> 00:39:12,560
By laying it out this way, a human can review the facts

978
00:39:12,560 --> 00:39:14,480
in seconds and make a fast decision.

979
00:39:14,480 --> 00:39:17,280
Think about how this looks inside Microsoft Teams.

980
00:39:17,280 --> 00:39:19,680
When an agent hits a situation that needs a human eye,

981
00:39:19,680 --> 00:39:21,040
it builds that proposal.

982
00:39:21,040 --> 00:39:24,640
But instead of sending a message, it sends an adaptive card.

983
00:39:24,640 --> 00:39:26,160
The card is clean and easy to scan.

984
00:39:26,160 --> 00:39:29,840
You see the username, the status, the proposed action, and the impact.

985
00:39:29,840 --> 00:39:32,000
It tells you if the user will be notified

986
00:39:32,000 --> 00:39:33,760
or if an audit log will be triggered.

987
00:39:33,760 --> 00:39:36,560
At the bottom, you have three simple buttons.

988
00:39:36,560 --> 00:39:39,360
Approve, reject, or ask me more questions.

989
00:39:39,360 --> 00:39:43,200
A human gets the notification and looks at the card.

990
00:39:43,200 --> 00:39:45,200
It takes maybe 10 seconds to review the details.

991
00:39:45,200 --> 00:39:46,960
If they hit "approved" the agent goes to work,

992
00:39:46,960 --> 00:39:49,040
if they reject it, the agent takes that feedback

993
00:39:49,040 --> 00:39:50,160
and tries a different path.

994
00:39:50,160 --> 00:39:53,040
If they have questions, the agent can provide the diagnostic data

995
00:39:53,040 --> 00:39:54,640
it used to reach that conclusion.

996
00:39:54,640 --> 00:39:56,960
The human is making an informed choice, not a guest.

997
00:39:56,960 --> 00:39:58,880
This is what we call "risk-based" tearing.

998
00:39:58,880 --> 00:40:00,640
Low-risk actions stay autonomous,

999
00:40:00,640 --> 00:40:03,680
but medium-risk tasks might need a team lead to sign off.

1000
00:40:03,680 --> 00:40:05,360
High-risk actions like deleting a user

1001
00:40:05,360 --> 00:40:07,600
should require a manager or a security officer.

1002
00:40:07,600 --> 00:40:10,800
Your policy layer defines exactly what fits into each tier.

1003
00:40:10,800 --> 00:40:13,760
This gives humans control over the decisions that actually matter

1004
00:40:13,760 --> 00:40:15,840
while letting the agent's handle the small stuff.

1005
00:40:15,840 --> 00:40:18,000
The beauty of this model is that it scales.

1006
00:40:18,000 --> 00:40:20,320
One person approving decisions won't become a bottleneck

1007
00:40:20,320 --> 00:40:22,240
if most of the work doesn't need approval.

1008
00:40:22,240 --> 00:40:23,840
The agent handles the easy stuff,

1009
00:40:23,840 --> 00:40:26,960
like running diagnostics and fixing low-risk queries.

1010
00:40:26,960 --> 00:40:30,320
Humans are no longer stuck doing the busy work or running routine tasks.

1011
00:40:30,320 --> 00:40:32,160
They are making the calls that matter.

1012
00:40:32,160 --> 00:40:34,160
Their time is spent on actual decision-making

1013
00:40:34,160 --> 00:40:37,200
rather than the administrative work that leads up to it.

1014
00:40:37,200 --> 00:40:40,320
In this setup, the agent is a decision support system.

1015
00:40:40,320 --> 00:40:42,240
It isn't there to replace human judgment,

1016
00:40:42,240 --> 00:40:43,280
but to augment it.

1017
00:40:43,280 --> 00:40:44,960
It gathers all the relevant info,

1018
00:40:44,960 --> 00:40:46,000
analyzes it,

1019
00:40:46,000 --> 00:40:47,840
and hands over a clear recommendation.

1020
00:40:47,840 --> 00:40:50,080
The human still brings their expertise

1021
00:40:50,080 --> 00:40:51,760
and organizational knowledge to the table.

1022
00:40:51,760 --> 00:40:54,560
The difference is that they're making that choice with complete information

1023
00:40:54,560 --> 00:40:56,000
instead of operating in the dark.

1024
00:40:56,000 --> 00:40:57,360
This is also how you build trust.

1025
00:40:57,360 --> 00:40:59,120
Organizations don't trust machines

1026
00:40:59,120 --> 00:41:01,760
that make irreversible changes without asking first.

1027
00:41:01,760 --> 00:41:03,760
But they do trust systems that propose a plan,

1028
00:41:03,760 --> 00:41:05,840
explain the logic and wait for a green light.

1029
00:41:05,840 --> 00:41:08,000
You aren't handing over the keys to the kingdom.

1030
00:41:08,000 --> 00:41:10,400
You're just letting the machine do the analytical work

1031
00:41:10,400 --> 00:41:12,640
so you can focus on the final decision.

1032
00:41:12,640 --> 00:41:16,160
The agent becomes a collaborator rather than a replacement worker.

1033
00:41:16,160 --> 00:41:17,280
It does what is best at,

1034
00:41:17,280 --> 00:41:19,920
which is rapid analysis and calling APIs.

1035
00:41:19,920 --> 00:41:21,200
You do what your best at,

1036
00:41:21,200 --> 00:41:23,200
which is weighing risk and understanding nuance.

1037
00:41:23,200 --> 00:41:24,640
When you work together like this,

1038
00:41:24,640 --> 00:41:26,720
you move much faster than either of you could alone.

1039
00:41:26,720 --> 00:41:28,640
Case study.

1040
00:41:28,640 --> 00:41:30,240
Autonomous ticket resolution.

1041
00:41:30,240 --> 00:41:32,720
Let's look at a real scenario to see how this works.

1042
00:41:32,720 --> 00:41:35,440
This is the step-by-step process of an autonomous agent

1043
00:41:35,440 --> 00:41:37,440
handling a ticket from start to finish.

1044
00:41:37,440 --> 00:41:40,080
A user sends in a ticket at 9.47 am.

1045
00:41:40,080 --> 00:41:41,840
They say they can't log into their laptop

1046
00:41:41,840 --> 00:41:43,280
because of a compliance error

1047
00:41:43,280 --> 00:41:44,880
and they need it fixed immediately.

1048
00:41:44,880 --> 00:41:46,720
There's no serial number, no error code,

1049
00:41:46,720 --> 00:41:48,080
and no extra context.

1050
00:41:48,080 --> 00:41:49,440
It's just a frustrated message.

1051
00:41:49,440 --> 00:41:51,600
The agent picks up the ticket the second it arrives.

1052
00:41:51,600 --> 00:41:54,240
The first thing it does is pull the email from the metadata.

1053
00:41:54,240 --> 00:41:55,440
It knows the device is involved,

1054
00:41:55,440 --> 00:41:56,880
but it doesn't know which one yet.

1055
00:41:56,880 --> 00:41:58,240
The agent has a starting point,

1056
00:41:58,240 --> 00:42:00,080
but it needs to go find the missing data.

1057
00:42:00,080 --> 00:42:03,440
It starts the diagnosis by querying Azure AD to find the user.

1058
00:42:03,440 --> 00:42:06,320
The account is active and there are no obvious issues there.

1059
00:42:06,320 --> 00:42:09,920
Next, it checks in tune to see what devices are registered to that person.

1060
00:42:09,920 --> 00:42:11,600
It finds two a laptop and a phone.

1061
00:42:11,600 --> 00:42:13,040
Since the ticket mentioned a laptop,

1062
00:42:13,040 --> 00:42:15,200
the agent pulls the compliance status for both.

1063
00:42:15,200 --> 00:42:16,480
It sees that the phone is fine,

1064
00:42:16,480 --> 00:42:18,640
but the laptop is marked as non-compliant.

1065
00:42:18,640 --> 00:42:20,720
The laptop hasn't checked in for three days.

1066
00:42:20,720 --> 00:42:22,640
The operating system is on an old build

1067
00:42:22,640 --> 00:42:25,280
and the current policy requires a much newer version.

1068
00:42:25,280 --> 00:42:26,720
Now the agent has the answer.

1069
00:42:26,720 --> 00:42:29,200
The device is blocked by a conditional access policy

1070
00:42:29,200 --> 00:42:30,880
because the OS is outdated.

1071
00:42:30,880 --> 00:42:32,480
But the agent can't just force an update.

1072
00:42:32,480 --> 00:42:35,440
That's a high-risk move that could fail or interrupt the user's work.

1073
00:42:35,440 --> 00:42:38,400
The agent doesn't have the authority to make that call on its own.

1074
00:42:38,400 --> 00:42:40,880
Instead of stopping, the agent builds a proposal.

1075
00:42:40,880 --> 00:42:42,640
It organizes everything it learned,

1076
00:42:42,640 --> 00:42:44,160
including the device ID,

1077
00:42:44,160 --> 00:42:45,200
the current build,

1078
00:42:45,200 --> 00:42:47,280
and the specific policy that's blocking access.

1079
00:42:47,280 --> 00:42:50,240
It knows the fix is to update the OS to the latest version.

1080
00:42:50,240 --> 00:42:52,880
It could also suggest replacing the device if it were too old,

1081
00:42:52,880 --> 00:42:55,040
but an update is the fastest way forward.

1082
00:42:55,040 --> 00:42:58,000
The agent sends this proposal to the IT manager on duty.

1083
00:42:58,000 --> 00:42:59,920
It doesn't send an email that will get buried.

1084
00:42:59,920 --> 00:43:03,040
It sends a team's adaptive card that pops up as a notification.

1085
00:43:03,040 --> 00:43:04,880
The manager sees the user impact,

1086
00:43:04,880 --> 00:43:06,000
the technical details,

1087
00:43:06,000 --> 00:43:07,920
and the risk level all in one place.

1088
00:43:07,920 --> 00:43:10,480
The manager reads the card in about 20 seconds.

1089
00:43:10,480 --> 00:43:11,600
They understand the requirement

1090
00:43:11,600 --> 00:43:13,360
and they see that the fix makes sense.

1091
00:43:13,360 --> 00:43:14,800
They hit a proof.

1092
00:43:14,800 --> 00:43:16,000
The moment that button is pressed,

1093
00:43:16,000 --> 00:43:18,160
the agent moves into the execution phase.

1094
00:43:18,160 --> 00:43:19,760
This is where delegation is key.

1095
00:43:19,760 --> 00:43:21,920
The agent might not push the update directly,

1096
00:43:21,920 --> 00:43:24,160
but it can trigger the workflow in your management system.

1097
00:43:24,160 --> 00:43:27,120
It moves the device into an update group and sends a note to the user.

1098
00:43:27,120 --> 00:43:29,200
It tells them a security update is ready

1099
00:43:29,200 --> 00:43:31,200
and asks them to save their work and restart.

1100
00:43:31,200 --> 00:43:33,760
It can even alert the manager once the restart happens,

1101
00:43:33,760 --> 00:43:35,120
so they can keep an eye on it.

1102
00:43:35,120 --> 00:43:37,120
The user gets the notification on their phone.

1103
00:43:37,120 --> 00:43:38,800
They probably expected this to take all day,

1104
00:43:38,800 --> 00:43:41,680
but now they have a clear instruction to just restart their machine.

1105
00:43:41,680 --> 00:43:43,840
They reboot the update runs for about 15 minutes,

1106
00:43:43,840 --> 00:43:46,560
and the device comes back online with the correct OS build.

1107
00:43:46,560 --> 00:43:49,120
The compliance start as flips to green almost immediately.

1108
00:43:49,120 --> 00:43:50,960
The agent keeps watching that status.

1109
00:43:50,960 --> 00:43:52,880
As soon as the device shows as compliant,

1110
00:43:52,880 --> 00:43:54,480
it knows the problem is solved.

1111
00:43:54,480 --> 00:43:57,840
It checks Azure AD one last time to confirm the block is gone.

1112
00:43:57,840 --> 00:44:00,160
Then it sends a final message to the user,

1113
00:44:00,160 --> 00:44:02,240
letting them know they can log back in.

1114
00:44:02,240 --> 00:44:04,560
It closes the ticket with a full summary of what happened

1115
00:44:04,560 --> 00:44:05,680
and how it was fixed.

1116
00:44:05,680 --> 00:44:07,200
The total time from the first message

1117
00:44:07,200 --> 00:44:09,360
to the final resolution was 15 minutes.

1118
00:44:09,360 --> 00:44:11,120
If a human had handled this manually,

1119
00:44:11,120 --> 00:44:13,840
they would have spent an hour just going back and forth with the user.

1120
00:44:13,840 --> 00:44:16,000
They would have had to remote in, check in tune,

1121
00:44:16,000 --> 00:44:17,920
and manually walk the user through the update.

1122
00:44:17,920 --> 00:44:19,600
That's two or three hours of wasted time.

1123
00:44:19,600 --> 00:44:21,200
The agent didn't take the human's job.

1124
00:44:21,200 --> 00:44:22,720
The manager still made the final call.

1125
00:44:22,720 --> 00:44:24,960
The agent just did the boring diagnostic work

1126
00:44:24,960 --> 00:44:27,280
and handled the execution once it had permission.

1127
00:44:27,280 --> 00:44:30,080
The human handled the judgment and the agent handled the speed.

1128
00:44:30,080 --> 00:44:32,320
This is the force multiplier effect in action.

1129
00:44:32,320 --> 00:44:35,280
The agent takes care of the complexity and the data analysis.

1130
00:44:35,280 --> 00:44:37,200
The human takes care of the authorization.

1131
00:44:37,200 --> 00:44:39,680
The result is a level of speed and accuracy

1132
00:44:39,680 --> 00:44:42,480
that you just can't get when you're working alone.

1133
00:44:42,480 --> 00:44:44,400
Scaling to enterprise operations.

1134
00:44:44,400 --> 00:44:47,200
One agent resolving one ticket is a great proof of concept,

1135
00:44:47,200 --> 00:44:48,400
but in a real organization,

1136
00:44:48,400 --> 00:44:50,080
you don't deal with one ticket a day.

1137
00:44:50,080 --> 00:44:51,920
You deal with hundreds or thousands.

1138
00:44:51,920 --> 00:44:53,360
This is where the model breaks.

1139
00:44:53,360 --> 00:44:55,120
We have to stop talking about a single agent

1140
00:44:55,120 --> 00:44:57,600
and start talking about a fleet of agents running in parallel.

1141
00:44:57,600 --> 00:45:00,400
The architecture changes fundamentally when you move to this level.

1142
00:45:00,400 --> 00:45:02,160
Instead of one agent and one orchestrator,

1143
00:45:02,160 --> 00:45:04,720
you have a pool of agents, a work dispatcher,

1144
00:45:04,720 --> 00:45:07,120
and a monitoring system that watches everything.

1145
00:45:07,120 --> 00:45:10,400
Think of the dispatcher as the nervous system of the entire operation.

1146
00:45:10,400 --> 00:45:12,960
Tickets come in and get routed to the first available agent

1147
00:45:12,960 --> 00:45:15,440
with the right skill set, which keeps the flow moving.

1148
00:45:15,440 --> 00:45:17,840
An identity agent handles user account issues,

1149
00:45:17,840 --> 00:45:20,160
while an infrastructure agent manages device compliance

1150
00:45:20,160 --> 00:45:22,320
and an application agent deals with licensing.

1151
00:45:22,320 --> 00:45:24,480
The dispatcher looks at the incoming request,

1152
00:45:24,480 --> 00:45:25,920
categorizes the problem,

1153
00:45:25,920 --> 00:45:27,680
and sends it to the right specialist.

1154
00:45:27,680 --> 00:45:29,280
If every identity agent is busy,

1155
00:45:29,280 --> 00:45:32,160
the ticket sits in a queue until someone finishes their current task

1156
00:45:32,160 --> 00:45:33,200
and picks up the next one.

1157
00:45:33,200 --> 00:45:34,480
This is load balancing,

1158
00:45:34,480 --> 00:45:37,760
but it is much smarter than just assigning tasks in a circle.

1159
00:45:37,760 --> 00:45:40,560
Each agent tracks its own performance metrics in real time,

1160
00:45:40,560 --> 00:45:42,560
measuring success rates, resolution times,

1161
00:45:42,560 --> 00:45:44,800
and how often it has to escalate a problem.

1162
00:45:44,800 --> 00:45:47,600
The dispatcher uses this data to root work intelligently.

1163
00:45:47,600 --> 00:45:50,720
If one agent consistently results password resets in eight minutes

1164
00:45:50,720 --> 00:45:52,240
while another takes 18,

1165
00:45:52,240 --> 00:45:55,680
the dispatcher roots more of those specific tasks to the faster agent.

1166
00:45:55,680 --> 00:45:59,360
This isn't a permanent change because agents improve or decline over time,

1167
00:45:59,360 --> 00:46:02,960
so the system adjusts dynamically based on current capability.

1168
00:46:02,960 --> 00:46:05,760
To make this work, your infrastructure has to be cloud native.

1169
00:46:05,760 --> 00:46:08,480
You aren't running fixed agents on fixed servers anymore.

1170
00:46:08,480 --> 00:46:11,520
Instead, you are spinning up agents as the load increases

1171
00:46:11,520 --> 00:46:13,600
and tearing them down when things get quiet.

1172
00:46:13,600 --> 00:46:15,280
This is orchestration at a different level

1173
00:46:15,280 --> 00:46:17,280
where Kubernetes handles the container life cycle

1174
00:46:17,280 --> 00:46:20,080
while the dispatcher manages the actual flow of work.

1175
00:46:20,080 --> 00:46:22,080
The monitoring layer watches both the hardware

1176
00:46:22,080 --> 00:46:24,960
and the agents themselves to ensure everything stays healthy.

1177
00:46:24,960 --> 00:46:27,520
Monitoring is the most critical piece of this puzzle.

1178
00:46:27,520 --> 00:46:30,960
A central dashboard shows you exactly how many tickets are in the queue,

1179
00:46:30,960 --> 00:46:34,240
how many are being worked on, and how many were resolved in the last hour.

1180
00:46:34,240 --> 00:46:36,720
It tracks agent health and availability constantly.

1181
00:46:36,720 --> 00:46:38,720
If an agent starts crashing repeatedly,

1182
00:46:38,720 --> 00:46:42,480
the system pulls it from the pool and flags the issue for the operations team.

1183
00:46:42,480 --> 00:46:44,240
It also reveals escalation patterns.

1184
00:46:44,240 --> 00:46:47,760
If a certain type of ticket is being kicked back to humans more than expected,

1185
00:46:47,760 --> 00:46:50,880
it tells you that something is wrong with the training or the classification.

1186
00:46:50,880 --> 00:46:53,840
The data shows you whether the problem is outside the agent's scope

1187
00:46:53,840 --> 00:46:55,600
or if it just needs better documentation.

1188
00:46:55,600 --> 00:46:58,080
This is where feedback loops finally start to matter.

1189
00:46:58,080 --> 00:46:59,440
Every ticket and agent resolves

1190
00:46:59,440 --> 00:47:02,800
in every decision it makes becomes part of a massive pool of training data.

1191
00:47:02,800 --> 00:47:04,320
Your system is actually learning.

1192
00:47:04,320 --> 00:47:07,360
Some organizations feed this data directly back into the model

1193
00:47:07,360 --> 00:47:09,600
while others use it for periodic retraining,

1194
00:47:09,600 --> 00:47:11,040
but the result is the same.

1195
00:47:11,040 --> 00:47:14,000
The agent that used to take eight minutes per ticket gets faster

1196
00:47:14,000 --> 00:47:16,240
and the escalation rate on difficult issues drops

1197
00:47:16,240 --> 00:47:18,560
as the agent learns from human corrections.

1198
00:47:18,560 --> 00:47:21,840
Load balancing also gives you the power to handle massive traffic spikes.

1199
00:47:21,840 --> 00:47:24,160
On a typical Monday morning, you might get a wave of tickets

1200
00:47:24,160 --> 00:47:26,160
because everyone had issues over the weekend,

1201
00:47:26,160 --> 00:47:28,640
but you can just spin up more agents to clear the queue.

1202
00:47:28,640 --> 00:47:30,560
By Wednesday evening, when things slow down,

1203
00:47:30,560 --> 00:47:33,200
you scale back and stop paying for compute you don't need.

1204
00:47:33,200 --> 00:47:35,920
Parallel execution changes your throughput completely

1205
00:47:35,920 --> 00:47:38,240
and if you had one script running one ticket at a time,

1206
00:47:38,240 --> 00:47:39,760
you would be limited by the clock

1207
00:47:39,760 --> 00:47:42,400
and a hundred tickets would take hours to finish

1208
00:47:42,400 --> 00:47:44,240
with a fleet running in parallel

1209
00:47:44,240 --> 00:47:46,720
though same hundred tickets might be done in 30 minutes.

1210
00:47:46,720 --> 00:47:49,920
The time it takes to resolve an individual ticket doesn't change much

1211
00:47:49,920 --> 00:47:51,680
but your total capacity multiplies.

1212
00:47:51,680 --> 00:47:54,800
This is the shift from running a script to running an operation.

1213
00:47:54,800 --> 00:47:57,040
You aren't just launching a PowerShell command anymore.

1214
00:47:57,040 --> 00:48:00,800
You are operating a complex system of agents, orchestration and governance.

1215
00:48:00,800 --> 00:48:02,320
The agents are just the workers,

1216
00:48:02,320 --> 00:48:05,520
while everything else is the machinery that makes them reliable at scale.

1217
00:48:05,520 --> 00:48:07,520
This requires a real infrastructure shift.

1218
00:48:07,520 --> 00:48:09,360
You need a message queue for work distribution

1219
00:48:09,360 --> 00:48:11,760
and deep observability through logging and metrics.

1220
00:48:11,760 --> 00:48:14,080
You also need policy engines to enforce rules

1221
00:48:14,080 --> 00:48:16,640
and human approval workflows to keep things safe.

1222
00:48:16,640 --> 00:48:19,840
Most importantly, you need an audit trail for every single action.

1223
00:48:19,840 --> 00:48:22,480
It also forces you to change how you think about governance.

1224
00:48:22,480 --> 00:48:24,560
You have to decide who approves what,

1225
00:48:24,560 --> 00:48:28,080
how the escalation path works and what happens if an agent makes a mistake

1226
00:48:28,080 --> 00:48:28,880
or gets attacked.

1227
00:48:28,880 --> 00:48:31,520
These are operational questions, not development ones.

1228
00:48:31,520 --> 00:48:35,040
Moving from a pilot to full production isn't about writing better code.

1229
00:48:35,040 --> 00:48:37,840
It's about building the system that the agents live inside.

1230
00:48:37,840 --> 00:48:40,560
Governance and guardrails.

1231
00:48:40,560 --> 00:48:43,680
Autonomous agents running at scale need boundaries that are clear,

1232
00:48:43,680 --> 00:48:45,120
enforced and unchangeable.

1233
00:48:45,120 --> 00:48:47,760
Without these limits, you are just giving away access

1234
00:48:47,760 --> 00:48:49,040
and hoping for the best.

1235
00:48:49,040 --> 00:48:52,320
The governance layer is what turns an agent from a wildcard

1236
00:48:52,320 --> 00:48:54,240
into a predictable reliable system.

1237
00:48:54,560 --> 00:48:57,280
Think about the level of access you are actually granting here.

1238
00:48:57,280 --> 00:48:59,680
You have agents that can query sensitive user data,

1239
00:48:59,680 --> 00:49:01,920
reset passwords, modify permissions,

1240
00:49:01,920 --> 00:49:04,640
and even send emails on behalf of the entire company.

1241
00:49:04,640 --> 00:49:06,480
Any one of those powers is a massive risk

1242
00:49:06,480 --> 00:49:08,080
if it's used in the wrong context.

1243
00:49:08,080 --> 00:49:10,800
Putting all of them together in an agent without guardrails

1244
00:49:10,800 --> 00:49:12,960
is a guaranteed way to end up explaining

1245
00:49:12,960 --> 00:49:15,120
a massive security breach to your board.

1246
00:49:15,120 --> 00:49:17,840
The policy layer is what defines these guardrails.

1247
00:49:17,840 --> 00:49:21,120
It is a declarative model that states exactly what an agent can do,

1248
00:49:21,120 --> 00:49:24,080
which data it can touch and under what specific conditions it can act.

1249
00:49:24,320 --> 00:49:27,920
This isn't buried in a block of code or a forgotten configuration file.

1250
00:49:27,920 --> 00:49:30,320
It is a living document that the governance team controls

1251
00:49:30,320 --> 00:49:31,920
and auditors can review at any time

1252
00:49:31,920 --> 00:49:33,520
without needing to redeploy the agents.

1253
00:49:33,520 --> 00:49:35,360
In practice, this looks very specific.

1254
00:49:35,360 --> 00:49:37,120
You might define a policy that says

1255
00:49:37,120 --> 00:49:40,720
a password reset agent can only help users in the HR department

1256
00:49:40,720 --> 00:49:42,880
if it gets approval from an HR manager first.

1257
00:49:42,880 --> 00:49:44,880
You can even add a rule that it only works

1258
00:49:44,880 --> 00:49:48,160
if the user hasn't asked for a reset in the last 30 days.

1259
00:49:48,160 --> 00:49:50,160
Because the rules are measurable and specific,

1260
00:49:50,160 --> 00:49:52,720
the agent checks them every single time it tries to act.

1261
00:49:52,720 --> 00:49:54,720
If the conditions aren't met, the agent stops

1262
00:49:54,720 --> 00:49:57,440
and either refuses the request or escalates it to a human.

1263
00:49:57,440 --> 00:49:59,360
Policies can be incredibly granular.

1264
00:49:59,360 --> 00:50:02,000
You don't just say an agent can read all user data,

1265
00:50:02,000 --> 00:50:04,480
you say it can read six specific fields for users

1266
00:50:04,480 --> 00:50:06,480
in the sales department during business hours.

1267
00:50:06,480 --> 00:50:09,440
The access is scoped to exactly what is needed for the task

1268
00:50:09,440 --> 00:50:10,400
and nothing more.

1269
00:50:10,400 --> 00:50:13,120
These policies also determine when a human needs to step in.

1270
00:50:13,120 --> 00:50:16,160
A simple read-only query might not need any oversight,

1271
00:50:16,160 --> 00:50:19,520
but modifying an email address or deleting a device certainly does.

1272
00:50:19,520 --> 00:50:21,440
Your policy layer maps every possible action

1273
00:50:21,440 --> 00:50:22,960
to a specific approval tier.

1274
00:50:22,960 --> 00:50:25,360
This means the agent knows whether it needs a yes

1275
00:50:25,360 --> 00:50:28,080
from a human before it even attempts to perform the action.

1276
00:50:28,080 --> 00:50:30,960
The audit trail is the necessary partner to these policies.

1277
00:50:30,960 --> 00:50:32,880
Every single move an agent makes is logged,

1278
00:50:32,880 --> 00:50:34,400
including what triggered the action,

1279
00:50:34,400 --> 00:50:35,680
which policy allowed it,

1280
00:50:35,680 --> 00:50:37,440
and what the final outcome was.

1281
00:50:37,440 --> 00:50:38,560
If something goes wrong,

1282
00:50:38,560 --> 00:50:40,720
you can rewind the tape to see exactly what happened

1283
00:50:40,720 --> 00:50:41,760
and who approved it.

1284
00:50:41,760 --> 00:50:44,400
This audit trail serves several purposes at once.

1285
00:50:44,400 --> 00:50:46,160
Regulators need to see that you are tracking

1286
00:50:46,160 --> 00:50:47,440
who accessed what and when,

1287
00:50:47,440 --> 00:50:49,360
but it's also vital for troubleshooting.

1288
00:50:49,360 --> 00:50:51,440
If an agent starts behaving strangely,

1289
00:50:51,440 --> 00:50:53,120
you can replay the logs to see exactly

1290
00:50:53,120 --> 00:50:54,880
where its reasoning went off the rails.

1291
00:50:54,880 --> 00:50:57,360
It also provides the feedback you need to improve the system

1292
00:50:57,360 --> 00:50:59,280
by showing you where policies are too tight

1293
00:50:59,280 --> 00:51:01,600
or where agents are making repeated mistakes.

1294
00:51:01,600 --> 00:51:04,320
Compliance requirements are baked directly into this layer.

1295
00:51:04,320 --> 00:51:06,320
If you have rules about data classification,

1296
00:51:06,320 --> 00:51:07,760
the agent has to respect them.

1297
00:51:07,760 --> 00:51:10,800
It won't export confidential files or keep personal data

1298
00:51:10,800 --> 00:51:12,400
longer than the retention window allows.

1299
00:51:12,400 --> 00:51:14,320
The policy isn't just a suggestion.

1300
00:51:14,320 --> 00:51:16,800
It is a hard constraint that the agent cannot break.

1301
00:51:17,680 --> 00:51:19,440
The shift happening here is fundamental

1302
00:51:19,440 --> 00:51:21,440
because you are moving from trusting the script

1303
00:51:21,440 --> 00:51:22,640
to trusting the policy.

1304
00:51:22,640 --> 00:51:23,840
With old school scripts,

1305
00:51:23,840 --> 00:51:25,920
you had to trust that the author wrote secure code,

1306
00:51:25,920 --> 00:51:28,400
which meant you had to audit the code itself before it ran.

1307
00:51:28,400 --> 00:51:30,160
If something broke, the script was the problem.

1308
00:51:30,160 --> 00:51:32,640
With agents, you trust that the policy is correct

1309
00:51:32,640 --> 00:51:34,480
and the enforcement is airtight.

1310
00:51:34,480 --> 00:51:36,320
The agent is just a worker following orders.

1311
00:51:36,320 --> 00:51:38,880
If something goes wrong, it means the policy failed,

1312
00:51:38,880 --> 00:51:40,000
not the agent.

1313
00:51:40,000 --> 00:51:42,000
This also changes how you handle updates.

1314
00:51:42,000 --> 00:51:43,120
With traditional scripts,

1315
00:51:43,120 --> 00:51:45,440
every update is terrifying because a small error

1316
00:51:45,440 --> 00:51:46,720
could break everything.

1317
00:51:46,720 --> 00:51:49,600
With agents, you don't change the code to change the behavior.

1318
00:51:49,600 --> 00:51:51,040
You just update the policy.

1319
00:51:51,040 --> 00:51:53,920
If you want an agent to be more autonomous,

1320
00:51:53,920 --> 00:51:55,520
you adjust the governance layer.

1321
00:51:55,520 --> 00:51:57,520
If you need to restrict it, you do the same.

1322
00:51:57,520 --> 00:51:59,920
The capability of the agent stays the same in the code,

1323
00:51:59,920 --> 00:52:01,840
but its permissions change in the governance.

1324
00:52:01,840 --> 00:52:04,080
Governance is actually what enables you to scale.

1325
00:52:04,080 --> 00:52:06,240
It isn't a hurdle or a constraint.

1326
00:52:06,240 --> 00:52:08,560
It's the foundation that lets you spin up more agents

1327
00:52:08,560 --> 00:52:11,200
with total confidence because the boundaries are clear

1328
00:52:11,200 --> 00:52:12,160
and the audit is complete.

1329
00:52:12,160 --> 00:52:14,240
You don't have to worry about what might go wrong.

1330
00:52:14,240 --> 00:52:16,400
You have a perfect record of everything that happens

1331
00:52:16,400 --> 00:52:18,720
and a system that ensures it stays within the lines.

1332
00:52:18,720 --> 00:52:21,680
Security considerations for autonomous agents.

1333
00:52:21,680 --> 00:52:24,160
The moment you give an agent the power to execute commands,

1334
00:52:24,160 --> 00:52:26,000
you have created a high-value target.

1335
00:52:26,000 --> 00:52:28,640
Unlike a human employee, an agent never gets tired,

1336
00:52:28,640 --> 00:52:31,280
and it won't stop to question a suspicious instruction.

1337
00:52:31,280 --> 00:52:32,960
It simply follows its logic to the end.

1338
00:52:32,960 --> 00:52:35,840
This creates a massive risk if the agent is compromised

1339
00:52:35,840 --> 00:52:38,400
or if someone manages to inject malicious instructions

1340
00:52:38,400 --> 00:52:39,520
into its context.

1341
00:52:39,520 --> 00:52:40,640
You have to ask yourself,

1342
00:52:40,640 --> 00:52:42,560
what is the blast radius if this goes wrong?

1343
00:52:42,560 --> 00:52:44,000
You need a real-world threat model

1344
00:52:44,000 --> 00:52:46,880
based on what actually matters in your specific environment.

1345
00:52:46,880 --> 00:52:49,040
The danger isn't just that an agent might malfunction.

1346
00:52:49,040 --> 00:52:51,680
The real threat is that someone outside your organization

1347
00:52:51,680 --> 00:52:55,120
or even a malicious insider turns that agent into a weapon.

1348
00:52:55,120 --> 00:52:57,200
Isolation is your first line of defense here.

1349
00:52:57,200 --> 00:53:00,480
Agents shouldn't run on the same infrastructure as your critical systems.

1350
00:53:00,480 --> 00:53:02,320
Instead, they need to live in containers,

1351
00:53:02,320 --> 00:53:05,280
Kubernetes pods, or isolated network segments.

1352
00:53:05,280 --> 00:53:06,800
If an agent is compromised,

1353
00:53:06,800 --> 00:53:09,120
that isolation keeps the damage contained.

1354
00:53:09,120 --> 00:53:11,200
It prevents the attacker from immediately pivoting

1355
00:53:11,200 --> 00:53:13,520
to your domain controllers or email servers.

1356
00:53:13,520 --> 00:53:14,720
Think of it as a sandbox.

1357
00:53:14,720 --> 00:53:17,120
This is a major shift from how we usually run scripts.

1358
00:53:17,120 --> 00:53:18,960
A script running on a server with admin rights

1359
00:53:18,960 --> 00:53:20,560
can reach your entire environment,

1360
00:53:20,560 --> 00:53:22,640
but an agent in a properly configured container

1361
00:53:22,640 --> 00:53:25,840
can only see what you explicitly allow through network policies.

1362
00:53:25,840 --> 00:53:27,440
Credential handling has to change as well.

1363
00:53:27,440 --> 00:53:29,360
Traditional scripts usually store credentials

1364
00:53:29,360 --> 00:53:31,360
in an encrypted vault or a config file.

1365
00:53:31,360 --> 00:53:32,880
The script authenticates once,

1366
00:53:32,880 --> 00:53:33,760
gets it token,

1367
00:53:33,760 --> 00:53:36,080
and uses that token for as long as it lives.

1368
00:53:36,080 --> 00:53:37,280
If that credential leaks,

1369
00:53:37,280 --> 00:53:38,960
it stays valid for a long time.

1370
00:53:38,960 --> 00:53:41,280
An agent should never store credentials like that.

1371
00:53:41,280 --> 00:53:43,040
It shouldn't have long-lived tokens at all.

1372
00:53:43,040 --> 00:53:45,040
Every time it needs to perform a task,

1373
00:53:45,040 --> 00:53:47,680
it should request a new credential from an identity broker

1374
00:53:47,680 --> 00:53:49,520
that is only valid for that specific job.

1375
00:53:49,520 --> 00:53:51,280
Because these credentials expire in minutes,

1376
00:53:51,280 --> 00:53:54,400
they are worthless to a thief almost immediately after they are issued.

1377
00:53:54,400 --> 00:53:56,960
This ties back to headless authentication in CAE,

1378
00:53:56,960 --> 00:53:59,040
but the security angle is much more aggressive.

1379
00:53:59,040 --> 00:54:01,040
It isn't just about checking a compliance box.

1380
00:54:01,040 --> 00:54:03,920
It's about ensuring that even if someone dumps the agent's memory

1381
00:54:03,920 --> 00:54:05,120
or reads its logs,

1382
00:54:05,120 --> 00:54:07,600
there are no usable credentials sitting there.

1383
00:54:07,600 --> 00:54:09,600
If that agent starts behaving strangely

1384
00:54:09,600 --> 00:54:12,880
by making unauthorized API calls or accessing data it doesn't need,

1385
00:54:12,880 --> 00:54:15,520
the policy engine can revoke its access instantly.

1386
00:54:15,520 --> 00:54:18,240
Behavioral analytics serves as your early warning system.

1387
00:54:18,240 --> 00:54:21,120
If an agent that usually processes password resets

1388
00:54:21,120 --> 00:54:23,920
suddenly starts scanning every user in the directory,

1389
00:54:23,920 --> 00:54:25,120
that is a major signal.

1390
00:54:25,120 --> 00:54:27,360
If an agent that typically runs during business hours

1391
00:54:27,360 --> 00:54:28,880
suddenly wakes up at 3am,

1392
00:54:28,880 --> 00:54:31,360
or if it jumps from 10 API calls to 1,000,

1393
00:54:31,360 --> 00:54:33,120
your monitoring system needs to flag it.

1394
00:54:33,120 --> 00:54:34,960
This is actually easier than traditional monitoring

1395
00:54:34,960 --> 00:54:37,600
because agent behavior is incredibly predictable.

1396
00:54:37,600 --> 00:54:39,680
You know exactly which commands it should run,

1397
00:54:39,680 --> 00:54:40,640
what data it needs,

1398
00:54:40,640 --> 00:54:42,400
and how long the process should take.

1399
00:54:42,400 --> 00:54:44,640
Any deviation from that baseline is a red flag

1400
00:54:44,640 --> 00:54:46,480
that likely indicates an attack.

1401
00:54:46,480 --> 00:54:48,080
While a script has broad boundaries

1402
00:54:48,080 --> 00:54:50,240
because humans might run it in different ways,

1403
00:54:50,240 --> 00:54:52,240
a production agent has a very narrow path.

1404
00:54:52,240 --> 00:54:53,440
Anything outside that path

1405
00:54:53,440 --> 00:54:55,200
deserves an immediate investigation.

1406
00:54:55,200 --> 00:54:56,560
The principle of least privilege

1407
00:54:56,560 --> 00:54:58,400
becomes much tighter with agents.

1408
00:54:58,400 --> 00:55:00,080
A human might need broad permissions

1409
00:55:00,080 --> 00:55:02,000
because their job requires flexibility

1410
00:55:02,000 --> 00:55:03,520
across different domains.

1411
00:55:03,520 --> 00:55:06,000
An agent only needs exactly what is required

1412
00:55:06,000 --> 00:55:07,600
for its one specific function.

1413
00:55:07,600 --> 00:55:11,120
A password reset agent has no business reading email servers

1414
00:55:11,120 --> 00:55:14,400
and a device provisioning agent doesn't need to see financial data.

1415
00:55:14,400 --> 00:55:16,000
You enforce this at the API level

1416
00:55:16,000 --> 00:55:17,680
so the agent can call a function,

1417
00:55:17,680 --> 00:55:20,880
but the function itself is restricted to specific objects.

1418
00:55:20,880 --> 00:55:24,000
This represents a profound shift in how we think about security.

1419
00:55:24,000 --> 00:55:26,240
With scripts, you focus on securing the code

1420
00:55:26,240 --> 00:55:28,720
by scanning for vulnerabilities and auditing changes.

1421
00:55:28,720 --> 00:55:30,320
It's a code security problem.

1422
00:55:30,320 --> 00:55:33,520
With agents, you are securing the identity and the context.

1423
00:55:33,520 --> 00:55:35,120
The code is actually secondary.

1424
00:55:35,120 --> 00:55:37,680
The real question is what this agent is authorized to do

1425
00:55:37,680 --> 00:55:39,520
right now in this exact moment

1426
00:55:39,520 --> 00:55:40,880
with this specific identity.

1427
00:55:40,880 --> 00:55:42,640
If that answer is tightly scoped

1428
00:55:42,640 --> 00:55:44,320
and constantly re-evaluated,

1429
00:55:44,320 --> 00:55:47,120
the agent stays secure even if the code has flaws.

1430
00:55:47,120 --> 00:55:50,480
Security architecture is moving away from the traditional perimeter.

1431
00:55:50,480 --> 00:55:52,320
We are moving toward a zero-trust model

1432
00:55:52,320 --> 00:55:54,960
where every single agent action is evaluated,

1433
00:55:54,960 --> 00:55:56,720
every identity is verified

1434
00:55:56,720 --> 00:55:58,480
and every behavior is monitored.

1435
00:55:58,480 --> 00:56:00,320
The agent doesn't get a free pass

1436
00:56:00,320 --> 00:56:01,760
just because it's software.

1437
00:56:01,760 --> 00:56:03,840
In fact, you should treat it with less trust

1438
00:56:03,840 --> 00:56:06,480
than a human user because it operates autonomously.

1439
00:56:06,480 --> 00:56:08,960
Your security team will find their roles changing too.

1440
00:56:08,960 --> 00:56:10,960
They won't just be auditing lines of code anymore.

1441
00:56:10,960 --> 00:56:12,960
Instead, they will be defining policies,

1442
00:56:12,960 --> 00:56:14,560
reviewing behavioral baselines

1443
00:56:14,560 --> 00:56:16,240
and managing the identity life cycle

1444
00:56:16,240 --> 00:56:18,240
for an entire fleet of agents.

1445
00:56:18,240 --> 00:56:19,760
They have to think about attack surfaces

1446
00:56:19,760 --> 00:56:21,760
that simply didn't exist a few years ago

1447
00:56:21,760 --> 00:56:23,920
which requires a completely different skill set,

1448
00:56:23,920 --> 00:56:25,440
measuring agent performance.

1449
00:56:25,440 --> 00:56:27,040
When you move from scripts to agents,

1450
00:56:27,040 --> 00:56:29,360
your measurement system has to change completely.

1451
00:56:29,360 --> 00:56:30,640
You can't rely on the old metrics

1452
00:56:30,640 --> 00:56:33,200
because you aren't evaluating the same type of work anymore.

1453
00:56:33,200 --> 00:56:35,600
With scripts, success was a binary outcome.

1454
00:56:35,600 --> 00:56:36,880
You check to see if it ran,

1455
00:56:36,880 --> 00:56:38,880
if it crashed or if the logs showed any errors.

1456
00:56:38,880 --> 00:56:40,240
These are mechanical measurements.

1457
00:56:40,240 --> 00:56:42,480
The script either finished its sequence or it didn't.

1458
00:56:42,480 --> 00:56:45,440
You measured things like runtime and error frequency.

1459
00:56:45,440 --> 00:56:47,440
And if the script finished without a crash,

1460
00:56:47,440 --> 00:56:48,880
you just assumed it worked.

1461
00:56:48,880 --> 00:56:50,080
The logic was hidden inside

1462
00:56:50,080 --> 00:56:52,240
so you couldn't see why it made certain decisions.

1463
00:56:52,240 --> 00:56:53,520
Agents are a different story.

1464
00:56:53,520 --> 00:56:54,720
A script might run perfectly

1465
00:56:54,720 --> 00:56:56,880
but still fail to solve the actual problem.

1466
00:56:56,880 --> 00:56:58,560
On the other hand, an agent that stops

1467
00:56:58,560 --> 00:57:00,320
and escalates a ticket to a human

1468
00:57:00,320 --> 00:57:02,640
might actually be making the smartest possible move.

1469
00:57:02,640 --> 00:57:04,960
Success isn't about the agent running smoothly.

1470
00:57:04,960 --> 00:57:07,280
It's about the agent achieving the final goal.

1471
00:57:07,280 --> 00:57:09,280
You should start by looking at your automation rate.

1472
00:57:09,280 --> 00:57:10,640
This is the percentage of tasks

1473
00:57:10,640 --> 00:57:12,160
that are fully resolved by the agent

1474
00:57:12,160 --> 00:57:13,680
without any human stepping in.

1475
00:57:13,680 --> 00:57:15,360
If you handle a thousand tickets a month

1476
00:57:15,360 --> 00:57:17,360
and your agents resolve 400 of them,

1477
00:57:17,360 --> 00:57:18,960
your automation rate is 40%.

1478
00:57:18,960 --> 00:57:20,080
This is your headline metric

1479
00:57:20,080 --> 00:57:22,080
because it shows exactly how much work the agents

1480
00:57:22,080 --> 00:57:23,120
are taking off your plate.

1481
00:57:23,120 --> 00:57:24,720
You should expect this number to climb

1482
00:57:24,720 --> 00:57:26,160
as you refine the agents

1483
00:57:26,160 --> 00:57:28,080
though it will never hit 100%.

1484
00:57:28,080 --> 00:57:30,400
Some problems will always be outside the agent's scope

1485
00:57:30,400 --> 00:57:31,520
but the trend will tell you

1486
00:57:31,520 --> 00:57:33,120
if you're moving in the right direction.

1487
00:57:33,120 --> 00:57:35,600
The escalation rate is the other side of that coin.

1488
00:57:35,600 --> 00:57:37,360
When an agent can't finish a task,

1489
00:57:37,360 --> 00:57:39,440
you need to know how often it escalates

1490
00:57:39,440 --> 00:57:41,440
versus how often it just fails.

1491
00:57:41,440 --> 00:57:43,920
A well-designed agent will escalate more than it fails.

1492
00:57:43,920 --> 00:57:45,760
Escalation means the agent tried,

1493
00:57:45,760 --> 00:57:46,960
realized it couldn't finish

1494
00:57:46,960 --> 00:57:48,560
and handed the ticket to a human

1495
00:57:48,560 --> 00:57:50,240
with all the necessary context.

1496
00:57:50,240 --> 00:57:51,760
Failure means it just crashed

1497
00:57:51,760 --> 00:57:54,160
or threw an error with no way forward.

1498
00:57:54,160 --> 00:57:55,680
You want to see low failure rates

1499
00:57:55,680 --> 00:57:57,120
and high escalation rates.

1500
00:57:57,120 --> 00:57:59,440
An agent that hands over a complete diagnostic report

1501
00:57:59,440 --> 00:58:01,120
to a human is much more valuable

1502
00:58:01,120 --> 00:58:02,560
than one that fails silently.

1503
00:58:02,560 --> 00:58:04,320
Approval time is another critical factor

1504
00:58:04,320 --> 00:58:06,160
because humans are often the bottleneck.

1505
00:58:06,160 --> 00:58:07,600
When an agent suggests a fix

1506
00:58:07,600 --> 00:58:09,520
that needs a sign off, how long does that take?

1507
00:58:09,520 --> 00:58:10,560
If your agents are fast,

1508
00:58:10,560 --> 00:58:12,800
but your humans take two days to review the work,

1509
00:58:12,800 --> 00:58:14,560
you've just traded one bottleneck for another.

1510
00:58:14,560 --> 00:58:15,760
You want these approvals happening

1511
00:58:15,760 --> 00:58:17,200
in minutes rather than hours.

1512
00:58:17,200 --> 00:58:19,760
This metric tells you if your workflow is actually efficient

1513
00:58:19,760 --> 00:58:21,520
or if it needs to be redesigned.

1514
00:58:21,520 --> 00:58:23,200
Quality metrics are harder to track,

1515
00:58:23,200 --> 00:58:24,480
but they are essential.

1516
00:58:24,480 --> 00:58:26,800
Accuracy asks if the agent did the right thing,

1517
00:58:26,800 --> 00:58:28,400
diagnose the problem correctly

1518
00:58:28,400 --> 00:58:29,920
and apply the proper fix.

1519
00:58:29,920 --> 00:58:32,240
You measure this by having a human expert sample agent

1520
00:58:32,240 --> 00:58:34,160
decisions to verify they were correct.

1521
00:58:34,160 --> 00:58:36,640
Over time, this builds a reliable quality score.

1522
00:58:36,640 --> 00:58:38,240
You also need to measure completeness.

1523
00:58:38,240 --> 00:58:39,840
Did the agent solve the whole problem?

1524
00:58:39,840 --> 00:58:43,040
Or did it stop after fixing just one part of a multi-step issue?

1525
00:58:43,040 --> 00:58:44,240
Then you have the business metrics.

1526
00:58:44,240 --> 00:58:47,040
Cost per resolution is the total cost of your compute power

1527
00:58:47,040 --> 00:58:48,320
and human approval time

1528
00:58:48,320 --> 00:58:50,240
divided by the number of tickets resolved.

1529
00:58:50,240 --> 00:58:53,280
This tells you if automation is actually saving you money.

1530
00:58:53,280 --> 00:58:55,440
If your agents end up costing more than your human staff,

1531
00:58:55,440 --> 00:58:56,960
your model is likely broken.

1532
00:58:56,960 --> 00:59:00,480
You also want to track the mean time to resolution or MTTR.

1533
00:59:00,480 --> 00:59:02,880
When agents are involved, the time from ticket submission

1534
00:59:02,880 --> 00:59:05,040
to closure should drop significantly.

1535
00:59:05,040 --> 00:59:07,520
Finally, check user satisfaction to see if people are actually

1536
00:59:07,520 --> 00:59:09,520
happier with the faster response times.

1537
00:59:09,520 --> 00:59:11,120
The shift here is moving from,

1538
00:59:11,120 --> 00:59:12,560
did the system work?

1539
00:59:12,560 --> 00:59:15,040
To, did the system solve the problem?

1540
00:59:15,040 --> 00:59:16,720
Scripts let you measure execution,

1541
00:59:16,720 --> 00:59:18,800
but agents require you to measure helpfulness.

1542
00:59:18,800 --> 00:59:20,320
This also changes your feedback loop.

1543
00:59:20,320 --> 00:59:23,280
With scripts, you look at logs to find bugs in the code.

1544
00:59:23,280 --> 00:59:25,200
With agents, you look at quality metrics

1545
00:59:25,200 --> 00:59:27,360
to see where the decision making went wrong

1546
00:59:27,360 --> 00:59:30,160
so you can retrain the model or update your policies.

1547
00:59:30,160 --> 00:59:31,920
You aren't just debugging code anymore.

1548
00:59:31,920 --> 00:59:34,080
You are improving the way the system thinks.

1549
00:59:34,080 --> 00:59:37,360
New observability practices are starting to emerge around this.

1550
00:59:37,360 --> 00:59:39,520
You need real-time dashboards that show these trends

1551
00:59:39,520 --> 00:59:42,800
and historical data to see if your improvements are actually sticking.

1552
00:59:42,800 --> 00:59:44,480
You need to break things down by category

1553
00:59:44,480 --> 00:59:46,640
so you can see if your agents are great at one task

1554
00:59:46,640 --> 00:59:47,760
but struggling with another.

1555
00:59:47,760 --> 00:59:49,280
You also need drill-down views

1556
00:59:49,280 --> 00:59:51,200
that let you inspect a specific ticket

1557
00:59:51,200 --> 00:59:52,960
to see exactly what the agent decided

1558
00:59:52,960 --> 00:59:54,640
and why it made that choice.

1559
00:59:54,640 --> 00:59:56,560
Measurement becomes a constant conversation

1560
00:59:56,560 --> 00:59:58,480
between you and your agent fleet.

1561
00:59:58,480 --> 01:00:01,120
The metrics will show you exactly where to focus your energy next.

1562
01:00:01,120 --> 01:00:03,440
If your automation rate is stuck at 30%,

1563
01:00:03,440 --> 01:00:06,400
you need to look at the 70% that is still escalating.

1564
01:00:06,400 --> 01:00:07,920
If your approval time is creeping up,

1565
01:00:07,920 --> 01:00:09,840
your process is becoming a bottleneck.

1566
01:00:09,840 --> 01:00:11,920
If the cost per resolution is climbing,

1567
01:00:11,920 --> 01:00:13,600
your agent might be over-engineered

1568
01:00:13,600 --> 01:00:15,520
or your infrastructure might be inefficient.

1569
01:00:15,520 --> 01:00:18,080
Without these specific metrics, you are flying blind.

1570
01:00:18,080 --> 01:00:20,880
You won't know if your agents are actually making things better

1571
01:00:20,880 --> 01:00:24,160
or if you're just enjoying the feeling of having things automated.

1572
01:00:24,160 --> 01:00:27,360
The roadmap to operationalization.

1573
01:00:27,360 --> 01:00:30,640
Moving an agent from a lab experiment to a production workhorse

1574
01:00:30,640 --> 01:00:32,160
requires a specific path.

1575
01:00:32,160 --> 01:00:34,080
The technology isn't actually the hard part

1576
01:00:34,080 --> 01:00:36,640
because you have already built the core logic.

1577
01:00:36,640 --> 01:00:39,040
The real challenge is shifting how your team works,

1578
01:00:39,040 --> 01:00:41,520
what they monitor, and how they build trust in the system.

1579
01:00:41,520 --> 01:00:44,080
You have to follow a roadmap with distinct phases

1580
01:00:44,080 --> 01:00:46,320
and if you try to skip them, it will cost you.

1581
01:00:46,320 --> 01:00:47,360
Phase one is the pilot.

1582
01:00:47,360 --> 01:00:50,240
You pick one narrow domain and one specific capability

1583
01:00:50,240 --> 01:00:52,480
like password resets and that is it.

1584
01:00:52,480 --> 01:00:54,640
You build a single agent that does one thing.

1585
01:00:54,640 --> 01:00:58,160
It only runs queries with read-only access to Azure AD and Intune

1586
01:00:58,160 --> 01:01:00,240
so there are no rights and no approvals yet.

1587
01:01:00,240 --> 01:01:02,800
When a user submits a ticket saying their password expired,

1588
01:01:02,800 --> 01:01:05,680
the agent reads the account status, confirms they exist,

1589
01:01:05,680 --> 01:01:07,360
and checks that they aren't locked out.

1590
01:01:07,360 --> 01:01:09,920
It resets the password and notifies the user

1591
01:01:09,920 --> 01:01:11,360
before closing the ticket.

1592
01:01:11,360 --> 01:01:13,840
This phase proves the fundamental concept

1593
01:01:13,840 --> 01:01:16,240
that an agent can interpret natural language

1594
01:01:16,240 --> 01:01:19,360
and execute a sequence of actions to solve a real problem.

1595
01:01:19,360 --> 01:01:22,400
You aren't doing anything fancy or using complex reasoning yet

1596
01:01:22,400 --> 01:01:24,960
but you are showing the team that the idea works

1597
01:01:24,960 --> 01:01:26,480
so they can gain confidence.

1598
01:01:26,480 --> 01:01:28,560
This pilot usually runs for four to eight weeks

1599
01:01:28,560 --> 01:01:30,960
while you measure success rates in error patterns.

1600
01:01:30,960 --> 01:01:33,200
This is where you discover the operational infrastructure

1601
01:01:33,200 --> 01:01:35,440
you are missing, like better logging or a plan

1602
01:01:35,440 --> 01:01:37,120
for updating agent behavior.

1603
01:01:37,120 --> 01:01:38,640
You might realize that approval workflows

1604
01:01:38,640 --> 01:01:39,920
are much harder than you thought

1605
01:01:39,920 --> 01:01:42,720
but these discoveries are exactly why you run a pilot.

1606
01:01:42,720 --> 01:01:45,760
You are learning what it takes to run the system at a low scale

1607
01:01:45,760 --> 01:01:48,000
where mistakes don't cause a massive collapse.

1608
01:01:48,000 --> 01:01:49,360
Phase two is expansion.

1609
01:01:49,360 --> 01:01:51,680
You add a second domain, perhaps access requests

1610
01:01:51,680 --> 01:01:54,480
or device provisioning, which means you now have two agents

1611
01:01:54,480 --> 01:01:55,600
running in parallel.

1612
01:01:55,600 --> 01:01:57,440
This is where scaling starts to matter

1613
01:01:57,440 --> 01:02:00,800
because you are adding complexity instead of just doing more of the same.

1614
01:02:00,800 --> 01:02:04,080
The orchestration layer now has to root tickets to the right agent

1615
01:02:04,080 --> 01:02:07,680
and your monitoring must track which agent handled which specific task.

1616
01:02:07,680 --> 01:02:10,320
You can start introducing low risk right operations here.

1617
01:02:10,320 --> 01:02:12,720
The access request agent might assign a user to a group

1618
01:02:12,720 --> 01:02:13,920
if the request is valid

1619
01:02:13,920 --> 01:02:17,600
but you still avoid high risk changes like deletions or MFA resets.

1620
01:02:17,600 --> 01:02:19,440
You only allow straightforward modifications

1621
01:02:19,440 --> 01:02:21,840
that you can easily undo if something goes wrong.

1622
01:02:21,840 --> 01:02:23,760
You also start introducing approval workflows

1623
01:02:23,760 --> 01:02:26,960
for medium risk decisions during this six to ten week period.

1624
01:02:26,960 --> 01:02:29,360
You are proving that multiple agents can coexist

1625
01:02:29,360 --> 01:02:32,480
and that the routing works without the approval system becoming a bottleneck.

1626
01:02:32,480 --> 01:02:33,920
This is when you start seeing patterns

1627
01:02:33,920 --> 01:02:36,320
in what the agents get right and where they struggle

1628
01:02:36,320 --> 01:02:40,160
and that feedback becomes the fuel for your retraining and policy adjustments.

1629
01:02:40,160 --> 01:02:41,600
Phase three is scale.

1630
01:02:41,600 --> 01:02:42,640
You have a fleet now

1631
01:02:42,640 --> 01:02:44,880
with five or six agents handling different domains

1632
01:02:44,880 --> 01:02:46,320
from a shared ticket queue.

1633
01:02:46,320 --> 01:02:48,880
The orchestrator distributes work based on capability

1634
01:02:48,880 --> 01:02:50,000
and availability.

1635
01:02:50,000 --> 01:02:52,160
And while high risk operations are finally in the mix

1636
01:02:52,160 --> 01:02:54,080
they all have strict approval gates.

1637
01:02:54,080 --> 01:02:57,440
This phase is about proving the system can handle real production volume.

1638
01:02:57,440 --> 01:02:59,920
You aren't testing 100 tickets a week anymore

1639
01:02:59,920 --> 01:03:02,240
but instead you are running hundreds every single day.

1640
01:03:02,240 --> 01:03:04,400
This is where your infrastructure scaling happens

1641
01:03:04,400 --> 01:03:07,600
and you find out if your Kubernetes setup can actually handle the load.

1642
01:03:07,600 --> 01:03:09,600
You will see which types of tickets the agents nail

1643
01:03:09,600 --> 01:03:11,440
and which ones cause them to stumble.

1644
01:03:11,440 --> 01:03:13,520
This phase typically runs for three or four months

1645
01:03:13,520 --> 01:03:14,960
as you ramp up the volume

1646
01:03:14,960 --> 01:03:16,960
and the business impact becomes visible.

1647
01:03:16,960 --> 01:03:19,760
Tickets that used to take two hours now take 15 minutes

1648
01:03:19,760 --> 01:03:21,200
which clears your backlog

1649
01:03:21,200 --> 01:03:23,440
and frees your IT staff from routine drudgery.

1650
01:03:23,440 --> 01:03:25,920
This is the moment you get the organizational buy-in

1651
01:03:25,920 --> 01:03:27,680
needed for the final stage.

1652
01:03:27,680 --> 01:03:29,280
Phase four is optimization.

1653
01:03:29,280 --> 01:03:30,880
Your agents are production grade

1654
01:03:30,880 --> 01:03:32,800
so now you focus on making them better.

1655
01:03:32,800 --> 01:03:34,640
You feed resolution data back into the model

1656
01:03:34,640 --> 01:03:36,880
so the agents can learn from human corrections.

1657
01:03:36,880 --> 01:03:38,960
You adjust policies based on the patterns you see

1658
01:03:38,960 --> 01:03:39,920
and optimize routing

1659
01:03:39,920 --> 01:03:42,320
so the right agent gets the right ticket more often.

1660
01:03:42,320 --> 01:03:44,160
You reduce approval times by refining

1661
01:03:44,160 --> 01:03:45,760
what actually needs human judgment

1662
01:03:45,760 --> 01:03:48,080
versus what the agent can decide on its own.

1663
01:03:48,080 --> 01:03:50,800
This phase is continuous because it isn't a checkpoint

1664
01:03:50,800 --> 01:03:52,640
but an ongoing operational mode.

1665
01:03:52,640 --> 01:03:55,280
You are constantly measuring ROI and tuning performance

1666
01:03:55,280 --> 01:03:57,600
while adding new domains as opportunities appear.

1667
01:03:57,600 --> 01:03:59,600
The entire journey from pilot to production

1668
01:03:59,600 --> 01:04:01,440
usually takes six to 12 months.

1669
01:04:01,440 --> 01:04:03,120
It isn't because the technology is slow

1670
01:04:03,120 --> 01:04:06,160
but because operationalization requires a high level of discipline.

1671
01:04:06,160 --> 01:04:09,360
You cannot skip phases or try to pilot everything at once.

1672
01:04:09,360 --> 01:04:11,760
You have to prove at each stage that the system works

1673
01:04:11,760 --> 01:04:13,280
that your team knows how to run it

1674
01:04:13,280 --> 01:04:16,080
and that the business impact justifies the next step.

1675
01:04:16,080 --> 01:04:18,400
The mindset shift moves from can we build this

1676
01:04:18,400 --> 01:04:20,160
and to how do we run this?

1677
01:04:20,160 --> 01:04:21,760
And that is where the real work happens.

1678
01:04:21,760 --> 01:04:23,280
The technology is the easy part.

1679
01:04:23,280 --> 01:04:26,240
What changes when agents are autonomous?

1680
01:04:26,240 --> 01:04:28,480
Everything changes the moment your agents start running

1681
01:04:28,480 --> 01:04:29,760
without permission gates.

1682
01:04:29,760 --> 01:04:32,640
Your operations transform not because the technology is different

1683
01:04:32,640 --> 01:04:34,320
but because the work distribution

1684
01:04:34,320 --> 01:04:37,280
and the organizational structure have to reorganize.

1685
01:04:37,280 --> 01:04:39,040
Think about your operational tempo.

1686
01:04:39,040 --> 01:04:40,720
Right now your IT team is reactive

1687
01:04:40,720 --> 01:04:43,040
because a problem happens, a user calls

1688
01:04:43,040 --> 01:04:45,120
and then someone diagnoses and fixes it.

1689
01:04:45,120 --> 01:04:47,040
This is a respond to crisis model

1690
01:04:47,040 --> 01:04:50,720
but with autonomous agents at scale, the game completely inverts.

1691
01:04:50,720 --> 01:04:53,520
Agents can detect that a device is drifting out of compliance

1692
01:04:53,520 --> 01:04:55,520
before the user even notices a problem.

1693
01:04:55,520 --> 01:04:58,240
They see patterns of failed logins from a specific location

1694
01:04:58,240 --> 01:04:59,840
and flag them for security

1695
01:04:59,840 --> 01:05:02,240
or they notice outdated applications across departments

1696
01:05:02,240 --> 01:05:04,080
and proactively push updates.

1697
01:05:04,080 --> 01:05:06,320
They watch your tenant health metrics constantly

1698
01:05:06,320 --> 01:05:08,560
and predict when you are going to hit a service limit.

1699
01:05:08,560 --> 01:05:11,520
This shift from reactive to proactive is preventive meaning

1700
01:05:11,520 --> 01:05:14,000
problems get solved before they ever become outages.

1701
01:05:14,000 --> 01:05:16,560
This changes the types of fires that end up on your desk.

1702
01:05:16,560 --> 01:05:18,960
Instead of spending your day fighting active incidents

1703
01:05:18,960 --> 01:05:21,040
you spend it reviewing what the agents prevented.

1704
01:05:21,040 --> 01:05:23,600
Your monitoring doesn't show you crisis dashboards anymore

1705
01:05:23,600 --> 01:05:25,120
but instead shows you early warnings

1706
01:05:25,120 --> 01:05:26,960
and the agents proposed fixes.

1707
01:05:26,960 --> 01:05:29,520
Instead of getting paged at midnight because something broke

1708
01:05:29,520 --> 01:05:31,360
you get an alert that something is about to break

1709
01:05:31,360 --> 01:05:34,080
and the agent is asking for approval to fix it ahead of time.

1710
01:05:34,080 --> 01:05:37,120
The organizational structure has to follow this shift right now.

1711
01:05:37,120 --> 01:05:38,880
You have a lot of people doing level one work

1712
01:05:38,880 --> 01:05:40,080
like ticket triage,

1713
01:05:40,080 --> 01:05:42,240
password resets and access requests.

1714
01:05:42,240 --> 01:05:45,280
These roles exist because you need human judgment to decide

1715
01:05:45,280 --> 01:05:48,080
where a ticket goes and what the best path forward is.

1716
01:05:48,080 --> 01:05:50,960
Autonomous agents eliminate that entire category of work.

1717
01:05:50,960 --> 01:05:53,840
You don't need as many junior technicians doing routine resolution

1718
01:05:53,840 --> 01:05:56,160
but the people you do have must be more skilled.

1719
01:05:56,160 --> 01:05:58,400
You need architects to design what agents can do

1720
01:05:58,400 --> 01:06:00,800
and policy experts to define the guardrails.

1721
01:06:00,800 --> 01:06:03,040
You need people who can read agent behavior analytics

1722
01:06:03,040 --> 01:06:05,520
to determine if an agent is making good decisions.

1723
01:06:05,520 --> 01:06:07,440
When an agent struggles in a specific domain

1724
01:06:07,440 --> 01:06:09,840
you need someone who can actually debug the workflow.

1725
01:06:09,840 --> 01:06:12,000
The skills conversation changes entirely.

1726
01:06:12,000 --> 01:06:14,400
You stop hiring people who are just good at following procedures

1727
01:06:14,400 --> 01:06:18,080
and start hiring people who can design procedures for agents to execute.

1728
01:06:18,080 --> 01:06:20,960
You stop training people on how to reset a password in exchange

1729
01:06:20,960 --> 01:06:23,040
and start training them on how to design an agent

1730
01:06:23,040 --> 01:06:25,680
that understands when a reset is the right answer.

1731
01:06:25,680 --> 01:06:29,440
You are moving from execution focused skills to design focused skills,

1732
01:06:29,440 --> 01:06:32,320
shifting from task specialists to system architects.

1733
01:06:32,320 --> 01:06:33,920
The cost structure inverts as well.

1734
01:06:33,920 --> 01:06:35,600
Right now you are paying salaries

1735
01:06:35,600 --> 01:06:38,000
and labor is your biggest operational expense.

1736
01:06:38,000 --> 01:06:39,680
As you move to autonomous agents

1737
01:06:39,680 --> 01:06:43,600
you are paying for compute, cloud infrastructure and API calls.

1738
01:06:43,600 --> 01:06:46,240
These are capital expenses, not labor expenses

1739
01:06:46,240 --> 01:06:48,880
and that matters because capital scales differently than people.

1740
01:06:48,880 --> 01:06:51,120
You can spin up more agents instantly

1741
01:06:51,120 --> 01:06:54,160
but you cannot hire a dozen good technicians overnight.

1742
01:06:54,160 --> 01:06:56,880
The constraint shifts from how many people you can hire

1743
01:06:56,880 --> 01:06:58,400
to what your cloud budget looks like

1744
01:06:58,400 --> 01:07:00,720
and whether your infrastructure can handle the throughput.

1745
01:07:00,720 --> 01:07:02,880
For some this is a dramatic cost reduction

1746
01:07:02,880 --> 01:07:04,560
while for others it is a cost shift

1747
01:07:04,560 --> 01:07:06,160
where you replace people with infrastructure.

1748
01:07:06,160 --> 01:07:07,520
Either way the economics are different.

1749
01:07:07,520 --> 01:07:10,880
The institutional knowledge problem gets solved and created at the same time.

1750
01:07:10,880 --> 01:07:12,800
Right now if your best technician leaves

1751
01:07:12,800 --> 01:07:14,640
you lose years of troubleshooting knowledge

1752
01:07:14,640 --> 01:07:16,240
and all the workarounds they've learned.

1753
01:07:16,240 --> 01:07:17,440
Their departure is painful

1754
01:07:17,440 --> 01:07:20,960
but with agents that knowledge is codified in the decision making logic.

1755
01:07:20,960 --> 01:07:22,960
When an agent escalates to a human

1756
01:07:22,960 --> 01:07:24,800
it isn't because it doesn't know what to do

1757
01:07:24,800 --> 01:07:27,360
but because the situation requires human judgment.

1758
01:07:27,360 --> 01:07:29,040
The knowledge doesn't walk out the door

1759
01:07:29,040 --> 01:07:30,800
but you do have a new problem.

1760
01:07:30,800 --> 01:07:32,400
The agent only knows what it knows

1761
01:07:32,400 --> 01:07:35,600
and updating that knowledge requires retraining or policy changes.

1762
01:07:35,600 --> 01:07:38,080
You can't just call a senior tech and ask them a question.

1763
01:07:38,080 --> 01:07:40,400
You have to change the model or the policy.

1764
01:07:40,400 --> 01:07:44,080
The speed to resolution changes your entire relationship with your users.

1765
01:07:44,080 --> 01:07:46,160
Problems get fixed in minutes instead of hours

1766
01:07:46,160 --> 01:07:49,600
and users start to see IT as a responsive service they can trust.

1767
01:07:49,600 --> 01:07:50,880
This isn't a small detail.

1768
01:07:50,880 --> 01:07:52,880
This is how you shift the perception of IT

1769
01:07:52,880 --> 01:07:55,520
from a bottleneck to a service that actually works.

1770
01:07:55,520 --> 01:07:58,080
It changes user behavior, ticket patterns

1771
01:07:58,080 --> 01:08:00,320
and how the business views technology as a whole.

1772
01:08:00,320 --> 01:08:03,680
The real opportunity underneath all of this is the human one.

1773
01:08:03,680 --> 01:08:07,200
Your team isn't spending their energy on repetitive tasks anymore

1774
01:08:07,200 --> 01:08:09,200
so they are finally free to work on things

1775
01:08:09,200 --> 01:08:10,960
that require real human thinking.

1776
01:08:10,960 --> 01:08:13,680
They can design better systems, understand business context

1777
01:08:13,680 --> 01:08:16,160
and strategize about how technology supports the company.

1778
01:08:16,160 --> 01:08:18,720
This is the best version of where technology should go.

1779
01:08:18,720 --> 01:08:20,240
It isn't about replacing humans

1780
01:08:20,240 --> 01:08:23,280
but about removing the drudgery so humans can do the thinking.

1781
01:08:23,280 --> 01:08:24,800
The competitive advantage.

1782
01:08:24,800 --> 01:08:26,560
The companies that get this right first

1783
01:08:26,560 --> 01:08:28,080
have something the others don't

1784
01:08:28,080 --> 01:08:30,320
and it's not just faster ticket resolution.

1785
01:08:30,320 --> 01:08:32,000
It's not just lower operational costs

1786
01:08:32,000 --> 01:08:32,960
though both of those matters.

1787
01:08:32,960 --> 01:08:35,680
The real advantage is that they're building a capability stack

1788
01:08:35,680 --> 01:08:37,120
that compounds over time

1789
01:08:37,120 --> 01:08:39,120
while everyone else is still writing if they're logic.

1790
01:08:39,120 --> 01:08:40,960
Here's how it actually breaks down.

1791
01:08:40,960 --> 01:08:44,160
If your organization moves to autonomous agents in 2026

1792
01:08:44,160 --> 01:08:46,800
you get a two to three year head start on everyone who waits.

1793
01:08:46,800 --> 01:08:48,960
This isn't because the technology is hard to copy.

1794
01:08:48,960 --> 01:08:51,600
Eventually other companies will build similar systems

1795
01:08:51,600 --> 01:08:53,600
but the organizations that start now

1796
01:08:53,600 --> 01:08:55,920
accumulate operational knowledge, feedback data

1797
01:08:55,920 --> 01:08:58,720
and policy patterns that the late comers simply won't have.

1798
01:08:58,720 --> 01:09:01,280
Think about what happens during your first year operating agents.

1799
01:09:01,280 --> 01:09:03,440
You're not just running automation, you're learning,

1800
01:09:03,440 --> 01:09:05,600
you're seeing patterns in what kinds of tickets agents

1801
01:09:05,600 --> 01:09:07,840
handle beautifully and what kinds trip them up.

1802
01:09:07,840 --> 01:09:09,440
You're building institutional knowledge about

1803
01:09:09,440 --> 01:09:11,520
how your specific environment behaves

1804
01:09:11,520 --> 01:09:13,760
and your refining policies dozens of times

1805
01:09:13,760 --> 01:09:15,440
based on real production feedback.

1806
01:09:15,440 --> 01:09:18,080
By the time the year is up you don't just have working agents.

1807
01:09:18,080 --> 01:09:20,240
You have a mature operational model.

1808
01:09:20,240 --> 01:09:23,760
An organization that starts this in 2027 or 2028

1809
01:09:23,760 --> 01:09:25,040
doesn't get to follow your path.

1810
01:09:25,040 --> 01:09:26,160
They have to chart their own.

1811
01:09:26,160 --> 01:09:28,240
They might avoid some of your early mistakes

1812
01:09:28,240 --> 01:09:31,200
but they don't get the benefit of your years of operational refinement.

1813
01:09:31,200 --> 01:09:34,160
They're starting from scratch while you're already optimized.

1814
01:09:34,160 --> 01:09:35,840
The second advantage is data.

1815
01:09:35,840 --> 01:09:38,560
Every ticket in agent resolves, every decision it makes

1816
01:09:38,560 --> 01:09:40,080
and every correction it receives.

1817
01:09:40,080 --> 01:09:41,040
That's training data.

1818
01:09:41,040 --> 01:09:43,040
Your agents get smarter over time

1819
01:09:43,040 --> 01:09:45,680
because they're operating in your actual environment

1820
01:09:45,680 --> 01:09:47,040
against your actual problems.

1821
01:09:47,040 --> 01:09:48,000
If you move fast,

1822
01:09:48,000 --> 01:09:50,400
you accumulate 18 months of production feedback

1823
01:09:50,400 --> 01:09:52,480
before competitors even launch pilots.

1824
01:09:52,480 --> 01:09:54,240
That feedback becomes a learning advantage.

1825
01:09:54,240 --> 01:09:56,000
Your agents understand your environment better

1826
01:09:56,000 --> 01:09:57,840
than any generic agent ever could

1827
01:09:57,840 --> 01:09:59,600
because they've seen your specific patterns,

1828
01:09:59,600 --> 01:10:01,360
your specific edge cases

1829
01:10:01,360 --> 01:10:03,200
and your specific business context.

1830
01:10:03,200 --> 01:10:05,520
The third advantage is organizational readiness.

1831
01:10:05,520 --> 01:10:07,600
By the time your industry is having conversations

1832
01:10:07,600 --> 01:10:09,920
about autonomous agents in 2027,

1833
01:10:09,920 --> 01:10:11,440
you've already retrained your team.

1834
01:10:11,440 --> 01:10:13,360
You've already figured out what skills matter.

1835
01:10:13,360 --> 01:10:15,120
You've already built the cultural capability

1836
01:10:15,120 --> 01:10:17,040
to work alongside autonomous systems.

1837
01:10:17,040 --> 01:10:18,400
You've already had the hard conversations

1838
01:10:18,400 --> 01:10:20,560
about what gets automated and what stays human.

1839
01:10:20,560 --> 01:10:23,600
Organizations coming later don't get that cultural head start.

1840
01:10:23,600 --> 01:10:25,440
They're still figuring out how to think about this

1841
01:10:25,440 --> 01:10:26,960
while you're already executing.

1842
01:10:26,960 --> 01:10:29,440
The fourth advantage is market consolidation.

1843
01:10:29,440 --> 01:10:30,800
In every technology transition,

1844
01:10:30,800 --> 01:10:33,120
the leaders captured disproportionate market share,

1845
01:10:33,120 --> 01:10:35,280
not because they have better technology eventually.

1846
01:10:35,280 --> 01:10:36,320
Competitors catch up,

1847
01:10:36,320 --> 01:10:38,400
but because they hit escape velocity first,

1848
01:10:38,400 --> 01:10:40,240
they're solving customer problems faster.

1849
01:10:40,240 --> 01:10:42,000
They're cheaper, they're more reliable.

1850
01:10:42,000 --> 01:10:43,040
They start winning business.

1851
01:10:43,040 --> 01:10:46,480
By the time competitors launch similar solutions,

1852
01:10:46,480 --> 01:10:48,640
the leader has already grown their customer base,

1853
01:10:48,640 --> 01:10:50,080
built stronger partnerships,

1854
01:10:50,080 --> 01:10:51,840
and established market presence.

1855
01:10:51,840 --> 01:10:54,960
The technology is table stakes after the first mover advantage.

1856
01:10:54,960 --> 01:10:56,880
The market position is what lasts,

1857
01:10:56,880 --> 01:10:58,160
but there's also a risk

1858
01:10:58,160 --> 01:11:00,480
that makes this a necessity rather than an option.

1859
01:11:00,480 --> 01:11:03,040
Organizations that don't move toward autonomous agents

1860
01:11:03,040 --> 01:11:06,720
by 2027 or 2028 start falling behind operationally.

1861
01:11:06,720 --> 01:11:08,480
Not gradually, sharply.

1862
01:11:08,480 --> 01:11:10,560
Imagine your competitor has reduced their meantime

1863
01:11:10,560 --> 01:11:11,920
to resolution to 40 minutes,

1864
01:11:11,920 --> 01:11:13,600
while yours is still three hours.

1865
01:11:13,600 --> 01:11:17,360
Imagine they're handling 80% of routine tickets autonomously

1866
01:11:17,360 --> 01:11:18,640
while you're at 20%.

1867
01:11:18,640 --> 01:11:22,240
Imagine their IT operational cost per resolution is half of yours.

1868
01:11:22,240 --> 01:11:23,520
These aren't minor differences.

1869
01:11:23,520 --> 01:11:26,000
These are the differences that show up in your margins,

1870
01:11:26,000 --> 01:11:27,680
your customer satisfaction scores,

1871
01:11:27,680 --> 01:11:29,440
and your ability to compete.

1872
01:11:29,440 --> 01:11:32,080
This is why the shift from automation is optional

1873
01:11:32,080 --> 01:11:34,080
to automation is strategic matters.

1874
01:11:34,080 --> 01:11:35,520
For the last 15 years,

1875
01:11:35,520 --> 01:11:38,000
you could be competitive with decent scripting

1876
01:11:38,000 --> 01:11:39,920
and solid operational practices.

1877
01:11:39,920 --> 01:11:41,360
That era is ending.

1878
01:11:41,360 --> 01:11:44,080
The organizations that build autonomous agent capabilities

1879
01:11:44,080 --> 01:11:47,280
now will set the standard for what IT operations look like.

1880
01:11:47,280 --> 01:11:48,640
Everyone else will be playing catch-up.

1881
01:11:48,640 --> 01:11:50,800
Not because the technology is complex, it's not.

1882
01:11:50,800 --> 01:11:52,320
Because the organizational capability

1883
01:11:52,320 --> 01:11:54,560
and operational knowledge compounds over time.

1884
01:11:54,560 --> 01:11:57,280
You can't catch up on learning by throwing money at the problem.

1885
01:11:57,280 --> 01:11:58,640
You catch up by committing now.

1886
01:11:58,640 --> 01:12:00,560
The competitive advantage isn't permanent.

1887
01:12:00,560 --> 01:12:02,720
It's an 18-24-month window

1888
01:12:02,720 --> 01:12:04,800
where the first move is established a lead.

1889
01:12:04,800 --> 01:12:07,520
After that, the technology is available to everyone.

1890
01:12:07,520 --> 01:12:08,960
But the organizations that move first

1891
01:12:08,960 --> 01:12:10,560
have already built the muscle memory.

1892
01:12:10,560 --> 01:12:12,160
They know what works in their environment.

1893
01:12:12,160 --> 01:12:13,440
They've optimized their workflows.

1894
01:12:13,440 --> 01:12:14,720
They've trained their teams.

1895
01:12:14,720 --> 01:12:17,360
They've embedded autonomous operations into their DNA.

1896
01:12:17,360 --> 01:12:19,040
That advantage takes years to overcome.

1897
01:12:19,040 --> 01:12:22,400
Static power shell scripts worked for a predictable world.

1898
01:12:22,400 --> 01:12:23,680
That world doesn't exist anymore.

1899
01:12:23,680 --> 01:12:25,120
Your enterprise is dynamic.

1900
01:12:25,120 --> 01:12:26,480
Your problems are complex.

1901
01:12:26,480 --> 01:12:29,680
And automation without reasoning is just repetition at high speed.

1902
01:12:29,680 --> 01:12:32,320
The shift to autonomous agents powered by semantic kernel

1903
01:12:32,320 --> 01:12:34,480
and Microsoft Graph isn't a technology change.

1904
01:12:34,480 --> 01:12:35,600
It's an operational one.

1905
01:12:35,600 --> 01:12:37,760
It's how IT operations work starting now.

1906
01:12:37,760 --> 01:12:40,400
Start building your first agent in the next quarter.

1907
01:12:40,400 --> 01:12:42,240
Pick a domain where you have high ticket volume

1908
01:12:42,240 --> 01:12:43,360
and low variation.

1909
01:12:43,360 --> 01:12:44,560
Get it running in production.

1910
01:12:44,560 --> 01:12:45,360
Measure what matters.

1911
01:12:45,360 --> 01:12:47,600
Use those results to expand.

1912
01:12:47,600 --> 01:12:49,600
The time to start isn't some time next year.

1913
01:12:49,600 --> 01:12:50,160
It's now.

1914
01:12:50,160 --> 01:12:52,000
Your competitive advantage depends on it.