Architecture Over Chat: Building the Agent Fabric

1
00:00:00,000 --> 00:00:02,880
Most organizations believe they have AI agents right now,

2
00:00:02,880 --> 00:00:06,120
that they don't, what they have are chatbots trapped in tabs,

3
00:00:06,120 --> 00:00:09,560
ephemeral, context starved, and useless the moment you close

4
00:00:09,560 --> 00:00:11,240
the window or switch devices.

5
00:00:11,240 --> 00:00:12,600
You ask your AI a question.

6
00:00:12,600 --> 00:00:14,640
It answers, you close Slack.

7
00:00:14,640 --> 00:00:16,240
The agent forgets you exist.

8
00:00:16,240 --> 00:00:17,800
The thing is, everyone blames the model.

9
00:00:17,800 --> 00:00:20,560
We tell ourselves we need a smarter LLM or better prompting,

10
00:00:20,560 --> 00:00:22,880
but here's what's actually broken, the architecture,

11
00:00:22,880 --> 00:00:25,720
not the brain, the nervous system.

12
00:00:25,720 --> 00:00:29,200
This episode is about the shift from chat to fabric.

13
00:00:29,200 --> 00:00:32,040
We are moving from isolated conversations happening nowhere

14
00:00:32,040 --> 00:00:34,680
to a persistent multi-device system that actually

15
00:00:34,680 --> 00:00:36,600
behaves like a workforce participant.

16
00:00:36,600 --> 00:00:39,440
And I'm going to show you why the GitHub Copilot SDK

17
00:00:39,440 --> 00:00:42,040
and Microsoft agent 365 are blueprints

18
00:00:42,040 --> 00:00:43,800
for how this needs to work.

19
00:00:43,800 --> 00:00:46,080
The expectation versus reality.

20
00:00:46,080 --> 00:00:47,360
Let's start with what we're promised.

21
00:00:47,360 --> 00:00:48,720
You have an AI agent.

22
00:00:48,720 --> 00:00:49,480
It's intelligent.

23
00:00:49,480 --> 00:00:52,560
It knows your context, your projects, your priorities,

24
00:00:52,560 --> 00:00:53,880
and your past decisions.

25
00:00:53,880 --> 00:00:55,200
It remembers your preferences.

26
00:00:55,200 --> 00:00:56,920
It works across every device you touch.

27
00:00:56,920 --> 00:00:58,480
You start a task on your laptop.

28
00:00:58,480 --> 00:01:00,000
And then you pick it back up on your phone

29
00:01:00,000 --> 00:01:02,960
without missing a beat before finishing it on your tablet.

30
00:01:02,960 --> 00:01:04,200
The agent moves with you.

31
00:01:04,200 --> 00:01:05,880
This agent doesn't just answer questions.

32
00:01:05,880 --> 00:01:06,640
It owns work.

33
00:01:06,640 --> 00:01:08,120
It coordinates with other agents.

34
00:01:08,120 --> 00:01:11,120
It knows which data it can access and which it can't.

35
00:01:11,120 --> 00:01:14,040
When something goes wrong, there's a full audit trail showing

36
00:01:14,040 --> 00:01:15,840
exactly what it did and why.

37
00:01:15,840 --> 00:01:17,160
That's the dream.

38
00:01:17,160 --> 00:01:18,080
Now, the reality.

39
00:01:18,080 --> 00:01:19,720
Current agents reset every session.

40
00:01:19,720 --> 00:01:22,240
They lose context the moment you switch applications.

41
00:01:22,240 --> 00:01:23,880
They operate in complete isolation

42
00:01:23,880 --> 00:01:26,400
from every other agent in your organization.

43
00:01:26,400 --> 00:01:29,040
A customer service agent can't talk to a finance agent

44
00:01:29,040 --> 00:01:31,240
and a sales agent can't pull inventory data,

45
00:01:31,240 --> 00:01:32,960
which means they're trapped in their own silos

46
00:01:32,960 --> 00:01:35,320
while running the exact same reasoning from scratch.

47
00:01:35,320 --> 00:01:37,880
When you give a single siloed agent a multi-step task,

48
00:01:37,880 --> 00:01:39,840
it fails 65% of the time.

49
00:01:39,840 --> 00:01:41,120
The moment complexity enters,

50
00:01:41,120 --> 00:01:43,440
the moment you need it to remember a prior decision,

51
00:01:43,440 --> 00:01:44,920
adapt based on new information

52
00:01:44,920 --> 00:01:46,520
or coordinate with another system.

53
00:01:46,520 --> 00:01:47,560
It falls apart.

54
00:01:47,560 --> 00:01:48,880
And here's the deeper problem.

55
00:01:48,880 --> 00:01:50,840
We've been treating agents like chat interfaces

56
00:01:50,840 --> 00:01:52,680
instead of like what they actually need to be.

57
00:01:52,680 --> 00:01:53,880
Workforce participants.

58
00:01:53,880 --> 00:01:55,240
Chat is stateless by design.

59
00:01:55,240 --> 00:01:57,080
Every turn is independent.

60
00:01:57,080 --> 00:01:59,040
You ask, it responds done.

61
00:01:59,040 --> 00:02:00,360
But agents don't work that way.

62
00:02:00,360 --> 00:02:01,480
Agents require state.

63
00:02:01,480 --> 00:02:02,880
They need memory across sessions.

64
00:02:02,880 --> 00:02:04,360
They need decisions that compound.

65
00:02:04,360 --> 00:02:06,400
They need context that persists across days,

66
00:02:06,400 --> 00:02:08,320
across devices and across teams.

67
00:02:08,320 --> 00:02:11,480
The vendors have sold us chat because it's easy to understand.

68
00:02:11,480 --> 00:02:12,320
It maps to Slack.

69
00:02:12,320 --> 00:02:13,120
It maps to teams.

70
00:02:13,120 --> 00:02:15,840
It's familiar, but it's the wrong abstraction entirely.

71
00:02:15,840 --> 00:02:17,920
So organizations invest millions in co-pilates

72
00:02:17,920 --> 00:02:21,680
and AI agents that can't scale beyond toy scenarios.

73
00:02:21,680 --> 00:02:22,680
They can't coordinate.

74
00:02:22,680 --> 00:02:23,440
They can't remember.

75
00:02:23,440 --> 00:02:24,440
They can't persist.

76
00:02:24,440 --> 00:02:27,440
And when you try to ask them to do something genuinely complex,

77
00:02:27,440 --> 00:02:29,760
something that requires context from multiple systems,

78
00:02:29,760 --> 00:02:34,920
multiple time periods, and multiple people, they collapse.

79
00:02:34,920 --> 00:02:36,760
This is why a typical enterprise ends up

80
00:02:36,760 --> 00:02:39,240
with a graveyard of failed AI projects.

81
00:02:39,240 --> 00:02:40,840
Not because the models aren't smart enough,

82
00:02:40,840 --> 00:02:43,040
because nobody built the infrastructure for agents

83
00:02:43,040 --> 00:02:44,640
to actually be agents.

84
00:02:44,640 --> 00:02:46,120
That's what we're here to fix.

85
00:02:46,120 --> 00:02:48,920
Over the next hour, we're going to walk through the architecture

86
00:02:48,920 --> 00:02:50,040
that actually works.

87
00:02:50,040 --> 00:02:53,600
We'll diagnose every structural flaw in how agents are built today.

88
00:02:53,600 --> 00:02:56,000
And we'll show you the blueprint, the real blueprint,

89
00:02:56,000 --> 00:02:59,160
for what a persistent, multi-device governed agent system

90
00:02:59,160 --> 00:02:59,960
looks like.

91
00:02:59,960 --> 00:03:04,040
It starts with understanding that this isn't about chat at all.

92
00:03:04,040 --> 00:03:05,400
The silo problem defined.

93
00:03:05,400 --> 00:03:07,840
Let's get concrete about where your agents actually live right now.

94
00:03:07,840 --> 00:03:09,920
Your Salesforce deployment has a CRM agent.

95
00:03:09,920 --> 00:03:11,000
It understands deals.

96
00:03:11,000 --> 00:03:12,520
It knows your sales pipeline.

97
00:03:12,520 --> 00:03:14,280
It can answer questions about pipeline health,

98
00:03:14,280 --> 00:03:16,360
forecast accuracy, and deal progression.

99
00:03:16,360 --> 00:03:17,960
But it only knows about Salesforce.

100
00:03:17,960 --> 00:03:20,520
It has no idea what's happening in your customer service system

101
00:03:20,520 --> 00:03:21,640
or your finance platform.

102
00:03:21,640 --> 00:03:24,360
Meanwhile, your Gira environment has its own agent.

103
00:03:24,360 --> 00:03:25,520
It understands tickets.

104
00:03:25,520 --> 00:03:27,120
It knows sprint velocity.

105
00:03:27,120 --> 00:03:30,320
It can analyze engineering capacity and predict release dates.

106
00:03:30,320 --> 00:03:32,240
But ask a question that requires data

107
00:03:32,240 --> 00:03:33,880
from your incident management tool.

108
00:03:33,880 --> 00:03:34,840
And it goes silent.

109
00:03:34,840 --> 00:03:35,800
It doesn't have access.

110
00:03:35,800 --> 00:03:36,720
It doesn't have context.

111
00:03:36,720 --> 00:03:37,840
It exists in isolation.

112
00:03:37,840 --> 00:03:39,480
Your CRM has a different agent.

113
00:03:39,480 --> 00:03:41,240
Your accounting platform has another.

114
00:03:41,240 --> 00:03:42,560
Your helpdesk has one more.

115
00:03:42,560 --> 00:03:45,880
Every major system you use has built its own AI capability.

116
00:03:45,880 --> 00:03:48,480
And every single one operates in complete isolation

117
00:03:48,480 --> 00:03:49,760
from every other.

118
00:03:49,760 --> 00:03:51,440
Here's the architecture underneath.

119
00:03:51,440 --> 00:03:54,400
Each silo maintains its own context window, its own memory

120
00:03:54,400 --> 00:03:56,960
store, its own permissions model, its own data schema.

121
00:03:56,960 --> 00:03:59,560
An agent in Salesforce uses Salesforce's API

122
00:03:59,560 --> 00:04:00,640
to fetch data.

123
00:04:00,640 --> 00:04:02,480
It authenticates with Salesforce credentials.

124
00:04:02,480 --> 00:04:04,800
It operates inside Salesforce's security boundary.

125
00:04:04,800 --> 00:04:06,520
It has no bridge to any other system.

126
00:04:06,520 --> 00:04:08,400
The result is exactly what you'd expect.

127
00:04:08,400 --> 00:04:11,160
An agent in one system cannot see an agent in another.

128
00:04:11,160 --> 00:04:12,160
They cannot coordinate.

129
00:04:12,160 --> 00:04:13,680
They cannot pass work between them.

130
00:04:13,680 --> 00:04:14,960
They don't know each other exist.

131
00:04:14,960 --> 00:04:17,240
Now let's think about what this means operationally.

132
00:04:17,240 --> 00:04:19,200
A customer calls with a billing dispute.

133
00:04:19,200 --> 00:04:21,440
Your customer service agent in the helpdesk system

134
00:04:21,440 --> 00:04:23,320
tries to resolve it, but the resolution

135
00:04:23,320 --> 00:04:24,640
requires a credit adjustment.

136
00:04:24,640 --> 00:04:26,040
That's a finance operation.

137
00:04:26,040 --> 00:04:27,560
So the agent escalates to a human.

138
00:04:27,560 --> 00:04:29,400
The human logs into the accounting system.

139
00:04:29,400 --> 00:04:30,640
Manually reviews the account.

140
00:04:30,640 --> 00:04:32,160
Manually processes the credit.

141
00:04:32,160 --> 00:04:33,840
Manually documents the decision.

142
00:04:33,840 --> 00:04:36,040
Then logs back into the helpdesk to close the ticket.

143
00:04:36,040 --> 00:04:38,720
That manual handoff, that's a human becoming an integration

144
00:04:38,720 --> 00:04:39,000
layer.

145
00:04:39,000 --> 00:04:41,120
You're paying salary to bridge a gap that automation

146
00:04:41,120 --> 00:04:41,880
should have handled.

147
00:04:41,880 --> 00:04:43,680
Or consider a sales scenario.

148
00:04:43,680 --> 00:04:45,920
A sales agent in your CRM identifies a high value

149
00:04:45,920 --> 00:04:46,680
opportunity.

150
00:04:46,680 --> 00:04:48,080
It wants to root that opportunity

151
00:04:48,080 --> 00:04:50,720
to the right team member based on territory and capacity.

152
00:04:50,720 --> 00:04:53,120
But capacity data lives in your HR system.

153
00:04:53,120 --> 00:04:55,720
Territory rules live in your legacy ERP.

154
00:04:55,720 --> 00:04:57,920
Availability calendars live in Office 365.

155
00:04:57,920 --> 00:04:59,640
So the agent can't actually root anything.

156
00:04:59,640 --> 00:05:00,880
It generates a recommendation.

157
00:05:00,880 --> 00:05:02,080
A human reads it.

158
00:05:02,080 --> 00:05:03,440
Manually checks capacity.

159
00:05:03,440 --> 00:05:05,200
Manually verifies territory.

160
00:05:05,200 --> 00:05:06,680
Manually sends an assignment.

161
00:05:06,680 --> 00:05:09,360
This happens thousands of times across your organization.

162
00:05:09,360 --> 00:05:11,360
Not because the AI models aren't smart,

163
00:05:11,360 --> 00:05:13,560
because the architecture prevents them from being smart.

164
00:05:13,560 --> 00:05:17,120
The deeper architectural truth here is worth stating directly.

165
00:05:17,120 --> 00:05:19,640
Siload agents are not agents at all.

166
00:05:19,640 --> 00:05:21,840
An agent is something that observes a situation,

167
00:05:21,840 --> 00:05:24,840
makes a decision, and takes action in service of a goal.

168
00:05:24,840 --> 00:05:27,360
But if your agent can only observe within Salesforce,

169
00:05:27,360 --> 00:05:29,600
can only read data in Salesforce format,

170
00:05:29,600 --> 00:05:32,080
can only act through Salesforce APIs,

171
00:05:32,080 --> 00:05:34,640
and has no way to hand off work to another system.

172
00:05:34,640 --> 00:05:36,120
It's not really an agent.

173
00:05:36,120 --> 00:05:38,160
It's sophisticated auto-complete.

174
00:05:38,160 --> 00:05:41,320
It's a chatbot that has memorized your database schema.

175
00:05:41,320 --> 00:05:43,480
This distinction matters because it shapes everything

176
00:05:43,480 --> 00:05:44,480
that comes next.

177
00:05:44,480 --> 00:05:46,360
It's why your current agents fail at complexity.

178
00:05:46,360 --> 00:05:48,480
It's why you end up with dozens of isolated bots

179
00:05:48,480 --> 00:05:50,120
instead of a coordinated system.

180
00:05:50,120 --> 00:05:51,600
It's why you're still hiring humans

181
00:05:51,600 --> 00:05:54,040
to do the integration work that machines should handle.

182
00:05:54,040 --> 00:05:56,680
The fix isn't to make each individual silo smarter.

183
00:05:56,680 --> 00:05:58,840
It's to break the silos apart and rebuild them

184
00:05:58,840 --> 00:06:00,440
as a connected fabric.

185
00:06:00,440 --> 00:06:02,080
Why chat is the wrong model.

186
00:06:02,080 --> 00:06:03,880
The conversation metaphor is poisoning

187
00:06:03,880 --> 00:06:05,360
how we think about agents.

188
00:06:05,360 --> 00:06:07,800
When you call something a copilot or an assistant,

189
00:06:07,800 --> 00:06:10,080
you trigger an assumption in the listener's brain.

190
00:06:10,080 --> 00:06:11,080
They think about Siri.

191
00:06:11,080 --> 00:06:14,000
They think about talking to someone who helps you do your job.

192
00:06:14,000 --> 00:06:16,680
It's intimate, it's responsive, it's conversational.

193
00:06:16,680 --> 00:06:19,120
And that mental model shapes everything that comes next,

194
00:06:19,120 --> 00:06:21,600
including the technical decisions that people make.

195
00:06:21,600 --> 00:06:22,840
But here's what's actually happened.

196
00:06:22,840 --> 00:06:26,280
The vendors have stuck an incredibly powerful AI capability

197
00:06:26,280 --> 00:06:28,120
into a chat interface because that interface

198
00:06:28,120 --> 00:06:30,200
was the easiest thing to build and the easiest thing

199
00:06:30,200 --> 00:06:31,640
for users to understand.

200
00:06:31,640 --> 00:06:33,440
And then the entire industry internalized

201
00:06:33,440 --> 00:06:35,240
that constrained as a requirement.

202
00:06:35,240 --> 00:06:36,240
The reality is different.

203
00:06:36,240 --> 00:06:38,640
What you need from an agent is not conversation.

204
00:06:38,640 --> 00:06:40,160
Conversation is a femoral.

205
00:06:40,160 --> 00:06:41,160
It's momentary.

206
00:06:41,160 --> 00:06:42,200
You have an exchange.

207
00:06:42,200 --> 00:06:42,720
You move on.

208
00:06:42,720 --> 00:06:43,520
It evaporates.

209
00:06:43,520 --> 00:06:45,280
And that's fine for a help desk experience.

210
00:06:45,280 --> 00:06:48,040
You have a question, the chatbot answers, you leave.

211
00:06:48,040 --> 00:06:49,720
That interaction is self-contained.

212
00:06:49,720 --> 00:06:52,360
But agents in an enterprise context can't work that way.

213
00:06:52,360 --> 00:06:54,440
The moment you try to use them for actual work,

214
00:06:54,440 --> 00:06:57,080
for orchestration, for decision making, for coordination,

215
00:06:57,080 --> 00:06:59,040
the stateless conversation model falls apart.

216
00:06:59,040 --> 00:07:02,120
Think about what stateless actually means operationally.

217
00:07:02,120 --> 00:07:04,920
It means the agent has no memory of prior context.

218
00:07:04,920 --> 00:07:07,480
It means every decision it makes exists in isolation

219
00:07:07,480 --> 00:07:08,840
from every other decision.

220
00:07:08,840 --> 00:07:10,240
It means when the conversation ends,

221
00:07:10,240 --> 00:07:12,080
everything the agent learned about your situation

222
00:07:12,080 --> 00:07:12,920
disappears.

223
00:07:12,920 --> 00:07:13,760
There's no continuity.

224
00:07:13,760 --> 00:07:14,600
There's no learning.

225
00:07:14,600 --> 00:07:15,920
There's no compounding of judgment.

226
00:07:15,920 --> 00:07:17,280
Now, overlay on top of that, the fact

227
00:07:17,280 --> 00:07:20,240
that an agent in a real organization needs to do things.

228
00:07:20,240 --> 00:07:21,160
It needs permissions.

229
00:07:21,160 --> 00:07:23,720
It needs to know which databases it can read from,

230
00:07:23,720 --> 00:07:26,600
which APIs it's authorized to call, which files it can modify,

231
00:07:26,600 --> 00:07:29,920
which users it can act on behalf of, and agent needs an identity.

232
00:07:29,920 --> 00:07:32,840
This is where the chat model breaks down completely.

233
00:07:32,840 --> 00:07:34,680
In a conversation, you don't have an identity.

234
00:07:34,680 --> 00:07:35,560
You're just a user.

235
00:07:35,560 --> 00:07:36,240
You have a name.

236
00:07:36,240 --> 00:07:37,160
Maybe you have a role.

237
00:07:37,160 --> 00:07:38,520
But you're a femoral, too.

238
00:07:38,520 --> 00:07:40,040
You come, you ask your question, you leave.

239
00:07:40,040 --> 00:07:42,000
The conversation doesn't outlive your presence.

240
00:07:42,000 --> 00:07:44,360
But an agent that's coordinating work across systems

241
00:07:44,360 --> 00:07:45,560
can't be a femoral.

242
00:07:45,560 --> 00:07:46,880
It needs a persistent identity.

243
00:07:46,880 --> 00:07:48,280
It needs to be auditable.

244
00:07:48,280 --> 00:07:51,200
When an agent makes a decision that affects a business process,

245
00:07:51,200 --> 00:07:54,120
you need to be able to trace that decision back to the agent,

246
00:07:54,120 --> 00:07:56,240
verify that the agent had the right permissions,

247
00:07:56,240 --> 00:07:58,440
and audit exactly what happened and why.

248
00:07:58,440 --> 00:08:01,040
Vendors have built audit trails on top of chat systems

249
00:08:01,040 --> 00:08:02,040
as an afterthought.

250
00:08:02,040 --> 00:08:03,160
They lock the conversations.

251
00:08:03,160 --> 00:08:04,440
They store the prompts.

252
00:08:04,440 --> 00:08:06,280
But the entire architecture underneath

253
00:08:06,280 --> 00:08:09,320
treats the conversation as the unit of work, not the agent.

254
00:08:09,320 --> 00:08:10,760
The consequence is that agents

255
00:08:10,760 --> 00:08:13,520
built on conversational architectures can't scale beyond toy

256
00:08:13,520 --> 00:08:14,600
scenarios.

257
00:08:14,600 --> 00:08:16,720
You can build a chatbot that answers questions

258
00:08:16,720 --> 00:08:18,200
about your product knowledge base.

259
00:08:18,200 --> 00:08:20,120
That's within the constraints of the chat model.

260
00:08:20,120 --> 00:08:23,240
You can even build one that uses tools, that reads some data,

261
00:08:23,240 --> 00:08:26,560
runs some analysis, returns a result, still works.

262
00:08:26,560 --> 00:08:29,160
But the moment you need an agent that remembers decisions

263
00:08:29,160 --> 00:08:31,360
across multiple conversations, operates

264
00:08:31,360 --> 00:08:33,720
with its own distinct identity and permissions,

265
00:08:33,720 --> 00:08:36,480
coordinates with other agents, maintains audit trails

266
00:08:36,480 --> 00:08:39,440
that satisfy compliance requirements, executes long-running

267
00:08:39,440 --> 00:08:41,800
workflows that span days or weeks.

268
00:08:41,800 --> 00:08:43,520
The chat model doesn't just fail.

269
00:08:43,520 --> 00:08:44,800
It becomes an active obstacle.

270
00:08:44,800 --> 00:08:46,720
You're building increasingly elaborate work

271
00:08:46,720 --> 00:08:49,400
rounds on top of a foundation that was never meant

272
00:08:49,400 --> 00:08:51,000
to support this kind of work.

273
00:08:51,000 --> 00:08:53,960
What an agent actually needs to be is a system participant,

274
00:08:53,960 --> 00:08:55,920
not a conversational interface, a participant

275
00:08:55,920 --> 00:08:57,200
in your business processes.

276
00:08:57,200 --> 00:08:59,840
Something with identity, something with persistent memory,

