One of the 3 promise that a database do is: I will Survive. Traditionally it was physical: disk, memory, replication, OOM. The hardware side. With agents, that definition is too small. Five things change.

Discovery shifts from hours to weeks

When a human breaks something, somebody notices. The team channel lights up. A manager asks. A jira ticket appears. The discovery window is short because humans confess.

When an agent breaks something quietly, nobody sees it. The classification worker’s been silently retrying inserts since the deploy three weeks ago. The cleanup agent’s been deleting rows that match a wrong predicate. The data drifts. The drift is found when an aggregate stops adding up, which can be a month later.

Your binlog_expire_logs_seconds was set assuming human discovery. It needs to be set for agent discovery. The default thirty days is no longer a ceiling. It’s a floor.

Recovery target stops being a point in time

Human disasters are catastrophic and obvious. Someone dropped the table. Restore to 14:00. Done. The point-in-time model assumes a single bad moment.

Agent disasters are distributed and silent. Eighty thousand rows deleted at once is the easy case. The hard case is six rows changed wrong by a confused agent every hour for three weeks, mixed with the millions of legitimate changes during the same window. There’s no point in time to restore to. The bad changes and the good changes happened at the same time, in the same tables, against the same rows.

Recovery becomes selective by row, by predicate, by agent identity. Not by clock.

Forensics flips from incident to operations

Forensics used to be something you did when something broke. The default mode of operating MySQL didn’t include “what changed in the customers table this week.” That was an exceptional question, asked maybe twice a year.

With agents the question becomes weekly, sometimes daily. What did the cleanup worker do in production yesterday? Why did the row count on users drift? Which agent issued the most updates against orders last Friday? These are not incident questions. They are operational ones.

mysqlbinlog | grep was an incident tool. Operational forensics needs an index, a query interface, and retention sized for the operating cadence.

Defenses inside the database can be defeated by the agent operating the database

The agent has database privileges. The defense is in the database. Pick which one wins.

deleted_at columns can be UPDATEd. Audit triggers can be DROPped. Append-only tables enforced by application code can be bypassed by an agent that bypasses the application. Soft deletes are a comfort the agent can withdraw.

For a defense to hold against the actor that has database privileges, it has to live where the actor cannot reach. The binary log written to disk by the database itself, before any agent touches it, is the closest thing MySQL gives you. Out of the box. The defense already exists. Most teams just don’t read it.

Prevention scales sublinearly. Reconstruction scales.

With human callers, prevention paid off. Code review caught bugs. Senior eyes caught misuse. Training reduced incidents. The investment compounded.

With agent callers, prevention helps and stalls. Guardrails work for known failure modes. The next confused agent finds a new one. Every public agentic deletion in the last year happened to a team that had read about the previous incidents.

Prevention is necessary. It is also insufficient. The defense that scales is the one that lets you reconstruct what happened, not the one that tries to stop it.

What this means

The three promises are still the three promises. Execute Queries is still ACID. Manage Relationships is still about who is on the other side. Survive is still about the database staying available.

The job description for each one changed. The diagnostic questions in order: Did the caller understand what they asked for? What kind of actor is on the other side? If something goes wrong, can the state be reconstructed and how long would it take? If you can answer those for your production database, you’ve done the work the agent era requires.

This is where the series ends. The frame is mine. The implementations are not one person’s job.

These five points are load-bearing for what we have been building. We call it dbtrail. If you’ve gotten this far, you already know what it does.