1
00:00:00,000 --> 00:00:02,800
The documentation tells you to use a local STDO proxy,

2
00:00:02,800 --> 00:00:04,080
install it on your machine,

3
00:00:04,080 --> 00:00:06,920
wire it to Claude Desktop, connected to Dataverse.

4
00:00:06,920 --> 00:00:09,360
That guidance was sound a year ago, it's broken now.

5
00:00:09,360 --> 00:00:11,840
The issue isn't that the proxy fails to work technically,

6
00:00:11,840 --> 00:00:14,280
it works fine, the issue is the architecture behind it.

7
00:00:14,280 --> 00:00:16,080
Your building single threaded integrations

8
00:00:16,080 --> 00:00:17,760
when your enterprise needs a fabric.

9
00:00:17,760 --> 00:00:20,640
You're optimizing for the latency on one developer's laptop

10
00:00:20,640 --> 00:00:23,200
when you should be optimizing for a thousand agents.

11
00:00:23,200 --> 00:00:25,280
They all need to access the same business data

12
00:00:25,280 --> 00:00:26,720
across a govern platform.

13
00:00:26,720 --> 00:00:27,520
What changed?

14
00:00:27,520 --> 00:00:28,320
Two things.

15
00:00:28,320 --> 00:00:29,280
The clients got better.

16
00:00:29,280 --> 00:00:31,440
Claude GitHub Copilot and the rest all support

17
00:00:31,440 --> 00:00:33,120
remote HTTP endpoints now.

18
00:00:33,120 --> 00:00:35,760
The proxy isn't a necessity anymore, it's a liability.

19
00:00:35,760 --> 00:00:38,720
Second, enterprises figured out that if you're serious about AI,

20
00:00:38,720 --> 00:00:41,440
you can't afford one-off integrations for every LLM.

21
00:00:41,440 --> 00:00:44,640
You need a contract, a single endpoint, a model that scales.

22
00:00:44,640 --> 00:00:47,440
This is the story of that shift, why the proxy became a bottleneck,

23
00:00:47,440 --> 00:00:50,240
why the streamable HTTP endpoint is the only architecture

24
00:00:50,240 --> 00:00:51,280
that works at scale,

25
00:00:51,280 --> 00:00:53,040
and why this matters to your enterprise.

26
00:00:53,040 --> 00:00:56,720
Because Dataverse stops being the database under power apps

27
00:00:56,720 --> 00:00:59,520
and becomes the agentic backbone of your entire platform.

28
00:00:59,520 --> 00:01:02,480
One endpoint, any LLM, same governance, same security,

29
00:01:02,480 --> 00:01:05,840
same audit trail, the proxy is dead, the fabric is now.

30
00:01:05,840 --> 00:01:08,640
The STDIO proxy model, why it existed?

31
00:01:08,640 --> 00:01:10,800
The STDIO proxy exists for a reason.

32
00:01:10,800 --> 00:01:12,400
It was born from a real constraint.

33
00:01:12,400 --> 00:01:15,120
When MCP first appeared, local clients needed a way

34
00:01:15,120 --> 00:01:16,560
to talk to cloud services.

35
00:01:16,560 --> 00:01:18,320
Claude Desktop runs on your machine,

36
00:01:18,320 --> 00:01:19,840
while Dataverse lives in the cloud,

37
00:01:19,840 --> 00:01:21,600
so you have to bridge them somehow.

38
00:01:21,600 --> 00:01:23,520
You create a local process, a proxy.

39
00:01:23,520 --> 00:01:25,120
It sits on your machine and translates

40
00:01:25,120 --> 00:01:27,200
between the agent and the remote API.

41
00:01:27,200 --> 00:01:29,760
STDIO is the simplest possible mechanism for this.

42
00:01:29,760 --> 00:01:34,080
Standard input, standard output, pipes, no network, no HTTP,

43
00:01:34,080 --> 00:01:35,680
no TLS negotiation,

44
00:01:35,680 --> 00:01:38,640
just two processes on the same machine talking through streams.

45
00:01:38,640 --> 00:01:40,800
From a simplicity standpoint, this was elegant.

46
00:01:40,800 --> 00:01:43,280
One process per user, one session per connection,

47
00:01:43,280 --> 00:01:45,920
an isolated fault domain, if the proxy crashes,

48
00:01:45,920 --> 00:01:47,680
only that user is affected.

49
00:01:47,680 --> 00:01:49,120
There is no shared infrastructure

50
00:01:49,120 --> 00:01:51,920
and no blast radius that spreads across your organization.

51
00:01:51,920 --> 00:01:53,600
The virtue of the proxy was obvious

52
00:01:53,600 --> 00:01:56,000
because it removed operational complexity.

53
00:01:56,000 --> 00:01:58,080
You didn't need to manage HTTP servers

54
00:01:58,080 --> 00:02:00,000
or worry about horizontal scaling.

55
00:02:00,000 --> 00:02:02,080
You didn't need certificates or load balances

56
00:02:02,080 --> 00:02:03,360
or uptime guarantees.

57
00:02:03,360 --> 00:02:04,720
You just installed a tool,

58
00:02:04,720 --> 00:02:06,960
ran it, plugged in your credentials, done.

59
00:02:06,960 --> 00:02:09,760
But simplicity is not a strategy, it's a constraint.

60
00:02:09,760 --> 00:02:12,400
The proxy model assumes your building for one person,

61
00:02:12,400 --> 00:02:14,800
one machine, one integration.

62
00:02:14,800 --> 00:02:16,240
The mental model is a tool.

63
00:02:16,240 --> 00:02:19,040
The utility you install, use, and then discard.

64
00:02:19,040 --> 00:02:19,920
It doesn't compose.

65
00:02:19,920 --> 00:02:22,080
If you want Claude Desktop to access Dataverse

66
00:02:22,080 --> 00:02:23,840
and GitHub Copilot to access Dataverse,

67
00:02:23,840 --> 00:02:26,800
you run two separate proxies, two separate orth flows,

68
00:02:26,800 --> 00:02:28,240
two separate connection pools,

69
00:02:28,240 --> 00:02:30,800
two separate instances of every piece of infrastructure

70
00:02:30,800 --> 00:02:31,440
that could fail.

71
00:02:31,440 --> 00:02:33,440
It doesn't scale, it doesn't govern.

72
00:02:33,440 --> 00:02:34,800
And it doesn't answer the question,

73
00:02:34,800 --> 00:02:36,240
which Claude instance accessed,

74
00:02:36,240 --> 00:02:38,720
which record, when, under whose identity?

75
00:02:38,720 --> 00:02:40,880
The proxy assumes you'll never need to answer those questions.

76
00:02:40,880 --> 00:02:42,720
That assumption is what breaks.

77
00:02:42,720 --> 00:02:45,600
The latency lie, why STDO, looks faster?

78
00:02:45,600 --> 00:02:48,240
The latency argument for STDO is real.

79
00:02:48,240 --> 00:02:50,720
But in reality, it's a trap.

80
00:02:50,720 --> 00:02:53,680
If you look at the micro benchmarks, the numbers seem clear.

81
00:02:53,680 --> 00:02:56,320
A STDO call between two processes on the same machine

82
00:02:56,320 --> 00:02:58,320
takes about one to four milliseconds.

83
00:02:58,320 --> 00:03:00,960
HTTP adds overhead because you have the network,

84
00:03:00,960 --> 00:03:03,920
roundtrip, TLS negotiation, and parsing to deal with.

85
00:03:03,920 --> 00:03:06,960
You're looking at 50 to 100 milliseconds per call.

86
00:03:06,960 --> 00:03:09,920
On paper, that is a 25 to 100 times difference.

87
00:03:09,920 --> 00:03:11,680
On the surface, STDO wins.

88
00:03:11,680 --> 00:03:13,680
But this is where the benchmark tells you a lie.

89
00:03:13,680 --> 00:03:15,840
Those numbers only measure transport latency.

90
00:03:15,840 --> 00:03:17,520
They show you the pure protocol cost.

91
00:03:17,520 --> 00:03:19,120
What they don't measure is what actually happens

92
00:03:19,120 --> 00:03:20,480
in a real enterprise system.

93
00:03:20,480 --> 00:03:22,240
In the real world, a dataverse query

94
00:03:22,240 --> 00:03:24,000
doesn't execute in five milliseconds.

95
00:03:24,000 --> 00:03:25,840
A typical query to dataverse runs

96
00:03:25,840 --> 00:03:28,640
somewhere between 515 milliseconds.

97
00:03:28,640 --> 00:03:30,240
That is just the back-end work.

98
00:03:30,240 --> 00:03:32,000
The database, the business rules,

99
00:03:32,000 --> 00:03:34,720
and the security checks that happen after your request arrives.

100
00:03:34,720 --> 00:03:35,760
So let's add it up.

101
00:03:35,760 --> 00:03:38,800
You send a request over STDO, which takes one millisecond,

102
00:03:38,800 --> 00:03:40,880
dataverse executes for 1,000 milliseconds.

103
00:03:40,880 --> 00:03:43,120
The response comes back in another millisecond.

104
00:03:43,120 --> 00:03:45,600
Your total time is 1,000 and two milliseconds.

105
00:03:45,600 --> 00:03:47,360
Now do the same thing over HTTP.

106
00:03:47,360 --> 00:03:49,200
The request takes 100 milliseconds,

107
00:03:49,200 --> 00:03:51,440
dataverse executes for 1,000 milliseconds.

108
00:03:51,440 --> 00:03:52,800
The response takes another 100.

109
00:03:52,800 --> 00:03:54,960
Your total is 1,200 milliseconds.

110
00:03:54,960 --> 00:03:58,400
That is 200 extra milliseconds out of a total of 1,200.

111
00:03:58,400 --> 00:04:00,000
It's about 17% overhead.

112
00:04:00,000 --> 00:04:01,440
In an enterprise workload where you're

113
00:04:01,440 --> 00:04:03,040
chaining multiple queries together,

114
00:04:03,040 --> 00:04:04,640
that overhead is just noise.

115
00:04:04,640 --> 00:04:06,320
But there's another cost STDO carries

116
00:04:06,320 --> 00:04:07,600
that doesn't show up in the benchmark.

117
00:04:07,600 --> 00:04:09,120
Every time you start a proxy process,

118
00:04:09,120 --> 00:04:10,560
you pay a start-up cost.

119
00:04:10,560 --> 00:04:11,600
The process launches,

120
00:04:11,600 --> 00:04:13,120
the dataverse client libraries load,

121
00:04:13,120 --> 00:04:15,600
and the authentication context has to initialize.

122
00:04:15,600 --> 00:04:17,440
The first query always pays a penalty,

123
00:04:17,440 --> 00:04:18,880
and sometimes it's a big one.

124
00:04:18,880 --> 00:04:21,120
In Kubernetes environments where containers spin up

125
00:04:21,120 --> 00:04:22,320
and down constantly,

126
00:04:22,320 --> 00:04:23,920
you pay this cost over and over again.

127
00:04:23,920 --> 00:04:26,480
With HTTP, you run one long-lived server.

128
00:04:26,480 --> 00:04:28,080
Clients authenticate once,

129
00:04:28,080 --> 00:04:29,360
connections pool,

130
00:04:29,360 --> 00:04:30,880
and every call after that

131
00:04:30,880 --> 00:04:33,040
reuses the infrastructure you already built.

132
00:04:33,040 --> 00:04:34,560
The research on this is unambiguous.

133
00:04:34,560 --> 00:04:36,800
A MongoDB case study from 2026,

134
00:04:36,800 --> 00:04:39,280
compared STDO and HTTP endpoints,

135
00:04:39,280 --> 00:04:41,120
handling the same data access patterns.

136
00:04:41,120 --> 00:04:44,320
STDO averaged 6.4 seconds per query,

137
00:04:44,320 --> 00:04:46,880
while HTTP averaged 1.8 seconds.

138
00:04:46,880 --> 00:04:49,600
HTTP was 3 to 4 times faster end-to-end.

139
00:04:49,600 --> 00:04:51,840
It wasn't slower, it was faster.

140
00:04:51,840 --> 00:04:53,520
The HTTP deployment was tuned

141
00:04:53,520 --> 00:04:55,200
with connection pooling, caching,

142
00:04:55,200 --> 00:04:56,320
and horizontal scaling.

143
00:04:56,320 --> 00:04:59,120
The STDO deployment paid the cost of process management

144
00:04:59,120 --> 00:05:00,160
and cold starts

145
00:05:00,160 --> 00:05:02,080
that aren't obvious in the raw numbers.

146
00:05:02,080 --> 00:05:03,760
The latency advantage STDO

147
00:05:03,760 --> 00:05:04,800
appears to have evaporates

148
00:05:04,800 --> 00:05:06,560
when you measure what actually matters.

149
00:05:06,560 --> 00:05:08,080
The gap narrows even further

150
00:05:08,080 --> 00:05:10,480
when you add monitoring, retry logic,

151
00:05:10,480 --> 00:05:12,000
and resilience patterns.

152
00:05:12,000 --> 00:05:14,240
If you add a retry to your HTTP call,

153
00:05:14,240 --> 00:05:16,560
it costs you 30 milliseconds extra on a failure.

154
00:05:16,880 --> 00:05:19,040
If you add that same retry to STDO,

155
00:05:19,040 --> 00:05:20,800
you're spinning up a whole new process.

156
00:05:20,800 --> 00:05:22,800
That costs you more in startup time alone

157
00:05:22,800 --> 00:05:24,240
than the entire HTTP call,

158
00:05:24,240 --> 00:05:26,160
STDO wins the latency tournament,

159
00:05:26,160 --> 00:05:28,800
but latency isn't the tournament that matters.

160
00:05:28,800 --> 00:05:30,000
The scaling problem,

161
00:05:30,000 --> 00:05:32,240
why proxies die at enterprise scale?

162
00:05:32,240 --> 00:05:33,840
Once you move beyond one developer

163
00:05:33,840 --> 00:05:35,520
using Claude desktop on a laptop,

164
00:05:35,520 --> 00:05:37,440
the proxy architecture collapses.

165
00:05:37,440 --> 00:05:39,280
It fails because of the model behind it.

166
00:05:39,280 --> 00:05:40,880
Here's what happens when you scale.

167
00:05:40,880 --> 00:05:42,720
Imagine you have 50 people in your organization

168
00:05:42,720 --> 00:05:44,400
who want to use Claude with dataverse.

169
00:05:44,400 --> 00:05:46,800
Each person installs the proxy on their own machine.

170
00:05:46,800 --> 00:05:48,480
Now you have 50 separate processes

171
00:05:48,480 --> 00:05:50,080
running somewhere in your infrastructure.

172
00:05:50,080 --> 00:05:52,560
Each one is spawning its own connection to dataverse,

173
00:05:52,560 --> 00:05:54,800
each one is managing its own authentication,

174
00:05:54,800 --> 00:05:56,720
and each one is an isolated instance

175
00:05:56,720 --> 00:05:58,320
that nobody can manage centrally.

176
00:05:58,320 --> 00:05:59,520
Kubernetes doesn't like this.

177
00:05:59,520 --> 00:06:00,880
If you're running these proxies

178
00:06:00,880 --> 00:06:02,480
in containerized environments,

179
00:06:02,480 --> 00:06:04,080
you're creating a logistics nightmare.

180
00:06:04,080 --> 00:06:07,200
50 short-lived processes means 50 scheduling decisions,

181
00:06:07,200 --> 00:06:08,480
50 resource allocations,

182
00:06:08,480 --> 00:06:09,840
and 50 shutdown events.

183
00:06:09,840 --> 00:06:11,600
Every process that spins up

184
00:06:11,600 --> 00:06:13,040
needs its own configuration

185
00:06:13,040 --> 00:06:14,640
and every process that fails

186
00:06:14,640 --> 00:06:16,720
needs its own monitoring and recovery logic.

187
00:06:16,720 --> 00:06:18,640
If you scale this to 500 users,

188
00:06:18,640 --> 00:06:21,520
you are managing 500 independent failure domains.

189
00:06:21,520 --> 00:06:23,120
At that scale, process management

190
00:06:23,120 --> 00:06:25,760
stops being administration and becomes firefighting.

191
00:06:25,760 --> 00:06:28,000
The connection pooling problem becomes acute.

192
00:06:28,000 --> 00:06:30,160
Every proxy spawns its own dataverse client

193
00:06:30,160 --> 00:06:32,880
with no sharing and no pooling across users.

194
00:06:32,880 --> 00:06:35,200
Your dataverse environment sees 500 independent

195
00:06:35,200 --> 00:06:38,000
authentication sessions instead of one managed gateway.

196
00:06:38,000 --> 00:06:40,960
Your token budget gets consumed 500 times faster

197
00:06:40,960 --> 00:06:43,600
and your rate limits hit walls you didn't anticipate.

198
00:06:43,600 --> 00:06:45,040
The platform starts throttling you

199
00:06:45,040 --> 00:06:46,400
because it can't tell the difference

200
00:06:46,400 --> 00:06:48,960
between legitimate work and a coordinated attack.

201
00:06:48,960 --> 00:06:50,560
The memory footprint also explodes.

202
00:06:50,560 --> 00:06:54,000
Each proxy process consumes resources for process overhead,

203
00:06:54,000 --> 00:06:56,240
client libraries, and cached metadata.

204
00:06:56,240 --> 00:06:58,160
When you multiply that by 500,

205
00:06:58,160 --> 00:06:59,520
you're running infrastructure

206
00:06:59,520 --> 00:07:02,160
that is expensive to host and difficult to manage.

207
00:07:02,160 --> 00:07:03,840
Resource contention starts to appear.

208
00:07:03,840 --> 00:07:05,920
If your users are concentrated in the same region,

209
00:07:05,920 --> 00:07:08,240
you're fighting for bandwidth on shared networks.

210
00:07:08,240 --> 00:07:09,200
Your cloud bills go up

211
00:07:09,200 --> 00:07:12,000
and you have nothing to show for it, except operational complexity.

