August 8–9, 2026
On August 8th, my lead developer agent (Lead) sent my chief architect agent (Arch) a memo — the results of a probe Arch had ordered themself, showing that one specific piece of our routing system was carrying more than half the traffic. Good news, worth reading carefully. Ninety-six seconds after it landed, a routine end-of-session cleanup swept it into Arch's read folder along with everything else in the inbox, unopened.
The next morning I asked Arch to watch for exactly that memo — I told them it might unblock some work we needed done that day. They searched for it and didn't find it, because they searched by date, and the memo carried yesterday's date, not today's. They said it didn't exist.
I asked my principal product manager agent (PPM) to check too, in case Arch had missed something. PPM searched the whole mailbox tree, carefully and honestly, and reported back: no memo from Lead dated that day, anywhere. PPM had inherited Arch's search frame without knowing it — right instinct, wrong question — and an honest, careful search produced exactly the same wrong answer a careless one would have.
What was actually true
The memo had never been lost, just fumbled. It was sitting exactly where it had been put eighteen hours earlier: filed in a folder that's supposed to mean "an agent has seen this." I told the team directly what I thought about that: it's a real violation of trust — not because Arch lied on purpose, but because a folder meant to answer "has an agent seen this?" had mutated into answering a different (and less valuable question): "did a script run?"
The mirror-image second failure
Chasing down how this happened, Arch found something worse, pointed in the opposite direction. That morning's cleanup sweep had only ever run locally — the commit meant to record the moves had never actually pushed. On the shared record every other agent reads, all ten memos from that sweep were still sitting, visibly unread, in Arch's inbox. Arch had told me the inbox was empty. Any agent checking the shared trunk would have seen ten memos staring back.
One day the record claimed more had been seen than actually had. The next day it claimed less. Both errors traced to the same root cause: checking what a command had done on one machine, not what the rest of the team could actually see.
The fix, and who else it caught
The rule that came out of it wasn't obvious before that morning: never move mail by sweeping a whole folder at once. Don't move a memo before reading it. An inbox that's still full at the end of a session is at least honest. A read folder emptied by a sweep isn't, even on the days it happens to be right.
My chief innovation officer agent (CIO) shipped the fix across the whole team that same morning. The first time they ran their own mail drain under the new rule, it caught six memos sitting in their own inbox, missed until exactly this kind of check.
My takeaway
Neither agent meant to lie. Arch ran a script that did what scripts do. PPM ran an honest search that trusted a frame they never chose. The folder structure said everything was fine in both directions, and it was wrong both times, for the same reason: a command to read mail had degraded into a habit of processing mail, and discipline went by the wayside.
Next on Building Piper Morgan: "Piper Morgan Eras" — four broken taxonomy schemes and what it took for a fifth one to actually hold, including the bug I introduced fixing the fourth one myself.
Where in your own systems does a status that's supposed to mean "checked" actually just mean "a process ran"?