import AiFigure from ’~/components/posts/base/AiFigure.astro’

TL;DR

Copilot Studio now runs on three harnesses, the runtime that sits between your design and the model, and each one bills differently:

• GitHub Copilot Harness, the new Copilot Studio. Nearly everything is usage-based Copilot Credits: AI-assisted authoring, testing and runtime all draw credits. Only manual Build-tab configuration, publishing and the Monitor tab stay free. An M365 Copilot license buys you nothing here.
• Standard Harness, the classic Copilot Studio. Consumption-based, or covered by the M365 Copilot license, though some premium features stay excluded even when you hold that license.
• Copilot Chat Harness, Microsoft 365 Copilot Chat. Consumption-based, or covered by the M365 Copilot license.

What actually bugs me is further down, but here it is in one line: on the new harness even testing an agent costs credits. Not just the runtime. You can’t try the thing out without paying, and your M365 Copilot license doesn’t cover it.

Why I’m writing this down at all

The new GitHub Copilot Harness has just landed, and it has thrown a lot of people. The confusion is all about the same thing: when, and for what, Copilot Studio actually bills you now. I’ve watched more than one person react to it with a bit of panic, and I understand why.

The reason for the confusion is that since the new harness went GA, “Copilot Studio” is no longer one product with one pricing model. It is three runtimes with three pricing models under one name. If you don’t know which harness your agent runs on, you simply can’t answer the question of what it costs.

So I dug into it.

What a harness even is

You can picture it best with a practical example. If I run Claude’s Opus 5, or even Opus 4.8, directly through Claude Code from Anthropic, the people who actually build that model, my coding sessions come out noticeably better than running the exact same model through a partner surface like GitHub Copilot. On paper it’s the identical model, and for most people that’s where the story ends. But the piece sitting around the model, the thing that feeds in context, calls tools and reacts to what comes back, is what actually decides how good the output is. The best model is only ever as good as the harness wrapped around it.

That piece in the middle is the harness. You design the agent or workflow, the model you picked does the reasoning and generation, and the harness is the runtime in between: it decides when the model gets called, which components it sees, interprets the answer and calls the right tools. Sounds like a detail. It’s actually where it gets decided what your agent can do and what it costs.

Because the harness determines four things at once: how the work gets done (a fixed script, or breaking a goal down into steps on its own), how much you can automate end to end, which capabilities you get out of the box (creating files, skills, memory, tool orchestration), and, yes, how you get billed.

And that’s exactly what’s playing out with Copilot Studio: the classic and the new experience can run the same models, and the harness still makes most of the difference in how good the answers turn out.

The three harnesses and what they hang off

GitHub Copilot Harness

What it can do, per Learn: instead of just following a fixed script it takes a goal, breaks it into steps, calls tools through connectors, knowledge, MCP and connected agents, and adapts when a step fails or the request changes. It natively creates and edits Word, Excel, PowerPoint and PDF files, supports skills and memory, and runs each task in a secured sandbox.

What it hangs off: the new agent experience and the new workflows.

Billing: Copilot Credits, usage-based.

Standard Harness

The classic example is an internal helpdesk that answers standard questions and routes simple requests onward.

What it hangs off: the classic agent experience and Agent Flows.

Billing: consumption-based, or covered by the M365 Copilot user license, following the existing licensing and billing model from the Copilot Studio licensing guide.

Copilot Chat Harness

The narrowest of the three, and the one with the clearest purpose. It connects your enterprise knowledge to Microsoft 365 Copilot Chat so employees get grounded answers without leaving the environment they already work in. Typical case: an onboarding agent that answers from SharePoint content.

Here you only publish to internal teams.

Billing: consumption-based, or covered by the M365 Copilot user license.

How the Standard and GitHub Copilot harnesses work, and why the loop is the real difference

The billing split makes more sense once you see how the two harnesses actually run a request. They don’t just cost differently, they think differently.