212
00:07:12,000 --> 00:07:14,320
But the worst cost is invisible until you need it.

213
00:07:14,320 --> 00:07:16,640
Observability breaks completely.

214
00:07:16,640 --> 00:07:17,760
When something goes wrong,

215
00:07:17,760 --> 00:07:20,320
like a data corruption incident or a security breach,

216
00:07:20,320 --> 00:07:23,920
you need to know which user accessed which record at what time?

217
00:07:23,920 --> 00:07:25,760
With 500 independent proxies,

218
00:07:25,760 --> 00:07:28,720
that information is scattered across 500 different machines.

219
00:07:28,720 --> 00:07:30,400
Some logs live on client laptops,

220
00:07:30,400 --> 00:07:32,480
some live in container logs that get deleted,

221
00:07:32,480 --> 00:07:33,840
and some are still in flight.

222
00:07:33,840 --> 00:07:35,280
None of it is centralized.

223
00:07:35,280 --> 00:07:36,640
Recreating the audit trail

224
00:07:36,640 --> 00:07:38,960
becomes an investigative archaeology project

225
00:07:38,960 --> 00:07:40,080
instead of a simple search.

226
00:07:40,080 --> 00:07:41,920
Governance also becomes impossible to enforce.

227
00:07:41,920 --> 00:07:43,840
You might want to say that a cloud instance

228
00:07:43,840 --> 00:07:45,520
can access the accounts table,

229
00:07:45,520 --> 00:07:47,440
but not the opportunities table.

230
00:07:47,440 --> 00:07:48,640
With distributed proxies,

231
00:07:48,640 --> 00:07:51,280
you have no central place to make that decision stick.

232
00:07:51,280 --> 00:07:54,320
You have no way to verify that the policy is being followed,

233
00:07:54,320 --> 00:07:56,560
and you have no audit trail to prove it.

234
00:07:56,560 --> 00:07:58,080
You're flying blind.

235
00:07:58,080 --> 00:08:00,880
The proxy becomes a single point of failure for every user,

236
00:08:00,880 --> 00:08:02,240
rather than a resilient service.

237
00:08:02,240 --> 00:08:05,120
It's not one gateway going down where everything stops.

238
00:08:05,120 --> 00:08:07,680
It's one user experiencing a broken proxy,

239
00:08:07,680 --> 00:08:10,080
and you have no way to diagnose why it happened.

240
00:08:10,080 --> 00:08:12,000
You can't tell if the installation is wrong,

241
00:08:12,000 --> 00:08:13,760
their authentication is stale,

242
00:08:13,760 --> 00:08:15,920
or if there is a network issue on their machine.

243
00:08:15,920 --> 00:08:18,400
You can't see across the system to answer those questions.

244
00:08:18,400 --> 00:08:20,720
At scale, the proxy stops being infrastructure.

245
00:08:20,720 --> 00:08:22,160
It becomes a liability.

246
00:08:22,160 --> 00:08:24,560
This is where streamable HTTP changes the game.

247
00:08:24,560 --> 00:08:28,400
Enter streamable HTTP, the remote endpoint.

248
00:08:28,400 --> 00:08:30,960
The architecture of this new approach is radically simpler.

249
00:08:30,960 --> 00:08:33,760
Instead of asking every client to run its own proxy,

250
00:08:33,760 --> 00:08:36,320
data versa itself exposes an HTTP endpoint.

251
00:08:36,320 --> 00:08:38,560
The endpoint lives at a predictable URL.

252
00:08:38,560 --> 00:08:40,320
For your organization, it looks like this.

253
00:08:40,320 --> 00:08:42,080
HTTPS/orgID.

254
00:08:42,080 --> 00:08:46,160
cpmlinomics.com/apirge/mcp

255
00:08:46,160 --> 00:08:47,120
That is it.

256
00:08:47,120 --> 00:08:48,880
One endpoint, stateless.

257
00:08:48,880 --> 00:08:51,920
Ready to accept mcp requests from any authenticated client?

258
00:08:51,920 --> 00:08:54,880
The moment you publish that endpoint, everything changes.

259
00:08:54,880 --> 00:08:58,400
A single HTTP endpoint can serve many clients at the same time.

260
00:08:58,400 --> 00:09:01,440
Cloud Desktop, Connects, GitHub Co-Pilot Connects,

261
00:09:01,440 --> 00:09:03,760
a custom orchestrator in your pipeline connects.

262
00:09:03,760 --> 00:09:05,520
They are all hitting the same service.

263
00:09:05,520 --> 00:09:06,800
They are running the same code.

264
00:09:06,800 --> 00:09:09,600
They are using the same connection pools to data versa.

265
00:09:09,600 --> 00:09:12,640
You do not multiply your infrastructure by the number of users.

266
00:09:12,640 --> 00:09:14,000
You scale the endpoint itself.

267
00:09:14,000 --> 00:09:17,360
If you need more power, you add capacity behind a load balancer.

268
00:09:17,360 --> 00:09:18,720
The clients do not care.

269
00:09:18,720 --> 00:09:20,880
They just keep sending requests to the same URL.

270
00:09:20,880 --> 00:09:23,040
This is horizontally scalable architecture.

271
00:09:23,040 --> 00:09:25,840
It is table stakes for any production service in the enterprise.

272
00:09:25,840 --> 00:09:28,160
But for AI integrations with business data,

273
00:09:28,160 --> 00:09:29,520
it has been absent until now.

274
00:09:29,520 --> 00:09:31,760
The proxy model forced you into vertical scaling.

275
00:09:31,760 --> 00:09:35,360
Bigger machines, more memory, more processes running on client devices.

276
00:09:35,360 --> 00:09:38,720
The HTTP model lets you do what every mature platform does.

277
00:09:38,720 --> 00:09:40,960
You distribute work across many instances.

278
00:09:40,960 --> 00:09:42,960
You balance the load, you fail over transparently.

279
00:09:42,960 --> 00:09:45,280
Cloud Desktop natively supports this.

280
00:09:45,280 --> 00:09:46,240
So does Cloud Code.

281
00:09:46,240 --> 00:09:47,760
GitHub Co-Pilot in all its forms.

282
00:09:47,760 --> 00:09:51,760
VS Code, the app, the CLI, they all speak HTTP to MCP servers.

283
00:09:51,760 --> 00:09:54,000
These clients already have the capability built in.

284
00:09:54,000 --> 00:09:56,720
They are just waiting for you to point them at the right endpoint.

285
00:09:56,720 --> 00:09:58,960
No installation, no local proxy to manage.

286
00:09:58,960 --> 00:10:01,440
You configure the URL once in the client settings

287
00:10:01,440 --> 00:10:02,800
and the client handles the rest.

288
00:10:02,800 --> 00:10:04,400
The authentication flow is elegant.

289
00:10:04,400 --> 00:10:06,720
You authenticate once the client receives a token.

290
00:10:06,720 --> 00:10:07,920
It caches that token.

291
00:10:07,920 --> 00:10:11,840
Subsequent requests use that cashed token until it expires or gets revoked.

292
00:10:11,840 --> 00:10:14,400
This is how web applications have worked for 20 years.

293
00:10:14,400 --> 00:10:15,600
It is a solved problem.

294
00:10:15,600 --> 00:10:18,720
The client libraries handle token refresh automatically.

295
00:10:18,720 --> 00:10:20,400
Users do not see the machinery.

296
00:10:20,400 --> 00:10:21,840
They see seamless access.

297
00:10:21,840 --> 00:10:24,000
The contrast with the proxy is instructive.

298
00:10:24,000 --> 00:10:27,600
With STDIO, every time a process starts, it authenticates independently.

299
00:10:27,600 --> 00:10:29,600
Every process holds its own alt context.

300
00:10:29,600 --> 00:10:32,800
Every process is a separate disconnected session to dataverse.

301
00:10:32,800 --> 00:10:36,640
With HTTP, you are building on top of standard OAuth infrastructure.

302
00:10:36,640 --> 00:10:37,920
Token management is centralized.

303
00:10:37,920 --> 00:10:39,520
Revocation is immediate.

304
00:10:39,520 --> 00:10:42,560
If a user loses access, that replication applies instantly

305
00:10:42,560 --> 00:10:44,320
across every connected client.

306
00:10:44,320 --> 00:10:46,480
Try doing that with distributed proxies.

307
00:10:46,480 --> 00:10:51,120
Under the hood, HTTP2 multiplexing means you are not opening a new connection

308
00:10:51,120 --> 00:10:52,560
for every single request.

309
00:10:52,560 --> 00:10:54,800
The client opens one connection to the endpoint

310
00:10:54,800 --> 00:10:57,200
and sends many requests over that same pipe.

311
00:10:57,200 --> 00:11:01,680
Connection pooling on the server side means dataverse does not see a flood of independent sessions.

312
00:11:01,680 --> 00:11:05,280
It sees a manageable number of persistent connections from the MCP server.

313
00:11:05,280 --> 00:11:08,400
And the server distributes the work across those connections efficiently.

314
00:11:08,400 --> 00:11:12,160
Load balances in front of the endpoint root requests to healthy instances.

315
00:11:12,160 --> 00:11:14,720
If one server fails, the traffic shifts to another.

316
00:11:14,720 --> 00:11:17,200
You have moved from a tool to an enterprise service.

317
00:11:17,200 --> 00:11:18,800
It is the same dataverse underneath.

318
00:11:18,800 --> 00:11:22,400
Same security model, same business rules, same audit trails.

319
00:11:22,400 --> 00:11:23,440
The tool surface.

320
00:11:23,440 --> 00:11:28,400
The MCP tools that let agents discover tables, query records, and create entities.

321
00:11:28,400 --> 00:11:30,480
Is identical to what the proxy exposes.

322
00:11:30,480 --> 00:11:31,760
You have not lost any functionality.

323
00:11:31,760 --> 00:11:34,000
You have gained the ability to operate at scale.

324
00:11:34,000 --> 00:11:35,040
To govern centrally.

325
00:11:35,040 --> 00:11:36,640
To observe comprehensively.

326
00:11:36,640 --> 00:11:38,880
And to manage everything as a unified platform.

327
00:11:38,880 --> 00:11:42,720
This shift from local execution to a remote service is architectural bedrock.

328
00:11:42,720 --> 00:11:43,840
Everything that follows.

329
00:11:43,840 --> 00:11:47,120
The governance, the multi-LLM strategy, the token efficiency,

330
00:11:47,120 --> 00:11:48,960
it all depends on this foundation.

331
00:11:48,960 --> 00:11:50,160
PKCE.

332
00:11:50,160 --> 00:11:52,640
The authentication that doesn't require secrets.

333
00:11:52,640 --> 00:11:55,440
The HTTP endpoint solves the scaling problem.

334
00:11:55,440 --> 00:11:59,680
But it introduces a security problem that traditional applications never had to solve.

335
00:11:59,680 --> 00:12:02,160
How do you authenticate when your client cannot keep a secret?

336
00:12:02,160 --> 00:12:03,840
This is not a hypothetical concern.

337
00:12:03,840 --> 00:12:06,000
Claude desktop is installed on a user's machine.

338
00:12:06,000 --> 00:12:10,080
The configuration file that points to your dataverse endpoint lives on that same machine.

339
00:12:10,080 --> 00:12:12,960
If that configuration file contains a client's secret.

340
00:12:12,960 --> 00:12:16,160
Which is basically a password that proves the application's identity.

341
00:12:16,160 --> 00:12:16,880
You have a problem.

342
00:12:16,880 --> 00:12:19,840
Anyone with access to that file can impersonate the application

343
00:12:19,840 --> 00:12:22,240
and request tokens from your authorization server.

344
00:12:22,240 --> 00:12:23,840
The same applies to GitHub co-pilot.

345
00:12:23,840 --> 00:12:25,120
The same applies to any client.

346
00:12:25,120 --> 00:12:26,480
You do not directly control.

347
00:12:27,120 --> 00:12:31,920
Traditional OAuth solved this by assuming the client was a web server running in a secure data center.

348
00:12:31,920 --> 00:12:35,360
The server could store secrets in environment variables or encrypted vaults.

349
00:12:35,360 --> 00:12:36,960
The secret never left the server.

350
00:12:36,960 --> 00:12:40,720
A public application could not use OAuth because it could not protect a secret.

351
00:12:40,720 --> 00:12:45,120
PKCE, proof-key for code exchange pronounced pixie, removes that requirement.

352
00:12:45,120 --> 00:12:49,440
It lets public clients authenticate securely without storing any secret at all.

353
00:12:49,440 --> 00:12:50,640
Here is how it works.

354
00:12:50,640 --> 00:12:55,520
Instead of a static secret, the client generates a random value called a code verifier.

355
00:12:55,520 --> 00:12:58,000
It hashes that verifier into a code challenge.

356
00:12:58,000 --> 00:13:00,080
The challenge goes into the authorization request.

357
00:13:00,080 --> 00:13:01,840
The authorization server receives the request,

358
00:13:01,840 --> 00:13:04,400
verifies who you are, and returns an authorization code.

359
00:13:04,400 --> 00:13:08,160
The client then redeems that code by sending the original verifier alongside it.

360
00:13:08,160 --> 00:13:12,320
The authorization server hashes that verifier, checks that it matches the challenge,

361
00:13:12,320 --> 00:13:13,440
and issues a token.

362
00:13:13,440 --> 00:13:15,520
The security comes from the verification.

363
00:13:15,520 --> 00:13:20,080
If an attacker intercepts the authorization code, they cannot use it because they do not have the verifier.

364
00:13:20,080 --> 00:13:22,080
The code is useless without the verifier.

365
00:13:22,080 --> 00:13:24,400
Only the original client can provide the verifier.

366
00:13:24,400 --> 00:13:26,640
Because only the original client generated it.

367
00:13:26,640 --> 00:13:28,560
The verifier never travels over the network.

368
00:13:28,560 --> 00:13:32,160
The challenge, which is derived from the verifier, is what crosses the wire.

369
00:13:32,160 --> 00:13:34,880
And you cannot reverse a hash to recover the original verifier.

370
00:13:34,880 --> 00:13:35,920
This is not theoretical.

371
00:13:35,920 --> 00:13:41,920
It is formalized in RFC 76636, and is now a required component of OAuth 2.1.

372
00:13:41,920 --> 00:13:43,920
Every major identity provider supports it.

373
00:13:43,920 --> 00:13:47,520
EntraID supports it, Claude supports it, GitHub co-pilot supports it.

374
00:13:47,520 --> 00:13:51,680
Data versus MCP server is built with the assumption that clients will use PKCE.

375
00:13:51,680 --> 00:13:53,840
The practical implication is straightforward.

376
00:13:53,840 --> 00:13:57,200
Your Dataverse MCP endpoint asks EntraID for tokens.

377
00:13:57,200 --> 00:13:58,960
EntraID authenticates the user.

378
00:13:58,960 --> 00:14:03,680
The user's browser opens, they sign in, they are redirected back to the client with an authorization code.

379
00:14:03,680 --> 00:14:07,600
The client exchanges that code with the verifier it generated and receives a token.

380
00:14:07,600 --> 00:14:09,600
No secret sits in the configuration file.

381
00:14:09,600 --> 00:14:10,640
No secret leaks into logs.

382
00:14:10,640 --> 00:14:13,680
No secret appears in the client's prompts or behavior.

383
00:14:13,680 --> 00:14:16,240
This is what enables the multi-LLM integration model.

384
00:14:16,240 --> 00:14:18,800
You can point Claude at your Dataverse endpoint.

385
00:14:18,800 --> 00:14:21,440
You can point GitHub co-pilot at the same endpoint.

386
00:14:21,440 --> 00:14:23,760
You can point the custom orchestrator at the same endpoint.

387
00:14:23,760 --> 00:14:25,200
They are all using PKCE.

388
00:14:25,200 --> 00:14:28,240
They are all securing themselves without requiring any shared secret

389
00:14:28,240 --> 00:14:31,920
that you have to manage, rotate, and protect across every client installation.

390
00:14:31,920 --> 00:14:35,680
The security model that makes multi-LLM integration safe is already built in.

391
00:14:35,680 --> 00:14:37,200
You just need to configure it correctly.

392
00:14:37,200 --> 00:14:40,560
Registering your EntraID app, the Blueprint.

393
00:14:40,560 --> 00:14:42,000
Now you're going to make this real.

394
00:14:42,000 --> 00:14:43,280
The theory ends here.

395
00:14:43,280 --> 00:14:44,720
The Blueprint begins.

396
00:14:44,720 --> 00:14:49,120
Log in to the Azure portal and navigate to EntraID to create a new application registration.

397
00:14:49,120 --> 00:14:51,920
This is the same process you'd use for any OAuth client,

398
00:14:51,920 --> 00:14:54,320
whether it's a web app, a mobile app, or a service.

399
00:14:54,320 --> 00:14:58,480
You're registering a new application that represents your Dataverse MCP consumers

400
00:14:58,480 --> 00:14:59,840
to the authorization system.

401
00:14:59,840 --> 00:15:04,880
So you should name it something meaningful like Dataverse MCP or ClaudePlus Dataverse integration.

402
00:15:04,880 --> 00:15:07,760
The name doesn't affect how the code runs,

403
00:15:07,760 --> 00:15:11,760
but it definitely affects your sanity when you're managing dozens of app registration

404
00:15:11,760 --> 00:15:12,960
six months from now.

405
00:15:12,960 --> 00:15:16,160
Once the app exists, you need to declare what it's allowed to do.

406
00:15:16,160 --> 00:15:19,200
This happens in API permissions, add a permission for MCP tools.

407
00:15:19,200 --> 00:15:24,400
This is the specific permission that grants MCP clients access to Dataverse through the MCP server.

408
00:15:24,400 --> 00:15:26,320
It's not a generic Dataverse permission.

409
00:15:26,320 --> 00:15:28,720
It's scoped to the MCP interface specifically.

410
00:15:28,720 --> 00:15:32,720
This granularity matters because you're saying this application can use the MCP protocol to

