Restart, Don't Duplicate: Why Agent Reliability Is an Idempotency Problem, Not a Prompt Problem

Every agent demonstration works. The design question is what happens when the job is interrupted at hour three, halfway through a change it has already half-applied.

That is not a prompt problem. It is an idempotency problem, and it is the reason so much agentic work stalls between a convincing pilot and a system anyone will let near a customer record.

What Microsoft actually published, and when

On 28 October 2026, Microsoft introduced the Copilot harness in Foundry Agent Service in public preview, and separately announced general availability of long-running resilience for hosted agents.

The harness itself is described as a managed execution system. Microsoft runs the agent loop and sandbox; the customer brings knowledge, procedures and tools. The founding post frames it the same way: if the model supplies the intelligence, the harness is everything around the model.

Those are vendor statements about a product in preview. They describe intent and capability, not audited outcomes, and this article treats them that way.

The sentence that matters more than the announcement

Buried in the mechanics is the part a delivery team should read twice.

Foundry detects interruptions and restarts the work with its original input. Your code saves progress and intermediate results so the agent can pick up where it left off. And if the agent updates another system, your workflow also needs to prevent duplicate actions when work restarts.

That is a distributed systems contract wearing an AI label. At-least-once execution plus a side effect equals duplicate writes unless something makes the second attempt harmless.

Microsoft is explicit about the limit: conversation history alone is not enough to restore work in progress. A transcript is not a checkpoint.

Why vibe-coded agents fail exactly here

An agent assembled from a prompt and a handful of connectors optimises for the happy path. It is impressive in a five-minute recording because nothing interrupts it.

Production interrupts things constantly: a model call times out, a tool returns an unexpected shape, a container cycles mid-task. The agent recovers, and then repeats the step it already completed.

The visible symptom is a duplicate invoice, a second email or a record created twice. The invisible cause is that nobody asked, at design time, what makes an action safe to attempt again.

That question has an answer that predates generative AI. Give every side-effecting action a stable key. Check for the key before acting. Record the result against it. The work of adapting it to agents is careful, not exotic.

Instructions are not a control

Microsoft's own training material for the harness is unusually direct. Instructions define an agent's role, behaviour and boundaries, but they do not replace platform security.

The same unit says to enforce access with authentication, permissions, data policies and connector controls. In other words, the sentence in the prompt is documentation. The permission is the control.

That distinction is the whole gap between agentic engineering and vibe coding. One team writes the boundary into the platform. The other writes it into a paragraph and hopes.

A decision table you can write before the code

The same material supplies a practical control model, and it is short enough to adopt as-is.

• Proceed for low-risk, reversible actions such as retrieving approved information.
• Confirm before actions such as sending a message, creating a request or updating a record.
• Escalate when an action requires human judgement, formal approval or privileged access.

Written as a table with named owners, that is a governance artefact. Left unwritten, it becomes a debate conducted after an incident.

Where a workflow beats reasoning

Microsoft's own guidance draws a line that buyers should borrow. Some tasks need a fixed sequence, such as a transaction requiring the same validation and approval steps every time.

Workflows are described as giving agents a deterministic, auditable path for actions that must produce the same result every time, with a clear input and output contract and complete test coverage.

Read that as a cost control as much as a correctness control. Reasoning is the expensive part, and it is least valuable where the correct sequence is already known.

Preview status, and a billing date to plan around

Two constraints belong in the design note rather than the appendix.

First, during preview the harness is selected at agent creation, and switching harness after creation is not supported yet. The execution environment's CPU, memory and idle settings are managed by the platform.

That makes an early architectural choice harder to reverse than a configuration change, which is an argument for deciding it deliberately rather than by default.

Second, billing for the Copilot harness in Foundry Agent Service begins 1 December 2026, with harness runtime free before then. Sandbox compute and memory are then billed per vCPU-hour and per GiB-hour, with prices varying by region and agreement.

A retry loop that loops badly is now a line item. That is not a reason to avoid it; it is a reason to instrument it.

