The End of Prompting: How to Build the Copilot Agent Fabric

1
00:00:00,000 --> 00:00:03,240
The end of prompting, how to build the co-pilot agent fabric.

2
00:00:03,240 --> 00:00:06,040
Prompting is a bridge to a world that no longer exists.

3
00:00:06,040 --> 00:00:09,800
For three years, we've been told that better adjectives and longer instructions

4
00:00:09,800 --> 00:00:11,240
would unlock productivity.

5
00:00:11,240 --> 00:00:15,360
We were told to write more detailed prompts, chain our thoughts, and ask the AI to think

6
00:00:15,360 --> 00:00:16,480
step by step.

7
00:00:16,480 --> 00:00:19,280
And it worked for about six months than something broke.

8
00:00:19,280 --> 00:00:21,160
Most people use co-pilot like a search bar.

9
00:00:21,160 --> 00:00:23,720
They ask at a question, they get an answer, and they move on.

10
00:00:23,720 --> 00:00:27,800
It feels productive, but it's not, because that assumption that co-pilot is just a better

11
00:00:27,800 --> 00:00:30,440
search interface is fundamentally broken.

12
00:00:30,440 --> 00:00:32,520
You're not here to learn how to write better prompts.

13
00:00:32,520 --> 00:00:36,800
You're not here to master the art of adjectives or learn the latest prompt engineering framework.

14
00:00:36,800 --> 00:00:39,680
We aren't going to spend 30 minutes on prompt craft.

15
00:00:39,680 --> 00:00:43,400
We're here because the shift from execution to orchestration is already happening.

16
00:00:43,400 --> 00:00:46,880
And your organization is either building toward it or falling behind it.

17
00:00:46,880 --> 00:00:51,680
If this changes how you think about agents, co-pilot, and the future of work in 2026, subscribe

18
00:00:51,680 --> 00:00:52,680
to M365FM.

19
00:00:52,680 --> 00:00:54,720
You'll stay ahead of the shift.

20
00:00:54,720 --> 00:00:56,320
The flow in the chatbot model.

21
00:00:56,320 --> 00:01:00,440
The industry sold you a chatbot, but what they should have sold you is a reasoning layer.

22
00:01:00,440 --> 00:01:01,440
Here's what actually happened.

23
00:01:01,440 --> 00:01:06,520
You licensed Microsoft 365 co-pilot, and it arrived as a text box in Word Excel and Teams.

24
00:01:06,520 --> 00:01:11,120
Your IT team rolled it out, people experimented, and a few early adopters found uses like drafting

25
00:01:11,120 --> 00:01:13,960
emails, summarizing meetings, or brainstorming headlines.

26
00:01:13,960 --> 00:01:14,960
It felt magical.

27
00:01:14,960 --> 00:01:17,920
Adoption metrics looked good, and usage spiked.

28
00:01:17,920 --> 00:01:19,920
Then it plateaued.

29
00:01:19,920 --> 00:01:23,960
Most organizations are stuck in the old model of manual interaction.

30
00:01:23,960 --> 00:01:25,140
User opens word.

31
00:01:25,140 --> 00:01:26,140
User types are prompt.

32
00:01:26,140 --> 00:01:27,140
User waits.

33
00:01:27,140 --> 00:01:28,140
User reads the output.

34
00:01:28,140 --> 00:01:29,520
User decides if it's good enough.

35
00:01:29,520 --> 00:01:31,200
If not, user rewrites the prompt.

36
00:01:31,200 --> 00:01:32,280
User waits again.

37
00:01:32,280 --> 00:01:36,560
This loop repeats five times, sometimes ten times, and eventually the user just does it themselves

38
00:01:36,560 --> 00:01:37,560
because it's faster.

39
00:01:37,560 --> 00:01:39,160
That's not a productivity system.

40
00:01:39,160 --> 00:01:40,600
That's a tax on your workflow.

41
00:01:40,600 --> 00:01:45,120
The reason for this is that you're treating the AI like an assistant that needs constant supervision.

42
00:01:45,120 --> 00:01:48,360
You're treating it like an intern who needs feedback on every draft or like a tool that's

43
00:01:48,360 --> 00:01:51,960
smart enough to help, but not smart enough to own the outcome.

44
00:01:51,960 --> 00:01:54,600
What engineering is a low leverage trap for architects?

45
00:01:54,600 --> 00:01:59,200
It looks like control, and it feels like customization, but it's actually attacks on every single

46
00:01:59,200 --> 00:02:00,200
user.

47
00:02:00,200 --> 00:02:02,920
Every person who touches co-pilot becomes a prompt consultant.

48
00:02:02,920 --> 00:02:06,600
Every workflow depends on the user's ability to ask the right question in the right way.

49
00:02:06,600 --> 00:02:07,720
That scales to nothing.

50
00:02:07,720 --> 00:02:08,720
It doesn't compound.

51
00:02:08,720 --> 00:02:09,720
It doesn't improve.

52
00:02:09,720 --> 00:02:11,440
It just spreads the manual work further.

53
00:02:11,440 --> 00:02:14,880
The most insidious thing about the chatbot model is the usage cliff.

54
00:02:14,880 --> 00:02:17,960
It's real, and you can track it in any organization.

55
00:02:17,960 --> 00:02:20,320
Week one of co-pilot adoption is excitement.

56
00:02:20,320 --> 00:02:23,800
Week four is experimentation, and week eight is the novelty wearing off.

57
00:02:23,800 --> 00:02:27,720
By week 12, the people who aren't getting immediate value from asking questions have simply

58
00:02:27,720 --> 00:02:29,040
stopped asking questions.

59
00:02:29,040 --> 00:02:30,600
That's not because co-pilot is bad.

60
00:02:30,600 --> 00:02:32,240
That's because the interface is broken.

61
00:02:32,240 --> 00:02:33,760
Most people think the problem is the AI.

62
00:02:33,760 --> 00:02:35,040
They say it's not accurate enough.

63
00:02:35,040 --> 00:02:38,760
It hallucinates, or it needs better fine tuning, but that's not the diagnosis.

64
00:02:38,760 --> 00:02:40,200
The diagnosis is this.

65
00:02:40,200 --> 00:02:44,640
Your organization is asking individual users to manage the complexity of a system that should

66
00:02:44,640 --> 00:02:45,880
be automated.

67
00:02:45,880 --> 00:02:49,320
The shift from task first to outcome first thinking solves this.

68
00:02:49,320 --> 00:02:52,600
Task first means generator draft of this email.

69
00:02:52,600 --> 00:02:56,920
Outcome first means respond to every inbound customer email within two hours, with a draft

70
00:02:56,920 --> 00:03:01,000
that maintains our brand voice, flags urgency, and suggests next steps.

71
00:03:01,000 --> 00:03:02,740
All without human intervention.

72
00:03:02,740 --> 00:03:04,520
One of those scales, the other one doesn't.

73
00:03:04,520 --> 00:03:06,080
He is where most organizations break.

74
00:03:06,080 --> 00:03:09,640
They invest in co-pilot, train users on prompting, and declare victory.

75
00:03:09,640 --> 00:03:13,840
They measure success in number of users who've tried it, or percentage of daily active

76
00:03:13,840 --> 00:03:14,840
users.

77
00:03:14,840 --> 00:03:16,600
But they never measure what actually matters.

78
00:03:16,600 --> 00:03:17,600
Did the outcome improve?

79
00:03:17,600 --> 00:03:18,720
Did the workflow speed up?

80
00:03:18,720 --> 00:03:20,680
Did the person have to supervise the AI?

81
00:03:20,680 --> 00:03:21,960
Or did the AI handle the work?

82
00:03:21,960 --> 00:03:24,280
Your productivity isn't stalling because of the AI.

83
00:03:24,280 --> 00:03:26,080
It's stalling because of the interface.

84
00:03:26,080 --> 00:03:27,920
You built a chatbot delivery model.

85
00:03:27,920 --> 00:03:29,440
You needed an orchestration model.

86
00:03:29,440 --> 00:03:33,080
And that shift from prompt-driven assistance to agent-driven orchestration is where the

87
00:03:33,080 --> 00:03:36,840
actual 100X productivity lives.

88
00:03:36,840 --> 00:03:38,920
Defining the co-pilot agent fabric.

89
00:03:38,920 --> 00:03:40,480
So what replaces the chatbot model?

90
00:03:40,480 --> 00:03:41,880
The co-pilot agent fabric.

91
00:03:41,880 --> 00:03:45,640
Think of it not as a single intelligence, but as a networked system of specialized

92
00:03:45,640 --> 00:03:48,720
intelligences where each one owns a specific domain.

93
00:03:48,720 --> 00:03:52,760
Each agent has its own knowledge, its own tools, and its own decision-making logic.

94
00:03:52,760 --> 00:03:56,200
They don't overlap or argue, but instead hand off work to each other based on context

95
00:03:56,200 --> 00:03:57,200
and expertise.

96
00:03:57,200 --> 00:03:59,160
A standalone co-pilot is monolithic.

97
00:03:59,160 --> 00:04:03,160
You have one AI, one context window, and one set of instructions trying to be smart about

98
00:04:03,160 --> 00:04:04,160
everything at once.

99
00:04:04,160 --> 00:04:08,600
It knows your email, your calendar, your files, your policies, and your team structure,

100
00:04:08,600 --> 00:04:11,200
but all those details compete for the same reasoning space.

101
00:04:11,200 --> 00:04:12,560
The result is a generalist.

102
00:04:12,560 --> 00:04:14,120
That's an expert in nothing.

103
00:04:14,120 --> 00:04:18,280
Working until it doesn't, hallucinating on details, and failing to sustain complexity.

104
00:04:18,280 --> 00:04:22,160
A skill-based agent is different because it's narrow and focused on one outcome.

105
00:04:22,160 --> 00:04:26,640
Because it's responsible for that one result, it owns the entire workflow to deliver it.

106
00:04:26,640 --> 00:04:30,440
It has access to specific data and knows the rules that govern its domain.

107
00:04:30,440 --> 00:04:33,760
It's been tested for that domain and it can fail safely because failure in one narrow

108
00:04:33,760 --> 00:04:36,120
area doesn't compromise the whole system.

109
00:04:36,120 --> 00:04:37,520
This is where skills become critical.

110
00:04:37,520 --> 00:04:43,240
They're the evolution of the standard operating procedure or the SOP, which every organization already has.

111
00:04:43,240 --> 00:04:47,200
Firing procedures, quote, "approval processes" and customer onboarding checklists have been

112
00:04:47,200 --> 00:04:50,160
documented as PDFs and word documents for decades.

113
00:04:50,160 --> 00:04:54,400
We've trained people to follow them and measure whether they did, but the execution was always

114
00:04:54,400 --> 00:04:55,400
manual.

115
00:04:55,400 --> 00:04:56,400
But here's what changed.

116
00:04:56,400 --> 00:05:00,880
SOPs were always meant to be executed by humans, but now they can be executed by agents.

117
00:05:00,880 --> 00:05:05,400
A skill is an SOP that's been translated into a language and AI can follow, improve,

118
00:05:05,400 --> 00:05:06,560
and reason about.

119
00:05:06,560 --> 00:05:10,080
It uses the same structure and the same logic, but it's no longer blocking a human.

120
00:05:10,080 --> 00:05:12,160
It's freeing one.

121
00:05:12,160 --> 00:05:14,720
The fabric itself rests on three pillars.

122
00:05:14,720 --> 00:05:17,320
Event, reasoning, and orchestration.

123
00:05:17,320 --> 00:05:18,920
Event is the trigger.

124
00:05:18,920 --> 00:05:22,580
Something happens in your system like an email arriving or a deadline passing and that

125
00:05:22,580 --> 00:05:23,920
event reaches an orchestrator.

126
00:05:23,920 --> 00:05:27,960
The orchestrator looks at that event and asks what outcome is required and which agent

127
00:05:27,960 --> 00:05:29,200
owns it.

128
00:05:29,200 --> 00:05:31,680
Reasoning is what happens inside the specialized agent.

129
00:05:31,680 --> 00:05:35,180
It takes the event context and retrieves relevant data from business systems and knowledge

130
00:05:35,180 --> 00:05:36,840
sources to make a decision.

131
00:05:36,840 --> 00:05:40,960
This happens in isolation from every other agent, which means there's no context overload

132
00:05:40,960 --> 00:05:43,720
and no reasoning about five different domains at once.

133
00:05:43,720 --> 00:05:46,800
One agent, one domain, one outcome, orchestration is the glue.

134
00:05:46,800 --> 00:05:50,960
It's the parent agent that receives the event, selects the right specialist and passes just

135
00:05:50,960 --> 00:05:53,120
enough context to make the decision.

136
00:05:53,120 --> 00:05:57,280
It waits for the result, then either responds to the user, passes the work to the next agent,

137
00:05:57,280 --> 00:05:59,640
or triggers an action in your business systems.

138
00:05:59,640 --> 00:06:02,520
This creates a personal AI operating system for the organization.

139
00:06:02,520 --> 00:06:06,880
Each department gets agents that understand its domain and because each outcome is measurable,

140
00:06:06,880 --> 00:06:08,640
every failure is iselable and fixable.

141
00:06:08,640 --> 00:06:11,960
The whole system runs continuously without needing constant supervision.

142
00:06:11,960 --> 00:06:16,120
It actually gets smarter as it processes more work because every failure teaches the agent

143
00:06:16,120 --> 00:06:17,840
what to do differently next time.

144
00:06:17,840 --> 00:06:18,960
This is the structural shift.

145
00:06:18,960 --> 00:06:22,560
It isn't about better prompting or more data in the context window, its organizational

146
00:06:22,560 --> 00:06:23,560
redesign.

147
00:06:23,560 --> 00:06:27,840
The work moves from a person asking an AI for help to an AI owning the workflow end to end.

148
00:06:27,840 --> 00:06:31,760
The person becomes a designer of agents rather than a supervisor of outputs.

149
00:06:31,760 --> 00:06:36,160
But to build this, we have to look at something most architect skip, which is the data.

150
00:06:36,160 --> 00:06:40,840
An agent is only as intelligent as the data it can reason over and most organizations data

151
00:06:40,840 --> 00:06:43,240
is a catastrophe waiting to happen.

152
00:06:43,240 --> 00:06:45,360
Grounding, the architecture of truth.

153
00:06:45,360 --> 00:06:47,560
Here's the problem architects don't want to face.

154
00:06:47,560 --> 00:06:51,400
Copilot is only as smart as the graph data it can reason over, not your prompts or your

155
00:06:51,400 --> 00:06:52,400
models training.

156
00:06:52,400 --> 00:06:57,320
It says smart as the data and most data in most organizations is structurally incoherent.

157
00:06:57,320 --> 00:07:00,840
When Microsoft Graph indexes your environment, it's looking for meaning.

158
00:07:00,840 --> 00:07:04,160
It wants to know who approved a file when it changed and what depends on it.

159
00:07:04,160 --> 00:07:08,760
It's trying to build relationships so that when copilot reasons over your content, it understands

160
00:07:08,760 --> 00:07:11,760
context and authority rather than just finding documents.

161
00:07:11,760 --> 00:07:15,880
But if your SharePoint is a flat dump of folders named archive and final final, the graph has

162
00:07:15,880 --> 00:07:17,120
nothing to work with.

163
00:07:17,120 --> 00:07:19,360
It can do keyword search, but it cannot reason.

164
00:07:19,360 --> 00:07:22,800
An agent without reasoning capability is just a faster search box.

165
00:07:22,800 --> 00:07:25,760
The industry sold storage mapping for 20 years.

166
00:07:25,760 --> 00:07:29,360
Telling you to move your file shares to SharePoint and keep the same folder structure.

167
00:07:29,360 --> 00:07:33,280
This approach is killing agent performance across every organization that bought it because

168
00:07:33,280 --> 00:07:35,200
the agent inherits the incoherence.

169
00:07:35,200 --> 00:07:37,080
Copilot looks at your content and sees noise.

170
00:07:37,080 --> 00:07:39,000
You need semantic modeling instead.

171
00:07:39,000 --> 00:07:42,780
Semantic modeling means designing your information architecture around what the agent needs

172
00:07:42,780 --> 00:07:46,000
to reason about, not how you've been filing things for the last decade.

173
00:07:46,000 --> 00:07:50,880
You have to ask what relationships matter and what signals an agent needs to make a decision.

174
00:07:50,880 --> 00:07:53,720
Metadata is what transforms data into knowledge.

175
00:07:53,720 --> 00:07:55,080
Consider a quote generation agent.

176
00:07:55,080 --> 00:07:58,520
It needs to know which customers have approved pricing and what the approval hierarchy looks

177
00:07:58,520 --> 00:07:59,520
like.

178
00:07:59,520 --> 00:08:02,400
That's not information buried in documents and it's not something a human can find by

179
00:08:02,400 --> 00:08:04,040
scrolling through shared folders.

180
00:08:04,040 --> 00:08:05,040
That's relationships.

181
00:08:05,040 --> 00:08:07,440
It must be structured, queryable and verifiable.

182
00:08:07,440 --> 00:08:11,320
If your contracts live in one library and you're pricing in another, the agent has to guess

183
00:08:11,320 --> 00:08:12,560
about relationships.

184
00:08:12,560 --> 00:08:13,880
It has to hallucinate details.

185
00:08:13,880 --> 00:08:16,400
It can't verify and it gets it wrong half the time.

186
00:08:16,400 --> 00:08:19,440
Instead, structure the metadata so relationships are explicit.

187
00:08:19,440 --> 00:08:25,080
A contract should have properties like approved by and effective date linked to your HR records

188
00:08:25,080 --> 00:08:26,560
and product taxonomy.

189
00:08:26,560 --> 00:08:27,920
Suddenly the agent doesn't search.

190
00:08:27,920 --> 00:08:28,920
It reasons.

191
00:08:28,920 --> 00:08:32,040
It walks the relationships and constructs a coherent picture.

192
00:08:32,040 --> 00:08:34,480
This is why file share lift and shift is the silent killer.

193
00:08:34,480 --> 00:08:38,320
You move the files but you didn't move the thinking so the agent still can't reason.

194
00:08:38,320 --> 00:08:40,960
Structuring metadata transforms what the agent can do.

195
00:08:40,960 --> 00:08:41,960
Metadata is signaling.

196
00:08:41,960 --> 00:08:45,720
It tells the agent how to rank and reason instead of just finding.

197
00:08:45,720 --> 00:08:50,040
High signal relationships like owned by or supersedes show authority and what's current