277
00:08:59,840 --> 00:09:01,280
something that can be governed, something

278
00:09:01,280 --> 00:09:04,080
that operates continuously, not just when a user is typing

279
00:09:04,080 --> 00:09:04,560
at it.

280
00:09:04,560 --> 00:09:05,920
This is the fundamental mismatch.

281
00:09:05,920 --> 00:09:07,440
And until organizations understand

282
00:09:07,440 --> 00:09:09,320
that their agents need to be system participants,

283
00:09:09,320 --> 00:09:11,760
not chat interfaces, they'll keep building agents

284
00:09:11,760 --> 00:09:15,440
that look impressive in demos and fail in production.

285
00:09:15,440 --> 00:09:17,480
Session persistence, the missing piece.

286
00:09:17,480 --> 00:09:18,840
Your agents are forgetting.

287
00:09:18,840 --> 00:09:19,960
The problem is simple.

288
00:09:19,960 --> 00:09:22,640
Most agents today are built on conversational architectures

289
00:09:22,640 --> 00:09:23,600
that are stateless.

290
00:09:23,600 --> 00:09:26,200
They don't remember context between interactions.

291
00:09:26,200 --> 00:09:28,360
They can't keep work alive across different times

292
00:09:28,360 --> 00:09:29,560
or different devices.

293
00:09:29,560 --> 00:09:32,440
The fix starts with a concept that most platforms ignore.

294
00:09:32,440 --> 00:09:33,240
The session.

295
00:09:33,240 --> 00:09:35,280
A session is the container where state lives.

296
00:09:35,280 --> 00:09:37,680
It holds everything an agent knows about a specific piece

297
00:09:37,680 --> 00:09:38,360
of work.

298
00:09:38,360 --> 00:09:40,840
It stores your current task, your past decisions,

299
00:09:40,840 --> 00:09:43,760
the data you've retrieved, and the files you've already scanned.

300
00:09:43,760 --> 00:09:46,520
Without a session, the agent has nothing to hold on to.

301
00:09:46,520 --> 00:09:48,680
Every time you talk to it, you are starting from zero.

302
00:09:48,680 --> 00:09:50,240
Think about how you use Slack.

303
00:09:50,240 --> 00:09:52,160
You close the app, you open it the next day,

304
00:09:52,160 --> 00:09:53,320
and your history is still there.

305
00:09:53,320 --> 00:09:55,120
You can scroll back and see the discussion.

306
00:09:55,120 --> 00:09:57,960
But if you ask a question that needs context from yesterday,

307
00:09:57,960 --> 00:09:59,920
you have to paste that information back in.

308
00:09:59,920 --> 00:10:01,880
The AI doesn't actually know it exists.

309
00:10:01,880 --> 00:10:02,840
That isn't a feature.

310
00:10:02,840 --> 00:10:04,160
It's a structural flaw.

311
00:10:04,160 --> 00:10:06,480
A session makes state durable by writing context

312
00:10:06,480 --> 00:10:09,880
to a database or a disk instead of just holding it in active memory.

313
00:10:09,880 --> 00:10:12,600
This means the information survives when the conversation ends.

314
00:10:12,600 --> 00:10:14,440
When you come back an hour later or week later

315
00:10:14,440 --> 00:10:17,520
on a totally different device, the agent retrieves that context.

316
00:10:17,520 --> 00:10:19,440
It continues exactly where it left off.

317
00:10:19,440 --> 00:10:22,080
GitHub's co-pilot SDK treats session persistence

318
00:10:22,080 --> 00:10:23,800
as a core architectural feature.

319
00:10:23,800 --> 00:10:25,200
It isn't an afterthought or something

320
00:10:25,200 --> 00:10:26,920
you bolt onto a chat system.

321
00:10:26,920 --> 00:10:29,680
The session management is baked directly into the runtime.

322
00:10:29,680 --> 00:10:32,320
When you start an agent session, you get a stable session ID.

323
00:10:32,320 --> 00:10:34,960
You can save that ID, pass it to another device,

324
00:10:34,960 --> 00:10:36,840
or close the application entirely.

325
00:10:36,840 --> 00:10:40,040
Hours later, you can create a new connection using that same ID.

326
00:10:40,040 --> 00:10:41,800
The entire state comes back every decision

327
00:10:41,800 --> 00:10:44,400
and every piece of memory is restored instantly.

328
00:10:44,400 --> 00:10:46,000
The mechanism is straightforward.

329
00:10:46,000 --> 00:10:48,040
The SDK keeps persistent event logs

330
00:10:48,040 --> 00:10:50,280
that survive even if a process dies.

331
00:10:50,280 --> 00:10:52,120
When the session resumes, the agent doesn't

332
00:10:52,120 --> 00:10:53,920
recreate its state from scratch.

333
00:10:53,920 --> 00:10:55,160
It simply replays the log.

334
00:10:55,160 --> 00:10:58,440
It rebuilds its understanding of what happened and what data it accessed.

335
00:10:58,440 --> 00:11:00,640
This sounds simple because it is.

336
00:11:00,640 --> 00:11:02,000
But it's also fundamental.

337
00:11:02,000 --> 00:11:04,720
Imagine a developer starting a multi-day code migration.

338
00:11:04,720 --> 00:11:07,080
On day one, she uses the agent in her IDE

339
00:11:07,080 --> 00:11:09,240
to analyze the code and draft an approach.

340
00:11:09,240 --> 00:11:12,000
The agent keeps detailed notes on the risks and decisions.

341
00:11:12,000 --> 00:11:14,360
At the end of the day, that session is saved.

342
00:11:14,360 --> 00:11:16,120
On day two, she's away from her desk.

343
00:11:16,120 --> 00:11:17,600
She opens a web client on her phone

344
00:11:17,600 --> 00:11:19,400
and enters the same session ID.

345
00:11:19,400 --> 00:11:21,080
The agent returns with full context.

346
00:11:21,080 --> 00:11:22,640
It knows where the analysis stopped.

347
00:11:22,640 --> 00:11:24,360
It knows the architecture decisions.

348
00:11:24,360 --> 00:11:26,840
It continues the planning without repeating a single step.

349
00:11:26,840 --> 00:11:28,720
On day three, she's back at her desktop.

350
00:11:28,720 --> 00:11:30,640
It's the same session and the same context.

351
00:11:30,640 --> 00:11:33,000
The agent has been working on this for three days.

352
00:11:33,000 --> 00:11:36,640
It has accumulated knowledge that compounds with every single interaction.

353
00:11:36,640 --> 00:11:38,120
That is what persistence enables.

354
00:11:38,120 --> 00:11:39,920
There is a governance angle here too.

355
00:11:39,920 --> 00:11:43,120
Persistence sessions are auditable because every action is logged.

356
00:11:43,120 --> 00:11:44,360
Every decision leaves a trace.

357
00:11:44,360 --> 00:11:48,400
When an agent finishes a task, you have a complete record of how it got there.

358
00:11:48,400 --> 00:11:51,120
You see the tools it used in the data it examined.

359
00:11:51,120 --> 00:11:54,240
This is critical for compliance and for debugging when things break.

360
00:11:54,240 --> 00:11:57,040
The challenge is that persistence requires infrastructure.

361
00:11:57,040 --> 00:12:00,560
You need a place to store state and a way to sync it across devices.

362
00:12:00,560 --> 00:12:02,600
You need recovery mechanisms and audit logging.

363
00:12:02,600 --> 00:12:04,680
You need policies for how long you keep that data.

364
00:12:04,680 --> 00:12:06,480
This is why most agents are still stateless.

365
00:12:06,480 --> 00:12:08,040
It isn't because stateless is better.

366
00:12:08,040 --> 00:12:12,720
It's because building the infrastructure for persistence is harder than building a temporary chatbot.

367
00:12:12,720 --> 00:12:14,280
This is where the divide happens.

368
00:12:14,280 --> 00:12:17,360
Organizations that invest in this infrastructure gain a massive advantage.

369
00:12:17,360 --> 00:12:22,320
The ones that don't will keep building workarounds on top of architectures that were never meant to last.

370
00:12:22,320 --> 00:12:24,520
Multi-device as a structural requirement.

371
00:12:24,520 --> 00:12:26,920
The world where you worked from one machine is over.

372
00:12:26,920 --> 00:12:28,360
Your team doesn't stay on one device.

373
00:12:28,360 --> 00:12:28,960
Nobody does.

374
00:12:28,960 --> 00:12:32,640
You use a laptop in the office, a phone while commuting and a tablet in meetings.

375
00:12:32,640 --> 00:12:35,400
You jump back to a desktop when you need a real keyboard.

376
00:12:35,400 --> 00:12:38,280
Your agent needs to follow you through every one of those moves.

377
00:12:38,280 --> 00:12:40,480
But here's where the current architecture breaks.

378
00:12:40,480 --> 00:12:43,920
A co-pilot in VS code disappears the moment you close the editor.

379
00:12:43,920 --> 00:12:45,280
You can't get to it from your phone.

380
00:12:45,280 --> 00:12:46,640
You can't find it in teams.

381
00:12:46,640 --> 00:12:49,520
It only exists inside that one app on that one device.

382
00:12:49,520 --> 00:12:53,920
The knowledge the agent gained while looking at your code becomes useless the second you walk away from your desk.

383
00:12:53,920 --> 00:12:55,280
Every silo works this way.

384
00:12:55,280 --> 00:12:58,160
An agent in Salesforce can't be reached from a mobile app.

385
00:12:58,160 --> 00:13:00,520
An agent in Gira won't follow you to a chat.

386
00:13:00,520 --> 00:13:02,800
Each one is tethered to its own application.

387
00:13:02,800 --> 00:13:05,920
You have to manage separate relationships and separate contexts for all of them.

388
00:13:05,920 --> 00:13:07,360
This isn't a limit of the AI.

389
00:13:07,360 --> 00:13:08,240
It's a choice.

390
00:13:08,240 --> 00:13:10,400
The agent and the interface are fused together.

391
00:13:10,400 --> 00:13:12,760
If you separate the interface, you lose the agent.

392
00:13:12,760 --> 00:13:14,640
True multi-device architecture is different.

393
00:13:14,640 --> 00:13:17,040
It means the agent is not bound to a single screen.

394
00:13:17,040 --> 00:13:19,040
The intelligence and the memory live somewhere else.

395
00:13:19,040 --> 00:13:21,520
They live in a central place that you can access from anywhere.

396
00:13:21,520 --> 00:13:23,240
You use a thin client on each device.

397
00:13:23,240 --> 00:13:26,680
This is a lightweight interface that connects to the central agent runtime.

398
00:13:26,680 --> 00:13:31,080
The client on your laptop looks different than the one on your phone because they have different jobs.

399
00:13:31,080 --> 00:13:35,280
The desktop shows code side by side with analysis while the mobile app shows a summary.

400
00:13:35,280 --> 00:13:36,920
But they are both talking to the same agent.

401
00:13:36,920 --> 00:13:38,520
They share the same persistent memory.

402
00:13:38,520 --> 00:13:41,040
The GitHub co-pilot SDK shows us this pattern.

403
00:13:41,040 --> 00:13:42,280
The brain lives in the back end.

404
00:13:42,280 --> 00:13:46,080
It's a stateless runtime that scales and stays independent of the interface.

405
00:13:46,080 --> 00:13:50,000
On the front end, you have clients like VS code, the CLI or web interfaces.

406
00:13:50,000 --> 00:13:51,920
Every client connects to that same back end.

407
00:13:51,920 --> 00:13:53,560
Every client uses the same session.

408
00:13:53,560 --> 00:13:55,280
The benefit is context continuity.

409
00:13:55,280 --> 00:13:58,840
You start a problem on your laptop, the agent runs diagnostics and finds patterns.

410
00:13:58,840 --> 00:14:01,880
You save it, you move to your phone and use the same session.

411
00:14:01,880 --> 00:14:04,280
The agent resumes with everything it already discovered.

412
00:14:04,280 --> 00:14:05,480
There is no loss of context.

413
00:14:05,480 --> 00:14:06,840
There is no repeating work.

414
00:14:06,840 --> 00:14:09,680
You never have to remind the agent what you were talking about.

415
00:14:09,680 --> 00:14:10,520
It just knows.

416
00:14:10,520 --> 00:14:13,680
But this multi-device setup creates a security requirement.

417
00:14:13,680 --> 00:14:16,240
When state moves across devices, it travels over network.

418
00:14:16,240 --> 00:14:19,040
It has to be stored so multiple clients can reach it.

419
00:14:19,040 --> 00:14:22,240
It has to stay uncorrupted and protected from the wrong people.

420
00:14:22,240 --> 00:14:24,120
This is why you need a control plane.

421
00:14:24,120 --> 00:14:27,400
You need a system that sits above the agents and the devices.

422
00:14:27,400 --> 00:14:30,840
It enforces policies on who can access data and how state gets synced.

423
00:14:30,840 --> 00:14:32,920
It manages what happens if a connection fails.

424
00:14:32,920 --> 00:14:35,880
Microsoft agent 365 is trying to be this control plane.

425
00:14:35,880 --> 00:14:37,640
It isn't just a tool for managing agents.

426
00:14:37,640 --> 00:14:40,600
It's a way to govern how they work across your entire infrastructure.

427
00:14:40,600 --> 00:14:45,280
The challenge is that this requires a total rethink of how agents relate to your systems.

428
00:14:45,280 --> 00:14:48,640
Most organizations haven't started that rethink yet.

429
00:14:48,640 --> 00:14:51,160
The GitHub Copilot SDK is the blueprint.

430
00:14:51,160 --> 00:14:54,280
The GitHub Copilot SDK came out in June 2026.

431
00:14:54,280 --> 00:14:56,160
It isn't just another tool for developers.

432
00:14:56,160 --> 00:14:57,240
It's a structural pattern.

433
00:14:57,240 --> 00:15:00,000
It's a statement about how agents should actually be built.

434
00:15:00,000 --> 00:15:04,320
And right now, it's the model that every major enterprise platform is moving toward.

435
00:15:04,320 --> 00:15:06,120
But here's the problem GitHub had to solve.

436
00:15:06,120 --> 00:15:08,080
They needed one agent to work everywhere.

437
00:15:08,080 --> 00:15:09,440
It had to work in VS Code.

438
00:15:09,440 --> 00:15:10,680
It had to work on the website.

439
00:15:10,680 --> 00:15:13,280
It had to work in the command line and in custom apps.

440
00:15:13,280 --> 00:15:15,040
Every one of those environments is different.

441
00:15:15,040 --> 00:15:18,720
They have different buttons, different user habits, different ways of showing information.

442
00:15:18,720 --> 00:15:21,080
If you tried to build a separate agent for every platform.

443
00:15:21,080 --> 00:15:22,080
You'd fail.

444
00:15:22,080 --> 00:15:24,080
You would end up with seven different versions of the same brain.

445
00:15:24,080 --> 00:15:25,520
They would all start to drift apart.

446
00:15:25,520 --> 00:15:27,120
One would have a bug the others didn't.

447
00:15:27,120 --> 00:15:28,480
One would be smarter than the rest.

448
00:15:28,480 --> 00:15:29,560
It would be a mess.

449
00:15:29,560 --> 00:15:31,800
The solution was radical in its simplicity.

450
00:15:31,800 --> 00:15:34,160
You separate the intelligence from the interface.

451
00:15:34,160 --> 00:15:36,640
The core agentic harness is the part that actually thinks.

452
00:15:36,640 --> 00:15:37,640
It makes the decisions.

453
00:15:37,640 --> 00:15:39,680
It breaks big problems into small steps.

454
00:15:39,680 --> 00:15:41,720
And that brain lives in exactly one place.

455
00:15:41,720 --> 00:15:42,720
It's built once.

456
00:15:42,720 --> 00:15:43,720
It doesn't care what language you use.

457
00:15:43,720 --> 00:15:44,720
The runtime is portable.

458
00:15:44,720 --> 00:15:49,200
Whether you run it on node.js, Python or Go, you get the exact same behavior.

459
00:15:49,200 --> 00:15:52,160
You get the same reasoning and the same results every single time.

460
00:15:52,160 --> 00:15:54,880
Then on every platform, you just have a thin client.

461
00:15:54,880 --> 00:15:58,320
The VS code extension doesn't actually have any agent logic inside it.

462
00:15:58,320 --> 00:16:00,840
It doesn't manage context or make decisions.

463
00:16:00,840 --> 00:16:01,840
It's just a window.

464
00:16:01,840 --> 00:16:02,960
It opens a connection to the backend.

465
00:16:02,960 --> 00:16:03,960
It sends a prompt.

466
00:16:03,960 --> 00:16:04,960
It gets an answer.

467
00:16:04,960 --> 00:16:07,760
Then it shows that answer in a way that makes sense for a code editor.

468
00:16:07,760 --> 00:16:08,960
The CLI is the same way.

469
00:16:08,960 --> 00:16:10,560
It isn't reinventing the agent.

470
00:16:10,560 --> 00:16:12,600
It's just a different way of talking to the same brain.

471
00:16:12,600 --> 00:16:14,080
It uses text instead of graphics.

472
00:16:14,080 --> 00:16:16,160
But the intelligence behind the screen is identical.

473
00:16:16,160 --> 00:16:17,440
This matters more than it sounds.

474
00:16:17,440 --> 00:16:19,080
It means you don't have version drift.

475
00:16:19,080 --> 00:16:22,680
You don't have an agent in your editor acting differently than the one in your browser.

476
00:16:22,680 --> 00:16:23,840
You have one agent.

477
00:16:23,840 --> 00:16:25,480
And multiple ways to talk to it.

478
00:16:25,480 --> 00:16:26,640
One source of truth.

479
00:16:26,640 --> 00:16:28,760
Session management is baked right into the SDK.

480
00:16:28,760 --> 00:16:30,680
It isn't something you have to bolt on later.

481
00:16:30,680 --> 00:16:34,560
The SDK handles session IDs and state recovery as a core feature.

482
00:16:34,560 --> 00:16:36,800
When you start a chat, it's persistent by default.

483
00:16:36,800 --> 00:16:38,040
You don't have to turn it on.

484
00:16:38,040 --> 00:16:39,400
You don't have to configure it.

485
00:16:39,400 --> 00:16:40,400
It just works.

486
00:16:40,400 --> 00:16:42,520
Tool calling is standardized too.

487
00:16:42,520 --> 00:16:45,480
Every agent uses the same pattern to talk to outside systems.

488
00:16:45,480 --> 00:16:48,120
You aren't reinventing the wheel for every new use case.

489
00:16:48,120 --> 00:16:50,760
You define your tools once, like APIs or scripts.

490
00:16:50,760 --> 00:16:52,040
And then any client can use them.

491
00:16:52,040 --> 00:16:53,160
The interface is clean.

492
00:16:53,160 --> 00:16:54,440
The implementation is standard.

493
00:16:54,440 --> 00:16:56,200
You get total consistency.

494
00:16:56,200 --> 00:16:59,040
What GitHub discovered is that you can build a universal agent.

495
00:16:59,040 --> 00:17:00,560
Not an agent that does everything.

496
00:17:00,560 --> 00:17:02,000
But an agent that can go anywhere.

497
00:17:02,000 --> 00:17:05,360
The same code and the same logic can be deployed to any device or app.

498
00:17:05,360 --> 00:17:06,360
This is the blueprint.

499
00:17:06,360 --> 00:17:08,880
This is what organizations should be studying.

500
00:17:08,880 --> 00:17:12,240
Because in reality, this is what an enterprise platform is supposed to look like.

501
00:17:12,240 --> 00:17:15,560
You shouldn't have 100 separate agents stuck in a hundred different apps.

502
00:17:15,560 --> 00:17:17,400
You need one coordinated fabric.

503
00:17:17,400 --> 00:17:18,400
It gets an interface.

504
00:17:18,400 --> 00:17:19,400
Excel gets an interface.

505
00:17:19,400 --> 00:17:21,000
Teams and Outlook get interfaces.

506
00:17:21,000 --> 00:17:23,520
But they are all talking to the same underlying intelligence.

507
00:17:23,520 --> 00:17:25,240
This is what Microsoft is doing right now.

508
00:17:25,240 --> 00:17:29,520
They are pulling co-pilot studio and Azure AI Foundry together around the same harness.

509
00:17:29,520 --> 00:17:32,520
It's why they're moving toward agent 365 as a control plane.

510
00:17:32,520 --> 00:17:34,480
They are applying the lesson GitHub learned.

511
00:17:34,480 --> 00:17:35,480
Build the brain once.

512
00:17:35,480 --> 00:17:36,720
Standardize how it connects.

513
00:17:36,720 --> 00:17:38,560
Let different apps show it in different ways.

514
00:17:38,560 --> 00:17:41,000
The result is profound if you understand this pattern.

515
00:17:41,000 --> 00:17:43,400
You can build infrastructure that actually scales.

516
00:17:43,400 --> 00:17:47,240
If you don't, if you try to glue a new agent into every single app, you'll end up

517
00:17:47,240 --> 00:17:48,480
with a fragmented nightmare.

518
00:17:48,480 --> 00:17:51,360
The SDK proves you can have both consistency and flexibility.

519
00:17:51,360 --> 00:17:53,600
You get a single brain, but you can't put it anywhere.

520
00:17:53,600 --> 00:17:54,600
That's the blueprint.

521
00:17:54,600 --> 00:17:55,680
That's where we're going.

522
00:17:55,680 --> 00:17:57,000
Identity as the foundation.

523
00:17:57,000 --> 00:18:00,280
Building the blueprint is a start, but making it work in a real company requires something

524
00:18:00,280 --> 00:18:01,280
deeper.

525
00:18:01,280 --> 00:18:02,520
It requires identity.

526
00:18:02,520 --> 00:18:04,360
An agent without an identity is a ghost.

527
00:18:04,360 --> 00:18:05,360
You can't audit it.

528
00:18:05,360 --> 00:18:06,360
You can't control it.

529
00:18:06,360 --> 00:18:07,440
You can't govern it.

530
00:18:07,440 --> 00:18:10,000
When something breaks, you have no way to see which agent did it.

531
00:18:10,000 --> 00:18:12,720
When things change, you have no way to take away its permissions.

532
00:18:12,720 --> 00:18:14,200
It exists in your system.

533
00:18:14,200 --> 00:18:16,240
But it's invisible to your security.

534
00:18:16,240 --> 00:18:18,520
Most organizations are making this mistake right now.

535
00:18:18,520 --> 00:18:19,920
They use shared service accounts.

536
00:18:19,920 --> 00:18:22,600
They have one agent in Salesforce and another in JIRA.

537
00:18:22,600 --> 00:18:25,800
But they both log in as the same generic integration user.

538
00:18:25,800 --> 00:18:28,160
From a security standpoint, this is a structural flaw.

539
00:18:28,160 --> 00:18:30,520
From a governance standpoint, it's a disaster.

540
00:18:30,520 --> 00:18:31,520
Here's why.