Vendor-published customer quotes, labelled

Microsoft's announcement carries testimonials, including a chief technology officer saying a solution was running in less than a week, and a chief executive describing agents that discover and calculate while commercially binding decisions remain under human control.

Both are vendor-published and unaudited. The second is nonetheless the more useful framing, because it locates the boundary where most regulated buyers need it: the agent prepares, a human commits.

Six decision criteria

• Idempotency by action. For every action that writes, is there a stable key and a recorded result, so a second attempt is harmless?
• Checkpoint ownership. Who defines what state is saved, where it lives, and how it is restored after an interruption?
• Determinism boundary. Which steps must always produce the same result, and are they workflows rather than reasoning?
• Control placement. Is each boundary enforced by permissions, or merely described in an instruction?
• Reversibility. Which choices are locked at creation, and have you treated them as architecture rather than settings?
• Cost visibility. Can you attribute spend to a specific agent, task and retry pattern, or only to a monthly total?

The fifth is the one that surprises teams in preview programmes, because it turns an experiment into a decision.

Three delivery options and their real costs

Prototype with prompts and tools. Fastest to a demonstration and genuinely useful for research and drafting. The cost is concealment: failure modes stay invisible until real data and real interruptions arrive.

Adopt a managed harness deliberately. You supply instructions, skills, tools and model choice; the provider runs the loop and sandbox. Maximum capability per unit of engineering effort. The cost is permanence: idempotency, checkpoints and approval records are yours to design inside a platform you did not build.

Build your own runtime. Total control of execution, retries and cost. Reasonable where agent execution is the product. Expensive where it is merely the plumbing under one.

None of these is wrong in every case. The error is arriving at one by accident and discovering at the first duplicate record which one you built.

A phased plan that produces evidence

• Phase zero, kill the agent mid-task. Before any feature work, interrupt one run deliberately and observe what happens. Most teams learn more in an hour than in a month of prompting.
• Phase one, write the action table. List every side effect, its reversibility and whether it needs proceed, confirm or escalate. Then implement the keys.
• Phase two, rehearse a duplicate. Replay one completed step and confirm nothing is written twice. Test the failure, not the intention.
• Phase three, publish the cost and approval record. Name who accepts an agent's output, on what evidence, with what override, and review it whenever the model or harness changes.

Four indicators worth baselining

Duplicate action rate: the share of side effects attempted more than once, measured after restart. Recovery fidelity: the share of interrupted runs that resume without human repair. Control coverage: the share of write actions enforced by permissions rather than instructions. Cost per completed task: spend divided by successfully finished work, not by tokens consumed.

Baseline all four on one workflow. A defensible improvement claim comes from your own before and after, not from a vendor's launch post.

Where JWA fits, stated factually

JWilliams & Associates architects, develops, integrates and operates enterprise software, multi-tenant SaaS platforms, AI-enabled business applications, automation systems and secure technology infrastructure.

Its stated design philosophy treats custom AI as a force multiplier for company staff, helping people perform meaningful work more effectively, rather than making staff replacement the default goal. That is a design philosophy, not a guarantee about outcomes.

No certification, partnership or productivity result is claimed here. Any such figure would require a measured baseline in a specific operating environment.

Evidence notes and limits

Evidence was reviewed through 19:00 UTC on 31 October 2026. Three Microsoft sources support the factual claims above, all dated or published around 28 October 2026: the official Copilot harness announcement; the Foundry announcement covering preview status, long-running resilience, checkpointing mechanics and pricing; and the Microsoft Learn unit on harness components and control boundaries.

All three are vendor-authored. None is an independent evaluation, and the product described is in public preview, which means behaviour and terms may change. Pricing figures are restated as published, with the caveat that Microsoft says prices may vary by region and agreement.

Customer quotations are Microsoft-published testimonials, labelled as such, and are not treated as evidence of general outcomes. No benchmarks, adoption figures, financial results or stock movements are asserted.

The six criteria, three options, phased plan and four indicators are analysis and suggested method, not a tested protocol.