Copilot Studio harness adds reasoning, retries and skills

Key insights

• The harness can observe tool results and choose another step, including retrying after an error.
• Microsoft says makers do not need a separate GitHub Copilot CLI account to use the harness.
• Skills package reusable instructions and supporting files; makers review and add generated skills to an agent.
• The demonstration combines SharePoint knowledge with tools to query file metadata.
• The harness can analyze images and include document screenshots in responses when instructed.

The Microsoft Copilot harness in Copilot Studio adds a reasoning loop that lets an agent act on a task, inspect results and decide what to do next. It matters most to Copilot Studio makers building agents that need to coordinate tools, knowledge and multi-step work rather than simply answer a question. Microsoft demonstrates the harness through examples involving SharePoint documents, image analysis and reusable skills.

What's new

The harness was introduced under the name GitHub Copilot harness and was renamed Microsoft Copilot harness in late October 2026, according to Microsoft’s announcement. The name changed; the supplied announcement describes the change as a rename, not a change to the underlying feature. In Copilot Studio, the harness is an alternative orchestration approach to the standard harness.

The key difference is how an agent handles a task. In the standard harness described in the demonstration, the agent identifies intent, creates a plan and executes it. The new harness repeatedly reasons over the latest state, chooses an action, observes the result and decides whether to continue, try a different approach or retry.

That loop is designed for tasks where the agent cannot map every step in advance. It can use the result of one tool call to inform the next, respond to an error or fetch additional information. The presenter recommends considering it for complex tasks involving complex data or tool use, rather than assuming it is needed for every agent.

The builder also brings instructions, skills, tools and knowledge into a redesigned agent-building experience, with testing and reasoning details available to the maker. A separate workflow designer can combine deterministic steps with agents and MCP tools. This supports workflows where a predictable process needs an AI agent for a particular part of the work.

Who it is for and what you need

The feature is aimed at makers building agents in Copilot Studio, especially those working on advanced scenarios that require multiple tools, complex data or decisions based on earlier results. The demonstration also shows why it may help people who need an agent to interpret SharePoint metadata or analyze images. The standard harness remains an option for scenarios that do not need this more dynamic task handling.

The presenter says a separate GitHub Copilot CLI account or GitHub setup is not required: the CLI-based orchestration runs behind the scenes in Copilot Studio. The transcript does not specify a Copilot Studio license, region, tenant requirement or rollout status, so those details cannot be established from this material.

Some building blocks will be familiar to existing Copilot Studio makers: instructions, knowledge, tools and connected agents. The harness also introduces or emphasizes skills, memory and an agent sandbox for running code. The presenter says existing governance tools, including DLP, solutions, pipelines and deployment, still apply; the demonstration does not provide configuration details for them.

How it works

In the agent builder, makers provide instructions and select the resources the agent can use. The transcript describes options for choosing a model, publishing location, skills, tools, knowledge, connected agents and memory. The agent can also receive supporting skill files, and the sandbox can run Python code supplied by the maker or generated by the agent.

1. Describe the agent’s role and behavior in its instructions, then add the knowledge and tools it needs.
2. For a task, the harness reasons over the request and available context, selects a tool or other action, and supplies its inputs.
3. After the action runs, the agent observes the result and decides whether to continue, retry, change approach or gather more information.
4. Test the agent and inspect its reasoning. The demonstration shows an end-user preview that hides the detailed reasoning shown to the maker.

Skills are reusable procedures that can include instructions and supporting resources such as templates or code. The transcript says makers can ask the agent to generate a skill based on a successful process, export it and then import it into the agent. The maker must perform that final step; the agent does not modify its own skill.

The SharePoint example combines a library as knowledge with tools that retrieve files and metadata. The presenter says the knowledge connection alone did not expose custom metadata columns in the example; adding tools to retrieve metadata and list files let the agent use those columns to narrow its answer. Other demonstrations show the agent selecting a requested document version, analyzing package damage from an image, and returning screenshots from a troubleshooting document when instructed to include them.

For makers following developments in Power Apps and the wider Power Platform, the practical distinction is that the harness handles reasoning and tool selection, while a workflow can supply more structured, repeatable steps. Use the smallest combination of instructions, tools, skills and connected agents that makes the task reliable and understandable.

Limitations and open questions

The source material does not establish licensing, broad availability, regional rollout or a specific setting to switch an existing agent to the new harness. Makers should verify those details in their Copilot Studio environment and Microsoft documentation before planning a deployment.

The examples also depend on how the agent is instructed and which tools and knowledge sources are configured. Image inclusion, for example, is presented as something the maker must request in instructions, not behavior that happens automatically. Likewise, metadata-based SharePoint answers rely on adding appropriate tools; the demonstration does not claim that custom metadata is automatically available through knowledge alone.

More reasoning flexibility also does not mean every design should be split into multiple agents. The presenter’s design guidance is to use the smallest component that makes behavior reliable, inspectable and safe. Generated skills require maker review and explicit addition, rather than automatically changing the running agent.

Sources

• Microsoft announcement: GitHub Copilot harness renamed Microsoft Copilot harness
• Microsoft Copilot Studio harness demonstration

Frequently asked questions

What does the Microsoft Copilot harness do in Copilot Studio?

It lets an agent reason over a task, use tools, observe results and decide what to do next. The demonstrated loop can retry or change approach when a tool result is not useful.

Do I need a GitHub Copilot CLI account to use the harness?

No separate GitHub Copilot CLI account or GitHub setup is needed, according to the presenter. The CLI-based orchestration runs behind the scenes in Copilot Studio.

How does the harness differ from the standard harness?

The standard harness described in the demonstration plans and then executes. The Microsoft Copilot harness keeps evaluating the latest state and can decide to retry, use another tool or fetch more information.

How do I add a generated skill to an agent?

The demonstration says to export the generated skill and then import it into the agent. The maker performs that step; the agent does not edit its own skill.