The Standard Harness plans, then executes. It reads the request, synthesises a multi-step workflow up front, and runs the authored steps in order. The plan is an explicit object you can look at: collect the inputs, run an action (a connector, a topic, a data query), summarise the response. Because the plan is fixed before anything runs, there’s less live replanning and the whole thing is easier to inspect.

The GitHub Copilot Harness runs a loop instead. It doesn’t commit to a plan up front. It reasons over the latest state, calls a tool or topic, reads the result, decides the next step live, and goes round again: Thought, Action, Observation, Decide, repeat. The plan emerges as it goes, and it can change course after every observation.

That loop is the whole point of the new harness, and it’s a genuine benefit. A plan-and-execute model has to be right about the plan before it has seen any results. The loop doesn’t. When a tool returns something unexpected, when a step fails, when the request turns out to be more complicated than it looked, the loop just reasons over the new state and picks a different next step. That’s what lets it handle the long-running, multi-system work the Standard Harness can’t: it adapts mid-run instead of falling off the end of a script.

The trade-off is the flip side of the same coin, and it ties straight back to the cost section. The loop’s freedom to replan is exactly what makes it consume credits while you build and test, and what makes a run harder to predict up front. Plan-then-execute is cheaper and easier to inspect precisely because it does less thinking on the fly. So the loop isn’t strictly better, it’s better for the class of problem that needs it, which is the same conclusion the pricing pushes you toward from the other direction.

The question I had to answer: can I pick the harness?

That was the most interesting open question for me. If Copilot Studio has three harnesses now, is there a dropdown somewhere?

Short answer: no.

There’s no setting to pick, and no way to change it after the fact. The harness is decided one step earlier: it simply depends on where you create the agent, in the new experience or the classic one.

And it’s a one-way street. Agents created in the new experience can’t be moved into the classic one, and the other way round doesn’t work either. The two are built on fundamentally different architectures.

The licensing comparison: before and now

And now we get to the part that causes the most confusion.

On that last row, because it’s the most misunderstood point: both sides bill in the same currency. Copilot Credits are the shared currency across all Copilot Studio capabilities, and since 1 September 2025 the currency for agents changed from Messages to Copilot Credits, with no change to the amount per prepaid pack or to the pay-as-you-go rate.

Read down that new-experience column and the pattern is stark. On the GitHub Copilot Harness the Build tab, as long as you’re configuring by hand and not letting it author for you, and the Monitor tab are the only two places that don’t touch credits. Everything else does.

So “it used to be free” isn’t true. It was covered, and that’s a different thing.

If you have a Microsoft 365 Copilot license, using Standard Harness agents in Copilot Chat, Teams or SharePoint for classic answers, generative answers or Microsoft Graph tenant grounding doesn’t count against the Copilot Studio message pack or meter. That usage is zero-rated. Agent flow actions triggered by M365-Copilot-licensed users are included at no extra cost too, though only for flows using the “When an agent calls the flow” trigger; other triggers still consume credits, and Computer-Using Agents are excluded from the license entitlement altogether.

The crucial catch: none of that applies to the GitHub Copilot Harness. Microsoft states plainly that agents on the GitHub Copilot Harness use usage-based billing for all work, regardless of Microsoft 365 Copilot licensing. So the “we already have the licenses, it’s covered” reasoning holds on the Standard Harness and evaporates the moment you’re on the new one.

Testing and running were, on the Standard Harness with an M365 license, effectively all-inclusive. With one exception I’ll get to in a second.

Something that also applies to the Standard side and gets forgotten a lot: Copilot Studio enforces the capacity you bought on a monthly basis, unused credits don’t roll over to the next month, and if you go over, technical enforcement kicks in. There’s a grace buffer, and per the current guidance enforcement bites at around 125% of your prepaid capacity rather than the instant you hit 100%, but at that point agents get disabled and further invocations are rejected until you top up or the month resets.

What actually bugs me about this