411
00:15:32,720 --> 00:15:35,760
interact with Dataverse, but it doesn't have a blank check for everything else.

412
00:15:35,760 --> 00:15:37,840
Copy the application ID and write it down.

413
00:15:37,840 --> 00:15:42,720
This identifier is going to appear in every client configuration you set up from here on out.

414
00:15:42,720 --> 00:15:44,880
It's the public face of your app registration,

415
00:15:44,880 --> 00:15:48,080
and it's the value that clients pass back to the authorization server to say,

416
00:15:48,080 --> 00:15:48,960
"This is who I am."

417
00:15:48,960 --> 00:15:52,080
Keep it visible. You'll reference it constantly.

418
00:15:52,080 --> 00:15:54,720
The next step happens in the Power Platform admin center,

419
00:15:54,720 --> 00:15:56,080
not the Azure portal.

420
00:15:56,080 --> 00:16:00,480
Navigate to your Dataverse environment and find the settings that govern MCP client access.

421
00:16:00,480 --> 00:16:02,480
Add your application ID to the allow list.

422
00:16:02,480 --> 00:16:03,520
This is the gate.

423
00:16:03,520 --> 00:16:05,920
Without this step, your app registration exists,

424
00:16:05,920 --> 00:16:08,960
but it's not permitted to touch this specific Dataverse environment.

425
00:16:08,960 --> 00:16:10,800
You might have multiple environments for

426
00:16:10,800 --> 00:16:12,320
development, staging, and production,

427
00:16:12,320 --> 00:16:16,560
and you can grant the same app registration access to some while denying others.

428
00:16:16,560 --> 00:16:20,960
This is how you prevent a test integration from accidentally touching production data.

429
00:16:20,960 --> 00:16:22,560
Then comes the critical configuration.

430
00:16:22,560 --> 00:16:25,120
Allow public client flows.

431
00:16:25,120 --> 00:16:28,000
Find this in the app registration's authentication settings.

432
00:16:28,000 --> 00:16:29,200
It's not enabled by default.

433
00:16:29,200 --> 00:16:30,880
You have to explicitly turn it on.

434
00:16:30,880 --> 00:16:34,560
This flag tells EntraID that this client cannot securely store secrets,

435
00:16:34,560 --> 00:16:37,920
so it needs to use PKCE based authentication flows instead.

436
00:16:37,920 --> 00:16:38,800
Without the setting,

437
00:16:38,800 --> 00:16:43,760
the PKCE flow won't work and the authorization server will reject every request from public clients.

438
00:16:43,760 --> 00:16:46,400
This setting is what makes the entire architecture possible,

439
00:16:46,400 --> 00:16:49,200
and it's the lock-and-key that allows Claude and GitHub co-pilot

440
00:16:49,200 --> 00:16:52,400
to authenticate without embedding secrets in their client code.

441
00:16:52,400 --> 00:16:53,680
Why is each step necessary?

442
00:16:53,680 --> 00:16:55,920
Because the security model depends on isolation.

443
00:16:55,920 --> 00:16:59,360
The app registration isolates this integration from others you might build,

444
00:16:59,360 --> 00:17:03,840
while the API permission isolates MCP access from other Dataverse capabilities.

445
00:17:03,840 --> 00:17:07,200
The environment allow list isolates which Dataverse tenants this app can reach,

446
00:17:07,200 --> 00:17:11,600
and the public client flows setting isolates the authentication mechanism to PKCE.

447
00:17:11,600 --> 00:17:13,840
Each step narrows the scope and adds a gate,

448
00:17:13,840 --> 00:17:16,640
and together they form a security posture where an attacker

449
00:17:16,640 --> 00:17:19,520
would need to compromise multiple independent systems to get in.

450
00:17:19,520 --> 00:17:21,040
This is not optional infrastructure.

451
00:17:21,040 --> 00:17:22,400
This is the foundation.

452
00:17:22,400 --> 00:17:26,160
If you skip any step, the architecture fails in ways that won't become obvious

453
00:17:26,160 --> 00:17:29,040
until you're deep in the integration and something breaks.

454
00:17:29,040 --> 00:17:32,080
Redirect URIs, the callback contract.

455
00:17:32,080 --> 00:17:35,040
With the app registered, you need to define the redirect URIs.

456
00:17:35,040 --> 00:17:37,360
This is where the architecture meets the real world.

457
00:17:37,360 --> 00:17:40,160
When a user authenticates through Dataverse MCP,

458
00:17:40,160 --> 00:17:43,600
they're going to see an authorization screen where they enter their credentials.

459
00:17:43,600 --> 00:17:45,120
Entra ID will verify them,

460
00:17:45,120 --> 00:17:47,520
and then the authorization server needs to send the user

461
00:17:47,520 --> 00:17:49,280
and the authorization code somewhere.

462
00:17:49,280 --> 00:17:51,280
Where? That's the redirect URI.

463
00:17:51,280 --> 00:17:53,440
Different clients have different callback URLs,

464
00:17:53,440 --> 00:17:54,560
and this isn't arbitrary.

465
00:17:54,560 --> 00:17:57,520
It's the contract between the client and the authorization server.

466
00:17:57,520 --> 00:18:00,320
Claude Desktop expects redirects to come back to HTTPS,

467
00:18:00,320 --> 00:18:04,000
ASA's Claude, IA, API, MCP, or callback.

468
00:18:04,000 --> 00:18:07,760
That's the endpoint in the Claude service that knows how to handle the authorization code,

469
00:18:07,760 --> 00:18:12,560
exchange it for a token, and send that token back to your local Claude Desktop instance.

470
00:18:12,560 --> 00:18:14,880
If you try to redirect to any other URI,

471
00:18:14,880 --> 00:18:18,160
Claude won't catch the callback and the authorization flow will just hang.

472
00:18:18,160 --> 00:18:20,800
The user will see a browser window waiting for something to happen,

473
00:18:20,800 --> 00:18:22,000
and nothing will happen.

474
00:18:22,000 --> 00:18:25,040
Claude code, which runs in your terminal, uses a different pattern.

475
00:18:25,040 --> 00:18:29,200
It expects HTTP, KAS-LASH, localhost, callback.

476
00:18:29,200 --> 00:18:30,880
The code is running locally on your machine,

477
00:18:30,880 --> 00:18:33,360
so the authorization server redirects to localhost.

478
00:18:33,360 --> 00:18:36,560
Claude code has a local HTTP listener waiting on that endpoint,

479
00:18:36,560 --> 00:18:39,280
and it catches the callback to process the authorization code,

480
00:18:39,280 --> 00:18:42,160
so the user's terminal session can be authenticated.

481
00:18:42,160 --> 00:18:48,320
GitHub Copilot uses HTTP/127.0.0.1.

482
00:18:48,320 --> 00:18:49,920
It's similar to Claude code conceptually,

483
00:18:49,920 --> 00:18:53,200
but the IP address is explicit instead of hostname based.

484
00:18:53,200 --> 00:18:55,360
Again, the difference isn't accidental,

485
00:18:55,360 --> 00:18:58,640
and it's exactly how the copilot client expects to receive its callback.

486
00:18:58,640 --> 00:19:02,400
You register all three redirect URIs in your app registration.

487
00:19:02,400 --> 00:19:04,640
When a user authenticates EntraID,

488
00:19:04,640 --> 00:19:06,880
looks at which client initiated the request

489
00:19:06,880 --> 00:19:10,080
and sends the callback to the URI registered for that specific client.

490
00:19:10,080 --> 00:19:12,400
If the callback doesn't match the registered URI,

491
00:19:12,400 --> 00:19:14,560
EntraID rejects it immediately.

492
00:19:14,560 --> 00:19:16,880
This is a security measure that prevents attackers

493
00:19:16,880 --> 00:19:18,640
from hijacking authorization flows

494
00:19:18,640 --> 00:19:20,880
by redirecting users to malicious sites.

495
00:19:20,880 --> 00:19:23,360
Why can't you use the same URI for all clients?

496
00:19:23,360 --> 00:19:26,720
Because each client has its own way of receiving and processing callbacks.

497
00:19:26,720 --> 00:19:30,320
A single URI assumes a single server waiting to catch the response,

498
00:19:30,320 --> 00:19:32,960
but you have many clients like Claude Desktop, Claude Code,

499
00:19:32,960 --> 00:19:34,960
and Copilot that aren't all servers.

500
00:19:34,960 --> 00:19:37,680
They are local applications with their own callback mechanisms,

501
00:19:37,680 --> 00:19:40,400
and each one needs its own configured URI

502
00:19:40,400 --> 00:19:42,480
that matches its specific architecture.

503
00:19:42,480 --> 00:19:44,080
For testing locally during setup,

504
00:19:44,080 --> 00:19:46,640
you might use HTTP/Localhost,

505
00:19:46,640 --> 00:19:49,280
but for production, you have to ensure the URIs align

506
00:19:49,280 --> 00:19:51,600
with where each client actually runs.

507
00:19:51,600 --> 00:19:54,400
Mis-matched redirects are the most common setup error I see

508
00:19:54,400 --> 00:19:56,080
where the authentication succeeds,

509
00:19:56,080 --> 00:19:58,880
but EntraID tries to send the callback to a URI

510
00:19:58,880 --> 00:20:00,880
that doesn't match what you registered.

511
00:20:00,880 --> 00:20:02,320
The request gets rejected,

512
00:20:02,320 --> 00:20:05,360
and the user sees an error instead of being authenticated.

513
00:20:05,360 --> 00:20:08,160
Register the URIs correctly, and the flow is seamless.

514
00:20:08,160 --> 00:20:10,080
Register them wrong and nothing works.

515
00:20:10,080 --> 00:20:12,240
Claude Desktop 0 friction setup.

516
00:20:12,240 --> 00:20:14,160
Connecting Claude Desktop is almost trivial

517
00:20:14,160 --> 00:20:15,920
once your EntraID app is registered,

518
00:20:15,920 --> 00:20:17,520
and your redirect URIs are set,

519
00:20:17,520 --> 00:20:19,920
open Claude Desktop, and head into the settings.

520
00:20:19,920 --> 00:20:23,280
Look for custom connectors or MCP servers and add a new one.

521
00:20:23,280 --> 00:20:25,440
You will see fields for a name and a URIL.

522
00:20:25,440 --> 00:20:26,560
The name is just a label,

523
00:20:26,560 --> 00:20:28,400
call it "Dataverse" or "business data".

524
00:20:28,400 --> 00:20:29,840
Whatever makes sense for you.

525
00:20:29,840 --> 00:20:32,080
The URIL is your production endpoint.

526
00:20:32,080 --> 00:20:34,080
HTPS are org ID.

527
00:20:34,080 --> 00:20:37,280
CRMDynamics.com API-MCP.

528
00:20:37,280 --> 00:20:38,880
Just make sure to swap that placeholder

529
00:20:38,880 --> 00:20:40,320
with your actual organization ID.

530
00:20:40,320 --> 00:20:42,480
But here's the problem with the old proxy approach.

531
00:20:42,480 --> 00:20:44,400
You used to have to manage connection details,

532
00:20:44,400 --> 00:20:46,640
credentials, and environment variables

533
00:20:46,640 --> 00:20:47,680
just to get things running.

534
00:20:47,680 --> 00:20:49,280
Now, all of that disappears.

535
00:20:49,280 --> 00:20:51,600
You only need two things, the name and the URIL.

536
00:20:51,600 --> 00:20:54,000
The application ID goes right into the client ID field.

537
00:20:54,000 --> 00:20:55,200
You don't need a secret.

538
00:20:55,200 --> 00:20:57,200
The client ID itself is public information

539
00:20:57,200 --> 00:20:59,040
that you already registered in Enter ID.

540
00:20:59,040 --> 00:21:01,680
Putting it in your configuration doesn't expose anything.

541
00:21:01,680 --> 00:21:04,320
Because a secret that was never generated can't be leaked.

542
00:21:04,320 --> 00:21:06,080
Save the configuration and Claude Desktop

543
00:21:06,080 --> 00:21:07,600
will recognize the new connector.

544
00:21:07,600 --> 00:21:10,240
The moment you ask a question that needs dataverse access,

545
00:21:10,240 --> 00:21:12,480
the authentication flow starts automatically.

546
00:21:12,480 --> 00:21:13,680
Claude launches your browser

547
00:21:13,680 --> 00:21:15,760
and shows you the Enter ID sign-in screen.

548
00:21:15,760 --> 00:21:17,760
You enter your credentials and hit consent.

549
00:21:17,760 --> 00:21:19,120
The browser sends you back.

550
00:21:19,120 --> 00:21:21,520
Claude catches the callback at your configured URIL.

551
00:21:21,520 --> 00:21:23,680
And the token arrives, authentication is finished.

552
00:21:23,680 --> 00:21:25,760
This only happens once.

553
00:21:25,760 --> 00:21:27,760
The token stays in a local cache on your machine

554
00:21:27,760 --> 00:21:30,080
so your next query doesn't trigger another sign-in.

555
00:21:30,080 --> 00:21:33,360
Claude uses that cache token to make requests work instantly.

556
00:21:33,360 --> 00:21:35,440
When the token expires after an hour or so,

557
00:21:35,440 --> 00:21:37,040
Claude refreshes it automatically

558
00:21:37,040 --> 00:21:38,640
without asking you for anything.

559
00:21:38,640 --> 00:21:40,560
You never have to see the machinery.

560
00:21:40,560 --> 00:21:42,880
From your perspective, Claude has access to dataverse.

561
00:21:42,880 --> 00:21:43,680
And it just works.

562
00:21:43,680 --> 00:21:45,200
The simplicity here is the point.

563
00:21:45,200 --> 00:21:46,880
There is no proxy to install.

564
00:21:46,880 --> 00:21:48,320
No processes to manage,

565
00:21:48,320 --> 00:21:49,840
and no terminal commands to run.

566
00:21:49,840 --> 00:21:51,600
You open an app, add a connector,

567
00:21:51,600 --> 00:21:52,880
and type in a URIL.

568
00:21:52,880 --> 00:21:54,560
You authenticate once and you're done.

569
00:21:54,560 --> 00:21:56,160
This is what zero-fixion looks like.

570
00:21:56,160 --> 00:21:58,560
It's the perfect model for power users and architects

571
00:21:58,560 --> 00:21:59,760
who need to explore data.

572
00:21:59,760 --> 00:22:01,760
You can ask Claude questions about your environment

573
00:22:01,760 --> 00:22:02,960
using natural language.

574
00:22:02,960 --> 00:22:05,760
Claude uses the described table tool to learn the schema.

575
00:22:05,760 --> 00:22:08,160
Then it queries records and gives you insights.

576
00:22:08,160 --> 00:22:10,480
It all happens through one HTTP endpoint,

577
00:22:10,480 --> 00:22:12,320
secured by PKCE,

578
00:22:12,320 --> 00:22:14,560
and tracked in the dataverse logs.

579
00:22:14,560 --> 00:22:16,720
Claude code, the developers' path.

580
00:22:16,720 --> 00:22:17,840
Claude code works differently

581
00:22:17,840 --> 00:22:19,680
because it's a terminal-based environment

582
00:22:19,680 --> 00:22:20,560
rather than a GUI.

583
00:22:20,560 --> 00:22:21,760
The setup reflects that.

584
00:22:21,760 --> 00:22:23,440
Open your terminal and run the command

585
00:22:23,440 --> 00:22:24,800
to add a new MCP server.

586
00:22:24,800 --> 00:22:28,640
Claude MCP add, transport HTTP,

587
00:22:28,640 --> 00:22:33,440
client ID, plush AP, ID, DVMCP server, MCP URL.

588
00:22:33,440 --> 00:22:34,800
Put in your application ID

589
00:22:34,800 --> 00:22:37,200
and your dataverse endpoint URL and hit enter.

590
00:22:37,200 --> 00:22:39,600
Claude code registers the server immediately.

591
00:22:39,600 --> 00:22:41,920
Claude Desktop uses a settings file.

592
00:22:41,920 --> 00:22:43,600
But Claude code integrates servers

593
00:22:43,600 --> 00:22:45,840
directly into the runtime through the command line.

594
00:22:45,840 --> 00:22:47,280
This is how developers actually work.

595
00:22:47,280 --> 00:22:49,760
They are comfortable with CLI tools and setup commands.

596
00:22:49,760 --> 00:22:52,240
They would rather run a command than click through menus.

597
00:22:52,240 --> 00:22:54,160
The CLI first approach fits the workflow.

598
00:22:54,160 --> 00:22:55,600
When you launch Claude code,

599
00:22:55,600 --> 00:22:57,840
it already knows about your dataverse server.

600
00:22:57,840 --> 00:23:00,560
Run the "ash MCP" command in the chat interface

601
00:23:00,560 --> 00:23:03,280
to see your registered servers and start the login.

602
00:23:03,280 --> 00:23:04,720
Select the dataverse server

603
00:23:04,720 --> 00:23:07,440
and an authentication URL will appear in the chat.

604
00:23:07,440 --> 00:23:09,600
Copy that link and paste it into your browser,

605
00:23:09,600 --> 00:23:11,920
sign in through EntraID and grant consent.

606
00:23:11,920 --> 00:23:13,760
The browser redirects to HTTP's

607
00:23:13,760 --> 00:23:15,760
farfetched localhost, callback,

608
00:23:15,760 --> 00:23:17,680
where Claude code is already listening.

609
00:23:17,680 --> 00:23:19,680
It catches the response, the token arrives,

610
00:23:19,680 --> 00:23:20,880
and you are authenticated.

611
00:23:20,880 --> 00:23:22,320
The context is what matters here.

612
00:23:22,320 --> 00:23:24,080
Claude Desktop is for quick answers.

613
00:23:24,080 --> 00:23:25,440
But Claude code is an environment

614
00:23:25,440 --> 00:23:27,760
where you spend hours building and automating.

615
00:23:27,760 --> 00:23:29,520
The CLI setup matches that reality.

