Recovering an interrupted agent skill

A scale request is sent, the tool times out, and the agent restarts. Its conversation remembers that scaling was requested. The destination may already have changed. This hypothetical interruption is a revealing test of a reusable agent skill: can the capability recover the unfinished action, or does reuse simply mean running the happy path again?

Here, an “operational skill” means a reusable capability with an execution contract: what it accepts, what it may change and how its outcome is established. Products use the term differently. An instruction file can describe all of that, but the tools and surrounding application still have to enforce permission, persist execution state and verify the result.

A read-only evidence bundle as a starting capability

An evidence-bundle compiler makes a useful first capability. Given a service and incident window, it gathers dashboard links, recent changes, the current runbook and the ownership record. Missing or stale sources remain visible. A responder can then judge whether the bundle reduces searching without having to infer whether a hidden infrastructure action occurred.

Even this read-only job needs a specific request: service identifier, time zone, allowed sources and maximum retrieval size. A structured schema can validate shape, while the tool still has to check that the service and timestamps make sense. A free-text incident description can contain useful evidence without authorizing access to more data than the capability was allowed to retrieve.

A write adds unfinished external work

The scaling example introduces something a missing document does not: an external action that may already have happened. Its contract needs a durable operation record that survives the agent restart. Otherwise a second invocation can create another change while describing it as recovery of the first.

For the scaling request, the preconditions identify the deployment state considered during approval, while the permitted change specifies the replica adjustment allowed. Duplicate handling establishes how a repeat is recognized or reconciled. Verification asks whether the service achieved the intended result, and stop behavior leaves unfinished work in a recoverable state.

Model confidence cannot fill a missing contract field. It may not be calibrated, and a persuasive malicious document can influence the proposal without changing what is authorized. The executor therefore needs the actual target, current state and permitted change, rather than a general statement that the agent believes it should proceed.

Recovery begins at the destination

After the scale timeout, the next question is what the destination did. The executor queries that state before choosing whether another write is appropriate. If no available observation can establish the outcome, it stays unresolved for human reconciliation with the original evidence attached. That is a useful recovery result even though the automated task cannot finish yet.

An unresolved action needs to persist across restart, together with the destination check that must run before another write. A restarted executor then has a specific point to resume from: the last fact established and the observation required next. It does not have to reconstruct a transaction from the agent’s memory of its plan.

Saving a record does not make the destination idempotent; when reliable reconciliation is unavailable, narrow the operation or require a human decision about residual risk. Persistence helps remember what must be resolved, but it cannot create an API guarantee the external system does not provide.

Once the destination confirms the change, verification moves to the service. Deployment state can be observed through the deployment API, while an independent checkout request can test the user-facing effect. Adverse effects elsewhere also matter. A failed check may call for containment when rollback is no longer safe, rather than another attempt to perform the original procedure.

A suggested application state model distinguishes proposed, authorized, submitted, observed complete, verified and unresolved. These are design choices for the surrounding application, not a protocol supplied by the model. Persisting the last established state and the observation needed for its next transition lets recovery proceed from evidence after restart.

A timed-out write belongs in an unresolved state

Read diagram description

Suggested application states: approval permits submission, an observed result permits verification, and an ambiguous result requires destination-state reconciliation. Never turn a timeout directly into a blind retry. Diagram labels: Proposed → authorized: Exact change and current preconditions; Submitted: Persist operation key and target; Observed complete: Destination confirms action; Unresolved: Timeout or ambiguous result; Verified: Independent service check; Reconcile destination: Establish state before any retry.

Where duplicate delivery and interrupted execution matter

Duplicate delivery, stale approval, a missing dependency, denied permission and a stop request during execution all exercise different promises in the capability. Retain request identity, policy version, approved change, tool result and verification evidence so a reviewer can explain each transition. That record does not require copying unnecessary sensitive payloads into logs.

Advisory and executing modes need separate evaluation because an incorrect suggestion and an incorrect write have different consequences. Track useful completion, wrong changes, unresolved outcomes, operator correction and elapsed time. The production-agent operations guide explains how those records support response when the capability fails.

A reusable scaling skill includes the recovery path: locate the original operation, inspect the destination and continue to service verification only once the result is established. When those checks cannot resolve the timeout, the operation stays visible for a responder. The next invocation then resumes unfinished work instead of starting a second change.