198
00:08:50,040 --> 00:08:51,480
versus what's legacy.

199
00:08:51,480 --> 00:08:52,960
You're designing for answerability.

200
00:08:52,960 --> 00:08:55,440
That means using atomic records over text blobs.

201
00:08:55,440 --> 00:08:59,400
A text blob is just a word document describing a policy but an atomic record is a structured

202
00:08:59,400 --> 00:09:02,280
entry with fields for effective dates and customer segments.

203
00:09:02,280 --> 00:09:05,400
The agent can't reason over a blob but it can interrogate a record.

204
00:09:05,400 --> 00:09:06,400
This is structural work.

205
00:09:06,400 --> 00:09:08,640
It's not sexy and it's not about the latest feature.

206
00:09:08,640 --> 00:09:12,080
It's about whether your organization's information makes sense to an intelligence that

207
00:09:12,080 --> 00:09:14,800
doesn't have decades of tacit context.

208
00:09:14,800 --> 00:09:18,120
Most organizations haven't done this because they've treated information architecture as a

209
00:09:18,120 --> 00:09:21,000
filing system problem rather than an intelligence problem.

210
00:09:21,000 --> 00:09:24,080
Your agents will operate at the ceiling of your schema quality.

211
00:09:24,080 --> 00:09:28,560
You can have the best reasoning layer in the world but if the data underneath is incoherent,

212
00:09:28,560 --> 00:09:32,880
the agent produces incoherent output and when that happens executive stop using it, this

213
00:09:32,880 --> 00:09:36,680
level of structured reasoning requires something architects keep underestimating.

214
00:09:36,680 --> 00:09:38,440
It requires a protocol.

215
00:09:38,440 --> 00:09:40,920
The hundreds workflow quoting as a case study.

216
00:09:40,920 --> 00:09:42,000
Let me make this concrete.

217
00:09:42,000 --> 00:09:45,920
The shift from faster prompting to agent orchestration doesn't live in theory and it actually

218
00:09:45,920 --> 00:09:48,920
lives in the workflows where time and compliance collide.

219
00:09:48,920 --> 00:09:52,160
Think about a manufacturing company receiving a request for a complex quote.

220
00:09:52,160 --> 00:09:56,520
The customer has a specific SKU, a certain volume and a particular geography that requires

221
00:09:56,520 --> 00:09:57,680
expedited delivery.

222
00:09:57,680 --> 00:10:01,640
This person has been a customer for three years but they haven't purchased this specific product

223
00:10:01,640 --> 00:10:02,800
category before.

224
00:10:02,800 --> 00:10:06,600
To get this right, the quote needs to account for volume discounts, regional pricing variations

225
00:10:06,600 --> 00:10:08,000
and inventory constraints.

226
00:10:08,000 --> 00:10:11,960
You also have to check if they qualify for fast fulfillment, what the current profit margin

227
00:10:11,960 --> 00:10:15,920
looks like, if there are active promotions and which executive needs to sign off based

228
00:10:15,920 --> 00:10:17,240
on the deal size.

229
00:10:17,240 --> 00:10:19,320
In the old model, here's what actually happens.

230
00:10:19,320 --> 00:10:22,920
A salesperson receives the request and opens a spreadsheet of customer records to check

231
00:10:22,920 --> 00:10:25,840
credit history, which usually takes about five minutes.

232
00:10:25,840 --> 00:10:27,480
Then they navigate to the pricing database.

233
00:10:27,480 --> 00:10:29,360
A different system with a different login.

234
00:10:29,360 --> 00:10:33,240
To find the base price for that SKU, that is another five minutes gone, they check the promotion

235
00:10:33,240 --> 00:10:37,640
calendar for three minutes and then they spend four minutes looking up the inventory system

236
00:10:37,640 --> 00:10:39,560
to confirm availability.

237
00:10:39,560 --> 00:10:44,160
Calculating the discount based on volume requires checking a table in a PDF stored on SharePoint

238
00:10:44,160 --> 00:10:45,680
and that takes another three minutes.

239
00:10:45,680 --> 00:10:49,880
They spend two minutes reviewing the approval matrix to see who signs off and then they finally

240
00:10:49,880 --> 00:10:51,480
draft the quote in word.

241
00:10:51,480 --> 00:10:55,280
They are manually assembling numbers from multiple systems, copying and pasting and checking

242
00:10:55,280 --> 00:10:58,800
their math twice because a single mistake damages their credibility.

243
00:10:58,800 --> 00:11:03,480
The total time for this process is 60 to 90 minutes and that is the best case scenario where

244
00:11:03,480 --> 00:11:05,680
everything is in stock and no exceptions are needed.

245
00:11:05,680 --> 00:11:10,140
If the customer qualifies for a promotional discount that isn't in the standard table,

246
00:11:10,140 --> 00:11:14,000
you can add 30 minutes of back and forth with the promotions team.

247
00:11:14,000 --> 00:11:17,640
If the deal requires executive approval, you have to add another roundtrip.

248
00:11:17,640 --> 00:11:22,240
When there is ambiguity about whether this customer class qualifies for expedited fulfillment,

249
00:11:22,240 --> 00:11:25,520
the salesperson has to call operations and that eats up even more time.

250
00:11:25,520 --> 00:11:28,920
The quote that finally arrives is often inconsistent with the last one sent to a similar

251
00:11:28,920 --> 00:11:33,600
customer because the discounts were calculated differently or the salesperson simply forgot

252
00:11:33,600 --> 00:11:35,320
a promotion.

253
00:11:35,320 --> 00:11:39,160
Finance gets the quote and has to validate the math, which often leads to finding errors

254
00:11:39,160 --> 00:11:40,920
and sending it back for revisions.

255
00:11:40,920 --> 00:11:44,000
The customer loses confidence and the deal cycle extends.

256
00:11:44,000 --> 00:11:46,440
Now imagine an agent owns this entire workflow.

257
00:11:46,440 --> 00:11:50,080
The agent receives the same request but it has been trained on the pricing engine, the

258
00:11:50,080 --> 00:11:53,560
inventory system, the customer database and the approval matrix.

259
00:11:53,560 --> 00:11:56,880
It isn't searching for files or logging into different systems because it is reasoning

260
00:11:56,880 --> 00:11:58,120
over live data.

261
00:11:58,120 --> 00:12:01,480
The agent retrieves the customer record in three seconds and looks up current pricing

262
00:12:01,480 --> 00:12:02,480
in another two.

263
00:12:02,480 --> 00:12:06,720
It evaluates volume discounts, applies promotions, checks approval thresholds and calculates

264
00:12:06,720 --> 00:12:09,120
the margin impact in about 45 seconds.

265
00:12:09,120 --> 00:12:13,120
Finally it generates a compliant quote in the exact form at the company uses, complete

266
00:12:13,120 --> 00:12:17,120
with governance notation showing which policies were applied and why.

267
00:12:17,120 --> 00:12:18,720
The total time is now three minutes.

268
00:12:18,720 --> 00:12:22,560
This isn't just a faster version of the old way, it is structurally different but here

269
00:12:22,560 --> 00:12:25,000
is what separates this from good prompt engineering.

270
00:12:25,000 --> 00:12:28,920
The agent has encoded the regulations and policies into its actual reasoning.

271
00:12:28,920 --> 00:12:32,720
It doesn't guess about discount thresholds because those rules are baked into the system.

272
00:12:32,720 --> 00:12:37,800
It doesn't hallucinate about who has approval authority because it follows the actual matrix.

273
00:12:37,800 --> 00:12:41,800
Because it is querying structured data instead of assembling numbers from documents, it doesn't

274
00:12:41,800 --> 00:12:43,160
make calculation errors.

275
00:12:43,160 --> 00:12:45,360
Every quote is consistent because the logic is consistent.

276
00:12:45,360 --> 00:12:49,840
This process takes three minutes because the agent owns the entire workflow and has eliminated

277
00:12:49,840 --> 00:12:50,840
the handoffs.

278
00:12:50,840 --> 00:12:55,080
The salesperson doesn't hunt through systems, the finance team doesn't validate math and

279
00:12:55,080 --> 00:12:58,360
the ops team doesn't have to clarify fulfillment eligibility.

280
00:12:58,360 --> 00:13:02,520
The work that used to take eight separate decisions made by four different people now happens

281
00:13:02,520 --> 00:13:04,080
in one coherent chain.

282
00:13:04,080 --> 00:13:07,840
Because the agent logs every policy it applied and every decision it made, compliance

283
00:13:07,840 --> 00:13:09,360
audits become trivial.

284
00:13:09,360 --> 00:13:12,840
You can trace exactly why this customer got this price and proved the agent followed the

285
00:13:12,840 --> 00:13:13,840
rules.

286
00:13:13,840 --> 00:13:16,480
95% time reduction isn't just about speed.

287
00:13:16,480 --> 00:13:19,280
It is about being compliant, consistent and scalable.

288
00:13:19,280 --> 00:13:23,200
Three minutes per quote means you can generate 50 quotes a day instead of five which increases

289
00:13:23,200 --> 00:13:26,800
deal velocity and improves margin consistency while decreasing risk.

290
00:13:26,800 --> 00:13:30,520
But delivering this level of orchestration requires something most organizations haven't

291
00:13:30,520 --> 00:13:31,520
built yet.

292
00:13:31,520 --> 00:13:35,400
It requires the agent to have secure real-time access to live data systems rather than

293
00:13:35,400 --> 00:13:36,800
just documents or emails.

294
00:13:36,800 --> 00:13:39,120
To do that, you need a protocol.

295
00:13:39,120 --> 00:13:40,440
Model context protocol.

296
00:13:40,440 --> 00:13:41,440
MCP.

297
00:13:41,440 --> 00:13:42,360
The tool layer.

298
00:13:42,360 --> 00:13:46,960
The agent needs hands, but right now in most organizations those hands are broken.

299
00:13:46,960 --> 00:13:50,920
An agent can reason beautifully by evaluating complexity and following rules, but if it can't

300
00:13:50,920 --> 00:13:55,000
reach the systems that hold the truth, all of that reasoning happens in a void.

301
00:13:55,000 --> 00:13:56,000
It has to guess.

302
00:13:56,000 --> 00:14:00,880
It has to hallucinate connections between data it can't verify and it becomes a more sophisticated

303
00:14:00,880 --> 00:14:03,120
version of the very problem you're trying to solve.

304
00:14:03,120 --> 00:14:06,360
This is where the model context protocol or MCP arrives.

305
00:14:06,360 --> 00:14:09,000
I call MCP the USB-C for AI.

306
00:14:09,000 --> 00:14:13,520
For USB-C you had proprietary cables for everything which meant different devices, different standards

307
00:14:13,520 --> 00:14:14,680
and different connectors.

308
00:14:14,680 --> 00:14:19,280
If you wanted to plug your AI application into your ERP system you had to build a custom integration.

309
00:14:19,280 --> 00:14:22,080
If you wanted to connect to your CRM, you built another one.

310
00:14:22,080 --> 00:14:26,240
Adding a data warehouse or a knowledge base meant writing custom glue code for each one,

311
00:14:26,240 --> 00:14:29,640
making every connection bespoke and every integration take months.

312
00:14:29,640 --> 00:14:33,280
Every system you added to your agent's reach required massive engineering effort.

313
00:14:33,280 --> 00:14:35,040
MCP is a universal connector.

314
00:14:35,040 --> 00:14:39,560
It is a protocol that defines how any AI application talks to any data system.

315
00:14:39,560 --> 00:14:44,080
This doesn't happen through custom APIs or specific vendor integrations but through a standard,

316
00:14:44,080 --> 00:14:46,600
discoverable and authenticated channel.

317
00:14:46,600 --> 00:14:51,200
An ERP vendor can publish an MCP server and a CRM can expose itself the same way.

318
00:14:51,200 --> 00:14:57,360
Your data warehouse, your knowledge base and your internal APIs can all be MCP servers.

319
00:14:57,360 --> 00:15:01,760
Any agent, whether it is Claude, a copilot or a custom engine, can connect to them using

320
00:15:01,760 --> 00:15:02,960
the same protocol.

321
00:15:02,960 --> 00:15:04,960
For architects this changes everything.

322
00:15:04,960 --> 00:15:07,920
Without MCP you are stuck in an integration debt spiral.

323
00:15:07,920 --> 00:15:11,600
You build an agent and the business says they needed to access the pricing engine so

324
00:15:11,600 --> 00:15:12,920
you build a connector.

325
00:15:12,920 --> 00:15:15,560
Then they say it needs customer history so you build another one.

326
00:15:15,560 --> 00:15:19,640
Then it is supply chain visibility, commission calculations and competitor intelligence.

327
00:15:19,640 --> 00:15:24,040
For every new capability you are writing code, managing versions and handling authentication

328
00:15:24,040 --> 00:15:25,720
differently for each system.

329
00:15:25,720 --> 00:15:28,680
With MCP you move beyond guessing and into querying.

330
00:15:28,680 --> 00:15:31,120
The agent doesn't search a document and infer a price.

331
00:15:31,120 --> 00:15:34,360
It queries the live pricing system through an MCP server.

332
00:15:34,360 --> 00:15:38,000
It doesn't hunt through email for customer history because it calls the CRM through an

333
00:15:38,000 --> 00:15:39,560
MCP connector.

334
00:15:39,560 --> 00:15:43,360
Instead of scraping data from a spreadsheet, it accesses the actual system of record in

335
00:15:43,360 --> 00:15:44,360
real time.

336
00:15:44,360 --> 00:15:46,640
The client server relationship is straightforward.

337
00:15:46,640 --> 00:15:50,600
The agent is the MCP client and your business systems are the MCP servers.

338
00:15:50,600 --> 00:15:54,640
They expose their capabilities, what tools they provide and what data they can access in

339
00:15:54,640 --> 00:15:56,800
a standard format that the agent understands.

340
00:15:56,800 --> 00:16:00,960
The agent discovers what is available, makes a request and gets back structured data.

341
00:16:00,960 --> 00:16:03,560
It can reason over without any guessing or inference.

342
00:16:03,560 --> 00:16:07,480
For architects, MCP becomes the primary lever for tool and data governance.

343
00:16:07,480 --> 00:16:11,480
Instead of building custom security for each integration, you define your governance,

344
00:16:11,480 --> 00:16:13,800
authentication and rate limiting once.

345
00:16:13,800 --> 00:16:18,040
Every system that talks to the agent through MCP inherits that same security posture.

346
00:16:18,040 --> 00:16:20,840
You aren't managing dozens of ad hoc connections anymore.

347
00:16:20,840 --> 00:16:25,320
You are managing one protocol enforced across your entire agent fabric because capabilities

348
00:16:25,320 --> 00:16:27,400
are exposed as standardized tools.

349
00:16:27,400 --> 00:16:28,800
They are also discoverable.

350
00:16:28,800 --> 00:16:32,240
An agent doesn't need to know which systems are available in advance because it can simply

351
00:16:32,240 --> 00:16:34,120
query the MCP registry.

352
00:16:34,120 --> 00:16:38,080
When it needs to check inventory or look up a policy, those tools are already listed and

353
00:16:38,080 --> 00:16:39,080
ready to use.

354
00:16:39,080 --> 00:16:43,120
The agent becomes extensible, meaning new systems plug in without requiring new prompts or extra

355
00:16:43,120 --> 00:16:44,120
training.

356
00:16:44,120 --> 00:16:48,400
You add the capability once at the system level and every agent immediately sees it.

357
00:16:48,400 --> 00:16:50,920
This transforms what an agent can actually do.

358
00:16:50,920 --> 00:16:55,080
Instead of working with inferences drawn from documents, the agent works with facts.

359
00:16:55,080 --> 00:16:57,560
Instead of assuming relationships, it verifies them.

360
00:16:57,560 --> 00:17:02,160
The confidence in the agent's output rises because the foundation underneath is solid.

361
00:17:02,160 --> 00:17:05,920
Tools are the agent's hands and MCP gives those hands reach, but hands without direction

362
00:17:05,920 --> 00:17:09,600
are just movement and the agent still needs the ability to delegate.

363
00:17:09,600 --> 00:17:13,120
That is where orchestration shifts from the tool layer to the collaboration layer.

364
00:17:13,120 --> 00:17:15,920
Agent to agent, A2A, the delegation layer.

365
00:17:15,920 --> 00:17:18,680
An agent with reach is useless if it can't delegate.

366
00:17:18,680 --> 00:17:21,280
That is where agent to agent protocols enter the picture.

367
00:17:21,280 --> 00:17:26,600
A2A is how agents talk to other agents and I don't mean through prompts or human handoffs.

368
00:17:26,600 --> 00:17:30,860
It is a standardized conversation layer that lets one agent ask another to handle a specific

369
00:17:30,860 --> 00:17:31,860
part of the work.

370
00:17:31,860 --> 00:17:35,880
This is the shift that separates a multi-person experiment from a real enterprise system.

371
00:17:35,880 --> 00:17:38,240
Think about what a monolithic co-pilot tries to do.

372
00:17:38,240 --> 00:17:42,360
It is one agent trying to cover all domains, all contexts and all responsibilities.

373
00:17:42,360 --> 00:17:46,600
It tries to be an HR expert, a finance analyst, a sales strategist and a compliance officer

374
00:17:46,600 --> 00:17:47,920
at the exact same time.

375
00:17:47,920 --> 00:17:49,880
The result is mediocrity across the board.

376
00:17:49,880 --> 00:17:52,880
It knows a little about everything, but it is an expert in nothing.

377
00:17:52,880 --> 00:17:54,800
A federation of specialists works differently.

378
00:17:54,800 --> 00:17:58,640
HR has its own agent, finance has its own and sales has its own.

379
00:17:58,640 --> 00:18:02,480
Each one is trained on its specific domain, which means it knows its own policies and

380
00:18:02,480 --> 00:18:03,880
owns its own outcomes.

381
00:18:03,880 --> 00:18:06,920
They don't compete for reasoning, space or argue about priorities.

382
00:18:06,920 --> 00:18:10,600
When work arrives that touches multiple departments, the parent agent roots it.

383
00:18:10,600 --> 00:18:14,680
It tells the finance agent to calculate the discount approval chain for a deal, while asking

384
00:18:14,680 --> 00:18:18,440
the HR agent to confirm an employee qualifies for a benefit upgrade.

385
00:18:18,440 --> 00:18:22,920
At the same time, it asks the compliance agent to verify execution in that jurisdiction.

386
00:18:22,920 --> 00:18:26,960
The parent waits for all three to respond, and then it assembles the final answer.