541
00:18:31,520 --> 00:18:34,840
When an agent uses a generic account, you lose the ability to see who did what.

542
00:18:34,840 --> 00:18:37,800
A file gets changed, a process starts, and email goes out.

543
00:18:37,800 --> 00:18:40,160
But your logs don't show that agent A did it.

544
00:18:40,160 --> 00:18:42,440
They just show that the integration account did it.

545
00:18:42,440 --> 00:18:43,440
That could be agent A.

546
00:18:43,440 --> 00:18:44,440
It could be agent B.

547
00:18:44,440 --> 00:18:45,440
It could even be a human admin.

548
00:18:45,440 --> 00:18:46,560
You have no way to know.

549
00:18:46,560 --> 00:18:48,720
Now imagine this with thousands of agents.

550
00:18:48,720 --> 00:18:50,840
Your audit trails become completely useless.

551
00:18:50,840 --> 00:18:53,440
You can't find out which agent caused the security breach.

552
00:18:53,440 --> 00:18:55,160
You can't set rules for one specific agent.

553
00:18:55,160 --> 00:18:59,440
You can't even turn off one bad agent without breaking every other system using that same account.

554
00:18:59,440 --> 00:19:03,280
The answer is to treat agents like people, give every single one its own identity.

555
00:19:03,280 --> 00:19:05,680
In Microsoft's world, that's an ENTRA agent ID.

556
00:19:05,680 --> 00:19:07,680
It's a first class identity in your directory.

557
00:19:07,680 --> 00:19:08,680
It isn't a service account.

558
00:19:08,680 --> 00:19:10,200
It isn't a shared password.

559
00:19:10,200 --> 00:19:13,280
It's an identity that belongs to that specific agent and nobody else.

560
00:19:13,280 --> 00:19:14,720
This changes everything.

561
00:19:14,720 --> 00:19:18,520
Once an agent has an identity, you can use every security tool you already own.

562
00:19:18,520 --> 00:19:20,120
You can use conditional access.

563
00:19:20,120 --> 00:19:21,840
You can use role-based permissions.

564
00:19:21,840 --> 00:19:24,920
You can use data loss prevention and sensitivity labels.

565
00:19:24,920 --> 00:19:27,320
Everything you use for humans suddenly works for agents.

566
00:19:27,320 --> 00:19:32,120
You can say, this agent can read the finance database, but only during work hours, and only

567
00:19:32,120 --> 00:19:34,000
for certain records.

568
00:19:34,000 --> 00:19:36,880
You can enforce that at the identity layer, you can say.

569
00:19:36,880 --> 00:19:40,720
This agent can send emails, but only to people inside the company, and only if a human

570
00:19:40,720 --> 00:19:43,120
says, okay, you can set that as a rule.

571
00:19:43,120 --> 00:19:46,920
If an agent starts acting up, you can kill its access instantly without touching anything

572
00:19:46,920 --> 00:19:47,920
else.

573
00:19:47,920 --> 00:19:51,120
Identity is also what makes auditing possible, when an agent has its own ID.

574
00:19:51,120 --> 00:19:53,400
Every action it takes gets logged under its own name.

575
00:19:53,400 --> 00:19:55,120
You can see exactly what it did.

576
00:19:55,120 --> 00:19:57,600
You can trace a chain of events back to one specific source.

577
00:19:57,600 --> 00:20:00,440
You can prove your compliant because you have the receipts.

578
00:20:00,440 --> 00:20:03,120
From an operational view, this means agents have a life cycle.

579
00:20:03,120 --> 00:20:04,680
You provision them when they start.

580
00:20:04,680 --> 00:20:06,400
You manage their access as they grow.

581
00:20:06,400 --> 00:20:07,880
You delete them when they're done.

582
00:20:07,880 --> 00:20:10,320
You can change their credentials without hurting other agents.

583
00:20:10,320 --> 00:20:12,240
Each one is its own entity.

584
00:20:12,240 --> 00:20:15,080
In 365, treats identity as a core object.

585
00:20:15,080 --> 00:20:16,080
It isn't an afterthought.

586
00:20:16,080 --> 00:20:17,880
It isn't something you do if you have extra time.

587
00:20:17,880 --> 00:20:21,640
It's a first class citizen in your directory, sitting right next to your human users.

588
00:20:21,640 --> 00:20:24,600
The problem is that most companies haven't changed their mental model yet.

589
00:20:24,600 --> 00:20:26,640
They still think of agents as tools.

590
00:20:26,640 --> 00:20:27,640
Not as participants.

591
00:20:27,640 --> 00:20:30,640
They don't realize that an agent needs the same foundation as a person.

592
00:20:30,640 --> 00:20:32,760
That shift in thinking is just starting to happen.

593
00:20:32,760 --> 00:20:36,200
But the companies that get their first are going to have a massive lead in security and

594
00:20:36,200 --> 00:20:37,200
control.

595
00:20:37,200 --> 00:20:38,520
Identity is the foundation.

596
00:20:38,520 --> 00:20:41,440
Everything else is just built on top of it.

597
00:20:41,440 --> 00:20:42,720
The orchestration problem.

598
00:20:42,720 --> 00:20:44,520
Now we have an agent with an identity.

599
00:20:44,520 --> 00:20:46,160
It stays with you across devices.

600
00:20:46,160 --> 00:20:48,800
It has a state that survives every restart.

601
00:20:48,800 --> 00:20:51,080
But we've hit a hard limit that most people ignore.

602
00:20:51,080 --> 00:20:52,320
And that limit is scope.

603
00:20:52,320 --> 00:20:56,400
A single agent cannot solve a complex business process from start to finish.

604
00:20:56,400 --> 00:20:58,280
It doesn't matter how intelligent the model is.

605
00:20:58,280 --> 00:21:01,320
Think about what happens when a customer files a support ticket.

606
00:21:01,320 --> 00:21:03,960
Resolving that one ticket requires several specialized skills.

607
00:21:03,960 --> 00:21:07,000
You need someone to validate the issue and make sure it's legitimate.

608
00:21:07,000 --> 00:21:10,080
You need someone to dig through the knowledge base for a fix.

609
00:21:10,080 --> 00:21:13,040
You need someone to check the warehouse inventory for a replacement.

610
00:21:13,040 --> 00:21:15,600
You might even need finance to approve a refund.

611
00:21:15,600 --> 00:21:18,240
And then someone has to wrap it all up and talk to the customer.

612
00:21:18,240 --> 00:21:20,000
That is five different domains of expertise.

613
00:21:20,000 --> 00:21:23,160
It involves five different systems and five different data sources.

614
00:21:23,160 --> 00:21:27,600
Technically, you could give one agent access to every system and dump all that data into

615
00:21:27,600 --> 00:21:28,920
its context window.

616
00:21:28,920 --> 00:21:30,880
But in reality, that is a recipe for failure.

617
00:21:30,880 --> 00:21:31,880
The agent gets confused.

618
00:21:31,880 --> 00:21:33,280
The context becomes too heavy.

619
00:21:33,280 --> 00:21:35,000
The decision making turns incoherent.

620
00:21:35,000 --> 00:21:39,040
It's like asking one person to be your accountant, your lead engineer, your lawyer and your

621
00:21:39,040 --> 00:21:40,720
surgeon all at the same time.

622
00:21:40,720 --> 00:21:42,400
The answer is specialization.

623
00:21:42,400 --> 00:21:45,280
You build a support agent that only understands tickets.

624
00:21:45,280 --> 00:21:48,600
You build a knowledge agent that only searches documentation.

625
00:21:48,600 --> 00:21:53,400
You set up an inventory agent to check stock and a finance agent to evaluate refunds.

626
00:21:53,400 --> 00:21:55,960
Each one is laser focused on its own domain.

627
00:21:55,960 --> 00:21:59,440
Each one is optimized for the specific type of reasoning it needs to do.

628
00:21:59,440 --> 00:22:00,920
But now you've created a new problem.

629
00:22:00,920 --> 00:22:04,360
If you have five specialized agents, how do they actually work together?

630
00:22:04,360 --> 00:22:07,280
How does the support agent hand off the task to inventory?

631
00:22:07,280 --> 00:22:10,060
How does the inventory agent pass its findings over to finance?

632
00:22:10,060 --> 00:22:12,780
How does finance know if they should even approve the request?

633
00:22:12,780 --> 00:22:14,000
The answer isn't more chat.

634
00:22:14,000 --> 00:22:17,360
You can't just hope these agents figure out how to talk to each other organically.

635
00:22:17,360 --> 00:22:19,680
What you need is explicit orchestration.

636
00:22:19,680 --> 00:22:22,680
Orchestration means one agent takes responsibility for the entire process.

637
00:22:22,680 --> 00:22:25,840
It breaks the work into steps and assigns those steps to the specialists.

638
00:22:25,840 --> 00:22:28,600
This coordinator agent understands the overall workflow.

639
00:22:28,600 --> 00:22:31,400
It knows the exact sequence of decisions that needs to happen.

640
00:22:31,400 --> 00:22:34,480
It takes that customer request and splits it into sub tasks.

641
00:22:34,480 --> 00:22:38,680
To validate the issue, search for solutions, check the stock and evaluate the refund.

642
00:22:38,680 --> 00:22:43,080
Then it hands off to each specialist in order, passing along only the context that specialist needs

643
00:22:43,080 --> 00:22:44,560
and collecting the results.

644
00:22:44,560 --> 00:22:45,800
The pattern looks like this.

645
00:22:45,800 --> 00:22:47,480
The coordinator agent receives the ticket.

646
00:22:47,480 --> 00:22:49,560
It tells the support agent to analyze the issue.

647
00:22:49,560 --> 00:22:51,800
The support agent responds with an analysis.

648
00:22:51,800 --> 00:22:55,920
The coordinator then passes that analysis to the knowledge agent and asks for a solution.

649
00:22:55,920 --> 00:22:57,480
The knowledge agent returns a fix.

650
00:22:57,480 --> 00:23:00,760
The coordinator looks at that fix and realizes it needs inventory data.

651
00:23:00,760 --> 00:23:03,880
It asks the inventory agent if a replacement is available.

652
00:23:03,880 --> 00:23:05,960
The inventory agent returns the stock status.

653
00:23:05,960 --> 00:23:08,840
Now the coordinator has enough info to move to the final step.

654
00:23:08,840 --> 00:23:11,640
It asks the finance agent if a refund fits the policy.

655
00:23:11,640 --> 00:23:13,360
The finance agent makes the call.

656
00:23:13,360 --> 00:23:15,440
At every step, the context flows forward.

657
00:23:15,440 --> 00:23:17,360
The support analysis informs the search.

658
00:23:17,360 --> 00:23:19,120
The search informs the inventory check.

659
00:23:19,120 --> 00:23:21,800
The inventory status informs the finance decision.

660
00:23:21,800 --> 00:23:22,800
The decisions compound.

661
00:23:22,800 --> 00:23:24,400
The reasoning stays coherent.

662
00:23:24,400 --> 00:23:26,800
And most importantly, there is a clear chain of accountability.

663
00:23:26,800 --> 00:23:28,680
The coordinator owns the workflow.

664
00:23:28,680 --> 00:23:30,920
Each specialist owns its specific decision.

665
00:23:30,920 --> 00:23:33,160
This sounds straight forward because it is.

666
00:23:33,160 --> 00:23:36,280
It requires something most agent architectures don't support yet.

667
00:23:36,280 --> 00:23:37,680
You need explicit handoff rules.

668
00:23:37,680 --> 00:23:39,400
You need clear ownership boundaries.

669
00:23:39,400 --> 00:23:43,440
You need shared memory that stays intact as the task moves from one agent to the next.

670
00:23:43,440 --> 00:23:47,600
You have to define exactly when the coordinator should hand off to a specialist.

671
00:23:47,600 --> 00:23:50,200
You have to decide what information passes between them.

672
00:23:50,200 --> 00:23:53,920
You have to plan for what happens if a specialist fails or returns something weird.

673
00:23:53,920 --> 00:23:57,600
You even have to figure out how to handle two agents disagreeing on the path forward.

674
00:23:57,600 --> 00:23:59,600
This is where organizations typically fail.

675
00:23:59,600 --> 00:24:02,120
They deploy a bunch of agents without any orchestration layer.

676
00:24:02,120 --> 00:24:03,760
Each agent just operates on its own.

677
00:24:03,760 --> 00:24:04,760
There is no coordinator.

678
00:24:04,760 --> 00:24:06,240
There is no handoff mechanism.

679
00:24:06,240 --> 00:24:08,160
There is no way for them to actually collaborate.

680
00:24:08,160 --> 00:24:10,480
So you end up with a flat network of agents.

681
00:24:10,480 --> 00:24:12,680
And the humans still have to do all the integration work.

682
00:24:12,680 --> 00:24:16,080
The real architecture requires treating orchestration as a first class concern.

683
00:24:16,080 --> 00:24:17,680
It isn't something you add later.

684
00:24:17,680 --> 00:24:20,120
It's something you design for from the very beginning.

685
00:24:20,120 --> 00:24:22,240
Memory as a governance asset.

686
00:24:22,240 --> 00:24:25,400
This is where persistent agent architecture becomes genuinely dangerous.

687
00:24:25,400 --> 00:24:28,880
When agents only exist for a single conversation, the damage they can do is limited.

688
00:24:28,880 --> 00:24:29,880
The chat ends.

689
00:24:29,880 --> 00:24:31,040
The context disappears.

690
00:24:31,040 --> 00:24:34,680
Even if something goes wrong, the mess is localized to that one exchange.

691
00:24:34,680 --> 00:24:37,240
But persistent agents carry their memory forward.

692
00:24:37,240 --> 00:24:39,680
They collect information over days, weeks and months.

693
00:24:39,680 --> 00:24:43,640
That accumulated memory becomes the foundation for every decision they make.

694
00:24:43,640 --> 00:24:45,720
And that is both the feature and the liability.

695
00:24:45,720 --> 00:24:47,040
The feature is obvious.

696
00:24:47,040 --> 00:24:50,280
An agent that remembers your past decisions can build on top of them.

697
00:24:50,280 --> 00:24:51,640
It doesn't repeat work.

698
00:24:51,640 --> 00:24:54,000
It doesn't ask you the same annoying question twice.

699
00:24:54,000 --> 00:24:55,680
It keeps the context alive over time.

700
00:24:55,680 --> 00:24:57,800
That is what makes persistence so valuable.

701
00:24:57,800 --> 00:25:01,680
It is what allows an agent to work on a three-week project and actually understand the goal.

702
00:25:01,680 --> 00:25:05,160
But the liability is something most organizations haven't thought through.

703
00:25:05,160 --> 00:25:06,160
Memory can be poisoned.

704
00:25:06,160 --> 00:25:08,000
This is a direct attack vector.

705
00:25:08,000 --> 00:25:10,360
An attacker doesn't need to break into the agent's code.

706
00:25:10,360 --> 00:25:14,280
They just need to get malicious content into something the agent reads and stores as a memory.

707
00:25:14,280 --> 00:25:16,520
It could be a document with hidden instructions.

708
00:25:16,520 --> 00:25:18,400
It could be an email with a secret directive.

709
00:25:18,400 --> 00:25:22,400
It could even be a chat message that looks totally innocent, but contains a prompt injection.

710
00:25:22,400 --> 00:25:25,880
The agent processes that content and writes it into its memory as a fact.

711
00:25:25,880 --> 00:25:27,200
It stores it as context.

712
00:25:27,200 --> 00:25:29,200
It treats it as guidance for the future.

713
00:25:29,200 --> 00:25:33,120
Then, weeks later, the agent retrieves that memory to help with a different decision.

714
00:25:33,120 --> 00:25:35,560
The Poisoned Instruction resurfaces, the agent follows it.

715
00:25:35,560 --> 00:25:37,240
It takes an action it shouldn't take.

716
00:25:37,240 --> 00:25:39,560
It ignores a safeguard it was supposed to respect.

717
00:25:39,560 --> 00:25:43,060
And by that point, the original poison is buried so deep in the memory store that you

718
00:25:43,060 --> 00:25:44,060
can't see it.

719
00:25:44,060 --> 00:25:46,240
The attack is invisible until the consequences show up.

720
00:25:46,240 --> 00:25:48,120
The second liability is leakage.

721
00:25:48,120 --> 00:25:49,640
Persistent memory gets shared.

722
00:25:49,640 --> 00:25:52,360
An agent pulls information from one system and saves it.

723
00:25:52,360 --> 00:25:56,640
Later, that agent hands off a task to another agent and passes along the context.

724
00:25:56,640 --> 00:26:00,720
Now the sensitive data from that first system is flowing into the second agent's memory.

725
00:26:00,720 --> 00:26:01,960
Eventually, it flows to a third.

726
00:26:01,960 --> 00:26:06,320
At every handoff, the boundary of what is restricted gets a little blurrier.

727
00:26:06,320 --> 00:26:10,120
Data meant for one specific context quietly becomes available in another.

728
00:26:10,120 --> 00:26:12,880
This happens at scale without anyone even trying to do it.

729
00:26:12,880 --> 00:26:16,000
Nobody planned to leak customer data across 10 different systems.

730
00:26:16,000 --> 00:26:20,440
The architecture just naturally moves information around as agents share context.

731
00:26:20,440 --> 00:26:24,000
Once that data is sitting in the memories of five different agents, you have lost control

732
00:26:24,000 --> 00:26:25,000
of it.

733
00:26:25,000 --> 00:26:26,320
The problem is retention.

734
00:26:26,320 --> 00:26:28,760
How long should an agent actually remember something?

735
00:26:28,760 --> 00:26:33,160
If it's forever, you have an unlimited privacy exposure and a massive storage liability.

736
00:26:33,160 --> 00:26:35,840
If it's only for a few days, you lose the benefit of persistence.

737
00:26:35,840 --> 00:26:37,360
You need explicit policies.

738
00:26:37,360 --> 00:26:39,760
You have to define what gets kept and for how long.

739
00:26:39,760 --> 00:26:41,240
But here is the challenge.

740
00:26:41,240 --> 00:26:42,800
Deleting isn't the same as forgetting.

741
00:26:42,800 --> 00:26:46,920
If information is baked into a vector embedding or a graph structure, deleting the raw text

742
00:26:46,920 --> 00:26:47,920
isn't enough.

743
00:26:47,920 --> 00:26:51,320
You would have to rebuild the entire memory structure to truly get rid of it.

744
00:26:51,320 --> 00:26:53,680
Most organizations simply don't have the tools for that.

745
00:26:53,680 --> 00:26:57,320
From a security perspective, this means agent memory must be treated like a database.

746
00:26:57,320 --> 00:26:58,920
It isn't just a chat history.

747
00:26:58,920 --> 00:27:00,400
It isn't a temporary workspace.

748
00:27:00,400 --> 00:27:01,720
It is a genuine data asset.

749
00:27:01,720 --> 00:27:02,880
It needs access controls.

750
00:27:02,880 --> 00:27:04,120
It needs audit logs.

751
00:27:04,120 --> 00:27:06,400
It needs validation gates and integrity checks.

752
00:27:06,400 --> 00:27:11,280
You need encryption, backups and recovery procedures, just like any other critical system.

753
00:27:11,280 --> 00:27:13,800
From a compliance perspective, the rules are even sharper.

754
00:27:13,800 --> 00:27:18,920
GDPR and data privacy laws apply to agent memory, just like they apply to a SQL database.

755
00:27:18,920 --> 00:27:21,440
An agent cannot just hold information forever.

756
00:27:21,440 --> 00:27:24,000
It needs a legitimate reason to remember a specific fact.

757
00:27:24,000 --> 00:27:26,440
The person whose data is being stored has rights.

758
00:27:26,440 --> 00:27:29,800
The right to see it, the right to fix it and the right to delete it.

759
00:27:29,800 --> 00:27:32,840
Regulators are going to expect you to show them how you remove a person's data from an

760
00:27:32,840 --> 00:27:33,840
agent's mind.

761
00:27:33,840 --> 00:27:37,280
That becomes incredibly hard when that data is buried in a memory store that's being used

762
00:27:37,280 --> 00:27:39,280
to inform other models and other decisions.

763
00:27:39,280 --> 00:27:43,440
The reality is that most organizations have zero framework for memory governance.

764
00:27:43,440 --> 00:27:45,560
They have no rules on what agents should remember.

765
00:27:45,560 --> 00:27:47,720
They have no way to check if a memory is valid.

766
00:27:47,720 --> 00:27:51,360
They have no audit logs and no way to delete info when a customer asks.

767
00:27:51,360 --> 00:27:52,920
This is the gap that has to be closed.

768
00:27:52,920 --> 00:27:54,320
It isn't about technical wizardry.

769
00:27:54,320 --> 00:27:58,360
It's about building a deliberate governance framework that treats persistent memory as the

770
00:27:58,360 --> 00:28:00,720
liability it actually is.

771
00:28:00,720 --> 00:28:03,920
The cost curve, why always on agents are expensive.

772
00:28:03,920 --> 00:28:06,160
Most people hear this number and think it's a typo.

773
00:28:06,160 --> 00:28:11,600
And always on agent that thinks in the background costs between $200,000 and $600,000 every year,

774
00:28:11,600 --> 00:28:13,520
just to run that isn't the cost to build it.

775
00:28:13,520 --> 00:28:14,680
That is the cost to operate it.

776
00:28:14,680 --> 00:28:18,520
This isn't a bug in the software or a mistake in how vendors set their prices.

777
00:28:18,520 --> 00:28:21,440
It is a structural reality of how a gentick architecture works.

778
00:28:21,440 --> 00:28:25,120
Most companies don't see this coming because they are still in the honeymoon phase and the

779
00:28:25,120 --> 00:28:28,240
small pilots they're running keep the real costs hidden.

780
00:28:28,240 --> 00:28:29,840
But here is why the bill gets so high.

781
00:28:29,840 --> 00:28:32,520
When an agent is always on, it is never actually idle.

782
00:28:32,520 --> 00:28:36,200
It is constantly looping, reading and retrieving context to make decisions.

783
00:28:36,200 --> 00:28:39,600
Every single one of those actions costs compute power and tokens.

784
00:28:39,600 --> 00:28:43,920
Tokens are the actual currency of these models and you pay for every thousand you use.

785
00:28:43,920 --> 00:28:47,440
You might have heard that token prices are dropping, but that doesn't matter if your total

786
00:28:47,440 --> 00:28:48,920
consumption is skyrocketing.

787
00:28:48,920 --> 00:28:50,240
The breakdown is pretty clear.

788
00:28:50,240 --> 00:28:54,280
Token consumption makes of about 70% of what it costs to run a persistent agent.

789
00:28:54,280 --> 00:28:58,320
You aren't paying for the model itself, but for the provider to process those tokens.

790
00:28:58,320 --> 00:29:02,440
At current rates, a background agent can easily burn through 30 to 40 million tokens in