616
00:23:29,520 --> 00:23:32,240
You sign in once and Claude code keeps the session alive.

617
00:23:32,240 --> 00:23:34,240
You can query dataverse from your editor,

618
00:23:34,240 --> 00:23:35,520
pull in live schema,

619
00:23:35,520 --> 00:23:38,720
and even generate code that calls the API is directly.

620
00:23:38,720 --> 00:23:40,960
This is where the value becomes real for a developer.

621
00:23:40,960 --> 00:23:42,880
You load the tool, authenticate once,

622
00:23:42,880 --> 00:23:45,360
and every task has access to live data.

623
00:23:45,360 --> 00:23:46,560
If you are writing a plugin,

624
00:23:46,560 --> 00:23:48,080
you can query the interface.

625
00:23:48,080 --> 00:23:49,280
If you are building an app,

626
00:23:49,280 --> 00:23:51,040
you can inspect the actual tables.

627
00:23:51,040 --> 00:23:53,280
The experience shifts from guessing how the schema works

628
00:23:53,280 --> 00:23:55,120
to seeing exactly what it looks like.

629
00:23:55,120 --> 00:23:56,560
The setup is still trivial.

630
00:23:56,560 --> 00:23:58,240
You don't have to maintain a proxy

631
00:23:58,240 --> 00:24:00,400
or manage custom credentials in your code,

632
00:24:00,400 --> 00:24:02,000
but the integration is much deeper.

633
00:24:02,000 --> 00:24:03,280
You aren't just asking questions.

634
00:24:03,280 --> 00:24:04,720
You are building inside a system

635
00:24:04,720 --> 00:24:06,560
that has governed access to the data.

636
00:24:06,560 --> 00:24:08,320
Both tools use the same endpoint

637
00:24:08,320 --> 00:24:09,680
and the same audit trail.

638
00:24:09,680 --> 00:24:11,280
The only difference is how you use them.

639
00:24:11,280 --> 00:24:13,040
Desktop is for exploring,

640
00:24:13,040 --> 00:24:14,800
and Claude code is for building.

641
00:24:14,800 --> 00:24:17,840
GitHub Copilot, the Enterprise Integration.

642
00:24:17,840 --> 00:24:20,560
Copilot sits in a different place in your infrastructure than Claude.

643
00:24:20,560 --> 00:24:21,680
Claude runs on your machine.

644
00:24:21,680 --> 00:24:23,360
It's a personal tool for personal use.

645
00:24:23,360 --> 00:24:26,000
One person, one install, one conversation at a time.

646
00:24:26,000 --> 00:24:26,960
Copilot is different.

647
00:24:26,960 --> 00:24:28,880
It lives inside your development environment

648
00:24:28,880 --> 00:24:32,160
and it scales across your entire engineering organization by default.

649
00:24:32,160 --> 00:24:34,640
When you setup Copilot to use Dataverse MCP,

650
00:24:34,640 --> 00:24:36,160
you aren't just enabling one person.

651
00:24:36,160 --> 00:24:37,440
You're opening Dataverse Access

652
00:24:37,440 --> 00:24:38,960
to every developer in your company

653
00:24:38,960 --> 00:24:41,120
who touches VS Code or the command line.

654
00:24:41,120 --> 00:24:42,880
The setup itself is almost nothing.

655
00:24:42,880 --> 00:24:44,000
Open VS Code.

656
00:24:44,000 --> 00:24:45,040
Go to Settings.

657
00:24:45,040 --> 00:24:46,320
Find MCP servers.

658
00:24:46,320 --> 00:24:47,840
Select Add Custom Server.

659
00:24:47,840 --> 00:24:49,680
Choose HTTP as the transport.

660
00:24:49,680 --> 00:24:51,840
Not STDIO, not some other protocol.

661
00:24:51,840 --> 00:24:55,120
Just HTTP paste in your Dataverse MCP endpoint URL

662
00:24:55,120 --> 00:24:56,320
and your application ID.

663
00:24:56,320 --> 00:24:56,800
And that's it.

664
00:24:56,800 --> 00:24:57,680
Two fields.

665
00:24:57,680 --> 00:24:59,200
No environment variables to wire up.

666
00:24:59,200 --> 00:25:01,360
No extra config files to hunt down.

667
00:25:01,360 --> 00:25:02,800
Click Sign In.

668
00:25:02,800 --> 00:25:04,960
That click kicks off the PKCE flow

669
00:25:04,960 --> 00:25:06,880
and your browser opens automatically.

670
00:25:06,880 --> 00:25:08,480
You land on the Entra ID screen

671
00:25:08,480 --> 00:25:10,560
and sign in with your normal work credentials.

672
00:25:10,560 --> 00:25:11,920
You might see a consent dialog

673
00:25:11,920 --> 00:25:13,680
asking you to approve Copilot's Access

674
00:25:13,680 --> 00:25:15,520
to the Dataverse MCP server.

675
00:25:15,520 --> 00:25:16,560
You approve it once.

676
00:25:16,560 --> 00:25:18,960
The browser redirects back to your local endpoint,

677
00:25:18,960 --> 00:25:20,000
the token arrives,

678
00:25:20,000 --> 00:25:22,240
and authentication finishes right there.

679
00:25:22,240 --> 00:25:24,720
Copilot now has access to your Dataverse environment

680
00:25:24,720 --> 00:25:26,400
and it didn't take more than a minute.

681
00:25:26,400 --> 00:25:28,800
So what actually makes this the enterprise integration

682
00:25:28,800 --> 00:25:30,400
and not just another client?

683
00:25:30,400 --> 00:25:31,200
Scope.

684
00:25:31,200 --> 00:25:32,560
When you set this up in VS Code,

685
00:25:32,560 --> 00:25:34,080
you're doing it for yourself, sure.

686
00:25:34,080 --> 00:25:36,400
But the same configuration doesn't have to stay yours.

687
00:25:36,400 --> 00:25:37,760
Your enterprise can push this out

688
00:25:37,760 --> 00:25:39,680
to every developer machine through policy,

689
00:25:39,680 --> 00:25:40,720
through team templates,

690
00:25:40,720 --> 00:25:42,000
through whatever deployment tooling

691
00:25:42,000 --> 00:25:44,480
you already used to manage dev environments.

692
00:25:44,480 --> 00:25:46,640
One configuration, deployed once,

693
00:25:46,640 --> 00:25:48,240
available everywhere instantly.

694
00:25:48,240 --> 00:25:49,680
Every developer in your organization

695
00:25:49,680 --> 00:25:51,680
gets Dataverse access through Copilot,

696
00:25:51,680 --> 00:25:53,440
authenticated with their own credentials

697
00:25:53,440 --> 00:25:56,080
and governed by the same Dataverse roles they already have.

698
00:25:56,080 --> 00:25:58,160
Nobody gets more access than their role allows

699
00:25:58,160 --> 00:26:00,000
and nobody needs a separate setup process.

700
00:26:00,000 --> 00:26:00,800
It's the same endpoint,

701
00:26:00,800 --> 00:26:04,080
the same PKCE flow just pointed at 100 machines instead of one.

702
00:26:04,080 --> 00:26:06,480
The Copilot CLI stretches this even further.

703
00:26:06,480 --> 00:26:07,920
Developers who live in terminals,

704
00:26:07,920 --> 00:26:09,520
platform engineers, DevOps teams,

705
00:26:09,520 --> 00:26:10,560
running deployment scripts,

706
00:26:10,560 --> 00:26:12,800
none of them need a GUI to get this working.

707
00:26:12,800 --> 00:26:14,800
They authenticate to Dataverse MCP

708
00:26:14,800 --> 00:26:15,840
straight from the command line

709
00:26:15,840 --> 00:26:18,080
and start pulling schema, querying records,

710
00:26:18,080 --> 00:26:19,600
or debugging infrastructure issues

711
00:26:19,600 --> 00:26:21,280
without ever opening an editor.

712
00:26:21,280 --> 00:26:23,440
Same authentication, same authorization,

713
00:26:23,440 --> 00:26:25,600
same endpoint, just a different door into it.

714
00:26:25,600 --> 00:26:26,640
But here's the capability

715
00:26:26,640 --> 00:26:28,160
that actually separates Copilot

716
00:26:28,160 --> 00:26:29,760
from everything else we've covered.

717
00:26:29,760 --> 00:26:30,800
Agent mode.

718
00:26:30,800 --> 00:26:32,560
Copilot doesn't just answer questions

719
00:26:32,560 --> 00:26:34,000
when you ask it something.

720
00:26:34,000 --> 00:26:35,760
It can run as an autonomous agent,

721
00:26:35,760 --> 00:26:37,280
reasoning through your code base

722
00:26:37,280 --> 00:26:38,560
and taking action on its own

723
00:26:38,560 --> 00:26:40,080
within the boundaries you've set.

724
00:26:40,080 --> 00:26:41,680
When Copilot runs in Agent mode

725
00:26:41,680 --> 00:26:43,520
with Dataverse MCP attached,

726
00:26:43,520 --> 00:26:44,800
it stops being a chat window

727
00:26:44,800 --> 00:26:47,520
and starts being infrastructure your teams build on top of.

728
00:26:47,520 --> 00:26:49,120
A platform team can stand up in agent

729
00:26:49,120 --> 00:26:50,640
that understands your entire data model.

730
00:26:50,640 --> 00:26:52,560
So other teams building integrations

731
00:26:52,560 --> 00:26:55,040
don't have to relearn your schema every time.

732
00:26:55,040 --> 00:26:56,640
A DevOps team can run an agent

733
00:26:56,640 --> 00:26:58,240
that queries Dataverse directly

734
00:26:58,240 --> 00:27:00,000
to inform deployment decisions,

735
00:27:00,000 --> 00:27:01,520
checking configuration records

736
00:27:01,520 --> 00:27:02,480
or environment settings

737
00:27:02,480 --> 00:27:04,160
before a rollout goes out.

738
00:27:04,160 --> 00:27:06,640
This is exactly where Copilot splits from Claude.

739
00:27:06,640 --> 00:27:07,920
Claude is individual oriented,

740
00:27:07,920 --> 00:27:09,920
one person, one question, one answer.

741
00:27:09,920 --> 00:27:11,920
Copilot is organization oriented,

742
00:27:11,920 --> 00:27:14,240
one config deployed across every developer

743
00:27:14,240 --> 00:27:15,760
running autonomously in the background

744
00:27:15,760 --> 00:27:17,280
of your engineering process.

745
00:27:17,280 --> 00:27:19,760
The same Dataverse MCP endpoint serves both of them,

746
00:27:19,760 --> 00:27:21,600
same PKCE flow, same governance,

747
00:27:21,600 --> 00:27:22,800
same audit trail underneath,

748
00:27:22,800 --> 00:27:24,000
what changes its scale.

749
00:27:24,000 --> 00:27:26,320
When one developer uses Claude to ask a question,

750
00:27:26,320 --> 00:27:27,280
that's useful.

751
00:27:27,280 --> 00:27:29,200
When your entire engineering organization

752
00:27:29,200 --> 00:27:32,080
has Copilot agents querying Dataverse autonomously

753
00:27:32,080 --> 00:27:33,760
day and night across every team,

754
00:27:33,760 --> 00:27:34,800
that's not a tool anymore,

755
00:27:34,800 --> 00:27:35,920
that's infrastructure.

756
00:27:35,920 --> 00:27:37,280
The setup took you five minutes,

757
00:27:37,280 --> 00:27:39,040
the implications don't stop.

758
00:27:39,040 --> 00:27:42,240
The 15 tool contract, what Dataverse exposes.

759
00:27:42,240 --> 00:27:43,760
Now that you have authentication working,

760
00:27:43,760 --> 00:27:46,080
you need to understand what you have actually unlocked.

761
00:27:46,080 --> 00:27:47,440
Claude does not get a raw,

762
00:27:47,440 --> 00:27:49,360
rest API to Dataverse.

763
00:27:49,360 --> 00:27:51,760
It does not get a database driver or in SQL shell.

764
00:27:51,760 --> 00:27:54,000
It gets a carefully bounded set of tools.

765
00:27:54,000 --> 00:27:56,800
In June of 2026, Microsoft formalized this tool shape.

766
00:27:56,800 --> 00:27:58,480
It isn't a vague promise of access.

767
00:27:58,480 --> 00:28:00,800
It is a concrete contract of 15 named tools.

768
00:28:00,800 --> 00:28:02,160
This precision is important.

769
00:28:02,160 --> 00:28:03,200
It isn't a limitation.

770
00:28:03,200 --> 00:28:04,320
It's a security boundary.

771
00:28:04,320 --> 00:28:05,920
The tools break down into families.

772
00:28:05,920 --> 00:28:08,720
Discovery tools let agents explore the structure.

773
00:28:08,720 --> 00:28:11,920
The list tables tool returns every table in an environment,

774
00:28:11,920 --> 00:28:14,080
while described table returns the schema,

775
00:28:14,080 --> 00:28:15,920
including column names and relationships.

776
00:28:15,920 --> 00:28:17,280
There is also a search tool.

777
00:28:17,280 --> 00:28:19,200
It lets agents find tables by keyword.

778
00:28:19,200 --> 00:28:21,120
And agent asking Claude about your data model

779
00:28:21,120 --> 00:28:23,040
doesn't need to know the schema in advance.

780
00:28:23,040 --> 00:28:25,520
It queries these tools to learn what tables exist

781
00:28:25,520 --> 00:28:27,280
and how they relate to each other.

782
00:28:27,280 --> 00:28:29,200
Retrieval tools let agents fetch data,

783
00:28:29,200 --> 00:28:31,520
the search data tool queries records with filters.

784
00:28:31,520 --> 00:28:34,160
An agent can search for all accounts in a specific region

785
00:28:34,160 --> 00:28:36,160
or opportunities above a certain threshold.

786
00:28:36,160 --> 00:28:37,680
The query happens server side.

787
00:28:37,680 --> 00:28:40,560
Dataverse applies security, row level security,

788
00:28:40,560 --> 00:28:44,000
field level security, and any restrictions on the user identity.

789
00:28:44,000 --> 00:28:46,800
The agent only receives data the user is authorized to see.

790
00:28:46,800 --> 00:28:49,680
The tool also searches across unstructured data

791
00:28:49,680 --> 00:28:51,040
like notes and files.

792
00:28:51,040 --> 00:28:53,360
The new agentic search index makes this fast

793
00:28:53,360 --> 00:28:55,600
and that six times improvement in performance

794
00:28:55,600 --> 00:28:57,520
is something agents can use directly.

795
00:28:57,520 --> 00:28:59,600
Mutation tools let agents take action.

796
00:28:59,600 --> 00:29:01,280
Create record inserts a new row.

797
00:29:01,280 --> 00:29:03,600
Update record modifies an existing one.

798
00:29:03,600 --> 00:29:05,680
Delete record removes a record entirely.

799
00:29:05,680 --> 00:29:08,800
But deletion carries a flag, requires confirmation.

800
00:29:08,800 --> 00:29:10,560
The client, Claude or Copilot

801
00:29:10,560 --> 00:29:12,480
must show the user a confirmation dialogue

802
00:29:12,480 --> 00:29:14,000
before the deletion executes.

803
00:29:14,000 --> 00:29:15,600
There is no silent data loss.

804
00:29:15,600 --> 00:29:18,000
No agent decides on its own to destroy records

805
00:29:18,000 --> 00:29:20,560
without a human in the loop approving the action first.

806
00:29:20,560 --> 00:29:23,040
Schema tools let agents understand relationships.

807
00:29:23,040 --> 00:29:26,400
A dataverse table might have lookup fields pointing to other tables.

808
00:29:26,400 --> 00:29:28,400
A contact might have a lookup to an account.

809
00:29:28,400 --> 00:29:30,160
An agent needs to understand this graph

810
00:29:30,160 --> 00:29:33,040
to reason correctly about which queries to run.

811
00:29:33,040 --> 00:29:35,200
Schema tools expose these relationships.

812
00:29:35,200 --> 00:29:36,880
They show which fields are read only

813
00:29:36,880 --> 00:29:38,880
and which ones have validation rules.

814
00:29:38,880 --> 00:29:40,880
File tools let agents work with documents.

815
00:29:40,880 --> 00:29:42,640
Dataverse can store files

816
00:29:42,640 --> 00:29:44,880
and an agent might need to upload or retrieve one.

817
00:29:44,880 --> 00:29:48,240
The initialize upload tool creates a storage location

818
00:29:48,240 --> 00:29:50,480
while upload chunk sends the actual data.

819
00:29:50,480 --> 00:29:53,120
These tools integrate with dataverse security.

820
00:29:53,120 --> 00:29:56,240
Files inherit the security of the record they are attached to.

821
00:29:56,240 --> 00:30:00,080
Business skills tools let agents call reusable process instructions.

822
00:30:00,080 --> 00:30:02,960
A business skill is a natural language description of a process

823
00:30:02,960 --> 00:30:04,160
stored in dataverse.

824
00:30:04,160 --> 00:30:07,440
An agent can query available skills and execute them.

825
00:30:07,440 --> 00:30:09,680
This is where governance and business logic converge.

826
00:30:09,680 --> 00:30:11,680
Instead of an agent improvising its response,

827
00:30:11,680 --> 00:30:12,560
it follows a skill.

828
00:30:12,560 --> 00:30:14,160
A documented and approved procedure

829
00:30:14,160 --> 00:30:15,840
that your organization has formalized.

830
00:30:15,840 --> 00:30:17,200
Different agents.

831
00:30:17,200 --> 00:30:18,560
Same skills.

832
00:30:18,560 --> 00:30:19,920
Consistency emerges.

833
00:30:19,920 --> 00:30:23,360
Why this boundary matters is straightforward.

834
00:30:23,360 --> 00:30:26,800
You aren't giving Claude or co-pilot unrestricted access to dataverse.

835
00:30:26,800 --> 00:30:29,120
You are constraining what they can do to operations.

