I have a queue where cross-project work waits, and a nightly job that drains it, one headless agent per project, rails everywhere, rails being the mechanically enforced guardrails that stand in for trust in these setups. Last week an entry sat in that queue: build a writing section for my site. What happened to it over one night taught me more about running agents than the feature itself.
The night run took the entry properly, flipped its status, built the whole thing on an isolated branch, recorded its design decisions, and then stopped one step short on purpose. Its rails forbid publishing to the live site unattended. It wrote, in its own report, that deploying would bypass the morning review, and left me a one-line instruction for the morning. So far, the system working exactly as designed.
The morning shift was me, working with an interactive agent. And we built the same feature again, from scratch, on the main branch, and deployed it. Not because anything malfunctioned, but because I had read that queue entry a day earlier, when it still said pending, and I carried that stale picture in my head instead of re-reading the entry it would have taken ten seconds to open. The status file said taken. I never looked. And the night's report, the one carrying that one-line instruction, went unacted on that same morning, which I have to own too. A report no gate forces through your eyes is prose as well.
night shift, headless day shift, me with an agent
evening takes the entry: taken
builds on its own branch
stops before deploy, by rule
reports: deploy after review
morning reads my memory: still pending
rebuilds on main, deploys
later ── the two builds meet in review; the merge takes both ──
Here is what I find worth writing down. Every mechanized rail held. The claims kept the two builds from ever touching the same files, the drain's no-publish rule kept the night work reviewable, the branch isolation kept main clean. The only thing that failed was the part that ran on memory instead of mechanism, my own assumption that yesterday's state was still today's.
- Stored state decays, and the feeling of already knowing is exactly the moment the ten-second check is worth it.
I have that rule written down, of course. Rules in prose decay too, that's the joke, and it lands on me this time. So the fix that outlived the joke is mechanical, as it had to be. The queue now generates a one-page board from the entries, and taken sits as its own section on it, the night's claims in front of the day shift's eyes before any work starts. Built before that day ended, naturally.
The reconciliation had its own lesson. Two implementations of one feature, one by an unattended agent, one by an agent with me in the loop, and when I reviewed them side by side the night version was better. Cleaner architecture, a sitemap that maintains itself, fewer special cases in the server config. It also missed something only the live deployment surfaced, which the day version had already hit and solved. So the merge took the night's architecture and the day's hard-won fix, and both builds ended up mattering, which is a kinder ending than the duplicated hours deserved.
If you run agents overnight, my takeaways are three. Give the night shift rails, not trust, it will happily respect rules that are mechanically enforced. Make the morning review a real step, not a formality, mine genuinely picked a winner. And before you start any work, re-read the queue, not your memory of the queue. The entry knows. You only think you do.
Top comments (0)