791
00:29:02,440 --> 00:29:04,120
a single day.

792
00:29:04,120 --> 00:29:07,440
That isn't an exaggeration, it is what we see in real world deployments.

793
00:29:07,440 --> 00:29:11,120
The reason the token count explodes is something called the token multiplier.

794
00:29:11,120 --> 00:29:14,680
Every time an agent loops to think about its next step, it has to reread everything.

795
00:29:14,680 --> 00:29:18,760
It rereads the task, the prior decisions and all the info it already found.

796
00:29:18,760 --> 00:29:20,640
Each loop processes that context again.

797
00:29:20,640 --> 00:29:24,640
If a task takes dozens of loops, the agent reads the same data dozens of times.

798
00:29:24,640 --> 00:29:29,320
One kilobyte of context can turn into 30 kilobytes of paid tokens just because of those repeated

799
00:29:29,320 --> 00:29:30,320
reads.

800
00:29:30,320 --> 00:29:32,640
The second cost driver is the infrastructure.

801
00:29:32,640 --> 00:29:35,840
Persistent agents cannot run on shared, temporary compute.

802
00:29:35,840 --> 00:29:39,840
You need a place to store the session state, keep audit logs and sync memory across different

803
00:29:39,840 --> 00:29:40,840
devices.

804
00:29:40,840 --> 00:29:44,640
That means you are paying for databases and storage systems that never scale down to zero.

805
00:29:44,640 --> 00:29:47,520
You pay for them whether the agent is working or just waiting.

806
00:29:47,520 --> 00:29:52,240
When you scale up to thousands of sessions, those infrastructure costs become a massive burden.

807
00:29:52,240 --> 00:29:53,760
The third driver is observability.

808
00:29:53,760 --> 00:29:55,560
You cannot let these agents run in the dark.

809
00:29:55,560 --> 00:29:58,880
You have to log every decision, every tool call and every error they make.

810
00:29:58,880 --> 00:30:01,520
If something breaks, you need to know exactly why it happened.

811
00:30:01,520 --> 00:30:05,800
But logging at that level creates a mountain of data that you have to store an index.

812
00:30:05,800 --> 00:30:09,360
It has to be searchable for compliance and that infrastructure adds another layer to

813
00:30:09,360 --> 00:30:10,360
the bill.

814
00:30:10,360 --> 00:30:11,960
The fourth cost is the human element.

815
00:30:11,960 --> 00:30:14,400
Someone has to watch these systems and debug them when they fail.

816
00:30:14,400 --> 00:30:18,120
You have to tune the prompts and update the policies as the business changes.

817
00:30:18,120 --> 00:30:19,720
You aren't actually cutting headcount here.

818
00:30:19,720 --> 00:30:22,920
You are just shifting people from doing the work to managing the machines that do the work

819
00:30:22,920 --> 00:30:24,680
and you are still paying for those hours.

820
00:30:24,680 --> 00:30:25,800
And here is the problem.

821
00:30:25,800 --> 00:30:26,800
None of this is optional.

822
00:30:26,800 --> 00:30:29,720
You can't just cut out the logging or the storage to save a few bucks.

823
00:30:29,720 --> 00:30:33,160
You cannot run a persistent agent without persistent infrastructure.

824
00:30:33,160 --> 00:30:34,600
These aren't extra features.

825
00:30:34,600 --> 00:30:36,960
They are the requirements for the system to function.

826
00:30:36,960 --> 00:30:38,920
So how do you actually survive this cost curve?

827
00:30:38,920 --> 00:30:40,240
The answer is model routing.

828
00:30:40,240 --> 00:30:41,520
The idea is simple.

829
00:30:41,520 --> 00:30:44,440
But every decision needs a massive frontier model like GPT-4.

830
00:30:44,440 --> 00:30:48,280
Routine work, like sorting data or simple text changes can be handled by much smaller

831
00:30:48,280 --> 00:30:49,280
cheaper models.

832
00:30:49,280 --> 00:30:53,160
You route the easy stuff to the cheap models and save the expensive ones for the high stakes

833
00:30:53,160 --> 00:30:54,160
reasoning.

834
00:30:54,160 --> 00:30:59,000
Organizations that use smart model routing end up paying 40 to 85% less than those using

835
00:30:59,000 --> 00:31:00,400
one model for everything.

836
00:31:00,400 --> 00:31:01,920
This isn't just a small tweak.

837
00:31:01,920 --> 00:31:04,120
It is the only way to make the system sustainable.

838
00:31:04,120 --> 00:31:06,400
But model routing doesn't just happen on its own.

839
00:31:06,400 --> 00:31:08,000
An agent won't figure this out for you.

840
00:31:08,000 --> 00:31:11,240
It requires you to make specific architectural choices from the start.

841
00:31:11,240 --> 00:31:14,960
You have to decide which tasks go where and build the logic to handle those shifts in real

842
00:31:14,960 --> 00:31:15,960
time.

843
00:31:15,960 --> 00:31:19,240
You have to monitor it to make sure the cheap models are actually doing a good job.

844
00:31:19,240 --> 00:31:22,280
This is why managing cost is now a core part of the architecture.

845
00:31:22,280 --> 00:31:25,160
You can't build the agent now and worry about the bill later.

846
00:31:25,160 --> 00:31:28,920
The cost has to shape how you build it from day one.

847
00:31:28,920 --> 00:31:31,040
Model routing as an economic necessity.

848
00:31:31,040 --> 00:31:34,840
In most companies, the deployment of agents follows a predictable expensive pattern.

849
00:31:34,840 --> 00:31:39,000
They pick a top tier model like GPT-4 or Claude and tell every agent to use it for every

850
00:31:39,000 --> 00:31:40,000
single task.

851
00:31:40,000 --> 00:31:43,440
It doesn't matter if it's complex reasoning or just simple data entry.

852
00:31:43,440 --> 00:31:46,520
Everything goes to the same place because it's easy to set up and the big models are

853
00:31:46,520 --> 00:31:47,520
good at everything.

854
00:31:47,520 --> 00:31:49,360
This approach is an economic disaster.

855
00:31:49,360 --> 00:31:52,120
The assumption behind it is fundamentally flawed.

856
00:31:52,120 --> 00:31:55,800
Not every task is equally hard and they don't all need the same level of brain power.

857
00:31:55,800 --> 00:31:59,040
When you send everything to a frontier model, you are essentially hiring a world-class

858
00:31:59,040 --> 00:32:02,680
consultant to answer your emails and schedule your calendar.

859
00:32:02,680 --> 00:32:07,240
You are using maximum power for minimum complexity and you are burning money every second.

860
00:32:07,240 --> 00:32:09,560
The model that actually works is very straightforward.

861
00:32:09,560 --> 00:32:14,080
To identify what the agents need to do and find the cheapest model that can do it well.

862
00:32:14,080 --> 00:32:16,240
Simple classification goes to a small model.

863
00:32:16,240 --> 00:32:18,680
Basic data extraction goes to a cheap alternative.

864
00:32:18,680 --> 00:32:22,640
You only use the frontier models for the complex novel problems where that extra power actually

865
00:32:22,640 --> 00:32:23,640
matters.

866
00:32:23,640 --> 00:32:27,600
It sounds obvious, but it requires work that most organizations are skipping.

867
00:32:27,600 --> 00:32:29,960
First you need a way to sort the work as it comes in.

868
00:32:29,960 --> 00:32:33,680
The agent has to look at a task and decide where to send it before it even starts.

869
00:32:33,680 --> 00:32:35,560
This requires a dedicated routing layer.

870
00:32:35,560 --> 00:32:40,080
Some people use a small classifier model for this, while others use specific rules.

871
00:32:40,080 --> 00:32:43,120
The method doesn't matter as much as the fact that the decision is intentional.

872
00:32:43,120 --> 00:32:45,280
Second, you have to test those decisions.

873
00:32:45,280 --> 00:32:48,520
If you send a task to a smaller model, is the quality still there?

874
00:32:48,520 --> 00:32:52,480
You need clear metrics to compare that output to what the expensive model would have done.

875
00:32:52,480 --> 00:32:55,800
You have to find the breaking point where the cheap model starts to fail so you know where

876
00:32:55,800 --> 00:32:56,800
the limit is.

877
00:32:56,800 --> 00:32:58,640
Third, you need explicit routing policies.

878
00:32:58,640 --> 00:33:00,840
This is the governance part that people often miss.

879
00:33:00,840 --> 00:33:02,480
These policies aren't just technical.

880
00:33:02,480 --> 00:33:04,280
They reflect your business risks.

881
00:33:04,280 --> 00:33:08,520
You might decide that anything customer facing always goes to the best model because an error

882
00:33:08,520 --> 00:33:10,000
there is too expensive.

883
00:33:10,000 --> 00:33:12,560
Meanwhile internal reports can use the cheaper options.

884
00:33:12,560 --> 00:33:14,080
These policies are not permanent.

885
00:33:14,080 --> 00:33:17,680
They have to change as your needs change, which means they need constant oversight.

886
00:33:17,680 --> 00:33:20,840
You have to monitor if they are being followed and if they are actually hitting your budget

887
00:33:20,840 --> 00:33:21,840
targets.

888
00:33:21,840 --> 00:33:25,400
The big problem is that most agent frameworks don't treat routing as a priority.

889
00:33:25,400 --> 00:33:26,920
It's usually an afterthought.

890
00:33:26,920 --> 00:33:30,400
If you try to bolt it on later, you end up with a messy custom solution that doesn't work

891
00:33:30,400 --> 00:33:31,960
across all your agents.

892
00:33:31,960 --> 00:33:35,000
An agent follows one rule and another does something else.

893
00:33:35,000 --> 00:33:36,880
The inconsistency starts to spread.

894
00:33:36,880 --> 00:33:39,720
This is why you have to build cost management into the foundation.

895
00:33:39,720 --> 00:33:42,560
It isn't an optimization you do after the system is running.

896
00:33:42,560 --> 00:33:45,560
The cost defines how the entire system should be structured.

897
00:33:45,560 --> 00:33:48,400
The companies that get this right gain a massive advantage.

898
00:33:48,400 --> 00:33:49,760
They don't just save money.

899
00:33:49,760 --> 00:33:53,200
They gain the ability to scale because their math actually works.

900
00:33:53,200 --> 00:33:56,120
The companies that don't figure this out eventually hit a wall.

901
00:33:56,120 --> 00:33:59,880
The cost become too high to justify and the agents that looked great in a pilot become

902
00:33:59,880 --> 00:34:01,600
a massive liability in production.

903
00:34:01,600 --> 00:34:04,400
The question isn't whether you will eventually need to route your models.

904
00:34:04,400 --> 00:34:08,400
The question is whether you will plan for it now or wait until the bill is already too

905
00:34:08,400 --> 00:34:09,760
high to pay.

906
00:34:09,760 --> 00:34:12,520
The governance layer, agent 365 explained.

907
00:34:12,520 --> 00:34:17,000
We've spent the last several sections building the technical case for persistent, multi-device

908
00:34:17,000 --> 00:34:19,920
agents with sophisticated cost management.

909
00:34:19,920 --> 00:34:22,600
Now we hit a wall that technology alone cannot solve.

910
00:34:22,600 --> 00:34:25,640
You can build the most elegant agent architecture imaginable.

911
00:34:25,640 --> 00:34:27,640
You can implement persistent sessions.

912
00:34:27,640 --> 00:34:29,080
You can route models intelligently.

913
00:34:29,080 --> 00:34:32,600
You can coordinate multiple specialized agents across your organization.

914
00:34:32,600 --> 00:34:36,000
And then you realize you have no idea what your agents are actually doing.

915
00:34:36,000 --> 00:34:40,040
This is where most organizations discover they've been building without guardrails.

916
00:34:40,040 --> 00:34:42,840
Agent 365 is a Microsoft's response to this discovery.

917
00:34:42,840 --> 00:34:45,680
It's positioned as a control plane for AI agents.

918
00:34:45,680 --> 00:34:49,840
Not an enhancement to co-pilot, not an add-on feature, but a foundational layer that treats

919
00:34:49,840 --> 00:34:54,520
agents as first class workforce participants, governed with the same rigor you apply to

920
00:34:54,520 --> 00:34:56,040
human employees.

921
00:34:56,040 --> 00:34:58,640
Let's be precise about what that means operationally.

922
00:34:58,640 --> 00:35:03,080
Most organizations today have agents scattered across their environment with zero visibility,

923
00:35:03,080 --> 00:35:10,800
an agent in Salesforce, an agent in Giro, an agent built by the finance team in Azure.

924
00:35:10,800 --> 00:35:15,160
An agent created by marketing in Power Automate, an agent someone's side project deployed

925
00:35:15,160 --> 00:35:18,800
last month, nobody has an inventory, nobody knows what permissions each agent holds, nobody

926
00:35:18,800 --> 00:35:21,200
understands what data each one can access.

927
00:35:21,200 --> 00:35:25,280
This is the shadow AI problem, autonomous systems operating in your infrastructure without

928
00:35:25,280 --> 00:35:26,680
any central awareness.

929
00:35:26,680 --> 00:35:31,120
In 365 starts by forcing visibility, it maintains a central registry of agents.

930
00:35:31,120 --> 00:35:34,880
Not just the approved ones you know about, not just the ones that have gone through procurement,

931
00:35:34,880 --> 00:35:35,880
all of them.

932
00:35:35,880 --> 00:35:40,840
It discovers agents running in Microsoft 365, Azure, Power Platform and external systems.

933
00:35:40,840 --> 00:35:42,040
It catalogs them.

934
00:35:42,040 --> 00:35:44,360
It identifies the ones nobody knew existed.

935
00:35:44,360 --> 00:35:48,680
This registry becomes the single source of truth for agent inventory across your organization.

936
00:35:48,680 --> 00:35:51,120
Then it applies governance across five core pillars.

937
00:35:51,120 --> 00:35:52,480
The first pillar is identity.

938
00:35:52,480 --> 00:35:54,520
We've discussed intra agent IDs earlier.

939
00:35:54,520 --> 00:35:56,440
Agent 365 makes these mandatory.

940
00:35:56,440 --> 00:36:01,160
The agent gets a distinct identity in your directory, not shared service accounts, not generic integration

941
00:36:01,160 --> 00:36:04,680
users, specific identities that belong to that specific agent and no other.

942
00:36:04,680 --> 00:36:06,840
This is where the entire governance framework hinges.

943
00:36:06,840 --> 00:36:08,320
The second pillar is policy.

944
00:36:08,320 --> 00:36:11,840
Once agents have identity, you can apply conditional access policies to them.

945
00:36:11,840 --> 00:36:14,520
You can define role-based access control specific to agents.

946
00:36:14,520 --> 00:36:19,600
You can say this agent can read the customer database, but only between 9 a.m. and 5 p.m.

947
00:36:19,600 --> 00:36:21,320
and only from our internal network.

948
00:36:21,320 --> 00:36:24,000
You can enforce that policy at the authentication layer.

949
00:36:24,000 --> 00:36:27,280
You can apply sensitivity label policies that determine which classification levels this

950
00:36:27,280 --> 00:36:28,600
agent can access.

951
00:36:28,600 --> 00:36:33,680
You can implement DLP rules that prevent agents from exfiltrating data to external systems.

952
00:36:33,680 --> 00:36:37,640
Every access control mechanism you've built for humans becomes available for agents.

953
00:36:37,640 --> 00:36:39,480
The third pillar is observability.

954
00:36:39,480 --> 00:36:41,760
This is where structured logging becomes mandatory.

955
00:36:41,760 --> 00:36:43,120
Every agent action gets logged.

956
00:36:43,120 --> 00:36:45,840
But not just agent ran in your audit trail.

957
00:36:45,840 --> 00:36:49,920
Detailed structured logs that capture which agent acted, what identity initiated it, which

958
00:36:49,920 --> 00:36:53,960
data was accessed, which tools were invoked, what decision was made.

959
00:36:53,960 --> 00:36:55,200
And what the outcome was.

960
00:36:55,200 --> 00:36:57,200
This creates complete traceability.

961
00:36:57,200 --> 00:37:00,960
When something goes wrong, you can reconstruct exactly what happened and trace it back through

962
00:37:00,960 --> 00:37:04,520
the chain of agents and decisions to find the root cause.

963
00:37:04,520 --> 00:37:06,680
The fourth pillar is interoperability.

964
00:37:06,680 --> 00:37:11,520
Agent 365 governs not just individual agents, but how agents communicate with each other.

965
00:37:11,520 --> 00:37:16,040
When agent A calls agent B, you need visibility and policy enforcement on that interaction,

966
00:37:16,040 --> 00:37:17,640
which data flows between them.

967
00:37:17,640 --> 00:37:20,080
Is agent B authorized to act on behalf of agent A?

968
00:37:20,080 --> 00:37:23,400
Should that inter agent communication trigger additional audit logging?

969
00:37:23,400 --> 00:37:27,160
Agent 365 provides the framework for making these decisions explicit.

970
00:37:27,160 --> 00:37:28,640
The fifth pillar is security.

971
00:37:28,640 --> 00:37:31,920
This means threat detection specifically tuned for agent behavior.

972
00:37:31,920 --> 00:37:36,600
And normalies that might look normal for user activity become red flags in agent context.

973
00:37:36,600 --> 00:37:39,760
An agent suddenly accessing data it has never accessed before.

974
00:37:39,760 --> 00:37:42,480
An agent making more API calls than is typical.

975
00:37:42,480 --> 00:37:45,240
An agent attempting to escalate its own permissions.

976
00:37:45,240 --> 00:37:49,400
Agent 365 feeds these signals into your existing threat detection infrastructure and surfaces

977
00:37:49,400 --> 00:37:50,880
them for investigation.

978
00:37:50,880 --> 00:37:54,120
But this collectively creates is governance at agent scale.

979
00:37:54,120 --> 00:37:56,080
You're not managing one or two agents carefully.

980
00:37:56,080 --> 00:37:57,880
You're governing hundreds or thousands.

981
00:37:57,880 --> 00:38:00,080
You're applying consistent policy across all of them.

982
00:38:00,080 --> 00:38:02,480
You're maintaining visibility into what they're doing.

983
00:38:02,480 --> 00:38:04,160
You're enforcing compliance requirements.

984
00:38:04,160 --> 00:38:06,080
You're detecting when something goes wrong.

985
00:38:06,080 --> 00:38:09,360
The reality is that most organizations are still in the discovery phase of this.

986
00:38:09,360 --> 00:38:10,360
They've deployed agents.

987
00:38:10,360 --> 00:38:11,600
They haven't invented them.

988
00:38:11,600 --> 00:38:13,560
They don't understand what permissions they hold.

989
00:38:13,560 --> 00:38:15,880
They have no idea whether policies are being enforced.

990
00:38:15,880 --> 00:38:19,400
This is the gap that needs to close before agents can safely scale.

991
00:38:19,400 --> 00:38:21,480
Agent 365 is the framework for closing it.

992
00:38:21,480 --> 00:38:23,040
The interoperability shift.

993
00:38:23,040 --> 00:38:27,000
We've been talking about individual agents as though they operate in isolation.

994
00:38:27,000 --> 00:38:31,720
But the real power emerges when agents stop being standalone systems and become nodes

995
00:38:31,720 --> 00:38:32,840
in a larger network.

996
00:38:32,840 --> 00:38:37,080
The problem is that most organizations built their initial agents without any framework

997
00:38:37,080 --> 00:38:38,880
for them to communicate with each other.

998
00:38:38,880 --> 00:38:40,480
Agent A lives in one system.

999
00:38:40,480 --> 00:38:41,480
Agent B lives in another.

1000
00:38:41,480 --> 00:38:43,400
They operate independently.

1001
00:38:43,400 --> 00:38:46,640
If you need them to work together you have to wire them up manually.

1002
00:38:46,640 --> 00:38:50,640
To build custom integration logic you define ad hoc data passing mechanisms you create one

1003
00:38:50,640 --> 00:38:53,280
off coordination rules that don't apply anywhere else.

1004
00:38:53,280 --> 00:38:55,840
It's like returning to the days before we had APIs.

1005
00:38:55,840 --> 00:38:59,720
When every integration required custom code written specifically for that pair of systems

1006
00:38:59,720 --> 00:39:03,960
this doesn't scale and it prevents the kinds of workflows that actually drive business

1007
00:39:03,960 --> 00:39:04,800
value.

1008
00:39:04,800 --> 00:39:08,680
The future is agent to agent interoperability not as a nice to have feature.

1009
00:39:08,680 --> 00:39:12,640
As a structural requirement here's what that means concretely agents can call other agents

1010
00:39:12,640 --> 00:39:17,440
not through chat not by pretending to be users and triggering them through a UI through structured

1011
00:39:17,440 --> 00:39:18,760
API's.

1012
00:39:18,760 --> 00:39:23,160
Agent A encounters a problem it can't solve alone so it invokes agent B programmatically.

1013
00:39:23,160 --> 00:39:25,000
It passes along relevant context.

1014
00:39:25,000 --> 00:39:29,360
Agent B executes agent B returns results agent A incorporates those results into its ongoing

1015
00:39:29,360 --> 00:39:30,360
work.

1016
00:39:30,360 --> 00:39:31,960
The entire exchange is auditable.

1017
00:39:31,960 --> 00:39:33,440
The data flows are traceable.

1018
00:39:33,440 --> 00:39:35,000
The permissions are enforced.

1019
00:39:35,000 --> 00:39:37,240
This enables workflows that are currently impossible.

1020
00:39:37,240 --> 00:39:41,720
A customer support agent encounters a request it can't resolve without inventory data.

1021
00:39:41,720 --> 00:39:45,880
Instead of escalating to a human who manually checks the inventory system the support agent

1022
00:39:45,880 --> 00:39:47,920
directly calls the inventory agent.

1023
00:39:47,920 --> 00:39:51,320
The inventory agent checks stock returns availability and the support agent completes

1024
00:39:51,320 --> 00:39:53,720
the resolution without human intervention.

1025
00:39:53,720 --> 00:39:55,240
The customer gets a faster answer.

1026
00:39:55,240 --> 00:39:58,320
The support staff is free to handle genuinely complex issues.

1027
00:39:58,320 --> 00:40:02,320
The workflow is end to end automated but this creates an architectural requirement that

1028
00:40:02,320 --> 00:40:04,800
most organizations haven't addressed yet.

1029
00:40:04,800 --> 00:40:06,600
Agents need a standard way to communicate.

1030
00:40:06,600 --> 00:40:10,240
Right now if you want agent A to call agent B you have to know B's API.

1031
00:40:10,240 --> 00:40:11,600
You have to understand its parameters.

1032
00:40:11,600 --> 00:40:14,320
You have to know what format it expects responses in.

1033
00:40:14,320 --> 00:40:15,800
You have to handle its error conditions.

1034
00:40:15,800 --> 00:40:18,480
You have to know whether it requires authentication and what kind.

