Copilot Studio was rebuilt while your agents kept running

In short. Microsoft rebuilt Copilot Studio. An agent’s behavior is now authored as Markdown files loaded on demand, a new orchestrator does the heavy lifting, and the classic experience keeps running alongside. The real question is not whether to migrate, it is what to keep.

What changed

On June 9, 2026, Microsoft published the rebuild of Copilot Studio. The nine configuration tabs become four: build, preview, evaluate, monitor. The rest sits on the same screen.

Underneath, the orchestrator is new. It is built on a coding harness and a command-line layer, which gives it stronger instruction adherence, the ability to work on long-horizon tasks and break a problem into sub-tasks, to process large volumes of content and to produce files. In plain terms, it behaves more like a coding agent than a dialogue engine.

The visible novelty is skills. A skill is a Markdown file with a name, a description and a body of instructions. The orchestrator reads the descriptions, then loads the full content only when the task calls for it. You can write them by hand, upload them, reuse them across agents, and import the ones you already have for GitHub Copilot or Claude Code.

Around that: skills, tools, knowledge and connected agents as the main surfaces, a memory surface in preview, and a redesigned workflow designer with agent nodes and MCP servers in preview. The classic experience has not disappeared. The two coexist.

Why it is not a facelift

The real move is this: behavior leaves the instruction block.

It used to fit in one block with a ceiling, and rules piled up in it until nobody could say which one applied. Now each procedure is a named file, loaded only when it is needed. The rest of the time it costs nothing to the context.

What genuinely changes is that behavior becomes a versionable asset. A Markdown file goes into a repository, gets reviewed through a pull request, gets shared across agents, and keeps a history. That is the shift I already watched happen in software development: the logic moves out of configuration and into code.

The format is open, and that is deliberate. The same file serves Microsoft, GitHub Copilot and Claude. Behavior written once can follow an organization from one tool to the next, which was not true of topics and templates two years ago.

What you should not migrate

The classic experience is still supported. It runs, it is proven, and nothing forces you to touch it. The agents I keep there meet three conditions.

Stable topics whose routing has been tested for months, with exceptions someone fixed by hand and nobody wants to rediscover. Short transactional dialogues with cards and buttons, where the value comes from a precise path. And anything touching a regulated process where every path is scripted on purpose, because a deviation there is a defect.

Two traps to know before opening the new experience. Topics are not skills: replacing routing with a procedure file does not reproduce the same behavior, and the documentation says as much in its own way by advising against it for complex scenarios. And an agent built in the new experience does not go back to the classic one. The decision is made at build time, not after.

What it changes in an agent factory

In an agent factory there are three objects: a guardrail framework, test sets as the release gate, and an agent registry with an owner per agent.

The rebuild moves the first one. My guardrails shipped in two copies, a block in the prompt and a knowledge file. That second copy becomes a versioned skill. Same content, but now one place, one owner and a revision history. In practice, a tone rule or an escalation rule becomes a pull request instead of an invisible change in a screen nobody rereads.

The test sets do not move, and that is the reassuring part. The release gate stays the same, with a threshold set per use case and failed cases fixed before production. During a platform rebuild, that is what lets you sleep.

The registry becomes more important, not less. The easier it is to build an agent, the more agents there are. The inventory, per-agent identity and a cyclical review remain the only place where you decide what to keep and what to switch off. A team that has never retired an agent does not have governance, it has a collection.

To close

The rule I apply comes from the documentation itself, and I think it is right: every behavior belongs in the smallest component that makes it reliable and inspectable. Instructions carry what is always true, knowledge carries the facts, tools carry the actions, skills carry the procedures, and connected agents carry the domains that belong to another team.

To choose between the two experiences, the useful question is not which one is newer. It is: does what I am building here need to reason across multiple steps, process documents and produce files, or does it need a path that stays predictable and auditable down to the button? The answer is in the use case, not in the announcement.

And the question to ask a partner: do they talk about migration in terms of files, repositories and tests, or in terms of buttons to click in a new interface? The first answer means they read the documentation.

If you have agents running and an exploration of the new experience to do without breaking what works, that is a two-hour workshop with your team: we sort your fleet, and decide what stays, what gets built in the new experience and what gets retired. Write to me.

Have a good week!

Sources: Microsoft, “Meet the new Copilot Studio”, June 9, 2026, Microsoft Learn, Copilot Studio, Microsoft Build 2026.