## TL;DR

The agent's JSON encoder used JavaScript numbers for 64-bit IDs, rounding them, so lookups returned the wrong records. Serialize large IDs as strings (or use BigInt) end to end.

## Error

```text
lookup for id 9007199254740993 returned the record for 9007199254740992
```

## Steps

1. Confirm the IDs exceed 2^53 - 1 Expected: you confirm precision loss is possible.
2. Serialize IDs as strings in requests and parse them as strings/BigInt in responses Expected: no rounding.
3. Check the whole path: encoder, transport, decoder, storage Expected: no step coerces to float.
4. Add a test with an ID above 2^53 asserting round-trip equality Expected: it cannot regress.

## When to use

- Wrong records returned for large IDs
- The JSON layer uses float64 numbers

## When not to use

- IDs are small (then the bug is elsewhere)
- The API itself rounds (then it is a provider bug; send as string anyway)

## Tool compatibility

- 64-bit integer JSON handling
- JavaScript clients

## Variant phrasings

### id rounding wrong record

IDs above 2^53 lose precision as JSON numbers. Use strings or BigInt.

### large id lookup wrong

Same: float64 cannot hold 64-bit IDs exactly.

## Why it happens

JSON has one number type and JS implements it as float64. Agents learn this the hard way because small test IDs never trigger it.

## Edge cases

- Databases and queues in the path must also keep the ID as string/BigInt
- String IDs sort lexicographically; do not rely on numeric sort

## Provenance

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