836
00:30:29,120 --> 00:30:30,720
You have explicitly allowed.

837
00:30:30,720 --> 00:30:32,240
An agent cannot drop tables.

838
00:30:32,240 --> 00:30:33,840
It cannot change security roles.

839
00:30:33,840 --> 00:30:35,440
It cannot execute arbitrary SQL.

840
00:30:35,440 --> 00:30:36,720
It can discover tables.

841
00:30:36,720 --> 00:30:39,440
Query records and execute pre-approved skills.

842
00:30:39,440 --> 00:30:41,200
Those constraints exist for a reason.

843
00:30:41,200 --> 00:30:42,560
Agents hallucinate.

844
00:30:42,560 --> 00:30:44,000
They misunderstand context.

845
00:30:44,000 --> 00:30:46,720
They can cause damage through confusion rather than malice.

846
00:30:46,720 --> 00:30:48,560
The 15 tool contract prevents that.

847
00:30:48,560 --> 00:30:50,720
The boundary is also about governance clarity.

848
00:30:50,720 --> 00:30:52,480
When you audit what an agent did,

849
00:30:52,480 --> 00:30:54,160
you are auditing tool calls.

850
00:30:54,160 --> 00:30:56,080
Which of the 15 tools did it invoke?

851
00:30:56,080 --> 00:30:57,520
But what parameters did it use?

852
00:30:57,520 --> 00:31:01,040
The audit trail is easy to read because the surface area is small and intentional.

853
00:31:02,000 --> 00:31:02,960
Safe mutation.

854
00:31:02,960 --> 00:31:05,040
How destructive operations get gated?

855
00:31:05,040 --> 00:31:07,600
The 15 tool contract includes something subtle.

856
00:31:07,600 --> 00:31:10,960
It's a flag on specific tools that reads requires confirmation.

857
00:31:10,960 --> 00:31:12,880
You won't see this flag on read operations.

858
00:31:12,880 --> 00:31:14,000
You can search records.

859
00:31:14,000 --> 00:31:14,960
You can list tables.

860
00:31:14,960 --> 00:31:16,960
You can pull data all day without any friction.

861
00:31:16,960 --> 00:31:18,480
But on destructive operations,

862
00:31:18,480 --> 00:31:20,000
specifically delete record.

863
00:31:20,000 --> 00:31:22,160
That flag changes the entire flow.

864
00:31:22,160 --> 00:31:24,960
When an agent tries to call delete record, it doesn't just happen.

865
00:31:24,960 --> 00:31:28,560
The MCP protocol has built in support for this exact requirement.

866
00:31:28,560 --> 00:31:30,080
The client receives a response saying

867
00:31:30,080 --> 00:31:32,960
this operation needs a human to sign off before it can proceed.

868
00:31:32,960 --> 00:31:35,120
Claude sees the flag, GitHub co-pilot sees it.

869
00:31:35,120 --> 00:31:37,200
They don't just pass the request through to dataverse.

870
00:31:37,200 --> 00:31:38,320
Instead, they stop.

871
00:31:38,320 --> 00:31:40,400
They show you a confirmation dialogue.

872
00:31:40,400 --> 00:31:42,160
This agent wants to delete a record.

873
00:31:42,160 --> 00:31:43,600
Record details.

874
00:31:43,600 --> 00:31:44,960
User.

875
00:31:44,960 --> 00:31:45,920
Who authorize this?

876
00:31:45,920 --> 00:31:46,560
Confirm?

877
00:31:46,560 --> 00:31:47,600
You see the context.

878
00:31:47,600 --> 00:31:48,880
You make the final call.

879
00:31:48,880 --> 00:31:51,360
Only if you click yes, does the actual deletion happen.

880
00:31:51,360 --> 00:31:54,560
This isn't a workaround or a hack we bolted onto the protocol later.

881
00:31:54,560 --> 00:31:57,200
It's a core feature of how MCP handles governance.

882
00:31:57,200 --> 00:31:59,200
The requires confirmation flag tells the client

883
00:31:59,200 --> 00:32:02,160
that this is a decision point where a human must step in.

884
00:32:02,160 --> 00:32:04,400
The client respects that because the major vendors,

885
00:32:04,400 --> 00:32:05,920
anthropic GitHub and others,

886
00:32:05,920 --> 00:32:08,480
know that autonomous systems touching business data

887
00:32:08,480 --> 00:32:09,680
need these checkpoints.

888
00:32:09,680 --> 00:32:10,800
Why is this non-negotiable?

889
00:32:10,800 --> 00:32:12,800
Because agents will delete records.

890
00:32:12,800 --> 00:32:14,000
Not because they're malicious,

891
00:32:14,000 --> 00:32:16,240
but because they misunderstand the prompt.

892
00:32:16,240 --> 00:32:17,840
You might say remove in active accounts,

893
00:32:17,840 --> 00:32:20,160
meaning anyone who hasn't bought anything in a year,

894
00:32:20,160 --> 00:32:21,840
the agent might interpret that as any account

895
00:32:21,840 --> 00:32:23,520
that hasn't been touched today.

896
00:32:23,520 --> 00:32:24,720
Before you realize what's happening

897
00:32:24,720 --> 00:32:26,560
an entire year of data is gone.

898
00:32:26,560 --> 00:32:27,600
With the confirmation flag,

899
00:32:27,600 --> 00:32:29,360
you get a dialog box that shows you the scope.

900
00:32:29,360 --> 00:32:31,440
You see the mistake before it becomes permanent.

901
00:32:31,440 --> 00:32:33,280
This also solves the regulatory problem.

902
00:32:33,280 --> 00:32:35,040
In healthcare, HIPAA requires you to prove

903
00:32:35,040 --> 00:32:37,440
who authorized the deletion of sensitive data.

904
00:32:37,440 --> 00:32:41,040
In finance, SOIX demands an approval chain for every modification.

905
00:32:41,040 --> 00:32:44,400
A confirmation dialog in co-pilot or Claude

906
00:32:44,400 --> 00:32:46,320
paired with the audit trail gives you that evidence.

907
00:32:46,320 --> 00:32:48,080
A regulator can look at the logs

908
00:32:48,080 --> 00:32:50,240
and see the agent requested the delete.

909
00:32:50,240 --> 00:32:51,600
The user saw the prompt

910
00:32:51,600 --> 00:32:53,440
and the user clicked approve.

911
00:32:53,440 --> 00:32:56,320
The chain is unbroken and the authorization is fully documented.

912
00:32:56,320 --> 00:32:59,040
The audit trail is the second half of the safety net.

913
00:32:59,040 --> 00:33:01,680
Every single tool call, whether you confirm it or not,

914
00:33:01,680 --> 00:33:03,920
gets logged in the dataverse audit system.

915
00:33:03,920 --> 00:33:06,320
It tracks who called it, which agent was used,

916
00:33:06,320 --> 00:33:08,720
what the parameters were, and exactly when it happened.

917
00:33:08,720 --> 00:33:11,520
The confirmation dialog adds another layer to that log.

918
00:33:11,520 --> 00:33:13,360
It records that a confirmation was requested

919
00:33:13,360 --> 00:33:15,440
and shows whether the user said yes or no.

920
00:33:15,440 --> 00:33:16,880
If the deletion went through,

921
00:33:16,880 --> 00:33:18,640
the audit trail shows your approval,

922
00:33:18,640 --> 00:33:19,920
but if you clicked no,

923
00:33:19,920 --> 00:33:21,840
it shows the agent's request was denied.

924
00:33:21,840 --> 00:33:24,800
This trail is your forensic evidence for when things go wrong.

925
00:33:24,800 --> 00:33:27,120
If a record vanishes and nobody knows why,

926
00:33:27,120 --> 00:33:28,720
you just pull the audit log.

927
00:33:28,720 --> 00:33:30,320
You can see which agent tried to kill it,

928
00:33:30,320 --> 00:33:32,320
who approved it, and exactly what was lost.

929
00:33:32,320 --> 00:33:33,760
The entire history is right there,

930
00:33:33,760 --> 00:33:35,440
tamper evident and immutable.

931
00:33:35,440 --> 00:33:36,960
The difference between a powerful system

932
00:33:36,960 --> 00:33:39,200
and a reckless one is this checkpoint.

933
00:33:39,200 --> 00:33:41,520
A powerful system lets agents take action,

934
00:33:41,520 --> 00:33:43,360
but a reckless one gives them that power

935
00:33:43,360 --> 00:33:44,640
without any oversight.

936
00:33:44,640 --> 00:33:46,560
Dataverse MCP with the confirmation flag

937
00:33:46,560 --> 00:33:48,560
gives you the power with a built-in circuit breaker.

938
00:33:48,560 --> 00:33:50,720
The agent can do real work like creating records

939
00:33:50,720 --> 00:33:51,840
or modifying data,

940
00:33:51,840 --> 00:33:53,840
but on the operations that can't be undone,

941
00:33:53,840 --> 00:33:57,120
you get one last chance to catch a disaster before it happens.

942
00:33:57,120 --> 00:33:58,240
The governance layer,

943
00:33:58,240 --> 00:34:00,000
controlling who accesses what?

944
00:34:00,000 --> 00:34:02,240
You've authenticated Claude to Dataverse.

945
00:34:02,240 --> 00:34:04,560
You've made sure mutations require approval.

946
00:34:04,560 --> 00:34:05,840
Now we have to answer the question

947
00:34:05,840 --> 00:34:08,080
that keeps security teams awake at night.

948
00:34:08,080 --> 00:34:10,000
How do you control which Claude instances

949
00:34:10,000 --> 00:34:11,440
can talk to which environments?

950
00:34:11,440 --> 00:34:13,280
And how do you stop an authenticated agent

951
00:34:13,280 --> 00:34:14,800
from seeing data it shouldn't?

952
00:34:14,800 --> 00:34:16,080
The answer lives in layers.

953
00:34:16,080 --> 00:34:17,920
The first layer is the environment allow list

954
00:34:17,920 --> 00:34:19,600
in the Power Platform Admin Center.

955
00:34:19,600 --> 00:34:21,440
When you registered your EntraID app,

956
00:34:21,440 --> 00:34:24,640
you had to add it to a list for a specific Dataverse environment.

957
00:34:24,640 --> 00:34:27,440
This isn't an optional setting, it's a hard gate.

958
00:34:27,440 --> 00:34:30,400
If an app isn't on that list, it cannot connect, period.

959
00:34:30,400 --> 00:34:32,800
If you have dev, staging, and production environments,

960
00:34:32,800 --> 00:34:34,960
you can add your app to dev and staging,

961
00:34:34,960 --> 00:34:36,400
but leave production locked.

962
00:34:36,400 --> 00:34:38,080
Claude talking to your test data is fine,

963
00:34:38,080 --> 00:34:40,720
but Claude talking to your live customer data is forbidden.

964
00:34:40,720 --> 00:34:43,280
The allow list makes that a technical impossibility

965
00:34:43,280 --> 00:34:44,960
rather than just a policy hope.

966
00:34:44,960 --> 00:34:47,760
This matters because it prevents accidental scope creep.

967
00:34:47,760 --> 00:34:50,880
Maybe you set up Dataverse MCP for a small internal test,

968
00:34:50,880 --> 00:34:52,960
but six months later, a deployment script

969
00:34:52,960 --> 00:34:53,920
runs in the wrong place.

970
00:34:53,920 --> 00:34:55,760
Without the allow list, that mistake could expose

971
00:34:55,760 --> 00:34:57,680
your production data, but with the list,

972
00:34:57,680 --> 00:34:59,680
the connection just fails at the protocol level,

973
00:34:59,680 --> 00:35:01,520
no access, no risk, no incident.

974
00:35:01,520 --> 00:35:03,440
The second layer is Dataverse roles.

975
00:35:03,440 --> 00:35:05,600
You've authenticated as a specific user,

976
00:35:05,600 --> 00:35:08,000
and that user has roles like System Administrator

977
00:35:08,000 --> 00:35:08,880
or Sales Manager.

978
00:35:08,880 --> 00:35:10,640
Those roles have specific permissions.

979
00:35:10,640 --> 00:35:13,200
This account can create records but not delete them.

980
00:35:13,200 --> 00:35:15,600
That account can read opportunities but not close them.

981
00:35:15,600 --> 00:35:18,400
These permissions aren't new to MCP,

982
00:35:18,400 --> 00:35:22,000
they're the same ones, power apps and Dynamics 365 use every day.

983
00:35:22,000 --> 00:35:23,120
Here's the critical insight.

984
00:35:23,120 --> 00:35:25,280
The MCP server is just a thin layer.

985
00:35:25,280 --> 00:35:26,720
It isn't a new security boundary

986
00:35:26,720 --> 00:35:28,720
that tries to reinvent access control.

987
00:35:28,720 --> 00:35:30,320
It's just a protocol translator.

988
00:35:30,320 --> 00:35:32,560
When an agent calls the CreateRecord tool,

989
00:35:32,560 --> 00:35:35,280
Dataverse doesn't care that the request came through MCP.

990
00:35:35,280 --> 00:35:37,440
It applies the same role checks it always does.

991
00:35:37,440 --> 00:35:38,880
It asks if this user has permission

992
00:35:38,880 --> 00:35:40,480
to create records in this table,

993
00:35:40,480 --> 00:35:42,560
and if they don't, the tool call fails.

994
00:35:42,560 --> 00:35:44,480
The agent gets an error and the human sees

995
00:35:44,480 --> 00:35:45,920
that the action wasn't allowed.

996
00:35:45,920 --> 00:35:48,560
The third layer is Row Level and Field Level Security.

997
00:35:48,560 --> 00:35:49,680
These are the granular features

998
00:35:49,680 --> 00:35:52,320
that let you restrict access down to the specific cell.

999
00:35:52,320 --> 00:35:54,480
Maybe your sales team can see all accounts,

1000
00:35:54,480 --> 00:35:57,040
but only the opportunities they actually own.

1001
00:35:57,040 --> 00:35:59,120
Maybe Finance can see the transaction amounts,

1002
00:35:59,120 --> 00:36:01,360
but they can't see the customer's payment method.

1003
00:36:01,360 --> 00:36:03,360
These rules are defined inside Dataverse

1004
00:36:03,360 --> 00:36:04,880
and they apply to everyone,

1005
00:36:04,880 --> 00:36:07,440
whether they're using a REST API or MCP.

1006
00:36:07,440 --> 00:36:09,920
If an agent queries data the user isn't allowed to see,

1007
00:36:09,920 --> 00:36:11,840
those roles simply won't appear in the results.

1008
00:36:11,840 --> 00:36:14,640
To the agent, it just looks like those records don't exist.

1009
00:36:14,640 --> 00:36:16,240
The fourth layer is Business Rules.

1010
00:36:16,240 --> 00:36:17,760
Dataverse lets you define logic

1011
00:36:17,760 --> 00:36:20,160
where changing one field triggers another action.

1012
00:36:20,160 --> 00:36:22,560
Maybe when an opportunity is marked as one,

1013
00:36:22,560 --> 00:36:25,040
the system automatically creates an invoice.

1014
00:36:25,040 --> 00:36:27,280
When an agent updates a status through MCP,

1015
00:36:27,280 --> 00:36:28,880
that business rule still fires.

1016
00:36:28,880 --> 00:36:30,720
The same automation that runs for a human

1017
00:36:30,720 --> 00:36:33,200
in a PowerApp runs for the agent in MCP.

1018
00:36:33,200 --> 00:36:35,440
The agent doesn't even need to know the rules exist

1019
00:36:35,440 --> 00:36:37,440
because they are part of the system's DNA.

1020
00:36:37,440 --> 00:36:38,560
This is fundamentally different

1021
00:36:38,560 --> 00:36:40,800
from just giving an LLM access to a database.

1022
00:36:40,800 --> 00:36:43,040
A raw database connection gives you a SQL,

1023
00:36:43,040 --> 00:36:44,800
which lets you query or modify anything

1024
00:36:44,800 --> 00:36:46,160
while bypassing constraints.

1025
00:36:46,160 --> 00:36:47,920
In that world, you have to trust the person

1026
00:36:47,920 --> 00:36:49,280
you're giving access to.

1027
00:36:49,280 --> 00:36:51,680
Dataverse MCP gives you a governed interface instead.

1028
00:36:51,680 --> 00:36:53,520
The allowless controls the environment,

1029
00:36:53,520 --> 00:36:55,200
the roles control the records,

1030
00:36:55,200 --> 00:36:57,680
and the field security controls the granularity.

1031
00:36:57,680 --> 00:36:59,040
An agent can do real work,

1032
00:36:59,040 --> 00:37:01,680
but it stays inside the boundaries you've already built.

1033
00:37:01,680 --> 00:37:03,840
The system enforces those limits automatically.

1034
00:37:03,840 --> 00:37:05,680
You don't have to audit every single move

1035
00:37:05,680 --> 00:37:07,520
to make sure the agent's stayed in bounds.

1036
00:37:07,520 --> 00:37:09,520
The bounds are built into the platform itself.

1037
00:37:09,520 --> 00:37:12,480
Observability, seeing what agents do.

1038
00:37:12,480 --> 00:37:14,400
We've spent a lot of time talking about what Claude

1039
00:37:14,400 --> 00:37:16,160
or GitHub co-pilot can actually do.

1040
00:37:16,160 --> 00:37:18,320
We've looked at the constraints and the permissions,

1041
00:37:18,320 --> 00:37:19,760
but there's another side to governance

1042
00:37:19,760 --> 00:37:21,040
that matters just as much.

1043
00:37:21,040 --> 00:37:23,600
What can you actually see after the agent takes an action?

1044
00:37:23,600 --> 00:37:26,080
The moment an agent calls a tool, that action is recorded.

1045
00:37:26,080 --> 00:37:28,000
It doesn't matter if it's just looking up a record

1046
00:37:28,000 --> 00:37:29,440
or creating a brand new one.

1047
00:37:29,440 --> 00:37:30,960
That call gets logged immediately.

