The Most Important Architecture Decision Was a Table

The most important architecture decision in my last agent project was a table.

Not the model. Not the orchestration. A table — because of a quiet crime almost every business system commits: it overwrites its own memory.

Think about how a standard record works. Status changes: old value gone. Owner reassigned: previous owner gone. Date pushed: original date gone. The system always knows where things are and never knows how they got there. We built a generation of software with amnesia and called it “current state.”

For twenty years that was mostly fine, because the questions were mostly “where is it now.”

Agents changed the questions. An agent that validates, routes, or predicts doesn’t learn from current state — there’s nothing to learn from a snapshot. It learns from history: what bounced and why, what got escalated, what the exceptions had in common. In one recent build, the change that made the agent possible wasn’t AI at all. It was converting an overwritten status into its own table, where every state change became a permanent row — when, why, by whom, how long.

Rows, it turns out, are the difference between a system that has data and a system that has experience.

So there’s an audit I now run on any system before an agent touches it: find the fields that overwrite. Every one of them is a question the organization already decided never to answer — and usually the exact question the agent will need answered.

A status field tells you where something is. Only history tells you why. And why is the whole job now.

Model choices are reversible. Data model choices compound.