On this page4 sections
The agent asks for more copies of a service to handle the load. The tool waits, then times out. After a restart, the conversation still contains the request. Somewhere else, the deployment may already have changed.
“Run it again” sounds like continuing the job. In this hypothetical interruption, it might be doing the job twice.
A reusable agent skill has to handle that gap. Here, skill means a repeatable operational capability with stated inputs, permissions and outcome checks; products use the word differently. Packaging the instructions makes a procedure available again. The surrounding application must also preserve what happened, enforce what is allowed and recover when the answer does not come back.
First, give the responder something they can open
Before giving the skill a write operation, a useful first job is gathering the material a responder needs. Supply a service and incident interval; return dashboard links, recent changes, the operating procedure and the ownership record. This read-only evidence bundle gives someone a concrete result to inspect.
If the ownership record is missing or a dashboard link is stale, the responder can see the gap. They do not also have an infrastructure change to recover.
The inputs need boundaries of their own: service ID, time zone, allowed sources and how much material to retrieve. A schema can check that the request has the expected structure. The tool still has to check whether the values make sense. A service named inside an incident description does not automatically become another service the tool is allowed to read.
The scale request needs more than a saved plan
Reading the same bundle twice usually means repeated work. Applying a scale adjustment twice may repeat an effect. The write needs a record that survives the agent stopping, with enough detail to recognize the original operation when it returns.
| Part of the contract | What the next responder needs to know |
|---|---|
| Before the change | How fresh the information must be, the resource state and compatibility, and the required approval. |
| Allowed adjustment | The named deployment, the approved change to its replica count and the bounds on that change. |
| A repeated request | A stable operation key and a way to reconcile the result with the destination's state. |
| Checking the outcome | The resulting deployment state and user-facing health over a stated interval. |
| Stopping | No further writes; preserve the record and notify the responsible owner. |
For our scale request, replicas are the copies of the service being run. Save the deployment state considered for approval, the exact permitted adjustment and its limits. Give that operation a stable key, an identifier the application keeps when the same request is encountered again. It helps the next invocation recognize unfinished work rather than create a new job with a familiar description.
The record also needs to distinguish “the change happened” from “the change helped.” Neither a confident model sentence nor an instruction found in a retrieved document can supply missing authorization. The executor needs a real target, an allowed change and current conditions it can check.
Ask the deployment what happened
After the timeout, start with what the destination can establish about the original operation. That is reconciliation: matching the saved request with what the receiving system can tell you, rather than treating the missing reply as proof that nothing happened.
If the available information cannot settle the result, keep it unresolved. Preserve the question, the supporting record and the next destination check for whoever resumes the work. A new invocation should find that unfinished operation before creating another one. Otherwise, the restart has erased the most important fact: the previous run did not know whether the change happened.
An identifier alone cannot make a remote software interface safe to repeat. Idempotency means a repeated request does not cause an additional effect; the receiving operation has to support that behavior. Saving a key in the agent's own record does not confer it on the destination. If reliable reconciliation is not possible, narrow the operation or seek a human decision about the remaining risk.
Once the destination confirms the scale change, check the service itself. A changed replica count and a customer successfully completing checkout are different observations. If the service check fails and reversing the change would be unsafe, containing the problem may be more appropriate than another run through the procedure.
Read diagram description
A proposed application design: submit after authorization, verify after the destination confirms the action, and investigate an uncertain result at the destination before considering another attempt. A timeout alone does not justify a 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.
Rehearse the restart, not just the successful run
The application can track proposed, authorized, submitted, observed-complete, verified and unresolved work. These states answer different questions. Was the change permitted? Was it sent? Did the destination confirm it? Did the independent service check show the intended result? They are design choices for the application, not a recovery protocol supplied by the model.
Exercise duplicate requests, stale approvals, missing dependencies, denied permission and a stop midway through the job. Keep the request identity, policy version, approved change, tool result and verification record, without retaining unnecessary sensitive payloads. The point is to leave enough for a responder to continue, not to collect everything the system saw.
Evaluate advisory and executing modes separately. Wrong advice can send a responder in the wrong direction; a wrong write can change the service directly. Track useful completion, incorrect changes, unknown outcomes, operator corrections and elapsed time. The production-agent guide connects those records to recovery.
When our interrupted skill returns, it now has somewhere useful to begin: the original operation, then the deployment's state, then the service check. If the result remains unknown, the next responder receives that uncertainty instead of a freshly repeated change. Reuse means continuing the job with its history intact, not starting the instructions from the top and hoping the first attempt left nothing behind.
Source context
This article does not include external reference links. Read it as the author’s perspective and evaluate the guidance against your environment.
Report an error or outdated detail