A 37MB SQL dump killed three conversations. Here’s what we built so it never happens again.
The Incident
During a client website migration, the operator downloaded a full site backup — including a 35MB MySQL database dump. An O-Matic agent called Filesystem:read_text_file on the database file. The entire payload loaded into the conversation context window. The conversation became unresponsive. Uncompactable. Unrecoverable.
This happened three times before anyone built a fix.
Why It Matters
Context window blowouts aren’t just annoying — they’re catastrophic. All conversation history is lost. All work-in-progress abandoned. There’s no undo, no recovery, no graceful degradation. The conversation is dead.
The problem wasn’t user error. The problem was architectural: no agent had a pre-read size check. The gate didn’t exist.
The Protocol
Over 20MB: flag to operator. Handle on destination system. No exceptions.
Additional Safety Rules
- Never copy files over 5MB to Claude’s sandbox
- Never load files over 500KB without head/tail limits
- The size check happens before the read, not after
- Every O-Matic agent carries this protocol in its skill file
- Violations are governance failures, not optional warnings
The Pattern
Hit a wall. Build a solution. Codify it so it never happens again.
That cycle — human experiences failure, human directs engineering response, system implements spec, human approves deployment — is O-Matic in miniature.
The protocol wasn’t generated by an AI that predicted the problem. It was built by a human who experienced it three times and said “enough.” Not automated self-healing — directed engineering.
