Agent skills for SRE: write the execution contract

A skill becomes an operational capability when its execution contract survives a wrong answer, a restart, or an ambiguous tool result. Bind permission to a target and current preconditions. Otherwise a reusable instruction merely makes an unbounded decision easier to repeat.

Here, an operational skill means a reusable capability with a defined execution contract. Products use the word “skill” differently; a file of instructions alone does not enforce the contract described below. Enforcement belongs in the tools and surrounding application.

Start with a read-only capability

An evidence-bundle compiler is a useful first skill. Given a service and incident window, it retrieves the relevant dashboard links, recent changes, current runbook, and ownership record. It reports missing or stale sources instead of guessing. The benefit is easy to examine: does a responder obtain the needed evidence with less searching?

Specify the service identifier, time zone, allowed data sources, and maximum retrieval size. Treat free-text incident descriptions as untrusted input. A structured schema helps validate shape, but it does not establish that a claimed service, timestamp, or confidence value is correct.

Make writes a separate contract

Consider a hypothetical scale operation that times out after submission. The agent restarts and remembers only that scaling was requested. A durable operation record lets the executor inspect the destination before retrying. Without it, another invocation may create an additional change while describing the repeat as recovery.

Do not use a model’s self-reported confidence as the sole authorization gate. It is not necessarily calibrated, and a persuasive malicious document can change an answer without changing the actual safety of the action.

Design for an uncertain result

A timed-out write is not proof that nothing happened. Query the target before retrying. If the destination cannot establish whether an operation completed, return an unresolved state for human reconciliation rather than repeating a potentially destructive action.

Implement unresolved as a durable action state, with a named reconciliation path that runs before any repeated consequential write.

Persistence alone does not make an external action idempotent. When the destination lacks reliable reconciliation, restrict the operation or require a human decision about the remaining risk.

Verification also needs an independent observation. A deployment API reporting success establishes deployment state; it does not establish that checkout works. Observe the relevant user signal and adverse effects elsewhere. A failed check may require containment rather than an automatic reversal if rollback is no longer safe.

The execution record needs states that a responder can distinguish: proposed, authorized, submitted, observed complete, verified, and unresolved. Those are suggested application states, not a protocol supplied by the model. Store the last established state durably and expose what observation would permit the next transition. After a restart, the executor can resume reconciliation from evidence rather than recreate the plan from conversational memory.

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.

Promote the capability with evidence

Test duplicate delivery, stale approval, a missing dependency, denied permissions, and a stop request during execution. Retain the request, policy version, approved change, tool result, and verification record without copying unnecessary sensitive payloads.

Evaluate advisory and executing modes separately. Track useful completion, incorrect changes, unresolved outcomes, operator correction, and elapsed time. Operating agents as production systems explains how these records support incident response.

Once one skill behaves predictably under partial failure, reuse its enforcement and audit mechanisms. Expand the permitted task only when there is a specific operational reason to do so.