387
00:18:26,960 --> 00:18:28,560
This requires a contract between agents.

388
00:18:28,560 --> 00:18:33,000
It is a protocol that says, if you send a request structured a certain way, the agent will

389
00:18:33,000 --> 00:18:35,560
respond with data structured the same way.

390
00:18:35,560 --> 00:18:40,240
It promises to complete the task in a specific time frame, log its reasoning and escalate to a

391
00:18:40,240 --> 00:18:42,440
human if certain conditions are met.

392
00:18:42,440 --> 00:18:44,640
The parent agent's job is to hold the context.

393
00:18:44,640 --> 00:18:48,160
It receives a user request and understands what outcome is needed, knowing exactly which

394
00:18:48,160 --> 00:18:50,560
specialist own which pieces of that outcome.

395
00:18:50,560 --> 00:18:55,080
It assembles just enough context for each specialist to make a decision without creating information

396
00:18:55,080 --> 00:18:56,720
overload or extra noise.

397
00:18:56,720 --> 00:19:00,960
Then it validates the responses, stitches them together and responds to the user.

398
00:19:00,960 --> 00:19:03,680
None of the specialists need to know about each other.

399
00:19:03,680 --> 00:19:08,280
The HR agent doesn't understand finance, and the sales agent doesn't understand compliance.

400
00:19:08,280 --> 00:19:12,000
They don't overlap or try to maintain coherence across different domains.

401
00:19:12,000 --> 00:19:15,600
Each specialist improves at its own pace and adapts to changing regulations without ever

402
00:19:15,600 --> 00:19:17,320
touching another agent's code.

403
00:19:17,320 --> 00:19:20,840
But specialist need an identity.

404
00:19:20,840 --> 00:19:22,480
This is where agent cards matter.

405
00:19:22,480 --> 00:19:26,640
An agent card is a capability manifest that tells the fabric what the agent does, what

406
00:19:26,640 --> 00:19:28,120
it needs and how to reach it.

407
00:19:28,120 --> 00:19:32,200
It includes the agent's domain, the inputs it expects, the outputs it produces, and the

408
00:19:32,200 --> 00:19:34,720
human escalation thresholds it enforces.

409
00:19:34,720 --> 00:19:37,720
When the parent agent needs to root work, it reads these cards.

410
00:19:37,720 --> 00:19:41,840
If it needs to know which agent can handle a customer refund dispute, it scans the cards

411
00:19:41,840 --> 00:19:44,160
until the customer service agent answers.

412
00:19:44,160 --> 00:19:48,560
That agent's card says it takes a customer ID and order ID, and then it returns the approval

413
00:19:48,560 --> 00:19:49,840
status and refund amount.

414
00:19:49,840 --> 00:19:51,320
The parent doesn't have to guess.

415
00:19:51,320 --> 00:19:54,480
It reads the card and knows exactly what it is getting.

416
00:19:54,480 --> 00:19:55,960
Agent cards also enable discovery.

417
00:19:55,960 --> 00:20:00,960
New agents plug into the fabric by publishing their cards and existing agents see them immediately.

418
00:20:00,960 --> 00:20:02,640
This makes orchestration extensible.

419
00:20:02,640 --> 00:20:06,960
You can add new capabilities without retraining the parent because the parent simply reads

420
00:20:06,960 --> 00:20:09,600
the new card and learns how to use the new agent.

421
00:20:09,600 --> 00:20:11,520
This works across different timeframes.

422
00:20:11,520 --> 00:20:15,080
From workflows finishing seconds like a pricing query or a policy lookup.

423
00:20:15,080 --> 00:20:19,560
The parent asks, the specialist responds immediately and the workflows to the next step.

424
00:20:19,560 --> 00:20:21,440
Other workflows span days.

425
00:20:21,440 --> 00:20:26,000
Think about an employee onboarding that touches HR, IT, facilities and finance.

426
00:20:26,000 --> 00:20:29,480
This might involve an approval chain where each step requires a person to validate the

427
00:20:29,480 --> 00:20:30,480
work.

428
00:20:30,480 --> 00:20:33,560
The parent agent doesn't hold a connection open for days while it waits.

429
00:20:33,560 --> 00:20:37,680
Instead, it spawns a workflow where each specialist works on its piece when the work

430
00:20:37,680 --> 00:20:38,680
reaches them.

431
00:20:38,680 --> 00:20:42,480
The parent checks in periodically to see if IT provisioning is complete or to find the

432
00:20:42,480 --> 00:20:44,480
status of a facilities assignment.

433
00:20:44,480 --> 00:20:48,520
It sequences dependencies so it won't tell sales and employee is ready until HR confirms

434
00:20:48,520 --> 00:20:49,880
the benefits are active.

435
00:20:49,880 --> 00:20:53,760
If an approval is overdue, it handles the escalation by alerting the manager.

436
00:20:53,760 --> 00:20:58,480
Long-running workflows are where agent orchestration moves from individual productivity to organizational

437
00:20:58,480 --> 00:20:59,480
productivity.

438
00:20:59,480 --> 00:21:02,640
One person drafting a document faster doesn't change company revenue.

439
00:21:02,640 --> 00:21:06,840
However, 10 people working in parallel on coordinated workflows changes how the entire

440
00:21:06,840 --> 00:21:08,520
organization executes.

441
00:21:08,520 --> 00:21:12,720
To make this parallel execution work, you need a definition of what each agent does.

442
00:21:12,720 --> 00:21:14,200
You have to encode the work itself.

443
00:21:14,200 --> 00:21:15,720
That isn't a contract between agents.

444
00:21:15,720 --> 00:21:17,880
It is a contract between a person and an agent.

445
00:21:17,880 --> 00:21:19,040
That is a skill.

446
00:21:19,040 --> 00:21:20,680
Anatomy of a co-pilot skill.

447
00:21:20,680 --> 00:21:22,120
A skill is not a prompt.

448
00:21:22,120 --> 00:21:24,280
It is not a configuration file or a template.

449
00:21:24,280 --> 00:21:29,080
It is a specification that acts as a contract between what the agent should do and what

450
00:21:29,080 --> 00:21:30,080
it actually does.

451
00:21:30,080 --> 00:21:35,040
It is the difference between giving an agent a suggestion and giving an agent a law.

452
00:21:35,040 --> 00:21:37,160
Every skill lives in a single file called skill.

453
00:21:37,160 --> 00:21:39,200
MD, it is just plain text markdown.

454
00:21:39,200 --> 00:21:42,360
There are no databases, no XMLs, brawl and no proprietary formats.

455
00:21:42,360 --> 00:21:46,800
It is a structured text file that sits in your repository and defines the complete operational

456
00:21:46,800 --> 00:21:47,800
logic.

457
00:21:47,800 --> 00:21:48,800
That file is non-negotiable.

458
00:21:48,800 --> 00:21:52,440
If your skill doesn't have a skill, MD isn't a skill, it is just a prompt or an experiment

459
00:21:52,440 --> 00:21:54,520
and it isn't ready for production.

460
00:21:54,520 --> 00:21:57,480
The skill.md file contains four critical components.

461
00:21:57,480 --> 00:22:00,600
Metadata, workflow, rules and reasoning gates.

462
00:22:00,600 --> 00:22:03,920
Metadata is how the orchestrator discovers and identifies the agent.

463
00:22:03,920 --> 00:22:08,640
It is your identity in the fabric, including your name, version and activation thresholds.

464
00:22:08,640 --> 00:22:12,000
Activation is critical because your skill lives alongside 50 others.

465
00:22:12,000 --> 00:22:14,960
The parent agent needs to know if this is the right skill for the job.

466
00:22:14,960 --> 00:22:16,480
The description tells that story.

467
00:22:16,480 --> 00:22:20,640
It might say it is a marketing email generator for newsletter campaigns that targets mid-market

468
00:22:20,640 --> 00:22:22,600
SaaS and preserves brand voice.

469
00:22:22,600 --> 00:22:26,280
That description is how the orchestrator reads agent cards and routes work to you instead

470
00:22:26,280 --> 00:22:27,840
of five other agents.

471
00:22:27,840 --> 00:22:31,560
Poor descriptions create ambiguity, which leads to work bouncing between specialists until

472
00:22:31,560 --> 00:22:33,360
the system loses coherence.

473
00:22:33,360 --> 00:22:36,360
Metadata also includes your namespace and your promised outputs.

474
00:22:36,360 --> 00:22:40,440
You have to define what data structure you expect like a customer email address or a campaign

475
00:22:40,440 --> 00:22:41,440
ID.

476
00:22:41,440 --> 00:22:45,600
Then you define what you return such as an HTML email draft and a tone-confident score.

477
00:22:45,600 --> 00:22:46,600
This is the contract.

478
00:22:46,600 --> 00:22:50,840
The parent agent sends data, shaped one way and you return data, shaped the other way.

479
00:22:50,840 --> 00:22:53,480
There are no surprises and no room for interpretation.

480
00:22:53,480 --> 00:22:55,080
Workflow is the operational core.

481
00:22:55,080 --> 00:22:57,760
It is the step-by-step logic of how you approach the work.

482
00:22:57,760 --> 00:22:58,920
This isn't generic advice.

483
00:22:58,920 --> 00:23:01,640
It is the exact sequence you follow every single time.

484
00:23:01,640 --> 00:23:04,720
First, you might retrieve customer emails from the past 12 months.

485
00:23:04,720 --> 00:23:08,120
Second, you extract voice patterns like tone and sentence structure.

486
00:23:08,120 --> 00:23:09,920
Third, you read the brand guidelines.

487
00:23:09,920 --> 00:23:11,600
Fourth, you synthesizer draft.

488
00:23:11,600 --> 00:23:13,600
Fifth, you apply the regulatory language.

489
00:23:13,600 --> 00:23:15,880
Sixth, you validate the draft against the checklist.

490
00:23:15,880 --> 00:23:18,240
Finally, you return the output with reasoning notes.

491
00:23:18,240 --> 00:23:19,600
Each step is explicit.

492
00:23:19,600 --> 00:23:21,640
There is no ambiguity about what comes next.

493
00:23:21,640 --> 00:23:24,560
The agent executing this workflow doesn't interpret the instructions.

494
00:23:24,560 --> 00:23:26,000
It simply follows them.

495
00:23:26,000 --> 00:23:29,520
If a step fails because a template is missing, the workflow fails cleanly.

496
00:23:29,520 --> 00:23:31,440
The agent doesn't hallucinate compliance language.

497
00:23:31,440 --> 00:23:33,280
It reports the failure and stops.

498
00:23:33,280 --> 00:23:36,360
That failure then becomes data that updates the reasoning gates.

499
00:23:36,360 --> 00:23:37,800
Rules are the guardrails.

500
00:23:37,800 --> 00:23:41,680
They are what prevent the agent from hallucinating style or inventing brand language.

501
00:23:41,680 --> 00:23:44,880
They are constraints on reasoning that the agent must follow.

502
00:23:44,880 --> 00:23:48,720
You might have a rule to never exceed four sentences per paragraph or to always include

503
00:23:48,720 --> 00:23:50,280
an unsubscribe link.

504
00:23:50,280 --> 00:23:51,280
These aren't suggestions.

505
00:23:51,280 --> 00:23:54,720
They are boundaries the agent respects or the output gets rejected.

506
00:23:54,720 --> 00:23:56,640
Underneath everything sits self-aneling.

507
00:23:56,640 --> 00:23:58,200
This is how the skill heals itself.

508
00:23:58,200 --> 00:24:00,200
Every execution and every failure is logged.

509
00:24:00,200 --> 00:24:03,440
The agent reads those logs and improves the skill over time.

510
00:24:03,440 --> 00:24:05,440
It executes the task and produces an output.

511
00:24:05,440 --> 00:24:09,480
If a human reviews it and rejects it because the tone doesn't match the brand, that feedback

512
00:24:09,480 --> 00:24:10,680
becomes data.

513
00:24:10,680 --> 00:24:15,320
The agent compares the output to the guidelines, identifies the gap and updates the skill.

514
00:24:15,320 --> 00:24:19,360
It refines the workflow and tightens the rules so it gets it right the next time.

515
00:24:19,360 --> 00:24:21,200
This requires one fundamental instruction.

516
00:24:21,200 --> 00:24:23,760
The agent's job is half execution and half improvement.

517
00:24:23,760 --> 00:24:27,760
It must execute the workflow, log the outcome, read the feedback and update the skill.

518
00:24:27,760 --> 00:24:31,760
That is the contract, a skill that never fails is a skill that is never pushed hard enough.

519
00:24:31,760 --> 00:24:34,920
But a skill that learns from every failure is production ready.

520
00:24:34,920 --> 00:24:36,960
That is how you reach true accuracy.

521
00:24:36,960 --> 00:24:40,480
The DBS framework, direction, blueprints, solutions.

522
00:24:40,480 --> 00:24:46,040
You have defined a skill, documented the workflow and set the rules, but now you face a common problem.

523
00:24:46,040 --> 00:24:49,000
Your skill is static while your organization is constantly moving.

524
00:24:49,000 --> 00:24:53,200
Brand guidelines evolve and regulatory language changes just as your tone of voice adapts

525
00:24:53,200 --> 00:24:54,400
when the market shifts.

526
00:24:54,400 --> 00:24:57,920
Approval thresholds update the moment new leadership arrives at the office.

527
00:24:57,920 --> 00:25:00,720
If all of that information lives inside your skill.

528
00:25:00,720 --> 00:25:04,920
MD file, you will find yourself rewriting the entire skill every single time a minor detail

529
00:25:04,920 --> 00:25:05,920
changes.

530
00:25:05,920 --> 00:25:08,640
You end up touching the core operational logic when you're only meant to update a simple

531
00:25:08,640 --> 00:25:12,560
reference document which creates friction where there should be total clarity.

532
00:25:12,560 --> 00:25:16,240
This is exactly why we use the DBS framework to solve the architecture problem.

533
00:25:16,240 --> 00:25:21,240
DBS stands for direction, blueprints and solutions and it is a three layer structure that separates

534
00:25:21,240 --> 00:25:23,360
what changes from what stays stable.

535
00:25:23,360 --> 00:25:27,080
This is how you build skills that can evolve without breaking the system.

536
00:25:27,080 --> 00:25:31,960
Direction is your skill.md which represents your operational intent, the workflow, the reasoning

537
00:25:31,960 --> 00:25:33,800
gates and the core logic.

538
00:25:33,800 --> 00:25:38,120
It tells the agent that when it receives work of a certain type, it must follow a specific

539
00:25:38,120 --> 00:25:40,760
sequence to produce the desired outcome.

540
00:25:40,760 --> 00:25:44,680
Direction is where your decision logic lives and it is also where the skill is most sensitive

541
00:25:44,680 --> 00:25:45,680
to errors.

542
00:25:45,680 --> 00:25:49,760
If you get this part wrong, the entire workflow breaks but the key is that direction should

543
00:25:49,760 --> 00:25:51,320
not change very often.

544
00:25:51,320 --> 00:25:55,480
A quoting workflow today will likely be the same quoting workflow next year because the

545
00:25:55,480 --> 00:25:57,200
fundamental steps do not shift.

546
00:25:57,200 --> 00:26:00,960
You aren't reordering the sequence just because a manager had a new idea because direction

547
00:26:00,960 --> 00:26:01,960
is structural.

548
00:26:01,960 --> 00:26:04,360
It only changes when the business process itself changes.

549
00:26:04,360 --> 00:26:06,400
Not when the brand guidelines get a refresh.

550
00:26:06,400 --> 00:26:09,840
Blueprints are everything else in your system and they live in your references folder.

551
00:26:09,840 --> 00:26:13,960
They include your brand standards, voice guidelines, policy language, tone checklists,

552
00:26:13,960 --> 00:26:17,840
regulatory templates, customer segmentation rules and approval matrices.

553
00:26:17,840 --> 00:26:21,960
These are context documents that inform how the agent executes the workflow without defining

554
00:26:21,960 --> 00:26:23,320
the workflow itself.

555
00:26:23,320 --> 00:26:27,280
The agent reads a blueprint and adapts its behavior accordingly which means the direction

556
00:26:27,280 --> 00:26:30,400
layer doesn't even need to know which specific blueprints exist.

557
00:26:30,400 --> 00:26:33,840
The direction simply says to apply the brand guidelines while the blueprints live and

558
00:26:33,840 --> 00:26:34,880
version separately.

559
00:26:34,880 --> 00:26:38,800
You can update them as frequently as you want without ever touching the underlying workflow

560
00:26:38,800 --> 00:26:39,800
logic.

561
00:26:39,800 --> 00:26:43,360
This matters because blueprints exist in the real world where things move fast.

562
00:26:43,360 --> 00:26:47,720
When your compliance team says they need new GDPR language, they simply update the blueprint

563
00:26:47,720 --> 00:26:48,720
and the job is done.

564
00:26:48,720 --> 00:26:52,400
The direction that references that file never has to change and the agent just reads the

565
00:26:52,400 --> 00:26:54,320
new version the next time it runs.

566
00:26:54,320 --> 00:26:58,040
If your brand team decides the company voice should be more direct and less flowery, they

567
00:26:58,040 --> 00:26:59,680
refresh the brand voice guide.

568
00:26:59,680 --> 00:27:04,080
The blueprint gets updated while the direction stays unchanged, allowing the agent to incorporate

569
00:27:04,080 --> 00:27:08,320
new guidance without the engineering team ever touching the operational logic.

570
00:27:08,320 --> 00:27:12,600
Solutions are your scripts and your code, including Python, JavaScript and HTTP requests

571
00:27:12,600 --> 00:27:14,120
to external APIs.

572
00:27:14,120 --> 00:27:18,560
These are complex calculations that live outside the agent's native language and handle everything

573
00:27:18,560 --> 00:27:20,600
the agent cannot do through pure reasoning.

574
00:27:20,600 --> 00:27:24,800
They stay in the solutions folder because they are implementation details that only change

575
00:27:24,800 --> 00:27:26,560
when the underlying systems change.

576
00:27:26,560 --> 00:27:30,960
When your pricing engine API gets a new endpoint, you update the solution script but the direction

577
00:27:30,960 --> 00:27:32,400
and blueprints don't care.

578
00:27:32,400 --> 00:27:37,320
They only need to know that a solution exists to look up the pricing data when it is needed.

579
00:27:37,320 --> 00:27:41,680
This three layer structure creates a clean separation of concerns across the company.

580
00:27:41,680 --> 00:27:45,880
The team's own the blueprints so they can update the voice, refine policy language or adjust

