Microsoft Copilot Harness in Foundry: Public Preview, Pricing and Five Enterprise Tests
28 October 2026 | Verified enterprise AI analysis. Microsoft has opened its Copilot harness to developers through Microsoft Foundry Agent Service. The important story is not a new language model. It is a managed system for running agents across models, tools, skills, files and long-running tasks. The Foundry offering is in public preview, not general availability. In a separate announcement, Microsoft says long-running resilience for hosted agents is becoming generally available this week. Those are different capabilities with different release states.
The 28 October Microsoft announcement describes the harness as the shared foundation behind experiences spanning GitHub and Microsoft Copilot. The Foundry engineering announcement confirms what developers can actually test, how the preview is configured and when runtime billing begins.
What is an AI agent harness, in plain language?
An AI model generates responses and makes decisions from the context it receives. A harness is the operating system around that model: it manages instructions, memory within a task, tool calls, files, execution boundaries, retries and the loop that keeps work moving. Without a reliable harness, a promising model can still fail a business process by losing context, calling the wrong tool, repeating an action or stopping halfway through.
Think of an accounts-payable exception. The model may interpret an invoice; the harness determines how the agent retrieves the purchase order, invokes a permitted matching tool, handles a missing attachment, records evidence and escalates the final decision. The real enterprise outcome depends on both. Microsoft says its shared harness works with more than 20 frontier models and bring-your-own-key options, but supported combinations must still be verified for the specific product and region.
What actually launched on 28 October?
New: Microsoft Copilot harness in Foundry Agent Service, public preview. Microsoft runs the agent loop and sandbox, while developers configure the model, instructions, reusable skills and connected tools. The preview includes source-controlled agent definitions, file and code execution, bounded subagent delegation, and connections to supported Foundry and Model Context Protocol tools. Authentication and approval settings must be configured explicitly; a tool connection is not a blanket permission to act.
Separately: long-running resilience for hosted agents, generally available this week. Hosted agents are for teams that bring their own framework or agent loop. Foundry can restart interrupted work with the original input, but developers must persist checkpoints and implement idempotency for writes. This does not mean that every agent automatically resumes from its last completed business step. See the official Foundry technical explanation.
Not a new launch: the Copilot Studio harness. Microsoft says the previously named GitHub Copilot harness in Copilot Studio is now called Microsoft Copilot harness. Existing Copilot Studio agents continue operating without a capability or billing change caused by the rename. Product terminology will update over the coming weeks, according to the Copilot Studio product team. Do not confuse a naming change in one product with preview availability in another.
GitHub also announced that the GitHub Copilot SDK is transitioning to Microsoft Copilot SDK. The migration is phased; existing package names and documentation may continue to use the earlier name, and GitHub says no immediate action is required for current SDK users.
What does it cost, and when does charging start?
Microsoft's Foundry team states that Copilot harness runtime billing begins on 1 December 2026. Before that date, harness runtime usage is free, but model inference, separately billed tools and connected services can still incur charges. Starting on 1 December, the published sandbox rates are US$0.0994 per vCPU-hour and US$0.0118 per GiB-hour, subject to region and commercial agreement.
For illustration, a sandbox using four vCPUs and 16 GiB of memory for one hour would have a listed sandbox component of approximately US$0.59 (4 × $0.0994 plus 16 × $0.0118), before model, tool and other charges. This is an arithmetic example, not a quotation or forecast for a production workflow. Idle behavior, regional availability and actual billable consumption must be checked in the customer's tenant. The authoritative source is Microsoft's 28 October Foundry pricing notice, alongside the Foundry pricing page.
The practical budgeting unit should be cost per successfully completed, reviewed task, not tokens alone. A long-running agent that retries often, calls expensive tools or requires extensive human correction may cost more than a simpler workflow despite using a cheaper model.
Five enterprise acceptance tests before a pilot
- Model independence: Run the same approved task with two supported models. Compare output quality, completion rate, latency, token consumption and human corrections. Do not assume all 20-plus models are enabled in your Foundry region or subscription.
- Identity and authorization: Give the agent a legitimate request and a request outside the user's permissions. Confirm that connected tools enforce user or service identity, deny unauthorized data access and do not silently fall back to an administrator account.
- Recovery without duplication: Interrupt a multistep workflow after it has created a draft or external record. Confirm that restart logic reads a durable checkpoint and does not create a second invoice, ticket or approval. The new hosted-agent resilience feature does not replace application-level idempotency.
- Untrusted-input resistance: Place a malicious instruction inside a retrieved document or repository file. Verify that the agent treats the content as evidence rather than authority, respects network and tool restrictions, and requires approval for consequential changes.
- Unit economics and auditability: Capture tool calls, model choice, approvals, retries, elapsed time and final business outcome. Calculate total cost per correct completed task and review the logs with security and process owners before expanding scope.
These tests are recommended evaluation controls, not claims that Microsoft certifies an agent as safe after completing them. Public preview is the appropriate stage to validate technical fit and governance, not to presume production-grade support for every scenario.
Why SAP and SuccessFactors teams should pay attention
The potential is not that Foundry suddenly becomes an SAP feature. Rather, a governed external agent could investigate integration failures, reconcile test evidence, prepare change-impact reports or draft release checklists using approved APIs and documents. For example, a SuccessFactors integration support agent could correlate an authorized monitoring alert with run history and prepare a diagnosis for a human reviewer.
However, this announcement does not establish an out-of-the-box connection to SAP SuccessFactors, SAP Joule, SAP Integration Suite or SAP Cloud ALM. Any such connection would require independently validated integration support, authentication, licensing, data protection and permissions. HR data is especially sensitive: no agent should retrieve employee or compensation records through a broad technical account merely because the orchestration layer can call an API.
I would start with a read-only integration incident-analysis pilot. Give the agent synthetic or appropriately authorized data, require citations to logs, and measure whether it reduces triage time without creating false diagnoses. Keep production changes, credential rotation and employee-data writes behind explicit human approval. Only expand after the process owner signs off on the observed results.
How to start without mistaking preview for production readiness
First, verify that the customer's Microsoft Foundry project, region, model deployment and subscription are eligible for the preview. Microsoft says developers can create a new agent in the Foundry portal or use Azure Developer CLI; its documented agent configuration uses the preview harness type microsoft_copilot_preview. Existing Foundry agents cannot yet be switched to this harness after creation. Then attach a narrowly scoped skill, connect only approved tools and run the five acceptance tests above. The official tutorial and supported-limit links are the right starting point.
Teams already using Copilot Studio should not migrate agents simply because the harness has a new name. Teams building their own hosted agents should evaluate the separate generally available resilience capability, remembering that checkpoints and duplicate-safe external writes remain their responsibility.
The bigger shift: enterprise AI competition is moving beyond the model
Model comparisons remain useful, but enterprise buyers increasingly need to assess the entire execution system. Can an agent complete a workflow, survive an interruption, respect permission boundaries, produce evidence and justify its cost? A good harness can make a capable model more useful; it cannot replace correct business rules, authorized integrations or human accountability.
Bottom line: On 28 October 2026 Microsoft made its shared Copilot harness available in Foundry Agent Service as a public preview, confirmed a separate hosted-agent resilience GA milestone and began a phased SDK naming transition. The immediate action is a controlled, measured pilot. The financial checkpoint is 1 December 2026, when Foundry harness sandbox billing begins. No automatic production entitlement, SAP integration or universal regional availability should be inferred.
Primary sources and verification notes
Primary documentation: Microsoft announcement (28 October); Microsoft Foundry engineering post (28 October); Copilot Studio rename and existing-agent impact (28 October); GitHub SDK changelog (28 October); Microsoft Foundry pricing. Availability statements are product-specific. No independent enterprise benchmark, regional entitlement or actual customer bill was verified.
No comments:
Post a Comment