Recover a write after a lost reply

A timeout can happen after a write committed. Keep its original action, exact arguments and stable retry key. A current-object read can show a later edit; it cannot prove which earlier write committed.

Look up the recorded outcome

Save the original arguments in intent.json, leaving out confirm_token:

anectico writes lookup set_agent_spend_budget \
  --idempotency-key approved-intent-1 --file intent.json --json

Through MCP, call lookup_write_outcome using execute_read_action with the same action, arguments and idempotency_key. Through REST, post that object to /api/v1/write-outcomes/lookup. Keep the exact original project and values.

You need activity:read and must still hold the original write's permissions and authority. You can recover only your own credential's writes. MCP also requires mcp:read and mcp:write. A recorded result is the first outcome, even when someone edited or retired the object later. Lookup does not request another approval or spend another write operation. One-time credentials remain withheld; rotate them if the original secret was lost.

Understand the answer

• recorded with durability: owner comes from the retained first-result record.
• recorded with durability: bounded comes from a retained short-lived result.
• unknown_or_expired means no outcome can be recovered under this request. It does not mean the write failed. Keep the same intent and key and resolve the uncertainty before starting another write.

Finding, ordinary alert-rule, metric-watch and responder creates retain stable key recovery across restarts and later edits. Other actions follow their stated retention contract. Privacy erasure and workspace deletion can remove recovery. The original result does not prove external delivery or the object's current state.

You may use --request-id instead of --idempotency-key when you retained the original request correlation ID and exact arguments. Correlation normally lasts ten minutes and can be unavailable after a lost reply. Keep the write's stable key for durable recovery; lookup does not extend retention.

Recover a spend policy in the console

If a spend apply reply is lost, the console keeps the reviewed intent and key and disables another apply. Choose Recover spend receipt. A recovered receipt shows the first committed policy observation separately from the refreshed current policy. An unknown answer keeps the intent unresolved. Recovery does not replace a later policy or confirm a new proposal.

Ask your agent

Use the installed anectico-cli skill. The lookup_write_outcome read action uses the original action, exact arguments and key, under activity:read and the original write's current authority. It returns the retained outcome without confirming another write.

Recover my earlier write using this action, exact intent and stable key. Show the first recorded result separately from current state. If recovery is unknown, retain this key and do not start another write.