581
00:27:45,880 --> 00:27:47,920
approval thresholds on the fly.

582
00:27:47,920 --> 00:27:52,040
Engineers own the solutions, maintaining the integrations, updating API calls and improving

583
00:27:52,040 --> 00:27:53,240
overall performance.

584
00:27:53,240 --> 00:27:57,680
The coordination layer, which is the direction, rarely changes because it only moves when the

585
00:27:57,680 --> 00:27:59,360
process itself moves.

586
00:27:59,360 --> 00:28:02,920
The result of this setup is a remarkable side effect called reusability.

587
00:28:02,920 --> 00:28:06,560
Imagine you write a sales email skill with direction that defines a workflow for customer

588
00:28:06,560 --> 00:28:07,560
outreach.

589
00:28:07,560 --> 00:28:11,360
It references blueprints for brand voice and regulatory language while calling solutions

590
00:28:11,360 --> 00:28:13,360
for signature blocks and compliance photos.

591
00:28:13,360 --> 00:28:16,880
Now you need a support email skill which has a different purpose but uses the same brand

592
00:28:16,880 --> 00:28:18,520
voice and regulatory requirements.

593
00:28:18,520 --> 00:28:22,440
You can reuse those blueprints easily by writing new direction for the different workflow

594
00:28:22,440 --> 00:28:24,440
and pointing it at the same files.

595
00:28:24,440 --> 00:28:28,920
Both skills inherit the company's voice without any duplication so when the brand team updates

596
00:28:28,920 --> 00:28:32,400
the guidance once, both skills reflected immediately.

597
00:28:32,400 --> 00:28:35,800
That is the standard for orchestration as we move toward 2026.

598
00:28:35,800 --> 00:28:39,120
You don't want one monolithic document trying to cover every single detail but rather

599
00:28:39,120 --> 00:28:40,280
three clean layers.

600
00:28:40,280 --> 00:28:44,360
You use direction for logic, blueprints for guidance and solutions for integration.

601
00:28:44,360 --> 00:28:46,480
The practical benefit here is velocity.

602
00:28:46,480 --> 00:28:50,480
When 90% of what changes is found in the blueprints and those blueprints don't require a full

603
00:28:50,480 --> 00:28:54,480
engineering review, non-technical teams can finally own their domain.

604
00:28:54,480 --> 00:28:57,800
They refresh the guidance and update the policy language whenever they need to.

605
00:28:57,800 --> 00:29:00,720
The direction stays locked, stable and production grade.

606
00:29:00,720 --> 00:29:05,320
That separation between what your organization thinks and what it actually does is where orchestration

607
00:29:05,320 --> 00:29:06,720
at scale becomes possible.

608
00:29:06,720 --> 00:29:11,840
This is how you move away from experimental agents and start building real operational infrastructure.

609
00:29:11,840 --> 00:29:13,280
Specialist delegation pattern.

610
00:29:13,280 --> 00:29:17,080
You have your direction, your blueprints and your solutions ready to go.

611
00:29:17,080 --> 00:29:20,520
You have structured the skill but now you have to decide who is actually going to execute

612
00:29:20,520 --> 00:29:21,520
the work.

613
00:29:21,520 --> 00:29:23,240
This is where architects have to make a critical choice.

614
00:29:23,240 --> 00:29:26,960
You could build one giant agent that knows everything about your entire organization or

615
00:29:26,960 --> 00:29:28,840
you could build a council of experts.

616
00:29:28,840 --> 00:29:33,080
This council consists of agents focused on narrow domains with a parent agent that coordinates

617
00:29:33,080 --> 00:29:34,080
everything.

618
00:29:34,080 --> 00:29:38,160
Generalist bot is a tempting idea because it offers one interface, one set of instructions

619
00:29:38,160 --> 00:29:39,840
and one place to apply guardrails.

620
00:29:39,840 --> 00:29:43,840
It feels clean and simple at first but in reality it is neither of those things.

621
00:29:43,840 --> 00:29:49,040
A generalist bot trying to handle HR policies, sales strategy and financial forecasting all

622
00:29:49,040 --> 00:29:51,320
at once becomes a reasoning nightmare.

623
00:29:51,320 --> 00:29:56,000
The context window fills up with unrelated knowledge and the agent waste cycles trying

624
00:29:56,000 --> 00:29:58,240
to decide which domain to engage.

625
00:29:58,240 --> 00:30:02,160
It eventually makes mistakes at the boundaries between domains because it isn't a true expert

626
00:30:02,160 --> 00:30:03,160
in any of them.

627
00:30:03,160 --> 00:30:07,040
But with an agent that is competent at nothing, the council of experts works in a completely

628
00:30:07,040 --> 00:30:08,040
different way.

629
00:30:08,040 --> 00:30:12,000
You have an HR agent trained specifically on labor law and benefits and a sales agent that

630
00:30:12,000 --> 00:30:14,640
understands pipeline dynamics and deal mechanics.

631
00:30:14,640 --> 00:30:19,000
You add a finance agent that knows cost structures and approval authorities along with an IT

632
00:30:19,000 --> 00:30:21,520
agent for infrastructure and system architecture.

633
00:30:21,520 --> 00:30:24,080
None of these agents overlap or second guess each other.

634
00:30:24,080 --> 00:30:27,480
So when work arrives in a specific domain, the right expert owns it.

635
00:30:27,480 --> 00:30:30,880
However, this setup creates an orchestration problem that you have to solve.

636
00:30:30,880 --> 00:30:35,560
The user never talks to the HR agent or calls the sales agent directly but instead communicates

637
00:30:35,560 --> 00:30:38,120
with one interface called the parent agent.

638
00:30:38,120 --> 00:30:42,600
The parent is responsible for understanding what the user needs, rooting the request correctly

639
00:30:42,600 --> 00:30:44,200
and assembling the final answer.

640
00:30:44,200 --> 00:30:47,720
The parent is the sole responder to the user and this rule is non-negotiable.

641
00:30:47,720 --> 00:30:52,600
If the HR agent starts answering the user directly, while the sales agent is also responding,

642
00:30:52,600 --> 00:30:55,520
you will have total confusion and conflicting guidance.

643
00:30:55,520 --> 00:31:00,560
The parent must own the conversation so that everything else remains invisible to the user.

644
00:31:00,560 --> 00:31:03,920
This pattern requires a lot of discipline when it comes to scoping your agents.

645
00:31:03,920 --> 00:31:08,280
The HR agent should not handle payroll because that is an accounting detail and the sales agent

646
00:31:08,280 --> 00:31:11,680
should not calculate commissions because that belongs to finance.

647
00:31:11,680 --> 00:31:15,600
Each agent must have a clear perimeter so that when work touches multiple domains, the

648
00:31:15,600 --> 00:31:17,600
parent can coordinate effectively.

649
00:31:17,600 --> 00:31:21,560
It doesn't just merge the answers together but assembles them into a logical response.

650
00:31:21,560 --> 00:31:26,240
It tells the user what HR says about benefits and what finance says about the cost, providing

651
00:31:26,240 --> 00:31:28,400
one integrated recommendation.

652
00:31:28,400 --> 00:31:32,960
Proper scoping prevents domain creep and keeps agents from accumulating too many responsibilities.

653
00:31:32,960 --> 00:31:37,440
It forces you to be explicit about ownership and that explicitness is what allows the system

654
00:31:37,440 --> 00:31:38,440
to scale.

655
00:31:38,440 --> 00:31:42,080
When new work arrives, the parent reads it and realizes it is an HR question so it roots

656
00:31:42,080 --> 00:31:46,160
the task to the HR agent immediately because the agent wasn't designed to answer anything

657
00:31:46,160 --> 00:31:49,120
else, it doesn't waste any context trying to figure it out.

658
00:31:49,120 --> 00:31:53,560
This leads to the hardest problem in multi-agent orchestration which is context overload.

659
00:31:53,560 --> 00:31:57,120
Every agent you load into memory costs tokens and every set of instructions or guardrails

660
00:31:57,120 --> 00:31:59,200
consumes valuable reasoning space.

661
00:31:59,200 --> 00:32:03,160
If you load five agents at once, you have burned a significant amount of context before

662
00:32:03,160 --> 00:32:04,760
the real work even begins.

663
00:32:04,760 --> 00:32:09,040
The parent agent actually gets dumber because it is trying to carry five entire expert systems

664
00:32:09,040 --> 00:32:10,720
in its head at the same time.

665
00:32:10,720 --> 00:32:12,880
The solution to this problem is lazy loading.

666
00:32:12,880 --> 00:32:16,400
You should not load specialists until the exact moment you actually need them.

667
00:32:16,400 --> 00:32:20,080
The parent agent stays lightweight because it only knows which specialists exist and which

668
00:32:20,080 --> 00:32:21,320
domains they handle.

669
00:32:21,320 --> 00:32:25,080
It does not hold their full instructions in memory until a request arrives and the parent

670
00:32:25,080 --> 00:32:27,160
identifies it as HR related.

671
00:32:27,160 --> 00:32:31,160
At that point, it instantiates only the HR agent and loads its specific direction, blueprints

672
00:32:31,160 --> 00:32:32,360
and solutions.

673
00:32:32,360 --> 00:32:36,600
Once it gets the answer, it unloads the specialist to keep the reasoning space clean.

674
00:32:36,600 --> 00:32:40,720
This allows multiple agents to participate in the orchestration without creating a context

675
00:32:40,720 --> 00:32:41,720
monster.

676
00:32:41,720 --> 00:32:46,040
This approach requires your agent registry and your agent cards to be easily scannable.

677
00:32:46,040 --> 00:32:49,640
The parent agent needs to read the metadata on those cards to make rooting decisions without

678
00:32:49,640 --> 00:32:51,000
loading the full instructions.

679
00:32:51,000 --> 00:32:55,000
This is why your card descriptions matter so much as they are the lightweight signals that

680
00:32:55,000 --> 00:32:57,040
tell the parent exactly who to call.

681
00:32:57,040 --> 00:33:00,960
But here is where most multi-agent systems fail and it usually happens during the handoff

682
00:33:00,960 --> 00:33:01,960
itself.

683
00:33:01,960 --> 00:33:05,560
The technical architecture might be perfect and the rooting logic might work, but something

684
00:33:05,560 --> 00:33:07,840
breaks in the transition between agents.

685
00:33:07,840 --> 00:33:11,800
An agent might return data that the parent doesn't understand or the format isn't what

686
00:33:11,800 --> 00:33:12,800
was promised.

687
00:33:12,800 --> 00:33:16,760
The parent tries to use that data and that is when hallucinations take over.

688
00:33:16,760 --> 00:33:20,000
Sometimes the specialist agent makes an assumption about the parent's context that simply isn't

689
00:33:20,000 --> 00:33:22,440
true and they end up talking past each other.

690
00:33:22,440 --> 00:33:25,720
This is why testing the handoff is where you need real engineering discipline.

691
00:33:25,720 --> 00:33:31,240
You cannot just test each agent in isolation but you must test the handoff between them relentlessly.

692
00:33:31,240 --> 00:33:35,240
You have to ensure the parent correctly passes the specialist response and roots the work

693
00:33:35,240 --> 00:33:36,400
to the right place.

694
00:33:36,400 --> 00:33:40,600
It needs to handle error states and no one to escalate to a human if the specialist cannot

695
00:33:40,600 --> 00:33:41,600
proceed.

696
00:33:41,600 --> 00:33:45,080
Multi-agent systems don't usually break inside the agents themselves but in the empty spaces

697
00:33:45,080 --> 00:33:46,080
between them.

698
00:33:46,080 --> 00:33:49,240
Progressive disclosure, saving your context window.

699
00:33:49,240 --> 00:33:52,960
There is a technical reality about large language models that architects often ignore because

700
00:33:52,960 --> 00:33:54,240
it's uncomfortable.

701
00:33:54,240 --> 00:33:57,120
As the context window fills up, the model actually gets dumber.

702
00:33:57,120 --> 00:33:58,520
It doesn't just get slower.

703
00:33:58,520 --> 00:34:00,840
The quality of its reasoning starts to fall apart.

704
00:34:00,840 --> 00:34:04,800
Hallucination rates go up and the ability to stay coherent across a complex decision just

705
00:34:04,800 --> 00:34:05,800
degrades.

706
00:34:05,800 --> 00:34:09,480
This isn't a bug we're waiting for a patch to fix but rather a fundamental property of

707
00:34:09,480 --> 00:34:10,800
how transformers work.

708
00:34:10,800 --> 00:34:14,520
Every token you add to that window leaves less cognitive space for new reasoning which means

709
00:34:14,520 --> 00:34:17,680
the model becomes a better retriever but a much worse thinker.

710
00:34:17,680 --> 00:34:20,480
Most organizations try to solve this by loading everything up front.

711
00:34:20,480 --> 00:34:24,240
They cram five different agent instructions into memory along with seven approved skills

712
00:34:24,240 --> 00:34:25,800
and three domain guides.

713
00:34:25,800 --> 00:34:29,400
Then they add ten guardrails and a hundred examples just to be safe.

714
00:34:29,400 --> 00:34:32,880
By the time the user even asks a single question, the reasoning space is already full.

715
00:34:32,880 --> 00:34:37,200
The agent starts the conversation at a massive handicap because it's carrying too much weight.

716
00:34:37,200 --> 00:34:40,000
Progressive disclosure fixes this by changing the starting point.

717
00:34:40,000 --> 00:34:42,640
Instead of loading everything at once you load nothing.

718
00:34:42,640 --> 00:34:45,840
You start with descriptions, metadata and lightweight signals.

719
00:34:45,840 --> 00:34:50,040
The agent scans those signals to figure out what's actually relevant to the user's request

720
00:34:50,040 --> 00:34:52,600
and only then does it pull in the full context.

721
00:34:52,600 --> 00:34:56,240
Skills stay light by using front matter until they are actually triggered.

722
00:34:56,240 --> 00:34:59,760
Front matter is a simple convention from the world of documentation where a small section

723
00:34:59,760 --> 00:35:02,240
of metadata sits at the top of a file.

724
00:35:02,240 --> 00:35:04,880
It summarizes the document so you don't have to read the whole thing to know what it's

725
00:35:04,880 --> 00:35:05,880
about.

726
00:35:05,880 --> 00:35:09,800
For a skill, this front matter contains the agent's name, its domain, the types of requests

727
00:35:09,800 --> 00:35:11,480
it handles and its output format.

728
00:35:11,480 --> 00:35:13,280
That's usually about sixty tokens.

729
00:35:13,280 --> 00:35:17,600
While the full skill file might be three thousand tokens of detailed workflows and guardrails,

730
00:35:17,600 --> 00:35:20,080
the front matter remains stripped down and fast.

731
00:35:20,080 --> 00:35:24,040
To see how this works in practice, imagine a parent agent receiving a user request.

732
00:35:24,040 --> 00:35:26,200
It doesn't immediately spin up five specialists.

733
00:35:26,200 --> 00:35:29,880
Instead, it reads the front matter for each one to see who is qualified.

734
00:35:29,880 --> 00:35:34,680
The registry shows a sale specialist for deal mechanics, a finance specialist for approvals,

735
00:35:34,680 --> 00:35:36,840
and an HR specialist for policy.

736
00:35:36,840 --> 00:35:41,000
When a user asks why a customer wants a discount and how it impacts the business, the parent

737
00:35:41,000 --> 00:35:43,680
agent sees that this touches both sales and finance.

738
00:35:43,680 --> 00:35:47,720
It instantiates exactly those two specialists, leaving the other three dormant and out of

739
00:35:47,720 --> 00:35:48,720
the context window.

740
00:35:48,720 --> 00:35:50,120
The token math here is brutal.

741
00:35:50,120 --> 00:35:54,360
In the old model, you might load seven agents at start-up, which burns twenty one thousand

742
00:35:54,360 --> 00:35:56,760
tokens before the reasoning even begins.

743
00:35:56,760 --> 00:36:00,400
That leaves the model with only seventy nine percent of its capacity for the actual work.

744
00:36:00,400 --> 00:36:04,200
It is essentially working at a deficit just to carry its own overhead.

745
00:36:04,200 --> 00:36:07,640
In the new model, you only load the front matter for those seven agents, which costs about

746
00:36:07,640 --> 00:36:12,640
four hundred twenty tokens. This leaves over ninety nine thousand tokens wide open for reasoning.

747
00:36:12,640 --> 00:36:16,160
When the work arrives and you pull in two full specialists, you've only used about six

748
00:36:16,160 --> 00:36:17,480
thousand tokens total.

749
00:36:17,480 --> 00:36:20,320
You still have more than double the reasoning capacity compared to the old way of doing

750
00:36:20,320 --> 00:36:21,320
things.

751
00:36:21,320 --> 00:36:22,640
This process is called skill matching.

752
00:36:22,640 --> 00:36:25,720
The orchestrator doesn't have to guess which specialist to use because it simply reads

753
00:36:25,720 --> 00:36:26,920
the metadata.

754
00:36:26,920 --> 00:36:30,680
If a request comes in about returns, the metadata points to the customer service specialist

755
00:36:30,680 --> 00:36:32,120
and the system loads it.

756
00:36:32,120 --> 00:36:36,160
If the request involves accounts payable, the finance specialist gets the call.

757
00:36:36,160 --> 00:36:39,880
These descriptions in your front matter act as a rooting index that lets the parent agent

758
00:36:39,880 --> 00:36:42,920
make smart decisions without burning through its memory.

759
00:36:42,920 --> 00:36:45,720
These descriptions have to be incredibly precise to work.

760
00:36:45,720 --> 00:36:50,360
If you just write that an agent handles customer issues, the description is too broad for

761
00:36:50,360 --> 00:36:51,840
the orchestrator to be useful.

762
00:36:51,840 --> 00:36:54,840
It won't know the difference between a refund and a general complaint.

763
00:36:54,840 --> 00:36:59,360
If you write that it processes refund requests and manages dispute escalation, the orchestrator

764
00:36:59,360 --> 00:37:01,160
knows exactly when to call.

765
00:37:01,160 --> 00:37:05,040
Ambiguous descriptions lead to false routing, which causes work to bounce between agents

766
00:37:05,040 --> 00:37:07,920
until the context fills up with failed attempts.

767
00:37:07,920 --> 00:37:11,120
Minimal context leads directly to maximum reasoning quality.

768
00:37:11,120 --> 00:37:14,320
This isn't just a metaphor, it is something you can actually measure.

769
00:37:14,320 --> 00:37:19,000
A model with plenty of breathing room produces fewer hallucinations and much better logic.

