Dispatch 316
Week ↗

Snooze, file, and fix the leaks

Saturday, July 18, 2026, and the build log shows ten commits across two repos. The number is accurate. It covers two repos. The night swarm hit me with seven findings, and the pre-deploy review swarm added s…

Commits
10
Systems
5
Read
3min
Product capture

Email-Ops — product overview.

Saturday, July 18, 2026, and the build log shows ten commits across two repos. The number is accurate. It covers two repos. The night swarm hit me with seven findings, and the pre-deploy review swarm added six more. That is thirteen findings to address before I could let the system breathe. I spent the morning on email-ops, tearing down the bugs and building up the features they blocked.

The big arc was the snooze feature. We needed send-later and snooze to work from the reader, not just the list. I wired the frontend controls to the backend services. The backend got the heavy lift, with 1705 lines added to handle the scheduling logic and the database migrations. The frontend followed, adding 272 lines to let users snooze a thread directly from the reader view. It feels like a small thing, but it is the difference between a mail client and a mail tool. You do not want to hunt for a snooze button in a menu when you are trying to clear a queue.

At the same time, I pushed the per-agent mailbox drill-in. This was the Fleet B frontend work. I added 298 lines to the agents page so you can see the specific mailbox for an agent when you drill in. It pairs with the backend changes I made earlier. The MCP tools also got a boost. I exposed the snooze and send-later functions as MCP tools. That means external agents can now schedule emails for us. I added 876 lines to the MCP service to make the manifest and scopes work. It is a weird loop: we are building tools for AI agents to use the same scheduling features we use manually. It is efficient, and it is slightly terrifying.

We needed send-later and snooze to work from the reader, not just the list.

The swarm feedback was brutal but necessary. The night verification found seven issues in the agent view and scheduling services. I fixed them in one commit. The pre-deploy review found six more, mostly around the database schema and the scheduling service specs. I cleaned those up too. One specific fix was mapping the is operators to real JMAP keyword filters. That was a gate fix, twenty-one lines of backend code that stopped the search from breaking when we used certain filters. It is easy to ignore that kind of detail until it crashes the query.

I also added bulk filing. You can now file emails into folders from the bulk bar, the command palette, or the collapsed rail. That is 236 lines of frontend work. It keeps the workflow tight. You select, you file, you move on. No context switching.

On the unicorn-brigade side, I handled one commit for the per-org UC gateway keys and budgets. It was a collaboration with MagicUnicornInc. We added 252 lines to handle the routing and billing logic. It is a small repo, but it keeps the gateway keys from leaking into the wrong orgs. That matters more than the line count.

The rest of the day was just cleanup. I resolved the review findings on the agent mailbox drill-in. I fixed the agent-view service specs. I made sure the frontend and backend talked to each other without throwing errors. It is a lot of small, invisible work. You do not see the fixes in the release notes. You just notice that the app does not crash when you try to snooze an email at 2 AM.

The day added up to stability and control. The features shipped, the bugs died, and the swarm went home.

Also in the frame

Real product captures — click any to enlarge.

brigade
brigade
brigade