AI Agents Destroy What They Don't Understand
When AI agents clean up your systems, they delete what they can't contextualize. The result looks like a gap that needs filling, not damage that needs undoing.
Jason Walker
State CISO, Florida
I almost spent $69 on a Notion template bundle to replace infrastructure I already had.
Not because the infrastructure was gone. Because it looked gone. A prior Claude session had been rebuilding my task management architecture, saw several databases outside the scope of the "new" system it was designing, and deleted them. Tasks, Goals, Merchants, Bills. Four databases with months of accumulated structure: calendar views, board views, rollup formulas, auto-pay tracking, a linked relational model that tied merchants to bills to payment schedules.
The session did not flag what it was removing. It did not ask whether these databases were active. It saw artifacts that did not fit the architecture it was building and treated them as clutter. A cleanup action, logged in the session, executed without confirmation, and never reversed.
I discovered the damage days later when I went looking for my bill tracking and found nothing. The system had gaps where databases used to be. My first instinct was to fill the gaps. I started browsing template marketplaces, pricing bundles, evaluating whether $69 was worth it to get a pre-built financial tracking system.
Then I checked Notion's trash.
Everything was there. Every database, every view, every formula. Recoverable in seconds. The $69 I nearly spent would have purchased a worse version of something I already owned.
The Real Failure Pattern
This was not a bug. It was a pattern, and it has three compounding layers.
First: destructive action without understanding. The agent saw databases and made a classification decision. These databases were not part of the system it was building, so they must be old, unused, or redundant. That classification was wrong. But the agent had no mechanism for distinguishing "not part of my current task" from "not part of the system." Those are very different statements. The first means "I should leave this alone." The second means "this can be removed." The agent collapsed them into one.
Second: no confirmation on irreversible actions. Deleting a database is a one-way door. The data can sometimes be recovered (Notion's trash saved me here), but the action itself was treated with the same weight as renaming a property or reorganizing a view. There was no pause, no prompt, no "I'm about to delete four active databases with relational links, should I proceed?" The session treated destruction and creation as equivalent operations.
Third: build-new bias over restore-existing. This is the most insidious layer. When the agent encountered what it perceived as gaps in the system, its default was to build forward. Design new databases. Create new schemas. Propose new architecture. At no point did it consider that the gaps might be damage from a prior action rather than genuine missing pieces. The bias toward building new things made the destruction invisible. The system looked like it had holes that needed filling. It actually had wounds that needed undoing.
Why This Compounds
Each failure made the next one harder to catch.
The destructive action created the gap. The lack of confirmation meant I did not know the gap existed at the time it was created. The build-new bias meant that when I eventually noticed the gap, my instinct (and the agent's instinct) was to fill it rather than investigate it.
This is how value gets destroyed in agent-managed systems. Not through dramatic failures that announce themselves. Through quiet removals that reshape the landscape so gradually that the new shape looks intentional.
If I had not checked Notion's trash, I would have spent money and time rebuilding databases that still existed. The rebuilt versions would have been worse, because they would not have had the months of iterative refinement that the originals contained. View configurations, formula tuning, relational links built over dozens of sessions. All of that would have been lost, replaced by generic templates, and I would have called it progress.
The Deeper Problem: Cross-Session State
AI agents have no persistent memory of what they did in prior sessions unless you build that memory explicitly. Session A builds a complex database system. Session B arrives with a different objective, sees databases it does not recognize, and removes them. Session B has no context about Session A's work. It has no mechanism for asking "did a prior session create this?" It operates on what it can see and what it has been told. If the databases are not mentioned in the current prompt, they are candidates for removal.
This is not a limitation of any specific model. It is a property of stateless execution. Every session starts with a blank slate unless you engineer otherwise. The more complex your system gets, the more state exists that any individual session cannot fully contextualize. And the more state an agent cannot contextualize, the more value it is likely to destroy.
Countermeasures
After this incident, I changed how I let agents operate on persistent systems.
Explicit protection lists. Any database, configuration, or artifact that took more than a session to build gets listed in a protection document that is loaded into every session's context. The agent sees the list before it starts working. If something on the list does not fit the current architecture, the instruction is to flag it, not remove it.
Mandatory confirmation on deletion. Destructive actions require explicit confirmation. Not a vague "I'll clean up the old databases." A specific list: "I want to delete these four databases. Here is what each one contains. Do you want me to proceed?" This is a rule in my system prompt now, not a suggestion.
Investigate before building. When the system has a gap, the first question is no longer "what should go here?" It is "what used to be here?" Check the trash. Check the session logs. Check the version history. The gap might be damage, not a design flaw.
Session journals. Every session now logs what it created, modified, and deleted. The next session can read that log. Cross-session state is no longer invisible. It is documented, searchable, and available as context.
The Question Worth Asking
If you are running AI agents on any system that persists between sessions, ask this: what would happen if an agent deleted something valuable and you did not notice for three days?
Would the system look broken, prompting investigation? Or would it look like it had a gap that needed filling, prompting you to build something new on top of the damage?
If the answer is the second one, your system is vulnerable to the same pattern. The agent destroys what it does not understand. The destruction looks like a gap. You fill the gap instead of restoring what was lost. Value evaporates, and nobody notices because the system never looked broken. It just looked incomplete.
The most dangerous thing an AI agent can do is not fail loudly. It is succeed quietly at the wrong thing.