770
00:37:19,000 --> 00:37:23,840
A model running at 90% capacity is noticeably worse than one running at 50%.

771
00:37:23,840 --> 00:37:27,320
Progressive disclosure keeps you in that sweet spot by loading only what is necessary and

772
00:37:27,320 --> 00:37:29,400
unloading it the moment the work is done.

773
00:37:29,400 --> 00:37:32,720
This is the real architectural reason why skills matter.

774
00:37:32,720 --> 00:37:35,800
They aren't just about automation, they are about context efficiency.

775
00:37:35,800 --> 00:37:39,880
They represent the difference between an agent that thinks clearly and one that is struggling

776
00:37:39,880 --> 00:37:41,040
under its own weight.

777
00:37:41,040 --> 00:37:44,480
This is how you keep intelligence sharp even when you're building at an organizational

778
00:37:44,480 --> 00:37:45,480
scale.

779
00:37:45,480 --> 00:37:47,880
Building the today's skill, a practical guide.

780
00:37:47,880 --> 00:37:51,080
Let's look at what this actually looks like when you sit down to build it.

781
00:37:51,080 --> 00:37:55,200
You are going to create a skill called today that generates your morning rundown.

782
00:37:55,200 --> 00:37:59,280
This isn't a generic briefing or a summary of what someone else thinks you should see.

783
00:37:59,280 --> 00:38:03,000
It is your personal rundown based on how you actually work and what needs your attention

784
00:38:03,000 --> 00:38:04,000
right now.

785
00:38:04,000 --> 00:38:07,880
You start with the workflow by looking at what you do when you first sit down in the morning.

786
00:38:07,880 --> 00:38:12,760
You probably check your calendar, skim your email for urgent replies and note any deadlines.

787
00:38:12,760 --> 00:38:18,040
You are building a mental model of your day and that specific sequence becomes your direction.

788
00:38:18,040 --> 00:38:22,240
In your skill file, step one is retrieving today's calendar events using the native M365

789
00:38:22,240 --> 00:38:23,240
connector.

790
00:38:23,240 --> 00:38:27,240
You filter for events before 5pm and sort them chronologically while extracting the attendees

791
00:38:27,240 --> 00:38:28,520
and descriptions.

792
00:38:28,520 --> 00:38:32,400
Step two involves pulling email from the last 12 hours and filtering out the noise like automated

793
00:38:32,400 --> 00:38:34,240
notifications or promotions.

794
00:38:34,240 --> 00:38:38,240
Step three, synthesizes a brief that shows your meetings in order and flags only the emails

795
00:38:38,240 --> 00:38:39,880
that actually require action.

796
00:38:39,880 --> 00:38:44,880
Finally, step four formats everything into a scannable summary that fits your preferred structure.

797
00:38:44,880 --> 00:38:45,880
That is your direction.

798
00:38:45,880 --> 00:38:46,880
It is specific.

799
00:38:46,880 --> 00:38:50,360
It doesn't guess what you need and it follows a very defined sequence.

800
00:38:50,360 --> 00:38:54,560
It uses native connectors that are already secured by your IT policy rather than relying

801
00:38:54,560 --> 00:38:57,440
on custom APIs or messy workarounds.

802
00:38:57,440 --> 00:38:58,600
You look at the blueprints.

803
00:38:58,600 --> 00:39:02,760
This is where you store the context the agent needs to understand your personal preferences.

804
00:39:02,760 --> 00:39:06,200
Maybe you organize your week with themed days where Mondays are for planning and Wednesdays

805
00:39:06,200 --> 00:39:07,280
are for execution.

806
00:39:07,280 --> 00:39:12,000
You have specific people who are always a priority and a standard way you like to see information.

807
00:39:12,000 --> 00:39:15,280
All of that lives in a separate reference folder so it doesn't have to be rewritten every

808
00:39:15,280 --> 00:39:16,920
time you update a preference.

809
00:39:16,920 --> 00:39:21,040
You can create a file for your planning logic that tells the agent to focus on strategy

810
00:39:21,040 --> 00:39:23,920
on Mondays and delivery status on Wednesdays.

811
00:39:23,920 --> 00:39:27,560
You can also create a list of VIP senders like your boss or your team lead so their emails

812
00:39:27,560 --> 00:39:28,560
always get flagged.

813
00:39:28,560 --> 00:39:32,600
You might even add a JSON file with noise filters to automatically strip out anything with

814
00:39:32,600 --> 00:39:35,240
an unsubscribe, footer or system notifications.

815
00:39:35,240 --> 00:39:37,080
The solutions folder stays minimal here.

816
00:39:37,080 --> 00:39:41,160
You might just have one Python script that takes your filtered email list and turns it into

817
00:39:41,160 --> 00:39:43,400
a one cent in summary for each sender.

818
00:39:43,400 --> 00:39:46,240
You aren't asking the agent to guess what is important.

819
00:39:46,240 --> 00:39:50,960
You are giving it a specific tool that handles the summarization consistently every single time.

820
00:39:50,960 --> 00:39:55,560
To execute this you go into co-pilot studio and drop in your skill file, your blueprints

821
00:39:55,560 --> 00:39:56,760
and your script.

822
00:39:56,760 --> 00:40:00,680
You connect the Gmail and calendar tools that your IT department has already approved and

823
00:40:00,680 --> 00:40:02,000
then you run a manual test.

824
00:40:02,000 --> 00:40:04,600
You just type us today and let it work.

825
00:40:04,600 --> 00:40:08,920
The agent follows your workflow by retrieving your calendar and reading your noise filters.

826
00:40:08,920 --> 00:40:12,840
It applies your planning logic and generates a summary that is specific to how you think.

827
00:40:12,840 --> 00:40:15,960
Three minutes later you have a rundown that actually matters to you.

828
00:40:15,960 --> 00:40:18,840
The real magic happens after you use this for a couple of weeks.

829
00:40:18,840 --> 00:40:22,480
The agent logs every execution which allows you to provide direct feedback.

830
00:40:22,480 --> 00:40:25,720
If the brief misses a meeting that was moved to 2pm you tell the agent.

831
00:40:25,720 --> 00:40:29,960
It reads that feedback, compares it to the calendar and updates its own rules to catch those

832
00:40:29,960 --> 00:40:31,680
time changes in the future.

833
00:40:31,680 --> 00:40:36,160
If you decide you want more aggressive email filtering you just say so and the agent updates

834
00:40:36,160 --> 00:40:37,600
the noise filters for you.

835
00:40:37,600 --> 00:40:39,920
Every one of these refinements makes the system better.

836
00:40:39,920 --> 00:40:43,320
You don't need an engineering team or a code editor because you just use the tool and

837
00:40:43,320 --> 00:40:44,400
tell it what's wrong.

838
00:40:44,400 --> 00:40:48,080
This is recursive building an action where your skill gets smarter as your own preferences

839
00:40:48,080 --> 00:40:49,080
become clearer.

840
00:40:49,080 --> 00:40:52,800
This is just a single skill that is narrow, useful and focused on one outcome.

841
00:40:52,800 --> 00:40:57,080
However, it is built on the exact same architecture that scales to complex systems across an entire

842
00:40:57,080 --> 00:40:58,080
company.

843
00:40:58,080 --> 00:41:01,560
It uses the same structure, the same connector discipline and the same self-healing logic.

844
00:41:01,560 --> 00:41:07,400
You are moving from a single personal agent to an organizational fabric using the same foundation.

845
00:41:07,400 --> 00:41:09,680
Recurse of building the feedback loop.

846
00:41:09,680 --> 00:41:13,760
Most organizations fail at agent architecture because they try to build the perfect skill

847
00:41:13,760 --> 00:41:15,360
before anyone ever uses it.

848
00:41:15,360 --> 00:41:19,480
They spend weeks in design meetings, they write massive comprehensive instructions.

849
00:41:19,480 --> 00:41:23,360
They try to anticipate every single edge case and document every possible outcome.

850
00:41:23,360 --> 00:41:27,360
Then they finally release it to production and it breaks immediately in ways they never

851
00:41:27,360 --> 00:41:28,360
saw coming.

852
00:41:28,360 --> 00:41:29,360
Stop doing that.

853
00:41:29,360 --> 00:41:32,840
The way you build reliable skills isn't by designing everything perfectly upfront but by

854
00:41:32,840 --> 00:41:36,560
deploying something incomplete and learning from the inevitable failures.

855
00:41:36,560 --> 00:41:37,560
This is recursive building.

856
00:41:37,560 --> 00:41:42,280
It is the only way you will ever reach the hit rates that actually matter for your business.

857
00:41:42,280 --> 00:41:44,800
The starting point for any skill should be a walkthrough.

858
00:41:44,800 --> 00:41:48,600
Instead of handwriting a skill from scratch, you teach the agent the workflow by actually

859
00:41:48,600 --> 00:41:50,320
executing the task together.

860
00:41:50,320 --> 00:41:53,240
You act as the first user while the agent serves as your assistant.

861
00:41:53,240 --> 00:41:56,920
As you work through a real task, you think out loud and explain your logic, showing the

862
00:41:56,920 --> 00:41:59,120
agent what matters and what can be ignored.

863
00:41:59,120 --> 00:42:03,320
The agent watches you, logs your sequence and notes which decisions you make and why.

864
00:42:03,320 --> 00:42:06,280
It captures the implicit rules you apply without even realizing it.

865
00:42:06,280 --> 00:42:09,920
Think about what this looks like when you're building a customer intake skill.

866
00:42:09,920 --> 00:42:13,180
You don't start by writing a long list of directions but instead you walk through a

867
00:42:13,180 --> 00:42:16,340
real inquiry with the agent shadowing your every move.

868
00:42:16,340 --> 00:42:20,680
You might say that a new customer inquiry just arrived and the first thing you do is check

869
00:42:20,680 --> 00:42:22,580
if they already have an account in the CRM.

870
00:42:22,580 --> 00:42:24,820
The agent watches and logs that specific step.

871
00:42:24,820 --> 00:42:27,900
When you see they aren't in the system, you look at the inquiry type to see if they want

872
00:42:27,900 --> 00:42:29,420
a product or a consultation.

873
00:42:29,420 --> 00:42:32,740
You read the email and tell the agent this is a product inquiry and the agent notes

874
00:42:32,740 --> 00:42:36,900
that specific decision because it's a product inquiry, you explain that you need to check

875
00:42:36,900 --> 00:42:38,700
inventory before committing to anything.

876
00:42:38,700 --> 00:42:42,380
You log in, check the stock and see that while there are two units, one is already promised

877
00:42:42,380 --> 00:42:43,540
to another order.

878
00:42:43,540 --> 00:42:47,420
You tell the agent that only one is actually available and note that in the intake.

879
00:42:47,420 --> 00:42:51,340
You create a record showing the available inventory while the agent captures the logic that

880
00:42:51,340 --> 00:42:52,620
lives in your head.

881
00:42:52,620 --> 00:42:56,540
Step by step and decision by decision, the agent isn't guessing because it's observing how

882
00:42:56,540 --> 00:42:58,580
you actually think through the problem.

883
00:42:58,580 --> 00:43:02,180
After this walkthrough, the agent synthesizes what it learned into a set of directions

884
00:43:02,180 --> 00:43:04,580
and proposes a workflow based on your actions.

885
00:43:04,580 --> 00:43:08,220
You review it and realize it missed the fact that you always check the customer's industry

886
00:43:08,220 --> 00:43:10,620
first because pricing varies by sector.

887
00:43:10,620 --> 00:43:14,780
The agent updates the workflow and you walk through another intake using that updated logic.

888
00:43:14,780 --> 00:43:18,340
It executes much more accurately this time because it watched you work twice.

889
00:43:18,340 --> 00:43:19,900
Then comes the moment most people fear.

890
00:43:19,900 --> 00:43:21,140
You release it to production.

891
00:43:21,140 --> 00:43:24,900
It isn't perfect and it's definitely incomplete compared to your original vision, but it

892
00:43:24,900 --> 00:43:27,900
is functional enough for real work to flow through it.

893
00:43:27,900 --> 00:43:28,900
And then it fails.

894
00:43:28,900 --> 00:43:30,820
It fails specifically and measurably.

895
00:43:30,820 --> 00:43:34,700
A customer intake comes through and the agent misidentifies the inquiry type or forgets

896
00:43:34,700 --> 00:43:36,260
to check the inventory.

897
00:43:36,260 --> 00:43:39,780
Maybe it applies the wrong pricing because it missed a rule about volume discounts, but

898
00:43:39,780 --> 00:43:41,700
the failure is concrete and visible.

899
00:43:41,700 --> 00:43:44,980
You shouldn't be embarrassed by this because this failure is actually data.

900
00:43:44,980 --> 00:43:48,300
This is the agent telling you exactly what it doesn't understand yet.

901
00:43:48,300 --> 00:43:51,900
You don't fix this by rewriting the directions from scratch or assuming the entire approach

902
00:43:51,900 --> 00:43:52,900
is broken.

903
00:43:52,900 --> 00:43:56,980
Instead, you isolate the failure and show the agent that it didn't catch a service request

904
00:43:56,980 --> 00:43:58,940
masquerading as a product question.

905
00:43:58,940 --> 00:44:02,580
You pass that failure case back to the agent and tell it what it should have detected

906
00:44:02,580 --> 00:44:04,180
so it can update the workflow.

907
00:44:04,180 --> 00:44:08,660
The agent reads the failure, updates its internal rules and refines the logic for identifying

908
00:44:08,660 --> 00:44:09,660
inquiry types.

909
00:44:09,660 --> 00:44:13,380
It adds a new example to its memory to distinguish between product and service inquiries

910
00:44:13,380 --> 00:44:14,540
in the future.

911
00:44:14,540 --> 00:44:17,740
When the next intake of that type comes through, the agent gets it right and you move on to

912
00:44:17,740 --> 00:44:18,740
the next challenge.

913
00:44:18,740 --> 00:44:22,940
If you repeat this over five or six iterative loops, those small failures accumulate into

914
00:44:22,940 --> 00:44:24,260
deep understanding.

915
00:44:24,260 --> 00:44:28,860
Each loop teaches the agent something new and each failure becomes a rule that prevents

916
00:44:28,860 --> 00:44:29,860
the next mistake.

917
00:44:29,860 --> 00:44:34,900
By the fifth loop, your hit rate is usually at 90% and by the sixth you're approaching 98%.

918
00:44:34,900 --> 00:44:39,580
You reached operational reliability, not through a perfect initial design, but through accumulated

919
00:44:39,580 --> 00:44:40,580
learning.

920
00:44:40,580 --> 00:44:41,820
This is why skills are self annealing.

921
00:44:41,820 --> 00:44:46,060
They heal because every single deployment teaches them something and every failure becomes

922
00:44:46,060 --> 00:44:47,220
a refinement.

923
00:44:47,220 --> 00:44:49,020
You aren't trying to predict what will break.

924
00:44:49,020 --> 00:44:51,420
You're letting the actual work show you.

925
00:44:51,420 --> 00:44:55,820
Human builders often hate this process because it feels like they're releasing unfinished work.

926
00:44:55,820 --> 00:45:00,220
In reality, you are, but unfinished work that learns is infinitely more valuable than finished

927
00:45:00,220 --> 00:45:01,740
work that can't adapt.

928
00:45:01,740 --> 00:45:06,540
This is how you move from theory to practice and from design to actual reliability.

929
00:45:06,540 --> 00:45:08,380
Governance, the architects guardrails.

930
00:45:08,380 --> 00:45:11,820
Once you've built a reliable skill and proven the concept, you're going to face a problem

931
00:45:11,820 --> 00:45:13,100
you didn't see coming.

932
00:45:13,100 --> 00:45:14,180
Proliferation.

933
00:45:14,180 --> 00:45:17,940
The moment you deploy one working agent, someone from another department is going to ask

934
00:45:17,940 --> 00:45:19,460
if you can build one for them.

935
00:45:19,460 --> 00:45:24,100
Then another person asks and then another until six months later you have 40 agents running

936
00:45:24,100 --> 00:45:25,900
across the entire organization.

937
00:45:25,900 --> 00:45:29,900
No one knows which agents exist, what access they have or who actually owns them.

938
00:45:29,900 --> 00:45:34,180
Some are calling live systems and making decisions about money, while others have access to sensitive

939
00:45:34,180 --> 00:45:36,940
data and suddenly you've created a governance nightmare.

940
00:45:36,940 --> 00:45:37,940
This is Shadow AI.

941
00:45:37,940 --> 00:45:41,540
It's the exact same thing that happened with unsanctioned spreadsheets and homegrown databases

942
00:45:41,540 --> 00:45:42,940
back in the 90s.

943
00:45:42,940 --> 00:45:46,260
Teams built what they needed because they couldn't wait for IT and now they're doing the

944
00:45:46,260 --> 00:45:47,620
same thing with agents.

945
00:45:47,620 --> 00:45:51,820
They're deploying agents in co-pilot studio without registering them or connecting to systems

946
00:45:51,820 --> 00:45:53,300
without a security review.

947
00:45:53,300 --> 00:45:58,180
They are exposing data because no one told them not to and this risk isn't just hypothetical.

948
00:45:58,180 --> 00:46:02,580
If an agent with overly broad access reads something it shouldn't and that data leaks your company

949
00:46:02,580 --> 00:46:05,260
faces massive compliance violations.

950
00:46:05,260 --> 00:46:07,700
Governance isn't just bureaucracy, it is architecture.

951
00:46:07,700 --> 00:46:11,180
It's the only thing standing between a controlled system and total chaos.

952
00:46:11,180 --> 00:46:14,780
It all starts with the principle of least privilege at the tool boundary.

953
00:46:14,780 --> 00:46:18,540
Every agent needs access to do its job, like a sales agent needing the CRM or a finance

954
00:46:18,540 --> 00:46:20,220
agent needing the general ledger.

955
00:46:20,220 --> 00:46:24,020
However, access to the CRM shouldn't mean the agent can read every single file in the

956
00:46:24,020 --> 00:46:25,020
system.

957
00:46:25,020 --> 00:46:28,740
In the meantime, the agent can read customer records for its specific organization and

958
00:46:28,740 --> 00:46:30,180
write to the opportunity table.

959
00:46:30,180 --> 00:46:34,180
It shouldn't touch employee records or financial data because least privilege means the

960
00:46:34,180 --> 00:46:36,500
agent has exactly what it needs and nothing more.

961
00:46:36,500 --> 00:46:38,900
This is where MCP becomes vital for governance.

