Microsoft’s October 28 announcements put a shared Copilot harness at the center of its developer story. Microsoft says the orchestration layer is available through Foundry; GitHub separately announced an SDK transition and a new default for VS Code sessions. As of October 31, the practical question is which changes reach a developer’s environment today—and which capabilities still carry product-specific limits.
What the shared harness actually unifies
Microsoft describes the harness as the machinery around a model: instructions, context, an execution environment and controls. The distinction matters because selecting a model and deciding how an agent carries out work are separate choices. A shared orchestration foundation could reduce the need to maintain separate harnesses, but that is an editorial inference, not demonstrated portability.
Microsoft’s announcement claims support for more than 20 frontier models, bring-your-own-key and intelligent routing. It provides no independent benchmark or detailed method establishing its performance and cost claims. Those claims therefore offer a direction to evaluate, rather than a measured outcome for a particular workload.
What changes in the SDK and VS Code
The SDK announcement is a phased branding transition from GitHub Copilot SDK to Microsoft Copilot SDK. GitHub says existing users need no immediate changes and support remains the same. Package names, namespaces and documentation may retain the GitHub name during migration.
That makes this a transition to track, rather than evidence that every package has already moved. Teams should check the identifiers their integration actually uses before scheduling migration work; the announcement does not guarantee compatibility for every integration.
There is a more immediate change in GitHub’s VS Code release notes: the harness, built on the Microsoft Copilot SDK, is the default for new sessions in the editor and Agents window. Running models and harnesses in parallel, comparing results and optionally adding judge or synthesis steps is marked preview. Neither statement establishes equivalent behavior across every Copilot surface.
Foundry and Copilot Studio have separate boundaries
Foundry’s documentation describes an optional managed harness for prompt agents, invoked through the Responses API while Foundry operates the runtime. Its initial preview requires choosing the harness when creating an agent; an existing agent cannot switch to it. Bring-your-own-model is unsupported.
The deployment limit is explicit: the capability is preview, has no SLA and is not recommended by Microsoft for production workloads. Project region, supported models and identity permissions also constrain tools and generated files. Microsoft’s broader multi-model announcement should not be read as overriding these implementation limits.
Copilot Studio’s documentation describes its GitHub Copilot harness as supporting multistep work, tools, files, skills and a governed sandbox. It says harness choice affects features and billing. It also says customer data is not sent to the GitHub Copilot service and Copilot Studio commitments remain in place. These are Studio-specific statements, not a description of Foundry’s billing or data boundaries.
What developers should verify before adopting it
Start with the product surface. A VS Code default, a Studio harness choice and a Foundry managed runtime are different adoption decisions. For Foundry, confirm model and regional availability, identity permissions and whether the preview restrictions fit the proposed work. For an SDK integration, check current package names and the documentation that matches them.
Then examine controls, billing and configuration portability within the chosen product. Related coverage of GitHub Copilot’s Model Policy API addresses model-access controls; this announcement concerns the runtime surrounding those choices.
The supplied sources establish a shared product direction, not identical APIs or feature parity. No account-specific availability, API call, customer deployment or benchmark was tested for this report. Adoption should rest on the documented constraints and workload-specific evaluation, with routing quality and economics treated as questions still requiring evidence.
Sources
- Microsoft: Introducing the Microsoft Copilot harness — October 28, 2026.
- GitHub: Copilot SDK transition — October 28, 2026.
- GitHub: Copilot in VS Code, Universe releases — October 28, 2026.
- Microsoft Learn: Harnesses in Copilot Studio — undated; accessed October 31, 2026 KST. An authorization notice appeared while article text remained readable.
- Microsoft Learn: Use the Microsoft Copilot harness with prompt agents — undated; accessed October 31, 2026 KST.