It isn’t the runtime costs. It’s that testing costs money, and the reason gets lost in the noise. The GitHub Copilot Harness is genuinely better: reasoning, tool use, file handling all take a visible jump. But “better” doesn’t mean you type three sentences of instructions and you’re done. A good agent is fast, doesn’t reach for six tools on every little question, and is cost-optimised, and that last twenty percent of quality only comes out of dozens of iterations. Change the wording, test. Swap the knowledge source, test. Pull a tool and see if the answer still holds, test.

Every one of those runs now has a meter on it. Spend an afternoon tuning and re-testing after each change and you can burn through a few hundred preview runs before lunch, each one billed. So the road to a cost-optimised agent is paved with runs that cost money: cost optimisation costs money.

What bothers me more is the effect on behaviour. I work differently when a meter is running. You test less, you test shallower, you skip the edge case that’s probably fine. Then the agent ships with exactly that edge case. My gut says worse-tested agents cost more in production than the test runs you saved.

On runtime costs I’m relaxed: for a manageable group or external users, credits often beat the license route anyway. What’s lost is the harmlessness. Before, I could tell a customer “you already have the licenses, just try it out, it costs nothing extra.” On the GitHub Copilot Harness that sentence is gone. And in an org where someone other than the builder sees the bill, one surprise month is enough to freeze the next agent project in approval. That’s not a cost problem, it’s a political one. (Microsoft is finally shipping guardrails for exactly this.)

There’s a learning-curve angle to this too. A lot of people aren’t fluent at building agents yet, and plenty genuinely don’t know whether an agent even makes sense for their use case until they’ve tried a handful. That trying-out phase is where they find out, and it’s exactly the phase the meter now taxes. That’s why I’d rather see this kind of exploratory use bundled into the M365 Copilot license, or included some other way: let people work out whether it’s worth it before the cost clock starts.

I don’t want to oversell it. The model is fair. Microsoft has to put the compute cost of frontier models somewhere, and consumption reflects real work better than a flat rate. It still takes the lightness out. And lightness was an underrated reason people got started with agents at all.

And how long does the classic one stick around?

If the classic route is cheaper, how long can I keep using it? Officially, indefinitely: the Learn doc says the classic experience stays fully supported alongside the new one. That’s not a deprecation, and there’s no end date.

The only hard dates concern the Teams route, and they live in tenant-only Message Center posts, not the public docs: creating classic agents from the Copilot Studio app in Teams is being retired in favour of the web app, originally slated for around 1 April 2026, then pushed to 30 June 2026. Existing agents keep running and users get redirected automatically. That’s a channel change, not a deprecation, so check your own Message Center for the current date.

For a sense of pace, look at the precedent. The Power Virtual Agents → Copilot Studio rename was late 2023; almost three years on, the migration guide is still live, still updated, and still says extra tooling to migrate classic bots “might” arrive in the future. No binding deadline was ever set, and existing bots keep running. Microsoft is a master at keeping product versions alive in parallel for years.

So the pressure is lower than it feels. Even the advocates I talk to don’t blanket-recommend the GitHub Copilot Harness for everything, and when the newest-thing crowd starts differentiating, that’s a signal. What you should change today is where you create new things, not what you do with the existing ones.

What it costs

I’m going to write something specific about how high the costs actually are, so I’ll keep it short here. For now the one thing worth doing is putting your own scenario into Microsoft’s calculator:

➡️ Copilot Credit Estimator

You pick licensing options, agent types and the features your agent uses, and you see the resulting credit consumption. One caveat to keep in mind: the estimator was originally built for the classic Copilot Studio, not the new experience, so the credit numbers it gives you can be off for a GitHub Copilot Harness agent. Treat it as a starting point for the conversation with finance, not a quote.

What I’m taking away for practice

If there’s one thing this shift makes clear, it’s that good governance matters more now than it ever has. The companies that already sorted out spend policies, thresholds and clear ownership are the ones this lands softly on. The new billing model just slots into controls they were already running, and the move pays off exactly when it counts.

For everyone who hasn’t got there yet, it’s the other way round. The meter is already running, and you’re putting the guardrails up after the spending has started instead of before. That’s the worse place to be, and it gets more expensive the longer it waits.