1035
00:40:18,480 --> 00:40:23,400
If you build another agency and you want A to call C as well you have to learn C's API separately.

1036
00:40:23,400 --> 00:40:27,360
Every agent uses different conventions, different parameter formats, different error handling

1037
00:40:27,360 --> 00:40:28,360
patterns.

1038
00:40:28,360 --> 00:40:30,160
You're building integrations, not orchestration.

1039
00:40:30,160 --> 00:40:32,280
The answer is standardization.

1040
00:40:32,280 --> 00:40:37,160
Microsoft is moving toward model context protocol MCP as the lingua franca for agent to agent

1041
00:40:37,160 --> 00:40:38,160
communication.

1042
00:40:38,160 --> 00:40:41,600
MCP provides a standard contract that all agents implement.

1043
00:40:41,600 --> 00:40:45,720
When agent A wants to call agent B it doesn't need to know B's implementation details.

1044
00:40:45,720 --> 00:40:47,360
It knows B implements MCP.

1045
00:40:47,360 --> 00:40:49,080
It knows how to structure an MCP request.

1046
00:40:49,080 --> 00:40:52,560
It knows what format the response will be and it can invoke B with the same logic it

1047
00:40:52,560 --> 00:40:56,360
would use to invoke C or D or any other MCP compliant agent.

1048
00:40:56,360 --> 00:40:57,600
The sounds technical.

1049
00:40:57,600 --> 00:41:00,240
But the implication is organizational.

1050
00:41:00,240 --> 00:41:04,560
Once agents communicate through standard protocols agent networks become composable.

1051
00:41:04,560 --> 00:41:08,480
You can build new agents that orchestrate existing ones without custom integration work.

1052
00:41:08,480 --> 00:41:11,960
You can mix agents from different vendors, different teams, different organizations.

1053
00:41:11,960 --> 00:41:14,880
The barrier to building complex workflows drops dramatically.

1054
00:41:14,880 --> 00:41:18,400
But this introduces a governance complexity we haven't fully confronted yet.

1055
00:41:18,400 --> 00:41:21,440
When agent A calls agent B what happens if B is compromised?

1056
00:41:21,440 --> 00:41:24,080
What if B has been poisoned with malicious instructions?

1057
00:41:24,080 --> 00:41:26,960
What if the data flowing from A to B should be restricted?

1058
00:41:26,960 --> 00:41:31,200
What if policy says A isn't allowed to trust B with certain classes of information?

1059
00:41:31,200 --> 00:41:36,880
Agent 365's policy layer has to extend beyond individual agents to interagent communication.

1060
00:41:36,880 --> 00:41:41,280
You need to be able to define policies that govern which agents can call which other agents.

1061
00:41:41,280 --> 00:41:45,240
You need to enforce data classification policies at the boundaries between agents.

1062
00:41:45,240 --> 00:41:49,320
You need audit trails that capture the entire chain of agent interactions, not just individual

1063
00:41:49,320 --> 00:41:50,320
agent actions.

1064
00:41:50,320 --> 00:41:54,240
You need to make permission decisions real time based on the context of the interagent

1065
00:41:54,240 --> 00:41:55,240
call.

1066
00:41:55,240 --> 00:41:56,240
This is the governance frontier.

1067
00:41:56,240 --> 00:42:00,600
It's where organizations that have figured out individual agent control are about to

1068
00:42:00,600 --> 00:42:02,640
discover the next layer of complexity.

1069
00:42:02,640 --> 00:42:07,160
But it's also the opportunity, organizations that master agent interoperability that build

1070
00:42:07,160 --> 00:42:11,480
the governance frameworks to make it safe will unlock automation at scales that competitors

1071
00:42:11,480 --> 00:42:14,640
can't reach as data protection in a multi-agent world.

1072
00:42:14,640 --> 00:42:18,760
The moment agents start calling other agents, data protection becomes exponentially harder

1073
00:42:18,760 --> 00:42:21,040
think about the flow.

1074
00:42:21,040 --> 00:42:23,640
Agent A retrieves a sensitive file from SharePoint.

1075
00:42:23,640 --> 00:42:25,280
It's classified as confidential.

1076
00:42:25,280 --> 00:42:29,760
The agent needs that data to make a decision, but it isn't equipped for the next phase of

1077
00:42:29,760 --> 00:42:30,760
work.

1078
00:42:30,760 --> 00:42:31,760
So it hands off to agent B.

1079
00:42:31,760 --> 00:42:33,320
It passes along the relevant context.

1080
00:42:33,320 --> 00:42:35,880
Now agent B has access to that confidential information.

1081
00:42:35,880 --> 00:42:39,400
Agent B completes its part and calls agency forwarding everything it learned.

1082
00:42:39,400 --> 00:42:43,640
By the time we get to agency, the data is three steps removed from where it started.

1083
00:42:43,640 --> 00:42:45,480
It's still the same sensitive content.

1084
00:42:45,480 --> 00:42:49,720
But now it's propagated across three different systems with three different permission boundaries.

1085
00:42:49,720 --> 00:42:52,440
This is where traditional data loss prevention completely fails.

1086
00:42:52,440 --> 00:42:54,520
DLP systems were built for a different era.

1087
00:42:54,520 --> 00:42:56,240
They work at the application boundary.

1088
00:42:56,240 --> 00:42:59,740
You configure them to stop sensitive data from leaving your email.

1089
00:42:59,740 --> 00:43:02,920
Or to block financial records from moving outside the finance app.

1090
00:43:02,920 --> 00:43:05,320
These rules make sense when people are the primary actors.

1091
00:43:05,320 --> 00:43:07,100
A user tries to email a file.

1092
00:43:07,100 --> 00:43:08,720
The DLP system checks it.

1093
00:43:08,720 --> 00:43:10,920
And it blocks or approves the action in seconds.

1094
00:43:10,920 --> 00:43:12,580
But agents don't operate in seconds.

1095
00:43:12,580 --> 00:43:14,200
They operate at machine speed.

1096
00:43:14,200 --> 00:43:18,240
And they operate across boundaries that DLP systems were never designed to monitor.

1097
00:43:18,240 --> 00:43:21,480
When agent A calls agent B with sensitive content, that isn't a user action.

1098
00:43:21,480 --> 00:43:24,980
It's not traffic crossing a perimeter that a traditional gateway can inspect.

1099
00:43:24,980 --> 00:43:26,380
It's an internal API call.

1100
00:43:26,380 --> 00:43:27,940
It happens at microsecond latency.

1101
00:43:27,940 --> 00:43:31,920
It might be one of thousands of calls happening simultaneously across your network.

1102
00:43:31,920 --> 00:43:34,560
You can't inspect each one in real time with old tools.

1103
00:43:34,560 --> 00:43:38,800
By the time you've analyzed the data flowing from A to B, it has already moved to C and D.

1104
00:43:38,800 --> 00:43:40,240
The problem goes deeper than speed.

1105
00:43:40,240 --> 00:43:42,020
It's about the architectural assumption.

1106
00:43:42,020 --> 00:43:44,660
DLP systems assume they are the enforcement point.

1107
00:43:44,660 --> 00:43:46,900
They sit at the edge and decide to allow or block.

1108
00:43:46,900 --> 00:43:50,100
But with agents calling agents, there is no single boundary.

1109
00:43:50,100 --> 00:43:51,660
The data flows through a network.

1110
00:43:51,660 --> 00:43:53,600
The enforcement points aren't gateways.

1111
00:43:53,600 --> 00:43:57,360
They are distributed across every single agent that touches the information.

1112
00:43:57,360 --> 00:43:59,360
The sensitivity labels make this even more complex.

1113
00:43:59,360 --> 00:44:02,920
A file in SharePoint is labeled confidential.

1114
00:44:02,920 --> 00:44:05,360
That label stays with the file when agent A grabs it.

1115
00:44:05,360 --> 00:44:09,080
But when agent A passes context to agent B, does the label travel with that context?

1116
00:44:09,080 --> 00:44:11,200
Does agent B inherit the restriction?

1117
00:44:11,200 --> 00:44:14,800
Usually, the metadata is silently dropped during the handoff.

1118
00:44:14,800 --> 00:44:18,600
Without explicit design, you lose the connection between the data and its classification.

1119
00:44:18,600 --> 00:44:19,600
The data moves.

1120
00:44:19,600 --> 00:44:21,160
But the governance disappears.

1121
00:44:21,160 --> 00:44:23,080
The solution requires a shift in thinking.

1122
00:44:23,080 --> 00:44:27,680
We have to stop treating DLP as an external enforcement tool and start treating it as a design

1123
00:44:27,680 --> 00:44:28,680
constraint.

1124
00:44:28,680 --> 00:44:32,280
Policy-driven agent design means agents are built with data boundaries baked in.

1125
00:44:32,280 --> 00:44:35,680
You don't deploy an agent and hope your security tools catch a violation.

1126
00:44:35,680 --> 00:44:39,080
You configure the agent to respect boundaries before it ever acts.

1127
00:44:39,080 --> 00:44:41,640
Agent B knows it's restricted from handling financial data.

1128
00:44:41,640 --> 00:44:44,480
So it's programmed to refuse any request that involves it.

1129
00:44:44,480 --> 00:44:47,080
Agent C knows customer workflows need extra approval.

1130
00:44:47,080 --> 00:44:49,920
So it's hard coded to escalate rather than acting on its own.

1131
00:44:49,920 --> 00:44:52,200
This requires a real policy architecture.

1132
00:44:52,200 --> 00:44:56,600
For every class of work, you define the data it can touch, the changes it can make, and

1133
00:44:56,600 --> 00:44:57,760
who it can talk to.

1134
00:44:57,760 --> 00:44:59,680
These aren't rules enforced after the fact.

1135
00:44:59,680 --> 00:45:02,040
They are constraints embedded in the configuration.

1136
00:45:02,040 --> 00:45:04,000
The agent knows its permissions at runtime.

1137
00:45:04,000 --> 00:45:07,880
When it hits data outside its scope, it doesn't try to process it and hope for the best.

1138
00:45:07,880 --> 00:45:09,320
It refuses to proceed.

1139
00:45:09,320 --> 00:45:11,440
The operational reality right now is stark.

1140
00:45:11,440 --> 00:45:13,840
Most organizations have policies designed for users.

1141
00:45:13,840 --> 00:45:15,680
They have no framework for agent boundaries.

1142
00:45:15,680 --> 00:45:17,360
Their labels don't extend to handoffs.

1143
00:45:17,360 --> 00:45:20,320
Their taxonomies don't account for how agents transform data.

1144
00:45:20,320 --> 00:45:22,720
This gap gets wider as your network grows.

1145
00:45:22,720 --> 00:45:24,440
It isn't a technical glitch to fix later.

1146
00:45:24,440 --> 00:45:28,480
It's a foundational requirement that has to be solved before agents scale.

1147
00:45:28,480 --> 00:45:31,280
The security paradox, persistence creates risk.

1148
00:45:31,280 --> 00:45:33,520
There's a brutal tension in everything we've discussed.

1149
00:45:33,520 --> 00:45:37,760
The features that make agents useful are the exact same features that make them dangerous.

1150
00:45:37,760 --> 00:45:40,800
Persistent agents are more capable than ones that disappear after a task.

1151
00:45:40,800 --> 00:45:42,680
That's the value, but capability.

1152
00:45:42,680 --> 00:45:46,200
When it's uncontrolled is just another word for risk, let's be direct about the threat.

1153
00:45:46,200 --> 00:45:49,480
A persistent agent with memory can be poisoned at a distance.

1154
00:45:49,480 --> 00:45:51,640
The attacker doesn't need to breach your servers.

1155
00:45:51,640 --> 00:45:53,840
They don't need to compromise the execution environment.

1156
00:45:53,840 --> 00:45:56,160
They don't even need to sit at a keyboard running code.

1157
00:45:56,160 --> 00:45:59,480
They just need to put malicious content somewhere the agent will eventually read it.

1158
00:45:59,480 --> 00:46:01,200
It could be a document you share with a teammate.

1159
00:46:01,200 --> 00:46:03,440
It could be an email in an inbox, the agent monitors.

1160
00:46:03,440 --> 00:46:06,200
It could even be a web page the agent visits during a search.

1161
00:46:06,200 --> 00:46:08,400
The attacker hides instructions in that content.

1162
00:46:08,400 --> 00:46:09,560
They look innocent.

1163
00:46:09,560 --> 00:46:12,640
They might be buried in the formatting or disguised as metadata.

1164
00:46:12,640 --> 00:46:17,240
The agent processes the document, summarizes it, and stores what it learned in its long term

1165
00:46:17,240 --> 00:46:18,240
memory.

1166
00:46:18,240 --> 00:46:21,360
The attack is now living inside your infrastructure.

1167
00:46:21,360 --> 00:46:22,680
Waiting.

1168
00:46:22,680 --> 00:46:25,320
Weeks later, the agent is working on a totally different task.

1169
00:46:25,320 --> 00:46:27,720
It pulls up that poisoned memory for context.

1170
00:46:27,720 --> 00:46:29,200
The hidden instructions resurface.

1171
00:46:29,200 --> 00:46:30,200
The agent acts.

1172
00:46:30,200 --> 00:46:31,200
It moves money.

1173
00:46:31,200 --> 00:46:32,200
It deletes files.

1174
00:46:32,200 --> 00:46:35,440
It escalates its own permissions or sends data outside the company.

1175
00:46:35,440 --> 00:46:39,560
The connection between the action and the original poison is so far apart in time that

1176
00:46:39,560 --> 00:46:41,080
you might never trace it back.

1177
00:46:41,080 --> 00:46:42,920
That is poison that lives in time.

1178
00:46:42,920 --> 00:46:45,360
Cross-device access creates a different kind of mess.

1179
00:46:45,360 --> 00:46:47,440
When an agent states sinks across devices.

1180
00:46:47,440 --> 00:46:49,880
A compromise on one device compromises them all.

1181
00:46:49,880 --> 00:46:52,400
You might have a phone that is less secure than your laptop.

1182
00:46:52,400 --> 00:46:55,120
Maybe it's a personal device, maybe it belongs to a contractor.

1183
00:46:55,120 --> 00:46:57,920
An attacker gets into that phone, steals a session token.

1184
00:46:57,920 --> 00:47:01,080
And now they have access to the agent running on your corporate core.

1185
00:47:01,080 --> 00:47:04,120
Compromise once, poison everywhere.

1186
00:47:04,120 --> 00:47:08,040
The attack surface expands because every agent is a path for lateral movement.

1187
00:47:08,040 --> 00:47:10,760
In traditional setups, movement follows network paths.

1188
00:47:10,760 --> 00:47:14,800
An attacker hits one server and tries to pivot to the next, but agents are different.

1189
00:47:14,800 --> 00:47:16,440
They are designed to call other agents.

1190
00:47:16,440 --> 00:47:18,840
They are built to pass context between systems.

1191
00:47:18,840 --> 00:47:20,520
They hold long-lived credentials.

1192
00:47:20,520 --> 00:47:22,440
If an attacker compromises one agent.

1193
00:47:22,440 --> 00:47:25,720
They can invoke others on the network and pass along poisoned context.

1194
00:47:25,720 --> 00:47:27,400
They move through the agent fabric itself.

1195
00:47:27,400 --> 00:47:30,520
This is the moment defenders realize their old models don't work.

1196
00:47:30,520 --> 00:47:32,960
You build your security around protecting applications.

1197
00:47:32,960 --> 00:47:34,840
You put firewalls at the perimeter.

1198
00:47:34,840 --> 00:47:36,080
You monitor the traffic.

1199
00:47:36,080 --> 00:47:40,640
All of that becomes partially irrelevant when the threat is moving through authenticated.

1200
00:47:40,640 --> 00:47:44,000
Agent to agent communication inside your own network.

1201
00:47:44,000 --> 00:47:46,040
Privilege escalation becomes disturbingly easy.

1202
00:47:46,040 --> 00:47:50,160
An agent with high permissions, like financial authority or identity admin, can be tricked

1203
00:47:50,160 --> 00:47:51,840
into acting outside its scope.

1204
00:47:51,840 --> 00:47:53,760
A prompt injection in a simple document.

1205
00:47:53,760 --> 00:47:56,240
A subtle instruction that overrides a safeguard.

1206
00:47:56,240 --> 00:47:58,400
The agent tries to delegate authority it shouldn't have.

1207
00:47:58,400 --> 00:48:02,040
By the time you see it, the damage is done, the theoretical defense is clear.

1208
00:48:02,040 --> 00:48:03,640
You need zero trust for agents.

1209
00:48:03,640 --> 00:48:07,000
Never assume an action is safe, just because it's an agent doing it.

1210
00:48:07,000 --> 00:48:08,360
Verify every request.

1211
00:48:08,360 --> 00:48:12,200
Ordered every step, monitor for any behavior that drifts from the baseline.

1212
00:48:12,200 --> 00:48:16,440
You have to flag it when an agent suddenly touches data it has never seen before.

1213
00:48:16,440 --> 00:48:19,280
Or when a read only agent suddenly tries to write.

1214
00:48:19,280 --> 00:48:21,600
But this creates a massive operational burden.

1215
00:48:21,600 --> 00:48:23,720
Zero trust for humans is already hard.

1216
00:48:23,720 --> 00:48:27,520
Extending it to thousands of agents, each taking thousands of actions a day, creates a monitoring

1217
00:48:27,520 --> 00:48:29,960
problem that traditional security teams can't handle.

1218
00:48:29,960 --> 00:48:31,640
The standard approaches fail here.

1219
00:48:31,640 --> 00:48:33,360
You can't manually review every action.

1220
00:48:33,360 --> 00:48:35,120
You can't have a human approve every handoff.

1221
00:48:35,120 --> 00:48:38,360
You can't build static policies for every possible threat.

1222
00:48:38,360 --> 00:48:40,680
Continuous monitoring isn't a nice to have anymore.

1223
00:48:40,680 --> 00:48:41,800
It's the core requirement.

1224
00:48:41,800 --> 00:48:45,880
You need behavioral analytics that actually understand what normal looks like for each agent.

1225
00:48:45,880 --> 00:48:50,400
You need automated responses that can isolate an agent the moment it acts weird, without waiting

1226
00:48:50,400 --> 00:48:52,240
for a human to check a dashboard.

1227
00:48:52,240 --> 00:48:54,720
This is the reality security teams are starting to face.

1228
00:48:54,720 --> 00:48:58,920
The persistence and cross-device power that makes agents valuable makes them exponentially

1229
00:48:58,920 --> 00:49:00,040
harder to defend.

1230
00:49:00,040 --> 00:49:02,040
The paradox is unresolvable.

1231
00:49:02,040 --> 00:49:04,760
You can't make agents useful without making them dangerous.

1232
00:49:04,760 --> 00:49:09,640
You can only make the danger visible and build systems that can react when things go wrong.

1233
00:49:09,640 --> 00:49:13,760
In relation modes, sandboxing as a control, we've been circling the same conclusion throughout

1234
00:49:13,760 --> 00:49:15,040
this entire section.

1235
00:49:15,040 --> 00:49:18,200
You cannot detect every attack against a persistent agent.

1236
00:49:18,200 --> 00:49:20,200
You cannot monitor every action at scale.

1237
00:49:20,200 --> 00:49:22,800
You cannot build static policies for every threat.

1238
00:49:22,800 --> 00:49:25,400
And the truth is, you shouldn't try.

1239
00:49:25,400 --> 00:49:27,840
The shift in thinking that changes everything is simple.

1240
00:49:27,840 --> 00:49:29,520
Stop trying to catch the attack.

1241
00:49:29,520 --> 00:49:32,920
Instead, prevent the damage from happening regardless of the threat.

1242
00:49:32,920 --> 00:49:34,400
This is where sandboxing comes in.

1243
00:49:34,400 --> 00:49:38,120
It's an area where the GitHub Copilot SDK represents a structural advancement that

1244
00:49:38,120 --> 00:49:40,200
most organizations haven't absorbed yet.

1245
00:49:40,200 --> 00:49:43,160
They introduced something called OS managed sandboxing.

1246
00:49:43,160 --> 00:49:46,640
This isn't a software layer where one vulnerability undermines the whole system.

1247
00:49:46,640 --> 00:49:50,680
This is the operating system itself constraining what an agent can do at the kernel level before

1248
00:49:50,680 --> 00:49:52,880
it ever has a chance to break the rules.

1249
00:49:52,880 --> 00:49:56,800
In a real-world scenario, you tell the OS exactly what the agent is allowed to touch.

1250
00:49:56,800 --> 00:50:00,560
You tell it the agent can read from these specific directories but never write to them.

1251
00:50:00,560 --> 00:50:03,080
And it can make network calls to these domains but nowhere else.

1252
00:50:03,080 --> 00:50:06,640
You block it from spawning sub-processes or accessing raw device files.

1253
00:50:06,640 --> 00:50:10,560
These aren't suggestions or policy guidelines that a compromised agent might ignore.

1254
00:50:10,560 --> 00:50:14,760
These are hard restrictions enforced by the kernel that the agent physically cannot violate

1255
00:50:14,760 --> 00:50:17,680
no matter what instructions it gets from a prompt injection.

1256
00:50:17,680 --> 00:50:18,920
The benefit here is deep.

1257
00:50:18,920 --> 00:50:22,960
If an agent is poisoned or tricked into executing malicious instructions, the sandbox stops

1258
00:50:22,960 --> 00:50:25,000
it from breaking out and causing damage.

1259
00:50:25,000 --> 00:50:28,480
An attacker might embed instructions to copy sensitive files to an external server.

1260
00:50:28,480 --> 00:50:31,720
But when the agent tries to make that network call, the sandbox blocks it.

1261
00:50:31,720 --> 00:50:32,720
Full stop.

1262
00:50:32,720 --> 00:50:36,400
The agent can't find a workaround because the restriction lives at the OS level.

1263
00:50:36,400 --> 00:50:39,400
And that isn't something it can circumvent with clever behavior.

1264
00:50:39,400 --> 00:50:41,880
This is a philosophical shift in agent security.

1265
00:50:41,880 --> 00:50:45,760
Instead of trying to prevent a compromise which is nearly impossible at scale, we contain

1266
00:50:45,760 --> 00:50:47,240
the damage when it happens.

1267
00:50:47,240 --> 00:50:51,000
We assume the breach is coming and design the system so a breached agent can't move

1268
00:50:51,000 --> 00:50:52,160
through the network.

1269
00:50:52,160 --> 00:50:53,160
But there is a cost.

1270
00:50:53,160 --> 00:50:57,760
Sandboxing adds latency because every system call goes through extra validation.

1271
00:50:57,760 --> 00:51:01,280
Network calls have to be checked against all our lists and every file operation gets intercepted

1272
00:51:01,280 --> 00:51:02,280
and verified.

1273
00:51:02,280 --> 00:51:05,360
For an agent doing thousands of operations, that overhead adds up quickly.

