A support lead asked me to build an agent that answers policy questions for staff inside Teams. Two weeks later the same team wanted that agent to also file the ticket, email the requester, and escalate if nobody picked it up in an hour. Same tool, two very different bills. That gap, between an agent that talks and an agent that acts on its own, is the whole story of Copilot Studio in 2026, and it is where most teams get the cost math wrong.
What Copilot Studio is, and where it sits in Azure
Copilot Studio is a low-code tool for building AI agents. You describe what the agent should do in plain language, point it at knowledge sources, give it tools, and publish it to a channel like Teams, a website, or Microsoft 365 Copilot Chat. Under the hood it runs on Power Platform, Microsoft’s low-code application layer, and stores structured data in Dataverse, the managed database that ships with Power Platform. If you have built a Power Automate flow before, the shape will feel familiar.
Here is the part people miss. Copilot Studio does not host its own frontier models. When an agent needs to reason, it calls a model, and those models are the same Foundry and Azure OpenAI deployments you have seen throughout this series. Copilot Studio can also reach into Microsoft Foundry to reuse a model you already tuned, and into Azure AI Search to reuse an index you already built. So the low-code surface sits on top of the same Azure plumbing, it just hides most of it. That is the trade you are making: less control, far less setup.
There are three ways to build. A declarative agent is defined by a manifest, a configuration file that lists instructions, knowledge, and connectors, and it runs on Microsoft’s shared model infrastructure. A custom engine agent brings its own model and orchestration, usually built on Microsoft Foundry, when you need a model or logic the declarative path will not give you. Agent flows are the third piece, deterministic sequences of actions that an agent can call or that can run on their own. Most real deployments use a mix.
How an agent actually answers a question
Older bots worked on topics, hand-drawn conversation trees where you mapped every intent to a branch. That still exists and still has its place for tightly scripted flows. The default now is generative orchestration, a planning layer driven by a large language model that reads the user request, breaks it into steps, picks the right knowledge sources and tools, and runs them in order. You write instructions and describe your tools; the model decides the path at runtime.
This is the same idea as the tool-calling loop in Part 21, moved behind a form. The advantage is speed to a working agent. The cost is that you have less say over the exact sequence, and you debug by reading traces rather than stepping through code. Microsoft reported an orchestration update in early 2026 that improved evaluation scores by roughly 20 percent while cutting token use by about half. Treat that as a direction of travel, not a number to quote to a customer.
In practice
Start every agent in generative orchestration and only fall back to scripted topics for the two or three flows that must never improvise, like identity verification or anything with a legal script. I have watched teams try to build the whole agent out of topics out of habit, then spend a week maintaining branches the model would have handled for free.
Agent flows and autonomous triggers
An agent flow is a trigger plus at least one action. A trigger is the event that starts it. That trigger can be instant, meaning you or the agent runs it on demand, scheduled, meaning it fires on a clock, or event based, meaning something happens in another system and the flow wakes up. Actions are the steps: call a connector, run business logic, ask for an approval, write to Dataverse. Copilot Studio ships with a large library of prebuilt Power Platform connectors covering common enterprise systems, and you can add custom ones. the exact connector count against the current catalog before you cite it.
The word that changes your bill is autonomous. A conversational agent waits for a person. An autonomous agent acts on a trigger with no person in the loop, following the instructions and guardrails you set. Newer builds can even drive a computer-using agent inside a flow, clicking through a legacy app that has no API. That is genuinely useful for old systems. It is also the most expensive thing you can turn on, because every self-started run consumes credits whether or not it produced anything a human needed.
Three ways to build, and which to pick
The choice between a declarative agent, a custom engine agent, and an agent flow is really a choice about how much control you need and where the reasoning happens. Here is how I sort them.
| Build type | Where reasoning runs | Reach for it when | Skip it when |
|---|---|---|---|
| Declarative agent | Shared Microsoft model | Fast internal Q and A, knowledge grounding, standard connectors | You need a specific tuned model or custom orchestration |
| Custom engine agent | Your Foundry deployment | You need a chosen or tuned model, full control of the loop | A declarative agent already answers the need |
| Agent flow | Deterministic, no model unless called | Fixed multi step actions, approvals, scheduled or event work | The task needs open ended reasoning every run |
My rule of thumb: reach for a declarative agent first, add flows for the parts that must be deterministic, and only move to a custom engine agent when a declarative agent genuinely cannot use the model or logic you need. The declarative path is where the low-code speed lives. Every step toward custom engine buys control and costs you the setup you were trying to avoid.
What does it cost to run?
Two pricing worlds sit side by side. If your users already hold a Microsoft 365 Copilot license, which lists at 30 dollars per user per month paid yearly, they can build and run internal agents inside Microsoft 365 at no extra cost, with no usage cap. That covers a large share of internal help-desk and knowledge agents.
The moment you cross one of three lines, you enter the Copilot Credit world. Those lines are: publishing to an external channel like a public website, serving users who do not have a license, or running autonomous agents. Credits are sold as packs of 25,000 for 200 dollars per pack per month, which works out to 0.008 dollars per credit. You can also run pay-as-you-go, billed on what you consume with no commitment, or pre-purchase Commit Units for up to 20 percent off. There is no feature difference between the pack and the meter; only the way you pay changes. Note that running agents on the standalone plan requires an Azure subscription.
Worked example
A customer-facing website agent handles 8,000 sessions a month. Say each session averages about 10 credits once you count the generative answer plus a grounded lookup. That is 80,000 credits a month.
On packs: 80,000 divided by 25,000 is 3.2, so you buy 4 packs, which is 800 dollars a month and leaves 20,000 credits unused. On pay-as-you-go: 80,000 times 0.008 dollars is 640 dollars a month, and you pay only for what you use.
Now add an autonomous flow that re-checks 2,000 stale tickets a night at roughly 25 credits each. That alone is 1.5 million credits a month, about 12,000 dollars, and it can run whether or not anyone reads the result. Autonomous is where budgets get away from people.
| Scenario | Monthly credits | Pay-as-you-go | Notes |
|---|---|---|---|
| Internal agent, licensed users | 0 billed | Included | Covered by Microsoft 365 Copilot |
| Website agent, 8,000 sessions | 80,000 | 640 dollars | Per-session credit rate is illustrative |
| Autonomous nightly checks, 2,000 per night | 1,500,000 | 12,000 dollars | Runs with no user present |
A minimal declarative agent
Most of the build is point-and-click, but declarative agents are defined by a manifest you can read and version. Below is a trimmed shape of what that configuration looks like, showing instructions, a knowledge source, and a single connector action. Field names differ across the manifest schema versions, so treat this as the shape, not a copy-paste spec. against the current schema before you ship it.
name: Policy Helper
description: Answers HR policy questions and files a ticket
instructions: >
Answer only from the HR policy knowledge source.
If the user asks to open a case, call file_ticket.
If you are not confident, say so and offer to escalate.
capabilities:
- knowledge:
source: azure_ai_search
index: hr-policy-index
- action:
connector: servicenow
operation: file_ticket
auth: entra_id
guardrails:
allowed_topics: [hr_policy, benefits, leave]
escalation: human_reviewExpected result: published to Teams, the agent answers policy questions from the Azure AI Search index and, on request, files a ticket through the ServiceNow connector under the caller’s Entra ID identity.
Failure mode: leave out the guardrails block and the agent will happily answer off-topic questions from its base model, which is how a policy bot ends up giving tax advice. Scope the allowed topics before you publish, not after someone screenshots it.
Where governance lives
Because Copilot Studio runs on Power Platform, its governance is Power Platform governance. You manage agents from the Power Platform admin center, set data loss prevention policies on which connectors an environment may use, and store structured data in Dataverse under the same access model as the rest of your Power Platform estate. Identity comes from Entra ID, so an agent action carries the caller’s permissions rather than a shared key.
For oversight, agent activity and cost surface in the Power Platform admin center, with usage and risk analytics flowing into Microsoft Purview and Viva Insights. The practical warning: hand a business user Copilot Studio without a DLP policy on the environment and they can wire an agent to a connector that reaches data it should never touch. Set environment boundaries and connector policies before you invite builders in, not after the first audit finding.
My take
The comparison people reach for is Copilot Studio versus the code-first frameworks from Part 21. That is the wrong axis. The real question is who owns the agent. If a business team owns it and IT sets the rails, Copilot Studio wins on time to value every time. If a platform team owns a shared agent that many products depend on, the pro-code path gives you the testing and version control you will wish you had. Pick by ownership, not by feature checklist. On AWS the same split shows up between Amazon Q Business and building on Bedrock, which I covered in the AWS series.
When not to use Copilot Studio
I will be blunt about the cases where I steer teams away. If your agent needs a specific open-weight model, deterministic version pinning, and a full test suite in CI, you are fighting the low-code surface, and the frameworks in Part 21 will serve you better. If your workload is a single high-volume, latency-sensitive API call rather than a conversation, a direct Foundry deployment is cheaper and simpler than routing it through an agent. And if you have no Microsoft 365 estate at all, much of the value, the free internal path, the Teams channel, the Purview reporting, simply does not apply to you.
None of that makes Copilot Studio a weak tool. It makes it a specific one. It is the fastest way to put a governed agent in front of Microsoft 365 users, and a poor fit for problems that were never about Microsoft 365. Knowing which one you have saves a rebuild.
Start internal, buy credits only when you leave Microsoft 365
Here is my recommendation, plainly. Build your first agent as an internal declarative agent for licensed users, where it costs nothing beyond the license you already bought, and prove it works. Add agent flows for the deterministic steps. Only reach for the credit meter when you genuinely cross a line, an external channel, unlicensed users, or autonomous runs, and when you do, model the credit math for the autonomous piece first because that is the line item that surprises people. Set the DLP and environment policies before builders arrive, not after.
Next in the series I move from building agents to trusting them: evaluation and observability in Microsoft Foundry, where you measure whether any of these agents are actually good before they reach a user. If you take one action from this part, open the Power Platform admin center and check whether an environment DLP policy is in place today.
References
- Microsoft Learn: What is Copilot Studio
- Microsoft Learn: Generative orchestration guidance
- Microsoft Learn: Agent flows overview
- Microsoft: Copilot Studio pricing and plans
About The Author
DrJha