The Agent Harness Can Restart. Your Business Transaction Still Needs a Recovery Design.

A compliance analyst asks an agent to examine a supplier contract, compare it with policy, and create a review task if a clause requires attention. The model can read files and call tools. Halfway through, its worker disappears. When the platform restarts the request, does the task resume, repeat, or silently create a second review item? The answer depends less on the model than on the application’s records of progress and effects.

On 28 October 2026, Microsoft announced a public preview of the Microsoft Copilot harness in Foundry Agent Service. It bundles skills, files and code execution, authenticated tools, and bounded subagents into a managed prompt-agent runtime. The same announcement says long-running resilience for hosted agents is generally available, while the resilience documentation still carries a preview label. Teams should confirm the state of the specific feature and region they intend to use before treating that label as a production commitment. Microsoft announcement, 28 October 2026.

The release matters because a provider is taking responsibility for more of the execution environment. That changes where architects draw boundaries. A harness can manage an agent loop, but it cannot infer whether a bank’s external system accepted a payment instruction, a publication, or a case update after a timeout. That last step belongs to the business workflow.

What the managed harness changes

Foundry distinguishes prompt agents from hosted agents. The new harness is selected when a prompt agent is created; Microsoft says existing agents remain unchanged and cannot yet be switched to it. Its managed environment supplies reusable skills and a file workspace, supports tool access including MCP servers, and can delegate bounded work to subagents. Authentication and approvals are part of the tool configuration. These are vendor-stated product capabilities, not evidence that every tool is safe for regulated data. Foundry overview; announcement.

A team designing an internal research assistant may welcome that packaging. A team handling customer or payment operations must still decide which identity each tool call uses, what data a tool may return, what action needs a human decision, and what happens when the agent makes the same call twice. A tool catalog and policy wrapper are useful only when their authorization is evaluated against the tenant, task, resource and action at the moment of use. An MCP connection can otherwise become a broad shortcut around the application’s normal access model.

The first design choice is whether the managed prompt harness is the right place for the work. It may suit bounded analysis with approved tools and data. A hosted agent is more appropriate when the application needs custom runtime code, durable state transitions or direct control of external effects. The answer should follow a workload test, not a preference for a single framework. Microsoft’s published runtime pricing is also a reminder that a managed loop has a meter beyond model tokens: from 1 December 2026 the announced sandbox charges start at $0.0994 per vCPU-hour and $0.0118 per GiB-hour, with regional and contract differences; model and tool costs are separate. Pricing statement in the announcement.

Restart is an execution event, not a business outcome

The long-running resilience documentation describes a specific mechanism for hosted agents. The platform stores an input before invoking the handler, detects loss of the process through a lease, and can invoke the handler again with the original input. It also describes stream replay. This is useful infrastructure recovery, but it is not arbitrary checkpoint restoration or a guarantee of exactly-once side effects. The handler can run from its beginning. The documentation describes opt-in recovery for stored background responses and says foreground requests are not recovered in the same way. Microsoft resilience documentation.

Consider the contract task. The agent calls a case system, which creates case 4812, but the reply is lost as the worker fails. The restarted handler sees no successful reply and calls the case system again. A well-designed case API accepts a stable idempotency key tied to the proposed business action and returns the original case. If that API offers no such key, the workflow needs a reconciliation lookup before a retry. Neither solution can be supplied merely by replaying model messages.

The diagram below is a conceptual control design, not a depiction of Foundry internals. A durable task record stores the requested operation, current phase and effect identifiers. Each attempt may have its own execution trace. The tool gateway checks authorization, approval and a stable effect key before calling an external system. Recovery reads the task record before deciding which step to retry.

Conceptual architecture: the business task and external effect record survive worker restarts; an execution trace alone does not establish whether an external action committed.

This distinction is especially important when a human approval is involved. The approval should bind to a specific action and payload, not merely to an earlier conversational intention. If the agent changes the proposed value after a restart, the previous approval must not silently authorize it. For retrieval, the same principle applies less visibly: a resumed task should retain the source versions or at least disclose when documents changed between attempts.

Security and evidence follow the tool boundary

Microsoft describes authenticated tools and explicit approvals for the harness. The architectural question for a European bank is how those controls connect to its existing entitlement model. An agent acting for a customer-service employee should not inherit broad service credentials simply because it runs in a trusted Azure environment. Retrieval filters must be enforced server-side, and each tool should validate the caller’s entitlement to the individual record or operation. Testing should include cross-tenant identifiers, revoked access, malicious document instructions and retries after authorization changes.

The Foundry FAQ warns that external tools may send data outside Foundry. That is a data-flow fact worth mapping before a pilot: a document excerpt retrieved for context may travel to a model, a tool provider, a tracing backend and an error queue. Each destination has its own retention and access rules. An approval prompt does not replace a data-processing decision.

Observability should connect the business task, agent attempt, retrieval sources, tool calls and external effect. It should also preserve uncertainty. When a timeout leaves the result unknown, the state should be “reconcile,” not “failed” or “succeeded” by guess. A decision log for high-impact actions should record the policy version, identity, approved payload, effect key and confirmed destination response. Traces then explain timing and execution; they are not the sole ledger of committed business actions.

A practical decision for Architech and Archy

For Architech, the immediate consulting opportunity is a recovery and authorization review around one bounded workflow. Choose an internal case-creation process with synthetic records, interrupt the worker before and after the destination accepts a write, and measure duplicate actions, time to reconcile, evidence completeness and operator effort. Compare a managed prompt harness with a hosted implementation if both satisfy the data constraints. The result is an architecture decision backed by failure behavior and total cost, not a feature checklist.

For Archy as an open orchestration platform, the relevant product question is what contract should remain portable across managed runtimes. Candidate fields include a durable task identity, execution attempt, tenant and actor, approval reference, source versions, idempotency key, effect state and recovery reason. This is an engineering direction to investigate, not a statement that Archy already implements the Foundry harness. A small adapter experiment could test whether those fields survive runs on Azure and another execution environment without hiding provider-specific semantics.

Watch three things next: whether Microsoft aligns the announcement and documentation status for long-running resilience, how the preview harness exposes policy and state boundaries under real failures, and what its combined sandbox, model and tool bill looks like for a representative task. The most useful acceptance test is simple: after interruption, can an operator prove what the agent read, what was approved, what external action actually happened, and what can safely be retried?