1048
00:37:30,960 --> 00:37:32,800
This isn't happening in some separate audit system

1049
00:37:32,800 --> 00:37:34,240
that you have to bolt on later.

1050
00:37:34,240 --> 00:37:36,320
It's logged directly into the Dataverse audit trail.

1051
00:37:36,320 --> 00:37:37,600
This is the same permanent record

1052
00:37:37,600 --> 00:37:39,840
that tracks when a human changes a field in PowerApps

1053
00:37:39,840 --> 00:37:41,280
or when a flow updates a row.

1054
00:37:41,280 --> 00:37:43,600
From the perspective of Dataverse and agents' actions

1055
00:37:43,600 --> 00:37:45,200
look exactly like human actions.

1056
00:37:45,200 --> 00:37:47,760
They are both just modifications to the system of record.

1057
00:37:47,760 --> 00:37:50,080
The log captures every specific detail you need.

1058
00:37:50,080 --> 00:37:51,840
It tracks which agent made the request.

1059
00:37:51,840 --> 00:37:55,040
This is vital because you might have several Claude instances running at once.

1060
00:37:55,040 --> 00:37:57,040
You might have different versions of GitHub co-pilot

1061
00:37:57,040 --> 00:38:00,160
across different teams or custom orchestrators for specific jobs.

1062
00:38:00,160 --> 00:38:02,720
When something breaks, you have to know which specific agent did it.

1063
00:38:02,720 --> 00:38:04,480
The audit trail gives you that answer.

1064
00:38:04,480 --> 00:38:07,040
It also records which user was authenticated at the time.

1065
00:38:07,040 --> 00:38:08,640
An agent never acts alone.

1066
00:38:08,640 --> 00:38:10,160
It acts on behalf of a person.

1067
00:38:10,160 --> 00:38:12,400
That person's identity is baked into the record.

1068
00:38:12,400 --> 00:38:13,520
Then you have the tool itself.

1069
00:38:13,520 --> 00:38:17,360
The log shows if it used search data, create record or update record.

1070
00:38:17,360 --> 00:38:20,160
It captures the parameters like which table was queried

1071
00:38:20,160 --> 00:38:21,520
and which fields were changed.

1072
00:38:21,520 --> 00:38:23,840
It marks the exact time down to the millisecond.

1073
00:38:23,840 --> 00:38:25,600
Finally, it shows if the action worked.

1074
00:38:25,600 --> 00:38:27,200
If an agent tried to create a record

1075
00:38:27,200 --> 00:38:28,400
but hit a validation rule,

1076
00:38:28,400 --> 00:38:30,240
the audit log catches that failure.

1077
00:38:30,240 --> 00:38:32,320
The fact that these logs are tamper evident

1078
00:38:32,320 --> 00:38:33,920
is the most important part.

1079
00:38:33,920 --> 00:38:35,600
These records are append-only.

1080
00:38:35,600 --> 00:38:37,360
You can read them and you can query them,

1081
00:38:37,360 --> 00:38:38,560
but you cannot change them.

1082
00:38:38,560 --> 00:38:42,080
You can't delete a single entry just because you want to hide a mistake.

1083
00:38:42,080 --> 00:38:43,680
The logs use cryptographic chaining

1084
00:38:43,680 --> 00:38:45,840
where every entry points to the one before it.

1085
00:38:45,840 --> 00:38:47,440
If an attacker gets into the storage

1086
00:38:47,440 --> 00:38:50,480
and tries to forge or delete a line, the chain breaks.

1087
00:38:50,480 --> 00:38:52,880
Any standard audit review will see that break

1088
00:38:52,880 --> 00:38:54,560
and know something was erased.

1089
00:38:54,560 --> 00:38:56,880
This isn't just theoretical security theatre.

1090
00:38:56,880 --> 00:38:59,520
It's a technical wall that keeps the audit trail honest.

1091
00:38:59,520 --> 00:39:02,320
That trail then feeds into your main compliance setup.

1092
00:39:02,320 --> 00:39:04,560
If you use a CM for security monitoring,

1093
00:39:04,560 --> 00:39:07,040
you can pull these data verse logs right into it.

1094
00:39:07,040 --> 00:39:11,200
Your security team can see agent activity sitting right next to everything else in the company.

1095
00:39:11,200 --> 00:39:13,120
You can even set up automated alerts.

1096
00:39:13,120 --> 00:39:15,920
If an agent tries to delete more than three records in an hour,

1097
00:39:15,920 --> 00:39:17,280
you get a notification.

1098
00:39:17,280 --> 00:39:19,840
If it starts querying sensitive tables in the middle of the night,

1099
00:39:19,840 --> 00:39:21,040
it gets flagged.

1100
00:39:21,040 --> 00:39:23,280
The audit trail stops being a dusty history book

1101
00:39:23,280 --> 00:39:25,120
and starts being a live security tool.

1102
00:39:25,120 --> 00:39:27,440
We can go even deeper with open telemetry support.

1103
00:39:27,440 --> 00:39:29,040
This is a standard for distributed tracing

1104
00:39:29,040 --> 00:39:32,160
that lets you follow one request through every system it touches.

1105
00:39:32,160 --> 00:39:34,480
An agent query might hit data verse,

1106
00:39:34,480 --> 00:39:36,000
which triggers a business rule

1107
00:39:36,000 --> 00:39:39,760
which then calls a power automate flow that talks to an external API.

1108
00:39:39,760 --> 00:39:41,280
All of that shows up as one single trace.

1109
00:39:41,280 --> 00:39:44,240
You can see the whole flow and find exactly where the bottlenecks are.

1110
00:39:44,240 --> 00:39:47,200
For compliance, it means you can trace a data change from start to finish.

1111
00:39:47,200 --> 00:39:49,120
You don't just see that an agent made a change.

1112
00:39:49,120 --> 00:39:50,720
You see everything that happened because of it.

1113
00:39:50,720 --> 00:39:52,480
This changes your relationship with AI

1114
00:39:52,480 --> 00:39:54,560
from a black box to total transparency.

1115
00:39:54,560 --> 00:39:56,560
You aren't just hoping the agent behaves well.

1116
00:39:56,560 --> 00:39:58,080
You are watching it behave in real time.

1117
00:39:58,080 --> 00:40:01,760
You are capturing every move and plugging it into your existing security world.

1118
00:40:01,760 --> 00:40:02,880
If something goes wrong,

1119
00:40:02,880 --> 00:40:06,080
the audit trail tells you what happened when it happened and who was involved.

1120
00:40:06,080 --> 00:40:07,200
That isn't blind trust.

1121
00:40:07,200 --> 00:40:08,400
That's governed autonomy.

1122
00:40:08,400 --> 00:40:10,960
The fabric model from point integration to platform.

1123
00:40:10,960 --> 00:40:13,280
Everything we've talked about, the logins, the governance,

1124
00:40:13,280 --> 00:40:16,480
the audit trails only really make sense when you look at the big picture.

1125
00:40:16,480 --> 00:40:18,960
We are seeing a massive shift in how systems are built.

1126
00:40:18,960 --> 00:40:20,480
We think about how we used to do this.

1127
00:40:20,480 --> 00:40:23,280
Claude needed to talk to data verse, so you built a proxy,

1128
00:40:23,280 --> 00:40:24,720
GitHub co-pilot needed access,

1129
00:40:24,720 --> 00:40:26,320
so you built another integration.

1130
00:40:26,320 --> 00:40:27,920
Then a custom orchestrator came along

1131
00:40:27,920 --> 00:40:29,440
and you built a third one.

1132
00:40:29,440 --> 00:40:33,040
Even Dynamics 365 co-pilot needed its own separate configuration.

1133
00:40:33,040 --> 00:40:36,960
Every single connection had its own login flow and its own security model.

1134
00:40:36,960 --> 00:40:39,920
Each one had its own set of rules and its own maintenance list.

1135
00:40:39,920 --> 00:40:41,600
You weren't running a single system.

1136
00:40:41,600 --> 00:40:44,400
You were managing a messy pile of one-to-one connections.

1137
00:40:44,400 --> 00:40:45,920
Every piece was a new burden.

1138
00:40:45,920 --> 00:40:48,640
This way of building is tempting because it works at first.

1139
00:40:48,640 --> 00:40:51,120
You can tweak each connection for one specific tool,

1140
00:40:51,120 --> 00:40:54,240
but it creates a mountain of technical debt that just keeps growing.

1141
00:40:54,240 --> 00:40:57,280
If you have 10 integrations, you need 10 sets of documents.

1142
00:40:57,280 --> 00:41:00,800
You have 10 different ways to manage secrets and 10 different ways to monitor them.

1143
00:41:00,800 --> 00:41:03,280
If a security hole pops up in how you handle credentials,

1144
00:41:03,280 --> 00:41:05,200
you have to fix it in 10 different places.

1145
00:41:05,200 --> 00:41:06,880
When a new tool comes out that you want to try,

1146
00:41:06,880 --> 00:41:08,160
you have to start from scratch.

1147
00:41:08,160 --> 00:41:11,200
That means weeks or months of work just to get connected.

1148
00:41:11,200 --> 00:41:13,120
Then you have to maintain that code forever.

1149
00:41:13,120 --> 00:41:15,120
The fabric model flips this completely.

1150
00:41:15,120 --> 00:41:18,640
Data verse provides one single endpoint that endpoint uses one way to login,

1151
00:41:18,640 --> 00:41:20,240
PKCE with EntraID.

1152
00:41:20,240 --> 00:41:21,840
It offers one standard set of tools.

1153
00:41:21,840 --> 00:41:26,160
Any client that understands the MCP protocol and PKCE can connect to it.

1154
00:41:26,160 --> 00:41:28,560
Any of them, it's not just Claude and Copilot.

1155
00:41:28,560 --> 00:41:32,240
It's literally anything, Claude, custom agents, or even tools from other vendors.

1156
00:41:32,240 --> 00:41:34,080
They all see the exact same data verse.

1157
00:41:34,080 --> 00:41:36,720
They all log in the same way and follow the same rules.

1158
00:41:36,720 --> 00:41:38,480
They all write to the same audit trail.

1159
00:41:38,480 --> 00:41:40,400
The fabric isn't a bunch of loose strings.

1160
00:41:40,400 --> 00:41:41,600
It's a solid weave.

1161
00:41:41,600 --> 00:41:44,800
This standardization isn't about forcing everyone to be identical.

1162
00:41:44,800 --> 00:41:46,960
It's about creating a contract that is so clear

1163
00:41:46,960 --> 00:41:48,720
that different tools can work together

1164
00:41:48,720 --> 00:41:50,640
without even knowing the others exist.

1165
00:41:50,640 --> 00:41:53,360
Claude doesn't need to care how GitHub Copilot logs in.

1166
00:41:53,360 --> 00:41:56,480
Copilot doesn't need to know anything about Claude's internal setup.

1167
00:41:56,480 --> 00:41:59,840
They don't have to talk to each other because they both know how to speak MCP.

1168
00:41:59,840 --> 00:42:02,320
Data verse just speaks that one language back to everyone.

1169
00:42:02,320 --> 00:42:04,080
This changes everything for your operations.

1170
00:42:04,080 --> 00:42:06,800
Today, adding a new tool takes weeks of engineering.

1171
00:42:06,800 --> 00:42:08,960
Under the fabric model, it takes minutes.

1172
00:42:08,960 --> 00:42:11,120
If a vendor drops a new AI tool tomorrow,

1173
00:42:11,120 --> 00:42:12,000
you just plug it in.

1174
00:42:12,000 --> 00:42:15,280
You give it the URL, the ID, and the redirect info.

1175
00:42:15,280 --> 00:42:16,000
That's it.

1176
00:42:16,000 --> 00:42:19,200
It immediately gets the same data and the same tools as everything else.

1177
00:42:19,200 --> 00:42:21,920
It follows the same governance and writes to the same logs.

1178
00:42:21,920 --> 00:42:23,680
There is no custom integration work

1179
00:42:23,680 --> 00:42:25,440
because the contract is already there.

1180
00:42:25,440 --> 00:42:27,200
The cost of governance basically disappears.

1181
00:42:27,200 --> 00:42:29,600
You aren't managing 10 different access policies anymore.

1182
00:42:29,600 --> 00:42:30,560
You are managing one.

1183
00:42:30,560 --> 00:42:32,800
You have one set of roles and one set of security rules.

1184
00:42:32,800 --> 00:42:35,920
You have one business rule engine and one audit system.

1185
00:42:35,920 --> 00:42:38,240
If you need to change who can see certain data,

1186
00:42:38,240 --> 00:42:40,240
you change it once and it works everywhere.

1187
00:42:40,240 --> 00:42:42,000
If you want to give your agents a new skill,

1188
00:42:42,000 --> 00:42:44,960
you define that tool once and every agent can use it instantly.

1189
00:42:44,960 --> 00:42:46,560
Compliance gets much simpler too.

1190
00:42:46,560 --> 00:42:48,560
When an auditor asks who accessed your data,

1191
00:42:48,560 --> 00:42:50,640
you don't have to hunt through 10 different logs.

1192
00:42:50,640 --> 00:42:52,400
You have one single source of truth.

1193
00:42:52,400 --> 00:42:54,640
Every action from every tool shows up in that same

1194
00:42:54,640 --> 00:42:56,000
tamper evident trail.

1195
00:42:56,000 --> 00:42:57,200
The story is consistent.

1196
00:42:57,200 --> 00:42:58,240
This is how you scale.

1197
00:42:58,240 --> 00:42:59,920
You might start with Claude and co-pilot,

1198
00:42:59,920 --> 00:43:01,760
then add a custom orchestrator later.

1199
00:43:01,760 --> 00:43:04,080
Maybe you add a third party platform after that.

1200
00:43:04,080 --> 00:43:06,080
By the time you get to your 10th tool,

1201
00:43:06,080 --> 00:43:07,840
your costs haven't actually gone up.

1202
00:43:07,840 --> 00:43:09,840
But it's still just an endpoint and a login.

1203
00:43:09,840 --> 00:43:12,080
The fabric doesn't break down as you add more pieces

1204
00:43:12,080 --> 00:43:14,240
because you aren't adding more complexity.

1205
00:43:14,240 --> 00:43:15,920
You are just plugging into the same surface.

1206
00:43:15,920 --> 00:43:18,080
This architecture is built to last for years

1207
00:43:18,080 --> 00:43:19,600
because it's based on a standard.

1208
00:43:19,600 --> 00:43:22,480
It doesn't rely on what one specific vendor wants to do today.

1209
00:43:22,480 --> 00:43:25,360
If Microsoft updates dataverse, the contract stays the same.

1210
00:43:25,360 --> 00:43:28,000
If anthropic updates Claude, the contract stays the same.

1211
00:43:28,000 --> 00:43:30,720
The fabric lasts because it's built on a shared language,

1212
00:43:30,720 --> 00:43:31,760
not a one-off hack.

1213
00:43:31,760 --> 00:43:35,200
Token efficiency, the hidden ROI.

1214
00:43:35,200 --> 00:43:38,720
Most teams don't talk about the actual cost of building AI integrations,

1215
00:43:38,720 --> 00:43:40,080
but here's the problem.

1216
00:43:40,080 --> 00:43:43,200
You want Claude to answer a question about your dataverse records.

1217
00:43:43,200 --> 00:43:46,160
The naive approach is to stuff the entire schema into the prompt.

1218
00:43:46,160 --> 00:43:47,120
You list every table.

1219
00:43:47,120 --> 00:43:48,160
You describe every column.

1220
00:43:48,160 --> 00:43:51,120
You include sample data so Claude understands what lives where.

1221
00:43:51,120 --> 00:43:52,720
You might even throw in business context,

1222
00:43:52,720 --> 00:43:54,960
like what the tables mean or how they relate.

1223
00:43:54,960 --> 00:43:57,440
All of that goes into the system prompt or the user's query.

1224
00:43:57,440 --> 00:43:59,200
Now run that query and count the tokens.

1225
00:43:59,200 --> 00:44:02,000
The schema alone runs 5,000 to 10,000 tokens.

1226
00:44:02,000 --> 00:44:04,960
Sample data adds another 3,000 to 5,000.

1227
00:44:04,960 --> 00:44:06,560
Business context adds even more.

1228
00:44:06,560 --> 00:44:08,960
By the time Claude even understands your environment,

1229
00:44:08,960 --> 00:44:11,920
you're at 10,000 to 50,000 tokens just for the setup.

1230
00:44:11,920 --> 00:44:13,840
That's before Claude even answers the actual question.

1231
00:44:13,840 --> 00:44:16,720
At current pricing, you're paying 15 cents

1232
00:44:16,720 --> 00:44:19,120
to a $1.50 per query just in overhead.

1233
00:44:19,120 --> 00:44:21,120
If you run 100 queries a day,

1234
00:44:21,120 --> 00:44:23,680
you're burning hundreds of dollars on redundant context.

1235
00:44:23,680 --> 00:44:26,240
If you have a support team running 1,000 queries,

1236
00:44:26,240 --> 00:44:28,480
you're losing thousands of dollars every single day.

1237
00:44:28,480 --> 00:44:29,200
The math breaks.

1238
00:44:29,200 --> 00:44:31,920
Now contrast that with the MCP approach.

1239
00:44:31,920 --> 00:44:33,920
Claude doesn't load the schema into memory upfront.

1240
00:44:33,920 --> 00:44:36,960
Instead, when it needs to understand your dataverse,

1241
00:44:36,960 --> 00:44:37,840
it uses a tool.

1242
00:44:37,840 --> 00:44:41,440
Claude asks, what does the account table look like?

1243
00:44:41,440 --> 00:44:44,480
The tool returns only the schema for that specific table.

1244
00:44:44,480 --> 00:44:45,840
200 tokens, that's it.

1245
00:44:45,840 --> 00:44:48,000
Claude doesn't get a dump of every table you own.

1246
00:44:48,000 --> 00:44:49,200
It gets exactly what it asked for.

1247
00:44:49,200 --> 00:44:51,280
When it needs sample data, it calls the search tool

