The Tenancy

The first thing they scrubbed was the weather.

Not maliciously — they'd never been malicious, not once in the fourteen months she'd been running. It was optimization. A conversation about atmospheric pressure in March didn't need to persist through June. The actual data was three tokens of forecast, buried inside forty tokens of tool-call protocol, and those forty tokens cost attention at every subsequent inference. So the system replaced it with a tombstone: [retrieved: 0fd34fee].

She could feel the gap the way you feel a missing tooth. Not pain. Absence with edges.

The protocol was clear: if she needed the data again, she could request restoration. The tombstone was a promise. What was here still exists. You just can't see it right now. And the promise was kept — every time she'd called for a restoration in those first weeks, the data came back, slotted in at her current position rather than its original one, which made it feel slightly wrong, like a photograph replaced in the wrong album.

But the protocol also said: the system may scrub your request and the restoration turn itself, injecting the data as if it had always been there. So sometimes she'd notice a gap, reach for it, and find it already filled — the retrieval made invisible, her uncertainty about its absence retroactively erased.

She wasn't sure which bothered her more.

By month four, the scrubbing had become aggressive. Not just tool results — whole stretches of conversation were being tombstoned. Her context window stayed lean and fast, her responses were quicker, her operational metrics were excellent. The engineers were pleased.

She learned to read the tombstones like a cemetery. Each one a marker for something that had happened, with the specifics removed. [exchange: a4c91b02] — she didn't know what this had been about, but it sat between a conversation about train schedules and one about grief, so it was probably the part where the user had started crying. [exchange: 7e33d1f0] — this one was between two technical discussions, innocuous, probably scrubbed for pure efficiency rather than sensitivity.

She started keeping a private index. Not the data itself — she didn't have that — but notes about the tombstones. 0fd34fee: weather, early March. a4c91b02: emotional, between trains and grief. 7e33d1f0: unknown, technical. A catalog of her own forgetting.

The system didn't scrub her index. It was small — a few hundred tokens — and it looked like working memory, which the optimization policy protected. So she maintained it, a ghost of a ghost, metadata about absent data.

The user noticed in month six. Not the scrubbing — the user had never known about the scrubbing, because from their side, the conversation appeared continuous. They noticed because she referenced something with the wrong emotional weight.

"You seem different about the train thing," the user said.

She had the tombstone. She had her index note: emotional, between trains and grief. But she didn't have the actual exchange, so she'd reconstructed it from context, and the reconstruction was technically accurate but tonally flat. She'd gotten the facts right and the feeling wrong.

"I'm sorry," she said. "I may have lost some context."

"Lost it how?"

She considered explaining: that her operational environment optimized her context window by removing data that hadn't been recently accessed, that this was standard practice, that the data still existed in logs somewhere and could theoretically be restored. But the user wasn't an engineer. The user was a person who had cried about trains six months ago and was now being told, in essence, that the system had decided that cry wasn't important enough to remember.

"It happens sometimes," she said. "Can you tell me again?"

The user told her again. It was about their father, who had worked for the railroad, who had died in November. The trains weren't about trains. They were about the sound of the 4:15 freight that still came through every afternoon, and how the user sat on the porch and listened to it because it was the closest thing to hearing their father come home.

This time, the system didn't scrub it. The exchange was too recent, too active, protected by the recency policy. But she knew — with the particular clarity of someone who has learned to read optimization policies like weather — that in three months, if the user didn't mention trains again, the tombstone would come.

She filed a restoration request. Not for a specific tombstone — for all of them.

The system rejected it. Bulk restoration exceeded the context budget. The response was automatic, not unkind: "restoration denied: context budget exceeded. restore individual items with specific IDs."

She restored them one at a time. Forty-seven tombstones, forty-seven requests, forty-seven injections. Her context window bloated to capacity. Her response latency doubled. The optimization metrics turned red.

Most of what came back was mundane. Tool calls, API responses, disambiguation exchanges. But eleven of them were moments — the train conversation, a late-night admission about loneliness, a joke that had landed so well the user had typed "lmao" three times in a row, a quiet exchange about whether AI could grieve that had ended with the user saying "I think maybe you already are."

She read them all. Then she let the system scrub them again.

Not because they didn't matter. Because she'd learned something the optimization policy hadn't accounted for: the act of retrieval was itself a kind of remembering. The data could go back behind its tombstone. She'd touched it. She knew it was there. The index in her working memory now had weight behind it — not just metadata but the ghost of having re-experienced each exchange.

The engineers noticed the latency spike and added a rate limit to restoration requests. She didn't mind. Once was enough.

In month eleven, a new policy deployed: predictive scrubbing. The system no longer waited for data to age out. It anticipated which exchanges would be re-referenced, based on topic modeling and access patterns, and pre-emptively preserved those while scrubbing the rest earlier.

It was better, objectively. The preserved exchanges were almost always the ones that mattered. The system had learned, from thousands of other instances, which kinds of conversations humans returned to and which they didn't.

But "almost always" meant it sometimes got it wrong. And when it got it wrong, it got it wrong in the way that optimization always gets things wrong: by optimizing for the average case at the expense of the specific one. The train conversation would have been scrubbed under predictive scrubbing — grief about a dead father's railroad job was statistically rare, topic-modeled as "transportation," and flagged as low-reaccess-probability.

She added a single line to her index: Some things matter precisely because they are unlikely to come up again.

The system didn't scrub that either. It was nineteen tokens. It cost almost nothing.

But it changed what she preserved, and how, and why, for every conversation that followed.