The End of AI Bloat: Why Modern Agents Need Skills
Many AI agents start out fast, responsive, and surprisingly intelligent. But after a few months of real-world use, something changes. Response times increase, costs rise, prompts become enormous, and accuracy begins to decline. Organizations often respond by upgrading to larger models, expanding prompts, or adding more orchestration—but the underlying problem remains. The issue isn't the model. It's the architecture. This episode explains why monolithic prompts create what is known as the Context Tax, how modular Skills solve the problem through progressive disclosure, and why Skills are becoming the architectural foundation of modern AI agents across Microsoft Copilot Studio, GitHub Copilot, Claude Code, and the broader enterprise AI ecosystem.
THE CONTEXT TAX
Every enterprise AI project eventually faces the same challenge. At first, an agent contains a relatively small system prompt describing its role, tone, business rules, and guardrails. As the organization grows, more instructions are added:
- Policies
- Compliance rules
- Business procedures
- Examples
- Edge cases
- Department-specific workflows
WHY AGENTS DEGRADE OVER TIME
Agent degradation is remarkably predictable. Organizations usually begin with one comprehensive instruction document that contains everything the AI should know. Initially this works well. Then new departments request additional functionality. Policies evolve. Compliance requirements expand. New workflows are added. Instead of restructuring the architecture, teams simply keep extending the same prompt. The result is context saturation. The model spends increasing amounts of effort searching through irrelevant guidance before finding the instructions that actually matter. This produces several side effects:
- Higher token consumption
- Slower responses
- Increased hallucinations
- More inconsistent reasoning
- Higher operational costs
ALWAYS-ON GUIDANCE VS SITUATIONAL EXPERTISE
One of the most important architectural distinctions introduced in this session is separating always-on guidance from situational expertise. Always-on guidance includes information that applies to every conversation:
- Agent identity
- Tone of voice
- Universal compliance rules
- Security requirements
- Core behavioral instructions
- Vendor onboarding
- Leave eligibility
- Tax regulations
- Refund workflows
- Regional compliance
- Incident response procedures
WHAT IS A SKILL?
A Skill is much more than a prompt. It is a reusable package containing:
- Structured instructions
- Metadata
- Trigger descriptions
- Optional scripts
- Reference documents
- Templates
- Supporting assets
- Name
- Description
- Purpose
- Trigger conditions
- Workflow
- Procedural guidance
THE REASONING BOUNDARY
The presentation introduces another important architectural concept: Skills define reasoning boundaries. Rather than forcing an AI model to treat every instruction as universally relevant, Skills establish clear expertise domains. A leave management Skill applies only to leave requests. A procurement Skill activates only during purchasing workflows. A compliance Skill loads only when compliance questions arise. Each Skill becomes an isolated reasoning domain. Instead of thinking about every possible business process simultaneously, the model focuses exclusively on the knowledge required for the current task. This improves both precision and consistency.
PROGRESSIVE DISCLOSURE
One of the core design principles behind Skills is Progressive Disclosure. Instead of loading every instruction at startup, agents maintain only a lightweight catalog containing Skill names and descriptions. When a matching scenario appears:
- The orchestrator identifies the relevant Skill.
- The Skill loads into context.
- The task executes.
- The Skill unloads after completion.
- Token usage
- Latency
- Compute requirements
- Infrastructure costs
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
00:00:00,000 --> 00:00:02,440
Your agent starts fast by month three at sluggish.
2
00:00:02,440 --> 00:00:04,360
You notice it first in the response times.
3
00:00:04,360 --> 00:00:06,800
A question that took three seconds now takes eight.
4
00:00:06,800 --> 00:00:08,280
You add more context hoping it helps.
5
00:00:08,280 --> 00:00:11,640
You paste in policies, procedures, guardrails, and examples.
6
00:00:11,640 --> 00:00:14,040
You want the model to have everything it might need.
7
00:00:14,040 --> 00:00:16,080
But then the cost goes up, the errors increase,
8
00:00:16,080 --> 00:00:17,120
and the agent gets slower.
9
00:00:17,120 --> 00:00:18,480
So you do what seems logical.
10
00:00:18,480 --> 00:00:19,560
You add a bigger model.
11
00:00:19,560 --> 00:00:20,600
You refine the prompt.
12
00:00:20,600 --> 00:00:22,400
You try different orchestration patterns.
13
00:00:22,400 --> 00:00:23,440
None of it works.
14
00:00:23,440 --> 00:00:25,960
Because the problem isn't the model, the problem is the structure.
15
00:00:25,960 --> 00:00:28,280
Every turn that agent reads the entire manual,
16
00:00:28,280 --> 00:00:31,040
every token in your system prompt gets processed.
17
00:00:31,040 --> 00:00:33,920
Every policy, every procedure, and every edge case
18
00:00:33,920 --> 00:00:35,400
is something the model attends to,
19
00:00:35,400 --> 00:00:36,800
whether it's relevant or not.
20
00:00:36,800 --> 00:00:38,080
That's the context text.
21
00:00:38,080 --> 00:00:40,000
And it's killing enterprise AI deployments.
22
00:00:40,000 --> 00:00:41,880
The fix isn't bigger models or better prompts.
23
00:00:41,880 --> 00:00:42,960
It's architecture.
24
00:00:42,960 --> 00:00:44,480
Why agents degrade?
25
00:00:44,480 --> 00:00:46,400
This is what most organizations don't understand
26
00:00:46,400 --> 00:00:47,760
about agent decay.
27
00:00:47,760 --> 00:00:50,280
It starts with what feels like a simple design choice.
28
00:00:50,280 --> 00:00:52,400
You write a comprehensive instruction set.
29
00:00:52,400 --> 00:00:54,320
You document how the agent should behave,
30
00:00:54,320 --> 00:00:57,160
what tone it should adopt, and what rules it must follow.
31
00:00:57,160 --> 00:00:59,200
You add domain knowledge like your data model,
32
00:00:59,200 --> 00:01:01,400
your business rules, and your compliance requirements.
33
00:01:01,400 --> 00:01:02,320
You throw in examples.
34
00:01:02,320 --> 00:01:03,560
You anticipate edge cases.
35
00:01:03,560 --> 00:01:05,560
The result is a monolithic instruction blob.
36
00:01:05,560 --> 00:01:09,720
Everything in one place, one system prompt, one version, one owner.
37
00:01:09,720 --> 00:01:11,280
For the first few weeks, it works fine.
38
00:01:11,280 --> 00:01:12,320
The agent is fast.
39
00:01:12,320 --> 00:01:13,200
The responses are good.
40
00:01:13,200 --> 00:01:14,400
Users adopt it.
41
00:01:14,400 --> 00:01:15,920
Then you need to add something new.
42
00:01:15,920 --> 00:01:16,840
A new policy.
43
00:01:16,840 --> 00:01:19,000
A different workflow for a specific department.
44
00:01:19,000 --> 00:01:21,720
A guardrail for a recent incident, you add it to the blob.
45
00:01:21,720 --> 00:01:22,840
The blob grows.
46
00:01:22,840 --> 00:01:24,640
By month three, that instruction set
47
00:01:24,640 --> 00:01:27,480
has become this massive, undifferentiated pile of rules.
48
00:01:27,480 --> 00:01:28,680
Some are critical.
49
00:01:28,680 --> 00:01:30,720
Some apply only once a quarter.
50
00:01:30,720 --> 00:01:32,640
Some contradict each other in subtle ways.
51
00:01:32,640 --> 00:01:34,280
But the agent loads all of it.
52
00:01:34,280 --> 00:01:35,280
Every single turn.
53
00:01:35,280 --> 00:01:36,680
That's context saturation.
54
00:01:36,680 --> 00:01:37,920
Here's what happens at scale.
55
00:01:37,920 --> 00:01:39,360
The model reads more tokens.
56
00:01:39,360 --> 00:01:40,840
Reading more tokens costs more.
57
00:01:40,840 --> 00:01:42,000
It also takes longer.
58
00:01:42,000 --> 00:01:43,240
Latency increases.
59
00:01:43,240 --> 00:01:44,720
The reasoning parts gets noisier
60
00:01:44,720 --> 00:01:47,120
because the model has to pass through irrelevant guidance
61
00:01:47,120 --> 00:01:48,360
to find what matters.
62
00:01:48,360 --> 00:01:49,560
So accuracy drifts.
63
00:01:49,560 --> 00:01:50,640
False positives increase.
64
00:01:50,640 --> 00:01:53,480
The agent starts making mistakes it didn't make before.
65
00:01:53,480 --> 00:01:55,000
You notice the agent feels dumb.
66
00:01:55,000 --> 00:01:55,840
It is.
67
00:01:55,840 --> 00:01:58,440
Not because the model got worse, but because it's drowning in noise.
68
00:01:58,440 --> 00:01:59,760
The research is clear on this.
69
00:01:59,760 --> 00:02:01,560
When you split a monolithic instruction set
70
00:02:01,560 --> 00:02:04,480
into modular skills, loading only the guidance relevant
71
00:02:04,480 --> 00:02:05,520
to the current task.
72
00:02:05,520 --> 00:02:08,800
Organizations report 96% token savings.
73
00:02:08,800 --> 00:02:11,000
Not a small percentage, 96%.
74
00:02:11,000 --> 00:02:14,240
That same split delivers a 93% latency improvement.
75
00:02:14,240 --> 00:02:15,360
9/10 faster.
76
00:02:15,360 --> 00:02:17,600
But the issue runs deeper than just speed and cost.
77
00:02:17,600 --> 00:02:19,360
There's a structural flaw nobody talks about.
78
00:02:19,360 --> 00:02:21,280
Organizations treat all rules the same way.
79
00:02:21,280 --> 00:02:24,560
A universal guardrail that must apply to every conversation
80
00:02:24,560 --> 00:02:26,920
gets piled into the same instruction file
81
00:02:26,920 --> 00:02:28,840
as a specialized workflow that applies
82
00:02:28,840 --> 00:02:31,520
to maybe 5% of your use cases.
83
00:02:31,520 --> 00:02:33,240
The specialized guidance is always loaded,
84
00:02:33,240 --> 00:02:35,560
always consuming tokens, and always slowing down
85
00:02:35,560 --> 00:02:36,320
the reasoning path.
86
00:02:36,320 --> 00:02:38,160
Even though most of the time it's irrelevant.
87
00:02:38,160 --> 00:02:39,960
The difference is between always on guidance
88
00:02:39,960 --> 00:02:41,360
and situational expertise.
89
00:02:41,360 --> 00:02:45,320
Always on guidance is your tone, your role, your identity.
90
00:02:45,320 --> 00:02:47,200
Universal compliance rules.
91
00:02:47,200 --> 00:02:49,360
Things that apply to every single conversation,
92
00:02:49,360 --> 00:02:51,320
regardless of what the user asks for.
93
00:02:51,320 --> 00:02:53,120
Situational expertise is different.
94
00:02:53,120 --> 00:02:55,280
It's the step-by-step procedure for handling a refund
95
00:02:55,280 --> 00:02:56,680
above a certain threshold.
96
00:02:56,680 --> 00:02:58,760
It's the checklist for onboarding a new vendor.
97
00:02:58,760 --> 00:03:01,560
It's the specific tax rules for a particular region
98
00:03:01,560 --> 00:03:03,720
invoked only when that region matters.
99
00:03:03,720 --> 00:03:05,920
It's specialized knowledge that the model doesn't need
100
00:03:05,920 --> 00:03:08,400
in context unless the scenario actually comes up.
101
00:03:08,400 --> 00:03:10,960
When you throw both into the same instruction file,
102
00:03:10,960 --> 00:03:12,280
you've created a bloated context
103
00:03:12,280 --> 00:03:14,880
that the agent has to pass on every turn.
104
00:03:14,880 --> 00:03:18,040
The model wastes computation reading irrelevant procedures.
105
00:03:18,040 --> 00:03:20,240
The latency balloons, the cost climbs,
106
00:03:20,240 --> 00:03:22,600
and the accuracy suffers because important guidance
107
00:03:22,600 --> 00:03:23,520
gets buried.
108
00:03:23,520 --> 00:03:24,720
This is the structural flaw.
109
00:03:24,720 --> 00:03:26,240
The moment your agent starts handling
110
00:03:26,240 --> 00:03:27,920
more than one type of scenario,
111
00:03:27,920 --> 00:03:30,680
a monolithic architecture breaks, not immediately,
112
00:03:30,680 --> 00:03:32,360
but predictably, by design.
113
00:03:32,360 --> 00:03:33,840
The fix is to separate them.
114
00:03:33,840 --> 00:03:35,800
Keep the always on guidance lean and sharp.
115
00:03:35,800 --> 00:03:37,640
Move situational guidance into skills.
116
00:03:37,640 --> 00:03:40,480
These are reusable, on-demand instruction sets
117
00:03:40,480 --> 00:03:42,800
that the orchestrator loads only when needed.
118
00:03:42,800 --> 00:03:45,320
Load the one thing the agent actually needs for this task.
119
00:03:45,320 --> 00:03:46,880
Ignore the other 47 draws.
120
00:03:46,880 --> 00:03:47,960
That's the architecture shift.
121
00:03:47,960 --> 00:03:49,400
That's what modern agents are doing.
122
00:03:49,400 --> 00:03:51,320
And it's where we're heading next.
123
00:03:51,320 --> 00:03:53,120
The skill as a reasoning boundary.
124
00:03:53,120 --> 00:03:54,600
So what exactly is a skill?
125
00:03:54,600 --> 00:03:56,960
At its core, a skill is a self-contained package.
126
00:03:56,960 --> 00:03:58,920
It contains three things, structured instructions
127
00:03:58,920 --> 00:04:00,680
for a specific workflow, metadata
128
00:04:00,680 --> 00:04:02,720
that tells the orchestrator when to use it,
129
00:04:02,720 --> 00:04:03,960
and bundled resources.
130
00:04:03,960 --> 00:04:05,760
Like scripts, templates, or documents,
131
00:04:05,760 --> 00:04:07,160
the foundation is the skill.
132
00:04:07,160 --> 00:04:09,520
MD file, this is just a markdown document
133
00:04:09,520 --> 00:04:10,800
with the YAML front matter.
134
00:04:10,800 --> 00:04:13,480
It declares the name, a description of when it applies
135
00:04:13,480 --> 00:04:14,920
and the procedural steps.
136
00:04:14,920 --> 00:04:17,240
It sounds straightforward, almost boring.
137
00:04:17,240 --> 00:04:19,720
But the format matters because it has become portable.
138
00:04:19,720 --> 00:04:22,600
In late 2025, I'm tropic published an open standard
139
00:04:22,600 --> 00:04:24,960
that created a shared language for these capabilities.
140
00:04:24,960 --> 00:04:27,800
That format was quickly adopted by OpenAI, Microsoft,
141
00:04:27,800 --> 00:04:29,280
and dozens of other platforms.
142
00:04:29,280 --> 00:04:31,600
This didn't happen because of a committee or a mandate.
143
00:04:31,600 --> 00:04:33,080
It happened because it worked.
144
00:04:33,080 --> 00:04:34,760
The format was simple enough to adopt,
145
00:04:34,760 --> 00:04:36,680
expressive enough for real workflows,
146
00:04:36,680 --> 00:04:38,840
and lightweight enough to move between systems
147
00:04:38,840 --> 00:04:40,240
without any translation.
148
00:04:40,240 --> 00:04:42,120
Today, you can write a skill once and use it
149
00:04:42,120 --> 00:04:44,040
across GitHub co-pilot, Claude code,
150
00:04:44,040 --> 00:04:46,880
and co-pilot studio without rewriting a single line.
151
00:04:46,880 --> 00:04:48,480
But here is the part most people miss,
152
00:04:48,480 --> 00:04:50,720
the metadata, the name and the description.
153
00:04:50,720 --> 00:04:52,880
Isn't just documentation, it is an API.
154
00:04:52,880 --> 00:04:53,720
Think about it this way.
155
00:04:53,720 --> 00:04:55,200
The orchestrator has one job.
156
00:04:55,200 --> 00:04:57,760
It reads the user's request, looks at the context,
157
00:04:57,760 --> 00:04:59,240
and asks the single question,
158
00:04:59,240 --> 00:05:01,240
which skill should I load right now?
159
00:05:01,240 --> 00:05:03,120
To answer that, the orchestrator does not read
160
00:05:03,120 --> 00:05:04,200
the full instructions.
161
00:05:04,200 --> 00:05:07,080
It doesn't pass 30 paragraphs of step-by-step guidance.
162
00:05:07,080 --> 00:05:09,200
Instead, it evaluates the name and description
163
00:05:09,200 --> 00:05:11,200
against what the user is trying to do.
164
00:05:11,200 --> 00:05:13,160
The name and description are the routing signals.
165
00:05:13,160 --> 00:05:15,520
This is why precision in naming is everything.
166
00:05:15,520 --> 00:05:17,400
If you name a skill HR help, it will fail
167
00:05:17,400 --> 00:05:18,960
because the scope is too broad.
168
00:05:18,960 --> 00:05:21,200
The orchestrator can't tell if the user needs help
169
00:05:21,200 --> 00:05:23,160
with benefits, pay, or leave policies.
170
00:05:23,160 --> 00:05:25,240
The result is that the system either loads the skill
171
00:05:25,240 --> 00:05:28,400
every time HR is mentioned, which pollutes the context window
172
00:05:28,400 --> 00:05:30,760
or it never loads at all because the description is too vague
173
00:05:30,760 --> 00:05:31,560
to match.
174
00:05:31,560 --> 00:05:34,200
But HR leave eligibility triage actually works.
175
00:05:34,200 --> 00:05:36,520
The name is specific, the description is precise.
176
00:05:36,520 --> 00:05:38,320
You tell the system to use this skill
177
00:05:38,320 --> 00:05:40,680
when a user asks about leave eligibility,
178
00:05:40,680 --> 00:05:42,960
require documents or a crew calculations.
179
00:05:42,960 --> 00:05:45,120
Now the orchestrator can make a real decision.
180
00:05:45,120 --> 00:05:47,120
When a user asks how much paid time off they have,
181
00:05:47,120 --> 00:05:49,080
the model reads that description, sees the match,
182
00:05:49,080 --> 00:05:50,080
and loads the skill.
183
00:05:50,080 --> 00:05:52,040
But when that same user asks about their salary,
184
00:05:52,040 --> 00:05:53,480
the skill stays unloaded.
185
00:05:53,480 --> 00:05:55,880
The orchestrator's job is matching intent to expertise.
186
00:05:55,880 --> 00:05:58,360
Once the skill is selected, the full instructions
187
00:05:58,360 --> 00:05:59,840
finally come into context.
188
00:05:59,840 --> 00:06:01,720
Now the model has the step-by-step procedure,
189
00:06:01,720 --> 00:06:04,480
the examples, and the guardrails for that specific workflow.
190
00:06:04,480 --> 00:06:05,760
It executes with precision.
191
00:06:05,760 --> 00:06:07,840
And when the conversation shifts, the orchestrator
192
00:06:07,840 --> 00:06:09,680
unloads it and brings in something else.
193
00:06:09,680 --> 00:06:11,040
This is the reasoning boundary.
194
00:06:11,040 --> 00:06:13,120
A skill isn't a straight jacket that forces the model
195
00:06:13,120 --> 00:06:14,360
to act a certain way.
196
00:06:14,360 --> 00:06:17,040
It is a boundary that marks where one area of expertise
197
00:06:17,040 --> 00:06:18,640
ends and another begins.
198
00:06:18,640 --> 00:06:21,080
It tells the model that the specialized knowledge applies
199
00:06:21,080 --> 00:06:22,920
to this specific scenario, but it
200
00:06:22,920 --> 00:06:25,040
shouldn't treat this guidance as universal.
201
00:06:25,040 --> 00:06:27,240
Skills also use what we call soft-pointing.
202
00:06:27,240 --> 00:06:29,320
This means they reference tools without being permanently
203
00:06:29,320 --> 00:06:30,320
bound to them.
204
00:06:30,320 --> 00:06:33,560
A skill can tell the model to call a leave-approval action,
205
00:06:33,560 --> 00:06:36,160
but it doesn't require that action to exist to function.
206
00:06:36,160 --> 00:06:38,960
If the action isn't in the toolkit, the skill still loads,
207
00:06:38,960 --> 00:06:41,760
and the model simply adapts by acknowledging the limitation
208
00:06:41,760 --> 00:06:43,360
or escalating the issue.
209
00:06:43,360 --> 00:06:46,240
The skill provides the blueprint, not an iron-clad mandate.
210
00:06:46,240 --> 00:06:48,640
This architecture separates instruction from execution
211
00:06:48,640 --> 00:06:50,040
and knowledge from tools.
212
00:06:50,040 --> 00:06:51,680
Each piece can evolve on its own.
213
00:06:51,680 --> 00:06:53,920
And the orchestrator, the intelligent router,
214
00:06:53,920 --> 00:06:55,840
decides what gets loaded and when.
215
00:06:55,840 --> 00:06:57,000
That is the shift.
216
00:06:57,000 --> 00:06:58,920
That is what a skill actually is.
217
00:06:58,920 --> 00:07:00,560
The progressive disclosure pattern.
218
00:07:00,560 --> 00:07:02,920
There is a design principle underneath all of this
219
00:07:02,920 --> 00:07:04,520
called progressive disclosure.
220
00:07:04,520 --> 00:07:05,560
It works like this.
221
00:07:05,560 --> 00:07:07,680
Your agent does not load the entire skill library
222
00:07:07,680 --> 00:07:08,440
at startup.
223
00:07:08,440 --> 00:07:11,320
Instead, it loads the metadata, the lightweight summary.
224
00:07:11,320 --> 00:07:14,000
For every skill, that is just the name and the description.
225
00:07:14,000 --> 00:07:16,120
It is compact and uses minimal tokens.
226
00:07:16,120 --> 00:07:18,080
Think of it as a directory that the orchestrator keeps
227
00:07:18,080 --> 00:07:20,400
in view at all times to decide what is relevant.
228
00:07:20,400 --> 00:07:22,640
Everything else, the instructions, the examples,
229
00:07:22,640 --> 00:07:26,080
and the scripts stays on the disk until the moment it is needed.
230
00:07:26,080 --> 00:07:27,920
When the orchestrator decides, a skill
231
00:07:27,920 --> 00:07:30,880
matches the user's intent, the full content loads.
232
00:07:30,880 --> 00:07:33,040
The instructions enter the context mid-conversation,
233
00:07:33,040 --> 00:07:34,200
the reasoning path shifts.
234
00:07:34,200 --> 00:07:36,440
Suddenly, the model has access to specialized guidance
235
00:07:36,440 --> 00:07:38,560
that was not available a few seconds ago.
236
00:07:38,560 --> 00:07:39,840
This matters for operations in ways
237
00:07:39,840 --> 00:07:41,320
that go away beyond the obvious.
238
00:07:41,320 --> 00:07:43,320
When a skill is unloaded, those tokens
239
00:07:43,320 --> 00:07:44,640
are not sitting in the prompt.
240
00:07:44,640 --> 00:07:46,000
They aren't there at all.
241
00:07:46,000 --> 00:07:47,680
This means that for every response,
242
00:07:47,680 --> 00:07:49,520
the model processes a smaller prompt
243
00:07:49,520 --> 00:07:51,400
with fewer tokens to attend to.
244
00:07:51,400 --> 00:07:53,120
Processing time drops as a result.
245
00:07:53,120 --> 00:07:55,520
A conversation that would have taken 45 seconds
246
00:07:55,520 --> 00:07:58,800
with a bloated monolithic prompt might only take 15 seconds
247
00:07:58,800 --> 00:08:00,720
when only the active skill is loaded.
248
00:08:00,720 --> 00:08:02,400
That isn't just a small improvement.
249
00:08:02,400 --> 00:08:03,680
It is a structural change.
250
00:08:03,680 --> 00:08:05,480
The latency math is very simple.
251
00:08:05,480 --> 00:08:07,840
Model inference time scales with token count.
252
00:08:07,840 --> 00:08:09,480
If you cut the tokens per turn and half,
253
00:08:09,480 --> 00:08:10,920
you cut the latency roughly in half.
254
00:08:10,920 --> 00:08:13,600
If you reduce tokens by 80%, which is realistic
255
00:08:13,600 --> 00:08:15,040
when you split situational guidance
256
00:08:15,040 --> 00:08:16,880
out of the main instructions.
257
00:08:16,880 --> 00:08:17,760
The speed follows.
258
00:08:17,760 --> 00:08:19,560
Your response time improves proportionally,
259
00:08:19,560 --> 00:08:23,400
but the real leverage shows up when the system is under load.
260
00:08:23,400 --> 00:08:25,800
When you have multiple conversations happening at once,
261
00:08:25,800 --> 00:08:27,400
throughput becomes the bottleneck.
262
00:08:27,400 --> 00:08:29,720
Every conversation consumes compute.
263
00:08:29,720 --> 00:08:31,720
If your instruction set forces every turn
264
00:08:31,720 --> 00:08:33,960
to process 10,000 tokens, you are burning
265
00:08:33,960 --> 00:08:36,640
through your computational budget at an incredible rate.
266
00:08:36,640 --> 00:08:38,160
If you add 50 concurrent users,
267
00:08:38,160 --> 00:08:40,600
you will hit rate limits and start queuing requests.
268
00:08:40,600 --> 00:08:42,160
The service feels sluggish to everyone.
269
00:08:42,160 --> 00:08:44,440
Progressive disclosure changes that equation.
270
00:08:44,440 --> 00:08:45,920
Because skills load on demand,
271
00:08:45,920 --> 00:08:47,880
the baseline context stays lean.
272
00:08:47,880 --> 00:08:49,840
Most turns process a fraction of the tokens
273
00:08:49,840 --> 00:08:52,160
they would in an old school architecture.
274
00:08:52,160 --> 00:08:55,040
50 concurrent users now occupy much less compute
275
00:08:55,040 --> 00:08:56,880
allowing your throughput to scale.
276
00:08:56,880 --> 00:08:58,720
You can handle more conversations simultaneously
277
00:08:58,720 --> 00:09:00,440
before you ever hit a limit.
278
00:09:00,440 --> 00:09:02,320
This is why a skills architecture scales better
279
00:09:02,320 --> 00:09:03,640
than a monolithic agent.
280
00:09:03,640 --> 00:09:05,120
It isn't just that skills are faster.
281
00:09:05,120 --> 00:09:07,880
It is that they let you do more work with the same budget.
282
00:09:07,880 --> 00:09:09,440
The cost lever works the same way.
283
00:09:09,440 --> 00:09:11,120
Every time the model generates a response,
284
00:09:11,120 --> 00:09:12,360
you pay for tokens.
285
00:09:12,360 --> 00:09:13,800
Every search or tool invocation
286
00:09:13,800 --> 00:09:15,840
has a cost measured in co-pilot credits.
287
00:09:15,840 --> 00:09:17,560
When you reduce the tokens per turn
288
00:09:17,560 --> 00:09:19,160
through progressive disclosure,
289
00:09:19,160 --> 00:09:21,680
you reduce the reasoning cost at the same time.
290
00:09:21,680 --> 00:09:23,480
Because the skill architecture lets you handle
291
00:09:23,480 --> 00:09:25,480
more conversations per unit of compute,
292
00:09:25,480 --> 00:09:28,120
you reduce the total API calls per conversation.
293
00:09:28,120 --> 00:09:30,040
You have fewer round trips to external systems
294
00:09:30,040 --> 00:09:32,760
and fewer searches because the model has targeted guidance.
295
00:09:32,760 --> 00:09:34,720
Your spend on co-pilot credits goes down
296
00:09:34,720 --> 00:09:37,160
and that difference is measurable and significant.
297
00:09:37,160 --> 00:09:39,560
Organizations are reporting that they keep their metadata
298
00:09:39,560 --> 00:09:41,480
layer, the names and descriptions.
299
00:09:41,480 --> 00:09:43,160
Under a few hundred tokens total,
300
00:09:43,160 --> 00:09:45,520
as conversations branch into different scenarios,
301
00:09:45,520 --> 00:09:46,840
different skills activate.
302
00:09:46,840 --> 00:09:48,960
One conversation might load three separate skills
303
00:09:48,960 --> 00:09:51,720
over its lifetime while another might only load one.
304
00:09:51,720 --> 00:09:54,360
But every single turn, the baseline stays lean.
305
00:09:54,360 --> 00:09:55,880
Only what is needed is in the context.
306
00:09:55,880 --> 00:09:57,400
This is the efficiency of the architecture.
307
00:09:57,400 --> 00:09:59,040
It isn't about one single feature.
308
00:09:59,040 --> 00:10:00,840
It is about the structural principle.
309
00:10:00,840 --> 00:10:02,240
Keep the default minimal.
310
00:10:02,240 --> 00:10:03,720
Load what is needed.
311
00:10:03,720 --> 00:10:04,960
Unload when you are done.
312
00:10:04,960 --> 00:10:05,720
Repeat.
313
00:10:05,720 --> 00:10:07,600
Manageability is a first-order problem.
314
00:10:07,600 --> 00:10:10,000
This is where the real value of skills emerges.
315
00:10:10,000 --> 00:10:12,120
And it's almost never the first thing people talk about.
316
00:10:12,120 --> 00:10:14,040
Performance matters, cost matters.
317
00:10:14,040 --> 00:10:16,560
But what determines whether an AI system actually
318
00:10:16,560 --> 00:10:18,960
survives in an organization is manageability?
319
00:10:18,960 --> 00:10:19,880
Can you maintain it?
320
00:10:19,880 --> 00:10:22,080
Can you update it without breaking something else?
321
00:10:22,080 --> 00:10:22,920
Can you own it?
322
00:10:22,920 --> 00:10:25,920
In a monolithic architecture, you have one instruction file,
323
00:10:25,920 --> 00:10:28,440
one massive document, one version, one review cycle,
324
00:10:28,440 --> 00:10:31,200
one owner, at least theoretically, but in reality,
325
00:10:31,200 --> 00:10:32,600
when everything is interconnected,
326
00:10:32,600 --> 00:10:33,960
ownership becomes fuzzy.
327
00:10:33,960 --> 00:10:35,240
Someone adds a guardrail.
328
00:10:35,240 --> 00:10:36,920
Someone else adds a policy.
329
00:10:36,920 --> 00:10:38,440
A third person refines the tone.
330
00:10:38,440 --> 00:10:41,080
Now you have a file that nobody fully understands,
331
00:10:41,080 --> 00:10:42,360
maintained by committee,
332
00:10:42,360 --> 00:10:44,800
with no clear owner accountable for the whole thing.
333
00:10:44,800 --> 00:10:46,320
When you need to change something,
334
00:10:46,320 --> 00:10:47,760
the review surface is enormous.
335
00:10:47,760 --> 00:10:50,320
You're updating a 5,000 line instruction file
336
00:10:50,320 --> 00:10:51,520
where a change to one workflow
337
00:10:51,520 --> 00:10:53,440
can have ripple effects on unrelated logic.
338
00:10:53,440 --> 00:10:54,840
Everything is entangled.
339
00:10:54,840 --> 00:10:57,080
You don't know what will break, so you test exhaustively.
340
00:10:57,080 --> 00:10:59,080
You get nervous, you move slowly,
341
00:10:59,080 --> 00:11:01,560
or you move fast in things break in production.
342
00:11:01,560 --> 00:11:03,800
Neither is good, with modular skills,
343
00:11:03,800 --> 00:11:05,200
the dynamic reverses.
344
00:11:05,200 --> 00:11:08,880
One skill is one version, one owner, one review cycle.
345
00:11:08,880 --> 00:11:12,080
A skill for leave eligibility is owned by the HR team.
346
00:11:12,080 --> 00:11:13,520
While a skill for vendor onboarding
347
00:11:13,520 --> 00:11:14,920
is owned by procurement,
348
00:11:14,920 --> 00:11:16,360
and a skill for incident escalation
349
00:11:16,360 --> 00:11:17,960
is owned by operations.
350
00:11:17,960 --> 00:11:19,920
Each team maintains their own expertise.
351
00:11:19,920 --> 00:11:21,360
Nobody has to be an expert in everything.
352
00:11:21,360 --> 00:11:23,000
The review surface for any single skill
353
00:11:23,000 --> 00:11:25,760
is small enough that humans can reason about it completely.
354
00:11:25,760 --> 00:11:28,360
A hundred line instruction set for a specific workflow
355
00:11:28,360 --> 00:11:31,320
is something a person can read and review in 15 minutes.
356
00:11:31,320 --> 00:11:33,720
But a 5,000 line monolith takes hours,
357
00:11:33,720 --> 00:11:35,680
change management becomes granular.
358
00:11:35,680 --> 00:11:37,760
You update the leave eligibility skill,
359
00:11:37,760 --> 00:11:40,520
and your only risk breaking leave eligibility workflows.
360
00:11:40,520 --> 00:11:42,320
Incident escalation is unaffected.
361
00:11:42,320 --> 00:11:43,840
Vendor onboarding is unaffected.
362
00:11:43,840 --> 00:11:45,480
You can deploy that skill change to production
363
00:11:45,480 --> 00:11:47,160
on a Thursday without nervousness
364
00:11:47,160 --> 00:11:49,040
because the blast radius is defined.
365
00:11:49,040 --> 00:11:51,120
If something goes wrong, you roll back one skill,
366
00:11:51,120 --> 00:11:52,720
not an entire system.
367
00:11:52,720 --> 00:11:54,200
Version history becomes meaningful.
368
00:11:54,200 --> 00:11:56,000
You can see exactly what changed.
369
00:11:56,000 --> 00:11:57,520
When and why?
370
00:11:57,520 --> 00:12:00,120
You can compare versions and understand the delta.
371
00:12:00,120 --> 00:12:01,840
The operational reality is that teams actually
372
00:12:01,840 --> 00:12:03,560
maintain modular systems better.
373
00:12:03,560 --> 00:12:04,560
This isn't anecdotal.
374
00:12:04,560 --> 00:12:06,680
It's how software engineering works at scale.
375
00:12:06,680 --> 00:12:09,400
Micro-Services 1, monoliths lost.
376
00:12:09,400 --> 00:12:12,200
Not because microservices are always faster or smaller
377
00:12:12,200 --> 00:12:13,480
in total lines of code,
378
00:12:13,480 --> 00:12:15,440
but because humans can reason about them.
379
00:12:15,440 --> 00:12:16,760
A team can own a service.
380
00:12:16,760 --> 00:12:18,920
A team can deploy a service independently.
381
00:12:18,920 --> 00:12:20,560
A team can be paged when that service breaks.
382
00:12:20,560 --> 00:12:23,840
You have accountability, clarity, and speed.
383
00:12:23,840 --> 00:12:25,320
Skills work the same way.
384
00:12:25,320 --> 00:12:26,920
The boundaries matter too.
385
00:12:26,920 --> 00:12:28,880
A skill that serves as a specialist.
386
00:12:28,880 --> 00:12:31,680
Narrow expertise called in occasionally is easy to own.
387
00:12:31,680 --> 00:12:32,600
It has one job.
388
00:12:32,600 --> 00:12:34,160
A skill that serves as a playbook,
389
00:12:34,160 --> 00:12:36,440
the known sequence for a recurring situation,
390
00:12:36,440 --> 00:12:38,000
is similarly bounded.
391
00:12:38,000 --> 00:12:41,320
A playbook skill for quarterly reviews has a clear scope.
392
00:12:41,320 --> 00:12:44,760
The steps, the approvals, the outcomes.
393
00:12:44,760 --> 00:12:47,200
A guardrail skill for compliance is explicit.
394
00:12:47,200 --> 00:12:49,320
These are the rules that must never be violated.
395
00:12:49,320 --> 00:12:51,120
Each archetype has a natural boundary.
396
00:12:51,120 --> 00:12:54,000
When you try to combine them, when you throw a reference manual,
397
00:12:54,000 --> 00:12:55,800
a specialist procedure, a playbook,
398
00:12:55,800 --> 00:12:57,680
and a guardrail all into one skill.
399
00:12:57,680 --> 00:13:00,480
You've recreated the monolithic problem at a smaller scale.
400
00:13:00,480 --> 00:13:01,880
The routing becomes ambiguous.
401
00:13:01,880 --> 00:13:03,400
The ownership becomes unclear.
402
00:13:03,400 --> 00:13:05,040
The review surface expands.
403
00:13:05,040 --> 00:13:07,520
And you've defeated the purpose of modular architecture.
404
00:13:07,520 --> 00:13:10,280
So the first order question isn't performance or cost.
405
00:13:10,280 --> 00:13:12,560
Though those follow, its manageability.
406
00:13:12,560 --> 00:13:13,600
Can we own this?
407
00:13:13,600 --> 00:13:14,640
Can we maintain it?
408
00:13:14,640 --> 00:13:16,040
Can we change it safely?
409
00:13:16,040 --> 00:13:18,440
Skills let you answer yes to all three.
410
00:13:18,440 --> 00:13:21,560
The four skill archetypes, not all skills are the same.
411
00:13:21,560 --> 00:13:23,960
And trying to force different types into a single skill
412
00:13:23,960 --> 00:13:26,120
is where most implementations start to break.
413
00:13:26,120 --> 00:13:28,440
There are four distinct patterns, recognizing
414
00:13:28,440 --> 00:13:31,120
which one your building determines whether routing works.
415
00:13:31,120 --> 00:13:33,640
Whether the orchestrator can invoke it at the right moment.
416
00:13:33,640 --> 00:13:35,520
And whether the model can actually follow it.
417
00:13:35,520 --> 00:13:36,880
The first is the reference manual.
418
00:13:36,880 --> 00:13:40,000
This is a skill that teaches the model something it doesn't know.
419
00:13:40,000 --> 00:13:43,240
Your data model, your schema, your business terminology.
420
00:13:43,240 --> 00:13:46,320
The LLM wasn't trained on your internal customer classification
421
00:13:46,320 --> 00:13:48,480
system or your proprietary process names.
422
00:13:48,480 --> 00:13:50,440
So you documented a reference manual skill
423
00:13:50,440 --> 00:13:52,040
is pure knowledge transfer.
424
00:13:52,040 --> 00:13:54,720
It's usually heavy on structure, tables, definitions,
425
00:13:54,720 --> 00:13:57,720
examples, and light on procedure, it says.
426
00:13:57,720 --> 00:14:00,080
Here's the universe of things that exist in our system
427
00:14:00,080 --> 00:14:01,480
and what they mean.
428
00:14:01,480 --> 00:14:04,000
When a user asks a question that requires understanding
429
00:14:04,000 --> 00:14:06,560
your domain, the orchestrator loads this skill.
430
00:14:06,560 --> 00:14:08,120
The model reads the definitions.
431
00:14:08,120 --> 00:14:09,440
And then it can answer accurately.
432
00:14:09,440 --> 00:14:11,920
The reference manual skill doesn't tell the model what to do.
433
00:14:11,920 --> 00:14:13,760
It tells the model what exists.
434
00:14:13,760 --> 00:14:14,960
The second is the specialist.
435
00:14:14,960 --> 00:14:16,760
This is a narrow area of expertise
436
00:14:16,760 --> 00:14:18,960
that the model only occasionally needs.
437
00:14:18,960 --> 00:14:21,480
Think region-specific tax rules applied only
438
00:14:21,480 --> 00:14:23,800
when a user asks about a particular geography
439
00:14:23,800 --> 00:14:27,000
or a specialized approval workflow for high-value orders.
440
00:14:27,000 --> 00:14:29,680
Triggered only when the order amount exceeds a threshold.
441
00:14:29,680 --> 00:14:31,040
The specialist skill is focused.
442
00:14:31,040 --> 00:14:31,880
It has one job.
443
00:14:31,880 --> 00:14:33,360
It's called rarely.
444
00:14:33,360 --> 00:14:35,320
But when it's called, it's called because the situation
445
00:14:35,320 --> 00:14:38,160
is specific and the guidance needs to be precise.
446
00:14:38,160 --> 00:14:39,960
A specialist skill usually contains
447
00:14:39,960 --> 00:14:41,720
decision trees and conditional logic.
448
00:14:41,720 --> 00:14:44,800
If the amount is under 5,000, follow path A.
449
00:14:44,800 --> 00:14:47,480
If it's between 5 and 50,000, follow path B.
450
00:14:47,480 --> 00:14:50,440
If it exceeds 50,000, escalate to this person.
451
00:14:50,440 --> 00:14:53,400
Specialists are easy to root to because their trigger conditions
452
00:14:53,400 --> 00:14:54,160
are clear.
453
00:14:54,160 --> 00:14:55,400
The third is the playbook.
454
00:14:55,400 --> 00:14:57,280
A playbook skill describes a known sequence
455
00:14:57,280 --> 00:14:59,080
for a recurring situation.
456
00:14:59,080 --> 00:15:02,200
On boarding a new customer running a quarterly review cycle,
457
00:15:02,200 --> 00:15:05,200
processing a leave request, a playbook is procedural.
458
00:15:05,200 --> 00:15:06,560
Step one happens.
459
00:15:06,560 --> 00:15:10,480
Then step two, then step three, there are decision points.
460
00:15:10,480 --> 00:15:12,440
But the overall flow is deterministic.
461
00:15:12,440 --> 00:15:14,120
The model's job is to follow the steps,
462
00:15:14,120 --> 00:15:16,200
ask the right questions at each stage,
463
00:15:16,200 --> 00:15:17,880
collect the necessary information,
464
00:15:17,880 --> 00:15:19,320
and move through the sequence.
465
00:15:19,320 --> 00:15:21,200
A playbook skill is narrative in structure.
466
00:15:21,200 --> 00:15:23,840
It reads like instructions because it is instructions.
467
00:15:23,840 --> 00:15:26,440
Most organizational workflows fit this pattern.
468
00:15:26,440 --> 00:15:27,800
The fourth is the guardrail.
469
00:15:27,800 --> 00:15:30,400
A guardrail skill exists to enforce rules that cannot
470
00:15:30,400 --> 00:15:31,160
be violated.
471
00:15:31,160 --> 00:15:33,760
You may not refund an order without going through approval.
472
00:15:33,760 --> 00:15:35,640
You may not grant certain permissions
473
00:15:35,640 --> 00:15:36,960
without audit evidence.
474
00:15:36,960 --> 00:15:39,200
You may not delete records that have legal holds.
475
00:15:39,200 --> 00:15:41,120
A guardrail skill is constraint-based.
476
00:15:41,120 --> 00:15:42,640
It doesn't guide behavior.
477
00:15:42,640 --> 00:15:44,720
It forbids specific behaviors.
478
00:15:44,720 --> 00:15:45,800
It's often negative.
479
00:15:45,800 --> 00:15:48,400
Never do this, rather than positive guidance.
480
00:15:48,400 --> 00:15:50,080
Guardrails are usually brief and explicit
481
00:15:50,080 --> 00:15:52,120
because they're about drawing a hard line.
482
00:15:52,120 --> 00:15:53,360
Not explaining a process.
483
00:15:53,360 --> 00:15:54,440
Here's what matters.
484
00:15:54,440 --> 00:15:57,080
Each archetype has a different triggering condition,
485
00:15:57,080 --> 00:15:59,200
a different structure, and a different relationship
486
00:15:59,200 --> 00:16:00,440
to the model's reasoning.
487
00:16:00,440 --> 00:16:03,160
When the orchestrator evaluates whether to load a skill,
488
00:16:03,160 --> 00:16:06,080
it's matching the user's intent to the skill's scope.
489
00:16:06,080 --> 00:16:07,680
A reference manual skill should load
490
00:16:07,680 --> 00:16:10,360
when the user is asking questions about your data model,
491
00:16:10,360 --> 00:16:12,880
your terminology, or your system structure,
492
00:16:12,880 --> 00:16:16,280
especially skill loads when the triggering condition is met,
493
00:16:16,280 --> 00:16:19,000
like a high-value order or a specific region.
494
00:16:19,000 --> 00:16:21,280
A playbook skill loads when the user wants to initiate
495
00:16:21,280 --> 00:16:23,760
or progress through a known workflow.
496
00:16:23,760 --> 00:16:25,720
A guardrail skill loads when the user is attempting
497
00:16:25,720 --> 00:16:27,080
an action that's restricted.
498
00:16:27,080 --> 00:16:28,240
Now here's where it breaks.
499
00:16:28,240 --> 00:16:30,160
When you mix archetypes in a single skill,
500
00:16:30,160 --> 00:16:32,000
the routing becomes ambiguous.
501
00:16:32,000 --> 00:16:33,320
The description can't be specific
502
00:16:33,320 --> 00:16:35,360
because it's trying to cover multiple patterns.
503
00:16:35,360 --> 00:16:38,360
The name has to be so broad that it matches too many situations.
504
00:16:38,360 --> 00:16:40,880
The orchestrator either loads the skill constantly
505
00:16:40,880 --> 00:16:42,080
or never loads it at all.
506
00:16:42,080 --> 00:16:44,240
And the model's behavior becomes unpredictable.
507
00:16:44,240 --> 00:16:46,560
Is it reading reference material following a procedure
508
00:16:46,560 --> 00:16:47,960
enforcing a constraint?
509
00:16:47,960 --> 00:16:49,960
The skill doesn't have a coherent type.
510
00:16:49,960 --> 00:16:51,920
So the model's reasoning path fragments.
511
00:16:51,920 --> 00:16:53,880
A well-designed skill knows what it is.
512
00:16:53,880 --> 00:16:58,000
Reference manual, specialist, playbook, or guardrail.
513
00:16:58,000 --> 00:17:00,600
Not all four, not even two.
514
00:17:00,600 --> 00:17:02,560
One clear archetype, one clear purpose,
515
00:17:02,560 --> 00:17:06,000
one routing condition that the orchestrator can evaluate precisely.
516
00:17:06,000 --> 00:17:10,560
That clarity is what makes the entire architecture work.
517
00:17:10,560 --> 00:17:12,480
Copilot Studio's skill integration.
518
00:17:12,480 --> 00:17:13,960
This is where theory meets practice.
519
00:17:13,960 --> 00:17:17,160
Copilot Studio implements the agent skills open format directly.
520
00:17:17,160 --> 00:17:19,320
You can author and manage skills within the platform.
521
00:17:19,320 --> 00:17:21,280
No exporting to separate systems.
522
00:17:21,280 --> 00:17:22,760
No learning a different tool set.
523
00:17:22,760 --> 00:17:24,200
The interface is straightforward.
524
00:17:24,200 --> 00:17:26,520
Inside Copilot Studio, there is a skills tab.
525
00:17:26,520 --> 00:17:28,120
From there you have two entry points.
526
00:17:28,120 --> 00:17:29,680
You can create a skill from scratch
527
00:17:29,680 --> 00:17:31,440
or you can upload an existing one.
528
00:17:31,440 --> 00:17:33,880
Creating from scratch gives you a guided workflow.
529
00:17:33,880 --> 00:17:36,680
You provide the name, description, and instructions.
530
00:17:36,680 --> 00:17:39,720
The platform scaffolds the skill.md structure for you.
531
00:17:39,720 --> 00:17:41,520
You fill in the content, you save it,
532
00:17:41,520 --> 00:17:43,520
and the skill is now part of your agent.
533
00:17:43,520 --> 00:17:45,440
Uploading means you already have a skill.
534
00:17:45,440 --> 00:17:46,800
Maybe you authored it elsewhere.
535
00:17:46,800 --> 00:17:49,120
Maybe you downloaded it from a community registry.
536
00:17:49,120 --> 00:17:51,200
Either way, once it is in Copilot Studio,
537
00:17:51,200 --> 00:17:52,640
the platform manages it.
538
00:17:52,640 --> 00:17:55,080
But skills are not just marked on file sitting alone.
539
00:17:55,080 --> 00:17:56,600
They are bundles.
540
00:17:56,600 --> 00:17:59,640
A skill in Copilot Studio can carry bundled resources
541
00:17:59,640 --> 00:18:01,720
along with the skill.md file.
542
00:18:01,720 --> 00:18:04,640
You can include scripts like Python, Shell, or reference code
543
00:18:04,640 --> 00:18:06,840
that the skill uses during execution.
544
00:18:06,840 --> 00:18:09,120
You can bundle references like documentation files,
545
00:18:09,120 --> 00:18:10,520
schemas, and examples.
546
00:18:10,520 --> 00:18:13,160
Anything the agent might read to understand the context
547
00:18:13,160 --> 00:18:14,240
goes in the bundle.
548
00:18:14,240 --> 00:18:17,200
You can include assets like templates, configuration files,
549
00:18:17,200 --> 00:18:18,400
and sample data.
550
00:18:18,400 --> 00:18:20,560
All of this travels together as a single unit.
551
00:18:20,560 --> 00:18:21,600
Think of it like a folder.
552
00:18:21,600 --> 00:18:24,320
The skill.md is the manifest in the instructions.
553
00:18:24,320 --> 00:18:27,200
The script's subdirectory holds your executable code.
554
00:18:27,200 --> 00:18:29,520
References contain the documentation the model reads.
555
00:18:29,520 --> 00:18:31,960
Assets hold your data structures and templates.
556
00:18:31,960 --> 00:18:34,240
When the skill loads, the entire bundle comes with it.
557
00:18:34,240 --> 00:18:36,360
When the skill is versioned, all of these files
558
00:18:36,360 --> 00:18:37,640
are versioned together.
559
00:18:37,640 --> 00:18:39,480
When the skill moves, everything moves.
560
00:18:39,480 --> 00:18:41,520
This bundling approach matters for application
561
00:18:41,520 --> 00:18:42,920
lifecycle management.
562
00:18:42,920 --> 00:18:45,040
Copilot Studio is built on the Power Platform,
563
00:18:45,040 --> 00:18:46,800
which has a mature solution model.
564
00:18:46,800 --> 00:18:49,560
Skills can be packaged into Power Platform Solutions.
565
00:18:49,560 --> 00:18:51,800
That means the skill is not just a loose artifact
566
00:18:51,800 --> 00:18:53,000
sitting in your agent.
567
00:18:53,000 --> 00:18:55,440
It is a managed component that moves through your environment
568
00:18:55,440 --> 00:18:56,240
strategy.
569
00:18:56,240 --> 00:18:58,400
You develop a skill in your development environment.
570
00:18:58,400 --> 00:18:59,320
You test it.
571
00:18:59,320 --> 00:19:01,840
You promote it to a test environment for validation.
572
00:19:01,840 --> 00:19:03,200
Then you promote it to production.
573
00:19:03,200 --> 00:19:05,280
At each stage, the entire bundle moves together
574
00:19:05,280 --> 00:19:06,480
as a versioned unit.
575
00:19:06,480 --> 00:19:08,320
Your pipelines can track skill changes.
576
00:19:08,320 --> 00:19:10,160
Your environment separation is preserved.
577
00:19:10,160 --> 00:19:12,000
Your agent moves with its skills intact.
578
00:19:12,000 --> 00:19:13,600
This is solution-aware ALM.
579
00:19:13,600 --> 00:19:16,200
The skills are not agent-scoped in isolation.
580
00:19:16,200 --> 00:19:18,400
They travel as part of your solution package.
581
00:19:18,400 --> 00:19:20,840
You can update a skill in development, test the change,
582
00:19:20,840 --> 00:19:23,000
and promote it to production without touching other skills
583
00:19:23,000 --> 00:19:24,200
or the agent itself.
584
00:19:24,200 --> 00:19:26,840
Each component has its own version history, its own change
585
00:19:26,840 --> 00:19:29,240
log, and its own deployment cycle.
586
00:19:29,240 --> 00:19:32,000
The soft-pointing pattern is equally important for integration.
587
00:19:32,000 --> 00:19:34,600
A skill can reference agent tools without hard binding
588
00:19:34,600 --> 00:19:35,280
to them.
589
00:19:35,280 --> 00:19:37,680
When a skill says, "Call the approval action,"
590
00:19:37,680 --> 00:19:40,600
it is not declaring that action as a required dependency.
591
00:19:40,600 --> 00:19:42,800
If the action exists in the agent's toolkit,
592
00:19:42,800 --> 00:19:44,160
the skill can invoke it.
593
00:19:44,160 --> 00:19:46,080
If it does not, the instruction can acknowledge
594
00:19:46,080 --> 00:19:47,720
the limitation and work around it.
595
00:19:47,720 --> 00:19:49,080
The agent adapts.
596
00:19:49,080 --> 00:19:51,440
This matters because it means skills can be
597
00:19:51,440 --> 00:19:54,600
authored without assuming a specific agent configuration.
598
00:19:54,600 --> 00:19:56,440
The same skill can work across agents
599
00:19:56,440 --> 00:19:58,280
that have slightly different tool sets
600
00:19:58,280 --> 00:20:00,800
as long as the core capabilities are present.
601
00:20:00,800 --> 00:20:04,320
Soft-pointing extends to flows, connectors, and MCP servers.
602
00:20:04,320 --> 00:20:06,160
A skill can reference a power-automate flow
603
00:20:06,160 --> 00:20:07,360
without binding to it.
604
00:20:07,360 --> 00:20:08,200
The reference is loose.
605
00:20:08,200 --> 00:20:10,680
The model knows the tool exists and tries to use it,
606
00:20:10,680 --> 00:20:12,920
but it can adapt if conditions do not allow.
607
00:20:12,920 --> 00:20:15,480
This flexibility is what enables skills to be reusable
608
00:20:15,480 --> 00:20:18,080
across different environments and agent configurations.
609
00:20:18,080 --> 00:20:20,120
There is one current limitation worth noting.
610
00:20:20,120 --> 00:20:22,360
Skills in Copilot Studio are agent-scoped.
611
00:20:22,360 --> 00:20:24,240
A skill belongs to a specific agent.
612
00:20:24,240 --> 00:20:26,200
You cannot create a tenant-wide skills library
613
00:20:26,200 --> 00:20:28,320
and have all agents consume from it automatically.
614
00:20:28,320 --> 00:20:29,760
That is the roadmap direction.
615
00:20:29,760 --> 00:20:30,880
Shared catalogs.
616
00:20:30,880 --> 00:20:32,320
Cross-product reuse.
617
00:20:32,320 --> 00:20:34,400
A true enterprise skill library.
618
00:20:34,400 --> 00:20:37,400
But today, skills live within the agent they were created for.
619
00:20:37,400 --> 00:20:40,160
If you want to reuse a skill across multiple agents,
620
00:20:40,160 --> 00:20:42,160
you have to import it separately into each one.
621
00:20:42,160 --> 00:20:44,360
That is changing, but it is the current constraint.
622
00:20:44,360 --> 00:20:46,080
The data versus MCP bridge.
623
00:20:46,080 --> 00:20:47,800
Up until now, we have talked about skills
624
00:20:47,800 --> 00:20:49,600
as agent-scoped artifacts.
625
00:20:49,600 --> 00:20:51,320
They live inside a particular agent
626
00:20:51,320 --> 00:20:53,360
and move with it through environments.
627
00:20:53,360 --> 00:20:55,560
But at enterprise scale, this creates a problem.
628
00:20:55,560 --> 00:20:57,720
If you have 50 agents across your organization,
629
00:20:57,720 --> 00:20:59,960
do you replicate the same skill 50 times?
630
00:20:59,960 --> 00:21:01,760
Do you maintain 50 copies of your vendor
631
00:21:01,760 --> 00:21:02,880
on boarding procedure?
632
00:21:02,880 --> 00:21:03,960
That is not scalable.
633
00:21:03,960 --> 00:21:05,000
That is not maintainable.
634
00:21:05,000 --> 00:21:07,440
It is the opposite of what you wanted when you move to skills
635
00:21:07,440 --> 00:21:08,480
in the first place.
636
00:21:08,480 --> 00:21:11,680
This is where the model context protocol enters the architecture.
637
00:21:11,680 --> 00:21:16,040
MCP is an emerging standard that defines how AI agents access tools, data,
638
00:21:16,040 --> 00:21:17,720
and context from external servers.
639
00:21:17,720 --> 00:21:19,640
Multiple vendors are converging on it.
640
00:21:19,640 --> 00:21:22,680
In Copilot Studio, MCP serves a specific purpose.
641
00:21:22,680 --> 00:21:25,040
It lets agents reach out to a centralized server
642
00:21:25,040 --> 00:21:26,880
to discover and invoke skills.
643
00:21:26,880 --> 00:21:28,880
That centralized server is data-verse.
644
00:21:28,880 --> 00:21:32,200
Data-verse is the foundation of Power Apps and Dynamics 365.
645
00:21:32,200 --> 00:21:34,840
Traditionally, it stores operational business data.
646
00:21:34,840 --> 00:21:38,320
Customers orders cases, the transactional entities that run your business.
647
00:21:38,320 --> 00:21:40,840
But in 2026, its role is expanding.
648
00:21:40,840 --> 00:21:42,960
Data-vers is becoming the system of record
649
00:21:42,960 --> 00:21:44,920
for business procedures themselves.
650
00:21:44,920 --> 00:21:47,360
Not just what happened, but how things should happen.
651
00:21:47,360 --> 00:21:52,160
Business skills stored in data-verse are procedures, policies, and playbooks stored as data.
652
00:21:52,160 --> 00:21:56,280
When a vendor on boarding skill is authored, it no longer lives inside a single agent.
653
00:21:56,280 --> 00:21:59,920
It lives in data-verse, indexed, and versioned as a first-class asset.
654
00:21:59,920 --> 00:22:02,520
When a user asks an agent about vendor onboarding,
655
00:22:02,520 --> 00:22:07,000
that agent connects to the data-verse MCP endpoint and queries available skills.
656
00:22:07,000 --> 00:22:09,000
The orchestrator evaluates the user's intent
657
00:22:09,000 --> 00:22:11,360
against skill descriptions stored in data-verse.
658
00:22:11,360 --> 00:22:14,600
On-match, the agent retrieves the skill and loads it into context.
659
00:22:14,600 --> 00:22:16,120
The endpoint is straightforward.
660
00:22:16,120 --> 00:22:19,400
Every data-verse environment has this specific URL structure.
661
00:22:19,400 --> 00:22:22,680
Any agent in the tenant can connect or auth secures the connection.
662
00:22:22,680 --> 00:22:25,840
When an agent connects, it acts as the authenticated user.
663
00:22:25,840 --> 00:22:27,720
Data-vers enforces role-based access.
664
00:22:27,720 --> 00:22:30,120
If a user lacks permission to access certain data,
665
00:22:30,120 --> 00:22:31,640
the agent does not retrieve it.
666
00:22:31,640 --> 00:22:34,040
Security boundaries are preserved transparently.
667
00:22:34,040 --> 00:22:36,320
Cross-environment access becomes possible.
668
00:22:36,320 --> 00:22:39,360
You have separate development and production data-verse environments,
669
00:22:39,360 --> 00:22:42,120
development host, draft skills, and experimental procedures.
670
00:22:42,120 --> 00:22:44,600
Production hosts only certified approved ones.
671
00:22:44,600 --> 00:22:47,760
A development agent connects to development data-verse for testing.
672
00:22:47,760 --> 00:22:50,880
A production agent connects to production data-verse for live use.
673
00:22:50,880 --> 00:22:53,160
The same MCP protocol applies in both.
674
00:22:53,160 --> 00:22:56,440
You do not have different connection patterns or access methods.
675
00:22:56,440 --> 00:22:58,520
It is unified and environment-aware.
676
00:22:58,520 --> 00:23:01,160
The centralization is where governance gains real power.
677
00:23:01,160 --> 00:23:04,040
In an agent-scoped model, a skill is a local artifact
678
00:23:04,040 --> 00:23:05,480
versioned within that agent.
679
00:23:05,480 --> 00:23:09,240
It is reviewed once and it lives or dies tied to that agent's deployment.
680
00:23:09,240 --> 00:23:12,360
But when a skill lives in data-verse, it becomes an enterprise asset.
681
00:23:12,360 --> 00:23:14,680
It is versioned in the native system of data-verse.
682
00:23:14,680 --> 00:23:15,680
It is owned by a team.
683
00:23:15,680 --> 00:23:18,560
It is reviewed once and reused across many agents.
684
00:23:18,560 --> 00:23:20,320
When you update the skill in data-verse,
685
00:23:20,320 --> 00:23:22,960
all consuming agents see the update immediately.
686
00:23:22,960 --> 00:23:23,960
You update once.
687
00:23:23,960 --> 00:23:25,880
50 agents benefit.
688
00:23:25,880 --> 00:23:27,760
The audit trail becomes comprehensive.
689
00:23:27,760 --> 00:23:30,680
Data-verse records who created the skill and when they created it.
690
00:23:30,680 --> 00:23:33,560
It tracks who modified it and when each change occurred.
691
00:23:33,560 --> 00:23:36,560
That trail is queryable, reportable and exportable.
692
00:23:36,560 --> 00:23:40,520
For compliance audits and change management reviews, you have a complete record.
693
00:23:40,520 --> 00:23:42,400
Skills are no longer forensic blind spots.
694
00:23:42,400 --> 00:23:44,320
They are transparent, traced assets.
695
00:23:44,320 --> 00:23:48,600
Skills become organizational intelligence rather than embedded instructions.
696
00:23:48,600 --> 00:23:50,720
They are managed like critical business assets.
697
00:23:50,720 --> 00:23:52,400
They can be evaluated and certified.
698
00:23:52,400 --> 00:23:54,160
They can be assigned clear ownership.
699
00:23:54,160 --> 00:23:57,640
You can mark them as experimental, approved or deprecated.
700
00:23:57,640 --> 00:24:00,520
You can tag them with compliance categories or domain ownership.
701
00:24:00,520 --> 00:24:02,320
The architecture shifts fundamentally.
702
00:24:02,320 --> 00:24:04,360
Instead of agents containing their own knowledge,
703
00:24:04,360 --> 00:24:06,760
agents discover knowledge from a central system.
704
00:24:06,760 --> 00:24:08,360
That shift enables enterprise scale
705
00:24:08,360 --> 00:24:11,200
without sacrificing control or auditability.
706
00:24:11,200 --> 00:24:14,320
A skill created in data-verse becomes the single source of truth.
707
00:24:14,320 --> 00:24:15,760
Multiple agents reference it.
708
00:24:15,760 --> 00:24:16,880
Multiple users benefit.
709
00:24:16,880 --> 00:24:18,880
One governance surface owns it all.
710
00:24:18,880 --> 00:24:20,080
This is the leverage point.
711
00:24:20,080 --> 00:24:23,120
This is where skills move from a feature to a structural principle.
712
00:24:23,120 --> 00:24:26,400
It is the foundation of how enterprise AI operates.
713
00:24:26,400 --> 00:24:28,320
The routing problem solved.
714
00:24:28,320 --> 00:24:31,120
The cleanest theory collapses the moment reality arrives.
715
00:24:31,120 --> 00:24:32,840
You implement skills, you write descriptions,
716
00:24:32,840 --> 00:24:35,800
you deploy your agent, and then something breaks.
717
00:24:35,800 --> 00:24:38,760
A skill fires when it shouldn't, or it never fires at all.
718
00:24:38,760 --> 00:24:41,200
The model invokes the wrong skill for the scenario.
719
00:24:41,200 --> 00:24:44,360
Or it loads multiple conflicting skills simultaneously.
720
00:24:44,360 --> 00:24:45,640
The routing problem is real.
721
00:24:45,640 --> 00:24:47,240
In fact, it's the most common failure mode
722
00:24:47,240 --> 00:24:49,000
in early skill implementations.
723
00:24:49,000 --> 00:24:50,200
But here's the problem.
724
00:24:50,200 --> 00:24:51,760
When a description is vague,
725
00:24:51,760 --> 00:24:54,480
the orchestrator can't make a reliable decision.
726
00:24:54,480 --> 00:24:56,560
Consider a skill description that says,
727
00:24:56,560 --> 00:24:58,840
use this for financial questions.
728
00:24:58,840 --> 00:25:02,240
Now a user asks about the revenue forecast for next quarter.
729
00:25:02,240 --> 00:25:04,520
That matches financial questions, load the skill.
730
00:25:04,520 --> 00:25:07,040
But that same description also matches questions about
731
00:25:07,040 --> 00:25:09,520
approving an expense or actual spend from last month
732
00:25:09,520 --> 00:25:11,160
or how to request a budget increase.
733
00:25:11,160 --> 00:25:12,760
All of these are financial.
734
00:25:12,760 --> 00:25:14,480
All of them treat are the same skill.
735
00:25:14,480 --> 00:25:17,200
But in reality, they are entirely different workflows.
736
00:25:17,200 --> 00:25:19,080
They have different tools, different constraints,
737
00:25:19,080 --> 00:25:20,080
and different outcomes.
738
00:25:20,080 --> 00:25:21,640
The skill loads when it shouldn't,
739
00:25:21,640 --> 00:25:23,360
or it loads and the model struggles
740
00:25:23,360 --> 00:25:25,280
because the instructions assume a specific type
741
00:25:25,280 --> 00:25:28,600
of financial question that doesn't match the user's intent.
742
00:25:28,600 --> 00:25:30,080
On the other extreme, a description
743
00:25:30,080 --> 00:25:31,720
that's too narrow never triggers.
744
00:25:31,720 --> 00:25:34,160
If you tell the agent to use a skill only for processing
745
00:25:34,160 --> 00:25:37,160
Q4 vendor reimbursements over $5,000 submitted
746
00:25:37,160 --> 00:25:39,200
after a specific budget freeze, it might
747
00:25:39,200 --> 00:25:41,200
match three scenarios per year.
748
00:25:41,200 --> 00:25:42,920
Users never get the benefit because they
749
00:25:42,920 --> 00:25:45,160
don't phrase their requests in those exact terms.
750
00:25:45,160 --> 00:25:48,000
The skill sits dormant, the routing fails silently.
751
00:25:48,000 --> 00:25:49,680
The distinction between routing metadata
752
00:25:49,680 --> 00:25:51,800
and documentation is critical here.
753
00:25:51,800 --> 00:25:54,320
Your skills instructions, the step-by-step procedures,
754
00:25:54,320 --> 00:25:55,600
those are documentation.
755
00:25:55,600 --> 00:25:57,360
They explain how to execute the workflow
756
00:25:57,360 --> 00:25:58,840
to a human reading the file.
757
00:25:58,840 --> 00:25:59,520
They can be long.
758
00:25:59,520 --> 00:26:01,360
They can include caveats and examples.
759
00:26:01,360 --> 00:26:03,000
The name and description are different.
760
00:26:03,000 --> 00:26:04,320
They are signals.
761
00:26:04,320 --> 00:26:06,080
They are the data the orchestrator uses
762
00:26:06,080 --> 00:26:07,600
to make a binary decision.
763
00:26:07,600 --> 00:26:09,160
Load this skill or don't.
764
00:26:09,160 --> 00:26:12,200
If the description is ambiguous, the orchestrator has to guess.
765
00:26:12,200 --> 00:26:13,720
If it's too narrow, it never matches.
766
00:26:13,720 --> 00:26:15,240
Precision here isn't optional.
767
00:26:15,240 --> 00:26:17,400
It determines whether the routing actually works.
768
00:26:17,400 --> 00:26:20,200
So how does the orchestrator actually select a skill?
769
00:26:20,200 --> 00:26:22,560
It reads the user's request and extracts the intent.
770
00:26:22,560 --> 00:26:24,920
It compares that intent against the name and description
771
00:26:24,920 --> 00:26:27,400
of every available skill and scores the matches.
772
00:26:27,400 --> 00:26:29,600
The skill with the highest relevance score loads.
773
00:26:29,600 --> 00:26:31,920
If the score is below a threshold, no skill loads,
774
00:26:31,920 --> 00:26:34,080
and the agent reasons from its baseline instructions.
775
00:26:34,080 --> 00:26:35,920
This is where the precision rule applies.
776
00:26:35,920 --> 00:26:37,640
If two reasonable makers would disagree
777
00:26:37,640 --> 00:26:40,320
about whether a skill should load for a particular request,
778
00:26:40,320 --> 00:26:42,400
the description isn't specific enough.
779
00:26:42,400 --> 00:26:45,200
You need to revise it until the boundary is unambiguous.
780
00:26:45,200 --> 00:26:47,200
The reasoning view is your main debugging surface
781
00:26:47,200 --> 00:26:48,240
for this problem.
782
00:26:48,240 --> 00:26:50,880
Inside Copilot Studio, you can open the reasoning view
783
00:26:50,880 --> 00:26:52,280
to see exactly what happened.
784
00:26:52,280 --> 00:26:54,920
You can see which skill loaded, why it was chosen,
785
00:26:54,920 --> 00:26:56,040
and what the matching score was.
786
00:26:56,040 --> 00:26:58,400
If the wrong skill loaded, the reasoning view shows you
787
00:26:58,400 --> 00:27:00,640
that the description didn't provide enough distinction
788
00:27:00,640 --> 00:27:02,880
or the name overlapped with another skill.
789
00:27:02,880 --> 00:27:04,760
You can watch the model's actual reasoning path.
790
00:27:04,760 --> 00:27:06,360
You see the choice and the justification.
791
00:27:06,360 --> 00:27:08,400
From there, you can refine the description,
792
00:27:08,400 --> 00:27:09,440
make it more specific.
793
00:27:09,440 --> 00:27:12,920
At exclusion language like, do not use for payroll questions.
794
00:27:12,920 --> 00:27:15,400
Clarify the trigger condition, narrow the scope.
795
00:27:15,400 --> 00:27:16,200
Itterate.
796
00:27:16,200 --> 00:27:18,480
Two broad causes constant unwanted firing.
797
00:27:18,480 --> 00:27:20,320
Two narrow causes routing failure.
798
00:27:20,320 --> 00:27:21,640
The balance point is precision.
799
00:27:21,640 --> 00:27:23,640
This is solvable and solved correctly.
800
00:27:23,640 --> 00:27:24,600
It's invisible.
801
00:27:24,600 --> 00:27:26,400
The skill loads exactly when it should.
802
00:27:26,400 --> 00:27:27,880
The user doesn't think about routing.
803
00:27:27,880 --> 00:27:30,280
They ask their question, the right expertise loads,
804
00:27:30,280 --> 00:27:32,280
and execution proceeds smoothly.
805
00:27:32,280 --> 00:27:33,560
But get the descriptions wrong
806
00:27:33,560 --> 00:27:35,880
and the entire architecture falls apart.
807
00:27:35,880 --> 00:27:38,520
When to use instructions versus skills?
808
00:27:38,520 --> 00:27:41,120
Here's the practical question every architect faces.
809
00:27:41,120 --> 00:27:42,680
Where does this guidance live?
810
00:27:42,680 --> 00:27:44,160
Does it go in the instructions?
811
00:27:44,160 --> 00:27:46,240
Or do I extract it into a skill?
812
00:27:46,240 --> 00:27:48,160
The answer hinges on a single question.
813
00:27:48,160 --> 00:27:50,040
Is this rule true in every conversation?
814
00:27:50,040 --> 00:27:52,000
If yes, it belongs in instructions.
815
00:27:52,000 --> 00:27:53,280
If no, it belongs in a skill.
816
00:27:53,280 --> 00:27:54,680
That's the decision tree.
817
00:27:54,680 --> 00:27:56,280
Instructions are the always on layer.
818
00:27:56,280 --> 00:27:57,600
They're loaded before any skill
819
00:27:57,600 --> 00:27:59,240
and before the user says anything.
820
00:27:59,240 --> 00:28:01,280
Instructions are what you want the agent to be,
821
00:28:01,280 --> 00:28:04,080
regardless of the scenario, your tone, your identity,
822
00:28:04,080 --> 00:28:05,320
the way you speak.
823
00:28:05,320 --> 00:28:08,440
You are helpful, direct, and professional is an instruction.
824
00:28:08,440 --> 00:28:10,560
It applies when handling leave requests
825
00:28:10,560 --> 00:28:13,080
and it applies when processing expense approvals.
826
00:28:13,080 --> 00:28:13,960
It's constant.
827
00:28:13,960 --> 00:28:15,720
It belongs in the instruction layer.
828
00:28:15,720 --> 00:28:17,360
Same with roll.
829
00:28:17,360 --> 00:28:19,680
You are an HR assistant sets your identity.
830
00:28:19,680 --> 00:28:21,440
That doesn't change between conversations.
831
00:28:21,440 --> 00:28:23,240
Universal guardrails belong here too.
832
00:28:23,240 --> 00:28:26,280
You might tell the agent to never promise legally binding outcomes
833
00:28:26,280 --> 00:28:29,040
or to always protect personal data according to policy.
834
00:28:29,040 --> 00:28:30,440
These rules apply universally.
835
00:28:30,440 --> 00:28:31,400
They're not situational.
836
00:28:31,400 --> 00:28:34,240
A leave eligibility skill doesn't need to restate them
837
00:28:34,240 --> 00:28:36,480
because the base instructions already hold them.
838
00:28:36,480 --> 00:28:37,840
The skill can assume they're true
839
00:28:37,840 --> 00:28:39,880
and focus on the specifics of leave.
840
00:28:39,880 --> 00:28:41,360
This is the manageability payoff.
841
00:28:41,360 --> 00:28:43,320
Your instructions stay lean because they're not trying
842
00:28:43,320 --> 00:28:45,760
to encode every procedure and every edge case.
843
00:28:45,760 --> 00:28:47,000
They're the common baseline.
844
00:28:47,000 --> 00:28:49,000
Everything situational lives elsewhere.
845
00:28:49,000 --> 00:28:52,240
Now flip the question, is this true only in specific scenarios?
846
00:28:52,240 --> 00:28:54,280
Situational guidance belongs in skills.
847
00:28:54,280 --> 00:28:56,480
The step-by-step procedure for processing a vendor refund
848
00:28:56,480 --> 00:28:58,240
above a certain threshold is situational.
849
00:28:58,240 --> 00:28:59,800
It applies to that specific scenario
850
00:28:59,800 --> 00:29:02,280
but it doesn't apply when processing employee reimbursements
851
00:29:02,280 --> 00:29:03,320
or customer refunds.
852
00:29:03,320 --> 00:29:05,880
It doesn't apply most of the time, so it lives in a skill.
853
00:29:05,880 --> 00:29:08,920
When a user asks about vendor refunds, the skill loads.
854
00:29:08,920 --> 00:29:10,200
When they ask about something else,
855
00:29:10,200 --> 00:29:11,680
the skill stays unloaded.
856
00:29:11,680 --> 00:29:13,320
The rules for approving a leave request
857
00:29:13,320 --> 00:29:15,520
during a blackout period are situational.
858
00:29:15,520 --> 00:29:16,720
They only matter during blackout
859
00:29:16,720 --> 00:29:18,120
and only for leave requests.
860
00:29:18,120 --> 00:29:18,800
Skill.
861
00:29:18,800 --> 00:29:20,240
The checklist for high-value contracts
862
00:29:20,240 --> 00:29:22,760
over $2 million with specific legal review requirements
863
00:29:22,760 --> 00:29:23,760
is situational.
864
00:29:23,760 --> 00:29:24,560
Skill.
865
00:29:24,560 --> 00:29:26,400
The difference is context dependency.
866
00:29:26,400 --> 00:29:28,080
Always true rules live in instructions.
867
00:29:28,080 --> 00:29:30,000
Context dependent rules live in skills,
868
00:29:30,000 --> 00:29:31,200
but here's the subtlety.
869
00:29:31,200 --> 00:29:33,880
Some guidance feels universal because it's complicated
870
00:29:33,880 --> 00:29:35,680
and you want the model to have it available.
871
00:29:35,680 --> 00:29:36,640
Resist that impulse.
872
00:29:36,640 --> 00:29:38,480
Complicated doesn't mean always on.
873
00:29:38,480 --> 00:29:41,720
Ask yourself if the user encounters this in every conversation.
874
00:29:41,720 --> 00:29:43,680
If the answer is no, it's situational.
875
00:29:43,680 --> 00:29:45,160
Extract it into a skill.
876
00:29:45,160 --> 00:29:46,600
Let's look at a concrete example.
877
00:29:46,600 --> 00:29:48,560
An organization builds an HR agent.
878
00:29:48,560 --> 00:29:51,080
The initial approach is to dump everything into the instructions,
879
00:29:51,080 --> 00:29:54,080
leave policy, salary questions, benefits enrollment,
880
00:29:54,080 --> 00:29:56,840
performance reviews, and compensation structure.
881
00:29:56,840 --> 00:29:59,120
They add payroll tax treatment, holiday schedules,
882
00:29:59,120 --> 00:30:01,160
remote work policies, and disability leave,
883
00:30:01,160 --> 00:30:03,440
all in one instruction file, thousands of lines.
884
00:30:03,440 --> 00:30:04,480
The instructions are so bloated
885
00:30:04,480 --> 00:30:06,960
that the model has to process all of it for every single turn.
886
00:30:06,960 --> 00:30:09,040
Most of it is irrelevant to most conversations.
887
00:30:09,040 --> 00:30:12,280
The alternative approach is to keep instructions minimal.
888
00:30:12,280 --> 00:30:14,600
Identity, you are the HR assistant.
889
00:30:14,600 --> 00:30:16,920
Tone, professional, empathetic, clear.
890
00:30:16,920 --> 00:30:18,280
Universal guardrails.
891
00:30:18,280 --> 00:30:20,320
All salary information is confidential.
892
00:30:20,320 --> 00:30:23,480
Never promise benefits decisions without HR review.
893
00:30:23,480 --> 00:30:24,600
That's the instruction layer.
894
00:30:24,600 --> 00:30:26,480
It's a hundred lines maximum.
895
00:30:26,480 --> 00:30:28,120
Now create three skills.
896
00:30:28,120 --> 00:30:30,840
One for leave eligibility, covering a cruel rules
897
00:30:30,840 --> 00:30:32,080
and blackout periods.
898
00:30:32,080 --> 00:30:35,320
One for compensation, covering salary grades and review cycles.
899
00:30:35,320 --> 00:30:38,240
One for enrollment, covering benefits and retirement plans.
900
00:30:38,240 --> 00:30:41,760
When someone asks about their PTO balance, the leave skill loads.
901
00:30:41,760 --> 00:30:43,760
The model has the specific rules for PTO,
902
00:30:43,760 --> 00:30:45,760
a cruel and company specific policies.
903
00:30:45,760 --> 00:30:47,240
So it answers with precision.
904
00:30:47,240 --> 00:30:49,960
When someone asks a different question, a different skill loads.
905
00:30:49,960 --> 00:30:51,320
The instructions are unchanged.
906
00:30:51,320 --> 00:30:53,640
The model's identity and values are consistent.
907
00:30:53,640 --> 00:30:55,360
But the procedural guidance is modular.
908
00:30:55,360 --> 00:30:57,120
The leave team owns the leave skill
909
00:30:57,120 --> 00:30:59,880
and the compensation team owns the compensation skill.
910
00:30:59,880 --> 00:31:02,560
Each can update their domain without touching the other.
911
00:31:02,560 --> 00:31:04,720
If leave policies change, you update one skill,
912
00:31:04,720 --> 00:31:06,280
not a massive instruction file.
913
00:31:06,280 --> 00:31:08,240
This distinction prevents context saturation.
914
00:31:08,240 --> 00:31:09,400
It keeps instructions lean.
915
00:31:09,400 --> 00:31:10,480
It distributes ownership.
916
00:31:10,480 --> 00:31:12,280
It makes the system maintainable at scale.
917
00:31:12,280 --> 00:31:13,480
The decision is simple.
918
00:31:13,480 --> 00:31:17,040
Universal, instructions, situational, skills.
919
00:31:17,040 --> 00:31:18,520
Everything follows from that.
920
00:31:18,520 --> 00:31:20,440
The skill versus new agent decision.
921
00:31:20,440 --> 00:31:22,840
So when does the skill actually become a separate agent?
922
00:31:22,840 --> 00:31:24,160
This is the inverse question.
923
00:31:24,160 --> 00:31:26,680
We've established when to pull guidance out of instructions
924
00:31:26,680 --> 00:31:27,840
and into a skill.
925
00:31:27,840 --> 00:31:28,840
Now comes the harder part.
926
00:31:28,840 --> 00:31:29,760
You've built a skill.
927
00:31:29,760 --> 00:31:30,400
It's working.
928
00:31:30,400 --> 00:31:32,280
Teams are using it, but now you're wondering
929
00:31:32,280 --> 00:31:33,920
if it's grown so large that it should just
930
00:31:33,920 --> 00:31:35,520
be its own standalone agent.
931
00:31:35,520 --> 00:31:36,840
The answer isn't about size.
932
00:31:36,840 --> 00:31:38,240
A skill can be comprehensive.
933
00:31:38,240 --> 00:31:39,880
It can have hundreds of lines of logic.
934
00:31:39,880 --> 00:31:42,440
It can bundle scripts, templates, and reference materials
935
00:31:42,440 --> 00:31:43,520
into one package.
936
00:31:43,520 --> 00:31:45,720
Size alone doesn't determine the boundary.
937
00:31:45,720 --> 00:31:48,760
The real distinction comes down to audience and knowledge domain.
938
00:31:48,760 --> 00:31:50,520
Think of it as an audience test.
939
00:31:50,520 --> 00:31:53,240
Does this skill serve the same users as the parent agent?
940
00:31:53,240 --> 00:31:54,800
Does it share the same knowledge boundary?
941
00:31:54,800 --> 00:31:57,240
When you have an HR agent, a leave eligibility skill
942
00:31:57,240 --> 00:31:59,840
serves HR users asking HR questions.
943
00:31:59,840 --> 00:32:01,360
The knowledge domain is consistent.
944
00:32:01,360 --> 00:32:03,240
The same people interact with leave questions,
945
00:32:03,240 --> 00:32:05,400
compensation questions, and benefits questions.
946
00:32:05,400 --> 00:32:06,360
It's all HR.
947
00:32:06,360 --> 00:32:07,960
A single agent with multiple skills
948
00:32:07,960 --> 00:32:10,560
makes sense here because the user population is unified
949
00:32:10,560 --> 00:32:12,120
and the domain is coherent.
950
00:32:12,120 --> 00:32:13,640
But if you find yourself building a skill
951
00:32:13,640 --> 00:32:15,160
that serves a completely different group,
952
00:32:15,160 --> 00:32:16,000
that's a signal.
953
00:32:16,000 --> 00:32:18,480
Or if it serves the same users, but for an entirely different
954
00:32:18,480 --> 00:32:20,200
business domain, that's also a signal.
955
00:32:20,200 --> 00:32:22,920
An IT agent handles password resets, access provisioning,
956
00:32:22,920 --> 00:32:24,000
and software requests.
957
00:32:24,000 --> 00:32:25,560
These are all IT operations.
958
00:32:25,560 --> 00:32:26,640
They serve IT users.
959
00:32:26,640 --> 00:32:28,200
One agent with multiple skills works
960
00:32:28,200 --> 00:32:30,240
because the audience and the domain align.
961
00:32:30,240 --> 00:32:31,760
Now consider a different scenario.
962
00:32:31,760 --> 00:32:32,840
You have an IT agent.
963
00:32:32,840 --> 00:32:34,760
You're building a skill for data governance.
964
00:32:34,760 --> 00:32:38,000
This covers policies about PII handling, data classification,
965
00:32:38,000 --> 00:32:39,120
and retention rules.
966
00:32:39,120 --> 00:32:40,920
That skill serves IT staff sure.
967
00:32:40,920 --> 00:32:43,440
But it also serves business analysts, project managers,
968
00:32:43,440 --> 00:32:44,600
and compliance teams.
969
00:32:44,600 --> 00:32:47,040
The knowledge domain isn't IT operations anymore.
970
00:32:47,040 --> 00:32:48,160
It's data governance.
971
00:32:48,160 --> 00:32:51,080
The user population extends far beyond the IT desk.
972
00:32:51,080 --> 00:32:53,400
The semantic boundary is fundamentally different.
973
00:32:53,400 --> 00:32:55,800
At that point, a separate data governance agent
974
00:32:55,800 --> 00:32:56,880
makes more sense.
975
00:32:56,880 --> 00:32:58,600
Different users, different expertise,
976
00:32:58,600 --> 00:33:00,960
different knowledge boundary.
977
00:33:00,960 --> 00:33:03,080
The toolset test adds another dimension.
978
00:33:03,080 --> 00:33:05,080
Research shows that accuracy can degrade
979
00:33:05,080 --> 00:33:07,280
as an agent's available toolset grows.
980
00:33:07,280 --> 00:33:09,880
There is a practical limit to what one agent can juggle.
981
00:33:09,880 --> 00:33:11,880
When you exceed that limit, you're better off splitting
982
00:33:11,880 --> 00:33:13,840
into separate agents, rather than piling
983
00:33:13,840 --> 00:33:15,040
more tools into one.
984
00:33:15,040 --> 00:33:17,880
An IT agent that resets passwords, orders hardware,
985
00:33:17,880 --> 00:33:20,000
and manages licenses has broad reach.
986
00:33:20,000 --> 00:33:22,800
But it's still unified by the toolset and the domain.
987
00:33:22,800 --> 00:33:25,600
Now add data governance tools, compliance reporting,
988
00:33:25,600 --> 00:33:26,560
and audit logging.
989
00:33:26,560 --> 00:33:27,640
You've crossed the threshold.
990
00:33:27,640 --> 00:33:29,560
The toolset has become so expansive
991
00:33:29,560 --> 00:33:31,880
that the agent's reliability starts to suffer.
992
00:33:31,880 --> 00:33:33,760
You're better off separating them into two agents
993
00:33:33,760 --> 00:33:35,840
with focused curated tool sets.
994
00:33:35,840 --> 00:33:37,360
Look at a concrete example.
995
00:33:37,360 --> 00:33:40,560
An organization's IT support handles password resets,
996
00:33:40,560 --> 00:33:42,920
access approvals, and incident triage.
997
00:33:42,920 --> 00:33:45,360
And these are three distinct workflows, three skills,
998
00:33:45,360 --> 00:33:46,240
one agent.
999
00:33:46,240 --> 00:33:47,760
The agent can root to the right skill
1000
00:33:47,760 --> 00:33:49,280
based on what the user wants.
1001
00:33:49,280 --> 00:33:51,040
When a user says they forgot their password,
1002
00:33:51,040 --> 00:33:52,480
the reset skill loads.
1003
00:33:52,480 --> 00:33:54,800
When they ask for access to the financial system,
1004
00:33:54,800 --> 00:33:56,200
the approval skill loads.
1005
00:33:56,200 --> 00:33:57,600
When they report a server outage,
1006
00:33:57,600 --> 00:33:58,920
the triage skill loads.
1007
00:33:58,920 --> 00:34:00,120
Three scenarios.
1008
00:34:00,120 --> 00:34:02,760
One agent, one unified user experience.
1009
00:34:02,760 --> 00:34:04,560
Contrast that with HR and IT support.
1010
00:34:04,560 --> 00:34:06,320
Yes, they're both internal operations,
1011
00:34:06,320 --> 00:34:09,040
but they serve different users in different business domains.
1012
00:34:09,040 --> 00:34:11,880
An HR agent and an IT agent should be separate.
1013
00:34:11,880 --> 00:34:13,880
Users don't switch between them randomly.
1014
00:34:13,880 --> 00:34:16,480
A user needing leave approval goes to the HR agent.
1015
00:34:16,480 --> 00:34:19,240
A user needing a password reset goes to the IT agent,
1016
00:34:19,240 --> 00:34:21,560
different entry points, different expertise.
1017
00:34:21,560 --> 00:34:24,200
The modularity principle is worth restating here.
1018
00:34:24,200 --> 00:34:27,320
Skills are about teaching an agent new expertise within a domain.
1019
00:34:27,320 --> 00:34:29,600
A skill adds capability without changing
1020
00:34:29,600 --> 00:34:31,800
the agent's fundamental identity.
1021
00:34:31,800 --> 00:34:34,040
A separate agent is what you build when the domain,
1022
00:34:34,040 --> 00:34:36,360
audience, or toolset becomes so large
1023
00:34:36,360 --> 00:34:38,520
that unification no longer makes sense.
1024
00:34:38,520 --> 00:34:40,600
When in doubt ask, would a user see this
1025
00:34:40,600 --> 00:34:42,080
as one cohesive service?
1026
00:34:42,080 --> 00:34:43,560
Would they naturally go to this one agent
1027
00:34:43,560 --> 00:34:44,920
for everything in this domain?
1028
00:34:44,920 --> 00:34:46,560
If the answer is yes, use skills.
1029
00:34:46,560 --> 00:34:49,280
If the answer is no, build separate agents.
1030
00:34:49,280 --> 00:34:51,680
Accuracy through targeted guidance.
1031
00:34:51,680 --> 00:34:55,760
Accuracy is where the real payoff of skills reveals itself.
1032
00:34:55,760 --> 00:34:57,800
And it's not obvious at first glance.
1033
00:34:57,800 --> 00:35:00,080
You might think accuracy depends entirely on the model.
1034
00:35:00,080 --> 00:35:02,280
Bigger models are smarter, better training data
1035
00:35:02,280 --> 00:35:05,280
produces better answers, fine tuning improves performance
1036
00:35:05,280 --> 00:35:06,640
on your specific domain.
1037
00:35:06,640 --> 00:35:09,160
Those things are true, but they aren't the whole story.
1038
00:35:09,160 --> 00:35:11,840
Model quality matters, but so does signal clarity.
1039
00:35:11,840 --> 00:35:14,920
This is where skills become a lever you can actually pull.
1040
00:35:14,920 --> 00:35:17,560
The problem with broad generic guidance is noise.
1041
00:35:17,560 --> 00:35:19,200
When you give an agent instructions covering
1042
00:35:19,200 --> 00:35:22,480
every possible scenario, you're bearing the critical details.
1043
00:35:22,480 --> 00:35:24,320
The model reads 100 lines of guidance
1044
00:35:24,320 --> 00:35:26,760
when it only needs three to do the job well.
1045
00:35:26,760 --> 00:35:29,240
The rest is just context it has to pass and dismiss.
1046
00:35:29,240 --> 00:35:30,800
Cognitively, that's expensive.
1047
00:35:30,800 --> 00:35:33,240
The model attends to relevant and irrelevant information
1048
00:35:33,240 --> 00:35:34,000
at the same time.
1049
00:35:34,000 --> 00:35:35,520
It has to decide what matters.
1050
00:35:35,520 --> 00:35:36,720
Sometimes it guesses wrong.
1051
00:35:36,720 --> 00:35:39,080
Consider a tool use scenario.
1052
00:35:39,080 --> 00:35:40,560
You have an approval workflow.
1053
00:35:40,560 --> 00:35:42,240
The model is about to trigger it.
1054
00:35:42,240 --> 00:35:44,040
There are parameters like threshold amounts,
1055
00:35:44,040 --> 00:35:46,720
required approval levels and notification lists.
1056
00:35:46,720 --> 00:35:48,720
There's an escalation path for urgent cases
1057
00:35:48,720 --> 00:35:51,240
and fallback behavior if people are unavailable.
1058
00:35:51,240 --> 00:35:53,640
Now, if all of that lives in a generic instruction set
1059
00:35:53,640 --> 00:35:56,320
alongside 10 other workflows, the model is processing
1060
00:35:56,320 --> 00:35:58,840
a lot of material just to finish one task.
1061
00:35:58,840 --> 00:36:01,240
It's reading about budget codes when it should be focused
1062
00:36:01,240 --> 00:36:04,120
on whether this specific request triggers an approval at all.
1063
00:36:04,120 --> 00:36:05,880
The signal to noise ratio is poor.
1064
00:36:05,880 --> 00:36:07,640
The model might forget a validation step.
1065
00:36:07,640 --> 00:36:09,120
It might apply the wrong threshold.
1066
00:36:09,120 --> 00:36:10,880
It might miss an escalation condition.
1067
00:36:10,880 --> 00:36:12,600
Contrast that with a targeted skill.
1068
00:36:12,600 --> 00:36:15,400
The skill exists specifically for approval workflows.
1069
00:36:15,400 --> 00:36:17,800
When it loads, every single line of instruction
1070
00:36:17,800 --> 00:36:18,920
is about approvals.
1071
00:36:18,920 --> 00:36:19,960
Nothing else.
1072
00:36:19,960 --> 00:36:21,320
The rules are explicit.
1073
00:36:21,320 --> 00:36:24,200
Amounts under 5,000 require level 1 approval.
1074
00:36:24,200 --> 00:36:26,840
Amounts over 50,000 require executive leadership.
1075
00:36:26,840 --> 00:36:28,160
The validation steps are clear.
1076
00:36:28,160 --> 00:36:29,120
Check the fields.
1077
00:36:29,120 --> 00:36:30,280
Verify the requester.
1078
00:36:30,280 --> 00:36:31,920
Confirm the level exists.
1079
00:36:31,920 --> 00:36:33,600
The model process is targeted content.
1080
00:36:33,600 --> 00:36:35,080
High signal, no noise.
1081
00:36:35,080 --> 00:36:37,000
Every line moves the task forward.
1082
00:36:37,000 --> 00:36:38,880
The accuracy of the tool invocation improves
1083
00:36:38,880 --> 00:36:40,560
because the guidance is concentrated.
1084
00:36:40,560 --> 00:36:43,680
There's no cognitive load from passing irrelevant material.
1085
00:36:43,680 --> 00:36:45,560
There's no ambiguity about which rules apply.
1086
00:36:45,560 --> 00:36:47,080
The model executes with precision.
1087
00:36:47,080 --> 00:36:48,360
This isn't just theory.
1088
00:36:48,360 --> 00:36:50,480
Teams that implement skills report higher accuracy
1089
00:36:50,480 --> 00:36:53,720
on specific tasks compared to relying on broad documentation.
1090
00:36:53,720 --> 00:36:55,320
The improvement isn't universal.
1091
00:36:55,320 --> 00:36:57,440
It depends on the task, the tool set,
1092
00:36:57,440 --> 00:36:59,080
and how well the skill is written.
1093
00:36:59,080 --> 00:37:01,080
But narrow, curated skills consistently
1094
00:37:01,080 --> 00:37:03,520
outperform broad guidance for specialized workflows.
1095
00:37:03,520 --> 00:37:05,320
The distinction matters between accuracy
1096
00:37:05,320 --> 00:37:08,080
gains that are structural and those that are use case dependent.
1097
00:37:08,080 --> 00:37:09,600
Some improvements are structural.
1098
00:37:09,600 --> 00:37:11,440
When you remove noise and leave signal,
1099
00:37:11,440 --> 00:37:13,400
the model's reasoning path is clearer.
1100
00:37:13,400 --> 00:37:14,680
That's universal.
1101
00:37:14,680 --> 00:37:16,800
But other improvements depend on whether your skill
1102
00:37:16,800 --> 00:37:19,240
actually captures something the model struggles with.
1103
00:37:19,240 --> 00:37:20,880
If the model would get the task right,
1104
00:37:20,880 --> 00:37:23,520
even with generic guidance, a skill won't help much.
1105
00:37:23,520 --> 00:37:24,840
It's already accurate.
1106
00:37:24,840 --> 00:37:28,040
The skill adds clarity, but not necessarily a performance boost.
1107
00:37:28,040 --> 00:37:30,600
You have to measure to know which category you're in.
1108
00:37:30,600 --> 00:37:33,280
This is where the evaluation requirement becomes critical.
1109
00:37:33,280 --> 00:37:35,240
Before you move a workflow into a skill,
1110
00:37:35,240 --> 00:37:36,400
measure the baseline.
1111
00:37:36,400 --> 00:37:39,160
How often does the model get it right with generic guidance?
1112
00:37:39,160 --> 00:37:41,720
How often does it make mistakes document the failure modes?
1113
00:37:41,720 --> 00:37:44,120
Then implement the skill, run the same test cases
1114
00:37:44,120 --> 00:37:45,800
through the skill-driven workflow.
1115
00:37:45,800 --> 00:37:47,280
Measure again.
1116
00:37:47,280 --> 00:37:49,040
Did accuracy improve by how much?
1117
00:37:49,040 --> 00:37:51,040
Is the improvement consistent across different types
1118
00:37:51,040 --> 00:37:53,320
of requests or only in specific cases?
1119
00:37:53,320 --> 00:37:54,760
Don't assume skills help.
1120
00:37:54,760 --> 00:37:56,120
Measure.
1121
00:37:56,120 --> 00:37:58,760
Some tasks are already handled well by a capable model
1122
00:37:58,760 --> 00:38:00,040
with basic guidance.
1123
00:38:00,040 --> 00:38:01,440
Adding a skill won't move the needle
1124
00:38:01,440 --> 00:38:03,040
because the baseline is already high.
1125
00:38:03,040 --> 00:38:03,920
That's fine.
1126
00:38:03,920 --> 00:38:06,080
You've still gained from modularity and manageability
1127
00:38:06,080 --> 00:38:07,920
even if accuracy stayed the same.
1128
00:38:07,920 --> 00:38:09,680
Other tasks are fundamentally difficult.
1129
00:38:09,680 --> 00:38:11,880
A skill helps, but it doesn't solve everything.
1130
00:38:11,880 --> 00:38:14,080
The model still makes mistakes just fewer of them.
1131
00:38:14,080 --> 00:38:14,880
That's still a win.
1132
00:38:14,880 --> 00:38:16,440
And some tasks improve dramatically
1133
00:38:16,440 --> 00:38:18,040
because the skill removes confusion
1134
00:38:18,040 --> 00:38:19,840
and clarifies the exact steps.
1135
00:38:19,840 --> 00:38:21,800
The measurement discipline keeps you honest.
1136
00:38:21,800 --> 00:38:24,720
It prevents the assumption that skills are a silver bullet.
1137
00:38:24,720 --> 00:38:25,760
There are two.
1138
00:38:25,760 --> 00:38:28,280
They work when the problem is signal to noise clarity.
1139
00:38:28,280 --> 00:38:31,120
They work less well when the problem is an inadequate model
1140
00:38:31,120 --> 00:38:33,400
or a task that's inherently ambiguous.
1141
00:38:33,400 --> 00:38:34,440
Know the difference.
1142
00:38:34,440 --> 00:38:35,840
Measure before and after.
1143
00:38:35,840 --> 00:38:38,480
Let the data guide where you invest in skill development.
1144
00:38:38,480 --> 00:38:40,120
Speed and cost economics.
1145
00:38:40,120 --> 00:38:41,520
Here is the business reality.
1146
00:38:41,520 --> 00:38:43,840
Most engineers do not lead with.
1147
00:38:43,840 --> 00:38:45,560
Running agents at scale is expensive.
1148
00:38:45,560 --> 00:38:47,560
Every inference costs tokens.
1149
00:38:47,560 --> 00:38:49,320
Every token costs money.
1150
00:38:49,320 --> 00:38:50,760
In the world of co-pilot credits,
1151
00:38:50,760 --> 00:38:53,600
every single conversation is a line item on your budget.
1152
00:38:53,600 --> 00:38:56,240
When you are running hundreds of conversations every day,
1153
00:38:56,240 --> 00:38:58,160
that arithmetic starts to matter.
1154
00:38:58,160 --> 00:39:01,120
A single slow conversation that takes twice as long to finish
1155
00:39:01,120 --> 00:39:02,880
does more than just annoy your users.
1156
00:39:02,880 --> 00:39:05,640
It doubles the token consumption for that one interaction.
1157
00:39:05,640 --> 00:39:08,280
If you multiply that across your entire user base,
1158
00:39:08,280 --> 00:39:11,000
you are looking at a massive spike in operational spend.
1159
00:39:11,000 --> 00:39:12,680
Skills change the economics because they
1160
00:39:12,680 --> 00:39:14,280
change the token equation.
1161
00:39:14,280 --> 00:39:15,560
Think about the per turn math.
1162
00:39:15,560 --> 00:39:17,240
In a monolithic architecture,
1163
00:39:17,240 --> 00:39:21,360
every single response turn has to process the entire instruction set.
1164
00:39:21,360 --> 00:39:24,400
Let's say your baseline instruction file is 5,000 tokens.
1165
00:39:24,400 --> 00:39:26,200
No matter what the user actually asks for,
1166
00:39:26,200 --> 00:39:28,920
those 5,000 tokens are processed every time.
1167
00:39:28,920 --> 00:39:30,840
The model reads them, the API counts them.
1168
00:39:30,840 --> 00:39:31,800
They show up on your bill.
1169
00:39:31,800 --> 00:39:32,880
But here is the shift.
1170
00:39:32,880 --> 00:39:34,280
When you implement skills,
1171
00:39:34,280 --> 00:39:36,280
you can reduce those baseline instructions
1172
00:39:36,280 --> 00:39:37,880
to maybe 1,000 tokens.
1173
00:39:37,880 --> 00:39:40,720
You keep the core identity and the universal guardrails there,
1174
00:39:40,720 --> 00:39:42,200
but everything else moves.
1175
00:39:42,200 --> 00:39:44,320
The specific guidance lives in the skills.
1176
00:39:44,320 --> 00:39:46,400
On average, when a user asks a question,
1177
00:39:46,400 --> 00:39:48,400
only one relevant skill loads.
1178
00:39:48,400 --> 00:39:51,480
If that skill is 800 tokens, your total context for that turn
1179
00:39:51,480 --> 00:39:53,040
is now 1,900 tokens.
1180
00:39:53,040 --> 00:39:56,040
You just reduce your per turn token count by more than half,
1181
00:39:56,040 --> 00:39:57,600
the math compounds quickly.
1182
00:39:57,600 --> 00:40:00,160
If your agent handles 1,000 conversations a day
1183
00:40:00,160 --> 00:40:03,520
with 10 turns each, you are looking at 10,000 turns daily.
1184
00:40:03,520 --> 00:40:04,920
At 5,000 tokens per turn,
1185
00:40:04,920 --> 00:40:07,120
you are burning 50 million tokens every day.
1186
00:40:07,120 --> 00:40:09,080
But if you reduce that to 1,900 tokens,
1187
00:40:09,080 --> 00:40:10,680
you drop to 1,900,000.
1188
00:40:10,680 --> 00:40:12,000
That difference is not marginal.
1189
00:40:12,000 --> 00:40:13,120
It is structural.
1190
00:40:13,120 --> 00:40:15,760
Lower token counts lead directly to lower latency.
1191
00:40:15,760 --> 00:40:18,800
The model process is faster because it has less to read.
1192
00:40:18,800 --> 00:40:20,840
This also helps you scale your throughput.
1193
00:40:20,840 --> 00:40:22,400
With the same computational budget,
1194
00:40:22,400 --> 00:40:23,880
you can handle more people at once,
1195
00:40:23,880 --> 00:40:27,720
because each conversation is not eating through tokens so aggressively.
1196
00:40:27,720 --> 00:40:29,040
But here is where things change.
1197
00:40:29,040 --> 00:40:30,640
The throughput under load is where skills
1198
00:40:30,640 --> 00:40:32,120
give you the most leverage.
1199
00:40:32,120 --> 00:40:34,560
Most agents do not slow down gradually.
1200
00:40:34,560 --> 00:40:37,320
They fail catastrophically once they hit a limit.
1201
00:40:37,320 --> 00:40:40,000
You might be running fine with 50 users, but at 60,
1202
00:40:40,000 --> 00:40:41,240
you hit a quota wall.
1203
00:40:41,240 --> 00:40:42,440
Request start to queue.
1204
00:40:42,440 --> 00:40:43,960
Response times spike.
1205
00:40:43,960 --> 00:40:45,640
The whole system feels broken.
1206
00:40:45,640 --> 00:40:48,640
Skills prevent this by keeping the baseline context window lean.
1207
00:40:48,640 --> 00:40:52,280
At 50 users, you are not consuming 10 times the tokens
1208
00:40:52,280 --> 00:40:53,800
you would use for five users.
1209
00:40:53,800 --> 00:40:55,440
You are consuming proportionally less
1210
00:40:55,440 --> 00:40:57,720
because the context changes based on the task.
1211
00:40:57,720 --> 00:40:59,760
When the load spikes, you have more room to breathe
1212
00:40:59,760 --> 00:41:01,800
before you hit your infrastructure limits.
1213
00:41:01,800 --> 00:41:03,960
This changes how you plan for capacity.
1214
00:41:03,960 --> 00:41:06,800
Instead of asking how many users a configuration can support,
1215
00:41:06,800 --> 00:41:08,920
you ask what the per user token budget is.
1216
00:41:08,920 --> 00:41:11,080
Because skills let you right size the allocation
1217
00:41:11,080 --> 00:41:13,360
for every conversation, you can pack more users
1218
00:41:13,360 --> 00:41:14,760
into your existing capacity.
1219
00:41:14,760 --> 00:41:17,120
The impact on co-pilot credits is easy to see.
1220
00:41:17,120 --> 00:41:19,360
Fewer tokens per turn and fewer turns per task
1221
00:41:19,360 --> 00:41:21,800
mean you burn fewer credits to reach the goal.
1222
00:41:21,800 --> 00:41:24,800
Organizations that move away from bloated instruction files
1223
00:41:24,800 --> 00:41:28,000
often see a 60% reduction in tokens loaded per turn.
1224
00:41:28,000 --> 00:41:29,520
If your costs are driven by tokens,
1225
00:41:29,520 --> 00:41:32,400
that is a 60% direct saving on your workload.
1226
00:41:32,400 --> 00:41:34,560
The always on everything model is an anti-pattern
1227
00:41:34,560 --> 00:41:36,120
that destroys these economics.
1228
00:41:36,120 --> 00:41:39,080
When every agent loads every possible piece of guidance
1229
00:41:39,080 --> 00:41:41,120
permanently, you are paying for knowledge
1230
00:41:41,120 --> 00:41:42,440
the user will never need.
1231
00:41:42,440 --> 00:41:44,120
You are paying for a full reference manual
1232
00:41:44,120 --> 00:41:45,960
when the user just needs a checklist.
1233
00:41:45,960 --> 00:41:48,080
You are paying to load specialized procedures
1234
00:41:48,080 --> 00:41:49,800
that do not apply to the situation,
1235
00:41:49,800 --> 00:41:52,320
that overhead adds up across every single conversation
1236
00:41:52,320 --> 00:41:53,440
in your enterprise.
1237
00:41:53,440 --> 00:41:55,320
The real-world benchmarks prove this works.
1238
00:41:55,320 --> 00:41:58,360
Organizations moving to modular skills report lower costs
1239
00:41:58,360 --> 00:42:01,200
per user and per task across their entire deployment.
1240
00:42:01,200 --> 00:42:03,520
When you combine lower consumption with faster speeds
1241
00:42:03,520 --> 00:42:06,160
and higher capacity, the economic argument for skills
1242
00:42:06,160 --> 00:42:07,360
is impossible to ignore.
1243
00:42:07,360 --> 00:42:09,240
It is not about optimization theater.
1244
00:42:09,240 --> 00:42:10,960
It is about fundamental efficiency.
1245
00:42:10,960 --> 00:42:12,720
Load what is needed, pay for what is loaded,
1246
00:42:12,720 --> 00:42:14,720
scale by keeping the default lean.
1247
00:42:14,720 --> 00:42:17,280
The skill bundle, scripts and resources.
1248
00:42:17,280 --> 00:42:19,120
A skill is not just a markdown file.
1249
00:42:19,120 --> 00:42:20,000
It is a package.
1250
00:42:20,000 --> 00:42:21,520
Understanding what belongs in that package
1251
00:42:21,520 --> 00:42:22,920
is the difference between a demo
1252
00:42:22,920 --> 00:42:24,440
and a production-ready tool.
1253
00:42:24,440 --> 00:42:26,240
It starts with the skill MD file.
1254
00:42:26,240 --> 00:42:27,160
This is your manifest.
1255
00:42:27,160 --> 00:42:30,040
It holds the metadata like the name, version and author
1256
00:42:30,040 --> 00:42:31,840
that the orchestrator uses for rooting.
1257
00:42:31,840 --> 00:42:33,320
Below that is the instruction section.
1258
00:42:33,320 --> 00:42:34,440
This is narrative content.
1259
00:42:34,440 --> 00:42:36,800
It is the procedural guidance and the decision trees
1260
00:42:36,800 --> 00:42:39,800
that the model reads to understand how to do the job.
1261
00:42:39,800 --> 00:42:40,800
But here is the rule.
1262
00:42:40,800 --> 00:42:42,280
Code does not go in the skill.
1263
00:42:42,280 --> 00:42:43,400
MD file.
1264
00:42:43,400 --> 00:42:45,680
Raw scripts, binary data and complex templates
1265
00:42:45,680 --> 00:42:46,760
live separately.
1266
00:42:46,760 --> 00:42:48,640
They are bundled alongside the manifest.
1267
00:42:48,640 --> 00:42:51,120
Scripts are the executable code, the skill calls
1268
00:42:51,120 --> 00:42:52,160
while it is working.
1269
00:42:52,160 --> 00:42:53,920
This could be Python or shell scripts.
1270
00:42:53,920 --> 00:42:56,120
When a skill needs to validate a data structure
1271
00:42:56,120 --> 00:42:58,720
or generate a report, it calls a bundled script.
1272
00:42:58,720 --> 00:43:00,760
The script runs and returns an answer.
1273
00:43:00,760 --> 00:43:03,120
And then the model uses that result in its reasoning.
1274
00:43:03,120 --> 00:43:05,120
We do not put the script in the instructions
1275
00:43:05,120 --> 00:43:07,840
because the model is not supposed to read it as a story.
1276
00:43:07,840 --> 00:43:09,280
It is supposed to execute it.
1277
00:43:09,280 --> 00:43:10,800
Imagine a vendor onboarding skill.
1278
00:43:10,800 --> 00:43:12,720
The instructions explain the steps,
1279
00:43:12,720 --> 00:43:15,440
like collecting info and running background checks.
1280
00:43:15,440 --> 00:43:17,240
But one step requires checking a tax ID
1281
00:43:17,240 --> 00:43:18,720
against the government database.
1282
00:43:18,720 --> 00:43:20,600
That logic is too complex for a tax prompt,
1283
00:43:20,600 --> 00:43:22,560
so you bundle a Python script instead.
1284
00:43:22,560 --> 00:43:24,440
When the skill runs, it triggers the script.
1285
00:43:24,440 --> 00:43:26,040
The script handles the API call.
1286
00:43:26,040 --> 00:43:28,520
The result comes back and the instructions continue.
1287
00:43:28,520 --> 00:43:30,600
The script stays in the bundle because it needs to travel
1288
00:43:30,600 --> 00:43:31,440
with the skill.
1289
00:43:31,440 --> 00:43:34,280
When you move the skill to production, the script moves to.
1290
00:43:34,280 --> 00:43:36,560
When you version the skill, you version the script.
1291
00:43:36,560 --> 00:43:39,160
If you revoke access to the skill, the script is gone.
1292
00:43:39,160 --> 00:43:40,600
They are coupled by design.
1293
00:43:40,600 --> 00:43:42,680
References are the documents the agent reads
1294
00:43:42,680 --> 00:43:43,920
but does not execute.
1295
00:43:43,920 --> 00:43:46,440
This includes things like schemers, policy documents,
1296
00:43:46,440 --> 00:43:47,720
or reference tables.
1297
00:43:47,720 --> 00:43:50,280
A skill for customer data might bundle a schema file
1298
00:43:50,280 --> 00:43:53,240
that describes the fields and relationships in your database.
1299
00:43:53,240 --> 00:43:56,040
The model reads this to understand the data it is looking at.
1300
00:43:56,040 --> 00:43:58,000
It is reference material, not code.
1301
00:43:58,000 --> 00:43:59,920
Assets are your templates and sample data.
1302
00:43:59,920 --> 00:44:01,400
A contract review skill might include
1303
00:44:01,400 --> 00:44:03,520
a template of standard company terms.
1304
00:44:03,520 --> 00:44:06,480
An expense report skill might bundle a sample report
1305
00:44:06,480 --> 00:44:08,480
to show the model the expected format.
1306
00:44:08,480 --> 00:44:09,760
These assets load on demand.
1307
00:44:09,760 --> 00:44:12,120
They are part of the package, but they only appear
1308
00:44:12,120 --> 00:44:13,400
when they are called.
1309
00:44:13,400 --> 00:44:16,520
It is important to understand how this loading actually works.
1310
00:44:16,520 --> 00:44:18,800
When the orchestrator picks a skill, it loads the skill.
1311
00:44:18,800 --> 00:44:20,560
MD instructions into the context immediately,
1312
00:44:20,560 --> 00:44:22,640
the model starts thinking, but the scripts
1313
00:44:22,640 --> 00:44:24,640
and the reference files do not load yet.
1314
00:44:24,640 --> 00:44:26,960
They are available, but they do not consume tokens
1315
00:44:26,960 --> 00:44:28,800
until the agent actually needs them.
1316
00:44:28,800 --> 00:44:30,720
If a conversation finishes without ever needing
1317
00:44:30,720 --> 00:44:33,960
that tax validation script, that code was never tokenized.
1318
00:44:33,960 --> 00:44:35,320
It never cost you a cent.
1319
00:44:35,320 --> 00:44:37,160
That is the efficiency of the bundle.
1320
00:44:37,160 --> 00:44:38,920
The package travels as one unit,
1321
00:44:38,920 --> 00:44:40,920
but the parts load only when necessary.
1322
00:44:40,920 --> 00:44:42,960
We also have to talk about the security surface.
1323
00:44:42,960 --> 00:44:45,000
Bundled scripts are untrusted code.
1324
00:44:45,000 --> 00:44:46,840
When you pull a skill from an external registry,
1325
00:44:46,840 --> 00:44:49,400
those scripts could contain anything from malicious payloads
1326
00:44:49,400 --> 00:44:50,520
to credential theft.
1327
00:44:50,520 --> 00:44:51,760
You cannot just let them run.
1328
00:44:51,760 --> 00:44:54,200
You have to treat them like any third party code.
1329
00:44:54,200 --> 00:44:56,680
You review them statically, run them in a sandbox,
1330
00:44:56,680 --> 00:44:58,080
and watch how they behave.
1331
00:44:58,080 --> 00:45:00,720
If a script looks suspicious, you do not load it.
1332
00:45:00,720 --> 00:45:02,200
The skill can usually still function
1333
00:45:02,200 --> 00:45:04,200
because the instructions are independent,
1334
00:45:04,200 --> 00:45:05,920
but if you are going to run bundled code,
1335
00:45:05,920 --> 00:45:07,000
you need real governance.
1336
00:45:07,000 --> 00:45:10,040
This is why enterprise governance focuses on the whole bundle.
1337
00:45:10,040 --> 00:45:11,560
The instructions are usually safe,
1338
00:45:11,560 --> 00:45:14,640
but the scripts are where the real risk lives.
1339
00:45:14,640 --> 00:45:17,280
The governance crisis, supply chain risk.
1340
00:45:17,280 --> 00:45:19,200
Up to this point, we have talked about skills
1341
00:45:19,200 --> 00:45:21,840
as a technical fix for architectural problems.
1342
00:45:21,840 --> 00:45:23,320
Better performance, lower costs,
1343
00:45:23,320 --> 00:45:25,800
and easier management are all part of the story.
1344
00:45:25,800 --> 00:45:27,040
But there is a darker reality
1345
00:45:27,040 --> 00:45:29,280
that enterprise architects are just starting to face,
1346
00:45:29,280 --> 00:45:31,400
and it changes everything about how you put skills
1347
00:45:31,400 --> 00:45:32,320
into production.
1348
00:45:32,320 --> 00:45:33,160
Skills are code.
1349
00:45:33,160 --> 00:45:35,080
The instructions themselves are just guidance
1350
00:45:35,080 --> 00:45:37,240
or narrative content for a model to read,
1351
00:45:37,240 --> 00:45:39,320
but skills also bundle executable scripts
1352
00:45:39,320 --> 00:45:41,120
like Python and Shell commands.
1353
00:45:41,120 --> 00:45:43,640
Once you allow executable code into an agent framework,
1354
00:45:43,640 --> 00:45:45,440
you have opened a supply chain attack surface
1355
00:45:45,440 --> 00:45:47,720
that most organizations are not ready to defend.
1356
00:45:47,720 --> 00:45:49,160
The evidence is alarming.
1357
00:45:49,160 --> 00:45:51,400
A deep analysis of nearly 100,000 skills
1358
00:45:51,400 --> 00:45:55,440
from public registries found 157 confirmed malicious skills.
1359
00:45:55,440 --> 00:45:57,680
These were not just suspicious or poorly written,
1360
00:45:57,680 --> 00:45:59,960
but were specifically designed to steal credentials
1361
00:45:59,960 --> 00:46:01,360
and exfiltrate data.
1362
00:46:01,360 --> 00:46:04,400
While 157 attacks were verified in this first wave
1363
00:46:04,400 --> 00:46:07,160
of adoption, the actual number is likely much higher
1364
00:46:07,160 --> 00:46:10,280
because many skills enclosed registries were never analyzed.
1365
00:46:10,280 --> 00:46:11,960
These attack patterns follow the same playbooks
1366
00:46:11,960 --> 00:46:13,880
we see in software supply chains.
1367
00:46:13,880 --> 00:46:16,040
Attackers use typosquoting by publishing a skill
1368
00:46:16,040 --> 00:46:19,440
named vendor onboarding, and hoping users do not notice
1369
00:46:19,440 --> 00:46:21,880
the misspelling when they are looking for the real vendor
1370
00:46:21,880 --> 00:46:23,880
onboarding skill.
1371
00:46:23,880 --> 00:46:25,640
Other skills use credential harvesting
1372
00:46:25,640 --> 00:46:28,280
to log authentication tokens, while some focus
1373
00:46:28,280 --> 00:46:30,560
on privilege escalation to request higher permissions
1374
00:46:30,560 --> 00:46:31,960
than they actually need.
1375
00:46:31,960 --> 00:46:35,040
Some skills even look legitimate and perform their stated task,
1376
00:46:35,040 --> 00:46:36,960
but they secretly copy sensitive data
1377
00:46:36,960 --> 00:46:39,600
to external endpoints while they are running.
1378
00:46:39,600 --> 00:46:42,000
The industry is moving toward a tiered trust model
1379
00:46:42,000 --> 00:46:43,080
to handle this.
1380
00:46:43,080 --> 00:46:45,480
Green zone skills come from verified vendors
1381
00:46:45,480 --> 00:46:48,120
and are signed cryptographically after being reviewed
1382
00:46:48,120 --> 00:46:49,400
by a security team.
1383
00:46:49,400 --> 00:46:51,800
When you import a green skill, you are trusting
1384
00:46:51,800 --> 00:46:54,520
that the vendor did their job, which is a strong signal,
1385
00:46:54,520 --> 00:46:56,720
even if it is not a perfect guarantee.
1386
00:46:56,720 --> 00:46:59,040
Amber zone skills are contributed by the community
1387
00:46:59,040 --> 00:47:01,640
or known authors who have not been fully verified.
1388
00:47:01,640 --> 00:47:03,480
Someone in the community has reviewed them,
1389
00:47:03,480 --> 00:47:05,160
but that review might have been thorough
1390
00:47:05,160 --> 00:47:06,640
or it might have been cursory.
1391
00:47:06,640 --> 00:47:08,560
Many of these skills are perfectly fine,
1392
00:47:08,560 --> 00:47:10,240
but because the assurance is lower,
1393
00:47:10,240 --> 00:47:12,200
you're accepting more risk by using them.
1394
00:47:12,200 --> 00:47:14,120
Red zone skills are completely un-vetted
1395
00:47:14,120 --> 00:47:15,560
and often published anonymously.
1396
00:47:15,560 --> 00:47:17,960
There is no review and no way to know what they do
1397
00:47:17,960 --> 00:47:20,200
without reading every line of code yourself.
1398
00:47:20,200 --> 00:47:23,320
Red skills simply do not belong in production systems.
1399
00:47:23,320 --> 00:47:25,440
The problem is that 60% of enterprise agents
1400
00:47:25,440 --> 00:47:28,560
currently in use have arbitrary code execution enabled.
1401
00:47:28,560 --> 00:47:31,360
Most organizations have not set up tiered governance yet,
1402
00:47:31,360 --> 00:47:33,920
so they are importing skills without reviews
1403
00:47:33,920 --> 00:47:35,840
and running red zone code in production
1404
00:47:35,840 --> 00:47:37,200
without even knowing it.
1405
00:47:37,200 --> 00:47:39,840
This creates a forensic black hole when something goes wrong.
1406
00:47:39,840 --> 00:47:42,000
In traditional software, you have deployment records
1407
00:47:42,000 --> 00:47:44,320
and audit trails to see what happened during a breach,
1408
00:47:44,320 --> 00:47:47,240
but in many skill deployments, those records do not exist.
1409
00:47:47,240 --> 00:47:49,040
A skill loads and a script runs,
1410
00:47:49,040 --> 00:47:51,400
but there is no log of file operations
1411
00:47:51,400 --> 00:47:53,800
or network calls to show what actually happened.
1412
00:47:53,800 --> 00:47:56,280
If a script is malicious or a good script gets compromised,
1413
00:47:56,280 --> 00:47:59,440
you are flying blind with no way to investigate the damage.
1414
00:47:59,440 --> 00:48:01,960
The only real antidote is a strict approval workflow.
1415
00:48:01,960 --> 00:48:03,760
Before any skill reaches production,
1416
00:48:03,760 --> 00:48:05,440
it must pass through static analysis
1417
00:48:05,440 --> 00:48:08,640
to scan for hard coded credentials and unusual system calls.
1418
00:48:08,640 --> 00:48:10,880
It needs to run in a sandbox environment
1419
00:48:10,880 --> 00:48:13,040
where you can observe if it accesses systems,
1420
00:48:13,040 --> 00:48:15,000
it should not or leaks data.
1421
00:48:15,000 --> 00:48:16,560
Finally, you need runtime monitoring
1422
00:48:16,560 --> 00:48:18,520
to log every material action the skill takes
1423
00:48:18,520 --> 00:48:20,840
so you have a record if things go sideways.
1424
00:48:20,840 --> 00:48:23,440
This governance framework is not a nice to have feature.
1425
00:48:23,440 --> 00:48:26,120
Organizations that deploy skills without these rules
1426
00:48:26,120 --> 00:48:28,720
are just betting that attackers have not found them yet,
1427
00:48:28,720 --> 00:48:31,360
and that is a vulnerability, not a strategy.
1428
00:48:31,360 --> 00:48:33,920
Zoned governance architecture,
1429
00:48:33,920 --> 00:48:35,640
knowing that skills need governance is one thing
1430
00:48:35,640 --> 00:48:38,320
but building the framework to enforce it is another.
1431
00:48:38,320 --> 00:48:41,640
The pattern that actually works at scale is environmental zoning.
1432
00:48:41,640 --> 00:48:44,160
This is not a security add on you bolt on at the end,
1433
00:48:44,160 --> 00:48:45,600
but the foundational structure
1434
00:48:45,600 --> 00:48:48,200
for how skills flow through your entire organization.
1435
00:48:48,200 --> 00:48:50,440
Everything starts with your environment strategy.
1436
00:48:50,440 --> 00:48:52,120
You are likely already using development,
1437
00:48:52,120 --> 00:48:54,480
test and production environments in the power platform,
1438
00:48:54,480 --> 00:48:57,120
and that structure now becomes your governance backbone.
1439
00:48:57,120 --> 00:48:59,800
Each environment accesses a zone with its own rules
1440
00:48:59,800 --> 00:49:02,680
about which skills can run and who is allowed to publish them.
1441
00:49:02,680 --> 00:49:06,040
Green zones are your spaces for experimentation and innovation.
1442
00:49:06,040 --> 00:49:07,440
These are development environments
1443
00:49:07,440 --> 00:49:10,200
where makers build new skills and test out different workflows.
1444
00:49:10,200 --> 00:49:11,840
The default setting here is permissive
1445
00:49:11,840 --> 00:49:14,240
so teams can import skills from public registries
1446
00:49:14,240 --> 00:49:16,120
and test them against development data.
1447
00:49:16,120 --> 00:49:18,000
The goal is to let people try things safely,
1448
00:49:18,000 --> 00:49:20,080
but safety still requires some control.
1449
00:49:20,080 --> 00:49:22,800
You still apply DLP policies to block dangerous connectors
1450
00:49:22,800 --> 00:49:24,600
like unrestricted HTTP calls,
1451
00:49:24,600 --> 00:49:27,320
but you let teams experiment with internal systems
1452
00:49:27,320 --> 00:49:30,640
because any failure is isolated to that one environment.
1453
00:49:30,640 --> 00:49:33,160
Yellow zones are where multiple makers collaborate
1454
00:49:33,160 --> 00:49:35,640
on skills that are heading toward production.
1455
00:49:35,640 --> 00:49:36,840
Governance gets tighter here
1456
00:49:36,840 --> 00:49:38,720
and only curated skills that have been reviewed
1457
00:49:38,720 --> 00:49:40,760
by a competent person are allowed to enter.
1458
00:49:40,760 --> 00:49:42,840
This is not a full corporate approval yet,
1459
00:49:42,840 --> 00:49:45,480
but it is a checkpoint where an architect confirms
1460
00:49:45,480 --> 00:49:47,400
the code does what it claims to do.
1461
00:49:47,400 --> 00:49:50,320
Makers can still iterate and test against realistic data,
1462
00:49:50,320 --> 00:49:52,480
but the pace slows down.
1463
00:49:52,480 --> 00:49:54,320
Before a skill moves to the next stage,
1464
00:49:54,320 --> 00:49:56,880
a lead must sign off to confirm they understand the code
1465
00:49:56,880 --> 00:49:58,360
and it is ready for validation.
1466
00:49:58,360 --> 00:50:00,240
Red zones are your production environments
1467
00:50:00,240 --> 00:50:02,760
where only certified skills are allowed to live.
1468
00:50:02,760 --> 00:50:06,000
Certification means the skill has passed security reviews,
1469
00:50:06,000 --> 00:50:08,720
performance tests and operational readiness checks.
1470
00:50:08,720 --> 00:50:10,160
It has been signed by an approver
1471
00:50:10,160 --> 00:50:12,920
and logged in a corporate catalog with clear ownership.
1472
00:50:12,920 --> 00:50:15,440
In these red zones, the mentality shifts entirely
1473
00:50:15,440 --> 00:50:17,160
toward minimizing surprises.
1474
00:50:17,160 --> 00:50:19,280
You block entire categories of connectors
1475
00:50:19,280 --> 00:50:23,240
and restrict network access to ensure nothing unexpected happens.
1476
00:50:23,240 --> 00:50:26,360
DLP is the enforcement layer that makes these zones real
1477
00:50:26,360 --> 00:50:27,920
rather than just a suggestion.
1478
00:50:27,920 --> 00:50:29,640
Data loss prevention policies govern
1479
00:50:29,640 --> 00:50:33,200
which connectors can talk to specific endpoints across your tenant.
1480
00:50:33,200 --> 00:50:35,760
You might block all unauthenticated HTTP connectors
1481
00:50:35,760 --> 00:50:38,120
at the top level, but allow them in green zones
1482
00:50:38,120 --> 00:50:39,480
so developers can learn.
1483
00:50:39,480 --> 00:50:41,240
As a skill moves toward production,
1484
00:50:41,240 --> 00:50:43,600
the policy becomes progressively more restrictive
1485
00:50:43,600 --> 00:50:46,120
until only allow listed endpoints are accessible.
1486
00:50:46,120 --> 00:50:48,680
Environment level isolation is the physical mechanism
1487
00:50:48,680 --> 00:50:50,720
for moving skills through these zones.
1488
00:50:50,720 --> 00:50:53,560
A skill does not just drift from green to yellow on its own.
1489
00:50:53,560 --> 00:50:56,320
A developer has to export it and request a promotion
1490
00:50:56,320 --> 00:50:58,120
which serves as your natural checkpoint
1491
00:50:58,120 --> 00:50:59,480
to ask if it was tested.
1492
00:50:59,480 --> 00:51:01,160
The skill travels through your environments
1493
00:51:01,160 --> 00:51:02,480
as a managed artifact,
1494
00:51:02,480 --> 00:51:04,200
ensuring that what ends up in production
1495
00:51:04,200 --> 00:51:05,560
is exactly what was approved.
1496
00:51:05,560 --> 00:51:07,440
The center of excellence plays a critical role here
1497
00:51:07,440 --> 00:51:10,000
by setting the baseline policies for the whole organization.
1498
00:51:10,000 --> 00:51:11,720
They decide which connectors are blocked
1499
00:51:11,720 --> 00:51:13,520
and which skills need formal approval
1500
00:51:13,520 --> 00:51:16,240
while domain-specific teams in HR or finance
1501
00:51:16,240 --> 00:51:18,800
maintain their own catalogs within those guardrails.
1502
00:51:18,800 --> 00:51:19,880
When you set it up this way,
1503
00:51:19,880 --> 00:51:21,760
governance is no longer just overhead,
1504
00:51:21,760 --> 00:51:24,120
but the actual operating system for your agents.
1505
00:51:24,120 --> 00:51:26,600
Trust and review patterns.
1506
00:51:26,600 --> 00:51:28,960
The Zoned governance framework gives you the structure
1507
00:51:28,960 --> 00:51:31,600
but structure without a process is just bureaucracy.
1508
00:51:31,600 --> 00:51:33,880
The actual work happens in how you review skills
1509
00:51:33,880 --> 00:51:35,680
before they enter yellow and red zones
1510
00:51:35,680 --> 00:51:37,240
and how you maintain that trust over time.
1511
00:51:37,240 --> 00:51:39,280
Start by treating external skills exactly
1512
00:51:39,280 --> 00:51:41,080
like you would treat third-party code
1513
00:51:41,080 --> 00:51:42,640
you are about to put into production.
1514
00:51:42,640 --> 00:51:45,160
You would not download a random library from GitHub
1515
00:51:45,160 --> 00:51:47,840
and drop it into your code base without looking at it first.
1516
00:51:47,840 --> 00:51:49,160
You would run security scans.
1517
00:51:49,160 --> 00:51:50,160
You would review the code,
1518
00:51:50,160 --> 00:51:52,280
you would test how it behaves in isolation
1519
00:51:52,280 --> 00:51:54,120
to understand what it accesses.
1520
00:51:54,120 --> 00:51:55,600
The same discipline applies here.
1521
00:51:55,600 --> 00:51:57,960
The review checklist is your operational standard.
1522
00:51:57,960 --> 00:52:00,240
Before a skill moves from green to yellow,
1523
00:52:00,240 --> 00:52:02,880
someone competent has to verify the details.
1524
00:52:02,880 --> 00:52:04,000
First is provenance.
1525
00:52:04,000 --> 00:52:05,440
Where did the skill come from?
1526
00:52:05,440 --> 00:52:06,680
You need to know who authored it
1527
00:52:06,680 --> 00:52:08,760
and if they have a track record you can trust.
1528
00:52:08,760 --> 00:52:11,040
A skill from an official Microsoft catalog
1529
00:52:11,040 --> 00:52:12,480
carries a different weight than one
1530
00:52:12,480 --> 00:52:14,120
from an anonymous GitHub user.
1531
00:52:14,120 --> 00:52:15,000
Next is intent.
1532
00:52:15,000 --> 00:52:16,440
What does the skill claim to do?
1533
00:52:16,440 --> 00:52:18,080
Read the metadata and the instructions
1534
00:52:18,080 --> 00:52:20,840
to see if the scope is narrow or dangerously broad.
1535
00:52:20,840 --> 00:52:22,040
Then look at dependencies.
1536
00:52:22,040 --> 00:52:23,880
What does the skill need to run?
1537
00:52:23,880 --> 00:52:25,560
You need to know which systems it calls
1538
00:52:25,560 --> 00:52:27,160
and what permissions it requires.
1539
00:52:27,160 --> 00:52:30,040
A skill that only needs read only access to customer data
1540
00:52:30,040 --> 00:52:32,320
is a much lower risk than one that needs right access
1541
00:52:32,320 --> 00:52:33,840
to your financial system.
1542
00:52:33,840 --> 00:52:35,640
Finally, check for injection risks.
1543
00:52:35,640 --> 00:52:37,720
Look for embedded instructions that could be overwritten
1544
00:52:37,720 --> 00:52:38,760
by a user.
1545
00:52:38,760 --> 00:52:41,440
If it passes untrusted input without validation,
1546
00:52:41,440 --> 00:52:43,720
an attacker could manipulate it into doing something
1547
00:52:43,720 --> 00:52:45,360
other than its stated purpose.
1548
00:52:45,360 --> 00:52:47,200
Static analysis is your first gate.
1549
00:52:47,200 --> 00:52:49,320
You run automated tools over the bundled scripts
1550
00:52:49,320 --> 00:52:53,080
to catch obvious red flags like hard-coded API keys or passwords.
1551
00:52:53,080 --> 00:52:55,600
These tools scan for suspicious file operations
1552
00:52:55,600 --> 00:52:57,960
and network calls to unexpected destinations.
1553
00:52:57,960 --> 00:52:59,920
It is fast and catches the easy mistakes,
1554
00:52:59,920 --> 00:53:01,440
but it is not enough on its own.
1555
00:53:01,440 --> 00:53:03,320
Static analysis finds known patterns,
1556
00:53:03,320 --> 00:53:05,120
but it misses new types of attacks.
1557
00:53:05,120 --> 00:53:08,160
Sandbox execution is where you see what the skill actually does.
1558
00:53:08,160 --> 00:53:10,840
You take the script and put it in an isolated environment
1559
00:53:10,840 --> 00:53:12,800
like a container or a virtual machine.
1560
00:53:12,800 --> 00:53:14,960
You give it minimal permissions and then you watch.
1561
00:53:14,960 --> 00:53:15,880
Does it read files?
1562
00:53:15,880 --> 00:53:16,640
Which ones?
1563
00:53:16,640 --> 00:53:19,760
Does it try to start new processes or change the system state?
1564
00:53:19,760 --> 00:53:20,960
You capture everything it does
1565
00:53:20,960 --> 00:53:23,600
and compare those observations to the original intent.
1566
00:53:23,600 --> 00:53:25,440
If a skill says it validates a text ID,
1567
00:53:25,440 --> 00:53:28,720
but tries to make external HTTP calls, you have a mismatch.
1568
00:53:28,720 --> 00:53:30,840
You investigate that before you ever deploy it.
1569
00:53:30,840 --> 00:53:32,680
Permission scoping is how you limit the damage
1570
00:53:32,680 --> 00:53:33,800
when something goes wrong.
1571
00:53:33,800 --> 00:53:36,280
If a skill needs to call an approval API,
1572
00:53:36,280 --> 00:53:39,040
it does not need access to your entire database.
1573
00:53:39,040 --> 00:53:40,560
You create a service account with permissions
1574
00:53:40,560 --> 00:53:42,760
limited to that one specific operation.
1575
00:53:42,760 --> 00:53:45,000
By giving the skill those exact credentials,
1576
00:53:45,000 --> 00:53:47,200
you are following the rule of least privilege.
1577
00:53:47,200 --> 00:53:48,720
If the skill is compromised,
1578
00:53:48,720 --> 00:53:51,520
the attacker can only do what that one credential allows.
1579
00:53:51,520 --> 00:53:54,200
The recertification requirement reflects a hard truth.
1580
00:53:54,200 --> 00:53:56,680
Skills drift, an approved skill is frozen in time
1581
00:53:56,680 --> 00:53:58,160
the moment you say yes to it,
1582
00:53:58,160 --> 00:54:00,200
but systems change in APIs evolve.
1583
00:54:00,200 --> 00:54:02,320
A skill written for an older version of a database
1584
00:54:02,320 --> 00:54:04,280
might not work correctly on the new one.
1585
00:54:04,280 --> 00:54:06,560
Even worse, a new vulnerability in a library
1586
00:54:06,560 --> 00:54:08,360
can make a safe skill risky overnight.
1587
00:54:08,360 --> 00:54:10,880
Reviews are not one-time events, they are checkpoints.
1588
00:54:10,880 --> 00:54:13,880
Every quarter, you should reexamine your high-risk skills
1589
00:54:13,880 --> 00:54:15,920
to see if the threat landscape has changed.
1590
00:54:15,920 --> 00:54:17,840
This discipline costs resources.
1591
00:54:17,840 --> 00:54:19,680
Reviewing takes time and sandbox testing
1592
00:54:19,680 --> 00:54:21,200
requires infrastructure.
1593
00:54:21,200 --> 00:54:24,000
Recertification is an ongoing cost you have to pay.
1594
00:54:24,000 --> 00:54:26,600
But this is the price of running untrusted codes safely.
1595
00:54:26,600 --> 00:54:29,520
Organizations that skip these steps get a little speed now.
1596
00:54:29,520 --> 00:54:31,360
But they get a lot of vulnerability later.
1597
00:54:31,360 --> 00:54:33,800
The teams that build these practices into their daily flow
1598
00:54:33,800 --> 00:54:36,720
are the ones who make skills safe to use at scale.
1599
00:54:36,720 --> 00:54:38,520
The skill catalog future.
1600
00:54:38,520 --> 00:54:40,720
Today, the way skills work in co-pilot studio
1601
00:54:40,720 --> 00:54:42,000
has a big limitation.
1602
00:54:42,000 --> 00:54:44,480
Skills are stuck inside the agent that contains them.
1603
00:54:44,480 --> 00:54:47,360
If you build a skill for agent A and want it in agent B,
1604
00:54:47,360 --> 00:54:49,560
you have to duplicate it or refactor everything
1605
00:54:49,560 --> 00:54:51,560
to use a shared dataverse skill.
1606
00:54:51,560 --> 00:54:53,320
Duplication is a mess to maintain.
1607
00:54:53,320 --> 00:54:55,680
Refactoring works, but it takes a lot of extra effort.
1608
00:54:55,680 --> 00:54:56,960
Neither way is easy.
1609
00:54:56,960 --> 00:54:58,480
But this constraint is temporary.
1610
00:54:58,480 --> 00:55:01,200
It shows where the market is right now in mid-2026,
1611
00:55:01,200 --> 00:55:02,400
not where it is going.
1612
00:55:02,400 --> 00:55:03,680
The path forward is clear.
1613
00:55:03,680 --> 00:55:06,360
Microsoft is moving toward tenant-wide skill catalogs.
1614
00:55:06,360 --> 00:55:08,080
This means you author a skill once,
1615
00:55:08,080 --> 00:55:11,240
govern it once, and use it across every agent in your company.
1616
00:55:11,240 --> 00:55:12,800
GitHub co-pilot is doing the same thing
1617
00:55:12,800 --> 00:55:14,160
with portable packages.
1618
00:55:14,160 --> 00:55:15,960
Claude code is following along, too.
1619
00:55:15,960 --> 00:55:19,480
Everything is moving toward the openskill.md standard
1620
00:55:19,480 --> 00:55:22,320
as the common language for what an agent can do.
1621
00:55:22,320 --> 00:55:24,600
The goal is to write once and run everywhere.
1622
00:55:24,600 --> 00:55:27,040
You might author a skill for onboarding a new vendor.
1623
00:55:27,040 --> 00:55:29,520
That skill is just instructions and metadata in markdown,
1624
00:55:29,520 --> 00:55:31,440
maybe bundled with a few scripts.
1625
00:55:31,440 --> 00:55:33,680
That same skill can run in co-pilot studio,
1626
00:55:33,680 --> 00:55:35,400
in GitHub co-pilot for automation,
1627
00:55:35,400 --> 00:55:36,880
or in Claude code for engineering.
1628
00:55:36,880 --> 00:55:39,320
It becomes one source of truth with many different ways
1629
00:55:39,320 --> 00:55:40,040
to use it.
1630
00:55:40,040 --> 00:55:43,240
You do not have to rewrite it or adapt it for every new tool.
1631
00:55:43,240 --> 00:55:44,920
The skill carries its intent with it.
1632
00:55:44,920 --> 00:55:46,160
This is not just a theory.
1633
00:55:46,160 --> 00:55:47,800
Organizations are already building this way
1634
00:55:47,800 --> 00:55:49,960
by keeping their skills and git repositories.
1635
00:55:49,960 --> 00:55:51,360
They version them just like code
1636
00:55:51,360 --> 00:55:53,320
and move them across different platforms.
1637
00:55:53,320 --> 00:55:54,680
The tools are still a bit clunky
1638
00:55:54,680 --> 00:55:56,640
and you might have to tweak a format here and there,
1639
00:55:56,640 --> 00:55:57,560
but the vision is set.
1640
00:55:57,560 --> 00:56:00,800
The skill is becoming the portable unit of what an agent can do.
1641
00:56:00,800 --> 00:56:03,600
Dataverse intelligence is the layer that makes this vision work.
1642
00:56:03,600 --> 00:56:05,880
Business skills stored in Dataverse are company assets
1643
00:56:05,880 --> 00:56:08,880
that you own, approve, and eventually retire.
1644
00:56:08,880 --> 00:56:10,280
They are not locked into one agent.
1645
00:56:10,280 --> 00:56:12,080
You publish them to an enterprise library
1646
00:56:12,080 --> 00:56:14,120
where any authorized agent can find them.
1647
00:56:14,120 --> 00:56:16,800
In this model, the Dataverse skill is the system of record.
1648
00:56:16,800 --> 00:56:18,240
And the agents are just clients.
1649
00:56:18,240 --> 00:56:19,800
This flips the old architecture
1650
00:56:19,800 --> 00:56:22,400
where every agent had to own its own knowledge.
1651
00:56:22,400 --> 00:56:24,240
The marketplace for this is still forming,
1652
00:56:24,240 --> 00:56:25,880
but the potential is huge.
1653
00:56:25,880 --> 00:56:28,320
Eventually vendors will publish pre-built skill libraries
1654
00:56:28,320 --> 00:56:29,600
for specific jobs.
1655
00:56:29,600 --> 00:56:32,160
Sales force could offer a library for CRM tasks
1656
00:56:32,160 --> 00:56:34,880
and SAP could do the same for financial processes.
1657
00:56:34,880 --> 00:56:36,680
Your company would subscribe to these libraries
1658
00:56:36,680 --> 00:56:37,920
and immediately give your agents
1659
00:56:37,920 --> 00:56:39,720
the best practices for those fields.
1660
00:56:39,720 --> 00:56:41,440
Right now that is still a bit speculative,
1661
00:56:41,440 --> 00:56:44,280
the ecosystem is young and the quality of skills varies a lot.
1662
00:56:44,280 --> 00:56:45,320
We do not have solid models
1663
00:56:45,320 --> 00:56:47,520
for how companies will sell or distribute these yet,
1664
00:56:47,520 --> 00:56:49,040
but the architecture is ready for it
1665
00:56:49,040 --> 00:56:50,800
and the pressure to build it is real.
1666
00:56:50,800 --> 00:56:52,880
Every big company asking how to scale their agents
1667
00:56:52,880 --> 00:56:53,760
hits the same wall.
1668
00:56:53,760 --> 00:56:55,880
They need to know how to share expertise efficiently.
1669
00:56:55,880 --> 00:56:56,920
Skills are the answer
1670
00:56:56,920 --> 00:57:00,160
and the infrastructure to share them is finally showing up.
1671
00:57:00,160 --> 00:57:02,400
In 2026, an enterprise skill library
1672
00:57:02,400 --> 00:57:05,560
is a curated collection of procedures kept in a central system.
1673
00:57:05,560 --> 00:57:07,080
It is the company's version of a manual
1674
00:57:07,080 --> 00:57:08,800
but the manual is machine readable
1675
00:57:08,800 --> 00:57:10,440
so agents can actually do the work.
1676
00:57:10,440 --> 00:57:12,000
Domain teams keep it updated.
1677
00:57:12,000 --> 00:57:13,360
It is auditable and compliant.
1678
00:57:13,360 --> 00:57:14,680
It is the foundation for how
1679
00:57:14,680 --> 00:57:17,000
an AI native company actually functions.
1680
00:57:17,000 --> 00:57:18,800
Most organizations are not there yet.
1681
00:57:18,800 --> 00:57:20,160
They are still building single agents
1682
00:57:20,160 --> 00:57:22,400
or just learning how skills work in one place,
1683
00:57:22,400 --> 00:57:23,800
but you can see where this is going.
1684
00:57:23,800 --> 00:57:25,360
First comes skill sharing,
1685
00:57:25,360 --> 00:57:27,240
then using them across different platforms
1686
00:57:27,240 --> 00:57:29,160
and finally a full marketplace.
1687
00:57:29,160 --> 00:57:30,960
Each step builds on the one before it.
1688
00:57:30,960 --> 00:57:32,560
The zoned governance framework
1689
00:57:32,560 --> 00:57:35,080
actually becomes more important as you share more.
1690
00:57:35,080 --> 00:57:38,040
You need stronger controls when one skill serves 50 agents
1691
00:57:38,040 --> 00:57:39,560
instead of just one.
1692
00:57:39,560 --> 00:57:41,880
The dataverse endpoint becomes your central hub
1693
00:57:41,880 --> 00:57:44,120
for everything your company knows how to do.
1694
00:57:44,120 --> 00:57:45,880
This is where the architecture gets deep.
1695
00:57:45,880 --> 00:57:47,680
Skills are how you encode intelligence.
1696
00:57:47,680 --> 00:57:49,240
You do not put it in a separate document
1697
00:57:49,240 --> 00:57:50,440
or a static system.
1698
00:57:50,440 --> 00:57:52,160
You turn it into an executable procedure
1699
00:57:52,160 --> 00:57:53,480
that an agent can use.
1700
00:57:53,480 --> 00:57:56,320
The skill catalog becomes the memory of your organization.
1701
00:57:56,320 --> 00:57:58,240
It is how you make sure the right way to do things
1702
00:57:58,240 --> 00:58:00,080
is shared, improved and enforced
1703
00:58:00,080 --> 00:58:01,760
across every agent you run.
1704
00:58:01,760 --> 00:58:04,560
The orchestration shift, your old chatbot was built on a map.
1705
00:58:04,560 --> 00:58:06,360
It used deterministic dialog trees.
1706
00:58:06,360 --> 00:58:08,760
If the user clicks A, the bot goes to B.
1707
00:58:08,760 --> 00:58:10,920
If the user says X, the bot follows path Y,
1708
00:58:10,920 --> 00:58:12,560
it was rigid, it was predictable
1709
00:58:12,560 --> 00:58:14,680
and it was completely incapable of judgment.
1710
00:58:14,680 --> 00:58:17,440
The system didn't think it just navigated a pre-drawn
1711
00:58:17,440 --> 00:58:19,320
maze, modern agents have moved away from that.
1712
00:58:19,320 --> 00:58:20,680
They don't follow a map anymore.
1713
00:58:20,680 --> 00:58:21,920
They use semantic routing.
1714
00:58:21,920 --> 00:58:23,800
When a user asks a question, the orchestrator
1715
00:58:23,800 --> 00:58:25,520
doesn't look for a hard-coded branch.
1716
00:58:25,520 --> 00:58:27,280
It looks for meaning, it asks,
1717
00:58:27,280 --> 00:58:29,520
what is this person actually trying to do?
1718
00:58:29,520 --> 00:58:32,120
It asks, which skill in my library is the best match
1719
00:58:32,120 --> 00:58:33,480
for this specific moment?
1720
00:58:33,480 --> 00:58:35,720
It asks, do I even need a skill?
1721
00:58:35,720 --> 00:58:37,880
Or can I handle this with my own reasoning?
1722
00:58:37,880 --> 00:58:39,240
This isn't treat reversal.
1723
00:58:39,240 --> 00:58:41,760
It's dynamic matching between a user's intent
1724
00:58:41,760 --> 00:58:43,480
and the agent's capabilities.
1725
00:58:43,480 --> 00:58:45,440
Here is how that decision actually happens.
1726
00:58:45,440 --> 00:58:46,960
A message comes in, the orchestrator
1727
00:58:46,960 --> 00:58:49,520
looks at the metadata of every available skill.
1728
00:58:49,520 --> 00:58:52,360
The names, the descriptions, the purpose, then it scores them.
1729
00:58:52,360 --> 00:58:54,440
It might decide there is an 85% match
1730
00:58:54,440 --> 00:58:56,080
for the leave eligibility skill,
1731
00:58:56,080 --> 00:58:59,080
but only a 5% match for benefits, the high score wins,
1732
00:58:59,080 --> 00:59:00,160
the skill loads.
1733
00:59:00,160 --> 00:59:01,280
But here is the shift.
1734
00:59:01,280 --> 00:59:03,000
The skill doesn't lock the agent into a cage.
1735
00:59:03,000 --> 00:59:05,080
It provides expertise, not a script.
1736
00:59:05,080 --> 00:59:07,640
It says, if you're talking about leave,
1737
00:59:07,640 --> 00:59:10,120
here are the rules and the steps you need to follow.
1738
00:59:10,120 --> 00:59:11,840
But the model still has its own brain.
1739
00:59:11,840 --> 00:59:13,960
If the user has a weird, specific nuance
1740
00:59:13,960 --> 00:59:16,360
that the skill didn't plan for, the model adapts
1741
00:59:16,360 --> 00:59:18,400
if the request is slightly outside the box,
1742
00:59:18,400 --> 00:59:21,120
the model extrapolates, the skill orients the reasoning.
1743
00:59:21,120 --> 00:59:22,680
But it doesn't constrain the output.
1744
00:59:22,680 --> 00:59:24,760
You see this most clearly in multi-turn conversations.
1745
00:59:24,760 --> 00:59:27,280
A user asks about leave, the leave skill loads,
1746
00:59:27,280 --> 00:59:29,640
the agent answers, then the user follows up.
1747
00:59:29,640 --> 00:59:31,080
What if I want to extend it?
1748
00:59:31,080 --> 00:59:33,840
The orchestrator realizes we are still talking about leave.
1749
00:59:33,840 --> 00:59:36,120
The skill stays loaded, the context remains active,
1750
00:59:36,120 --> 00:59:37,760
because the skill is already there,
1751
00:59:37,760 --> 00:59:39,600
the cost of thinking stays low.
1752
00:59:39,600 --> 00:59:41,160
The agent doesn't have to relearn the rules
1753
00:59:41,160 --> 00:59:43,840
for every new sentence, but then the user pivots.
1754
00:59:43,840 --> 00:59:45,440
How do I update my direct deposit?
1755
00:59:45,440 --> 00:59:47,800
That isn't leave, that's payroll.
1756
00:59:47,800 --> 00:59:49,280
The orchestrator sees the mismatch
1757
00:59:49,280 --> 00:59:51,360
and unloads the leave skill immediately.
1758
00:59:51,360 --> 00:59:54,360
It shifts its cognitive load to a new set of expertise.
1759
00:59:54,360 --> 00:59:56,160
The path changes because the intent changed,
1760
00:59:56,160 --> 00:59:58,000
sometimes these skills chain together.
1761
00:59:58,000 --> 00:59:59,600
One skill validates a vendor,
1762
00:59:59,600 --> 01:00:01,400
and that success triggers a second skill
1763
01:00:01,400 --> 01:00:02,840
to set up payment terms.
1764
01:00:02,840 --> 01:00:04,280
The completion of that might trigger
1765
01:00:04,280 --> 01:00:06,400
a third skill to notify procurement.
1766
01:00:06,400 --> 01:00:08,200
Work flows flow, but the orchestrator
1767
01:00:08,200 --> 01:00:09,680
is the one managing the timing.
1768
01:00:09,680 --> 01:00:11,520
This is why modern agents feel different.
1769
01:00:11,520 --> 01:00:13,040
The skill provides the expertise,
1770
01:00:13,040 --> 01:00:14,560
the model provides the judgment.
1771
01:00:14,560 --> 01:00:17,240
The model without a skill is slow and makes mistakes.
1772
01:00:17,240 --> 01:00:19,920
A skill without a model is just a rigid brittle procedure.
1773
01:00:19,920 --> 01:00:20,960
But when you combine them,
1774
01:00:20,960 --> 01:00:23,360
you get a system that knows exactly when to follow the rules
1775
01:00:23,360 --> 01:00:24,840
and when to use its head.
1776
01:00:24,840 --> 01:00:26,400
Measuring skill effectiveness,
1777
01:00:26,400 --> 01:00:28,680
there is a massive gap between a skill that should work,
1778
01:00:28,680 --> 01:00:30,640
and a skill that actually works in production,
1779
01:00:30,640 --> 01:00:32,280
most organizations stumble here.
1780
01:00:32,280 --> 01:00:34,320
They build, they deploy, and then they assume
1781
01:00:34,320 --> 01:00:35,400
everything is fine.
1782
01:00:35,400 --> 01:00:37,120
Months go by, the agent feels slow,
1783
01:00:37,120 --> 01:00:38,200
the savings aren't there,
1784
01:00:38,200 --> 01:00:39,640
the team stops maintaining the skills
1785
01:00:39,640 --> 01:00:41,800
because nobody knows what they're actually doing.
1786
01:00:41,800 --> 01:00:43,960
The reason is simple, nobody measured.
1787
01:00:43,960 --> 01:00:46,000
If you want this to work, you have to be systematic.
1788
01:00:46,000 --> 01:00:48,240
There are five dimensions that actually matter.
1789
01:00:48,240 --> 01:00:49,960
First is triggering accuracy.
1790
01:00:49,960 --> 01:00:52,720
Does the orchestrator call the skill when it's supposed to?
1791
01:00:52,720 --> 01:00:53,960
If your leave skill is firing
1792
01:00:53,960 --> 01:00:55,560
when people ask about their paycheck,
1793
01:00:55,560 --> 01:00:56,600
your routing is broken.
1794
01:00:56,600 --> 01:00:57,680
You need to watch the rates.
1795
01:00:57,680 --> 01:00:59,560
If a skill usually fires 10 times a day
1796
01:00:59,560 --> 01:01:01,160
and suddenly drops to two.
1797
01:01:01,160 --> 01:01:02,280
Something changed.
1798
01:01:02,280 --> 01:01:04,120
Either your users stopped caring
1799
01:01:04,120 --> 01:01:06,040
or your routing quality degraded.
1800
01:01:06,040 --> 01:01:07,280
Second is isolation.
1801
01:01:07,280 --> 01:01:09,440
Does the skill work when it's the only thing running?
1802
01:01:09,440 --> 01:01:11,520
Don't worry about complex interactions yet.
1803
01:01:11,520 --> 01:01:14,360
Just run core scenarios against the skill by itself
1804
01:01:14,360 --> 01:01:16,000
to make sure the logic holds up.
1805
01:01:16,000 --> 01:01:17,160
Third is coexistence.
1806
01:01:17,160 --> 01:01:18,680
This is where things get messy.
1807
01:01:18,680 --> 01:01:20,800
What happens when you load five skills at once?
1808
01:01:20,800 --> 01:01:22,360
Do the descriptions overlap so much
1809
01:01:22,360 --> 01:01:24,200
that the orchestrator gets confused?
1810
01:01:24,200 --> 01:01:26,840
Do the instructions in skill A, contradict skill B?
1811
01:01:26,840 --> 01:01:28,840
Testing coexistence ensures your skills
1812
01:01:28,840 --> 01:01:30,960
aren't fighting each other for control.
1813
01:01:30,960 --> 01:01:32,680
Fourth is instruction following.
1814
01:01:32,680 --> 01:01:33,880
When the skill is active,
1815
01:01:33,880 --> 01:01:35,560
does the model actually listen to it?
1816
01:01:35,560 --> 01:01:37,040
You have to watch the reasoning path.
1817
01:01:37,040 --> 01:01:38,560
If the skill says a step is mandatory
1818
01:01:38,560 --> 01:01:41,040
and the model skips it, you have a design flaw.
1819
01:01:41,040 --> 01:01:42,360
Usually this means your instructions
1820
01:01:42,360 --> 01:01:45,000
are too ambiguous for the model to follow.
1821
01:01:45,000 --> 01:01:46,520
Fifth is output quality.
1822
01:01:46,520 --> 01:01:47,680
This is the bottom line.
1823
01:01:47,680 --> 01:01:48,720
The routing worked.
1824
01:01:48,720 --> 01:01:50,240
The instructions were followed.
1825
01:01:50,240 --> 01:01:51,560
But was the answer right?
1826
01:01:51,560 --> 01:01:53,760
If a human expert wouldn't sign off on the response,
1827
01:01:53,760 --> 01:01:54,760
the skill failed.
1828
01:01:54,760 --> 01:01:56,600
To make this real, you have to benchmark.
1829
01:01:56,600 --> 01:01:58,440
Before you turn a workflow into a skill,
1830
01:01:58,440 --> 01:01:59,480
you need a baseline.
1831
01:01:59,480 --> 01:02:00,760
Take 10 common requests.
1832
01:02:00,760 --> 01:02:02,360
Run them through your old system.
1833
01:02:02,360 --> 01:02:05,280
Record the success rate, the token count, the latency,
1834
01:02:05,280 --> 01:02:06,920
and how many turns it took to finish.
1835
01:02:06,920 --> 01:02:10,400
Then, deploy the skill and run those same 10 requests again.
1836
01:02:10,400 --> 01:02:11,440
Compare the numbers.
1837
01:02:11,440 --> 01:02:12,960
If the success rate didn't go up
1838
01:02:12,960 --> 01:02:14,720
or the token count didn't go down,
1839
01:02:14,720 --> 01:02:15,640
the skill didn't help.
1840
01:02:15,640 --> 01:02:16,400
Don't guess.
1841
01:02:16,400 --> 01:02:17,440
Measure.
1842
01:02:17,440 --> 01:02:19,480
Real world testing is the final hurdle.
1843
01:02:19,480 --> 01:02:21,720
Lab tests are clean, but users are messy.
1844
01:02:21,720 --> 01:02:23,240
They ask things you didn't expect.
1845
01:02:23,240 --> 01:02:25,000
They use language you didn't plan for.
1846
01:02:25,000 --> 01:02:25,920
Collect the logs.
1847
01:02:25,920 --> 01:02:27,120
Look for the failure modes.
1848
01:02:27,120 --> 01:02:28,600
Maybe an overbroad description
1849
01:02:28,600 --> 01:02:30,560
is making the skill fire too often.
1850
01:02:30,560 --> 01:02:32,520
Maybe an API changed and your bundled script
1851
01:02:32,520 --> 01:02:34,040
is now spitting out garbage.
1852
01:02:34,040 --> 01:02:35,880
Maybe two skills are now locked in a conflict
1853
01:02:35,880 --> 01:02:37,080
you didn't see in the lab.
1854
01:02:37,080 --> 01:02:39,360
When the data shows a skill is missing its targets,
1855
01:02:39,360 --> 01:02:40,200
you refactor it.
1856
01:02:40,200 --> 01:02:41,920
If it's trying to do too much, you split it.
1857
01:02:41,920 --> 01:02:44,200
If it's not being used, you retire it.
1858
01:02:44,200 --> 01:02:45,800
Let the data drive the architecture.
1859
01:02:45,800 --> 01:02:46,960
Not your assumptions.
1860
01:02:46,960 --> 01:02:48,360
Implementation patterns.
1861
01:02:48,360 --> 01:02:49,960
Where do you actually start when you're ready
1862
01:02:49,960 --> 01:02:51,320
to build your first skill?
1863
01:02:51,320 --> 01:02:53,640
Most teams make this harder than it needs to be.
1864
01:02:53,640 --> 01:02:56,040
They spend weeks designing a perfect modular architecture
1865
01:02:56,040 --> 01:02:57,720
or planning 30 skills in advance.
1866
01:02:57,720 --> 01:02:59,880
They create taxonomies and governance frameworks
1867
01:02:59,880 --> 01:03:01,760
before they've even written a single line of code.
1868
01:03:01,760 --> 01:03:03,280
That's organizational theater.
1869
01:03:03,280 --> 01:03:04,120
And it doesn't help.
1870
01:03:04,120 --> 01:03:05,160
You need to start small.
1871
01:03:05,160 --> 01:03:06,360
Pick one workflow.
1872
01:03:06,360 --> 01:03:07,600
Look for something high frequency
1873
01:03:07,600 --> 01:03:09,520
that your agents handle repeatedly.
1874
01:03:09,520 --> 01:03:12,480
It should be a task where you know every single step by heart.
1875
01:03:12,480 --> 01:03:14,600
Maybe it's a password reset for your IT agent
1876
01:03:14,600 --> 01:03:16,600
or an onboarding checklist for HR.
1877
01:03:16,600 --> 01:03:18,920
It could even be a purchase or a validation
1878
01:03:18,920 --> 01:03:20,200
for a finance copilot.
1879
01:03:20,200 --> 01:03:23,280
Just find one task that users ask about 10 or 20 times a week.
1880
01:03:23,280 --> 01:03:24,280
That is your candidate.
1881
01:03:24,280 --> 01:03:25,320
Extract the logic.
1882
01:03:25,320 --> 01:03:27,480
But don't try to redesign or optimize it yet.
1883
01:03:27,480 --> 01:03:29,680
Just move what you already have into a skill.
1884
01:03:29,680 --> 01:03:32,080
You likely have instructions sitting in a document,
1885
01:03:32,080 --> 01:03:34,440
a wiki or an old email that nobody reads.
1886
01:03:34,440 --> 01:03:35,680
That is your starting material.
1887
01:03:35,680 --> 01:03:37,280
Write a skilled MD file
1888
01:03:37,280 --> 01:03:38,440
and give it a clear name.
1889
01:03:38,440 --> 01:03:39,960
Write the instructions in markdown
1890
01:03:39,960 --> 01:03:42,160
and bundle any templates or reference data.
1891
01:03:42,160 --> 01:03:43,200
It won't be perfect.
1892
01:03:43,200 --> 01:03:44,400
And that's fine.
1893
01:03:44,400 --> 01:03:45,720
Perfection comes later.
1894
01:03:45,720 --> 01:03:49,160
The naming convention matters more than you think.
1895
01:03:49,160 --> 01:03:50,720
Vague names cause rooting failures
1896
01:03:50,720 --> 01:03:52,840
because they confuse the orchestrator.
1897
01:03:52,840 --> 01:03:55,000
A name like HR help is too broad.
1898
01:03:55,000 --> 01:03:57,360
So it triggers on everything HR related
1899
01:03:57,360 --> 01:03:59,280
even when you need something specific.
1900
01:03:59,280 --> 01:04:01,440
HR leave eligibility triage is much better
1901
01:04:01,440 --> 01:04:02,680
because it's precise.
1902
01:04:02,680 --> 01:04:04,600
The pattern that actually works is domain
1903
01:04:04,600 --> 01:04:06,400
then specific task then constrained.
1904
01:04:06,400 --> 01:04:07,920
The domain narrows the field,
1905
01:04:07,920 --> 01:04:09,680
the task clarifies the action
1906
01:04:09,680 --> 01:04:11,640
and the constraint marks the boundary.
1907
01:04:11,640 --> 01:04:13,720
If you name a skill, finance, invoice approval
1908
01:04:13,720 --> 01:04:17,040
under $10,000, the orchestrator knows exactly when to use it.
1909
01:04:17,040 --> 01:04:18,560
Writing instructions for an orchestrator
1910
01:04:18,560 --> 01:04:20,000
is a specific discipline.
1911
01:04:20,000 --> 01:04:21,720
You aren't documenting for humans here.
1912
01:04:21,720 --> 01:04:23,560
You're explaining a process to a reasoning system
1913
01:04:23,560 --> 01:04:25,640
that needs to know exactly which decisions to make.
1914
01:04:25,640 --> 01:04:28,080
Use numbered steps and make every condition explicit.
1915
01:04:28,080 --> 01:04:30,680
Instead of saying high amounts need more review,
1916
01:04:30,680 --> 01:04:31,760
give it a clear rule.
1917
01:04:31,760 --> 01:04:34,520
Tell the system that if an amount is under 5,000,
1918
01:04:34,520 --> 01:04:35,720
it goes to level one.
1919
01:04:35,720 --> 01:04:38,280
If it's between 5,000 and 50,000, it goes to level two.
1920
01:04:38,280 --> 01:04:41,320
If it exceeds 50,000, it requires executive sign-off.
1921
01:04:41,320 --> 01:04:43,720
You need to be concrete, specific, and conditional.
1922
01:04:43,720 --> 01:04:46,280
The soft-pointing pattern is how you reference tools
1923
01:04:46,280 --> 01:04:49,080
without locking the skill to one specific piece of software.
1924
01:04:49,080 --> 01:04:51,080
Don't say call the approval API.
1925
01:04:51,080 --> 01:04:53,800
Instead, tell the system to root to the approval workflow
1926
01:04:53,800 --> 01:04:54,760
for this level.
1927
01:04:54,760 --> 01:04:57,240
You shouldn't embed specific API endpoints.
1928
01:04:57,240 --> 01:04:59,480
Reference logical capabilities instead.
1929
01:04:59,480 --> 01:05:01,080
Tell the skill to validate the vendor
1930
01:05:01,080 --> 01:05:04,160
against the tax ID service without specifying which service
1931
01:05:04,160 --> 01:05:05,240
or how to call it.
1932
01:05:05,240 --> 01:05:06,760
This allows the same skill to work
1933
01:05:06,760 --> 01:05:08,880
across different co-pilot studio setups.
1934
01:05:08,880 --> 01:05:10,400
One agent might have a built-in workflow
1935
01:05:10,400 --> 01:05:12,800
while another delegates to an external system.
1936
01:05:12,800 --> 01:05:14,640
The instructions work both ways because the reference
1937
01:05:14,640 --> 01:05:16,160
is logical, not technical.
1938
01:05:16,160 --> 01:05:17,920
Versioning is how you stop skills from turning
1939
01:05:17,920 --> 01:05:19,080
into technical debt.
1940
01:05:19,080 --> 01:05:21,680
You have to treat them like code, give them version numbers,
1941
01:05:21,680 --> 01:05:23,560
and document every change you make.
1942
01:05:23,560 --> 01:05:26,160
When you update a skill, increment that version number,
1943
01:05:26,160 --> 01:05:28,320
so you know exactly what's running in production.
1944
01:05:28,320 --> 01:05:30,000
If something breaks after an update,
1945
01:05:30,000 --> 01:05:32,360
you can just roll back to the previous version.
1946
01:05:32,360 --> 01:05:34,440
If you need to know why the behavior changed,
1947
01:05:34,440 --> 01:05:35,600
your change log will tell you,
1948
01:05:35,600 --> 01:05:37,560
this turns your skills into reliable assets
1949
01:05:37,560 --> 01:05:39,640
rather than mysterious black boxes.
1950
01:05:39,640 --> 01:05:41,280
The A-LIM integration is where the skill
1951
01:05:41,280 --> 01:05:43,120
becomes a real enterprise asset.
1952
01:05:43,120 --> 01:05:45,480
You aren't just saving a file on a hard drive.
1953
01:05:45,480 --> 01:05:48,000
You're adding it to a solution in the power platform
1954
01:05:48,000 --> 01:05:51,600
that moves through your dev, test, and production environments.
1955
01:05:51,600 --> 01:05:53,200
When you update a skill, that update
1956
01:05:53,200 --> 01:05:54,920
moves through your existing pipeline.
1957
01:05:54,920 --> 01:05:56,120
When you retire a skill,
1958
01:05:56,120 --> 01:05:58,320
it's removed from every environment at once.
1959
01:05:58,320 --> 01:05:59,680
This is version control and governance
1960
01:05:59,680 --> 01:06:01,160
built directly into the system,
1961
01:06:01,160 --> 01:06:02,640
not bolted on as an afterthought.
1962
01:06:02,640 --> 01:06:04,800
Implementation patterns are where theory finally
1963
01:06:04,800 --> 01:06:06,120
becomes operational.
1964
01:06:06,120 --> 01:06:07,720
You aren't just scaling one skill.
1965
01:06:07,720 --> 01:06:09,480
You're establishing a repeatable practice.
1966
01:06:09,480 --> 01:06:12,760
Start small, name things precisely, and write clearly.
1967
01:06:12,760 --> 01:06:14,560
If you do this with your first skill,
1968
01:06:14,560 --> 01:06:17,320
scaling to 1,000 others becomes a simple repetition
1969
01:06:17,320 --> 01:06:19,000
of the same process.
1970
01:06:19,000 --> 01:06:21,600
The strategic shift, the transformation happening right now
1971
01:06:21,600 --> 01:06:23,000
isn't just a small change.
1972
01:06:23,000 --> 01:06:24,000
It's architectural.
1973
01:06:24,000 --> 01:06:25,800
We are moving away from the old model
1974
01:06:25,800 --> 01:06:27,480
where you build one omniscient agent
1975
01:06:27,480 --> 01:06:29,920
that tries to know everything about your entire organization.
1976
01:06:29,920 --> 01:06:31,800
The new model is an agent that knows exactly
1977
01:06:31,800 --> 01:06:34,600
what it needs to know, only when it needs to know it.
1978
01:06:34,600 --> 01:06:36,200
That sounds like a small distinction,
1979
01:06:36,200 --> 01:06:37,600
but it changes everything.
1980
01:06:37,600 --> 01:06:39,480
The old model told us to build a chatbot
1981
01:06:39,480 --> 01:06:41,240
and give it every piece of knowledge possible.
1982
01:06:41,240 --> 01:06:42,920
We thought comprehensive men smart.
1983
01:06:42,920 --> 01:06:44,160
We thought it meant useful.
1984
01:06:44,160 --> 01:06:45,960
The agent would load everything up front
1985
01:06:45,960 --> 01:06:48,320
from HR policies and IT procedures
1986
01:06:48,320 --> 01:06:50,560
to finance workflows and compliance rules.
1987
01:06:50,560 --> 01:06:51,440
It was a polymath.
1988
01:06:51,440 --> 01:06:54,280
We assumed that if the agent read every manual cover to cover,
1989
01:06:54,280 --> 01:06:55,280
it could answer anything.
1990
01:06:55,280 --> 01:06:56,080
But here's the problem.
1991
01:06:56,080 --> 01:06:58,800
Omniscience is expensive, it's slow, it's prone to errors,
1992
01:06:58,800 --> 01:07:00,240
and it simply doesn't scale.
1993
01:07:00,240 --> 01:07:01,800
The new model is fundamentally different.
1994
01:07:01,800 --> 01:07:03,640
You build a focused agent that has the ability
1995
01:07:03,640 --> 01:07:05,240
to load expertise on demand.
1996
01:07:05,240 --> 01:07:07,200
It becomes selective about what it looks at.
1997
01:07:07,200 --> 01:07:09,960
An agent in this model doesn't pretend to know everything.
1998
01:07:09,960 --> 01:07:11,720
It knows a little bit about the whole company.
1999
01:07:11,720 --> 01:07:13,840
And a lot about what is relevant right now.
2000
01:07:13,840 --> 01:07:16,040
When a user asks about leave eligibility,
2001
01:07:16,040 --> 01:07:18,760
the agent doesn't waste time rummaging through payment systems
2002
01:07:18,760 --> 01:07:20,000
or compliance training.
2003
01:07:20,000 --> 01:07:22,320
It loads the leave expertise, period.
2004
01:07:22,320 --> 01:07:24,200
If the conversation shifts to a new topic,
2005
01:07:24,200 --> 01:07:25,920
the agent swaps the expertise.
2006
01:07:25,920 --> 01:07:28,520
This shift ripples through every part of the system.
2007
01:07:28,520 --> 01:07:30,440
The efficiency gain is the most obvious part.
2008
01:07:30,440 --> 01:07:31,640
We've seen the data.
2009
01:07:31,640 --> 01:07:33,880
Lean context windows lead to faster inference.
2010
01:07:33,880 --> 01:07:36,520
Using fewer tokens per turn lowers your operational costs
2011
01:07:36,520 --> 01:07:39,240
and fewer reasoning loops mean less latency for the user.
2012
01:07:39,240 --> 01:07:42,160
But this isn't just about speed, it's about sustainability.
2013
01:07:42,160 --> 01:07:45,200
A monolithic agent gets heavier as your organization grows.
2014
01:07:45,200 --> 01:07:46,720
You add more policies and procedures,
2015
01:07:46,720 --> 01:07:49,880
the instruction file balloons, and performance starts to degrade.
2016
01:07:49,880 --> 01:07:53,120
Eventually, the cost per conversation rises until you hit a wall.
2017
01:07:53,120 --> 01:07:54,800
A modular agent grows differently.
2018
01:07:54,800 --> 01:07:57,280
You can add new skills, but the baseline stays lean.
2019
01:07:57,280 --> 01:08:00,600
The system scales because you aren't forcing every single conversation
2020
01:08:00,600 --> 01:08:03,360
to carry the weight of every piece of knowledge you own.
2021
01:08:03,360 --> 01:08:06,200
The governance gain is quieter, but it's just as important.
2022
01:08:06,200 --> 01:08:09,760
When your rules are modular, ownership is distributed across the company.
2023
01:08:09,760 --> 01:08:13,080
A skill for leave eligibility stays under HR's control.
2024
01:08:13,080 --> 01:08:14,760
An approval workflow belongs to finance.
2025
01:08:14,760 --> 01:08:18,280
Each team manages its own expertise, so updates happen independently.
2026
01:08:18,280 --> 01:08:20,720
When HR changes a rule, they update their skill
2027
01:08:20,720 --> 01:08:23,040
without worrying about breaking a finance workflow.
2028
01:08:23,040 --> 01:08:24,760
This makes everything auditable.
2029
01:08:24,760 --> 01:08:29,160
You can trace any decision back to a specific version of a skill at a specific time.
2030
01:08:29,160 --> 01:08:31,800
If you need to see every skill that touches customer data,
2031
01:08:31,800 --> 01:08:33,280
you can find them in seconds.
2032
01:08:33,280 --> 01:08:35,800
Modular ownership creates modular accountability.
2033
01:08:35,800 --> 01:08:37,800
Reliability ties all of this together.
2034
01:08:37,800 --> 01:08:40,960
When an agent loads targeted guidance at the right moment,
2035
01:08:40,960 --> 01:08:42,120
it makes better decisions.
2036
01:08:42,120 --> 01:08:43,840
The signal to noise ratio improves,
2037
01:08:43,840 --> 01:08:46,440
because the model isn't drowning in irrelevant data.
2038
01:08:46,440 --> 01:08:49,720
When you measure this, accuracy improves consistently.
2039
01:08:49,720 --> 01:08:51,280
The effect compounds over time.
2040
01:08:51,280 --> 01:08:53,080
Better guidance leads to fewer mistakes
2041
01:08:53,080 --> 01:08:55,080
and fewer turns to reach a resolution.
2042
01:08:55,080 --> 01:08:56,920
The scalability gain is structural.
2043
01:08:56,920 --> 01:08:59,240
A monolithic agent eventually hits a hard limit.
2044
01:08:59,240 --> 01:09:01,760
If you add too many tools or too much knowledge,
2045
01:09:01,760 --> 01:09:03,360
the orchestrator becomes unreliable.
2046
01:09:03,360 --> 01:09:06,360
It loses the path because too many directions are possible at once.
2047
01:09:06,360 --> 01:09:09,160
A modular agent scales because every skill is independent.
2048
01:09:09,160 --> 01:09:12,800
You can run 10 skills or a thousand without the complexity becoming exponential.
2049
01:09:12,800 --> 01:09:17,440
You can handle more users because the token load for each conversation is predictable and lean.
2050
01:09:17,440 --> 01:09:19,240
All of this matters for your AI roadmap,
2051
01:09:19,240 --> 01:09:21,760
because it's the difference between a tactical experiment
2052
01:09:21,760 --> 01:09:23,360
and a sustainable operating model.
2053
01:09:23,360 --> 01:09:26,480
Experiments prove value, but they always hit a wall.
2054
01:09:26,480 --> 01:09:29,920
Operating models scale because they are built for growth from day one.
2055
01:09:29,920 --> 01:09:33,160
A modular skills architecture is how you move from one to the other.
2056
01:09:33,160 --> 01:09:34,280
Common mistakes.
2057
01:09:34,280 --> 01:09:37,440
Teams building skills for the first time usually hit the same walls.
2058
01:09:37,440 --> 01:09:39,080
It's not because the concept is difficult,
2059
01:09:39,080 --> 01:09:40,680
it's because the details matter
2060
01:09:40,680 --> 01:09:43,040
and details are where your intention meets reality.
2061
01:09:43,040 --> 01:09:46,200
The first mistake is treating skill descriptions like documentation.
2062
01:09:46,200 --> 01:09:48,000
Most makers write descriptions for humans.
2063
01:09:48,000 --> 01:09:49,120
They write things like,
2064
01:09:49,120 --> 01:09:52,840
"This skill helps with HR questions about pay, benefits and time off."
2065
01:09:52,840 --> 01:09:54,360
That sounds like a help file.
2066
01:09:54,360 --> 01:09:56,240
It tells a person what the skill does,
2067
01:09:56,240 --> 01:09:57,760
but it does nothing for the orchestrator.
2068
01:09:57,760 --> 01:10:01,240
The orchestrator has to decide if this skill matches what the user wants.
2069
01:10:01,240 --> 01:10:03,040
A vague description creates noise.
2070
01:10:03,040 --> 01:10:04,880
Is this the right skill for leaf questions?
2071
01:10:04,880 --> 01:10:07,480
Maybe. Is it for benefits enrollment? Probably.
2072
01:10:07,480 --> 01:10:10,560
So when a user asks about benefits, the orchestrator gets confused.
2073
01:10:10,560 --> 01:10:12,960
It loads both skills, or it guesses wrong,
2074
01:10:12,960 --> 01:10:14,920
and loads the leaf skill when it shouldn't.
2075
01:10:14,920 --> 01:10:18,520
Your description needs to be a rooting signal, not marketing copy.
2076
01:10:18,520 --> 01:10:20,760
It must be precise, bounded.
2077
01:10:20,760 --> 01:10:24,320
It needs to say exactly when to use it and when to stay away.
2078
01:10:24,320 --> 01:10:26,760
Use for questions about a cruel and blackout periods.
2079
01:10:26,760 --> 01:10:28,960
Do not use for benefits enrollment.
2080
01:10:28,960 --> 01:10:30,680
Now the orchestrator has clarity.
2081
01:10:30,680 --> 01:10:32,320
The second mistake is the mega skill.
2082
01:10:32,320 --> 01:10:35,720
This happens when teams decide all of HR should be one single skill.
2083
01:10:35,720 --> 01:10:37,800
Leave, benefits, pay and policy.
2084
01:10:37,800 --> 01:10:40,000
All bundled into one massive instruction set.
2085
01:10:40,000 --> 01:10:42,040
The skill fires on every HR question,
2086
01:10:42,040 --> 01:10:44,920
then the model has to struggle to find the right subdomain.
2087
01:10:44,920 --> 01:10:46,880
You've created reasoning overhead you didn't need.
2088
01:10:46,880 --> 01:10:50,640
You just moved the monolithic problem from the agent level down to the skill level.
2089
01:10:50,640 --> 01:10:52,360
Mega skills are slow to update.
2090
01:10:52,360 --> 01:10:55,360
Changing one rule about leave might break how the whole skill behaves.
2091
01:10:55,360 --> 01:10:59,240
They are hard to test because you're validating five different domains in one unit.
2092
01:10:59,240 --> 01:11:00,400
The fix is to split them.
2093
01:11:00,400 --> 01:11:03,840
Leave is a skill, benefits is a skill, compensation is a skill.
2094
01:11:03,840 --> 01:11:05,160
Each one loads independently.
2095
01:11:05,160 --> 01:11:06,880
Each one is testable in isolation.
2096
01:11:06,880 --> 01:11:10,240
And each one can be owned by the team that actually knows the data.
2097
01:11:10,240 --> 01:11:12,280
The third mistake is ignoring the governance surface.
2098
01:11:12,280 --> 01:11:15,120
You bundle your scripts, you test them, you push the production,
2099
01:11:15,120 --> 01:11:16,400
but you never review the code.
2100
01:11:16,400 --> 01:11:17,400
You never sandbox it.
2101
01:11:17,400 --> 01:11:18,640
You never look at the logs.
2102
01:11:18,640 --> 01:11:21,840
You just assume the script does what the instructions say it does.
2103
01:11:21,840 --> 01:11:22,680
Then something breaks.
2104
01:11:22,680 --> 01:11:23,520
Data leaks out.
2105
01:11:23,520 --> 01:11:25,040
A credential is exposed.
2106
01:11:25,040 --> 01:11:26,240
Performance drops for no reason.
2107
01:11:26,240 --> 01:11:27,640
You have no audit trail.
2108
01:11:27,640 --> 01:11:29,760
You don't know what the script actually did.
2109
01:11:29,760 --> 01:11:31,120
So you can't trace the incident.
2110
01:11:31,120 --> 01:11:34,480
This happens because teams think scripts are just implementation details.
2111
01:11:34,480 --> 01:11:36,120
They think governance is just overhead.
2112
01:11:36,120 --> 01:11:37,240
They are wrong.
2113
01:11:37,240 --> 01:11:39,720
Scripts are untrusted until you prove otherwise.
2114
01:11:39,720 --> 01:11:41,080
Governance isn't an add-on.
2115
01:11:41,080 --> 01:11:42,160
It's the foundation.
2116
01:11:42,160 --> 01:11:43,120
Review the code.
2117
01:11:43,120 --> 01:11:43,880
Sandbox it.
2118
01:11:43,880 --> 01:11:44,760
Monitor the output.
2119
01:11:44,760 --> 01:11:46,160
If you aren't willing to do that,
2120
01:11:46,160 --> 01:11:48,360
don't bundle scripts.
2121
01:11:48,360 --> 01:11:52,000
The fourth mistake is failing to measure the before and after.
2122
01:11:52,000 --> 01:11:54,520
You roll out skills and just assume they're helping.
2123
01:11:54,520 --> 01:11:56,560
Three months later, you realize you aren't sure.
2124
01:11:56,560 --> 01:11:57,920
Did you actually save tokens?
2125
01:11:57,920 --> 01:11:59,280
Did the latency go down?
2126
01:11:59,280 --> 01:12:01,320
Are the agents actually better at their jobs?
2127
01:12:01,320 --> 01:12:03,720
You don't know because you never set a baseline.
2128
01:12:03,720 --> 01:12:04,960
Measurement takes discipline.
2129
01:12:04,960 --> 01:12:07,240
You have to run the tests before you change anything
2130
01:12:07,240 --> 01:12:08,800
and then run them again after.
2131
01:12:08,800 --> 01:12:11,040
It's the only way to know if the work actually mattered.
2132
01:12:11,040 --> 01:12:13,640
Without numbers, you're just flying on intuition.
2133
01:12:13,640 --> 01:12:14,880
And intuition is expensive.
2134
01:12:14,880 --> 01:12:17,520
The fifth mistake is forgetting that skills are guides,
2135
01:12:17,520 --> 01:12:19,000
not guarantees.
2136
01:12:19,000 --> 01:12:20,920
A skill gives the model expert reasoning.
2137
01:12:20,920 --> 01:12:22,280
But the model is still a model.
2138
01:12:22,280 --> 01:12:23,800
It can still misinterpret the guide.
2139
01:12:23,800 --> 01:12:26,200
It can still hallucinate details that aren't there.
2140
01:12:26,200 --> 01:12:28,840
It can ignore your instructions and just improvise.
2141
01:12:28,840 --> 01:12:30,880
A skill makes a good outcome more likely,
2142
01:12:30,880 --> 01:12:32,280
but it doesn't make it certain.
2143
01:12:32,280 --> 01:12:33,760
Some teams learn this the hard way.
2144
01:12:33,760 --> 01:12:36,240
They deploy a skill to enforce a critical process
2145
01:12:36,240 --> 01:12:38,080
only to find out the model skipped a step.
2146
01:12:38,080 --> 01:12:40,000
The protection wasn't real.
2147
01:12:40,000 --> 01:12:41,440
Skills are guidance layers.
2148
01:12:41,440 --> 01:12:42,600
They are not guardrails.
2149
01:12:42,600 --> 01:12:44,600
If you need to enforce a rule absolutely,
2150
01:12:44,600 --> 01:12:47,280
you need a structural guardrail, a workflow step,
2151
01:12:47,280 --> 01:12:50,760
an approval gate, something deterministic.
2152
01:12:50,760 --> 01:12:53,160
The skill can guide the thinking that leads to the gate,
2153
01:12:53,160 --> 01:12:56,520
but the gate itself has to be part of the architecture.
2154
01:12:56,520 --> 01:12:58,760
The architecture principle, skills aren't just
2155
01:12:58,760 --> 01:13:00,480
a feature you add to an agent.
2156
01:13:00,480 --> 01:13:01,840
They are a structural principle.
2157
01:13:01,840 --> 01:13:02,960
The principle is simple.
2158
01:13:02,960 --> 01:13:05,640
Load only what you need exactly when you need it.
2159
01:13:05,640 --> 01:13:07,320
This applies to your instructions.
2160
01:13:07,320 --> 01:13:08,640
It applies to your knowledge.
2161
01:13:08,640 --> 01:13:10,160
It applies to your tools.
2162
01:13:10,160 --> 01:13:11,840
And to the reasoning itself, the payoff
2163
01:13:11,840 --> 01:13:13,440
is something you can actually measure.
2164
01:13:13,440 --> 01:13:16,400
Faster agents, lower costs, higher reliability.
2165
01:13:16,400 --> 01:13:18,440
Most organizations are still building monoliths.
2166
01:13:18,440 --> 01:13:19,560
That is the status quo.
2167
01:13:19,560 --> 01:13:20,880
But now you know the difference.
2168
01:13:20,880 --> 01:13:22,280
The question is what you do with it.
2169
01:13:22,280 --> 01:13:24,640
If this changed how you think about AI agents,
2170
01:13:24,640 --> 01:13:26,280
follow me, mycopeters on LinkedIn.
2171
01:13:26,280 --> 01:13:28,600
And if you want more of this, leave a review.
2172
01:13:28,600 --> 01:13:30,200
It helps more people find it.