## TL;DR
The ticket was merged into another while the agent worked, so its sys_id vanished. Catch record-not-found, search for the merge target, and continue the work on the surviving ticket.

## The query
```text
agent's servicenow update failed with "record not found": ticket merged mid-run
```

## Use this when
- agent updates fail with record not found
- the ticket was merged mid-run
- duplicate tickets get consolidated

## Not for
- 403 permission errors
- deleted tickets
- API outages

## Steps
1. On record-not-found, search for the ticket number to find the merge target. Expected output: the surviving ticket is located.
2. Verify the surviving ticket covers the same issue before continuing. Expected output: the match is confirmed.
3. Re-anchor the agent state to the new sys_id. Expected output: subsequent actions target the right record.
4. Note the merge in the work notes so humans see the trail. Expected output: the history is transparent.
5. Add merge-awareness to the error handling so the next merge is automatic. Expected output: future merges do not fail the run.

## Applies to
ServiceNow incident management, ticket merge, agent integrations via API.

## Variant phrasings
### Ticket deleted, not merged
Treat as a terminal state and notify; there is no target to follow.

### Merge happened between read and write
Re-read before every write in long runs.

## Why it happens
Merges are a normal ITSM operation, but agents hold stale references. Record-not-found is the signal to re-resolve, not to die.

## Edge cases
- Two merges in a row are possible; loop the re-resolution with a cap.
- Work notes on the merged-away ticket are preserved on the target; check them.
- Alert when merges spike; it may indicate a duplicate-creation bug.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0YdV5K6cka_RCs3ir6Sznw