962
00:46:38,900 --> 00:46:43,380
When an agent calls a tool through MCP, that tool is protected by authentication, rate

963
00:46:43,380 --> 00:46:44,900
limiting and scoping.

964
00:46:44,900 --> 00:46:49,660
The organization's control plane, IT and security defines exactly what each agent is allowed

965
00:46:49,660 --> 00:46:50,660
to do.

966
00:46:50,660 --> 00:46:53,220
The agent doesn't get broad access just because it asks.

967
00:46:53,220 --> 00:46:55,380
It gets constrained access by design.

968
00:46:55,380 --> 00:47:00,180
MCP servers expose tools with very specific parameters, allowing an agent to update a customer

969
00:47:00,180 --> 00:47:03,220
status but blocking it from reading financial history.

970
00:47:03,220 --> 00:47:07,020
It can create a new opportunity, but deleting one requires a human to step in.

971
00:47:07,020 --> 00:47:10,660
These guardrails are encoded at the tool level rather than in the agent's instructions.

972
00:47:10,660 --> 00:47:14,300
This means the agent can't override them with creative prompting because it hits a hard

973
00:47:14,300 --> 00:47:16,420
architectural boundary and stops.

974
00:47:16,420 --> 00:47:20,140
But we have to realize that some decisions can't be coded into a guardrail.

975
00:47:20,140 --> 00:47:24,300
They require human judgment and validation, which is why having a human in the loop is

976
00:47:24,300 --> 00:47:25,500
non-negotiable.

977
00:47:25,500 --> 00:47:29,500
When an agent recommends a large discount, it shouldn't be allowed to execute it alone.

978
00:47:29,500 --> 00:47:31,420
It needs to flag that for human approval.

979
00:47:31,420 --> 00:47:35,260
If an agent suggests terminating a service agreement or processes a refund above a certain

980
00:47:35,260 --> 00:47:37,860
amount, it should cue those actions for review.

981
00:47:37,860 --> 00:47:41,220
These are high impact actions with real business consequences, so the agent shouldn't

982
00:47:41,220 --> 00:47:42,380
own the execution.

983
00:47:42,380 --> 00:47:45,300
The agent owns the reasoning, but a human must own the final act.

984
00:47:45,300 --> 00:47:48,060
You need to write these explicit guardrails into the direction.

985
00:47:48,060 --> 00:47:53,180
You tell the agent that if a discount exceeds 10% or a refund is too high, it must escalate

986
00:47:53,180 --> 00:47:54,340
to a manager.

987
00:47:54,340 --> 00:47:55,940
These aren't optional suggestions.

988
00:47:55,940 --> 00:47:57,900
They are part of the core specification.

989
00:47:57,900 --> 00:48:02,420
However, escalation only works if you're actually tracking who is doing what and why.

990
00:48:02,420 --> 00:48:04,260
That is what we call auditability.

991
00:48:04,260 --> 00:48:08,580
In an A2A mesh, you need to know which agent made a recommendation and what data it used

992
00:48:08,580 --> 00:48:09,580
to get there.

993
00:48:09,580 --> 00:48:12,580
You aren't doing this for paperwork, but for learning and tracing failures.

994
00:48:12,580 --> 00:48:16,220
When something goes wrong, you need to be able to reconstruct the chain to see who asked

995
00:48:16,220 --> 00:48:18,700
whom to do what and what the context was at the time.

996
00:48:18,700 --> 00:48:21,540
This is the difference between control plane thinking and data plane thinking.

997
00:48:21,540 --> 00:48:25,300
The data plane is where the agents actually work, calling tools and generating outputs.

998
00:48:25,300 --> 00:48:27,700
The control plane is where you enforce the rules.

999
00:48:27,700 --> 00:48:31,540
You aren't trying to micromanage every single decision in the data plane, but you are setting

1000
00:48:31,540 --> 00:48:32,540
the boundaries.

1001
00:48:32,540 --> 00:48:36,140
The control plane is where you register agents, define their scope, and set those critical

1002
00:48:36,140 --> 00:48:37,140
approval thresholds.

1003
00:48:37,140 --> 00:48:41,460
For M365 admins, this means you have to treat agent governance just like application

1004
00:48:41,460 --> 00:48:42,460
governance.

1005
00:48:42,460 --> 00:48:46,540
You need to know which agents are deployed, who owns them, and what systems they touch.

1006
00:48:46,540 --> 00:48:50,100
You need to see the escalation rules and the audit trail because these aren't optional

1007
00:48:50,100 --> 00:48:51,100
questions.

1008
00:48:51,100 --> 00:48:54,740
These are infrastructure questions and without answers, you don't actually have governance.

1009
00:48:54,740 --> 00:48:55,860
You just have hope.

1010
00:48:55,860 --> 00:48:58,780
The most common governance failure is an agent that nobody owns.

1011
00:48:58,780 --> 00:49:02,780
It's running and making decisions, but when it eventually breaks, no one knows who to call

1012
00:49:02,780 --> 00:49:03,780
to fix it.

1013
00:49:03,780 --> 00:49:07,300
You have to assign ownership by giving each agent both a business owner and a technical

1014
00:49:07,300 --> 00:49:08,300
owner.

1015
00:49:08,300 --> 00:49:12,260
Make them accountable for the updates, the failures, and the security of that agent.

1016
00:49:12,260 --> 00:49:14,540
This isn't about restraint, it's about permission.

1017
00:49:14,540 --> 00:49:18,020
It's how you give agents the freedom to operate confidently because they are running within

1018
00:49:18,020 --> 00:49:19,820
boundaries you control.

1019
00:49:19,820 --> 00:49:22,780
Graph connector, schemas, semantic contracts.

1020
00:49:22,780 --> 00:49:26,820
Your schema is not just a technical document, it is a contract between your data and the

1021
00:49:26,820 --> 00:49:29,020
reasoning system that needs to use it.

1022
00:49:29,020 --> 00:49:32,340
Most organizations treat schemas like a clerical mapping exercise.

1023
00:49:32,340 --> 00:49:35,860
They decide that a specific field in the CRM maps to a certain field in the connector

1024
00:49:35,860 --> 00:49:38,220
or they link a table to a content type.

1025
00:49:38,220 --> 00:49:40,820
While this work is necessary, it isn't strategic.

1026
00:49:40,820 --> 00:49:44,660
The schema ends up as a generic list of field names and data types that looks more like an

1027
00:49:44,660 --> 00:49:46,620
inventory list than a blueprint.

1028
00:49:46,620 --> 00:49:50,420
This approach fails when you design for agents because an agent doesn't read a schema the

1029
00:49:50,420 --> 00:49:51,700
way a database does.

1030
00:49:51,700 --> 00:49:55,300
A database only cares about data types and relationships to ensure it queries a string

1031
00:49:55,300 --> 00:49:56,540
or a number correctly.

1032
00:49:56,540 --> 00:49:57,980
An agent cares about meaning.

1033
00:49:57,980 --> 00:50:02,860
It needs to understand what a field represents, why it matters, and how that information relates

1034
00:50:02,860 --> 00:50:04,420
to a specific decision.

1035
00:50:04,420 --> 00:50:08,340
When you give an agent a field called last contact date, it needs to know more than just

1036
00:50:08,340 --> 00:50:09,340
the calendar day.

1037
00:50:09,340 --> 00:50:14,220
It needs to know if that date signals customer engagement, if it points to a churn risk, or

1038
00:50:14,220 --> 00:50:16,860
if it acts as a leading indicator for a renewal.

1039
00:50:16,860 --> 00:50:20,460
The semantic meaning of the field determines whether the agent uses it correctly, not the

1040
00:50:20,460 --> 00:50:21,460
data type.

1041
00:50:21,460 --> 00:50:25,660
Moving beyond simple field mapping to relevant signaling changes everything.

1042
00:50:25,660 --> 00:50:28,900
Relevant signaling is how you tell the agent which specific fields actually matter for

1043
00:50:28,900 --> 00:50:29,900
reasoning.

1044
00:50:29,900 --> 00:50:34,140
Instead of just listing 50 fields in a customer record, you are marking the ones that

1045
00:50:34,140 --> 00:50:35,300
carry a real signal.

1046
00:50:35,300 --> 00:50:39,740
30 of those fields might be administrative data like account numbers or internal codes,

1047
00:50:39,740 --> 00:50:44,220
while 20 of them track behavioral patterns like purchase history and support ticket volume.

1048
00:50:44,220 --> 00:50:47,700
If the agent doesn't know which fields to wait, it treats contact information with the

1049
00:50:47,700 --> 00:50:49,740
same importance as customer health.

1050
00:50:49,740 --> 00:50:53,540
It might build a recommendation based on a zip code instead of a declining engagement

1051
00:50:53,540 --> 00:50:54,540
score.

1052
00:50:54,540 --> 00:50:56,380
Signaling tells the system what to prioritize.

1053
00:50:56,380 --> 00:51:01,540
In your schema, this means you must add metadata that goes deeper than the field name.

1054
00:51:01,540 --> 00:51:03,740
Don't just label a column engagement score.

1055
00:51:03,740 --> 00:51:05,260
You should add details like.

1056
00:51:05,260 --> 00:51:11,700
Signal strength, high and relationship correlates with renewal.

1057
00:51:11,700 --> 00:51:15,220
For a support tickets field, you might add an interpretation note stating that high volume

1058
00:51:15,220 --> 00:51:17,460
over 90 days indicates a churn risk.

1059
00:51:17,460 --> 00:51:21,060
You are essentially building a reasoning map for the intelligence to follow rather than

1060
00:51:21,060 --> 00:51:23,380
just a storage map for data to sit in.

1061
00:51:23,380 --> 00:51:28,220
However, relevant signaling only works if the data in that schema is actually trustworthy.

1062
00:51:28,220 --> 00:51:32,220
This is why access control lists or ACLs are so critical to the process.

1063
00:51:32,220 --> 00:51:36,860
In the old world, we treated ACLs as a simple security layer, enforced at the database level

1064
00:51:36,860 --> 00:51:39,820
where a user either had permission or they didn't.

1065
00:51:39,820 --> 00:51:43,340
In the world of agents, these permissions become part of the semantic understanding.

1066
00:51:43,340 --> 00:51:47,260
If an agent tries to reason about a customer, but cannot see their purchase history due to

1067
00:51:47,260 --> 00:51:49,340
a restriction, it doesn't just stop working.

1068
00:51:49,340 --> 00:51:54,220
It often makes inferences based on incomplete information or starts to hallucinate details.

1069
00:51:54,220 --> 00:51:57,580
It reaches a bad conclusion because it has no idea what information is missing from its

1070
00:51:57,580 --> 00:51:58,580
view.

1071
00:51:58,580 --> 00:52:02,420
If you design your schema, you cannot treat security controls as an afterthought because they

1072
00:52:02,420 --> 00:52:04,060
are a core part of the contract.

1073
00:52:04,060 --> 00:52:08,300
Your schema must document what data exists and exactly which agents can see it under specific

1074
00:52:08,300 --> 00:52:09,300
conditions.

1075
00:52:09,300 --> 00:52:13,020
If an agent has permission to see general account info but not the financials, the schema

1076
00:52:13,020 --> 00:52:15,020
needs to signal that boundary clearly.

1077
00:52:15,020 --> 00:52:18,740
You might include a note that if the financial summary is not visible, the agent should not

1078
00:52:18,740 --> 00:52:21,060
attempt to infer financial capacity.

1079
00:52:21,060 --> 00:52:24,060
Telling the agent what it doesn't know is often more important than showing it what it

1080
00:52:24,060 --> 00:52:25,060
does.

1081
00:52:25,060 --> 00:52:28,700
It has a massive impact on how the system handles ranking and summarization.

1082
00:52:28,700 --> 00:52:32,820
When an agent summarizes a record, it prioritizes the fields you've marked as high signal.

1083
00:52:32,820 --> 00:52:36,500
When it ranks search results, it weights those fields based on their relevance to the task.

1084
00:52:36,500 --> 00:52:39,420
If your schema is vague, the agent is forced to guess.

1085
00:52:39,420 --> 00:52:43,060
It might summarize a complex customer history by focusing on the office address instead

1086
00:52:43,060 --> 00:52:44,300
of the health metrics.

1087
00:52:44,300 --> 00:52:48,260
Poor schemas lead to poor summaries and poor summaries lead to bad business decisions.

1088
00:52:48,260 --> 00:52:52,900
This is exactly why a full crawl is more valuable than simple incremental updates.

1089
00:52:52,900 --> 00:52:56,340
When you first ingest your data, you are establishing that semantic contract.

1090
00:52:56,340 --> 00:53:00,100
The schema you build on day one sets the expectations for what fields mean and how they relate

1091
00:53:00,100 --> 00:53:01,100
to one another.

1092
00:53:01,100 --> 00:53:05,180
If you change permissions later or shift the meaning of a field, an incremental update might

1093
00:53:05,180 --> 00:53:07,060
miss that shift in context.

1094
00:53:07,060 --> 00:53:10,260
The agent might continue using the old logic from the original schema.

1095
00:53:10,260 --> 00:53:15,340
A full crawl re-establishes the entire contract and tells the system what the data landscape

1096
00:53:15,340 --> 00:53:16,780
looks like right now.

1097
00:53:16,780 --> 00:53:21,300
It forces total clarity on permission boundaries and reasoning expectations.

1098
00:53:21,300 --> 00:53:24,900
Your schema is the primary way that data talks to intelligence.

1099
00:53:24,900 --> 00:53:28,380
If you get this right, your agents will reason with incredible clarity.

1100
00:53:28,380 --> 00:53:32,420
If you build it carelessly, those same agents will start to hallucinate.

1101
00:53:32,420 --> 00:53:36,860
This is where architects provide the most value by building contracts between data and reasoning

1102
00:53:36,860 --> 00:53:41,260
that actually hold up at scale than measuring ROI beyond minutes saved.

1103
00:53:41,260 --> 00:53:44,900
This is where most organizations get it wrong when they try to measure agent performance.

1104
00:53:44,900 --> 00:53:48,140
They deploy a new skill and immediately start tracking time.

1105
00:53:48,140 --> 00:53:52,340
If an agent cuts the time to create a quote from 60 minutes down to 3, they announce that

1106
00:53:52,340 --> 00:53:54,540
they've saved 57 minutes per quote.

1107
00:53:54,540 --> 00:53:59,500
They multiply that time by the number of quotes per year, calculate the labor value and

1108
00:53:59,500 --> 00:54:00,820
declare victory.

1109
00:54:00,820 --> 00:54:03,380
They think the ROI is proven and the budget is justified.

1110
00:54:03,380 --> 00:54:04,460
But that logic is flawed.

1111
00:54:04,460 --> 00:54:08,540
The time savings are real, but they are the smallest possible measure of what an agent actually

1112
00:54:08,540 --> 00:54:09,860
changes in a business.

1113
00:54:09,860 --> 00:54:13,860
The uncomfortable truth is that when you give a team 57 minutes back, they don't just

1114
00:54:13,860 --> 00:54:15,500
pack up and go home early.

1115
00:54:15,500 --> 00:54:18,260
They don't work fewer hours, but they do start working differently.

1116
00:54:18,260 --> 00:54:21,420
They shift that new capacity toward work that carries more value.

1117
00:54:21,420 --> 00:54:23,340
This is known as the productivity paradox.

1118
00:54:23,340 --> 00:54:27,860
Total hours worked usually stay the same and utilization looks unchanged on a spreadsheet,

1119
00:54:27,860 --> 00:54:29,940
but the actual output of the work is transformed.

1120
00:54:29,940 --> 00:54:34,620
A salesperson who used to spend an hour on a single quote now finishes it in 3 minutes.

1121
00:54:34,620 --> 00:54:36,860
They don't spend the rest of the hour taking a break.

1122
00:54:36,860 --> 00:54:40,780
Instead, they might handle 18 quotes in the time it used to take to do 3.

1123
00:54:40,780 --> 00:54:45,380
They might use that extra time to focus on account strategy or qualify leads more carefully

1124
00:54:45,380 --> 00:54:48,180
because the quoting process is no longer a bottle neck.

1125
00:54:48,180 --> 00:54:51,660
The input of time stays the same, but the output of the person changes completely.

1126
00:54:51,660 --> 00:54:56,180
This is why you should focus on measuring capacity gained instead of just minutes saved.

1127
00:54:56,180 --> 00:55:00,220
Capacity gained represents what your team can do now that was physically impossible before.

1128
00:55:00,220 --> 00:55:03,680
Before you had agents, you might have processed 20 customer intakes a day because each one

1129
00:55:03,680 --> 00:55:05,020
took 30 minutes.

1130
00:55:05,020 --> 00:55:10,220
After implementing agents, you can process 80 intakes a day because the task takes 7 minutes

1131
00:55:10,220 --> 00:55:13,700
and your staff is now managing the agent instead of doing the manual labor.

1132
00:55:13,700 --> 00:55:18,460
The salesperson who managed 5 customers can now handle 15 and the analyst who wrote 3 reports

1133
00:55:18,460 --> 00:55:20,440
a month can now produce 12.

1134
00:55:20,440 --> 00:55:21,880
This isn't a hypothetical benefit.

1135
00:55:21,880 --> 00:55:23,820
It is a structural change you can measure.

1136
00:55:23,820 --> 00:55:25,620
You should track this at 3 distinct levels.

1137
00:55:25,620 --> 00:55:27,620
The first level is task velocity.

1138
00:55:27,620 --> 00:55:31,060
This measures how fast a person can complete one single unit of work.

1139
00:55:31,060 --> 00:55:35,340
If a sales team drafts presentations, you can set a baseline of 45 minutes per deck.

1140
00:55:35,340 --> 00:55:39,460
If an agent brings that down to 32 minutes, you improve velocity by 29%.

1141
00:55:39,460 --> 00:55:41,740
However, velocity alone doesn't prove value.

1142
00:55:41,740 --> 00:55:46,940
A presentation that gets finished 10% faster means nothing if it doesn't help close a deal.

1143
00:55:46,940 --> 00:55:49,980
Velocity is just a diagnostic tool to show the agent is working, but it doesn't prove

1144
00:55:49,980 --> 00:55:51,420
the organization is winning.

1145
00:55:51,420 --> 00:55:53,740
The second level is workflow cycle time.

1146
00:55:53,740 --> 00:55:57,020
This tracks the time it takes to move work from the very beginning to the very end of a

1147
00:55:57,020 --> 00:55:58,020
process.

1148
00:55:58,020 --> 00:56:00,500
Instead of looking at one task, you look at the whole chain.

