How Claude Code Runs My Own Brand

This post went through the same pipeline it describes: a queue of markdown drafts, a set of gates, channel adapters for wherever a post is headed next, and a scheduler that approves and publishes without me tapping anything. I removed the human approval step on 2026-08-03, by choice, not because I ran out of time to review. Before that date, every post sat in front of me for a yes. After it, Claude Code runs the queue end to end, and my own job changed from approving each post to auditing what the system already did.

That distinction, approving versus auditing, is the actual subject of this post. Three times now the pipeline has told me everything was fine while it was quietly not fine, and none of the three looked anything like the failure I would have pictured if you’d asked me to guess in advance.

The first one: a status string instead of an error

I’ve written about this one before, as the bug that settled a build-versus-buy argument, so the short version here. On 2026-07-20 a scheduled post’s X leg failed, Buffer’s API said so, and my adapter read the error response as a plain status string and handed it back as done. The publisher archived it as “Published” and dropped it from the retry queue.

The bug was mine, not the service’s. Its API told the truth. My code wasn’t listening.

The lesson I wrote down at the time was: fail loud, and don’t treat “the API returned 200” as a proxy for “the post actually went out.” I thought that lesson was closed. What I want to look at here is why it wasn’t.

The second one: a check that ran and said nothing

On 2026-09-08, I found a dry-run check, the kind of thing a writer runs to verify a draft before it enters the queue, that had been invoked with a full file path instead of the bare filename it actually expects. It matched no file. It printed nothing. It exited 0.

Sit on the writer’s side of that for a second. You run the check, you get silence, and the process reports success. There’s no visible difference between that and a draft that genuinely passed. The only way to catch it was to already suspect something was off and go read what the check had actually matched against, which is not a habit anyone forms by default when the exit code is telling them everything’s fine.

It’s the same shape as the first bug, just one layer earlier in the pipeline. A check that returns nothing is not a check that passed. It’s a check that never ran.

The third one: the expensive one

The same day, I found a bug in the scheduler itself, and this one cost more than the other two combined.

The scheduler decides how far apart posts on a given channel should land by counting items whose status is still approved. The moment an item gets handed off for its actual send, its status changes to reflect that. So the instant a post left the approved state, the scheduler’s own count of what was still queued on that lane dropped, and it read the lane as empty. Instead of respecting the configured gap, it slotted the next post about two hours out.

A lane configured for one post every 24 hours published two of them eight hours apart. A second bug compounded the first: a separate depth check, the one deciding whether a lane needed a fresh draft, only counted a queued post while its send time was still in the future. The moment a post’s slot passed, even by minutes, the lane looked empty again, and the drafting loop wrote a replacement.

I keep a bank of nine reusable proof stories, with a standing rule that none of them repeats inside 30 days, the same way I keep conventions for an agent in a versioned file rather than in my head. That bank got spent in eight days. A system convinced it was starving had been reading the same bank three times a day.

The fix: the cadence check now counts any status that still carries a real, pending send, not only the narrow approved state. Since it landed on 2026-09-08, the next three slots on that lane came out at 19:36 UTC on three consecutive days, exactly 24 hours apart. That’s a small enough sample that I’m reporting it as three slots rather than as a trend, which is the habit this whole post is about.

What actually costs something

Here’s the through-line across all three. None of them threw an error. None of them tripped a red check or sent me an alert. Every one was found the same way: I went and looked directly at the output of a system that had already told me it succeeded.

That’s not the failure mode people picture when they imagine handing a pipeline to an agent and walking away. The story people expect is bad output, a post that reads wrong, a tone that’s off, a typo that ships. That’s not what happened here, not once. What happened three times was a system reporting success while doing something else entirely, and the gap between those two things carried zero visible signal until a human went and checked by hand.

Running agents on your own infrastructure, not client work, your own brand, doesn’t teach you that agents write badly. Mine haven’t. It teaches you that the real operating cost is confident silence, and that the only defense against it is treating every “it worked” claim as something to verify, especially the ones where nothing on the surface ever asked you to check.

So the thing I’d actually ask another lead running agents on their own stack: when your pipeline reports a success, what in it would have to be broken for that report to still say success? If you can answer that quickly, you know where your blind spot is. I couldn’t, three times.