Microsoft's named agents solve common patterns. For everything else, Copilot Studio is the build platform — a visual editor, connectors to your systems, your own knowledge, and publishing as a real agent inside Copilot Chat or Teams. This is the Pro+ tier: knowing when to build, how to structure an agent, and how to ship it without breaking things.
Step 1 of 60% complete
First principle
Don't build what you can configure
Copilot Studio is powerful, and that's the trap — it's easy to spend three weeks building something a named agent already does. The first skill isn't building. It's knowing when not to.
Predict first
You want an agent that researches across your SharePoint docs and the web, then writes a brief. Build it in Copilot Studio, or use a named agent?
When to build · the anatomy
Build only when a named agent can't reach it
Build custom when
It uses systems Microsoft's agents don't touch (line-of-business apps, niche SaaS)
Your process has unusual logic (industry compliance, multi-step approvals)
You need it embedded in a specific product or branded UX
Use a named agent when
The job is general (research, analysis, notes, sales prep)
Microsoft already covers ~80% of it
The last 20% is solvable by configuration or prompting
When you do build, every Copilot Studio agent is the same four parts:
Trigger
What starts it — a user invoking it by name, an inline phrase, or another system calling it.
Topic
A focused conversation flow it handles (e.g. "Submit an expense"), with its own dialog and branching.
Knowledge
The data it searches to answer — specific SharePoint pages, docs, sites.
Actions
The things it can do — Power Automate flows, custom connectors, native Microsoft actions.
Do it · architect the agent
Spec out a "PTO Request" agent
You're building an agent that lets staff book time off. Choose the right option for each of the four parts — the blueprint fills in as you go.
PTO Request Agent · blueprint
Trigger— not set
Topic— not set
Knowledge— not set
Action— not set
Part 1 of 4
Knowledge
The data decides the quality
Most custom-agent failures aren't the flow — they're the sources. The agent searches what you point it at, so messy, stale, or contradictory data makes it confidently wrong.
Curate, don't dump
Point it at 5–15 specific, well-maintained pages — never "all of SharePoint."
One source of truth per topic
If the PTO policy lives in three places, the agent contradicts itself. Pick one canonical doc; redirect the rest.
Fresh & structured
Recent, well-headed docs get used reliably; two-year-old wiki pages and "final v2 (draft)" do not.
Knowledge quality is the single biggest factor in agent quality. A well-prompted agent on bad data is worse than a basic agent on great data.
Actions, safely
Let it do things — with a hand on the wheel
Actions are what make an agent more than a chatbot. They also carry the risk, so tier them:
Lookups → run freely
Read-only and reversible: check a PTO balance, a ticket status, a contract date. No confirmation needed.
Create / modify → confirm first
File an expense, submit PTO, open a ticket — always show a summary and require a confirm before executing.
Financial / external / irreversible → human in the loop
Approving money, sending external email, changing production data — never auto. A person decides.
And ship it in order: internal test (try to break it) → fix the top issues → pilot with 10–30 users → general release with training. Skip the pilot and the bugs surface org-wide.
The call
Your PTO agent's action can file the request straight into HR's system. How do you wire it?
🛠️
Lesson complete
You can architect an agent, not just use one
What you can do now
Check a named agent can't do it before you build custom
Structure an agent as trigger → topic → knowledge → actions
Curate knowledge tightly — one canonical, current source per topic
Confirm before create/modify actions; never auto-run anything irreversible
Test, then pilot with a small group, before going org-wide
Your move: build one small, scoped agent
Pick a real annoyance — PTO requests, expense submissions, helpdesk routing. Build it end-to-end in Copilot Studio: trigger, one focused topic, a single canonical knowledge source, and a confirm-first action. Pilot it with five people. The skill is in the iteration, not version one.
Copilot at scale — rollout, governance & the AI architect
Building one agent is the start. Next is the org view: adoption playbooks, prompt libraries by department, security and compliance settings, agent inventory, and measuring real ROI.
Hey! I'm your AI Coach for this lesson on Copilot Studio. Ask me about the build-vs-buy call, structuring an agent, curating knowledge, or wiring actions safely. What are you thinking of building?
Free lesson coaching is limited to 3 questions. Upgrade to Pro for unlimited coaching on every lesson.