From Agent Builder to Copilot Studio
Lesson 4.2 covered Agent Builder: describe a task in plain language, add some files, and get an agent that opens like any other chat. That covers a real slice of what people need, but it stops at a fairly shallow ceiling. An Agent Builder agent cannot branch on conditions, call other systems through connectors, run on its own schedule, or hand off a step to a human for approval.
Copilot Studio is where you go once you hit that ceiling. It is Microsoft's full low-code studio for building agents and the automations around them, and it is the same product whether IT builds something tenant-wide or you build something for your own team. The building blocks are agents (the conversational layer), workflows (drag-and-drop automations, newer and AI-assisted), and agent flows (a Power Automate-style flow that can run standalone or be attached to an agent as a callable tool). For this lesson, agent flows are the one worth learning first, because they are the cleanest way to add real automation to something you already built in Agent Builder or Copilot Studio.
What an agent flow actually is
An agent flow is a deterministic, rule-based automation: the same input produces the same output, every time, unlike an agent's more open-ended reasoning. It needs a trigger, the event that starts it, and at least one action, a task it performs. Copilot Studio's designer supports conditions, loops, child flows, human-in-the-loop approval steps, and AI actions that call a language model mid-flow, so a flow can be far more than "if this, then that."
Three trigger types cover almost everything you will need:
- Manual (instant): you run it on demand, useful while building and testing.
- Scheduled: it runs on a recurring schedule you set, the direct equivalent of a Claude Cowork scheduled task (lesson covered in the Claude track, and conceptually familiar if you have used any calendar-based automation before).
- Event-based: it starts when something else happens, including the specific "When an agent calls the flow" trigger, which is what lets a flow serve as a callable tool inside an agent. Microsoft's own example: your manager sends an email (the trigger), Copilot posts a message in Teams (the action).
Building your first one: a scheduled status flow
A good first project, small enough to finish in one sitting: a flow that runs every Monday morning, checks a SharePoint list of open client items, and posts a short status message in a Teams channel.
- Open Copilot Studio and start a new agent flow (or attach one to an existing agent as a tool).
- Describe what you want in plain language. Copilot Studio drafts the trigger and the first actions for you, the same natural-language-first pattern Agent Builder uses.
- Set the trigger to Scheduled, pick the recurrence (weekly, Monday, a set time), and confirm the time zone.
- Add the action that reads the SharePoint list, then a condition step if you only want items that are still open, then the action that posts to Teams.
- Run a manual test before you trust the schedule. Test runs of an agent flow in the designer do not draw down your credits, so iterating on the flow itself costs nothing. One exception to know about: agents built on the newer GitHub Copilot harness are billed from the moment you start building, testing included, so check which kind of agent you are working in before assuming a test is free.
- Publish once it behaves the way you expect.
Attaching a flow to an agent as a tool
The more powerful pattern is not a standalone flow but one that an agent calls mid-conversation. Build the flow with the "When an agent calls the flow" trigger, then add it as a tool inside your agent (the same agent you might have started in Agent Builder, or a new one built directly in Studio). Now, when someone asks the agent a question that needs a live lookup or an external action, instead of only answering from its knowledge sources, it can call the flow, get a real result back, and use that result in its reply. This is the structural piece that turns "an agent that talks about your process" into "an agent that actually touches your process."
Autonomous agents: working without being asked
Some Copilot Studio agents can be given their own account, which lets them work proactively rather than only in response to a message. Microsoft's own examples are process-shaped: onboarding a new employee, or coordinating the logistics of a recurring meeting, where the agent initiates steps as part of a shared workflow rather than waiting to be prompted each time. This is a genuinely different mode from everything covered so far in the Copilot track, where every agent, connector, and flow still starts from something a person typed or scheduled. Treat it as a capability to be aware of rather than something to build on day one: it is the deepest end of the pool, and it is worth trying only once a simpler flow or agent is already working reliably.
What it costs: Copilot Credits
Building requires one of a few paths: a free Copilot Studio user licence assigned by an admin (which needs a tenant Copilot Credit pack behind it), the Copilot Studio authors role granted in the Power Platform admin center, an existing Microsoft 365 Copilot licence (which lets you extend Copilot with agents), or an individual trial licence that lets you build and test but not publish.
Since September 2025, usage is billed in Copilot Credits rather than the older "messages" unit, though the quantity per prepaid pack and the pay-as-you-go rate did not change in that switch. Credits measure the effort an agent spends retrieving information, answering, and running actions, so a flow with several actions and an AI step costs more than a one-line lookup. One genuinely useful exception: agents used inside Copilot Chat, Teams, or SharePoint that rely only on classic answers, generative answers, or standard Microsoft Graph grounding are zero-rated and do not draw down your Copilot Studio credits at all, which is exactly why Agent Builder agents and ordinary Copilot grounding (lessons 4.1 and 4.2) feel free to use day to day, while Studio-built flows and agents carry a real, metered cost.
Capacity is enforced monthly and unused credits do not roll over, so it is worth checking your tenant's usage against the agent usage estimator Microsoft publishes before you build something that will run on every message in a busy channel.
There are three separate ways a tenant can pay for this, and it is worth knowing which one yours uses before you build anything that will run often. A prepaid subscription, bought as a standalone Copilot Studio purchase in the admin center, covers building on any supported channel plus premium connectors. Pay-as-you-go links an environment to an Azure subscription through a billing policy, so you only pay monthly for what you actually use, and unlinking stops the billing outright. A Copilot Credits prepurchase plan is a one-year prepaid pool of credit units bought through the Azure portal, generally the better fit once usage is predictable and high enough to justify committing in advance. None of these numbers are fixed long-term; Microsoft revises its credit pricing periodically, so check the current licensing guide before scoping anything that will run continuously in production rather than relying on a figure quoted here.
A worked example, start to finish
Say your team runs a weekly check on open client items in a SharePoint list, and right now someone manually opens the list every Monday, scans it, and pastes a summary into a Teams channel. Here is the same task, built as a flow from scratch, with the actual prompts and choices you would make along the way.
Start the build by describing the end state rather than the mechanics: "Every Monday at 8am, check the Open Client Items list in SharePoint, and post a short summary in the #client-ops Teams channel listing anything still marked In Progress or Overdue." Copilot Studio's natural-language builder reads this and proposes a trigger (Scheduled, weekly, Monday) and a first pass at the actions (a SharePoint "get items" step, a filter, a Teams "post message" step). This is the same description-first pattern used throughout the Copilot track, from Agent Builder's own build flow back in lesson 4.2.
From there you refine rather than start over. If the generated filter is too broad or too narrow, you adjust the condition step directly: "status equals In Progress OR status equals Overdue" rather than Copilot's first guess. If the Teams message reads flat, you can route it through an AI action that rewrites the raw item list into a short, readable summary before it posts, which is the "AI actions that use LLMs" piece Copilot Studio's designer supports mid-flow, not something you have to build in a separate tool. Each of these is a small, visible edit in the designer, the same "test it, see what's wrong, fix that one thing" loop that runs through every build tool in the Copilot track.
Before publishing, run it manually at least twice: once with the list in its normal state, and once after deliberately adding or removing an item, to confirm the filter and the summary both still behave the way you expect. Only then switch it from a manual trigger you are testing to the live Scheduled trigger, and only then is it drawing on your tenant's Copilot Credits on an ongoing basis.
Staying in control
Three habits keep a Copilot Studio build from becoming a maintenance problem six months from now, the same concern that comes up with Agent Builder sharing (lesson 4.2) and connector permissions (lesson 4.5), just one level deeper here because flows can act, not only answer.
Keep human approval on anything that writes, sends, or spends. Copilot Studio's designer supports an explicit human-in-the-loop approval step: use it on any action that posts somewhere visible, updates a record, or triggers a downstream system, at least until the flow has a track record. A flow that only reads data and summarizes it is low risk to automate end to end; one that sends an email or updates a CRM record is not.
Know who can see and edit what you build. A flow or agent built under your own account behaves like anything else you create in the Microsoft 365 ecosystem: it is private until you explicitly share it, and sharing it only shares the specific knowledge sources and connections you added, never blanket access to your mailbox or files, the same permissions model that governs Agent Builder sharing.
Watch your credit usage before scaling up. A flow that runs once a week on a short list is cheap. The same flow attached as a callable tool inside a busy agent, firing on every relevant message in an active channel, can draw down a prepaid capacity pack far faster than expected, because capacity is enforced monthly and unused credits do not carry over. Check Microsoft's own agent usage estimator before wiring a flow into anything high-traffic, and treat autonomous agents in particular as something to pilot narrowly before letting them run unsupervised on a real business process.
Where this sits in the toolkit
Think of the last three lessons as a single ladder: Agent Builder (4.2) for a quick, no-code agent you describe in a sentence; Copilot Studio's agent flows for anything that needs a real trigger, a condition, or a connector; and autonomous agents for the rare case where the work itself should start without a person asking. Most of what a regular employee needs stops at Agent Builder. Copilot Studio is for the person on a team who owns a recurring process and wants to stop running it by hand.
When Studio is the wrong call
Not every recurring task deserves a Copilot Studio build. If an Agent Builder agent (lesson 4.2) already handles the work without needing a trigger, a condition, or an outside connector, build it there: it costs no credits, and it stays easier for someone without Studio experience to maintain if they pick it up later. Move to Studio only once you notice you are trying to force a task into something that only describes and answers, rather than acts on a schedule or an event. That turning point, "I want this to just happen, not only to be something I can ask about," is the clearest signal you are ready for an agent flow.
Try it
Pick one small, recurring task you currently do on a schedule by hand (a weekly status check, a monthly reminder, a recurring data pull). In Copilot Studio, describe it in plain language, set a Scheduled trigger that matches your real cadence, and run a manual test before publishing. If you already have an Agent Builder agent from lesson 4.2, try attaching a simple flow to it as a callable tool instead, and ask the agent a question that should trigger that tool.