Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
A harness is the operating layer between the model and the agent's configuration in Microsoft Copilot Studio. It determines how the model receives context, uses instructions and tools, interprets results, and moves through a task toward completion. Put simply, the model provides the reasoning capability, while the harness equips and directs it.
Standard vs. GitHub Copilot harness
The standard harness and the GitHub Copilot harness are two authoring and runtime options in Copilot Studio. Both are built for task-based, multistep agents that create real business value.
Standard harness: Supports consistent, reliable execution of multistep business processes, particularly when working with a bounded set of data, documents, and tools. Its context is distributed across topics, variables, subagents, tools, and other components, giving makers granular control but requiring them to be a little more hands-on when designing the end-to-end goal of the agent.
GitHub Copilot harness: Extends the capabilities of the standard harness to a larger operating scale. It supports longer-running tasks, larger files and datasets, agentic loops that allow for multiple AI tasks in parallel, iterative reasoning, persistent memory, and ongoing subagent conversations with shared context.
Key principles for choosing a harness
Choose the standard harness when the work is relatively short and bounded, and when established channels and explicit control matter most. Choose the GitHub Copilot harness when the task is long-running, coordination-heavy, reasoning-intensive, or requires the agent to iteratively evaluate and refine its work to reach an outcome. The GitHub Copilot harness is particularly useful when the process isn't yet fully optimized, and AI can identify opportunities for improvement.
Both harnesses allow for predictable, deterministic responses through predefined topics in the standard harness or workflows in the GitHub Copilot harness. Reasoning models and some emerging agentic capabilities are available only through the GitHub Copilot harness.
Start with the scenario
Start with the business process and the behavior the agent must exhibit. Both harnesses can plan, call tools, and combine AI with deterministic steps. Some agents encountering blockers today might benefit from migration to the GitHub Copilot harness. However, without optimization, a more capable harness can overwork a simple problem, increasing Copilot Credit consumption and latency without improving the outcome. The decision is whether the task's scale, context demands, and coordination needs justify the GitHub Copilot harness, or whether the standard harness provides the more responsive and controlled fit to achieve the desired outcome.
Match capabilities to task weight
Consider task weight when choosing a harness. Lighter tasks typically use a bounded working set, stable action set, and have a primary outcome. Heavier work usually runs longer, spans multiple systems, requires deeper analysis and iterative looping on larger files, and produces multiple outputs. The more the work resembles the latter, the stronger the case for the GitHub Copilot harness.
Use agentic loops for adaptive paths
With an agentic loop, an agent evaluates its progress, interprets intermediate results, and determines whether to continue, try a different approach, delegate work, or stop. This approach is valuable when you can't fully specify the correct sequence of actions in advance or when the process might unfold differently each time you perform it.
The GitHub Copilot harness provides the following capabilities:
- Dynamic orchestration: The orchestrator manages reasoning and communication throughout the task, maintaining unified context as work flows back from connected agents. Both harnesses can adapt at runtime, but the standard harness typically requires makers to explicitly design paths and context handoffs. In the GitHub Copilot harness, the orchestrator adapts based on the results it receives.
- Secure data processing: A Bash container provides access to tools and libraries that aren't available in the standard harness. For example, an agent can generate or edit documents as part of completing an outcome.
- Larger shared context: The agent can work across large files, source data, tool results, generated outputs, and subagent work. Persistent memory can retain useful insights across runs. Together with whole-file reasoning and the Bash container's file system, these capabilities support agentic solutions that weren't previously possible.
The standard harness can still use agent flows, retries, tool chaining, and reasoning. The distinction isn't simply whether repetition is possible, but where adaptation is managed, how much data can be processed, and which tools are available. Makers define more of the path and context handoffs in the standard harness, while the GitHub Copilot harness gives the orchestrator greater responsibility for determining the next best action.
Consider consumption and governance
Harness selection can affect Copilot Credit consumption. GitHub Copilot harness solutions use usage-based billing for AI-based creation and use. Standard harness agents retain the pre-existing Copilot Studio licensing model. Consider expected task volume, model and runtime needs, context breadth, tool use, consumption controls, and the organization's governance requirements.
Evaluate usage across the full agent lifecycle, including building, testing, evaluating, and running the agent. Governance shouldn't focus only on whether makers can select a harness. It should establish appropriate environments, capacity controls, architecture reviews, evaluation requirements, security guardrails, and consumption accountability as solutions move from experimentation to production.
Learn more in Govern Copilot Credit consumption for agents powered by the GitHub Copilot harness.
Migrate only for a scenario-level benefit
Migration of any standard harness agents to GitHub Copilot harness agents should be driven by a clear benefit such as better quality, more efficient orchestration, long-running execution, or access to a specific reasoning model or needed new capability. A functioning standard harness agent doesn't need to move simply because another harness is available.
Treat migration as re-architecture rather than component conversion. First define the agent's required tasks, outcomes, boundaries, risks, and evaluation criteria. Then inventory the purpose of the existing topics, flows, variables, and prompts. Map the required capabilities into instructions, skills, tools, workflows, memory, code execution, and connected agents. The migration is complete when the rebuilt agent performs its core journeys successfully, not when every old component is mechanically reproduced.
Compare harness tradeoffs
The standard harness lets architects define and inspect more of the execution path. The GitHub Copilot harness lets them define the outcome and delegate more decisions about how to reach it. Neither is universally better—the right choice depends on the business process.
| Tradeoff | Standard harness | GitHub Copilot harness |
|---|---|---|
| Best-fit gain | An agent that tackles short, straightforward tasks, structured conversations, and bounded processes. | Advanced coordination for long-running, complex, multi-step business processes across tools, systems, and outputs. |
| When the scenario is too complex | Context is distributed across topics, tools, prompts, variables, and subagents. Makers retain direct control but must reconcile more of the context and exception logic as the process grows. | Ideal for complex scenarios. Dynamically plans, selects tools, leverages memory, and recovers from exceptions, reducing overall guidance required by the maker. |
| When the scenario is too simple | Ideal for simpler scenarios. Provides a proportionate runtime for short-running, straightforward tasks. | May introduce unnecessary reasoning, latency, and Copilot Credit consumption without materially improving the result. |
| Control and adaptability | Offers tighter control, but unexpected conditions generally require additional authored logic. | Continuously reasons from the latest state and can adapt when information, requests, or intermediate results change. It might retry a failed tool call, select another path, or resume after a conversational detour, but its execution path can be less predictable for agent-only solutions. |
| Latency and consumption profile | Well suited to high-traffic, user-facing scenarios where responsive interaction is important. | Longer latency and higher Copilot Credit consumption can be justified when advanced reasoning, large file processing, and orchestration create measurable value, but might be excessive for lightweight interactions. |
| Capability and maturity | Provides established features and channels, but some advanced models and new agentic capabilities aren't available. | Provides access to the latest agentic capabilities and reasoning models, but customers should validate required features and channels as the experience matures. |
For existing agents, migration should be a business-case decision, not a default upgrade. Move only when a demonstrated improvement justifies the additional Copilot Credit consumption, testing, and governance requirements.
Explore standard harness scenarios
These canonical scenarios show where the standard harness is the proportionate choice.
HR intake and routing bot. An employee reports an HR issue, and the agent must always collect the required information, apply predefined routing logic, and hand the case to the correct process. The agent shouldn't improvise a resolution from general knowledge. This example illustrates the standard harness's current strength in rule-based, topic-driven conversations. Choose the standard harness when the ordered conversation and deterministic handoff are the product requirement.
An existing production agent that depends on established channels or features. A deployed service or support agent already depends on a publishing channel, rich UI, topic structure, system variables, or another established standard harness capability that isn't yet available or fully mature in the GitHub Copilot harness experience. The safest choice is to preserve the working implementation until the required capability and migration path are available. Choose the standard harness when continuity and validated feature coverage outweigh the potential benefit of the new orchestration stack.
A predictable agent or agent flow with bounded reasoning. A maker needs an agent that answers from known business knowledge, follows explicit instructions, and invokes a small, stable set of actions. The scenario doesn't require broad source aggregation, deep analysis, or several deliverables. The standard harness can be the more proportionate choice, particularly where predictable behavior is a priority. The presence of connectors, MCP servers, or some dynamic planning doesn't by itself require the GitHub Copilot harness. The decision should turn on whether the scenario requires continuous replanning, advanced recovery, or capabilities that are specific to the newer runtime. Choose the standard harness when the work is structured and the value comes from consistency rather than autonomous planning.
Explore GitHub Copilot harness scenarios
These canonical scenarios show where the scale, context, and coordination demands justify the GitHub Copilot harness.
End-to-end customer meeting preparation. An agent analyzes relevant emails, meeting notes, CRM updates, and support incidents; identifies deal status, risks, and competitive threats; creates a briefing document and client-ready presentation; and sends a concise summary with recommended actions. This task is an example of a coordinated task that combines context, models, tools, and runtime. Choose the GitHub Copilot harness when the agent must plan and complete a multi-source, multi-output business process.
A deep compliance or operational audit. An agent aggregates several years of operational records, recomputes measures, checks thresholds, correlates findings with permit or policy conditions, writes a full audit report, and distributes results through multiple channels. Internal query-type guidance classifies this task as heavy work: broad aggregation, deep reasoning, and many outputs. Choose the GitHub Copilot harness when the process is long-running, analysis-heavy, and requires coordinated execution across tools.
Accounts payable reconciliation and exception handling. An agent manages an invoice from receipt through approval. It reads the invoice, extracts key details, locates the corresponding purchase order, and verifies that the supplier, amounts, quantities, and payment terms match. It records the results in an Excel reconciliation file and prepares approval documentation. If information is missing or records don't match, the agent adapts its plan by consulting connected systems or specialized agents to resolve gaps. Skills encode the organization's procedures, while tools, workflows, and the agent sandbox provide access, repeatable execution, and exact computation. Memory can preserve relevant user-specific preferences or corrections across interactions, while the agent's working context carries information during the current process. Predictable approval, record-creation, and notification steps can remain in a deterministic workflow, while the agent reasons through discrepancies, missing information, and exceptions. Choose the GitHub Copilot harness when an agent must take ownership of a complex business outcome, coordinate several tools, create or update business documents, and recover from exceptions that can't be fully anticipated.
Data curation as a joint harness experience. An organization uses high-volume standard harness agents to support responsive, user-facing business processes, but the agents depend on large Excel workbooks and disorganized SharePoint repositories. A GitHub Copilot harness agent runs autonomously on a schedule to analyze the files, transform workbook data into structured Dataverse tables, reorganize repository content, apply metadata and tags, prepare documents, and improve the signals used for search and retrieval. The curated information then becomes a higher-quality data foundation for the standard harness agents. This architecture applies each harness where it creates the most value. The GitHub Copilot harness handles the large-context, long-running curation work that would otherwise require the standard harness to process smaller batches through multiple prompts, handoffs, and exception paths. The standard harness remains the responsive and controlled conversational layer serving a high volume of users. Choose this combined approach when poor data organization or retrieval quality is limiting an otherwise well-suited standard harness scenario.
Compare harnesses at a glance
| Comparison | Standard harness | GitHub Copilot harness |
|---|---|---|
| What it is | A dependable runtime for rule-based agents, structured conversations, and agent flows. | An advanced runtime for reasoning-heavy agents and workflows that complete complex, long-running business processes. |
| Typical cadence | Usually short interactions with few steps and one primary output. | Usually long-running work with multiple steps, tools, iterative loops, parallel work, and outputs. |
| Context | Context is distributed across topics, variables, tools, and subagents, so makers manage the handoffs. | Supports a larger shared context across files, source data, tool results, generated outputs, long-running interactions, and subagent work. Persistent memory can retain useful insights across runs. |
| Control and adaptability | Offers tighter control, but unexpected conditions generally require additional authored logic. | Continuously reasons from the latest state and can adapt when information, requests, or intermediate results change. Its execution path can be less predictable for agent-only solutions. |
| Use when | Consistency, explicit control, responsive interaction, proven channels, or established features are priorities. | The agent must process large files, run for longer periods, adapt to changing information, recover from failures, create or modify documents, or own a business outcome end to end. |
| Caveats | Complex scenarios can require extensive custom routing, context handoffs, and exception logic. | Simple scenarios can incur unnecessary reasoning, latency, and Copilot Credit consumption without materially improving the result. Customers should also validate required features and channels as the experience matures. |
| Example scenarios | HR intake and routing, internal help desk, predictable support conversations, and existing production agents that depend on established features or channels. | Customer meeting preparation, accounts payable reconciliation, compliance audits, and cross-system processes that produce multiple deliverables and actions. |
Learn more in Compare harnesses.