From topic tree to skill

If you have two years of work invested in topics, the new harness in Copilot Studio is bad news at first. Not because it is worse. Because what you built cannot come along.

This dispatch is the guide I wish I had had. It is a reference, so the date of the last review is at the top.

The one rule up front

Agents cannot be moved between harnesses. What was built in the classic experience stays there. There is no export, no converter and no migration assistant.

That does not mean you have to do anything. Existing agents on the standard harness keep running, and no shutdown date has been announced. It does mean that every decision for the new harness is a rebuild decision, and you want to take it deliberately rather than in passing.

The mistake I made first

My first instinct was to translate topics one to one into skills. One topic, one skill. That does not work, for a structural reason.

A topic is a flow: trigger, nodes, branches, variables. You drew it, so it runs that way. A skill is an instruction: name, description, instructions in Markdown. The orchestration runtime loads it when the request matches its description, and then decides for itself how to follow it.

Converting a topic tree into skills means translating a description of a procedure into a description of an intent. That is not a conversion. It is a restatement of the problem.

The sort I start with

Before anything gets written, I sort every existing topic into one of three buckets.

Bucket 1: this has to stay deterministic. Everything where the procedure itself is the requirement. Approved advisory sequences, regulated disclosure obligations, anything with prescribed wording. That does not belong in a skill, it belongs in a workflow or stays on the standard harness. If the sentence "the orchestrator usually follows that" would not pass at your organisation, the topic belongs here.

Bucket 2: this is really a task. Everything where the flow was only the crutch for expressing an intent. Check order status, trace an invoice, submit a holiday request. These topics become skills, and usually five topics become one skill rather than five.

Bucket 3: this was a misunderstanding. Topics that exist only because the model was too weak at the time. Classics: thirty variants of "I did not understand that", hand-built entity recognition, rephrasing chains. Delete those and replace them with nothing.

After this sort, the migration effort is usually much smaller than feared. Bucket 3 is the largest one in every grown bot.

How bucket 2 becomes a skill

A skill consists of YAML front matter with a name and a description, and Markdown instructions underneath. My order when writing:

1. The description first. It is not documentation, it is the interface. The runtime decides on it whether the skill gets loaded. Write into it when the skill should apply, in the language users phrase their concerns. Not "order process handler" but "Use when someone asks about the status, whereabouts or modification of an existing order."
2. The procedure as numbered steps. This is where your topic knowledge is genuinely valuable. The sequence you worked out painstakingly now gets written as prose instead of drawn.
3. The abort conditions. What the skill must not do, when it escalates, what happens when data is missing. In topics these were branches. In a skill they are sentences, and they have to be just as explicit.
4. The output format. If the answer has to have a particular structure, describe it. Otherwise you get a different one on every run.
5. The limits. A paragraph on what the skill expressly does not assess and what applies in case of doubt.

What does not belong in the skill: the text of the answer itself. Writing fixed response text into skills means rebuilding a topic tree in Markdown and taking on the disadvantages of both worlds.

What happens to the parts

In the topic model

In the new model

Topic with trigger phrases

Skill, routed through its description

Conditional branch

Instruction in the skill, or condition group in the workflow

Variables across the dialogue

Memory, or context of the run

Call to a Power Automate flow action

Tool or workflow

Hard-wired response text

Belongs in a deterministic workflow, not in the skill

Fallback topic

Gone, the orchestrator takes over

Knowledge source

Unchanged as knowledge, plus Microsoft IQ

The row underestimated most often is the one about variables. Persistent context is called memory in the new world, is stored per user, and is therefore a governance topic rather than an implementation detail. Before switching it on, settle what gets stored, for how long, and how deletion works.

The migration in the order I recommend

1. Inventory. All agents, all topics, owners, usage figures. Without that you are working in the dark.
2. Sort into the three buckets. That is thinking work, not clicking work, and it goes best in pairs.
3. Pick a candidate that hurts but is not critical. Not the easiest, or you learn nothing, and not the most critical, or you learn expensively.
4. Write test cases before the first skill exists. Copilot Studio has had GA tooling for evaluations since March, including multi-turn tests. Old topics make excellent test cases, because every branch was an expectation.
5. Write the skills, description first.
6. Run them against the test cases. The most common finding is not that the skill is bad but that it never gets loaded at all. That is always a description problem.
7. Run in parallel. The old agent stays, the new one runs on one channel or for one user group. Only switch over when the numbers support it.
8. Only then the next candidate.

Two things you have to plan for

Cost from the first build step. The GitHub Copilot harness bills through Copilot Credits from the moment you start building, not after publishing. A migration is therefore a cost item, not a side project. Set budgets per environment before the makers start.

Parallel operation for months. You will maintain both worlds for a while. That is not a sign of poor planning, it is the structure of the thing. Plan for it instead of discovering it.

The honest part

I think the direction is right. Topic trees failed in the same place rule-based systems always fail: the variety of real concerns. An orchestrator that breaks a goal down itself is the better answer.

What I do not know is instruction adherence over long runs under load. The preview window between June and August was tight for a change of this size, and demos are not production. That is why the point about test cases comes before the point about skills in my sequence, and why bucket 1 stays where it is for now.

Sources

• Choose a harness, Microsoft Learn, as of 3 August 2026
• Skills overview for agents, Microsoft Learn, as of 3 August 2026
• Overview of billing for agents powered by the GitHub Copilot harness, Microsoft Learn
• What's new in Copilot Studio, Microsoft Learn, on memory, condition groups and evaluations