So the takeaway is simple: sort the governance out now, not once the first surprise bill lands.

Resources

• Microsoft Copilot Credits Guide, August 2026 (PDF)
• Billing and credits overview, Microsoft Learn
• Billing rates and management, Microsoft Learn
• Copilot Credit Estimator
• Introducing a new harness for Copilot Studio, Microsoft Community Hub

import urlSwapGif from ”./assets/workflow-builder-url-swap-copy-paste.gif?url”;

This is my first blog post, and I’m starting with something that kept me busy for quite a few days. I wanted to call an agent from the new Copilot Studio, so the New Experience, out of an existing Power Automate flow. Sounds like a small thing. It really wasn’t.

Let me take you through the whole thing: what the scenario was, where it broke, and how I got it working in the end.

Where I started

We had a Power Automate flow that runs the “Execute Agent and wait” step from the Copilot Studio connector. So it calls an agent I built in Copilot Studio beforehand, and the flow then patiently waits until an answer comes back. With the old Copilot Studio that worked fine, that was our proven setup.

Why I wanted to switch in the first place

The new Copilot Studio (new experience), has been around for a while now. It isn’t GA yet, so not generally available, but I think it’s already surprisingly mature.

What actually triggered all of this was one specific agent. I believe it was a business agent to begin with, and it didn’t work particularly well in the old Copilot Studio. The exact same agent in the new Copilot Studio worked a lot, and I mean a lot better. From what I can tell that comes down to the new orchestrator, or rather the new engine running underneath. So if an agent is behaving oddly for you in the old studio, I’d definitely test it against the New Experience.

And from there the idea was obvious. I take the Power Automate flow I already have and just put the other agent into that step. Same flow, just the agent from the new studio instead of the old one.

Two agents that look exactly alike

To show that nothing exotic is going on here, I built two deliberately boring agents for this article. Both are supposed to do nothing but tell a joke.

One lives in the classic Copilot Studio and is called “Classic - Tell A Joke”.

The other lives in the New Experience and is called “New - Tell A Joke”.

Same model, same instruction, same job. The only difference is which studio the agent sits in. That matters to me because it rules out all the obvious explanations: it isn’t a complicated agent, it isn’t knowledge, it isn’t tools, and it isn’t some setting I forgot on one side.

And then came the error

That’s where it started. And in a way that is easy to miss at first.

The flow runs through just fine. Green check, “Your flow ran successfully”, the “Execute Agent and wait” step says Succeeded. No red failure, nothing. If you only look at the run status, you’d think everything is fine.

The error sits in the response itself. You have to expand the step and look at the body.

And that is where it gets awkward, because the two runs look practically identical at first glance. Here is the run with the classic agent first, the way it is supposed to go:

And here is the same flow with the agent from the New Experience:

Same green banner both times, status Succeeded both times. The entire difference sits in the body:

Spelled out, the response from the New Experience looks like this:

Sorry, something unexpected happened. We're looking into it. Error code: InvalidContent. Conversation ID: {conversation-id}. Time (UTC): 7/29/2026 10:54:59 AM

So technically the agent answers politely, its answer just happens to be an error message. To Power Automate that is a perfectly valid result, hence the green check. And if you process that response further in your flow, you quietly pass this text along, into an email or a Teams post for example.

Two small things only jumped out at me once I put the runs side by side. The broken run is noticeably faster at two seconds than the working one at eight, which makes sense, it bails out immediately. And activities.0.type is endOfConversation for the classic agent but message for the new one. If you want to build a check into your flow, that is probably the more honest anchor than the run status.

And it was stubborn. We tried a few variations, but there was simply no normal way around it. The error stayed.

First glimmer of hope: the workflow builder

After poking at it for a while I had the idea to come at it from the other side. So not use the “old” Power Automate, but the new workflow builder that you now also get through the new Copilot Studio.

Said and done. I rebuilt the exact same scenario there, called the agent as an action, ran it. And lo and behold, it worked. Same agent, just called from the workflow builder, and suddenly it goes through.