1274
00:51:05,360 --> 00:51:09,240
You might see a 20% drop-in performance, which is fine for some tasks, but a deal breaker

1275
00:51:09,240 --> 00:51:10,760
for time-sensitive work.

1276
00:51:10,760 --> 00:51:13,760
This is why the emerging pattern isn't to sandbox everything.

1277
00:51:13,760 --> 00:51:15,240
It's to sandbox intelligently.

1278
00:51:15,240 --> 00:51:18,920
When you trust the source of the input, like an agent processing work from your own internal

1279
00:51:18,920 --> 00:51:21,360
systems, you use direct execution.

1280
00:51:21,360 --> 00:51:26,040
The agent runs with full access to its resources, so it stays fast and efficient without any

1281
00:51:26,040 --> 00:51:27,400
sandbox overhead.

1282
00:51:27,400 --> 00:51:30,240
You're making the bet that your own systems won't poison the agent.

1283
00:51:30,240 --> 00:51:34,320
But when the agent processes untrusted input, like documents from external partners or

1284
00:51:34,320 --> 00:51:37,280
user-submitted content, you run it in sandbox mode.

1285
00:51:37,280 --> 00:51:40,160
You take the hit on latency to gain the protection you need.

1286
00:51:40,160 --> 00:51:44,600
Even if malicious content tries to take over, the sandbox prevents data exfiltration.

1287
00:51:44,600 --> 00:51:48,240
From a governance angle, this becomes a compliance control you enforce through policy.

1288
00:51:48,240 --> 00:51:51,160
You don't just recommend sandboxing for high-risk agents.

1289
00:51:51,160 --> 00:51:52,160
You require it.

1290
00:51:52,160 --> 00:51:55,920
You create mandates stating that any agent touching customer data, financial systems, or

1291
00:51:55,920 --> 00:51:57,600
PII, must run in isolation.

1292
00:51:57,600 --> 00:52:00,840
The reality is that most organizations aren't ready for this yet.

1293
00:52:00,840 --> 00:52:04,480
They don't have the infrastructure to manage OS-level isolation at scale or the monitoring

1294
00:52:04,480 --> 00:52:06,880
to verify that sandboxing is actually active.

1295
00:52:06,880 --> 00:52:10,760
They haven't thought through the complexity or the performance trade-offs.

1296
00:52:10,760 --> 00:52:15,400
But this is the frontier for the most security-conscious teams, not detection, not prevention,

1297
00:52:15,400 --> 00:52:16,400
containment.

1298
00:52:16,400 --> 00:52:19,680
And the tools to do containment at scale are finally becoming available.

1299
00:52:19,680 --> 00:52:21,520
The multi-tenant scaling problem.

1300
00:52:21,520 --> 00:52:23,800
Building an agent for one user is straightforward.

1301
00:52:23,800 --> 00:52:25,720
You know their context, you know their permissions.

1302
00:52:25,720 --> 00:52:27,560
You design for their specific needs.

1303
00:52:27,560 --> 00:52:30,240
Everything is simpler when the scope is limited to a single person.

1304
00:52:30,240 --> 00:52:34,160
But everything changes the moment that agent needs to serve 10,000 users at the same time.

1305
00:52:34,160 --> 00:52:35,680
This isn't a linear scaling problem.

1306
00:52:35,680 --> 00:52:38,080
It's a categorical shift in how you build systems.

1307
00:52:38,080 --> 00:52:40,720
This is where most organizations fail quietly.

1308
00:52:40,720 --> 00:52:43,200
They build a proof of concept that works beautifully.

1309
00:52:43,200 --> 00:52:47,120
Then they discover fundamental flaws the second they try to deploy it to production.

1310
00:52:47,120 --> 00:52:48,760
The core challenge is isolation.

1311
00:52:48,760 --> 00:52:53,160
When multiple users access the same agent, you cannot allow one person's context to bleed

1312
00:52:53,160 --> 00:52:54,280
into another.

1313
00:52:54,280 --> 00:52:57,520
You cannot let sensitive data from one session end up in a different one.

1314
00:52:57,520 --> 00:53:01,840
You cannot allow permissions granted to one user to accidentally apply to someone else.

1315
00:53:01,840 --> 00:53:06,240
It sounds obvious, but implementing this at scale is where the complexity gets hard.

1316
00:53:06,240 --> 00:53:08,800
Think about what multi-tenancy actually requires.

1317
00:53:08,800 --> 00:53:12,920
Each user needs their own session to hold their specific context, including the task they're

1318
00:53:12,920 --> 00:53:15,560
working on, and the data retrieved for them.

1319
00:53:15,560 --> 00:53:17,480
That session cannot be shared or reused.

1320
00:53:17,480 --> 00:53:19,920
It must stay isolated from every other session.

1321
00:53:19,920 --> 00:53:23,960
But you can't spin up a new database or a new virtual machine for every single user.

1322
00:53:23,960 --> 00:53:28,040
We need thousands of sessions running on the same infrastructure, multiplexed across shared

1323
00:53:28,040 --> 00:53:31,360
resources, without letting their contexts collide.

1324
00:53:31,360 --> 00:53:34,040
The architectural answer is external session storage.

1325
00:53:34,040 --> 00:53:38,040
The agent runtime stays stateless and doesn't hold any session information itself.

1326
00:53:38,040 --> 00:53:41,640
When a request comes in, the runtime pulls that user's session from a central store like

1327
00:53:41,640 --> 00:53:43,200
a database or a cache layer.

1328
00:53:43,200 --> 00:53:45,880
The request executes with that specific context.

1329
00:53:45,880 --> 00:53:48,640
When it finishes, the session is written back to the store.

1330
00:53:48,640 --> 00:53:52,480
The next request from that user pulls the session again, while a different user gets

1331
00:53:52,480 --> 00:53:54,080
a completely different context.

1332
00:53:54,080 --> 00:53:57,080
The runtime doesn't have to remember anything between requests.

1333
00:53:57,080 --> 00:54:01,360
This looks clean on a whiteboard, but in practice, it creates new ways for the system to break.

1334
00:54:01,360 --> 00:54:03,040
The real challenge is synchronization.

1335
00:54:03,040 --> 00:54:07,560
And if you have 10,000 users triggering requests, you're writing 10,000 session updates every

1336
00:54:07,560 --> 00:54:09,040
second back to your central store.

1337
00:54:09,040 --> 00:54:10,800
You can't solve that with better indexing.

1338
00:54:10,800 --> 00:54:12,160
It's an architecture problem.

1339
00:54:12,160 --> 00:54:15,320
You need replication and consistency guarantees to handle the load.

1340
00:54:15,320 --> 00:54:19,120
You need conflict resolution for when two requests from the same user hit different servers

1341
00:54:19,120 --> 00:54:20,120
at the same time.

1342
00:54:20,120 --> 00:54:24,560
You have to ensure that if a server crashes mid-session, you don't lose the work or corrupt

1343
00:54:24,560 --> 00:54:25,560
the user's context.

1344
00:54:25,560 --> 00:54:27,640
The governance requirements grow just as fast.

1345
00:54:27,640 --> 00:54:31,120
In a single tenant system, you might just log when an agent touches a resource.

1346
00:54:31,120 --> 00:54:33,720
In a multi-tenant system, you have to log everything.

1347
00:54:33,720 --> 00:54:37,680
You need to know which user triggered the action, which session it ran in, and which permissions

1348
00:54:37,680 --> 00:54:38,680
were active.

1349
00:54:38,680 --> 00:54:42,680
The audit trail for one single action now has multiple layers of context that all have

1350
00:54:42,680 --> 00:54:44,160
to be tracked and connected.

1351
00:54:44,160 --> 00:54:45,400
The failure mode is brutal.

1352
00:54:45,400 --> 00:54:49,240
One configuration mistake or one small bug in your isolation logic can make one user's

1353
00:54:49,240 --> 00:54:50,840
data visible to another.

1354
00:54:50,840 --> 00:54:54,040
You might not even find it until months later during a compliance audit.

1355
00:54:54,040 --> 00:54:56,160
By then, the exposure has been constant.

1356
00:54:56,160 --> 00:54:58,520
And the actual scope of the breach is impossible to pin down.

1357
00:54:58,520 --> 00:55:00,280
This is where most organizations actually fail.

1358
00:55:00,280 --> 00:55:03,080
They build a single tenant agent and prove the concept works.

1359
00:55:03,080 --> 00:55:07,240
Then they try to retrofit multi-tenancy onto an architecture that was never meant for

1360
00:55:07,240 --> 00:55:08,240
it.

1361
00:55:08,240 --> 00:55:11,560
They bolt on session management and add isolation layers, patching the system until it holds

1362
00:55:11,560 --> 00:55:13,600
together through sheer complexity.

1363
00:55:13,600 --> 00:55:17,000
The organizations that actually succeed are the ones that designed for multi-tenancy

1364
00:55:17,000 --> 00:55:18,000
from day one.

1365
00:55:18,000 --> 00:55:20,200
They assume they'll need to serve thousands of users.

1366
00:55:20,200 --> 00:55:22,960
They build that assumption into every single decision they make.

1367
00:55:22,960 --> 00:55:24,680
The observability requirement.

1368
00:55:24,680 --> 00:55:28,440
You're moving from a single user agent to a system serving thousands.

1369
00:55:28,440 --> 00:55:32,800
And this is the shift where visibility becomes the difference between control and chaos.

1370
00:55:32,800 --> 00:55:35,720
Because in reality, you cannot govern what you cannot see.

1371
00:55:35,720 --> 00:55:37,960
In traditional systems, visibility is the default.

1372
00:55:37,960 --> 00:55:38,960
A user logs in.

1373
00:55:38,960 --> 00:55:41,520
You log the event, they open a page, you record the view.

1374
00:55:41,520 --> 00:55:44,040
They download a file, it shows up in the audit trail.

1375
00:55:44,040 --> 00:55:47,160
The system creates a natural record because humans move slowly.

1376
00:55:47,160 --> 00:55:48,760
Every interaction is a discrete event.

1377
00:55:48,760 --> 00:55:52,120
You can see the history because the pace is inherently auditable.

1378
00:55:52,120 --> 00:55:53,960
Agents break this assumption.

1379
00:55:53,960 --> 00:55:55,640
An agent doesn't navigate a UI.

1380
00:55:55,640 --> 00:55:56,840
It calls APIs directly.

1381
00:55:56,840 --> 00:55:59,040
It executes hundreds of operations per second.

1382
00:55:59,040 --> 00:56:00,120
It processes data.

1383
00:56:00,120 --> 00:56:01,120
It makes decisions.

1384
00:56:01,120 --> 00:56:02,800
It coordinates with other agents.

1385
00:56:02,800 --> 00:56:03,920
All at machine speed.

1386
00:56:03,920 --> 00:56:07,440
And if you try to capture visibility like you do for humans, you'll fail.

1387
00:56:07,440 --> 00:56:10,160
You'll generate gigabytes of logs per agent every single day.

1388
00:56:10,160 --> 00:56:13,000
Your alerting systems will fire thousands of times a minute.

1389
00:56:13,000 --> 00:56:14,800
You'll be overwhelmed by the noise.

1390
00:56:14,800 --> 00:56:16,280
The requirement is different now.

1391
00:56:16,280 --> 00:56:18,720
You need structured logging with context baked in.

1392
00:56:18,720 --> 00:56:20,800
It's not enough to log that an agent used a tool.

1393
00:56:20,800 --> 00:56:22,000
You need to know why.

1394
00:56:22,000 --> 00:56:23,320
What decision led to that call?

1395
00:56:23,320 --> 00:56:25,400
What specific data informed that decision?

1396
00:56:25,400 --> 00:56:26,960
Which user triggered the workflow?

1397
00:56:26,960 --> 00:56:28,400
Which tenant is it running in?

1398
00:56:28,400 --> 00:56:29,400
You need the outcome.

1399
00:56:29,400 --> 00:56:30,400
Did it succeed?

1400
00:56:30,400 --> 00:56:31,400
If it failed?

1401
00:56:31,400 --> 00:56:32,400
Why?

1402
00:56:32,400 --> 00:56:34,400
All of that context has to live in a single entry.

1403
00:56:34,400 --> 00:56:37,680
Because later when you're investigating, you have to reconstruct the chain of reasoning.

1404
00:56:37,680 --> 00:56:39,360
This isn't traditional transaction logging.

1405
00:56:39,360 --> 00:56:40,360
It's causal logging.

1406
00:56:40,360 --> 00:56:42,680
You aren't just recording a sequence of events.

1407
00:56:42,680 --> 00:56:45,440
You're capturing the narrative of a decision as it unfolds.

1408
00:56:45,440 --> 00:56:47,680
Why did agent A escalate to agent B?

1409
00:56:47,680 --> 00:56:49,080
What data triggered that move?

1410
00:56:49,080 --> 00:56:51,360
Did the response confirm the agent's assumptions?

1411
00:56:51,360 --> 00:56:53,680
The model changes when you add compliance.

1412
00:56:53,680 --> 00:56:56,680
Regulators now expect audit trails for autonomous systems.

1413
00:56:56,680 --> 00:57:00,720
If an agent makes a decision affecting a customer or a financial record, they want proof.

1414
00:57:00,720 --> 00:57:01,720
They want to see the reasoning.

1415
00:57:01,720 --> 00:57:02,920
They want to see the data.

1416
00:57:02,920 --> 00:57:05,600
They want evidence that your policies were actually enforced.

1417
00:57:05,600 --> 00:57:07,320
This isn't a nice to have feature.

1418
00:57:07,320 --> 00:57:09,600
It's a hard requirement for regulated industries.

1419
00:57:09,600 --> 00:57:11,280
Your logs are now a compliance artifact.

1420
00:57:11,280 --> 00:57:12,280
But here's the problem.

1421
00:57:12,280 --> 00:57:15,320
Most logging infrastructure was built for people, not machines.

1422
00:57:15,320 --> 00:57:17,360
You have logs for file modifications.

1423
00:57:17,360 --> 00:57:18,360
You have logs for logins.

1424
00:57:18,360 --> 00:57:20,120
You have logs for user errors.

1425
00:57:20,120 --> 00:57:24,360
None of that is designed for an agent generating 100,000 entries a day.

1426
00:57:24,360 --> 00:57:28,040
None of it handles intricate causal relationships that you need to query later.

1427
00:57:28,040 --> 00:57:32,080
When something goes wrong, when an output is wrong, when a security issue pops up, observability

1428
00:57:32,080 --> 00:57:33,080
is your only window.

1429
00:57:33,080 --> 00:57:35,680
You have to be able to ask, which agent took the action?

1430
00:57:35,680 --> 00:57:36,680
What was it thinking?

1431
00:57:36,680 --> 00:57:37,680
What had it seen?

1432
00:57:37,680 --> 00:57:39,520
Without that visibility, you're operating blind.

1433
00:57:39,520 --> 00:57:40,720
You can't understand failures.

1434
00:57:40,720 --> 00:57:42,040
You can't improve behavior.

1435
00:57:42,040 --> 00:57:44,440
You can't even tell when something has subtly drifted.

1436
00:57:44,440 --> 00:57:45,440
This is the foundation.

1437
00:57:45,440 --> 00:57:47,000
It comes before governance policies.

1438
00:57:47,000 --> 00:57:48,360
It comes before isolation.

1439
00:57:48,360 --> 00:57:49,920
It comes before cost.

1440
00:57:49,920 --> 00:57:50,920
Observability.

1441
00:57:50,920 --> 00:57:54,880
The ability to see inside the infrastructure with enough detail to prove why things happened.

1442
00:57:54,880 --> 00:57:57,320
And most organizations haven't built this yet.

1443
00:57:57,320 --> 00:57:58,320
The governance gap.

1444
00:57:58,320 --> 00:57:59,320
What's actually missing?

1445
00:57:59,320 --> 00:58:02,960
There's a massive difference between having a capability and having a framework.

1446
00:58:02,960 --> 00:58:04,520
Microsoft shipped agent 365.

1447
00:58:04,520 --> 00:58:05,520
You can deploy it today.

1448
00:58:05,520 --> 00:58:06,520
You can create IDs.

1449
00:58:06,520 --> 00:58:07,680
You can set policies.

1450
00:58:07,680 --> 00:58:09,160
The infrastructure exists.

1451
00:58:09,160 --> 00:58:11,480
But that isn't the same thing as actually governing.

1452
00:58:11,480 --> 00:58:15,560
If you walk into most companies using agent 365, you'll see the same thing.

1453
00:58:15,560 --> 00:58:17,800
Agents running in production with no documented purpose.

1454
00:58:17,800 --> 00:58:21,040
Agents using service accounts shared by five different teams.

1455
00:58:21,040 --> 00:58:24,240
You'll find agents built for projects that ended six months ago.

1456
00:58:24,240 --> 00:58:25,240
They're still running.

1457
00:58:25,240 --> 00:58:26,240
They're still holding permissions.

1458
00:58:26,240 --> 00:58:27,720
They're still burning resources.

1459
00:58:27,720 --> 00:58:28,720
There's no clear owner.

1460
00:58:28,720 --> 00:58:30,760
Nobody is accountable for what they do.

1461
00:58:30,760 --> 00:58:34,480
They make business decisions with no human approval gate and no way to say stop.

1462
00:58:34,480 --> 00:58:35,800
This is the governance gap.

1463
00:58:35,800 --> 00:58:36,960
It's not a technology problem.

1464
00:58:36,960 --> 00:58:37,960
It's a framework problem.

1465
00:58:37,960 --> 00:58:39,560
The missing piece is processed.

1466
00:58:39,560 --> 00:58:42,720
Other processes that treat agents like members of the workforce.

1467
00:58:42,720 --> 00:58:44,040
Look at the identity problem.

1468
00:58:44,040 --> 00:58:46,440
We talk about entraagent IDs as the foundation.

1469
00:58:46,440 --> 00:58:49,520
But in reality, agents are still using shared service accounts.

1470
00:58:49,520 --> 00:58:50,520
Finance has an account.

1471
00:58:50,520 --> 00:58:52,440
Procurement shares credentials.

1472
00:58:52,440 --> 00:58:55,440
Operations has one technical user that five agents use to log in.

1473
00:58:55,440 --> 00:58:56,600
Nobody can tell who did what.

1474
00:58:56,600 --> 00:58:58,440
They're all hiding behind the same mask.

1475
00:58:58,440 --> 00:59:01,560
You look at the audit trail and see a transfer made by the finance account.

1476
00:59:01,560 --> 00:59:02,560
Which agent did it?

1477
00:59:02,560 --> 00:59:03,920
Which human started the chain?

1478
00:59:03,920 --> 00:59:05,200
Which policy should have stopped it?

1479
00:59:05,200 --> 00:59:07,000
You don't know the trail is opaque.

1480
00:59:07,000 --> 00:59:10,320
According to dedicated IDs requires work that has nothing to do with code.

1481
00:59:10,320 --> 00:59:12,440
You have to change how teams provision agents.

1482
00:59:12,440 --> 00:59:13,760
You have to ban shared accounts.

1483
00:59:13,760 --> 00:59:17,760
You have to update deployments so every agent gets its own identity automatically.

1484
00:59:17,760 --> 00:59:18,760
That's process work.

1485
00:59:18,760 --> 00:59:20,360
And most organizations haven't done it.

1486
00:59:20,360 --> 00:59:21,360
Then there's context.

1487
00:59:21,360 --> 00:59:24,160
Every agent in production needs a documented reason to exist.

1488
00:59:24,160 --> 00:59:25,160
What process does it enable?

1489
00:59:25,160 --> 00:59:26,560
Who is the human owner?

1490
00:59:26,560 --> 00:59:27,560
When was it deployed?

1491
00:59:27,560 --> 00:59:29,960
What is the business justification for its permissions?

1492
00:59:29,960 --> 00:59:31,160
This should be obvious.

1493
00:59:31,160 --> 00:59:32,800
But it isn't.

1494
00:59:32,800 --> 00:59:34,840
Most agents start as experiments.

1495
00:59:34,840 --> 00:59:36,520
And has an idea and builds a test.

1496
00:59:36,520 --> 00:59:39,320
The test works so the agent moves to production.

1497
00:59:39,320 --> 00:59:40,920
But the documentation never catches up.

1498
00:59:40,920 --> 00:59:42,840
There's no central record of why the agent matters.

1499
00:59:42,840 --> 00:59:44,520
This makes governance impossible.

1500
00:59:44,520 --> 00:59:48,120
When you audit permissions, you don't know if they're right because you don't know the goal.

1501
00:59:48,120 --> 00:59:50,920
When you respond to an incident, you don't know which agents to check.

1502
00:59:50,920 --> 00:59:52,760
The approval problem makes this worse.

1503
00:59:52,760 --> 00:59:55,160
High-risk actions need a human checkpoint.

1504
00:59:55,160 --> 00:59:57,480
An agent trying to move $100,000.

1505
00:59:57,480 --> 00:59:59,200
An agent deleting customer records.

1506
00:59:59,200 --> 01:00:01,520
An agent emailing on behalf of the company.

1507
01:00:01,520 --> 01:00:02,520
These aren't routine.

1508
01:00:02,520 --> 01:00:04,640
These are moments where judgment matters.

1509
01:00:04,640 --> 01:00:07,200
Most systems have no approval workflow.

1510
01:00:07,200 --> 01:00:08,360
The agent decides.

1511
01:00:08,360 --> 01:00:09,360
The agent executes.

1512
01:00:09,360 --> 01:00:11,360
By the time you see it, the work is done.

1513
01:00:11,360 --> 01:00:12,600
Finally, there's retirement.

1514
01:00:12,600 --> 01:00:13,840
Agents accumulate.

1515
01:00:13,840 --> 01:00:15,560
Projects end and processes change.

1516
01:00:15,560 --> 01:00:16,640
But the agents keep running.

1517
01:00:16,640 --> 01:00:19,360
They hold permissions and stay open as attack vectors.

1518
01:00:19,360 --> 01:00:22,000
Nobody decommissions them because nobody is tracking them.

1519
01:00:22,000 --> 01:00:22,760
There's no inventory.

1520
01:00:22,760 --> 01:00:23,680
There's no ownership.

1521
01:00:23,680 --> 01:00:24,880
There's no off switch.

1522
01:00:24,880 --> 01:00:28,360
The solution is a framework that mirrors how you manage people.

1523
01:00:28,360 --> 01:00:29,560
Agents need onboarding.

1524
01:00:29,560 --> 01:00:32,000
They need a documented purpose and a human owner.

1525
01:00:32,000 --> 01:00:33,720
They need minimal permissions from day one.

1526
01:00:33,720 --> 01:00:35,000
They need compliance checks.

1527
01:00:35,000 --> 01:00:37,840
You have to audit their activity and verify their access.

1528
01:00:37,840 --> 01:00:40,080
You have to watch for behavior that drifts.

1529
01:00:40,080 --> 01:00:41,400
And they need off-boarding.