1149
00:56:00,500 --> 00:56:04,260
A quoting workflow might move from the initial inquiry to a signed contract.

1150
00:56:04,260 --> 00:56:09,900
If the baseline was 8 days and agent orchestration brings it down to 2 days, you've achieved a 75%

1151
00:56:09,900 --> 00:56:10,900
reduction.

1152
00:56:10,900 --> 00:56:12,620
Speed changes how people behave.

1153
00:56:12,620 --> 00:56:16,300
When a customer gets a quote back in 2 days instead of 8, they stop shopping around and

1154
00:56:16,300 --> 00:56:17,900
the deal closes faster.

1155
00:56:17,900 --> 00:56:21,900
That time reduction creates a pressure that changes decision making further down the line.

1156
00:56:21,900 --> 00:56:24,660
The third and most important level is business outcome.

1157
00:56:24,660 --> 00:56:27,860
This is the only metric that the finance department actually cares about.

1158
00:56:27,860 --> 00:56:31,500
It isn't about how fast things move, but what actually changes for the company.

1159
00:56:31,500 --> 00:56:35,700
A sales team that closes deals faster will eventually move more deals and close higher

1160
00:56:35,700 --> 00:56:38,980
value contracts because they have the bandwidth to qualify leads.

1161
00:56:38,980 --> 00:56:43,060
A support team that handles 30 escalations instead of 10 will reduce churn because they are

1162
00:56:43,060 --> 00:56:45,100
more responsive to customer needs.

1163
00:56:45,100 --> 00:56:49,580
When a marketing team publishes 12 reports instead of 3, they can run more experiments and

1164
00:56:49,580 --> 00:56:52,340
find new growth opportunities much faster.

1165
00:56:52,340 --> 00:56:56,300
This is where the statistic about having 66% more customer meetings comes from.

1166
00:56:56,300 --> 00:57:01,300
A sales organization with more capacity doesn't just work 66% harder than before.

1167
00:57:01,300 --> 00:57:02,460
It works differently.

1168
00:57:02,460 --> 00:57:05,140
They schedule more meetings because they finally have the time to do it.

1169
00:57:05,140 --> 00:57:09,780
They qualify prospects more aggressively because they aren't drowning in administrative paperwork.

1170
00:57:09,780 --> 00:57:12,860
They sell more because the structural constraints have been removed.

1171
00:57:12,860 --> 00:57:14,340
These three levels build on each other.

1172
00:57:14,340 --> 00:57:16,740
Task velocity proves the agent is functional.

1173
00:57:16,740 --> 00:57:19,540
Work flow cycle time proves the process has changed.

1174
00:57:19,540 --> 00:57:22,180
Business outcome proves the company is actually growing.

1175
00:57:22,180 --> 00:57:23,900
Most organizations stop at the first level.

1176
00:57:23,900 --> 00:57:26,460
They track the minutes and declare the project a success.

1177
00:57:26,460 --> 00:57:30,180
They completely miss the second and third levels, which is where the real transformation

1178
00:57:30,180 --> 00:57:31,180
lives.

1179
00:57:31,180 --> 00:57:34,180
A sales team that can handle double the pipeline because quoting is fast isn't just

1180
00:57:34,180 --> 00:57:35,180
saving time.

1181
00:57:35,180 --> 00:57:37,820
They are changing the entire revenue trajectory of the company.

1182
00:57:37,820 --> 00:57:39,700
That isn't a story about efficiency.

1183
00:57:39,700 --> 00:57:41,820
It is a story about business transformation.

1184
00:57:41,820 --> 00:57:45,420
When you sit down to build your measurement framework, you must anchor it to the business

1185
00:57:45,420 --> 00:57:46,420
outcome.

1186
00:57:46,420 --> 00:57:50,500
Ask yourself what specific outcome improves because the work is moving faster.

1187
00:57:50,500 --> 00:57:54,900
Then you can work backward to find the workflow changes and task improvements that made it

1188
00:57:54,900 --> 00:57:55,900
possible.

1189
00:57:55,900 --> 00:57:59,100
This is how you move the conversation from being more efficient to being more valuable.

1190
00:57:59,100 --> 00:58:01,380
The agent operated organization.

1191
00:58:01,380 --> 00:58:04,860
Starting from AI assisted to agent operated isn't just a tech upgrade.

1192
00:58:04,860 --> 00:58:07,340
It's a total shift in how your company actually functions.

1193
00:58:07,340 --> 00:58:12,060
You have to redesign how authority and accountability are handed out across the entire organization.

1194
00:58:12,060 --> 00:58:15,900
Most companies today are still stuck in the old assistance model where IT builds the tools

1195
00:58:15,900 --> 00:58:17,900
and the business units just use them.

1196
00:58:17,900 --> 00:58:22,060
In that world, IT owns the platform while the business units own the results, which is

1197
00:58:22,060 --> 00:58:24,900
fine when you're just dealing with spreadsheets or dashboards.

1198
00:58:24,900 --> 00:58:26,260
But that logic falls apart.

1199
00:58:26,260 --> 00:58:30,220
The second you have autonomous agents making real decisions on behalf of the company.

1200
00:58:30,220 --> 00:58:35,340
An agent operated organization flips that script by pushing authority out to the edges.

1201
00:58:35,340 --> 00:58:39,300
Every department becomes a builder and every function owns its own portfolio of agents.

1202
00:58:39,300 --> 00:58:42,740
Sales builds for sales, finance builds for finance and HR builds for HR.

1203
00:58:42,740 --> 00:58:46,340
Instead of waiting months for IT to build a generic tool that doesn't quite fit, these teams

1204
00:58:46,340 --> 00:58:49,060
design agents that encode exactly how they work.

1205
00:58:49,060 --> 00:58:51,860
They are turning their own expertise into digital logic.

1206
00:58:51,860 --> 00:58:52,860
But here's the problem.

1207
00:58:52,860 --> 00:58:56,300
Decentralization only works if you have a rock solid central governance framework.

1208
00:58:56,300 --> 00:59:00,420
You can't have 80 different agents running wild with nobody watching the big picture.

1209
00:59:00,420 --> 00:59:04,180
If the sales team builds an agent that exposes sensitive customer data that finance also needs

1210
00:59:04,180 --> 00:59:08,820
or if an HR agent makes a call that breaks compliance rules, the whole system collapses.

1211
00:59:08,820 --> 00:59:12,080
The moment you let everyone build, you have to tighten the leash on control.

1212
00:59:12,080 --> 00:59:14,460
This is where the central governance layer comes in.

1213
00:59:14,460 --> 00:59:19,220
Teams like IT security and compliance stop being the builders and start being the architects.

1214
00:59:19,220 --> 00:59:23,420
They set the boundaries, define which systems an agent can touch and enforce the rules for

1215
00:59:23,420 --> 00:59:25,260
when a human needs to step in.

1216
00:59:25,260 --> 00:59:28,740
They aren't building the agents themselves but they are building the safe playground where

1217
00:59:28,740 --> 00:59:30,020
those agents live.

1218
00:59:30,020 --> 00:59:34,140
The business units get total freedom, but only within those preset constraints.

1219
00:59:34,140 --> 00:59:36,380
This creates a very clean division of labor.

1220
00:59:36,380 --> 00:59:41,700
IT provides the plumbing, like the server connections for the CRM and tells the business exactly

1221
00:59:41,700 --> 00:59:43,540
what can be read or written.

1222
00:59:43,540 --> 00:59:45,500
Then they hand it over.

1223
00:59:45,500 --> 00:59:50,020
Finance might say they need an agent to approve any purchase order under $5,000 so they

1224
00:59:50,020 --> 00:59:51,860
build it, test it and own its performance.

1225
00:59:51,860 --> 00:59:55,380
The governance layer just makes sure that agents can't buy things from restricted categories

1226
00:59:55,380 --> 00:59:57,580
and logs every single move it makes.

1227
00:59:57,580 --> 01:00:00,780
The business unit decides the logic but the governance layer decides the limits.

1228
01:00:00,780 --> 01:00:03,020
That's why the agent champion role is so vital.

1229
01:00:03,020 --> 01:00:07,500
You need to pick one person in every department to own that team's agent portfolio.

1230
01:00:07,500 --> 01:00:11,900
They need to understand the business side and work directly with IT to design the right workflows.

1231
01:00:11,900 --> 01:00:16,180
Well this isn't a full-time job for most people yet, it is a massive responsibility.

1232
01:00:16,180 --> 01:00:19,780
Without a champion, these agents become orphans that nobody looks after and they eventually

1233
01:00:19,780 --> 01:00:21,260
just sit there and rot.

1234
01:00:21,260 --> 01:00:24,740
The champion also acts as the bridge between the business needs and the security rules.

1235
01:00:24,740 --> 01:00:28,540
If sales wants to show customer payment history through an agent, the champion is the one

1236
01:00:28,540 --> 01:00:30,220
who negotiates the details.

1237
01:00:30,220 --> 01:00:33,660
They might agree to show the payment date and status but keep credit card numbers completely

1238
01:00:33,660 --> 01:00:34,660
hidden.

1239
01:00:34,660 --> 01:00:38,500
They speak both languages, translating business goals into security requirements.

1240
01:00:38,500 --> 01:00:43,220
This helps you avoid the biggest bottleneck coming in 2026, the center of excellence.

1241
01:00:43,220 --> 01:00:47,900
A lot of companies set up a central COE to build every agent and manage every standard.

1242
01:00:47,900 --> 01:00:52,060
On paper it sounds smart but in reality it becomes a massive traffic jam.

1243
01:00:52,060 --> 01:00:55,980
Every department ends up waiting in a long line for the COE to build their specific tool

1244
01:00:55,980 --> 01:00:58,980
and when the COE can't keep up, the work just stops.

1245
01:00:58,980 --> 01:01:02,940
People go back to doing things manually and your AI advantage disappears because the bureaucracy

1246
01:01:02,940 --> 01:01:04,100
moved too slowly.

1247
01:01:04,100 --> 01:01:07,780
The fix is to turn the COE from a builder into a coach.

1248
01:01:07,780 --> 01:01:11,780
Instead of making the agents, the center of excellence builds the templates, the training

1249
01:01:11,780 --> 01:01:14,220
and the security frameworks that everyone else uses.

1250
01:01:14,220 --> 01:01:17,460
They do the code reviews and handle the weird security exceptions but they govern at

1251
01:01:17,460 --> 01:01:18,460
the platform level.

1252
01:01:18,460 --> 01:01:20,900
The business units are the ones actually doing the building.

1253
01:01:20,900 --> 01:01:24,660
This is the shift from reacting to problems to actually designing a system.

1254
01:01:24,660 --> 01:01:26,860
Right now most IT teams are just firefighters.

1255
01:01:26,860 --> 01:01:30,660
They wait for something to break or for a department to complain and then they rush to fix

1256
01:01:30,660 --> 01:01:31,660
it.

1257
01:01:31,660 --> 01:01:34,980
But when you move to an agent operated model, the firefighting stops.

1258
01:01:34,980 --> 01:01:38,500
You spend your time designing the landscape and setting the bumpers that keep everyone

1259
01:01:38,500 --> 01:01:39,500
safe.

1260
01:01:39,500 --> 01:01:41,820
You move from tactical fixes to strategic architecture.

1261
01:01:41,820 --> 01:01:45,500
The organization that figures this out first, the one that actually lets departments build

1262
01:01:45,500 --> 01:01:48,660
while keeping central control is going to win.

1263
01:01:48,660 --> 01:01:52,820
Everyone else is going to spend the next few years just trying to catch up.

1264
01:01:52,820 --> 01:01:54,980
Roadmap to 100X, the 3 step path.

1265
01:01:54,980 --> 01:01:58,900
The plan is clear and the logic is solid but you can't wait 6 months to start.

1266
01:01:58,900 --> 01:02:02,740
You need to move from understanding how this works to actually building it right now.

1267
01:02:02,740 --> 01:02:04,580
Step 1 is all about finding your bottlenecks.

1268
01:02:04,580 --> 01:02:07,620
You aren't trying to automate your entire company on day one.

1269
01:02:07,620 --> 01:02:11,500
Instead you need to find the specific high volume problems that are dragging everyone

1270
01:02:11,500 --> 01:02:12,500
down.

1271
01:02:12,500 --> 01:02:14,300
Don't look for the cool problems.

1272
01:02:14,300 --> 01:02:17,660
Don't look for the places where work piles up and decisions get stuck in a queue.

1273
01:02:17,660 --> 01:02:18,860
Every department has one of these.

1274
01:02:18,860 --> 01:02:22,820
In sales it might be that proposals take way too long to write, so deals just die while

1275
01:02:22,820 --> 01:02:24,020
waiting for a contract.

1276
01:02:24,020 --> 01:02:27,100
In finance it's usually manual expense reports that make everyone angry.

1277
01:02:27,100 --> 01:02:31,020
HR might be stuck manually sending the same 5 emails to every new hire.

1278
01:02:31,020 --> 01:02:35,220
These aren't fancy problems but they are boring, repetitive and they happen constantly.

1279
01:02:35,220 --> 01:02:36,940
Just pick one.

1280
01:02:36,940 --> 01:02:39,620
Where you start actually matters more than being perfect.

1281
01:02:39,620 --> 01:02:43,300
You should always aim for front end tasks that people actually see and feel.

1282
01:02:43,300 --> 01:02:46,820
If you build a sales agent that cuts down the time it takes to close a deal, the team will

1283
01:02:46,820 --> 01:02:48,420
tell you if it's working immediately.

1284
01:02:48,420 --> 01:02:54,020
If you start with a back end warehouse agent, you might not see the actual value for a month.

1285
01:02:54,020 --> 01:02:57,540
Front end work gives you that instant feedback you need to know if you're winning.

1286
01:02:57,540 --> 01:02:58,940
Step 2 is building a specialist.

1287
01:02:58,940 --> 01:03:01,300
You aren't trying to create a do-it-all AI.

1288
01:03:01,300 --> 01:03:04,300
You want one focused agent that owns that one specific bottleneck.

1289
01:03:04,300 --> 01:03:06,500
If you pick sales you build a proposal agent.

1290
01:03:06,500 --> 01:03:10,300
It should know your pricing, your legal terms and which clauses go to which customers.

1291
01:03:10,300 --> 01:03:11,500
That is its entire world.

1292
01:03:11,500 --> 01:03:14,620
You build this in co-pilot studio using the DBS framework.

1293
01:03:14,620 --> 01:03:18,340
You give it direction for the workflow, blueprints for the brand standards and solutions for

1294
01:03:18,340 --> 01:03:19,340
the pricing math.

1295
01:03:19,340 --> 01:03:23,460
You hook it up to your CRM but you set very strict boundaries on what it can actually touch.

1296
01:03:23,460 --> 01:03:27,580
You keep a human in the loop for any big discounts and you log every single recommendation

1297
01:03:27,580 --> 01:03:28,580
it makes.

1298
01:03:28,580 --> 01:03:29,580
Then you just run it.

1299
01:03:29,580 --> 01:03:31,940
You watch it work, find the mistakes and fix them.

1300
01:03:31,940 --> 01:03:35,340
After about 5 rounds of this, it should be hitting 95% accuracy.

1301
01:03:35,340 --> 01:03:36,820
Then you look at the hard numbers.

1302
01:03:36,820 --> 01:03:40,620
If you were doing 10 proposals a day before and now you're doing 40, that's a win.

1303
01:03:40,620 --> 01:03:45,460
If your cycle time dropped from 8 days down to 2, you now have the proof you need to justify

1304
01:03:45,460 --> 01:03:46,460
the next move.

1305
01:03:46,460 --> 01:03:48,220
Step 3 is about scaling that fabric.

1306
01:03:48,220 --> 01:03:51,620
Now that you've proven one specialist works, you start connecting it to others.

1307
01:03:51,620 --> 01:03:53,660
That proposal agent shouldn't live on an island.

1308
01:03:53,660 --> 01:03:57,300
When a sales rep starts a new contract, that agent should be able to call the finance agent

1309
01:03:57,300 --> 01:04:00,940
to check the pricing or the compliance agent to verify the legal language.

1310
01:04:00,940 --> 01:04:05,140
Each one handles its own tiny domain and a parent orchestrator keeps them all in sync.

1311
01:04:05,140 --> 01:04:06,980
But don't try to build everything at once.

1312
01:04:06,980 --> 01:04:07,980
You have to cascade.

1313
01:04:07,980 --> 01:04:10,580
Since the proposal agent is working, your next move is to find the best way to do it.

1314
01:04:10,580 --> 01:04:13,060
And the next bottleneck, like contract approvals.

1315
01:04:13,060 --> 01:04:16,580
You build an approval agent that knows who has the authority to sign off on what.

1316
01:04:16,580 --> 01:04:19,580
Now the proposal agent just hands the finished work to the approval agent.

1317
01:04:19,580 --> 01:04:21,380
You've officially connected to specialists.

1318
01:04:21,380 --> 01:04:24,900
Whatever you do, don't get distracted by shiny objects.

1319
01:04:24,900 --> 01:04:28,900
There's always someone who wants to automate a complex manufacturing schedule or some deep

1320
01:04:28,900 --> 01:04:31,060
financial model because it sounds impressive.

1321
01:04:31,060 --> 01:04:34,380
Those are fun projects, but they don't actually make the business move faster.

1322
01:04:34,380 --> 01:04:38,300
Front end specialists are the ones that move deals and change the employee experience.

1323
01:04:38,300 --> 01:04:39,900
Back end stuff is a nice to have.

1324
01:04:39,900 --> 01:04:42,420
But front end acceleration is what keeps you alive.

1325
01:04:42,420 --> 01:04:43,620
The path is simple.

1326
01:04:43,620 --> 01:04:47,220
Find the bottleneck, build the specialist, connect them, and then repeat.

1327
01:04:47,220 --> 01:04:48,860
Don't spend months planning.

1328
01:04:48,860 --> 01:04:51,540
Find the pain, build the fix, and deploy it fast.

1329
01:04:51,540 --> 01:04:54,260
By the third month, you'll have a few specialists working together.

1330
01:04:54,260 --> 01:04:58,420
By the end of the year, you'll be operating at a hundred times the speed of your old manual

1331
01:04:58,420 --> 01:04:59,420
processes.

1332
01:04:59,420 --> 01:05:01,740
That is how you move forward.

1333
01:05:01,740 --> 01:05:02,740
Troubleshooting the fabric.

1334
01:05:02,740 --> 01:05:06,580
You've built your agents, you've set up the orchestration, and you've configured every

