In briefWhat this article is about
Building a first agent takes about forty minutes in a training session. You describe in plain language what it should do, connect a SharePoint site to it, ask it a few questions in the test panel and publish it to Teams. That nearly always goes well, and it is also the part every demonstration shows.
What comes afterwards is less visible and decides whether the agent still exists in three months. Where does it get its answers and are those sources good enough? Who is allowed to see which answer? What does it cost when two hundred people start using it? And who owns it when the person who built it moves to another department? This article walks the route from idea to working agent along those questions, with the rates and the amounts included.
For the IT or information manager who gets asked whether "we could do something like that too", and for the application manager who has already built a first agent and now has to explain what it will cost. The rates and settings below were checked with Microsoft itself on 13 September 2026. Copilot Studio changes quickly; the sources are listed at the end with dates.
01What an agent is, and what it is not
An agent is not a chatbot with a decision tree underneath, even though the first demonstration makes it look like one. Microsoft describes it as an assistant that handles conversations and completes tasks: it follows the instructions you give it, draws on the knowledge sources you connect, and uses tools to actually do something. For every request it reasons about the best next step, rather than walking a path you drew out in advance.
That difference is a practical one. In the older way of working you wrote a conversation route per subject, and anything you had not thought of fell outside it. In the current way you supply instructions and sources and the agent works out how to handle a question. That makes it usable faster and at the same time less predictable, and that tension is what the rest of this article is about.
Alongside agents you can build workflows and agent flows in the same studio: fixed sequences of steps that do behave predictably. The combination is what it comes down to in practice. The agent talks to the person and judges the request, the flow does the repeatable work you would rather nobody reasoned about each time.
02Three engines under one platform
Since 2026 whatever you build in Copilot Studio runs on one of three engines. Microsoft calls this the harness, and it is not a technical footnote: the choice determines how the agent reasons, how complex a task it can take on, what it can do out of the box and how it is billed.
| Engine | What it is meant for | What you need to know |
|---|---|---|
| GitHub Copilot | Reasoning-heavy work and composite business processes. | Consumption starts when you begin building, not when you publish. |
| Standard | Rule-based agents and repeatable, structured conversations. | Consumption counts only after publishing. This is the engine most existing agents run on. |
| Copilot chat | Extending Microsoft 365 Copilot Chat with your organisation’s knowledge. | Your people stay in the environment they know; the agent adds the sources. |
That first point deserves emphasis, because it can produce a surprise at the end of the month. On the heaviest engine, trying things out costs credits too: having a solution generated in plain language, testing it in the preview panel and generating evaluations all consume. On the standard engine the meter starts only once the agent is published. Anyone about to practise with a group would do well to know which of the two they are on.
For most organisations starting here, the standard engine is the right point of departure. An agent answering questions from a handbook, a set of regulations or a product catalogue does not need a deep chain of reasoning, which makes it both cheaper and easier to predict.
03The redesigned building environment
Since June 2026, Copilot Studio opens in a redesigned building environment. This is not a fresh coat of paint but a different way of working, and anyone who knows the old one has to look again. The New experience toggle on the home page takes you back to the familiar environment; both remain, and existing agents keep running.
The most visible difference is that the number of configuration tabs has gone from nine to four: Build, Preview, Evaluate and Monitor. On the Build tab, the instructions, the knowledge sources, the tools, the skills and the chosen model sit side by side on one screen, instead of spread across screens you had to walk through one at a time.
More important than the layout is what you put into it. In the old environment you drew the conversation: a topic, a trigger phrase, a series of nodes. In the new one you describe what the agent should do and leave the reasoning to the engine. That saves a considerable amount of time in the first few hours. It also moves the work: from dragging nodes around to writing instructions that are precise enough, including what the agent explicitly does not do.
Three things that were not there before
Beyond the new layout, three additions matter more in the long run than the screen itself.
- Skills. A way of working that you capture once in a text file of instructions and then hand to several agents. The engine invokes it as soon as a question matches its description. An expenses procedure or a fixed way of reporting no longer has to be written out again in every agent.
- Memory. Turning it on means the agent remembers a user’s preferences between conversations, stored per person. Useful for an assistant someone talks to regularly, and one more reason to decide in advance what you do and do not want remembered.
- Connected agents. One agent at the front door that passes a question to an agent that knows more about it. That is more useful than it sounds, because it is also how you stop every department building its own jack of all trades.
The workflows environment has been redrawn as well: actions, decisions and AI steps now sit on a single canvas rather than in separate screens. And an agent can take an MCP server as a tool, which opens up an external system without a connector having to be built for it.
Skills, memory and connected agents run on the GitHub Copilot engine, and that is the engine where building and testing already consume credits. For an agent that opens up a handbook this is rarely needed; the standard engine does that work more cheaply and more predictably. For an agent that completes a process from beginning to end, it is the other way around. The redesigned environment is therefore not automatically the cheaper choice, and that trade-off returns in the sections that follow.
04The route from idea to agent
The order below is the one we use in training, and it deliberately differs from the order the screen leads you through. The screen starts at building; this list starts at the question of whether there is anything to build.
- Pick a question that gets asked often and has a fixed answer. Not the most complicated process you know, but the most repeated one. The helpdesk question about passwords, the HR question about leave, the question of which version of the handbook applies.
- Identify the source and check whether it is correct. This is the step that gets skipped and costs the most projects. An agent on an outdated handbook gives outdated answers, only faster and with more conviction.
- Create the agent and write the instructions. Describing in plain language what it should do works; the craft is in what you add about what it should not do and when it should hand over to a person.
- Connect the knowledge sources. SharePoint, Dataverse, uploaded documents, public websites or connected business data. How those compare is in the next section.
- Test with questions you did not think of yourself. Have five colleagues from the target group ask ten questions each. Half of what goes wrong comes from questions the builder would never ask.
- Publish to one channel. Usually Teams, because that is where people already are. An agent on four channels at once is four times the maintenance before you know whether the idea works.
- Look at the numbers after two weeks. Copilot Studio shows per agent what was asked, which knowledge source was used and how many credits it cost. That is the moment to decide whether to extend or to stop.
Steps two and five are the ones that make the difference, and neither appears in the product manual. That is not a criticism of Microsoft; it is the reason building an agent is easier than having one.
05Knowledge sources: where the answer comes from
The quality of an agent is the quality of its sources. Copilot Studio supports five kinds, differing in how many you can connect and in how permissions travel with them.
| Source | What it is | Permissions |
|---|---|---|
| Public website | Searches through Bing but returns results only from the sites you specify. Up to 25 sites. | No sign-in needed. |
| Documents | Files you upload to the agent itself. | No sign-in needed. |
| SharePoint | One or more SharePoint addresses, up to 25 in the modern mode. | Work account of the person asking. |
| Dataverse | Structured data from your Power Platform environment. | Work account of the person asking. |
| Connected business data | Systems indexed into Microsoft Search through connectors. | Work account of the person asking. |
That last column is the most important thing in this article. For SharePoint, Dataverse and connected data the agent answers under the account of the person asking, and surfaces only what that person could already open. An agent does not widen permissions.
What it does do is make visible whatever sits too widely shared. A folder of performance reviews that was once set to "everyone in the organisation" by accident goes unnoticed for years as long as nobody searches for it. An agent does search. That is not an argument against agents; it is an argument for aiming the first agent at a site whose permissions you know, and treating the tidying of the rest as a project in its own right.
If you publish an agent without sign-in, for example on a public website for customers, no personal permission profile applies. Everything you connect to that agent is then in principle visible to anyone who talks to it. For an agent on your product documentation that is fine. For an agent on an internal SharePoint site it is an incident waiting to happen.
One more difference that counts in practice: an agent allowed to search the organisation’s whole Microsoft Graph gives noticeably better answers on documents than an agent that only knows one SharePoint address. That capability does cost extra, which is what the section on consumption covers.
06The setting that decides whether you can trust the answers
In the generative AI settings sits a switch few people change deliberately, and it determines how the agent behaves when it does not know: allow ungrounded responses.
With it on, the agent may answer from the model’s general knowledge, even when it used no source or tool at all. With it off, it blocks any answer where no source was consulted, and falls back on saying it cannot find the information. For an agent explaining regulations, off is almost always right: better no answer than a plausible answer that is not in the regulations.
There is a side effect you should know about, because otherwise it produces an error nobody can explain. With the switch off, the agent only answers when the answer also carries a reference to the source. The model occasionally forgets that reference, and the agent then withholds an answer that was actually correct. Asking the same question again may work. Microsoft advises stating explicitly in the agent’s instructions that every statement should cite its source, and avoiding instructions that force a rigid output format, because those push the citation out.
Two settings sit next to it. One decides whether the agent may also search the open web, which helps for an agent about public regulation and is unwanted for an agent about your internal procedures. The other is the level of content filtering, which defaults to high: lowering it produces more answers and less protection at the same time. Neither is a technical knob; they are decisions about what the agent is for.
07What an agent costs
Since 1 September 2025 usage has been billed in Copilot Credits, which were called messages before that. You buy them in advance in packs, or settle afterwards through an Azure subscription. On its own pricing page Microsoft lists a pack of 25,000 credits at 200 dollars per pack per month. Unused credits do not carry over to the next month.
What a conversation costs depends on what the agent does. Microsoft’s rates, per action:
| What the agent does | Credits | With a Microsoft 365 Copilot licence |
|---|---|---|
| Give a pre-written answer | 1 | No charge |
| Generate an answer from a knowledge source | 2 | No charge |
| Carry out an action | 5 | No charge |
| Search the organisation’s whole Microsoft Graph | 10 | No charge |
| Steps in an agent flow, per hundred steps | 13 | No charge with the right trigger |
| Heavy reasoning tools, per ten responses | 100 | No charge |
For many organisations the third column is the whole story. If your own employee uses an agent inside Microsoft 365, Teams or SharePoint, and that employee holds a Microsoft 365 Copilot licence, these forms are included. Credits become interesting the moment the agent faces outward, towards customers or towards colleagues without that licence.
Two sums to give a sense of scale, both from the examples Microsoft itself gives. A customer service agent on a website giving four fixed answers and two generated answers per conversation consumes 7,200 credits a day at nine hundred visitors. An internal agent that reacts automatically to an incoming order and carries out four actions consumes 20 credits per run. The difference between those two is not complexity but the number of people.
Once consumption reaches 125 per cent of what you bought, agents are disabled. A conversation in progress is finished, after which users are told the agent has reached its usage limit. In the Power Platform admin centre you can set a monthly cap per agent; that is a minute’s work and it stops a single agent from eating the whole organisation’s capacity. Agent flows have a milder regime: there only new runs are blocked and the agent keeps answering everything else.
If you want to work it out in advance, there is a usage estimator in which you enter the type of agent, the expected traffic, the way it is orchestrated and the connected sources. That is more accurate than an assumption, and it is a good conversation to have with the sponsor before anything gets built.
08Publishing: where the agent ends up
An agent can go to Microsoft Teams, to Microsoft 365 Copilot, to websites and to mobile applications, and agents can work in multiple languages. In practice Teams is nearly always the first channel, for a reason that has little to do with technology: that is where people already are. An agent on an intranet page visited twice a week does not get used, however good it is.
A second decision belongs with it and is often forgotten: how someone signs in. Choose sign-in with the work account and permissions travel along as described above. Choose no sign-in and the agent is the same for everyone. That is a deliberate choice, not a setting you inherit from the example you started with.
Publishing is also not a one-off act. What users see is the published version; changes you make sit in a draft until you publish again. That sounds obvious and it is the most common confusion of the first month: someone adjusts the instructions, sees in the test panel that it works, and cannot understand why the colleague in Teams still gets the old answer.
09The overview that stops you ending up with fifty agents
As soon as building becomes easy, building happens a lot. That is the point at which organisations discover they do not know how many agents exist, who made them and what they are allowed to reach.
Microsoft has an inventory for this. It shows per agent, published and unpublished alike, who created it, when it was last published, to which channels, how users sign in, with how many people or groups it is shared and which connectors are attached. The data refreshes itself; a change is usually visible within twenty minutes. At the time of writing several fields are still in preview, so expect the picture to keep changing over the coming months.
What you do with it matters more than that it exists. Three agreements keep it manageable: every agent has a named owner, every agent has a reason to exist that fits in one sentence, and every agent is reviewed after three months. Agents nobody uses are not a problem as long as you know they are there.
This is also where introducing agents turns into an organisational question rather than a technical one. Anyone who would rather have a structure for that than a set of loose agreements will find it in our AI adoption training based on a framework, which covers assessment, change and governance as one whole.
10Which ideas survive and which do not
After a few years of having the same conversation, a pattern emerges in which proposals are still running three months later.
What usually survives: questions that are asked often and have a fixed, findable answer. The agent on the staff handbook. The agent on the product documentation for the service desk. The agent that takes a request in hand by walking four fixed steps and sending an email at the end. The common feature: a document or a process already exists in which the right answer sits.
What usually does not: agents asked to judge something the organisation has no recorded position on. Agents on a pile of documents where nobody knows any more which one is current. And agents invented to work around an organisational problem, for instance because the knowledge base has not been updated in two years and nobody is given time for it. In that last case you build a faster route to an outdated answer.
Building an agent, then, is rarely the part that takes the most time. Deciding which work lends itself to it and getting the source in order does. Organisations that do that first have three agents in use after a quarter. Organisations that start at the screen have ten that nobody can remember the purpose of.
In closingA level-headed conclusion
Copilot Studio puts building an agent within reach of people who do not program, and that is a genuine shift. But the skill it asks for has moved rather than disappeared. Where it used to be about writing conversation routes, it is now about judging sources, understanding permissions and estimating consumption. That is work for someone who knows the organisation, not necessarily for someone who knows the technology.
The cheapest way to find out whether this is for you is to start small, with a question your service desk gets ten times a week. If that agent works, you have an example with which to hold the conversation about the next five. If it does not, you know why within two weeks, and the reason is usually a source that is wrong rather than a platform that disappoints.
If you would rather do that with guidance, our Copilot Studio training delivers a working agent by the end of the day, built on a knowledge source of your own. If you would rather have the building done for you or alongside you, that is what the Copilot Studio agent building service is for. And if the first question is what agents can do without a paid licence, the article on what Copilot Chat includes draws that line.
SourcesChecked on 13 September 2026
- learn.microsoft.com – The redesigned building environment, the four tabs Build, Preview, Evaluate and Monitor, describing an agent in plain language, and the skills, memory and connected agents available on the GitHub Copilot engine
- learn.microsoft.com – Overview of Microsoft Copilot Studio, what agents, workflows and agent flows are, the three engines and what each is for, creating an agent in plain language, the channels and the address of the studio
- learn.microsoft.com – Knowledge sources in Copilot Studio, the five kinds of source with their limits, answering under the account of the person asking, the ungrounded responses setting, citations and content moderation
- learn.microsoft.com – Copilot Credits billing rates and management, the rates per action, the worked examples for a customer service agent and an order agent, the 125 per cent threshold, the milder regime for agent flows and setting a monthly cap per agent
- learn.microsoft.com – Standard harness licensing, the move from messages to Copilot Credits on 1 September 2025, prepaid packs versus pay-as-you-go, and what is included with a Microsoft 365 Copilot licence
- learn.microsoft.com – Usage-based billing on the GitHub Copilot harness, the point that consumption starts while building, testing and evaluating rather than after publishing, and the credits estimator
- microsoft.com – Copilot Studio pricing, the pack of 25,000 Copilot Credits at 200 dollars per pack per month and paying for consumption without an upfront commitment
- learn.microsoft.com – Agent inventory, what administrators see per agent, the refresh within twenty minutes and the fields still in preview