An agent creates a report in another system and crashes before saving its completion checkpoint. The runtime starts the work again with the same input. Will the destination contain one report or two?
That question matters when reading Microsoft's October 28 announcement. The managed Copilot harness public preview and recovery for long-running hosted agents were announced together, but apply to different execution paths. This article reviews the documents and runs a local fake-service example; it does not report a Foundry deployment.
Decide who owns the loop
For prompt agents using the Copilot harness, Microsoft operates the model/tool loop and sandbox while developers configure instructions, skills and tools. Hosted agents provide a path for bringing your own framework and execution logic. Keep that distinction in view when reading the recovery claims. Developer announcement
The following is our adoption decision table, rather than a reproduced feature matrix.
| Question to resolve first | Direction |
|---|---|
| Are instructions and supported tool calls enough? | Evaluate a basic prompt agent first |
| Do you want managed files, skills and multi-step coordination? | Check the managed harness's supported scope and limits |
| Must you replace the loop, middleware or dependencies? | Budget for the code you would own in a hosted agent |
| Will the workflow change another system? | Define operation identity, authorization and deduplication in either path |
Before expanding delegation, make sure the state after one failed tool call can be explained. Separating read-only research from publication makes approval and recovery easier to reason about.
Put the 10.8–22.1-point claim in its product context
The October 28 Copilot Studio post reports pass-rate gains over its Standard harness of 10.8 percentage points with an OpenAI model and 22.1 with an Anthropic model on equivalent tasks. Its footnote attributes this to October internal analysis of successful evaluation runs. Exact model versions, sample sizes, a public dataset, and baseline pass rates are absent, preventing independent reproduction or calculation of relative gains.
These are not customer migration results for the Foundry preview. Continuing after a failed tool call also differs from completing the task. Compare verified completions and retry costs with inputs, model, and permissions held fixed.
The YAML selects execution responsibility
The current harness guide uses this selection in azure.yaml. This is an unexecuted example, not a complete deployment manifest. review-agent is an illustrative name.
services:
review-agent:
host: azure.ai.agent
harness:
type: microsoft_copilot_preview
The generated project, model, authentication, supported region and remaining settings are prerequisites. The guide says the initial preview selects the harness at creation and cannot switch an existing agent's harness. We have not added a model name or deployment commands to imply this fragment is deployable. The eventual verification target is the persisted harness value; we did not deploy it here.
Read the tool controls carefully. Keeping Shell enabled while disabling dedicated file or web tools does not establish a strict file or network boundary. Approval settings for harness tools also differ from those for customer MCP tools. A capability toggle and the permissions of the execution environment are separate controls. Harness tool configuration
A remote commit can outlive a local checkpoint
The resilience guide describes hosted handler reentry from the beginning, without restoring local variables or the call stack. Replaying a stream is also different from restoring domain progress. That leaves this failure interval:
Create request → destination commits report → process stops
↓
no local completion record
↓
handler reentry → create again?
This is our failure scenario derived from the documented model. Even checking for an existing report first can race with another request between the read and the create. The receiving system needs atomic deduplication or a uniqueness constraint to close that race.
Save the original example below as restart.mjs and run it with Node.js 18 or newer. An array and a receipt Map stand in for an external service. The scenario loses the checkpoint after the first creation and reenters the handler; it does not terminate a real process or test Azure recovery.
function simulate(deduplicate) {
const reports = [], receipts = new Map();
let checkpoint = null;
const key = 'tenant-demo:job-42:report:v1';
function createReport() {
if (deduplicate && receipts.has(key)) return receipts.get(key);
const id = `report-${reports.length + 1}`;
reports.push(id);
receipts.set(key, id);
return id;
}
createReport(); // Remote commit; crash before local checkpoint.
if (!checkpoint) checkpoint = createReport();
return { reports: reports.length, checkpoint };
}
console.log(JSON.stringify(simulate(false)));
console.log(JSON.stringify(simulate(true)));
Local execution output:
{"reports":2,"checkpoint":"report-2"}
{"reports":1,"checkpoint":"report-1"}
The difference comes from how the destination handles the stable operation key. This Map is not a distributed store and tests neither concurrency, retention nor durability. In production, verify the destination's idempotency contract, rejection of a different payload under the same key, and atomic creation plus receipt storage. An agent invocation ID that changes on each run is unsuitable as the domain operation key.
Three agreements to make before adoption
First, define an operation identity that survives reentry, such as tenant + job + operation + version. A revised report gets a new version; a network retry keeps the same key.
Second, treat an ambiguous timeout as an unknown outcome. Check the destination for an existing effect. If reconciliation is unavailable, a review state is preferable to automatic creation. A local ledger alone cannot guarantee exactly-once effects in another system.
Third, resolve the release status against your deployment contract. The announcement calls hosted resilience GA, but the linked guide inspected on October 29 still has a preview title and notice. We could not reconcile that discrepancy. The harness itself is public preview; check the region, SDK, SLA and status of the feature you intend to deploy. A free harness-runtime period does not make model inference or separately billed tools free. Announcement status and billing notes
A managed harness reduces the execution infrastructure you own. The domain contract for identifying and recovering a committed external change remains application work. Start with a small research-and-publication flow that can answer the report-count question, then expand task duration and delegation.
Related background: what harness engineering covers and checkpoint and resume design.
The published paid course below connects to designing tools, verification, loops and graphs. It is not Azure-specific deployment training. The course link is promotional.