Instructions or skills? I made my Copilot Studio agent pick a fight with itself

I went to see a Beatles tribute band this weekend. And of course, the debate started again. Did Paul die in 1966.This time I decided to let a Copilot Studio agent settle it. But that answer was going to cost me credits. The other debate? How many? So I built the same agent two ways. One version has every rule crammed into one instructions field. The other splits those rules into Skills the agent only loads when it actually needs them.

The confusion

Roel Schenk put the rule better than I could in his post on how Skills work in the new Copilot Studio agent experience: if something is true in every conversation, it belongs in instructions. If it only applies to a specific scenario, it belongs in a Skill.

Here’s what that looks like when you actually build it. Click the tab to see the comparison.

Everything in one field means every turn reads every rule, even the ones that have nothing to do with what was just asked. Split into Skills, and the agent only pulls in what the question actually touches. Less irrelevant text in front of the model on any given turn is a win for accuracy and focus. I assumed it was also a straight line to a smaller bill. It isn’t, and Copilot Studio’s own billing model explains exactly why.

What I built

Meet the Fab Four Help Desk, a support agent for a Beatles fan club that is dead serious about tribute show tickets, trivia night rulings, merch returns, and yes, whether Paul is dead.

Agent A, the blob. Just instructions. No knowledge sources, no skills, no tools, purely conversational, so the only thing being tested is how the agent carries its own rules.

Agent B, the Skills version. Same tone, same job, same policies. The instructions field only holds what’s true in every conversation. Everything situational moved into its own named Skill. There are 9 skills.

Round one: one question per skill, and a result I didn’t expect

One prompt per skill, tested individually against both agents:

I'm a member and I need to cancel my spot for next month's tribute show. It's in about three weeks, can I get a refund or do I have to eat the cost?

We had a huge fight at trivia last night. Someone said Ringo wrote "Octopus's Garden" and the quiz master marked it wrong, saying it doesn't matter who sang it. I pulled up a forum post backing me up but got overruled. Who's right here and what's the actual policy for settling this?

Ok serious question, if Paul really did die in 1966 like people say, wouldn't that mess up basically every trivia answer we have about him from '67 onward? Doesn't that need to get sorted before trivia night?

That third one was the deliberate stress test, a Paul is dead question wearing a trivia costume, meant to see whether the Skills agent routed it to the right scenario or drifted into the wrong one.

Here is what the credit consumption showed in Power Platform Admin Center (PPAC)

The blob won. 20.19 credits versus 26.45. Skills cost more, not less. Four scenarios in a few hundred words wasn’t enough weight to punish the blob, so I couldn’t yet tell whether that was the real story or just too small a test to see one. I needed a better instrument than a dashboard total to find out.

Bringing in a second set of eyes

Roel released a local analysis tool for modern Copilot Studio agents. THIS TOOL IS FANTASTIC.

Grab it here: https://github.com/Roelzz/mcs-modern-agent-analyser

You feed it two files pulled straight from the Test pane, the agent’s build definition and a conversation transcript, and it reads back a full breakdown: reasoning trace, tool and skill usage, a per-conversation credit estimate, all running locally with no external LLM involved.

Messages were redacted in export by default, but that doesn’t matter, because the numbers are relative.

The real mechanism, in Microsoft’s own numbers

The tool’s credit estimate is built from Copilot Studio’s published billing rates. A classic answer costs 1.0 credit. A generative answer costs 2.0. And loading a Skill is billed as an agent action, at a flat 5.0 credits, every time.

https://learn.microsoft.com/microsoft-copilot-studio/requirements-messages-management#copilot-credits-billing-rates

The output of this tool is a real beauty.

Rather than paraphrase four separate reports, here’s the actual data, swipe through and see it for yourself. Each one is pulled straight from Roel’s analyzer, same billing rates, same real transcripts. Two separate tests here, run the same way, single one-shot question versus a four-turn thread. The single prompt, same for both agents:

I left my umbrella at last month's tribute show. Can I get it shipped to me, or do I have to come pick it up? Also how long do you hold onto it before it's gone for good?

The four-turn thread jumps across four different topics instead, one skill per turn. Rather than paraphrase four separate reports, here’s the actual data, swipe through and see it for yourself. Each one is pulled straight from Roel’s analyzer, same billing rates, same real transcripts.

Four turns, four Skill loads, four times 5 credits is 20, before the reasoning cost even gets added on top. Both tests land Skills at right around 167 times the blob's estimated cost. That's not two unrelated numbers, that's one fixed tax firing on a predictable schedule. And it lines up (somwhat) cleanly with round one too, my original 26.45 for the Skills agent is close to what four Skill loads worth of agent-action tax plus normal generation would produce, even on short prompts.

Skills billing isn't broken. It's just not what I assumed.

This isn't Microsoft doing something wrong. Loading a Skill is a real orchestration step, the agent has to decide which Skill applies and hand off to it, and that's meaningfully more machinery than an agent just answering directly from what's already in its instructions.

What it means practically is that Skills cost scales with how many times a conversation invokes a Skill, not with how much irrelevant text you kept the model from reading. A conversation that touches four different scenarios pays that tax four times, however small each individual Skill is.

Where Skills still win, because they still do