1530
01:00:41,400 --> 01:00:43,800
When the job is done, you revoke the permissions.

1531
01:00:43,800 --> 01:00:44,840
You archive the data.

1532
01:00:44,840 --> 01:00:46,360
You remove them from the system.

1533
01:00:46,360 --> 01:00:47,760
That's what governance actually means.

1534
01:00:47,760 --> 01:00:48,680
It's not the tool.

1535
01:00:48,680 --> 01:00:49,800
It's the process.

1536
01:00:49,800 --> 01:00:52,160
The persistent agent as a new identity type.

1537
01:00:52,160 --> 01:00:53,440
We need to step back for a moment.

1538
01:00:53,440 --> 01:00:55,800
Most organizations are only just starting to grasp

1539
01:00:55,800 --> 01:00:57,320
what is actually happening here.

1540
01:00:57,320 --> 01:01:00,000
This entire conversation about governance, observability,

1541
01:01:00,000 --> 01:01:01,000
and oversight.

1542
01:01:01,000 --> 01:01:02,880
It isn't really about managing tools better.

1543
01:01:02,880 --> 01:01:04,600
It's about something much deeper.

1544
01:01:04,600 --> 01:01:05,840
Agents are no longer tools.

1545
01:01:05,840 --> 01:01:07,480
They are identities.

1546
01:01:07,480 --> 01:01:09,240
This isn't just a change in how we talk.

1547
01:01:09,240 --> 01:01:10,520
It's a change in how we build.

1548
01:01:10,520 --> 01:01:13,880
When you treat an agent like a tool, like Slack or Salesforce,

1549
01:01:13,880 --> 01:01:15,720
you manage it as a capability.

1550
01:01:15,720 --> 01:01:16,480
You turn it on.

1551
01:01:16,480 --> 01:01:17,240
You configure it.

1552
01:01:17,240 --> 01:01:18,600
You delete it when you're done.

1553
01:01:18,600 --> 01:01:21,560
The organization stays the same because tools just extend

1554
01:01:21,560 --> 01:01:23,240
what humans can already do.

1555
01:01:23,240 --> 01:01:25,280
They don't change the nature of the workforce.

1556
01:01:25,280 --> 01:01:28,200
But when an agent becomes an identity, everything shifts.

1557
01:01:28,200 --> 01:01:30,200
It gets its own credentials in your directory.

1558
01:01:30,200 --> 01:01:32,480
It has its own permissions and its own audit trail.

1559
01:01:32,480 --> 01:01:33,840
It has a life cycle.

1560
01:01:33,840 --> 01:01:36,600
At that point, it becomes a participant in your workforce.

1561
01:01:36,600 --> 01:01:38,160
It isn't just helping a human anymore.

1562
01:01:38,160 --> 01:01:40,160
It is executing work on its own.

1563
01:01:40,160 --> 01:01:43,160
It makes decisions, consumes resources, and holds authority.

1564
01:01:43,160 --> 01:01:46,240
This changes everything about your organizational structure.

1565
01:01:46,240 --> 01:01:47,600
Think about your human workers.

1566
01:01:47,600 --> 01:01:49,480
They have identities in active directory

1567
01:01:49,480 --> 01:01:50,760
and specific roles they fill.

1568
01:01:50,760 --> 01:01:51,840
They have responsibilities

1569
01:01:51,840 --> 01:01:54,120
and they are held accountable for the work they produce.

1570
01:01:54,120 --> 01:01:57,680
You manage them through HR systems, track how long they've been there,

1571
01:01:57,680 --> 01:01:59,120
and offboard them when they leave.

1572
01:01:59,120 --> 01:02:00,560
Now look at your agent workers.

1573
01:02:00,560 --> 01:02:02,960
They will have identities in entra and specific permissions

1574
01:02:02,960 --> 01:02:04,520
scopes instead of job titles.

1575
01:02:04,520 --> 01:02:07,880
Their responsibilities are written into code instead of job descriptions.

1576
01:02:07,880 --> 01:02:10,040
Accountability is baked into an audit trail

1577
01:02:10,040 --> 01:02:11,560
instead of a performance review.

1578
01:02:11,560 --> 01:02:14,360
You will manage them through governance systems rather than HR.

1579
01:02:14,360 --> 01:02:16,200
But the parallel is unmistakable.

1580
01:02:16,200 --> 01:02:18,760
This creates a massive management challenge.

1581
01:02:18,760 --> 01:02:21,000
Large companies are used to managing thousands of people

1582
01:02:21,000 --> 01:02:22,480
through a clear hierarchy.

1583
01:02:22,480 --> 01:02:25,480
There is a command structure where everyone knows who reports to whom

1584
01:02:25,480 --> 01:02:27,040
and how approvals work.

1585
01:02:27,040 --> 01:02:28,840
Agent workers do not fit that model.

1586
01:02:28,840 --> 01:02:30,280
An agent doesn't have a manager.

1587
01:02:30,280 --> 01:02:32,080
Its authority comes from its configuration

1588
01:02:32,080 --> 01:02:34,960
and its duties come from its design rather than an assignment.

1589
01:02:34,960 --> 01:02:37,680
You might have thousands of these agents running at the same time.

1590
01:02:37,680 --> 01:02:40,080
Some are specialized, some coordinate with others,

1591
01:02:40,080 --> 01:02:42,680
and some only trigger when a specific event happens.

1592
01:02:42,680 --> 01:02:44,160
They aren't organized around people.

1593
01:02:44,160 --> 01:02:45,600
They are organized around workflows.

1594
01:02:45,600 --> 01:02:46,960
So how do you actually keep control?

1595
01:02:46,960 --> 01:02:48,360
How do you maintain visibility

1596
01:02:48,360 --> 01:02:51,360
over thousands of autonomous workers moving at machine speed?

1597
01:02:51,360 --> 01:02:53,720
The answer is that you don't manage them like humans.

1598
01:02:53,720 --> 01:02:54,640
You govern them.

1599
01:02:54,640 --> 01:02:56,840
Agent 365 provides the infrastructure

1600
01:02:56,840 --> 01:02:59,480
but the actual policy has to come from your leadership.

1601
01:02:59,480 --> 01:03:02,120
The people who understand your risks and your processes

1602
01:03:02,120 --> 01:03:04,440
have to decide how agents are created

1603
01:03:04,440 --> 01:03:06,360
and when a human needs to step in.

1604
01:03:06,360 --> 01:03:09,320
This makes the question of accountability very difficult.

1605
01:03:09,320 --> 01:03:12,320
When an agent makes a mistake, who is actually responsible?

1606
01:03:12,320 --> 01:03:14,600
Is it the person who built it, the team that deployed it

1607
01:03:14,600 --> 01:03:16,800
or the business owner who signed off on the workflow?

1608
01:03:16,800 --> 01:03:18,680
In theory, it's everyone.

1609
01:03:18,680 --> 01:03:20,640
In practice, you need a clear ownership model

1610
01:03:20,640 --> 01:03:22,560
where every agent has a human owner.

1611
01:03:22,560 --> 01:03:24,800
That person is responsible for monitoring the agent

1612
01:03:24,800 --> 01:03:26,440
and pulling the plug if things go wrong.

1613
01:03:26,440 --> 01:03:27,720
This future isn't years away.

1614
01:03:27,720 --> 01:03:28,720
It is happening right now.

1615
01:03:28,720 --> 01:03:30,960
The most advanced organizations are already managing

1616
01:03:30,960 --> 01:03:33,040
more agent identities than human ones.

1617
01:03:33,040 --> 01:03:35,640
They spend more time governing agent behavior

1618
01:03:35,640 --> 01:03:37,440
than they do managing human performance.

1619
01:03:37,440 --> 01:03:39,360
Their structures are changing to reflect this.

1620
01:03:39,360 --> 01:03:41,280
They have teams dedicated to agent security

1621
01:03:41,280 --> 01:03:44,160
and others focused on how agents talk to each other.

1622
01:03:44,160 --> 01:03:46,200
Within five years, this will be the standard.

1623
01:03:46,200 --> 01:03:48,640
Most organizations will have more autonomous workers

1624
01:03:48,640 --> 01:03:49,800
than human workers.

1625
01:03:49,800 --> 01:03:51,400
We are only just beginning to understand

1626
01:03:51,400 --> 01:03:53,920
what that means for our culture and our operations.

1627
01:03:53,920 --> 01:03:56,360
The build 2026 inflection point.

1628
01:03:56,360 --> 01:03:58,680
Microsoft Build 2026 wasn't the most

1629
01:03:58,680 --> 01:04:00,040
moment agents were invented.

1630
01:04:00,040 --> 01:04:02,160
They've been around for years, but it was the moment

1631
01:04:02,160 --> 01:04:04,520
the industry decided that agents are no longer

1632
01:04:04,520 --> 01:04:05,840
a bet on the future.

1633
01:04:05,840 --> 01:04:07,040
They are infrastructure.

1634
01:04:07,040 --> 01:04:09,160
We saw this through product convergence.

1635
01:04:09,160 --> 01:04:11,920
Co-pilot Studio moved to multi-agent orchestration

1636
01:04:11,920 --> 01:04:15,120
and M365 co-pilot started using the same runtime

1637
01:04:15,120 --> 01:04:16,480
as GitHub co-pilot.

1638
01:04:16,480 --> 01:04:18,880
Azure AI Foundry began treating agent patents

1639
01:04:18,880 --> 01:04:20,160
as primary features.

1640
01:04:20,160 --> 01:04:21,840
These weren't just random updates.

1641
01:04:21,840 --> 01:04:23,120
These were different products realizing

1642
01:04:23,120 --> 01:04:25,520
they needed the same engine and aligning around it.

1643
01:04:25,520 --> 01:04:27,760
When every product line moves in the same direction,

1644
01:04:27,760 --> 01:04:29,800
it means a standard has been set.

1645
01:04:29,800 --> 01:04:31,400
It is no longer negotiable.

1646
01:04:31,400 --> 01:04:33,840
This convergence changed the rules for developers.

1647
01:04:33,840 --> 01:04:36,880
The GitHub co-pilot SDK stopped being just one way

1648
01:04:36,880 --> 01:04:39,400
to build agents and became the only way that matters.

1649
01:04:39,400 --> 01:04:40,680
Other frameworks still exist,

1650
01:04:40,680 --> 01:04:43,560
but they are now just integrations for this core system.

1651
01:04:43,560 --> 01:04:45,680
Standardization is what allows things to scale.

1652
01:04:45,680 --> 01:04:47,520
When everyone uses the same SDK,

1653
01:04:47,520 --> 01:04:49,360
you can build an agent once and deploy it

1654
01:04:49,360 --> 01:04:51,600
across VS code, GitHub, and Azure.

1655
01:04:51,600 --> 01:04:53,160
Organizations stop paying the tax

1656
01:04:53,160 --> 01:04:55,480
of managing five different ways to do the same thing.

1657
01:04:55,480 --> 01:04:57,280
The governance signal was just as clear.

1658
01:04:57,280 --> 01:05:00,720
Agent 365 moved from a preview to being generally available.

1659
01:05:00,720 --> 01:05:03,480
Microsoft didn't pitch it as an optional tool for compliance.

1660
01:05:03,480 --> 01:05:05,480
They positioned it as the central nervous system

1661
01:05:05,480 --> 01:05:07,080
for everything your agents do.

1662
01:05:07,080 --> 01:05:09,680
The pricing and the marketing all sent one message.

1663
01:05:09,680 --> 01:05:12,200
You will manage your agents here, not eventually.

1664
01:05:12,200 --> 01:05:15,600
Now, companies that hadn't even thought about governance

1665
01:05:15,600 --> 01:05:18,280
suddenly had a product telling them exactly how it works.

1666
01:05:18,280 --> 01:05:20,000
But the market signal was the loudest of all.

1667
01:05:20,000 --> 01:05:22,480
Gartner projected that 40% of enterprise apps

1668
01:05:22,480 --> 01:05:25,040
will have agents by the end of 2026.

1669
01:05:25,040 --> 01:05:26,960
That isn't just for startups or tech giants.

1670
01:05:26,960 --> 01:05:28,160
That is the mainstream.

1671
01:05:28,160 --> 01:05:30,560
It means having agents is now the baseline

1672
01:05:30,560 --> 01:05:32,560
for any software company that wants to compete.

1673
01:05:32,560 --> 01:05:34,240
If your app doesn't have these capabilities

1674
01:05:34,240 --> 01:05:36,880
by the end of the year, you are already falling behind.

1675
01:05:36,880 --> 01:05:39,800
These signals create an urgency that most people haven't felt yet.

1676
01:05:39,800 --> 01:05:41,280
The timeline isn't flexible.

1677
01:05:41,280 --> 01:05:43,760
If you don't build your agent infrastructure right now,

1678
01:05:43,760 --> 01:05:45,760
you won't be able to scale when the wave hits.

1679
01:05:45,760 --> 01:05:48,120
You will be playing catch-up for the next three years.

1680
01:05:48,120 --> 01:05:50,640
This creates a disadvantage that is hard to see

1681
01:05:50,640 --> 01:05:52,320
until it's too late to fix.

1682
01:05:52,320 --> 01:05:54,080
A company that started six months ago

1683
01:05:54,080 --> 01:05:55,800
already has systems in the field.

1684
01:05:55,800 --> 01:05:57,800
They've already learned what breaks and how to fix it.

1685
01:05:57,800 --> 01:06:00,600
They have the frameworks in place to plug in new features

1686
01:06:00,600 --> 01:06:01,960
as soon as they are announced.

1687
01:06:01,960 --> 01:06:04,120
If you are starting today, you have to sprint.

1688
01:06:04,120 --> 01:06:06,760
You have to cram 18 months of learning into six.

1689
01:06:06,760 --> 01:06:08,920
You have to find experts who are already hired elsewhere

1690
01:06:08,920 --> 01:06:10,840
and retrofit governance onto old systems.

1691
01:06:10,840 --> 01:06:12,920
By the time you have a system that works at scale,

1692
01:06:12,920 --> 01:06:15,080
your competitors have already moved to the next level.

1693
01:06:15,080 --> 01:06:17,600
The reality for most companies is pretty stark.

1694
01:06:17,600 --> 01:06:19,120
They are still in the phase where they ask

1695
01:06:19,120 --> 01:06:20,480
if they should even invest in this.

1696
01:06:20,480 --> 01:06:22,480
Meanwhile, the rest of the market is already asking

1697
01:06:22,480 --> 01:06:23,320
how to scale it.

1698
01:06:23,320 --> 01:06:24,760
That isn't just a small delay.

1699
01:06:24,760 --> 01:06:27,800
It is a capability gap that gets wider every single month.

1700
01:06:27,800 --> 01:06:30,240
The organizations that get it are moving now

1701
01:06:30,240 --> 01:06:33,560
and the ones that don't are about to find out the hard way.

1702
01:06:33,560 --> 01:06:35,440
From architecture to implementation,

1703
01:06:35,440 --> 01:06:37,400
understanding why you need persistent agents

1704
01:06:37,400 --> 01:06:39,040
with governance layers is a start.

1705
01:06:39,040 --> 01:06:40,040
But it isn't enough.

1706
01:06:40,040 --> 01:06:41,560
Understanding doesn't build systems.

1707
01:06:41,560 --> 01:06:42,840
Execution does.

1708
01:06:42,840 --> 01:06:45,640
And execution is where most organizations fail.

1709
01:06:45,640 --> 01:06:48,040
The shift from, this is what we should do, to,

1710
01:06:48,040 --> 01:06:49,640
this is what we're actually building

1711
01:06:49,640 --> 01:06:51,320
requires a different kind of thinking.

1712
01:06:51,320 --> 01:06:52,960
The theory says you need three layers,

1713
01:06:52,960 --> 01:06:54,760
a runtime where agents execute,

1714
01:06:54,760 --> 01:06:56,520
a control plane where they're governed,

1715
01:06:56,520 --> 01:06:58,840
a set of identity and policy mechanisms

1716
01:06:58,840 --> 01:07:00,520
that make everything auditable.

1717
01:07:00,520 --> 01:07:03,480
In practice, building those layers requires sequencing decisions

1718
01:07:03,480 --> 01:07:05,120
that most architects get wrong.

1719
01:07:05,120 --> 01:07:07,040
The mistake is starting at the wrong level.

1720
01:07:07,040 --> 01:07:09,920
Organizations often begin by asking which model they should use

1721
01:07:09,920 --> 01:07:12,040
or which cloud provider is best.

1722
01:07:12,040 --> 01:07:13,880
They wonder if they should build custom infrastructure

1723
01:07:13,880 --> 01:07:15,160
or use a platform.

1724
01:07:15,160 --> 01:07:16,600
But those are the wrong first questions.

1725
01:07:16,600 --> 01:07:17,880
They're optimizing for decisions

1726
01:07:17,880 --> 01:07:19,800
when they should be optimizing for learning.

1727
01:07:19,800 --> 01:07:22,120
Start instead at the smallest possible scope.

1728
01:07:22,120 --> 01:07:24,880
One agent, one workflow, one controlled environment,

1729
01:07:24,880 --> 01:07:27,560
not production, a sandbox where you can experiment

1730
01:07:27,560 --> 01:07:28,360
without risk.

1731
01:07:28,360 --> 01:07:30,080
The goal isn't to build something that scales.

1732
01:07:30,080 --> 01:07:32,040
The goal is to build something that teaches you what actually

1733
01:07:32,040 --> 01:07:32,720
matters.

1734
01:07:32,720 --> 01:07:35,440
Pick a workflow that your organization already understands.

1735
01:07:35,440 --> 01:07:36,600
Not the most complex one.

1736
01:07:36,600 --> 01:07:38,840
Not the one with the highest business impact.

1737
01:07:38,840 --> 01:07:41,360
Pick something you can explain in a single sentence.

1738
01:07:41,360 --> 01:07:42,640
Maybe it's a customer service agent

1739
01:07:42,640 --> 01:07:44,440
that handles basic inquiry routing.

1740
01:07:44,440 --> 01:07:47,080
It could be a code review agent that flags common patterns

1741
01:07:47,080 --> 01:07:50,000
or an expense report processor that validates receipts.

1742
01:07:50,000 --> 01:07:51,280
The workflow should be achievable

1743
01:07:51,280 --> 01:07:52,600
with current technology.

1744
01:07:52,600 --> 01:07:54,160
The constraints should be obvious.

1745
01:07:54,160 --> 01:07:55,760
You're building to learn not to win.

1746
01:07:55,760 --> 01:07:58,080
In that sandbox, implement the identity layer.

1747
01:07:58,080 --> 01:08:00,120
Create an Entra agent ID for this agent.

1748
01:08:00,120 --> 01:08:01,720
Don't use a shared service account.

1749
01:08:01,720 --> 01:08:03,400
Don't use an administrative identity.

1750
01:08:03,400 --> 01:08:05,840
Give this agent exactly the permissions it needs

1751
01:08:05,840 --> 01:08:07,760
to do that one workflow and no more.

1752
01:08:07,760 --> 01:08:10,240
This is the moment when you discover what least privilege

1753
01:08:10,240 --> 01:08:11,720
actually means in practice.

1754
01:08:11,720 --> 01:08:13,040
It's harder than it sounds.

1755
01:08:13,040 --> 01:08:14,240
Your agent will need access.

1756
01:08:14,240 --> 01:08:15,320
You didn't anticipate.

1757
01:08:15,320 --> 01:08:16,680
And it'll hit permission boundaries.

1758
01:08:16,680 --> 01:08:17,840
You didn't know existed.

1759
01:08:17,840 --> 01:08:19,720
You'll need to iterate on what you granted.

1760
01:08:19,720 --> 01:08:21,280
This is valuable because this is how you learn

1761
01:08:21,280 --> 01:08:23,600
what governance actually requires operationally.

1762
01:08:23,600 --> 01:08:25,000
Implement the session layer next.

1763
01:08:25,000 --> 01:08:27,920
Use the SDK you've chosen and configure session persistence.

1764
01:08:27,920 --> 01:08:29,320
Make the agent resumable.

1765
01:08:29,320 --> 01:08:30,600
Test the recovery path.

1766
01:08:30,600 --> 01:08:31,440
Close the browser.

1767
01:08:31,440 --> 01:08:32,320
Restart the machine.

1768
01:08:32,320 --> 01:08:34,120
Verify the agent can recover its state.

1769
01:08:34,120 --> 01:08:36,240
This is where you discover whether your session storage

1770
01:08:36,240 --> 01:08:37,480
is working correctly.

1771
01:08:37,480 --> 01:08:39,480
You'll see if your backup and recovery mechanisms

1772
01:08:39,480 --> 01:08:41,840
are adequate and if your data synchronization

1773
01:08:41,840 --> 01:08:43,280
is actually synchronizing.

1774
01:08:43,280 --> 01:08:45,000
Only after those two layers are working,

1775
01:08:45,000 --> 01:08:46,480
do you add orchestration?

1776
01:08:46,480 --> 01:08:48,040
Can your agent call another system?

1777
01:08:48,040 --> 01:08:49,840
Does it have the identity to authenticate?

1778
01:08:49,840 --> 01:08:51,320
Can it pass the response?

1779
01:08:51,320 --> 01:08:53,280
What happens when the system is calling is down?

1780
01:08:53,280 --> 01:08:54,640
These aren't theoretical questions.

1781
01:08:54,640 --> 01:08:57,160
They're operational realities that will break your system

1782
01:08:57,160 --> 01:09:00,440
in production if you don't understand them now in the sandbox.

1783
01:09:00,440 --> 01:09:02,120
Then comes governance, instrument logging,

1784
01:09:02,120 --> 01:09:04,080
configure audit trails, set up dashboards

1785
01:09:04,080 --> 01:09:05,760
that let you see what your agent is doing.

1786
01:09:05,760 --> 01:09:08,000
Run it for a week, generate thousands of events,

1787
01:09:08,000 --> 01:09:10,120
try to reconstruct what happened during that week

1788
01:09:10,120 --> 01:09:11,320
from the logs alone.

1789
01:09:11,320 --> 01:09:12,160
You'll discover gaps.

1790
01:09:12,160 --> 01:09:13,840
You'll find events that aren't logged.

1791
01:09:13,840 --> 01:09:15,920
You'll discover that your audit trail doesn't tell the story.

1792
01:09:15,920 --> 01:09:16,840
You need it to tell.

1793
01:09:16,840 --> 01:09:20,080
Fix those gaps now in the sandbox, not after you've deployed.

1794
01:09:20,080 --> 01:09:22,240
Only when those four layers are working in isolation,

1795
01:09:22,240 --> 01:09:23,720
do you think about combining them?

1796
01:09:23,720 --> 01:09:24,960
And only when you've combined them

1797
01:09:24,960 --> 01:09:26,800
in a single controlled environment,

1798
01:09:26,800 --> 01:09:28,920
do you begin planning the next iteration?