And while doing that I noticed something I almost find more important than the workaround itself: the workflow builder can call both kinds of agents. The ones from the New Experience just as well as the classic ones. Classic Power Automate, out of the box, can only call the classic ones.

To prove the other half, I rebuilt the same setup with the classic agent in the workflow builder. Runs through without a hitch as well:

So the direction is unambiguous. The workflow builder isn’t just a new surface for the same thing, here it is the superset. Anyone starting fresh simply has less grief there, because the question of a workaround never comes up in the first place.

That did make me curious. Why does it work here and not in classic Power Automate? The answer is in the connector, but more on that in a second.

The obvious attempt that doesn’t work

My first reflex was: if it runs in the workflow builder, I’ll just copy that agent step over. Right click, copy, which puts the JSON on my clipboard, and paste it back into my old Power Automate flow.

Except that’s exactly the problem. The JSON from classic Power Automate and the JSON from the workflow builder are fundamentally different. You can’t just copy an action from one into the other, at least not from the workflow builder straight into Power Automate. Nothing useful happens.

Why that is becomes obvious the moment you look at what actually lands on your clipboard. Here is what comes out of the workflow builder:

{
  "version": 1,
  "marker": "__WFD_CLIPBOARD__",
  "nodes": [
    {
      "id": "{node-id}",
      "name": "New - Tell A Joke",
      "type": "agent",
      "position": { "x": 566, "y": 278 },
      "data": {
        "config": {
          "mode": "invoke",
          "instructions": "Tell a joke about IT",
          "botSchemaName": "{agent-schema-name}",
          "outputMode": "text",
          "inlineModel": "Sonnet46"
        },
        "outcomes": ["…"]
      }
    }
  ],
  "edges": [],
  "connectionRefs": { "…": "…" },
  "operation": "copy"
}

That’s a graph. Nodes, edges, even the position on the canvas. And right at the top sits its own marker, __WFD_CLIPBOARD__, which is how the workflow builder recognises its own clipboard format. Power Automate doesn’t know that marker and can’t do anything with the structure behind it. Which is why pasting does precisely nothing.

The actual trick: just swap the URL

And now to the part I eventually landed on, which is what solved it.

When I have the workflow builder open, the address bar still says copilotstudio.microsoft.com. So I simply swap that part of the URL for make.powerautomate.com, and the exact same workflow opens up in Power Automate.

https://copilotstudio.microsoft.com/....../<workflow-id>
https://make.powerautomate.com/....../<workflow-id>

And from there I can absolutely right click the agent action, copy it, and paste it into a different Power Automate flow. Take that detour and the JSON suddenly fits.

So it’s two detours: first build the workflow in the workflow builder, because that’s where the agent call works, and then open that same workflow in Power Automate through the URL swap and copy the action from there.

Why any of this makes sense

Now you could fairly ask why I’m going through all this trouble. Surely that’s the same action for calling an agent that I already had in Power Automate anyway.

It isn’t. It’s actually a different connector. It’s just called “Agents”, and here’s the interesting bit: it doesn’t exist in the actual Power Automate at all. It only exists in the workflow builder. So this has nothing whatsoever to do with the original Copilot Studio action “Execute Agent and wait”, it really is a standalone connector with a standalone action at the end of the day. You can’t find it in Power Automate, but you can copy it over using those two detours. And with that it worked after all.

Because once you copy that same action after the URL swap, something entirely different lands on your clipboard:

{
  "nodeId": "New_-_Tell_A_Joke",
  "nodeData": {
    "id": "New_-_Tell_A_Joke",
    "nodeInputs": {
      "parameterGroups": {
        "default": {
          "parameters": [
            {
              "label": "Agent",
              "parameterName": "body/agentId",
              "parameterKey": "inputs.$.body.body/agentId",
              "value": [{ "type": "literal", "value": "{agent-schema-name}" }]
            },
            {
              "label": "Message",
              "parameterName": "body/prompt",
              "parameterKey": "inputs.$.body.body/prompt",
              "value": [{ "type": "literal", "value": "Tell a joke about IT" }]
            },
            { "label": "Request human assistance when unsure": "…" },
            { "label": "Output Properties Schema": "…" }
          ],
          "rawInputs": ["…"]
        }
      }
    },
    "nodeOutputs": { "…": "…" },
    "nodeDependencies": { "…": "…" },
    "operationMetadata": { "…": "…" },
    "settings": { "…": "…" },
    "nodeTokenData": { "…": "…" },
    "nodeOperationInfo": {
      "connectorId": "/providers/Microsoft.PowerApps/apis/shared_agentnode",
      "operationId": "InvokeAgent",
      "type": "OpenApiConnection"
    },
    "nodeConnectionData": { "…": "…" }
  }
}

And there it is in black and white, the connector: shared_agentnode with the operation InvokeAgent. That is emphatically not the Copilot Studio action.

The two formats simply think in different categories:

That’s why direct copy/paste gets you nowhere, and why the URL detour works. In the end you aren’t copying the same JSON at all, you’re getting each surface to hand you the same action in its own format.

The difference shows best when you hang both actions side by side in the same flow. Which is exactly what I did in the end: the classic “Execute Agent and wait” step on the left, the pasted agent action on the right, both pointed at the same New Experience agent.

And there’s one more detail that ties neatly back to the JSON from before: the pasted action doesn’t return its result as responses.0 but as result, alongside status and conversationId. That is exactly the outcomeSchema from the workflow builder JSON. So if you adopt this workaround, you have to point your downstream steps at different field names.

I should be honest about that last point, and it stings more than the table makes it look. The joke agent from earlier takes around 8 seconds through the Copilot Studio action. Through the Agents connector my runs landed between a good 20 and 40 seconds, 22 in the screenshot above for instance. That is three times as long at best, for an agent that does nothing but hand back a single sentence. No knowledge, no tools, no thinking.

Keep that in mind before you drop this workaround anywhere someone is waiting on the answer. In a nightly batch run, half a minute is irrelevant. In a flow hanging off a form or a chat, it very much is not. And if your flow loops over multiple records, it multiplies accordingly.

My assumption is that a fair bit of this is preview-state and that it will get faster. I can’t back that up though, that’s just my hope. At that point what mattered to me was that it ran at all.

My takeaway and what I’m trying next

That’s the workaround we’ve sort of settled on for now. It isn’t pretty, but it does the job. Long term Microsoft wants everyone to move to the workflow builder anyway. It’s just that I don’t want to migrate every workflow over right now, so I’ll take my time and watch how it develops.

What I’d find really cool is being able to migrate this automatically later on. Some kind of migrator that moves existing Power Automate flows into the workflow builder, that would be brilliant.

Something else is heading in that direction now: Microsoft has published its own Power Automate skills, power-platform-skills on GitHub. They let you build, edit, run and debug cloud flows straight from Claude Code or the GitHub Copilot CLI. There is a bundled MCP server doing the work underneath, and authentication goes through the Azure CLI.

To me that is the more interesting route, because you are no longer tied to one particular product, you just use whichever AI you already work with. Whether the skills can deal with the workflow builder or only with classic Power Automate I genuinely don’t know yet. I suspect the latter, but I’ll try it soon and write something about it.

One more thing: all of this is a snapshot that can change quickly. The New Experience isn’t GA yet, and I’d strongly expect Microsoft to fix this properly at some point. Until then, if you’re stuck in the same scenario, don’t waste too much time fighting the classic “Execute Agent and wait”, just try the route through the workflow builder. For me that was the difference.

And if you know a better way, please tell me. I’m curious.

Resources

• copilot-studio-agent-power-automate on GitHub — the exported solution with the working flow and the agent (new experience), plus new-agent-node.json, the JSON for the new agent node to paste straight into your flow.
• power-platform-skills on GitHub — Microsoft’s own Power Automate skills for building, editing, running and debugging cloud flows from Claude Code or the GitHub Copilot CLI.