The Domesday Default

In 1086, William the Conqueror sent clerks into every shire in England to write down who held what — every landholder, every plow and pig, each entry reconcilable to a named individual. They called it the Domesday Book, not because it dealt in death, but because there was no appeal against its judgment. The record was permanent. And no one voted for it.

A version of that ledger is now running inside most enterprise AI deployments, and almost no one intentionally signed off on it. The moment your vendor’s agent gained memory, through chat, web, MCP, CLI, API, or a new integration like Claude Tag, it began holding identity-linked state for every employee who touched it: a running model of each person, in the vendor’s records, reconcilable to a named individual, kept indefinitely. Nobody decided that. It was the default.

It’s easy to see how this happened. We’ve all been focused on moving as quickly as possible to implement AI. But, treat agent memory as an infrastructure choice - a question of cost, latency, and where the embeddings sit - and you inherit the whole ledger without ever examining it. The question you’ll grapple with, after the contract is signed and the system is already in production, is different: not where the bits live, but who the agent is allowed to remember, and for how long.

That question defines enterprise AI in 2026, and it’s easy to gloss over it in our effort to keep up with the latest innovation. Let me start with the deployment forcing the question this month.

Anthropic’s Claude Tag is the cleanest recent example of how the default arrives. Admins can scope which channels, tools, data sources, and codebases Claude reaches; they can set spend limits and review logs of everything Claude did and who requested it. Private-channel memory stays isolated. On paper, this is governance.

But look at what actually happens when you enable it. Claude isn’t just reading a Slack thread. It retains channel context, pulls from connected tools, and, if you let it, proactively surfaces updates across the channels you’ve scoped. The contract probably doesn’t change: Anthropic frames Claude Tag as a beta for Enterprise and Team customers that replaces the existing Claude-in-Slack app, with a 30-day migration window. That reads like a product transition, not a rewrite of your MSA. Commercial usage stays outside the consumer training program, and any BAA or special clause you negotiated is meant to carry forward.

So the safest reading is this: your terms stay the same, but your operational footprint expands the moment you grant broader access. The contract didn’t move. The ledger did. That gap, terms unchanged, memory surface enlarged, is exactly how the Domesday default works. No appeal, no vote, just a checkbox that scoped one more agent into one more set of channels.

Which is why the right questions at evaluation aren’t about features. They’re: is this covered under our current order form, are log and memory retention addressed in writing, and did someone with authority actually approve channel-scoped access? If you can’t answer those, you’ve accepted the ledger.

The default enterprise instinct is to centralize. Memory in the cloud means observability, lifecycle management, audits, one place to enforce policy. It makes the security team comfortable and the architecture team productive. I’ve spent a career making that argument for hyperscale platforms.

But that argument was built for transactional data - things like orders, clicks, sessions, and support tickets. Centralization gave us a single source of truth for events that had already happened.

Agent memory is not that. Agent memory is the substrate of an ongoing relationship: the running model the agent keeps of who you are, what you’re trying to do, what it learned about you, what you asked it to forget. When that record sits in a third-party tenant, you haven’t made an infrastructure choice. You’ve decided that the long memory of a person, a customer, an internal team, will be held by a vendor, at rest and in motion, across the indefinite life of the model.

That’s not a deployment convenience. That’s a governance posture based on the wrong focus: infrastructure.

And here’s what will haunt us later: twelve months of identity-linked memory in a vendor’s tenant will be the highest switching cost in the AI stack. Higher than model choice. Higher than the orchestration framework. You can swap an LLM in an afternoon. You cannot swap out a year of accumulated user state without rebuilding the relationship from zero. The Domesday Book’s power wasn’t the parchment. It was that you couldn’t appeal it.

You cannot solve memory by picking a vector database, because placement is a runtime control problem, not a storage decision. Concretely, it’s four problems:

- Storage. Where the bits live and who can read them.

- Decay. How memory ages — what the agent should recall after thirty days versus thirty months, and when it expires.

- Deletion. What “forget” actually means once an LLM has already shaped its responses around something, and how you prove deletion to an auditor, a regulator, or the person who asked.

- Poisoning. What happens when something hostile or wrong gets written into long-term memory, and how the agent’s downstream behavior bends because of it.

You can solve these in the cloud or on-device. What you cannot do is solve them by accident. They’re runtime disciplines, and the test below won’t resolve them for you — it tells you which deployments demand you resolve them before the first row is written.

Here’s a framework you can use when leaders ask where agent memory should live. Three layers.

Layer 1: Sensitivity of the aggregate — not the average. The worst case. Six months in, the cumulative memory is almost always more sensitive than any single interaction. If sharing that aggregate externally would require a contract, a DPA, or a board conversation, the placement decision has to be made with the aggregate in mind from day one, not the first row.

Layer 2: Durability of identity. If the memory is tied to a named user, an employee profile, a customer record, then placement is an identity decision. The further identity-linked memory travels from its system of record, the more reconciliation, deletion, and audit risk you take on. Ask yourself: would you be comfortable explaining the data flow, in plain English, to the person being modeled, before the deployment ships?

Layer 3: Half-life of the value. Some memory is high-value for an hour and worthless in a week — the agent helps someone finish a workflow, and the long memory adds nothing. Other memory compounds for months. Short half-life memory has almost no business case for centralization. Long half-life memory does, but only if the discipline around decay, deletion, and poisoning is in place first.

Apply the framework against any deployment on your roadmap and the answer is rarely “all cloud” or “all device.” It’s layered: short-term, low-sensitivity, low-identity memory close to the user; long-term, identity-linked, high-sensitivity memory held under deliberate governance, usually closer to the system of record than to the model.

Pick one deployment. Three yes/no questions:

1. If you stacked six months of this agent’s memory into one document, would sharing it externally require a contract or a board conversation?

2. Is the memory reconcilable to a named individual outside the system of record for that identity?

3. Does the value of the memory still exist a month after the last interaction?

A yes on any one is a flag. A yes on all three, with memory placed in a vendor tenant by default, is the Domesday meeting I opened with, where you discover the ledger was written and there’s no appeal.

The placement decision is being made every week, by engineering teams, by vendors, by default, without the governance conversation ever happening at the leadership level. The pre-PMF team accepts the vendor’s twelve-month identity-linked memory at the same time as the seat pricing; there’s no security team in the room to push back. Eighteen months later, post-Series A, with a real CISO and a customer asking where their employees’ data is modeled, that checkbox is a six-figure migration and a board-level conversation. The founders I work with aren’t making bad decisions. They’re making no decision, very early, where the default carries forward.

The asymmetry to internalize: centralization is reversible at the infrastructure layer and irreversible at the trust layer. You can re-platform a vector store. You cannot un-tell a customer, an employee, or a regulator that their identity-linked memory sat in a vendor’s tenant for a year.

The leaders who get this right in 2026 will treat memory placement as a board-visible data-control decision, not a vendor selection. They’ll ask their teams to show, in writing, where agent memory lives, who can read it, how it decays, how it gets deleted, and what happens if it gets poisoned — and they’ll accept that the right answer differs by workload. The architectural cost of getting that right is dramatically lower than the trust cost of getting it wrong.

If you’re inside that decision now: map your current and planned deployments against the three layers, and find the one where the answers feel least defensible. Not the biggest. The least defensible. Trust erodes from the weakest link, not the largest one.

Reply with your layer-three answer — the one deployment where the half-life question feels hardest to defend. I read every response, and the patterns across operators are starting to look like the early shape of a real discipline. I’ll write back with what I’m seeing from the other side of the same question.

— Jason C. Lewis

Operator’s Log · [jasonclewis.com]