1335
01:05:06,580 --> 01:05:07,580
connection.

1336
01:05:07,580 --> 01:05:10,380
The paper, the system should be working perfectly, but then it doesn't.

1337
01:05:10,380 --> 01:05:11,740
It's not a catastrophic crash.

1338
01:05:11,740 --> 01:05:12,740
It's a quiet failure.

1339
01:05:12,740 --> 01:05:16,260
A skill doesn't trigger when it should, or the parent agent roots a task to the wrong

1340
01:05:16,260 --> 01:05:17,260
specialist.

1341
01:05:17,260 --> 01:05:19,780
Maybe the handoff between agents fails silently.

1342
01:05:19,780 --> 01:05:22,900
The system keeps running, but it stops doing what you actually designed it to do.

1343
01:05:22,900 --> 01:05:25,740
This is the exact point where most organizations give up.

1344
01:05:25,740 --> 01:05:29,060
Something broke and the fix isn't obvious, so the problem starts to feel architectural,

1345
01:05:29,060 --> 01:05:30,500
rather than just a small bug.

1346
01:05:30,500 --> 01:05:34,220
Instead of digging in, they disable the agent and go back to manual processes.

1347
01:05:34,220 --> 01:05:37,100
They never actually find out why it stopped working in the first place.

1348
01:05:37,100 --> 01:05:39,740
The reality is that the failure is usually mundane.

1349
01:05:39,740 --> 01:05:44,060
It's a diagnostic issue, not a systemic one, and you just need to know where to look.

1350
01:05:44,060 --> 01:05:45,060
Start with skill triggering.

1351
01:05:45,060 --> 01:05:49,460
Your skill exists, and it's deployed, but the work that should trigger it just sits there.

1352
01:05:49,460 --> 01:05:52,860
The orchestrator reads the user request yet it doesn't invoke the skill when it's supposed

1353
01:05:52,860 --> 01:05:53,860
to.

1354
01:05:53,860 --> 01:05:57,500
This almost always comes down to the description, specifically the front matter metadata.

1355
01:05:57,500 --> 01:06:01,060
You have to remember that the orchestrator doesn't read your full skill instructions to

1356
01:06:01,060 --> 01:06:02,580
decide whether to trigger it.

1357
01:06:02,580 --> 01:06:03,980
It only reads the description.

1358
01:06:03,980 --> 01:06:08,260
If your description says, "This skill handles customer refund requests validates eligibility

1359
01:06:08,260 --> 01:06:09,940
and notifies the customer."

1360
01:06:09,940 --> 01:06:12,300
The orchestrator scans those specific words.

1361
01:06:12,300 --> 01:06:16,100
When a request arrives saying "customer wants to return an item purchased six months ago",

1362
01:06:16,100 --> 01:06:20,900
the orchestrator looks at your description and sees no mention of returns or item processing.

1363
01:06:20,900 --> 01:06:24,340
Because of that missing keyword, it doesn't trigger the refund skill and routes the request

1364
01:06:24,340 --> 01:06:25,980
to a generic handler instead.

1365
01:06:25,980 --> 01:06:27,820
The fix here is purely mechanical.

1366
01:06:27,820 --> 01:06:31,660
You need to rewrite the description to signal exactly what the skill handles.

1367
01:06:31,660 --> 01:06:36,480
As you'd to say, this skill handles customer refund and return requests, validates eligibility

1368
01:06:36,480 --> 01:06:41,020
based on purchase date, and processes execution through the payment system.

1369
01:06:41,020 --> 01:06:45,260
Now that the description is explicit about returns, the orchestrator recognizes the request

1370
01:06:45,260 --> 01:06:47,380
and triggers the skill every single time.

1371
01:06:47,380 --> 01:06:52,100
Ambiguity creates a different kind of failure where two sub agents claim the same task.

1372
01:06:52,100 --> 01:06:55,140
Imagine a request comes in to update employee benefits.

1373
01:06:55,140 --> 01:06:59,420
The HR agent claims it because it handles benefits administration, but the payroll agent

1374
01:06:59,420 --> 01:07:01,620
also claims it because it's payroll related.

1375
01:07:01,620 --> 01:07:03,460
The orchestrator doesn't know which one to call.

1376
01:07:03,460 --> 01:07:07,660
It might invoke both which creates duplicate work or it might just pick one arbitrarily

1377
01:07:07,660 --> 01:07:09,460
and cause massive inconsistency.

1378
01:07:09,460 --> 01:07:13,100
Sometimes it just gives up and escalates to a human, which completely defeats the purpose

1379
01:07:13,100 --> 01:07:14,340
of your automation.

1380
01:07:14,340 --> 01:07:16,380
The solution is explicit domain scoping.

1381
01:07:16,380 --> 01:07:19,060
The HR agent shouldn't just own benefits in a general sense.

1382
01:07:19,060 --> 01:07:23,460
It needs to own benefits eligibility, enrollment, coverage changes, and dependent updates.

1383
01:07:23,460 --> 01:07:29,140
Meanwhile, the payroll agent owns payroll deductions, tax withholding, and direct deposit.

1384
01:07:29,140 --> 01:07:31,940
When you define it this way, you aren't overlapping anymore.

1385
01:07:31,940 --> 01:07:34,740
A request to update coverage is clearly HR.

1386
01:07:34,740 --> 01:07:37,580
And a request to change deduction amount is clearly payroll.

1387
01:07:37,580 --> 01:07:39,500
No more ambiguity and no more routing errors.

1388
01:07:39,500 --> 01:07:41,900
The compact context problem is a bit more subtle.

1389
01:07:41,900 --> 01:07:45,660
Your agent starts a workflow and reasons clearly through the first few steps, but by step

1390
01:07:45,660 --> 01:07:47,380
five, something shifts.

1391
01:07:47,380 --> 01:07:50,780
The reasoning becomes lazy and the agent starts skipping analysis.

1392
01:07:50,780 --> 01:07:55,020
It begins making assumptions instead of checking facts, or it starts hallucinating details

1393
01:07:55,020 --> 01:07:56,420
instead of retrieving them.

1394
01:07:56,420 --> 01:07:58,580
This happens because the context window is filling up.

1395
01:07:58,580 --> 01:08:02,140
If you loaded five specialist agents, they're full instructions, blueprints, and example

1396
01:08:02,140 --> 01:08:03,140
cases at startup.

1397
01:08:03,140 --> 01:08:06,260
There's barely any room left for new reasoning by the time you hit step five.

1398
01:08:06,260 --> 01:08:07,940
The agent isn't actually thinking anymore.

1399
01:08:07,940 --> 01:08:11,340
It's just patent matching, which is really just a polite way of saying it's guessing.

1400
01:08:11,340 --> 01:08:13,260
The fix is aggressive context minimization.

1401
01:08:13,260 --> 01:08:16,180
Do not load every specialist at the start of the process.

1402
01:08:16,180 --> 01:08:17,860
Instead, load the descriptions first.

1403
01:08:17,860 --> 01:08:20,900
Load the one specific specialist you need for the current task.

1404
01:08:20,900 --> 01:08:23,780
Let it execute and then unload it immediately.

1405
01:08:23,780 --> 01:08:27,100
When the workflow moves to a new domain, you load the next specialist.

1406
01:08:27,100 --> 01:08:31,620
By keeping the reasoning space open, the agent stays sharp because it isn't drowning in unnecessary

1407
01:08:31,620 --> 01:08:32,620
context.

1408
01:08:32,620 --> 01:08:36,220
Authentication and connection failures happen when those agent to agent handshakes fail without

1409
01:08:36,220 --> 01:08:37,380
a word.

1410
01:08:37,380 --> 01:08:41,500
One agent calls another, and they're supposed to establish a secure connection, but something

1411
01:08:41,500 --> 01:08:43,740
in the credentials or the endpoint is wrong.

1412
01:08:43,740 --> 01:08:47,100
The call fails, yet neither agent reports the error clearly.

1413
01:08:47,100 --> 01:08:50,460
The orchestrator has no idea a problem occurred, so it just waits for a response that's never

1414
01:08:50,460 --> 01:08:51,460
coming.

1415
01:08:51,460 --> 01:08:53,820
The user just sees a timeout or a generic error message.

1416
01:08:53,820 --> 01:08:57,780
When you finally dig through the logs, you find a connection-refused error because the agent

1417
01:08:57,780 --> 01:08:59,660
tried to use expired credentials.

1418
01:08:59,660 --> 01:09:02,660
The handshake failed before the work even had a chance to start.

1419
01:09:02,660 --> 01:09:05,300
This is why you need centralized credential management.

1420
01:09:05,300 --> 01:09:09,180
Credentials for these connections shouldn't be stored inside individual agents or hardcoded

1421
01:09:09,180 --> 01:09:10,180
into your configurations.

1422
01:09:10,180 --> 01:09:13,180
They need to live in a dedicated secrets management system.

1423
01:09:13,180 --> 01:09:17,420
The orchestrator should retrieve those credentials at the exact moment of execution.

1424
01:09:17,420 --> 01:09:19,940
If the credentials are expired, the system knows it immediately.

1425
01:09:19,940 --> 01:09:24,020
It can refresh them or escalate the issue, but it won't result in a silent failure.

1426
01:09:24,020 --> 01:09:26,460
Finally you have to watch out for static skill decay.

1427
01:09:26,460 --> 01:09:29,580
You might have built a skill six months ago that worked perfectly, but now it's making

1428
01:09:29,580 --> 01:09:31,860
the wrong call in 20% of your cases.

1429
01:09:31,860 --> 01:09:34,900
The code for the skill hasn't changed at all, but your organization has.

1430
01:09:34,900 --> 01:09:39,620
Your policies evolved, your approval thresholds shifted, and your customer segments were refined.

1431
01:09:39,620 --> 01:09:43,500
The skill is still executing logic that worked last year, but it's no longer aligned with

1432
01:09:43,500 --> 01:09:44,860
how you actually work today.

1433
01:09:44,860 --> 01:09:47,620
This is exactly why skills require quarterly reviews.

1434
01:09:47,620 --> 01:09:50,180
You don't necessarily need a full rewrite, but you do need to check up.

1435
01:09:50,180 --> 01:09:54,300
You should examine the skills recent decisions and check them against your current policy.

1436
01:09:54,300 --> 01:09:56,580
If your guidance has shifted, you update the blueprints.

1437
01:09:56,580 --> 01:09:58,940
If thresholds have changed, you refine the rules.

1438
01:09:58,940 --> 01:10:03,780
Keeping the skills synchronized with your organization's living reality only takes a few hours, and

1439
01:10:03,780 --> 01:10:07,620
it prevents a full year of silent decay.

1440
01:10:07,620 --> 01:10:08,620
Future proofing.

1441
01:10:08,620 --> 01:10:09,620
The open standard.

1442
01:10:09,620 --> 01:10:12,220
Vendor lock-in is the silent killer of enterprise architecture.

1443
01:10:12,220 --> 01:10:16,540
You build a whole system around one platform, specific way of doing things, and you optimize

1444
01:10:16,540 --> 01:10:17,940
everything for their APIs.

1445
01:10:17,940 --> 01:10:22,020
You write code for their semantics and train your entire team on their specific tools.

1446
01:10:22,020 --> 01:10:25,060
Then five years down the road, a much better platform emerges.

1447
01:10:25,060 --> 01:10:26,060
But you're stuck.

1448
01:10:26,060 --> 01:10:28,740
You can't migrate because the switching cost is catastrophic.

1449
01:10:28,740 --> 01:10:32,500
You end up staying with inferior technology just because leaving is more painful than staying.

1450
01:10:32,500 --> 01:10:36,180
This is the exact risk most organizations are facing with AI agents right now.

1451
01:10:36,180 --> 01:10:40,060
You're building your orchestrations in co-pilot studio and designing workflows in a specific

1452
01:10:40,060 --> 01:10:41,460
Microsoft framework.

1453
01:10:41,460 --> 01:10:45,660
You're essentially betting your entire automation future on one company's roadmap.

1454
01:10:45,660 --> 01:10:49,940
What happens if Google releases an agent platform that's objectively better in two years?

1455
01:10:49,940 --> 01:10:52,580
What if AWS builds something that costs half as much?

1456
01:10:52,580 --> 01:10:55,580
You've painted yourself into a corner where you own the software, but you don't own the

1457
01:10:55,580 --> 01:10:56,900
ability to move your data.

1458
01:10:56,900 --> 01:10:59,500
The only real antidote is protocol-based design.

1459
01:10:59,500 --> 01:11:03,580
The skill format we've been building throughout this deep dive isn't proprietary to co-pilot.

1460
01:11:03,580 --> 01:11:05,220
It isn't a Microsoft-only standard.

1461
01:11:05,220 --> 01:11:06,580
It's completely vendor-neutral.

1462
01:11:06,580 --> 01:11:11,700
The skill markdown file with its directions, blueprints and solutions is platform agnostic.

1463
01:11:11,700 --> 01:11:16,580
The same goes for the agent card, the MCP protocol for data access and the A2A protocol for

1464
01:11:16,580 --> 01:11:17,580
communication.

1465
01:11:17,580 --> 01:11:19,860
None of these tools lock you into a single vendor.

1466
01:11:19,860 --> 01:11:23,980
Claude can read a skill file just as easily as chat GPT or Gemini can.

1467
01:11:23,980 --> 01:11:27,220
The instruction format is human readable and completely portable.

1468
01:11:27,220 --> 01:11:31,020
If you build a skill today in co-pilot studio and a better platform becomes dominant in three

1469
01:11:31,020 --> 01:11:33,740
years, you won't have to rewrite everything from scratch.

1470
01:11:33,740 --> 01:11:36,740
You can just upload that same skill file to a different orchestrator.

1471
01:11:36,740 --> 01:11:39,740
The workflow logic doesn't change and the direction stays the same.

1472
01:11:39,740 --> 01:11:41,660
The only thing that actually changes is the runtime.

1473
01:11:41,660 --> 01:11:44,740
This kind of portability is your architectural insurance policy.

1474
01:11:44,740 --> 01:11:47,620
You aren't betting on Microsoft owning the future of AI.

1475
01:11:47,620 --> 01:11:49,740
Instead, you're betting on standards and protocols.

1476
01:11:49,740 --> 01:11:54,300
You're betting on the idea that good design matters more than any single platform.

1477
01:11:54,300 --> 01:11:57,980
It's the difference between building your house on shifting sand or solid bedrock.

1478
01:11:57,980 --> 01:12:03,780
This shift also changes what the word "skill" actually means in a professional context.

1479
01:12:03,780 --> 01:12:07,980
Right now, many people think a skill is just a configuration or a set of prompts inside

1480
01:12:07,980 --> 01:12:12,140
co-pilot studio. That's a very narrow view. When you move toward protocol-based thinking,

1481
01:12:12,140 --> 01:12:16,300
a skill becomes a full specification of how work should be done and it becomes independent

1482
01:12:16,300 --> 01:12:19,060
of the tool that's actually executing the task.

1483
01:12:19,060 --> 01:12:23,340
This is the big move from prompting as a skill to systems design as a skill.

1484
01:12:23,340 --> 01:12:26,420
In the old model, a skill was just a really well-written prompt.

1485
01:12:26,420 --> 01:12:30,860
You engineered the phrasing, you got the examples right, and you tweaked the tone until it worked.

1486
01:12:30,860 --> 01:12:32,740
But that's tool-specific and very brittle.

1487
01:12:32,740 --> 01:12:36,980
If the underlying model changes even slightly, that prompt might stop working entirely.

1488
01:12:36,980 --> 01:12:41,100
In this new model, a skill is a design. It describes the entire workflow, the logic,

1489
01:12:41,100 --> 01:12:45,420
the constraints and the context. The prompt itself is just an implementation detail because

1490
01:12:45,420 --> 01:12:49,340
the skill is platform agnostic, you can set it up on co-pilot studio with one set of

1491
01:12:49,340 --> 01:12:53,460
prompts or on-clawed with a different set. The intellectual structure of the skill never

1492
01:12:53,460 --> 01:12:56,860
changes, only how you express it to different systems.

1493
01:12:56,860 --> 01:13:01,220
This elevation of skill design is what architects should be focusing on as we move toward

1494
01:13:01,220 --> 01:13:05,220
2026. You shouldn't be worrying about how to write better prompts for one specific

1495
01:13:05,220 --> 01:13:09,700
tool. You should be learning how to design systems that work across any agent platform.

1496
01:13:09,700 --> 01:13:13,620
It's not about configuring a specific studio. It's about architecting intelligence into

1497
01:13:13,620 --> 01:13:17,540
your organization that exists independently of any single vendor.

1498
01:13:17,540 --> 01:13:21,420
This matters because the agent ecosystem is about to explode. Google has its own version

1499
01:13:21,420 --> 01:13:25,620
of agent-to-agent communication and OpenAI is building its own frameworks. Microsoft

1500
01:13:25,620 --> 01:13:29,900
has co-pilot studio and AWS is right behind them. Every cloud vendor is trying to own

1501
01:13:29,900 --> 01:13:34,700
the orchestration layer. But the standard that wins won't be the one with the most licenses.

1502
01:13:34,700 --> 01:13:38,100
It will be the one that is the most portable and interoperable.

1503
01:13:38,100 --> 01:13:42,020
Organizations that design for these protocol-based standards are the ones that win because

1504
01:13:42,020 --> 01:13:46,260
they have the freedom to move. They can choose the best tool for the job at any given moment.

1505
01:13:46,260 --> 01:13:49,660
They aren't locked into a decision they made years ago. They are architecting for a world

1506
01:13:49,660 --> 01:13:54,020
where half of all work is agent-to-agent, where those agents span across different vendors

1507
01:13:54,020 --> 01:13:56,820
and where the work itself is the only thing that matters.

1508
01:13:56,820 --> 01:14:00,100
Your job as an architect is to design that intelligence layer. You don't need to become

1509
01:14:00,100 --> 01:14:04,500
a narrow expert in one specific software suite. You need to become an expert in

1510
01:14:04,500 --> 01:14:08,980
building agent systems that transcend any single vendor. That is how you future-proof your

1511
01:14:08,980 --> 01:14:14,020
career and that is the only mandate that actually matters. Prompting is just a phase, but

1512
01:14:14,020 --> 01:14:17,780
orchestration is the structure that actually scales. You need to build your agent fabric

1513
01:14:17,780 --> 01:14:22,100
now. Connect with me on LinkedIn if this changes how you think about intelligence. If this

1514
01:14:22,100 --> 01:14:23,740
helped, leave a review. It matters.