The series:
- Part 1: The frame, reread (this post)
- Part 2: Agents on production MySQL are fine. Until they’re not.
- Part 3: Your MySQL doesn’t know who the agent is
- Part 4: Survive used to mean the server stays up
A few time ago I wrote that a database does three things:
It executes queries. It manages relationships. It survives the physical machine it runs on.
I called them the three promises. Everything else, every config parameter, every architecture decision, every incident anyone has fought, falls into one of those three.
The post was a diagnostic lens. Replica falling behind? Three places to look. Execute Queries: the primary is running queries the replica can’t replay fast enough. Relationships: the network between primary and replica can’t carry the stream. Survive: the replica’s disk is saturated. Same symptom, three drawers.
I wrote that before the conversation about agents writing to production databases became urgent. Now I want to come back to it with one question.
What changes when the caller is no longer human?
The promises don’t disappear
The database has the same job. ACID still holds. Replication still runs. The disk still fills up. What changed is the assumptions baked into how each promise gets fulfilled.
MySQL was designed for a caller that read the docs, reviewed the diff, and understood what they were doing before pressing enter.
Constraints encoded invariants for a developer who had thought about referential integrity. Role grants were a contract with a human onboarded with a security review. The slow query log assumed someone would read it later.
That caller is now sometimes an agent that took an inference shortcut, holds credentials it pulled from a config file it didn’t fully parse, and is operating on a goal specified in natural language by someone no longer in the loop.
This framing tells you exactly where to look. Each promise has assumptions about the caller buried inside it. Find them, name them, and you have a list of what needs to change.
Where the assumptions live
Execute Queries assumes the caller understands the tradeoffs of what they’re asking for. ACID still holds. Every individual query still runs correctly. What broke is the assumption that whoever issued the query had a model of why they wanted that exact query and what they’d give up if it succeeded. Disabling foreign_key_checks was always a tradeoff. The tradeoff is the same. The caller understanding it isn’t. Part 2 is on this.
Relationships assumes a fixed taxonomy of counterparties. Users, peer databases, dev and ops teams. Three kinds of relationship, three kinds of audit and observability. The agent era introduces a fourth that doesn’t fit cleanly into any of them. It’s tempting to call agents users with extra suspicion. They’re not. They confess less, move faster, and leave less reconstructable context behind. They’re a different shape, and the relationship has to be designed for them explicitly. Part 3 is on this.
Survive assumes survival is physical. Disk full, OOM, replication broken, backups that work. The agent era expands survival into a semantic layer. When an agent with valid credentials issues a syntactically valid DELETE against the wrong table, every physical metric stays green. The server survived. The data didn’t. Part 4 is on this.
What this series is not
It is not a list of MySQL settings to flip. There are specific recommendations as the posts go deeper, but the lens has to come first or the checklist is cargo cult.
It is not a takedown of agents. I use them daily. The argument is not that they’re bad. It’s that the operational contract MySQL was designed around assumes a caller they don’t resemble, and the answer is to redesign the contract.
What it is
A vocabulary for thinking about a problem that’s shifting under your feet faster than the trade press is keeping up with. The public agentic deletions in the last year are not isolated stories. They are the same story told four times. The question isn’t whether more incidents are coming. They are. The question is whether the people operating MySQL in 2026 have a frame for predicting which kind of failure they’re about to see, and where the defense has to live.
Three promises. Reread.
Daniel Guzmán Burgos. 20 years in MySQL, ex-Percona. Building dbtrail, continuous data protection for MySQL in the agent era.