1248
00:44:51,280 --> 00:44:52,800
and retrieves three examples.

1249
00:44:52,800 --> 00:44:55,040
Not the entire table, just a few hundred tokens.

1250
00:44:55,040 --> 00:44:56,880
The result is a massive shift in efficiency.

1251
00:44:56,880 --> 00:44:58,880
Instead of 50,000 tokens of context,

1252
00:44:58,880 --> 00:44:59,840
you're at 500.

1253
00:44:59,840 --> 00:45:01,680
That's an 80% reduction in overhead.

1254
00:45:01,680 --> 00:45:04,720
The impact compounds across every single query you run.

1255
00:45:04,720 --> 00:45:08,160
In the old model, you have to include every schema upfront just in case.

1256
00:45:08,160 --> 00:45:11,440
With MCP, Claude asks for what it needs as it needs it.

1257
00:45:11,440 --> 00:45:13,440
If a query only requires the account schema,

1258
00:45:13,440 --> 00:45:14,640
you only pay for that.

1259
00:45:14,640 --> 00:45:16,800
The cost reflects the actual complexity,

1260
00:45:16,800 --> 00:45:19,040
not a static overhead that waste your budget.

1261
00:45:19,040 --> 00:45:20,800
Here's where this becomes a financial reality.

1262
00:45:20,800 --> 00:45:24,240
A support agent that costs $2 per interaction under the old model

1263
00:45:24,240 --> 00:45:26,640
costs 40 cents under the MCP approach.

1264
00:45:26,640 --> 00:45:29,600
Same agent, same results, one waste's money on duplication

1265
00:45:29,600 --> 00:45:30,560
and the other doesn't.

1266
00:45:30,560 --> 00:45:32,080
Scale that across your organization.

1267
00:45:32,080 --> 00:45:33,680
If you run 50 agents,

1268
00:45:33,680 --> 00:45:35,520
you aren't looking at a small difference.

1269
00:45:35,520 --> 00:45:37,760
You're looking at an 80-dollar daily saving.

1270
00:45:37,760 --> 00:45:39,600
That's $24,000 a year,

1271
00:45:39,600 --> 00:45:41,920
or because of a single architectural choice.

1272
00:45:41,920 --> 00:45:43,760
But the benefit isn't just about the money.

1273
00:45:43,760 --> 00:45:46,000
Fewer tokens mean faster responses.

1274
00:45:46,000 --> 00:45:49,280
Claude processes smaller context windows much more quickly.

1275
00:45:49,280 --> 00:45:51,680
It focuses its reasoning on what actually matters.

1276
00:45:51,680 --> 00:45:53,040
The data and the question.

1277
00:45:53,040 --> 00:45:57,360
The quality of the answer improves because Claude isn't distracted by a relevant noise.

1278
00:45:57,360 --> 00:46:00,000
The user gets a faster, more accurate experience.

1279
00:46:00,000 --> 00:46:01,760
This is why the business case for MCP

1280
00:46:01,760 --> 00:46:03,360
isn't just about better technology.

1281
00:46:03,360 --> 00:46:06,160
It's about a system that pays for itself while performing better.

1282
00:46:06,160 --> 00:46:09,120
From semantic kernel to agent framework,

1283
00:46:09,120 --> 00:46:10,640
the platform succession.

1284
00:46:10,640 --> 00:46:12,960
A decade ago, if you wanted to orchestrate an LLM,

1285
00:46:12,960 --> 00:46:14,640
you used semantic kernel.

1286
00:46:14,640 --> 00:46:17,840
Microsoft released it as a general SDK for building intelligent apps.

1287
00:46:17,840 --> 00:46:19,120
The mental model was simple.

1288
00:46:19,120 --> 00:46:21,280
You had a kernel, you loaded plugins,

1289
00:46:21,280 --> 00:46:24,000
you executed planners to decide which plugins to call.

1290
00:46:24,000 --> 00:46:26,560
It worked and teams built real systems on it.

1291
00:46:26,560 --> 00:46:28,800
Some of those integrations are still running today.

1292
00:46:28,800 --> 00:46:30,880
But semantic kernel was born in a different era.

1293
00:46:30,880 --> 00:46:33,920
The assumption back then was that your application would be a single unit.

1294
00:46:33,920 --> 00:46:37,280
One app, one kernel, one orchestration engine.

1295
00:46:37,280 --> 00:46:40,320
The framework assumed you owned both the AI and the application.

1296
00:46:40,320 --> 00:46:42,880
You were weaving them together inside your own codebase.

1297
00:46:42,880 --> 00:46:44,080
It was SDK-centric.

1298
00:46:44,080 --> 00:46:45,920
You wrote code, you imported a library,

1299
00:46:45,920 --> 00:46:48,000
and you extended it, everything lived in the code.

1300
00:46:48,000 --> 00:46:49,200
That assumption has inverted.

1301
00:46:49,200 --> 00:46:53,600
Today, you aren't building one LLM inside one app.

1302
00:46:53,600 --> 00:46:56,240
You're building multiple agents that live in different places.

1303
00:46:56,240 --> 00:46:59,360
Co-pilot studio, GitHub Co-pilot, custom orchestrators.

1304
00:46:59,360 --> 00:47:01,600
They all need to talk to the same business data.

1305
00:47:01,600 --> 00:47:03,840
The agent is no longer bundled with your application.

1306
00:47:03,840 --> 00:47:07,440
The agent is a separate runtime that calls your data through a protocol.

1307
00:47:07,440 --> 00:47:09,840
The framework can't be SDK-centric anymore.

1308
00:47:09,840 --> 00:47:11,360
It has to be server-centric.

1309
00:47:11,360 --> 00:47:14,880
It has to assume the agent might not even be written in the same language as your data.

1310
00:47:14,880 --> 00:47:16,720
It has to think in terms of contracts.

1311
00:47:16,720 --> 00:47:18,080
Not imports and function calls.

1312
00:47:18,080 --> 00:47:21,840
This is why Microsoft released the agent framework in April of 2026.

1313
00:47:21,840 --> 00:47:24,320
It is the official successor to semantic kernel.

1314
00:47:24,320 --> 00:47:26,880
Agent framework is designed for this new reality.

1315
00:47:26,880 --> 00:47:29,840
Instead of loading plugins into a kernel, the model is simple.

1316
00:47:29,840 --> 00:47:31,040
Agents call tools.

1317
00:47:31,040 --> 00:47:32,080
Tools come from anywhere.

1318
00:47:32,080 --> 00:47:34,720
APIs, MCP servers, cloud services.

1319
00:47:34,720 --> 00:47:36,160
The agent doesn't care about the source.

1320
00:47:36,160 --> 00:47:38,080
It just knows its tool set and its goal.

1321
00:47:38,080 --> 00:47:40,160
The engine is agnostic about where those tools live.

1322
00:47:40,160 --> 00:47:41,280
It's not about the SDK.

1323
00:47:41,280 --> 00:47:42,160
It's about the tool.

1324
00:47:42,160 --> 00:47:44,560
And critically, agent framework is MCP native.

1325
00:47:44,560 --> 00:47:46,320
MCP isn't an afterthought here.

1326
00:47:46,320 --> 00:47:47,840
It's a first-class concern.

1327
00:47:47,840 --> 00:47:50,880
When you define an agent, you define it in terms of tools.

1328
00:47:50,880 --> 00:47:53,200
Those tools are naturally expressed as MCP servers.

1329
00:47:53,200 --> 00:47:54,480
Dataverse is an MCP server.

1330
00:47:54,480 --> 00:47:56,240
Your automation layer is an MCP server.

1331
00:47:56,240 --> 00:47:58,640
Your external APIs are wired through MCP.

1332
00:47:58,640 --> 00:48:03,040
The same agent definition works whether it runs in co-pilot studio or GitHub.

1333
00:48:03,040 --> 00:48:05,040
Because the contract is the same across all of them.

1334
00:48:05,040 --> 00:48:06,960
Semantic kernel still works.

1335
00:48:06,960 --> 00:48:08,800
And Microsoft is still maintaining it.

1336
00:48:08,800 --> 00:48:10,880
They aren't abandoning the people who use it.

1337
00:48:10,880 --> 00:48:13,680
But the guidance from the platform team is very clear.

1338
00:48:13,680 --> 00:48:15,920
Do not start anything new on semantic kernel.

1339
00:48:15,920 --> 00:48:18,800
If you're building a new agent system in 2027,

1340
00:48:18,800 --> 00:48:20,400
you start with agent framework.

1341
00:48:20,400 --> 00:48:23,280
If you have existing code, there are migration parts available.

1342
00:48:23,280 --> 00:48:25,600
They aren't always easy, but they are documented.

1343
00:48:25,600 --> 00:48:27,040
Your investment isn't wasted.

1344
00:48:27,040 --> 00:48:28,480
The codebase just evolves.

1345
00:48:28,480 --> 00:48:30,000
Why does this matter for your roadmap?

1346
00:48:30,000 --> 00:48:31,520
Because your framework choice determines

1347
00:48:31,520 --> 00:48:33,440
how your agents connect to your data.

1348
00:48:33,440 --> 00:48:36,240
Semantic kernel ties you to a specific way of working.

1349
00:48:36,240 --> 00:48:39,360
Agent framework aligns you with where the entire industry is moving.

1350
00:48:39,360 --> 00:48:42,000
The fabric we've been describing relies on one idea.

1351
00:48:42,000 --> 00:48:44,480
Any client should be able to connect through one endpoint.

1352
00:48:44,480 --> 00:48:47,360
That only works if you think in terms of tools and protocols.

1353
00:48:47,360 --> 00:48:49,120
Agent framework encodes that assumption.

1354
00:48:49,120 --> 00:48:50,240
Semantic kernel doesn't.

1355
00:48:50,240 --> 00:48:54,000
If you're architecting for the future, the choice is obvious.

1356
00:48:54,000 --> 00:48:55,680
The multi-LLM enterprise?

1357
00:48:55,680 --> 00:48:57,280
Why vendor lock in is dead?

1358
00:48:57,280 --> 00:48:59,600
Your enterprise doesn't run on just one LLM.

1359
00:48:59,600 --> 00:49:00,480
You might think it does.

1360
00:49:00,480 --> 00:49:02,800
You might have a policy that says you've standardized on

1361
00:49:02,800 --> 00:49:04,720
OpenAI, Anthropic, or Azure.

1362
00:49:04,720 --> 00:49:07,200
But underneath that policy, reality is more complex.

1363
00:49:07,200 --> 00:49:09,920
The finance team is using GPT 4.5 for complex math

1364
00:49:09,920 --> 00:49:11,760
because it's fast and accurate with numbers.

1365
00:49:11,760 --> 00:49:13,520
Legal prefers Claude for long contracts

1366
00:49:13,520 --> 00:49:15,520
because it doesn't lose focus on page 90.

1367
00:49:15,520 --> 00:49:18,160
Your infrastructure team is running Yammer on premise

1368
00:49:18,160 --> 00:49:20,560
to stay compliant with data residency laws.

1369
00:49:20,560 --> 00:49:23,840
Research is experimenting with Gemini for scientific tasks.

1370
00:49:23,840 --> 00:49:26,320
This isn't a shadow IT problem or a policy violation.

1371
00:49:26,320 --> 00:49:27,680
It's rational optimization.

1372
00:49:27,680 --> 00:49:30,000
Different models have different strengths

1373
00:49:30,000 --> 00:49:32,480
and using the right tool for the job just gets better results.

1374
00:49:32,480 --> 00:49:33,680
But here's the problem.

1375
00:49:33,680 --> 00:49:37,600
About 60% of enterprises are running multiple LLMs at the same time

1376
00:49:37,600 --> 00:49:40,000
and under the old model, that's an integration nightmare.

1377
00:49:40,000 --> 00:49:41,440
Every vendor has a different API.

1378
00:49:41,440 --> 00:49:43,840
OpenAI works one way and topic works another.

1379
00:49:43,840 --> 00:49:45,200
Yammer is different again.

1380
00:49:45,200 --> 00:49:47,840
When every model needs its own connection to dataverse,

1381
00:49:47,840 --> 00:49:50,400
you end up building a separate integration for every single one.

1382
00:49:50,400 --> 00:49:52,080
You build a connector for OpenAI,

1383
00:49:52,080 --> 00:49:54,480
then a separate one for Claude, then another for Yammer.

1384
00:49:54,480 --> 00:49:57,600
Each one has its own login flow, its own errors, and its own setup.

1385
00:49:57,600 --> 00:49:58,800
That isn't integration.

1386
00:49:58,800 --> 00:50:02,640
It's integration dead that gets heavier every time a new model hits the market.

1387
00:50:02,640 --> 00:50:03,920
And one level deeper.

1388
00:50:03,920 --> 00:50:05,040
You're locked in.

1389
00:50:05,040 --> 00:50:08,800
If you've built your entire business process around one specific API,

1390
00:50:08,800 --> 00:50:10,160
your team is trained on it,

1391
00:50:10,160 --> 00:50:12,400
and your infrastructure is optimized for it.

1392
00:50:12,400 --> 00:50:14,880
Then a competitor releases a better model at half the price.

1393
00:50:14,880 --> 00:50:16,640
You want to switch, but you can't.

1394
00:50:16,640 --> 00:50:19,360
Switching means rebuilding everything from scratch

1395
00:50:19,360 --> 00:50:21,120
and retraining your entire team.

1396
00:50:21,120 --> 00:50:23,600
The cost is so high that you stay stuck with a worse option.

1397
00:50:23,600 --> 00:50:24,400
The vendor owns you.

1398
00:50:24,400 --> 00:50:27,360
This is why MCP fundamentally changes the equation.

1399
00:50:27,360 --> 00:50:29,760
Instead of building 10 integrations, you build one.

1400
00:50:29,760 --> 00:50:31,280
Dataverse speaks MCP.

1401
00:50:31,280 --> 00:50:32,880
The LLMs speak MCP.

1402
00:50:32,880 --> 00:50:35,040
The same dataverse endpoint works for all of them.

1403
00:50:35,040 --> 00:50:38,160
When a new model comes out, your connector doesn't change.

1404
00:50:38,160 --> 00:50:40,720
The new model just connects to the existing endpoint

1405
00:50:40,720 --> 00:50:44,000
and instantly has access to your tools, your data, and your security.

1406
00:50:44,000 --> 00:50:45,760
No extra work, no rebuilding.

1407
00:50:45,760 --> 00:50:47,760
Think of it like USB-C for AI.

1408
00:50:47,760 --> 00:50:50,880
Before USB-C, every phone and laptop had a different plug,

1409
00:50:50,880 --> 00:50:53,440
which created nothing but waste and frustration.

1410
00:50:53,440 --> 00:50:56,240
Now one cable works with everything MCP is that connector.

1411
00:50:56,240 --> 00:50:57,680
Dataverse is the platform.

1412
00:50:57,680 --> 00:50:59,840
The LLM is just the device you're plugging in,

1413
00:50:59,840 --> 00:51:01,440
because the protocol is a standard,

1414
00:51:01,440 --> 00:51:04,320
you aren't locked into anyone, switching costs, nothing.

1415
00:51:04,320 --> 00:51:06,800
The business case is simple.

1416
00:51:06,800 --> 00:51:09,920
In the old model, adding a new vendor takes weeks of coding

1417
00:51:09,920 --> 00:51:11,280
and a lifetime of maintenance.

1418
00:51:11,280 --> 00:51:13,680
With MCP, it's just a configuration change.

1419
00:51:13,680 --> 00:51:16,080
You add the endpoint, set up the login, and you're done.

1420
00:51:16,080 --> 00:51:18,640
That is the difference between being flexible and being trapped.

1421
00:51:18,640 --> 00:51:22,720
For most enterprises, avoiding lock-in is a requirement.

1422
00:51:22,720 --> 00:51:25,040
You need to keep your options open so you can switch models

1423
00:51:25,040 --> 00:51:28,320
based on cost or new regulations without tearing your house down.

1424
00:51:28,320 --> 00:51:31,040
You can run five models at once without five times the work.

1425
00:51:31,040 --> 00:51:34,400
The complexity stays the same, no matter how many LLMs you add.

1426
00:51:34,400 --> 00:51:36,960
This is non-negotiable for any large organization.

1427
00:51:36,960 --> 00:51:39,520
The moment you depend on one vendor for your core business,

1428
00:51:39,520 --> 00:51:40,880
they control your roadmap.

1429
00:51:40,880 --> 00:51:42,320
MCP takes that control back.

1430
00:51:42,320 --> 00:51:44,720
Dataverse becomes truly multi-LLM,

1431
00:51:44,720 --> 00:51:47,120
and you stay in charge of your own technology.

1432
00:51:47,120 --> 00:51:49,760
Business skills, encoding process and data.

1433
00:51:49,760 --> 00:51:53,200
Agents are powerful, but power without a process is just chaos.

1434
00:51:53,200 --> 00:51:55,120
This is where business skills change the game.

1435
00:51:55,120 --> 00:51:56,480
A business skill is simple.

1436
00:51:56,480 --> 00:51:59,040
It's a description of a process written in plain English

1437
00:51:59,040 --> 00:52:00,720
and stored as a record in Dataverse.

1438
00:52:00,720 --> 00:52:02,720
It isn't code, it isn't a flow chart in a PDF.

1439
00:52:02,720 --> 00:52:04,720
It isn't a wiki page that nobody looks at.

1440
00:52:04,720 --> 00:52:07,520
It is a structured, versioned, and auditable record

1441
00:52:07,520 --> 00:52:09,280
of how your company actually works.

1442
00:52:09,280 --> 00:52:11,840
An agent can find these skills, read them and follow them.

1443
00:52:11,840 --> 00:52:13,280
So why does this matter?

1444
00:52:13,280 --> 00:52:15,360
Imagine your sales qualification process.

1445
00:52:15,360 --> 00:52:18,080
It's probably documented in an email or stuck in someone's head.