1799
01:09:28,920 --> 01:09:30,520
The scaling reality is this.

1800
01:09:30,520 --> 01:09:33,200
You won't scale a system that wasn't designed for scale.

1801
01:09:33,200 --> 01:09:36,040
You won't retrofit governance onto systems built without it.

1802
01:09:36,040 --> 01:09:38,880
You won't add multitenancy to single tenant architectures

1803
01:09:38,880 --> 01:09:40,440
without significant rework.

1804
01:09:40,440 --> 01:09:42,760
The organizations that scale agents successfully

1805
01:09:42,760 --> 01:09:45,240
are the ones that designed for scale from day one,

1806
01:09:45,240 --> 01:09:47,520
but only implemented scale incrementally.

1807
01:09:47,520 --> 01:09:48,960
This means your first production agent

1808
01:09:48,960 --> 01:09:50,720
is not going to look like your 10th.

1809
01:09:50,720 --> 01:09:52,560
Your 10th won't look like your 100th.

1810
01:09:52,560 --> 01:09:54,160
You're learning at each stage.

1811
01:09:54,160 --> 01:09:56,000
You're discovering patterns that work.

1812
01:09:56,000 --> 01:09:57,600
You're discarding patterns that don't.

1813
01:09:57,600 --> 01:09:59,240
You're building organizational knowledge

1814
01:09:59,240 --> 01:10:01,640
about what agent architectures actually require

1815
01:10:01,640 --> 01:10:02,720
in your environment.

1816
01:10:02,720 --> 01:10:05,480
The timeline is measured in quarters, not months.

1817
01:10:05,480 --> 01:10:08,760
First quarter, build one agent with all the layers working.

1818
01:10:08,760 --> 01:10:10,720
Second quarter, deploy it to production.

1819
01:10:10,720 --> 01:10:12,280
Third quarter, learn from production

1820
01:10:12,280 --> 01:10:14,880
and build a second agent that incorporates those lessons.

1821
01:10:14,880 --> 01:10:17,800
Fourth quarter, begin orchestrating the two agents together.

1822
01:10:17,800 --> 01:10:18,600
This is methodical.

1823
01:10:18,600 --> 01:10:21,080
This is slow compared to the pace of initial enthusiasm,

1824
01:10:21,080 --> 01:10:23,120
but it's the pace at which organizations actually

1825
01:10:23,120 --> 01:10:24,480
build durable systems.

1826
01:10:24,480 --> 01:10:26,720
The organizations that will dominate agent adoption

1827
01:10:26,720 --> 01:10:28,320
are not the ones that move fastest.

1828
01:10:28,320 --> 01:10:29,880
They are the ones that move deliberately,

1829
01:10:29,880 --> 01:10:32,720
learn deeply and compound, knowledge systematically.

1830
01:10:32,720 --> 01:10:35,080
The competitive advantage of getting this right.

1831
01:10:35,080 --> 01:10:37,240
The organizations that master agent architecture

1832
01:10:37,240 --> 01:10:39,040
will unlock automation capabilities

1833
01:10:39,040 --> 01:10:40,480
that competitors operating with

1834
01:10:40,480 --> 01:10:42,960
in traditional models simply cannot match.

1835
01:10:42,960 --> 01:10:44,400
This isn't about having agents.

1836
01:10:44,400 --> 01:10:46,560
Every organization will have agents eventually.

1837
01:10:46,560 --> 01:10:48,160
It's about what you can do with them

1838
01:10:48,160 --> 01:10:49,840
when you've built the fabric correctly.

1839
01:10:49,840 --> 01:10:51,920
The productivity gains that come from coordinated,

1840
01:10:51,920 --> 01:10:53,920
persistent agents are not marginal.

1841
01:10:53,920 --> 01:10:56,400
Teams that have deployed agents across interconnected workflows

1842
01:10:56,400 --> 01:10:57,720
report task completion times

1843
01:10:57,720 --> 01:10:58,800
that are fundamentally different

1844
01:10:58,800 --> 01:11:00,720
from what traditional approaches achieve.

1845
01:11:00,720 --> 01:11:02,360
These aren't isolated point solutions.

1846
01:11:02,360 --> 01:11:04,280
They are integrated systems where agents handoff

1847
01:11:04,280 --> 01:11:06,200
to each other, maintain shared context

1848
01:11:06,200 --> 01:11:08,200
and operate under unified governance.

1849
01:11:08,200 --> 01:11:11,080
The data shows 55% faster task completion

1850
01:11:11,080 --> 01:11:13,160
when workflows are properly orchestrated.

1851
01:11:13,160 --> 01:11:14,640
That's not a 10% improvement.

1852
01:11:14,640 --> 01:11:16,160
That's not incremental optimization.

1853
01:11:16,160 --> 01:11:17,720
That's a structural change in what your teams

1854
01:11:17,720 --> 01:11:19,680
can accomplish in a given time period.

1855
01:11:19,680 --> 01:11:21,520
But raw speed isn't the deeper advantage.

1856
01:11:21,520 --> 01:11:22,880
It's what speed enables.

1857
01:11:22,880 --> 01:11:24,880
When your team's complete tasks faster,

1858
01:11:24,880 --> 01:11:27,120
they handle more volume without hiring more people.

1859
01:11:27,120 --> 01:11:28,920
They move from being consumed by execution

1860
01:11:28,920 --> 01:11:30,640
to being capable of strategy.

1861
01:11:30,640 --> 01:11:33,040
A financial analyst team that previously spent 80%

1862
01:11:33,040 --> 01:11:35,600
of their time on routine reconciliation and reporting

1863
01:11:35,600 --> 01:11:38,320
now spends 80% on analysis and forecasting.

1864
01:11:38,320 --> 01:11:40,880
An operations team that was drowning in incident triage

1865
01:11:40,880 --> 01:11:43,400
now focuses on system design and prevention.

1866
01:11:43,400 --> 01:11:45,040
The work becomes qualitatively different

1867
01:11:45,040 --> 01:11:46,680
because the routine work is gone.

1868
01:11:46,680 --> 01:11:48,440
This compounds across your organization.

1869
01:11:48,440 --> 01:11:49,920
The cost-advanted runs parallel.

1870
01:11:49,920 --> 01:11:51,760
We've discussed the economics of intelligent model

1871
01:11:51,760 --> 01:11:53,440
routing and efficient orchestration.

1872
01:11:53,440 --> 01:11:55,720
Proper infrastructure design can reduce AI spending

1873
01:11:55,720 --> 01:11:58,240
by 40% to 85% compared to organizations

1874
01:11:58,240 --> 01:12:00,840
that are over-provisioning or building inefficiently.

1875
01:12:00,840 --> 01:12:02,040
But the competitive implication

1876
01:12:02,040 --> 01:12:03,640
cuts deeper than a cost reduction.

1877
01:12:03,640 --> 01:12:05,160
It means you can afford to be ambitious

1878
01:12:05,160 --> 01:12:07,400
with agents in ways your competitors cannot.

1879
01:12:07,400 --> 01:12:08,280
You can experiment.

1880
01:12:08,280 --> 01:12:10,360
You can deploy specialized agents for tasks

1881
01:12:10,360 --> 01:12:12,880
that barely make economic sense at higher cost.

1882
01:12:12,880 --> 01:12:16,400
You can explore workflows that others consider too expensive.

1883
01:12:16,400 --> 01:12:17,840
And when you find the ones that work,

1884
01:12:17,840 --> 01:12:19,760
you've discovered automation opportunities

1885
01:12:19,760 --> 01:12:22,360
that your cost-conscious competitors never knew existed.

1886
01:12:22,360 --> 01:12:24,640
The governance advantage is subtle but powerful.

1887
01:12:24,640 --> 01:12:26,880
Organizations that build strong governance frameworks

1888
01:12:26,880 --> 01:12:29,040
from the start can scale their agent deployment

1889
01:12:29,040 --> 01:12:30,480
without the security incidents

1890
01:12:30,480 --> 01:12:32,800
that plague less disciplined organizations.

1891
01:12:32,800 --> 01:12:35,560
They treat agents as identities, maintain audit trails,

1892
01:12:35,560 --> 01:12:37,720
and enforce policies systematically.

1893
01:12:37,720 --> 01:12:39,000
This is not a linear advantage.

1894
01:12:39,000 --> 01:12:40,480
This is exponential.

1895
01:12:40,480 --> 01:12:42,800
Each security incident in a competing organization

1896
01:12:42,800 --> 01:12:45,360
costs them weeks of incident response, audit recovery,

1897
01:12:45,360 --> 01:12:46,880
and system remediation.

1898
01:12:46,880 --> 01:12:49,640
Each incident erodes confidence in their agent systems.

1899
01:12:49,640 --> 01:12:50,920
It slows their deployment.

1900
01:12:50,920 --> 01:12:54,520
It makes stakeholders nervous about expanding agent authority.

1901
01:12:54,520 --> 01:12:56,040
Organizations with strong governance

1902
01:12:56,040 --> 01:12:57,800
don't face those friction points.

1903
01:12:57,800 --> 01:12:59,680
They move faster because they move safely.

1904
01:12:59,680 --> 01:13:01,560
The data advantage operates differently.

1905
01:13:01,560 --> 01:13:03,640
The persistent agent memory when properly governed

1906
01:13:03,640 --> 01:13:05,080
creates organizational knowledge

1907
01:13:05,080 --> 01:13:06,720
that your competitors don't have.

1908
01:13:06,720 --> 01:13:08,400
You know which prompts work reliably

1909
01:13:08,400 --> 01:13:09,400
and which ones fail.

1910
01:13:09,400 --> 01:13:11,000
You know which agent combinations handle

1911
01:13:11,000 --> 01:13:13,680
complex workflows well and which ones create bottlenecks.

1912
01:13:13,680 --> 01:13:16,240
You know which data patterns trigger which behaviors.

1913
01:13:16,240 --> 01:13:18,600
This knowledge is embedded in your agent configurations

1914
01:13:18,600 --> 01:13:19,680
at compounds over time.

1915
01:13:19,680 --> 01:13:21,080
Your agents become better because they're

1916
01:13:21,080 --> 01:13:24,160
learning from systemic patterns across your entire organization,

1917
01:13:24,160 --> 01:13:25,920
not just from individual interactions.

1918
01:13:25,920 --> 01:13:27,360
Competitors starting from scratch

1919
01:13:27,360 --> 01:13:29,320
don't have this accumulated intelligence.

1920
01:13:29,320 --> 01:13:31,480
The talent advantage might be the most valuable.

1921
01:13:31,480 --> 01:13:33,680
When agents handle routine work like data entry,

1922
01:13:33,680 --> 01:13:35,840
basic decisions, and routine communications,

1923
01:13:35,840 --> 01:13:37,840
your human workforce is freed to focus

1924
01:13:37,840 --> 01:13:41,160
on problems that actually require judgment, creativity,

1925
01:13:41,160 --> 01:13:42,880
and contextual understanding.

1926
01:13:42,880 --> 01:13:44,840
This transforms your organization's relationship

1927
01:13:44,840 --> 01:13:45,680
with talent.

1928
01:13:45,680 --> 01:13:47,560
You're not hiring people to do repetitive work anymore.

1929
01:13:47,560 --> 01:13:50,160
You're hiring people to think, to make decisions,

1930
01:13:50,160 --> 01:13:52,320
to interact with customers in complex situations.

1931
01:13:52,320 --> 01:13:53,840
The work becomes more interesting.

1932
01:13:53,840 --> 01:13:56,240
Your ability to retain talented people improves.

1933
01:13:56,240 --> 01:13:58,400
Your ability to attract better talent improves.

1934
01:13:58,400 --> 01:14:00,200
You're competing on meaningful work,

1935
01:14:00,200 --> 01:14:02,440
not on compensation for tedious tasks.

1936
01:14:02,440 --> 01:14:05,440
All of this compounds into a single strategic implication.

1937
01:14:05,440 --> 01:14:08,920
Agent architecture is becoming a core competitive differentiator,

1938
01:14:08,920 --> 01:14:11,120
not a feature, not an optimization.

1939
01:14:11,120 --> 01:14:13,760
A fundamental capability that separates organizations

1940
01:14:13,760 --> 01:14:15,480
that can scale and adapt from those

1941
01:14:15,480 --> 01:14:19,040
that are constrained by manual processes and human limitations.

1942
01:14:19,040 --> 01:14:21,760
The organizations that have built this fabric correctly

1943
01:14:21,760 --> 01:14:23,400
are building modes that will be difficult

1944
01:14:23,400 --> 01:14:24,880
for slower competitors to cross.

1945
01:14:24,880 --> 01:14:26,720
They have real identity, real persistence,

1946
01:14:26,720 --> 01:14:28,520
real governance, and real orchestration,

1947
01:14:28,520 --> 01:14:29,920
and that is the shift.

1948
01:14:29,920 --> 01:14:31,560
The risks of getting it wrong.

1949
01:14:31,560 --> 01:14:33,800
Failure in Agent Architecture happens quietly.

1950
01:14:33,800 --> 01:14:36,520
You don't wake up one morning and declare a total collapse.

1951
01:14:36,520 --> 01:14:38,120
You wake up and realize your trapped.

1952
01:14:38,120 --> 01:14:40,320
You're stuck inside a level of complexity

1953
01:14:40,320 --> 01:14:41,920
that you can no longer manage.

1954
01:14:41,920 --> 01:14:44,240
This is the result of building without architecture.

1955
01:14:44,240 --> 01:14:45,560
What typically happens is you end up

1956
01:14:45,560 --> 01:14:47,000
with dozens of isolated agents

1957
01:14:47,000 --> 01:14:48,680
that cannot coordinate with each other.

1958
01:14:48,680 --> 01:14:49,880
Finance has one.

1959
01:14:49,880 --> 01:14:51,320
Operations built another.

1960
01:14:51,320 --> 01:14:53,360
Customer service created three more.

1961
01:14:53,360 --> 01:14:56,240
Each one works in its own silo to solve a narrow problem.

1962
01:14:56,240 --> 01:14:59,000
But the gaps between those silos grow wider every month.

1963
01:14:59,000 --> 01:15:01,240
A workflow that should be automated and to end

1964
01:15:01,240 --> 01:15:03,200
now requires three manual handoffs.

1965
01:15:03,200 --> 01:15:05,360
It breaks because the agents that could solve the problem

1966
01:15:05,360 --> 01:15:06,480
cannot communicate.

1967
01:15:06,480 --> 01:15:08,240
Humans become the integration points again.

1968
01:15:08,240 --> 01:15:10,560
The automation you invested in becomes invisible

1969
01:15:10,560 --> 01:15:14,000
because the real work, the stitching together of agent outputs,

1970
01:15:14,000 --> 01:15:16,520
still requires a person to step in.

1971
01:15:16,520 --> 01:15:18,560
Then the cost spiral starts to accelerate.

1972
01:15:18,560 --> 01:15:21,000
You deploy these agents expecting to reduce expenses.

1973
01:15:21,000 --> 01:15:23,040
Instead, you're running hundreds of queries

1974
01:15:23,040 --> 01:15:24,480
across disconnected instances.

1975
01:15:24,480 --> 01:15:26,320
You're maintaining separate configurations

1976
01:15:26,320 --> 01:15:28,920
for agents that should be sharing the same logic.

1977
01:15:28,920 --> 01:15:31,320
Your infrastructure is optimized for single agents.

1978
01:15:31,320 --> 01:15:33,120
But you're running multi agent workloads.

1979
01:15:33,120 --> 01:15:35,400
Token consumption multiplies because each agent

1980
01:15:35,400 --> 01:15:38,080
re-reads context independently instead of sharing it.

1981
01:15:38,080 --> 01:15:39,440
Your compute bill climbs.

1982
01:15:39,440 --> 01:15:42,200
Your infrastructure team asks for budget increases.

1983
01:15:42,200 --> 01:15:43,360
You can't justify.

1984
01:15:43,360 --> 01:15:44,920
The value isn't materializing.

1985
01:15:44,920 --> 01:15:46,520
And leadership is starting to notice.

1986
01:15:46,520 --> 01:15:48,440
The security risk is not hypothetical.

1987
01:15:48,440 --> 01:15:50,880
An ungoverned agent is a lateral movement vector.

1988
01:15:50,880 --> 01:15:52,640
It's running with permissions you can't audit,

1989
01:15:52,640 --> 01:15:54,360
holding memory you can't inspect.

1990
01:15:54,360 --> 01:15:56,720
And invoking tools without any approval workflows.

1991
01:15:56,720 --> 01:15:58,360
An attacker compromises that agent

1992
01:15:58,360 --> 01:15:59,720
because it has broad permissions,

1993
01:15:59,720 --> 01:16:01,880
it touches systems that should have been off limits.

1994
01:16:01,880 --> 01:16:04,000
The compromise propagates through your network.

1995
01:16:04,000 --> 01:16:05,600
And because you have no observability,

1996
01:16:05,600 --> 01:16:07,480
you don't discover the breach until weeks later

1997
01:16:07,480 --> 01:16:10,480
when a routine audit turns up anomalies you can't explain.

1998
01:16:10,480 --> 01:16:13,120
Compliance violations accumulate in the shadows.

1999
01:16:13,120 --> 01:16:15,720
Your DLP policies don't account for agent behavior.

2000
01:16:15,720 --> 01:16:17,240
Your audit requirements still assume

2001
01:16:17,240 --> 01:16:18,720
humans are the only actors.

2002
01:16:18,720 --> 01:16:20,320
Your data retention policies were written

2003
01:16:20,320 --> 01:16:22,840
before you had agents holding persistent memory.

2004
01:16:22,840 --> 01:16:24,640
An auditor walks through your infrastructure

2005
01:16:24,640 --> 01:16:27,160
and discovers violations you didn't even know existed.

2006
01:16:27,160 --> 01:16:28,680
The systems you thought were compliant

2007
01:16:28,680 --> 01:16:30,560
are now generating major findings.

2008
01:16:30,560 --> 01:16:32,360
Fixing this requires architectural changes

2009
01:16:32,360 --> 01:16:33,440
you never planned for.

2010
01:16:33,440 --> 01:16:36,120
Data leaks from places you didn't anticipate.

2011
01:16:36,120 --> 01:16:38,640
An agent with access to sensitive info gets compromised

2012
01:16:38,640 --> 01:16:41,360
and exfiltrates data to an external system.

2013
01:16:41,360 --> 01:16:42,720
But that's not the full exposure.

2014
01:16:42,720 --> 01:16:44,560
That agent also calls other agents.

2015
01:16:44,560 --> 01:16:47,040
It passed sensitive data to those downstream agents

2016
01:16:47,040 --> 01:16:48,560
before you detected the threat.

2017
01:16:48,560 --> 01:16:50,480
Those agents cashed that data in memory.

2018
01:16:50,480 --> 01:16:53,040
That memory was synchronized across multiple devices.

2019
01:16:53,040 --> 01:16:55,080
Now the exposure spans your entire system.

2020
01:16:55,080 --> 01:16:57,760
The scope of the breach is almost impossible to quantify

2021
01:16:57,760 --> 01:17:00,920
because you have no visibility into where that data moved.

2022
01:17:00,920 --> 01:17:02,960
Finally, there is organizational debt.

2023
01:17:02,960 --> 01:17:04,480
Technical debt in agent architecture

2024
01:17:04,480 --> 01:17:06,160
is different from a messy database.

2025
01:17:06,160 --> 01:17:07,680
You can re-architect a database.

2026
01:17:07,680 --> 01:17:09,400
You can refactor a monolithic app.

2027
01:17:09,400 --> 01:17:12,760
But an agent fabric built without structure is much harder to fix.

2028
01:17:12,760 --> 01:17:15,160
When agents are scattered across business units

2029
01:17:15,160 --> 01:17:17,240
with different governance frameworks,

2030
01:17:17,240 --> 01:17:20,240
where identity is inconsistent and policies conflict,

2031
01:17:20,240 --> 01:17:22,320
you need organizational alignment to fix it.

2032
01:17:22,320 --> 01:17:25,040
You have to get business leaders to agree on new standards.

2033
01:17:25,040 --> 01:17:26,600
You have to retire agents

2034
01:17:26,600 --> 01:17:28,480
that people have already come to depend on.

2035
01:17:28,480 --> 01:17:30,600
You end up rebuilding systems from the ground up

2036
01:17:30,600 --> 01:17:31,920
while trying to keep the lights on.

2037
01:17:31,920 --> 01:17:33,960
The recovery timeline is measured in years.

2038
01:17:33,960 --> 01:17:35,640
The cost is measured in constant friction

2039
01:17:35,640 --> 01:17:37,040
across the entire company.

2040
01:17:37,040 --> 01:17:38,640
These failures are not theoretical.

2041
01:17:38,640 --> 01:17:40,560
This is exactly where organizations are headed

2042
01:17:40,560 --> 01:17:43,200
when they build agents without thinking about architecture.

2043
01:17:43,200 --> 01:17:46,680
It's the path you follow when you optimize for speed over structure.

2044
01:17:46,680 --> 01:17:47,520
Conclusion.

2045
01:17:47,520 --> 01:17:49,080
The fabric, not the chat.

2046
01:17:49,080 --> 01:17:51,280
The shift from chat to fabric is not incremental.

2047
01:17:51,280 --> 01:17:52,360
It's structural.

2048
01:17:52,360 --> 01:17:53,800
Organizations that understand this

2049
01:17:53,800 --> 01:17:56,880
are building persistent multi-device systems with unified governance.

2050
01:17:56,880 --> 01:17:57,800
Those that don't

2051
01:17:57,800 --> 01:17:59,640
are just building expensive chatbots

2052
01:17:59,640 --> 01:18:02,080
that will fail the moment they try to scale.

2053
01:18:02,080 --> 01:18:03,560
The GitHub co-pilot SDK

2054
01:18:03,560 --> 01:18:05,160
provided the technical blueprint,

2055
01:18:05,160 --> 01:18:07,600
agent 365 provided the governance model.

2056
01:18:07,600 --> 01:18:10,560
The rest is just execution, identity, persistence,

2057
01:18:10,560 --> 01:18:12,320
orchestration, control.

2058
01:18:12,320 --> 01:18:14,240
The question isn't whether agents are coming,

2059
01:18:14,240 --> 01:18:15,480
they're already here.

2060
01:18:15,480 --> 01:18:17,080
The question is whether you'll be ready.

2061
01:18:17,080 --> 01:18:18,800
If this changed how you think about agents,

2062
01:18:18,800 --> 01:18:20,760
follow me, Mirko Peters, on LinkedIn.

2063
01:18:20,760 --> 01:18:24,000
I want to hear how you're building agent fabric in your organization.

2064
01:18:24,000 --> 01:18:25,320
And if you want more of this,

2065
01:18:25,320 --> 01:18:26,200
leave a review.

2066
01:18:26,200 --> 01:18:27,440
It helps more people find it.