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.
Update · September 10, 2026 — Copilot Studio now builds apps, not just agents. Microsoft announced natural-language app building in Copilot Studio and Copilot Cowork. In Studio, a new App (Preview) tile sits alongside Agents and Workflows: describe the outcome, users, data and actions you need, and Studio uses agentic coding to produce a working app scaffold that you refine in conversation, preview, and — if you want — inspect at the code level. In Cowork the same capability is the /app skill, available now through the Microsoft Frontier program; the Studio tile is rolling out in public preview during the week of September 10.
Why it belongs in this lesson: the same rules apply. Apps use connectors (including Work IQ for organizational context) to read and write back to systems inside your Microsoft 365 tenant boundary; identity is Microsoft Entra by default; published apps appear as an inventory in the Microsoft 365 admin center, and people find shared ones at managedapps.cloud.microsoft.com. Apps support Git-backed source control, deployment stages and version isolation. Building and running them is billed on the usage-based Copilot credits model — so pilot on a real-but-small process first. The “don’t build what you can configure” test in the next step now covers apps too.
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.