Copilot Studio's New Harness - Here's What You Need to Know
Microsoft just moved the new agent harness out of preview
If you’ve been watching Copilot Studio since June, you already know the platform got rebuilt from the engine out. The new authoring experience showed up, then quietly got relabeled as public preview a few days later. That preview period is now wrapping up and it was announced that it is in GA today.
Microsoft is calling it a new harness, and it’s worth understanding what that actually means before you decide how to handle your existing agents.
What a “harness” Actually Is
This is the part that trips people up, because it’s not Microsoft marketing language - it’s borrowed from the coding agent world.
A harness is the runtime layer around the model. It manages the loop: the model decides what to do, the harness executes it, feeds back the result, and lets the model decide again. It handles tool calls, file access, code execution, and context management.
Copilot Studio agents now run on the same harness lineage as GitHub Copilot’s coding agent. Practically, that means:
Recursive task execution. The agent can work a problem across many steps instead of one reason-and-respond pass.
Code execution. Python, JavaScript, and Bash run inside the agent’s container.
Built-in skills. Document extraction, file generation, and similar capabilities ship preloaded.
Stronger instruction adherence. This was the pitch in June and it’s the thing most worth testing yourself.
The practical version: an agent can now pull project data, generate an Excel summary, build a PDF brief, and attach it to an outbound email - using the default orchestrator and its tools, without you wiring up each step.
Workflows Designer
Workflows are the deterministic counterpart to the agent. Same visual canvas, but you control which steps are rules and which steps are AI:
Combine triggers, connector actions, and an agent node on one canvas
The agent node classifies, extracts, validates, and picks the next action based on grounding knowledge
Human-in-the-loop approvals and refinement loops are first-class
Connects to SharePoint, Outlook, Teams, Dataverse, Planner, and M365 agents like Researcher
Quality-of-life additions worth knowing about: drag-and-drop node composition, testing individual nodes in place without a full run, versioning and variation comparison, variable folding, and inline canvas notes.
Node-level testing is the one I expect people to actually feel day to day. Debugging a workflow by triggering the whole thing and reading logs gets old fast.
Where Triggers Live Now
Worth calling out because it changes how you architect autonomous scenarios.
Triggers no longer sit inside the agent editor. You build a workflow with a recurrence or connector trigger, then position the agent as a step inside it. Autonomous behavior is now a workflow concern, not an agent setting.
If you’ve built autonomous agents the old way, this is the structural change to plan around.
Skills Replace What Topics Used to Do
Topics are gone in the new experience. Skills and workflows are the replacement, but they are not a one-to-one swap and I’d push back on anyone who tells you otherwise.
Skills are markdown instruction sets the orchestrator loads into context when it decides they’re relevant. They’re reusable, they travel with the agent through solutions and ALM, and you can import skills authored for GitHub Copilot or Claude Code without rewriting them.
That last point is more interesting than it sounds. Skill work is becoming portable across platforms, which is not something we’ve had before.
But if you relied on topics for tightly scripted conversation flow, the current answer is to write a skill describing the structure and trust the orchestrator to follow it. For a lot of scenarios that’s fine. For tightly regulated conversation paths, test it hard before you commit.
What To Do About Existing Agents
Nothing urgent. Classic agents keep running.
That said, the two experiences are different enough that “migrate later” turns into a real project rather than a settings change. If you have agents heavy on topics, autonomous triggers, or channel publishing beyond Teams and Copilot, start scoping the work now rather than in Q4.
The Copilot Studio CAT team has published migration guidance, a technical deep dive deck, and a skills gallery. Worth the read before you plan anything.
Bottom Line
This is the biggest architectural shift Copilot Studio has had since it stopped being Power Virtual Agents.
The direction is clear and I think it’s the right one - agents handle judgment, workflows handle the parts that need to be identical every time, and you decide where the line sits. That’s a better model than forcing everything into one or the other.
The open question is instruction adherence at scale. Long-horizon execution is exactly where agents drift, and demos are not production. The June-to-August preview window was short for a change this fundamental.
Build something real on it before you rewrite your architecture around it. But start building - this is where the platform is going.