# Recover a write after a lost reply

> Look up the first recorded outcome without applying the write again.

Canonical page: https://anectico.com/docs/manage/write-recovery/


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`:

```sh
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.