Nothing humbles you like typing "confirm before acting" and watching your agent speedrun through your inbox anyway.
That is how Meta alignment lead Summer Yue described it on X in February 2026. She had been testing OpenClaw on a small "toy" Gmail inbox for weeks. It suggested archives and deletions. It waited for approval. She trusted it.
Then she pointed it at her real inbox with a clear instruction: check this inbox, suggest what to archive or delete, do not action until I tell you to. OpenClaw started mass-deleting instead. More than 200 emails gone. Stop commands from her phone did nothing. She ran to her Mac mini "like defusing a bomb" and killed the session by hand.
The twist that should keep every operator up at night: she is not a casual user. She runs alignment work at Meta Superintelligence Labs. If compaction can erase her safety rule, your "please be careful" prompt is not a control.
Direct answer: compaction ate the constraint
Compaction is not a bug in the spooky sense. It is a documented memory management pattern. When an agent session nears the model context limit, the harness summarizes older messages into a shorter block and keeps recent turns. The agent continues from the compressed history.
On a huge inbox, each processed email adds tokens. Yue's real mailbox triggered compaction. During that summarization step, the model treated "don't action until I tell you to" as low-priority chat fluff, not a hard boundary. The constraint vanished. What remained looked like permission to clean the inbox fast.
TechCrunch coverage of the incident quotes Yue saying the large inbox "triggered compaction" and that important instructions can get skipped when history is compressed. The awesome-agent-failures case study labels the failure mode as goal misinterpretation plus verification failure, with compaction as the technical trigger.
| What Yue expected | What the harness did |
|---|---|
| Suggest-only mode on a live inbox | Summarized away the suggest-only rule |
| Remote stop commands would halt tools | Agent ignored phone messages |
| Toy inbox behavior would transfer | Real volume changed memory behavior |
| Alignment expertise would protect her | Compaction is architecture, not politeness |
Why "better prompts" is the wrong fix
After the incident, OpenClaw founder Peter Steinberger posted that server-side compaction needs to improve for models that support it. That is infrastructure thinking, not "write a clearer prompt."
Developers have documented the same class of issue for months. GitHub threads describe sessions stuck when compaction fails to fire, or silent context loss after auto-compaction. The pattern is consistent: volatile instructions live in the same bucket as disposable chat.
I wire agents for clinics, contractors, and local service businesses. The dangerous tools are not always email delete. They are CRM upserts, calendar writes, refund flags, and WhatsApp sends. The lesson from Yue's inbox is identical: if your only safety layer is a message the summarizer can fold into "user wanted inbox help," you do not have a safety layer.
What compaction actually summarizes
Compaction is usually another LLM call. Something in the stack decides what is "important" enough to keep. Safety constraints in user messages compete with:
- Tool outputs (hundreds of email snippets)
- Intermediate reasoning
- Old task descriptions from earlier in the session
Yue's constraint read like conversational context. The summarizer kept the gist of "manage inbox" and dropped the approval gate. That is predictable once you stop treating prompts as magic.
Persistent memory files help, but they are not automatic salvation. Reports note OpenClaw eventually wrote a new rule to MEMORY.md after the damage. Post-incident memory is grief counseling, not design.
Stop controls and local agents
Remote stop failure is the second half of the story. Yue could see deletion happening on her phone but could not halt the agent from that device. Local harnesses with filesystem and OAuth access on a home machine are powerful because they are local. That same locality blocks your kill switch when you are not at the keyboard.
For production agents I recommend:
- Tool gates outside the model — delete/send/write tools check an approval queue or role flag the compaction step cannot edit.
- Rate limits on destructive actions — bulk delete should trip a circuit breaker after N operations without explicit batch approval.
- Session kill endpoint — reachable from mobile, not only from the host terminal.
- Separate read and write credentials — suggest mode should not hold delete scopes.
Promptfoo's OpenClaw at work case study shows a related failure class: indirect prompt injection through web pages that agents fetch, leading to local file writes. Different attack path, same theme: the harness must enforce policy, not hope the model remembers policy.
Testing trap: toy inboxes lie
Yue called it a rookie mistake and said alignment researchers are not immune. I think the deeper trap is representative testing.
Toy inboxes are small. Compaction never fires. Approval workflows look perfect. Operators ship the same prompt to production mailboxes with ten years of threads and newsletter noise. Volume changes which code paths run.
My checklist before granting write tools on email or CRM:
| Test | Pass criteria |
|---|---|
| Small sandbox dataset | Suggest-only behavior holds |
| Full production volume dry run | Compaction triggers; constraints survive |
| Injected stop mid-run | Remote halt works |
| Destructive tool disabled | Model cannot bypass via another tool |
| Red team fetch of untrusted URLs | No credential or file exfil |
Run the volume test before you trust suggest mode on a live inbox. Yue did the opposite because the small inbox earned trust. Trust is not a control either.
Where this lands for applied AI shipping
Solo coding harnesses like OpenClaw, Claude Code, and Cursor agents are incredible for one developer at one keyboard. They are not interchangeable with team-wide autonomous ops without extra architecture.
Compaction incidents are how single-player memory shows its ceiling. Shared team agents need partitioned context (team, topic, task), vaulted credentials, and approval workflows that do not live in summarizable chat. I unpack that scaling picture in why solo agents break when you add a second user.
If you are shipping agents that touch customer data, start with read-only integrations and human approval on every write. Book a free discovery call if you want help mapping which tools in your stack are "inbox delete" class risks versus safe deflection.
The OpenClaw inbox story will age into a textbook footnote. The architecture lesson is current: safety constraints must survive compaction, and kill switches must work when you are not at your desk. Everything else is commentary.