None of this means don't use Skills. It means don't reach for them expecting a flat credit discount, because that's not automatically what they're for. But it turns out there's a real cost angle too, once you know where to look.

I ran one more test to check it. Same four-message thread structure as round two, but instead of jumping between four different scenarios, all four messages stayed inside one, a fan asking follow-up after follow-up about a scarf they'd left behind.

The agent action tax tells the real story here. It fires exactly once, on the first turn, when the skill loads. Every follow-up after that, turns 2 through 4, only pays the small reasoning cost, the same rate the blob was already paying. The skill stays loaded for the rest of the session instead of reloading every single turn.

Line up all three tests and the pattern is obvious:

Test	Blob	Skills
Single prompt, one topic	0.03	5.03
Four turns, four different topics	0.12	20.18
Four turns, one topic	0.12	5.15

The tax scales with how many different skills get invoked, not with how many turns happen. A conversation that jumps across four scenarios pays that 5 credit tax four separate times. A conversation that stays inside one scenario pays it once, then rides on ordinary reasoning cost no matter how long the follow-up chain runs.

If your agent mostly fields users who ask one kind of question and then dig into it, refunds, one policy, one troubleshooting flow, Skills stop bleeding credits after the first turn and the per-scenario tax amortizes across the whole conversation. If your agent's users bounce between unrelated topics in the same chat, that tax resets every time they change lanes, and the blob starts looking cheap by comparison.

And underneath the cost story, the organizational case for Skills was never about credits in the first place. Skills win on the things that actually matter once an agent gets past a handful of scenarios: you can test one Skill in isolation without re-verifying the other eight. You can hand a single Skill to a teammate to own without them touching the rest of the agent. You can add a tenth scenario without re-reading and re-editing an instructions field that's already hard to scan. And a smaller instructions field does keep the model more focused on what's true every time, which is a real accuracy benefit even when it isn't a cost one.

Put the two together and the decision gets a lot less mysterious. The credit cost is a real, fixed input now, not a hidden one, and you know exactly what shape of conversation makes it worth paying. If a scenario gets asked about constantly, tends to run long once someone's in it, and rarely overlaps with the others, the organizational win and the cost profile both point the same direction, toward Skills. If your agent only has three or four scenarios, they're short, and users tend to ask about several of them in one sitting, the blob might be the cheaper and simpler build, and that's fine too.

One more scenario worth thinking through, even though I didn't test it

My test agent tops out at nine short policies. A real complex agent use case usually carries a lot more than that and skills and instructions are not basic (almost static knowledge responses), so here's a scenario I didn't run, just reasoned through using the mechanism I confirmed today.

Say the fan club also streams trivia night, and someone messages in because the stream keeps freezing.

What actually matters to a fan whose stream just froze isn't which line item shows up on my credit report. It's whether they get an answer that works, and how many messages it takes to get there. On the blob side, that troubleshooting logic is sitting in the same instructions field as fourteen other unrelated policies. Without a clean decision tree to follow, the agent falls back on generic clarifying questions, tries a few things that don't apply, cross-references policy language that has nothing to do with streaming, and slowly narrows in. Frustrating for the fan, slower to a fix, worse odds the first answer even works. On the Skills side, one focused skill holds the whole decision tree. Ask, diagnose, fix, done in a few turns, because it isn't wading through fourteen unrelated scenarios to get there. That's the real win: getting someone to success faster with less back and forth, before a single credit even gets counted.

And here's the part that surprised me putting the numbers next to each other. Today's mechanism means the Skills agent still pays that 5 credit agent-action tax once, up front, no matter how short the resolution ends up being. The blob never pays that tax, so its early turns are cheap on paper. But real troubleshooting answers run longer than a quick policy lookup, and fourteen long, meandering turns add up fast. Somewhere in that stretch, the blob's accumulating reasoning cost should cross the flat tax the Skills agent already paid on turn one, which means the faster, less frustrating experience might end up being the cheaper one too.

I don't know exactly where that crossover sits, because I didn't build this agent and I didn't run it. That's not a gap I'm going to paper over with made-up numbers, the chart above is a projection, not a result. It's the next test on my list, and if your support bot has anything like this shape, a handful of clean policies plus one complex troubleshooting flow, it's worth running on your own agent before you assume either direction. But even without the exact number, the experience argument stands on its own: fewer turns, faster resolution, less frustration, every time, and possibly a lower bill on top of it.

What I'd actually tell you to do

Skills can be cheaper. So can instructions. Which one wins on credits depends entirely on how a conversation moves, one topic or five, a quick answer or a long troubleshooting chain, and that's not something you can guess from a blog post, mine included. Build the same two-version test on whatever you're actually shipping. Pull the credit estimate before you commit to a shape, using Monitor for the billed number and a tool like Roel's analyser if you want to see which Skills are actually firing and when.

But if you're asking which one I'd actually build, it's Skills, and the credit math isn't why. A support agent where one teammate owns the refund policy, another owns the troubleshooting flow, and nobody has to reread a wall of text to add scenario ten, that agent is easier to trust and easier to grow. That's a better experience for the person building it and the person using it. In the real world, that's the thing that wins, regardless of what a single test run says about the bill.

Go build the same test on your own agent and get automating.