Copilot Studio: what it can and can't do yet

Copilot Studio builds agents that answer questions and take actions inside Teams and your Microsoft environment. For a 50–500 person business it is genuinely useful for a narrow set of jobs: answering staff questions from a document set you control, running structured intake, and triggering Power Automate flows. It is oversold for everything else, and how well it works depends almost entirely on the quality of the content you point it at.

What it does well

Answering from a document set you control. Point it at your policy library and staff stop asking the same twenty questions. This is the highest-value use and the easiest to get right. Think leave policy, travel and expense rules, the vehicle policy, the site induction pack, how to raise a purchase order. The agent finds the relevant passage, answers in plain language and cites the source document so the person can check.

Structured intake. Instead of a form, a conversation that asks the right follow-up questions and creates the request properly. A form shows every field to everyone. An agent can ask "is this for a project or overhead?" and only then ask for the job number, which means fewer half-filled requests landing on someone's desk.

Triggering flows. "Book me a vehicle for Thursday" becomes an actual booking, because the agent calls a Power Automate flow. The agent handles the conversation; the flow does the work and writes a record. This is where an agent stops being a search box and starts saving time, but every action is something that has to be built and tested, just like any other Power Automate flow.

What it does not do

Reason across systems it cannot see. If the answer requires joining your finance system to your project data, the agent needs that connection built. It does not infer it. "Which jobs are over budget?" is a reporting question, and the honest answer is usually a Power BI report, not an agent.

Fix an undefined process. If three people would give three different answers to a policy question, an agent trained on your documents will be confidently wrong in a fourth way. The agent amplifies whatever is written down, including the gaps.

Replace search on messy content. An agent over a disorganised document library gives you fast access to the wrong version. If your SharePoint has "Leave Policy v3 FINAL", "Leave Policy 2023" and "Leave policy (old)" all sitting side by side, the agent has no reliable way to know which one is current. Structure first, agent second.

Can and can't, side by side

How an agent answers, and when it hands over

The part most demos skip is what happens when the agent does not know. A well-built agent has a clear path for that, and it is designed up front rather than discovered after launch.

That last step is the one that makes the agent improve over time. Every question it cannot answer is a gap in your documentation, and someone should own closing it. If nobody does, the agent stays as good as it was on day one, and staff learn to go back to asking a person.

What determines whether it works

Almost entirely the quality of the source content. An agent over a clean, current, well-structured policy library is excellent. The same agent over a shared drive is a liability.

In practice, "good content" means a few concrete things:

• One current version of each document, with old versions archived out of the agent's reach.
• A named owner per document who updates it when the policy changes.
• Plain headings and short sections, so the passage that answers a question is easy to find and cite.
• Permissions that already make sense. Agents generally respect what the person asking can see. If your SharePoint permissions are loose, the agent can surface things people were never meant to read. Our note on SharePoint permission mistakes covers the common ones.

This is why many agent projects are really content projects with an agent on the end. That is not a reason to avoid them; it is a reason to budget for the content work honestly.

What it costs to run

Copilot Studio licensing has changed several times and is likely to change again. Broadly, it is capacity-based: you buy a pool of messages (or credits) for the tenant, and there is a pay-as-you-go option billed through Azure for usage beyond that. What counts as one message, and whether some staff are covered by existing Microsoft 365 Copilot licences when they use an agent inside Microsoft 365, depends on the current terms. Check Microsoft's current pricing before you budget, and size it from a realistic estimate of questions per week rather than headcount.

The build cost matters more than the run cost for most first agents. A narrow policy agent with one or two actions is a small project; an agent that touches several systems is a single build like any other, scoped the same way.

Is it worth it for you?

A quick way to judge: count how often the question actually gets asked. As an illustrative example, if 200 staff each ask HR or ops one routine policy question a fortnight, that is roughly 100 questions a week. At five minutes each to find and answer, that is around eight hours a week of someone's time, before counting the wait on the asker's side. That is worth automating if a single correct document answers most of those questions. If the answers live in people's heads, the first project is writing them down.

The calculator will run the same arithmetic on your own numbers if you want to check it before talking to anyone.

A sensible first project

1. Pick the question your ops team answers most often. Ask the people who field them; they will know in seconds.
2. Check that a single correct, current document answers it. If not, fix the document first. That fix is valuable even if you never build the agent.
3. Build the agent over that narrow set. One library, a handful of documents, a clear hand-over path for anything it cannot answer.
4. Add one action if it earns its place. A leave request, a vehicle booking, an IT ticket. One that already has a defined process.
5. Measure whether the question stops arriving. Not satisfaction scores; the actual number of times the HR or ops inbox gets the same question.

If you want to see the kinds of agents that suit businesses your size, the agents page has examples, and the Copilot Studio service page explains how we scope one.

The short version

Copilot Studio is good at three things: answering from documents you control, turning forms into conversations, and kicking off flows. It does not join up systems on its own, fix a process nobody has defined, or make a messy library usable. Start with the most-asked question, make sure one good document answers it, build narrow, and measure whether the question goes away.

If you cannot point to the document that contains the answer, the agent cannot either.