Module 8 of StartCloud's Copilot Essentials learning pathway, in five short units with a knowledge check: what a Copilot agent actually is compared with a chat prompt, the difference between Agent Builder and Copilot Studio, four realistic small-business agent examples, the governance and data-access risks including authentication and knowledge sources, and how to tell when building an agent is over-engineering.
Copilot Agents and Copilot Studio in Plain English
An agent is not just a clever prompt
Ask Copilot a question and you get an answer, and then the whole arrangement evaporates. Tomorrow the next person asks the same question, phrases it slightly differently, and gets a slightly different answer. That is chat. It is useful, and it does not accumulate.
An agent is what you get when you stop retyping the setup. It is an assistant with a job description: standing instructions about what it is for, a defined set of sources it is allowed to draw on, and sometimes the ability to take an action rather than just describe one. It reasons about the request and works out the next step, within the fence you built for it.
What it is for, how it should answer, what it must not do. Written once, applied every single time, instead of retyped by whoever happens to be asking.
The sources it is allowed to draw on, such as a SharePoint site, a folder, specific files, or content pulled in through a Copilot connector.
The actions it can take, like calling a workflow or a business system. This is the part that turns an answering machine into something that does a job.
"Using the leave policy in this document, tell me how much notice someone needs to give for annual leave." Great answer, gone in a puff of smoke, and the next person has to know which document to attach.
An assistant sitting in your Teams called "HR questions", already pointed at the policy library, told to answer only from those documents and to say so when it does not know. Everyone gets the same answer, and nobody has to go hunting for the file.
A prompt is asking a colleague a question. An agent is writing the answer down properly, once, and putting it somewhere everyone can reach. The value is not that the AI got cleverer. It is that the knowledge stopped living in one person's head.
There are two doors into building agents, and picking the wrong one is how small businesses end up with a six week project where an afternoon would have done.
Microsoft's own advice is straightforward: use Agent Builder in the Microsoft 365 Copilot app for straightforward jobs, and move to Copilot Studio when you need actions that reach into other systems. Start on the left. Only move right when the agent hits a wall you can actually name.
Agent Builder, inside the Microsoft 365 Copilot app
The simple option, and where almost every small business should begin. You describe the agent in plain language, or configure it by hand, then test it before anyone else sees it.
- Point it at knowledge sources like SharePoint sites, folders or specific files
- Write instructions telling it what it is for and how to behave
- Add starter prompts so colleagues know what to ask
- Included with a Microsoft 365 Copilot licence, no extra tooling
Copilot Studio, the full workbench
Where you go when the agent needs to do something rather than just answer. Copilot Studio builds agents, workflows and agent flows, and lets them talk to your business systems.
- Connect to other systems through connectors and APIs
- Publish to Teams, Microsoft 365 Copilot, your website and other channels
- Build workflows with human review steps built in
- Test, version and publish with proper controls around it
People on the included Copilot Chat can use agents too, through a pay-as-you-go arrangement billed in Copilot Credits against an Azure subscription, or through prepaid capacity. Your admin sets up a billing policy and can put a budget limit on it with email alerts at set thresholds. Set that limit on day one. An agent that turns out to be popular is a lovely problem right up until the invoice arrives.
Both tools let you test an agent privately before sharing it. Use that. Ask it the twenty questions your team actually asks, including the awkward edge cases, and see how often it invents something or answers confidently from a document that is three years out of date. Better you find that than a new starter does.
The demos you see at conferences are agents that reconcile invoices across four systems. Ignore them. The agents that actually work in a twenty person business are boringly small, and they all share the same shape: a question people ask constantly, a document that already holds the answer, and one person who is sick of being interrupted about it.
Pointed at your HR and policy library in SharePoint, published in Teams. Answers the leave, expenses and induction questions that currently land on one very patient person's desk. The easiest first agent there is, because the documents already exist and the questions repeat forever.
Same idea, narrower audience. Onboarding steps, who to ask about what, where the templates live, how to book leave. New people ask a hundred small questions in their first fortnight and hate asking most of them out loud.
Grounded on the current price list, standard inclusions and terms, so the team stops quoting from a spreadsheet someone saved to their desktop in 2023. This one only works if somebody owns keeping the source document right, which is the whole point.
Answers common pre-sales questions from your public content and hands the genuine leads to a human. Worth doing, and the one that needs the most care, because it faces the internet and must only ever see content you are happy for strangers to read.
- Does more than one person ask this question, more than once a week?
- Does a document already exist with the right answer in it?
- Is somebody willing to own keeping that document current?
- Would you be comfortable with everyone who can reach the agent reading that source?
Agents are genuinely useful and they are also the easiest way in the whole Microsoft stack to accidentally publish something you did not mean to. Not because the tooling is careless, but because the whole point of an agent is to make information easy to reach, and "easy to reach" is a compliment right up until it is not.
Agents can be set to require a Microsoft sign-in, or to require nothing at all. "No authentication" means anyone with the link can chat with it, which is exactly right for a public website agent and exactly wrong for anything touching internal documents.
An agent is only as well behaved as the site you pointed it at. Aim one at a SharePoint library with a stray folder of salary reviews in it and you have built a very efficient way to find that folder. This is the oversharing problem from Module 4, wearing a friendlier face.
Someone builds it, shares it, then changes roles. Six months later it is confidently quoting a superseded policy to new staff. Every agent needs a named owner and a review date, same as any other business document.
An agent that only answers questions is low risk. An agent connected to systems that can take actions is a different animal, and deserves proper thought about what it is allowed to touch and where a human has to approve a step.
- Data policies in the Power Platform admin centre can require user authentication, block particular knowledge sources, block connectors being used as tools, and block publishing to specific channels
- Publishing an agent to your organisation's app catalogue requires admin approval, so nothing goes wide by accident
- Purview sensitivity labels are respected when agents surface content, and agent activity lands in the audit logs
- Copilot Studio has an analytics view per agent, and admins can see credit consumption per agent and per user
When it is over-engineering
The honest answer is that most small businesses need one or two agents, not a fleet. Here is when to put the tools down.
- The process runs twice a month. A pinned document and a decent prompt will do.
- Only one person needs it. That is not an agent, that is a saved prompt.
- The source material is out of date. An agent on stale content just industrialises wrong answers.
- Nobody has volunteered to own it. Build it anyway and you have made someone a maintenance job they did not agree to.
- The real problem is that four systems do not talk to each other. An agent will paper over that beautifully until the day it does not.
Build the policy agent. Give it an owner, a review date, and a small group to test it. Let it run for a month and see whether the interruptions actually stop. If they do, you have earned the right to build a second one. If they do not, you have learned something for the price of an afternoon, and you have not left four abandoned agents sitting in Teams quoting old documents at people. Everything you covered in Module 4 on getting your data ready matters twice as much here.
- Microsoft Learn: Copilot Studio overview
- Microsoft Learn: Agents overview in Copilot Studio
- Microsoft Learn: Agent Builder in Microsoft 365 Copilot
- Microsoft Learn: Choose between Microsoft 365 Copilot and Copilot Studio to build your agent
- Microsoft Learn: Copilot Studio security and governance
- Microsoft Learn: Configure data policies for agents
- Microsoft Learn: Microsoft 365 Copilot pay-as-you-go service overview
Details were current at the time of writing (August 2026). Agents and Copilot Studio are moving faster than any other part of Microsoft 365, so treat screen names and billing details as a starting point and check the links above.
Knowledge check
5 quick questions. Get 4 right and the module is yours.
1. What makes an agent different from a well-written Copilot prompt?
2. You want an agent that answers HR policy questions from your SharePoint policy library. Where should you start?
3. Which setting deserves the most attention before you share an agent?
4. What is the biggest risk of pointing an agent at a SharePoint site you have not tidied up?
5. Which of these is a sign you are over-engineering with agents?