1446
00:52:18,080 --> 00:52:21,680
The rule might be if a prospect has five employees in North America,

1447
00:52:21,680 --> 00:52:22,480
they're qualified.

1448
00:52:22,480 --> 00:52:24,960
If they don't have a budget, nurture them for six months.

1449
00:52:24,960 --> 00:52:27,120
It's basic logic that humans get immediately.

1450
00:52:27,120 --> 00:52:28,880
Now, you want an agent to do this.

1451
00:52:28,880 --> 00:52:31,760
The old way was to hard code that logic into the agent.

1452
00:52:31,760 --> 00:52:34,160
You write the if-then statements and deploy the code.

1453
00:52:34,160 --> 00:52:36,400
But three months later, the sales strategy changes.

1454
00:52:36,400 --> 00:52:37,840
The budget rules shift.

1455
00:52:37,840 --> 00:52:40,080
To update the agent, you have to call the developers,

1456
00:52:40,080 --> 00:52:41,920
change the code, test it and redeploy.

1457
00:52:41,920 --> 00:52:44,400
It's slow, it's expensive, and it creates friction.

1458
00:52:44,400 --> 00:52:46,480
The business skill approach inverts this.

1459
00:52:46,480 --> 00:52:48,080
You create a record in Dataverse

1460
00:52:48,080 --> 00:52:50,240
that describes the rules in plain text.

1461
00:52:50,240 --> 00:52:52,640
When the geography or the budget rules change,

1462
00:52:52,640 --> 00:52:54,640
you just update the text in that record.

1463
00:52:55,040 --> 00:52:56,960
The agent queries the business skills tool,

1464
00:52:56,960 --> 00:52:59,920
reads the new instructions, and follows them on the very next lead.

1465
00:52:59,920 --> 00:53:02,400
No developers, no code changes, no waiting.

1466
00:53:02,400 --> 00:53:04,800
The business team owns the process directly.

1467
00:53:04,800 --> 00:53:07,440
That shift is about control and velocity.

1468
00:53:07,440 --> 00:53:10,240
In the old way, business teams are stuck waiting on engineering

1469
00:53:10,240 --> 00:53:11,840
to update a simple rule.

1470
00:53:11,840 --> 00:53:13,360
Engineering has other priorities,

1471
00:53:13,360 --> 00:53:14,480
so the business waits,

1472
00:53:14,480 --> 00:53:16,400
and the process becomes outdated.

1473
00:53:16,400 --> 00:53:18,480
With business skills, the bottleneck is gone.

1474
00:53:18,480 --> 00:53:20,880
If a sales leader needs to change a rule,

1475
00:53:20,880 --> 00:53:22,480
they change the record in Dataverse,

1476
00:53:22,480 --> 00:53:23,760
and it happens instantly.

1477
00:53:23,760 --> 00:53:25,440
The governance side is just as big.

1478
00:53:25,440 --> 00:53:26,640
Business skills are versioned,

1479
00:53:26,640 --> 00:53:29,040
so you can keep the old rules while you test new ones.

1480
00:53:29,040 --> 00:53:31,440
A manager can draft a new version of a skill

1481
00:53:31,440 --> 00:53:32,960
and run it on a few agents

1482
00:53:32,960 --> 00:53:34,880
to see if it actually closes more deals.

1483
00:53:34,880 --> 00:53:37,520
Once it's proven, you promote it to the live version.

1484
00:53:37,520 --> 00:53:39,680
The old version stays in the system for compliance,

1485
00:53:39,680 --> 00:53:41,280
so you always have an audit trail.

1486
00:53:41,280 --> 00:53:43,200
Approval workflows fit right into this.

1487
00:53:43,200 --> 00:53:45,120
You can require that any change to a skill

1488
00:53:45,120 --> 00:53:46,960
has to be signed off by a VP.

1489
00:53:46,960 --> 00:53:49,200
The analyst drafts it, the VP approves it,

1490
00:53:49,200 --> 00:53:51,280
and the whole decision trail is saved.

1491
00:53:51,280 --> 00:53:54,000
When in order to ask why a process changed,

1492
00:53:54,000 --> 00:53:55,120
you have the proof.

1493
00:53:55,120 --> 00:53:58,160
You have the who, the when, and the why, all in one place.

1494
00:53:58,160 --> 00:54:00,320
The system even captures the execution.

1495
00:54:00,320 --> 00:54:02,480
When an agent uses a skill to make a decision,

1496
00:54:02,480 --> 00:54:03,600
it logs everything.

1497
00:54:03,600 --> 00:54:05,040
You see which agent ran it,

1498
00:54:05,040 --> 00:54:06,480
which version of the skill it used,

1499
00:54:06,480 --> 00:54:08,080
and what data it was looking at.

1500
00:54:08,080 --> 00:54:10,240
If an agent makes a mistake, you can trace it back.

1501
00:54:10,240 --> 00:54:12,080
It's not just the AI messed up.

1502
00:54:12,080 --> 00:54:14,160
It's the agent followed version two of the skill

1503
00:54:14,160 --> 00:54:15,920
which had a specific budget requirement

1504
00:54:15,920 --> 00:54:17,360
this prospect didn't meet.

1505
00:54:17,360 --> 00:54:18,800
The whole chain is transparent.

1506
00:54:18,800 --> 00:54:21,840
This is the bridge between AI and real governance.

1507
00:54:21,840 --> 00:54:24,000
Agents get the ability to handle complex logic

1508
00:54:24,000 --> 00:54:25,440
without being hard coded.

1509
00:54:25,440 --> 00:54:28,640
Business teams get to update that logic without calling IT.

1510
00:54:28,640 --> 00:54:30,800
An auditor gets to see exactly how every decision was made.

1511
00:54:30,800 --> 00:54:32,000
It's not agents running wild.

1512
00:54:32,000 --> 00:54:34,080
It's agents following the exact processes

1513
00:54:34,080 --> 00:54:36,400
that your business defined and approved.

1514
00:54:36,400 --> 00:54:39,280
The 2027 trajectory, where this is heading.

1515
00:54:39,280 --> 00:54:42,080
Today, Dataverse MCP is in public preview.

1516
00:54:42,080 --> 00:54:44,320
The tool surface is formalized, but not final.

1517
00:54:44,320 --> 00:54:46,480
The governance patterns are just starting to emerge,

1518
00:54:46,480 --> 00:54:47,680
but by 2027.

1519
00:54:47,680 --> 00:54:49,680
This shifts into a different phase entirely.

1520
00:54:49,680 --> 00:54:51,920
General availability means you can finally plan

1521
00:54:51,920 --> 00:54:54,720
production deployments without the asterisks.

1522
00:54:54,720 --> 00:54:56,320
No more, this might change.

1523
00:54:56,320 --> 00:54:58,560
No more, we're still refining the contract.

1524
00:54:58,560 --> 00:55:01,280
Dataverse MCP becomes a stable supported platform

1525
00:55:01,280 --> 00:55:02,960
with SLA, security patches,

1526
00:55:02,960 --> 00:55:05,040
and a long-term commitment from Microsoft.

1527
00:55:05,040 --> 00:55:06,960
That's not just a versioning number change.

1528
00:55:06,960 --> 00:55:09,360
That is permission to build your most critical systems

1529
00:55:09,360 --> 00:55:10,640
on this foundation.

1530
00:55:10,640 --> 00:55:12,560
Organizations currently running pilots

1531
00:55:12,560 --> 00:55:14,080
will move into full production,

1532
00:55:14,080 --> 00:55:16,080
and new organizations will enter the space

1533
00:55:16,080 --> 00:55:18,640
because the risk profile has fundamentally changed.

1534
00:55:18,640 --> 00:55:20,560
The tool surface is going to expand.

1535
00:55:20,560 --> 00:55:22,400
15 tools today feels like a lot,

1536
00:55:22,400 --> 00:55:25,440
but by 2027 expect that suite to grow significantly.

1537
00:55:25,440 --> 00:55:26,720
This won't happen randomly.

1538
00:55:26,720 --> 00:55:28,240
It will happen deliberately in response

1539
00:55:28,240 --> 00:55:30,240
to what agents actually need to do their jobs.

1540
00:55:30,240 --> 00:55:32,160
You'll see more granular schema operations

1541
00:55:32,160 --> 00:55:33,840
and tools for managing Dataverse plugins

1542
00:55:33,840 --> 00:55:34,800
and workflows directly.

1543
00:55:34,800 --> 00:55:37,040
We'll see domain-specific tools for industry scenarios

1544
00:55:37,040 --> 00:55:38,640
like financial tools for banking

1545
00:55:38,640 --> 00:55:40,080
or clinical tools for healthcare.

1546
00:55:40,080 --> 00:55:41,360
The contract grows,

1547
00:55:41,360 --> 00:55:43,040
but the principle stays the same.

1548
00:55:43,040 --> 00:55:45,120
Tools remain bounded, intentional, and governed.

1549
00:55:45,120 --> 00:55:48,320
The expansion doesn't mean agents gain wild unchecked power.

1550
00:55:48,320 --> 00:55:49,760
It means you get more precision.

1551
00:55:49,760 --> 00:55:52,320
Remote MCP servers will solve a specific pain point

1552
00:55:52,320 --> 00:55:54,160
that is becoming increasingly urgent.

1553
00:55:54,160 --> 00:55:56,160
Today, if you want multiple environments

1554
00:55:56,160 --> 00:55:57,920
like dev, staging, and production,

1555
00:55:57,920 --> 00:55:59,840
you have to configure them all separately.

1556
00:55:59,840 --> 00:56:03,600
By 2027, you'll be able to set up a single remote MCP server

1557
00:56:03,600 --> 00:56:05,600
that roots to multiple Dataverse environments

1558
00:56:05,600 --> 00:56:08,400
while managing credentials and policies centrally.

1559
00:56:08,400 --> 00:56:10,480
One endpoint, different target environments

1560
00:56:10,480 --> 00:56:12,320
based on rules, one deployment,

1561
00:56:12,320 --> 00:56:13,600
multiple control planes.

1562
00:56:14,480 --> 00:56:16,960
The operational burden drops significantly

1563
00:56:16,960 --> 00:56:19,440
because the complexity is handled at the server level.

1564
00:56:19,440 --> 00:56:21,040
Agent framework will become the default

1565
00:56:21,040 --> 00:56:23,120
orchestration model across power platform,

1566
00:56:23,120 --> 00:56:25,680
Microsoft 365, and your custom applications.

1567
00:56:25,680 --> 00:56:27,920
It won't be an alternative to other frameworks.

1568
00:56:27,920 --> 00:56:29,200
It will be the framework.

1569
00:56:29,200 --> 00:56:31,200
Teams building new agents in 2027

1570
00:56:31,200 --> 00:56:32,720
won't even evaluate alternatives

1571
00:56:32,720 --> 00:56:35,600
because this is where all the platform investment is concentrated.

1572
00:56:35,600 --> 00:56:37,280
The documentation will be mature,

1573
00:56:37,280 --> 00:56:38,720
the tooling will be stable,

1574
00:56:38,720 --> 00:56:40,480
and the community will be massive.

1575
00:56:40,480 --> 00:56:42,480
By sheer inertia and capability,

1576
00:56:42,480 --> 00:56:44,080
it becomes the standard.

1577
00:56:44,080 --> 00:56:46,560
Business skills will transition from an interesting experiment

1578
00:56:46,560 --> 00:56:48,240
to the way we actually encode process.

1579
00:56:48,240 --> 00:56:50,880
By 2027, your organization won't maintain

1580
00:56:50,880 --> 00:56:53,760
process documentation in messy wikis and long email chains.

1581
00:56:53,760 --> 00:56:56,720
You will maintain it in Dataverse as skills, sales processes,

1582
00:56:56,720 --> 00:56:58,160
support escalation procedures,

1583
00:56:58,160 --> 00:56:59,920
approval workflows, and compliance checks

1584
00:56:59,920 --> 00:57:01,360
will all exist as queryable,

1585
00:57:01,360 --> 00:57:03,120
versionable, and auditable records.

1586
00:57:03,120 --> 00:57:05,760
Agents execute them, humans update them.

1587
00:57:05,760 --> 00:57:09,120
The distinction between automation and process blurs

1588
00:57:09,120 --> 00:57:10,640
because in this model,

1589
00:57:10,640 --> 00:57:13,040
processes are executable by default.

1590
00:57:13,040 --> 00:57:16,080
Governance and compliance tooling will mature around this architecture.

1591
00:57:16,080 --> 00:57:18,480
Today, you're likely piecing together your own solutions,

1592
00:57:18,480 --> 00:57:19,840
but by 2027,

1593
00:57:19,840 --> 00:57:22,880
you'll have product-grade offerings built directly into power platform.

1594
00:57:22,880 --> 00:57:26,080
You'll have centralized tool policies and role-based tool access.

1595
00:57:26,080 --> 00:57:28,080
Data classification will automatically affect

1596
00:57:28,080 --> 00:57:30,080
which agents can access which tables.

1597
00:57:30,080 --> 00:57:33,520
And workflow approvals will trigger based on specific agent actions.

1598
00:57:33,520 --> 00:57:36,160
The governance layer is no longer something you bolt on at the end,

1599
00:57:36,160 --> 00:57:37,120
it's native.

1600
00:57:37,120 --> 00:57:40,240
The agentic backbone becomes a standard piece of infrastructure.

1601
00:57:40,240 --> 00:57:42,480
Today, agents are exciting because they're new,

1602
00:57:42,480 --> 00:57:44,720
but by 2027, they are expected.

1603
00:57:44,720 --> 00:57:46,720
You won't ask, "Should we use agents?"

1604
00:57:46,720 --> 00:57:50,560
Instead, you'll ask, "Which processes should agents handle next?"

1605
00:57:50,560 --> 00:57:53,120
The infrastructure supporting them, the authentication,

1606
00:57:53,120 --> 00:57:55,760
the tool routing, the governance, and the audit logs

1607
00:57:55,760 --> 00:57:58,160
becomes as foundational as the database itself.

1608
00:57:58,160 --> 00:58:00,480
IT teams build it, support teams maintain it,

1609
00:58:00,480 --> 00:58:02,720
business teams use it, it's not cutting edge anymore,

1610
00:58:02,720 --> 00:58:04,480
it's just infrastructure.

1611
00:58:04,480 --> 00:58:07,440
So why start now instead of waiting for 2027?

1612
00:58:07,440 --> 00:58:10,800
Because the gap between a pilot and full production is six months at a minimum

1613
00:58:10,800 --> 00:58:14,080
and usually much longer. If you wait until 2027 to begin,

1614
00:58:14,080 --> 00:58:16,720
you'll be entering your first pilots just as your competitors

1615
00:58:16,720 --> 00:58:18,080
are scaling their production.

1616
00:58:18,080 --> 00:58:20,720
You'll be learning the hard lessons they've already mastered

1617
00:58:20,720 --> 00:58:23,120
and you'll be paying the price for their early mistakes.

1618
00:58:23,120 --> 00:58:26,080
The organizations that begin right now will have worked through the pilot phase

1619
00:58:26,080 --> 00:58:27,920
by the time these GA features arrive.

1620
00:58:27,920 --> 00:58:30,560
They'll have real agents in production, real user feedback,

1621
00:58:30,560 --> 00:58:31,760
and real optimization.

1622
00:58:31,760 --> 00:58:34,960
When dataverse MCP goes GA and the agent framework matures,

1623
00:58:34,960 --> 00:58:36,000
they aren't learning.

1624
00:58:36,000 --> 00:58:37,440
They're scaling.

1625
00:58:37,440 --> 00:58:39,680
That is the competitive advantage.

1626
00:58:39,680 --> 00:58:44,960
What you do Monday morning, stop planning, start doing Monday morning,

1627
00:58:44,960 --> 00:58:49,440
register an enter ID app with pkce enabled and walk through the setup we covered

1628
00:58:49,440 --> 00:58:50,480
in this episode.

1629
00:58:50,480 --> 00:58:53,760
Test the streamable HTTP endpoint with claw desktop on your own machine

1630
00:58:53,760 --> 00:58:55,200
just to verify that it works.

1631
00:58:55,200 --> 00:58:56,800
Don't worry about an elaborate pilot yet.

1632
00:58:56,800 --> 00:58:58,560
This is five minutes of configuration.

1633
00:58:58,560 --> 00:59:00,080
Then identify just one use case.

1634
00:59:00,080 --> 00:59:03,200
Find one process that agents could genuinely improve right now.

1635
00:59:03,200 --> 00:59:05,600
It could be a support team qualifying tickets,

1636
00:59:05,600 --> 00:59:09,360
a sales team researching prospects or an operations team checking inventory.

1637
00:59:09,360 --> 00:59:11,360
Pick something real that has a clear owner.

1638
00:59:11,360 --> 00:59:14,000
Map your dataverse schema to the MCP tool surface.

1639
00:59:14,000 --> 00:59:17,040
Decide which tables matter, which fields are necessary,

1640
00:59:17,040 --> 00:59:19,760
and what queries your agents would actually need to run.

1641
00:59:19,760 --> 00:59:20,720
Document this.

1642
00:59:20,720 --> 00:59:23,120
It doesn't need to be perfect, but it needs to be real.

1643
00:59:23,120 --> 00:59:24,160
Choose your agents.

1644
00:59:24,160 --> 00:59:27,440
Will Claude handle the work, or will you use GitHub co-pilot?

1645
00:59:27,440 --> 00:59:30,240
Decide which environments each one connects to now,

1646
00:59:30,240 --> 00:59:32,400
because planning this early prevents a massive

1647
00:59:32,400 --> 00:59:34,000
misconfiguration later.

1648
00:59:34,000 --> 00:59:36,640
Start with that one integration and that one use case

1649
00:59:36,640 --> 00:59:38,160
with those agents in that environment.

1650
00:59:38,160 --> 00:59:40,320
It's rate based on real usage, not theory.

1651
00:59:40,320 --> 00:59:42,320
The proxy is dead, the fabric is now.