Your Harness Exit Needs a Duplicate-Action Test

A duplicate can happen when the old runner completes an action but loses the acknowledgment, and the replacement treats that missing acknowledgment as permission to try again. An agent harness is the software that carries a model's instructions, tools and execution loop. Changing that software also changes how unfinished tool calls get interpreted.

Imagine a synthetic acceptance test: the old runner asks a service to create a support ticket. The service creates it, but the response never reaches the runner. The exported session says the call is unfinished. A replacement that simply replays unfinished calls can create another ticket. Both runners can follow their local records correctly while the combined workflow does the wrong thing.

The title of Destiner's essay on a lasting harness puts durability on the table. For a buyer, that raises a practical follow-up: what would happen if you had to leave yours? Our position at Gunner Technology is that a switch needs to preserve the meaning of unfinished actions, alongside the conversation and code.

The old runner must lose the ability to start or retry actions before the replacement gains it. Stop new assignments, pause scheduled retries and account for workers already running. A paused user interface doesn't establish any of those conditions.

Give the receiving service a way to reject requests from a retired runner where your architecture allows it. That could mean revoking its dedicated access or requiring an active ownership record before accepting an action. Enforce the restriction outside the agent. Asking an old session to stop politely leaves its background work outside the boundary.

Record which runner owns each interrupted task and when ownership transfers. If you cannot establish that the old worker has stopped, hold the task. As we explain in The Workflow Has to Survive the Agent, continuity belongs in the workflow. During a switch, continuity also requires knowing who can still act.

Check the receiving system for evidence of completion before retrying an action whose outcome is unknown. Separate actions that never started, actions confirmed complete and actions that may have completed. Collapsing the last category into failure is the mistake this test should catch.

Where the tool supports it, assign an idempotency key before sending the request. That is a stable identifier the receiving service uses to recognize repeated requests for the same action. Preserve that identifier across the harness switch. Generating a fresh identifier during recovery can turn a retry into a new action.

A local identifier cannot make an external tool honor that promise. Check what the receiving service actually guarantees, including how long it remembers requests. When it offers no suitable protection, look up the resulting object through a reliable reference. If the result remains ambiguous, stop and ask the responsible person to reconcile it. Don't have the agent guess from a similar ticket title.

Interrupt a synthetic action after the receiving service accepts it but before the old runner records success. Then transfer the task through the actual export and import path and let the replacement attempt recovery. Have a separate check inspect the receiving system for the result.

Also interrupt before submission and after confirmed completion. The first case should still allow the intended action to happen; the second should leave the completed result alone. Otherwise a migration that avoids duplicates by dropping unfinished work could look successful. Include a delayed response and an old worker that attempts a retry after losing ownership.

Keep these tests away from real customer records. Use a disposable service or an isolated test account, with observations the switching agent cannot rewrite. Preserve the harness versions, task record, action identifier and receiving system's evidence. Our handoff contract argument applies here: the next stage needs a mechanical reason to accept or refuse the work.

Before approving the switch, require a list of unresolved actions and their owners. The person deciding needs to know which work can resume, which work is complete and which work remains held. An import summary saying that every session loaded answers a different question.

Test the route back as well. If the replacement fails, restoring the old harness must not replay actions completed during the trial. Reconcile the action record again before handing ownership back. A rollback changes the worker; it doesn't rewind the services that worker touched.

Start with a bounded queue and rehearse its interrupted actions before moving more work. People decide whether the remaining uncertainty is acceptable. The factory should collect the evidence, block unsafe retries and carry unresolved work to that decision. Owning the code makes an exit possible. Proving that the exit won't repeat yesterday's work makes it usable.