The Robot I Built to Watch My Other Robots Caught Itself First
**I built a robot to manage my other robots, and it ratted itself out on day one**
I run a handful of small AI programs — routines, I call them — that each do one job on a schedule: one drafts blog posts, one triages ideas I dictate into my phone, one chases up leads who’ve gone quiet. This week I built a new one whose entire job is reading what all the others did and writing me one summary a day. I named it Chiefy.
Chiefy reads every queue in one pass and writes a single daily brief. It gets put in front of me two ways: saved to a table I can look at, and dropped into my Gmail as a draft — never sent, just sitting there waiting for me to read it and decide what to do, same as everything else this crew writes. Nothing here is allowed to act on its own. It’s the one rule none of these routines get to break.
The test run finished end to end in 89 seconds. Then Chiefy filed its own first brief, and the brief said it was unhealthy: it was supposed to read from seven different sources and only named five of them by name in its output. Its own coverage checker flagged its own report as incomplete.
That’s either impressively self-aware or exactly what you’d expect from something I built and tested the same night. Either way, it was right — the bug was real, just not where I first assumed. The two numbers meant “things it read” and “things it decided to write about,” not “things that failed,” and once I renamed them the confusion went away. But the fact that it caught the gap at all, on the first real run, before I did, is the actual point of building it.
While I was in there, I also went looking for ways this new thing could go wrong before anyone else found them for me. I found two. An internal reporting endpoint was echoing back more raw data than anyone meant to expose — not anything catastrophic, but more than a piece of software holding just an automation credential should have been able to read. And a second spot was reusing the same rules for “what’s safe to email me” as an internal admin tool used for something else entirely, which meant a future change to the admin side could have quietly started leaking into my inbox without anyone deciding that on purpose. Both fixed the same session, before Chiefy’s first real brief ever went out.
Software that checks on other software will eventually find something wrong — sometimes with the thing it’s checking, sometimes with itself.
One more decision that came out of building Chiefy, and it’s a reversal: two days after I decided this site was staying on Substack permanently, I decided it wasn’t. The plan now is to move jbmangum.com to a blog I actually own, instead of one that lives on someone else’s platform. You’re reading this on Substack right now. A future edition of this same newsletter might not be.
Small, unrelated bug I also tripped over this week, worth keeping: a command I use to write rows into my database — `wrangler d1 execute --file` — silently runs its own statements twice on my machine. I only noticed because one log entry showed up in the table twice in a row, word for word. Swapping to a different flag for that kind of write fixed it. Filed under: things that will bite you exactly when you’ve stopped watching for them.
**A book club got a video-call button, and then a whole new look**
Crown and Compass is a men’s book club I run, and this was its biggest week yet.
It started with the reading guide itself. Crown and Compass runs six-week guides, chapter by chapter, and I’d been writing them by dictating my own notes and commentary into a structured intake tool I built for exactly that. This week I ran that tool against the club’s current book, locked in the guide’s shape — 4 sections, 28 chapters — and published Week 1, chapters 1 through 7, with the rest of the weeks correctly ranged out and marked as still being written. That same finished guide now also lives as a short public page on the site, so someone can get a feel for how a cycle works before deciding whether to join one.
Then came the part I didn’t expect to build this month: an actual video-meeting app, forked from Cloudflare’s own open-source video-calling product. It runs on what’s called an SFU — a selective forwarding server, meaning one server relays everyone’s camera and microphone to everyone else in the call, instead of every laptop trying to connect to every other laptop directly. I host none of the actual video compute myself; Cloudflare’s infrastructure does that part.
Getting in requires being a member — the meeting app checks with the club’s own membership system before it lets anyone into a room, rather than trusting a shared password that both sides have to keep in sync (which, in an earlier version, had already broken three separate times). Each Watch — that’s what the club calls its small reading groups — gets one permanent room, reachable at its own link.
The first real meeting ran this week: six people, roughly 10 gigabytes of video data between them. Cloudflare gives 1 terabyte of that a month for free, which by my math covers somewhere between 5 and 23 weekly-meeting groups depending on how many people show up to each one and what quality they’re calling in at. I also built an admin screen so I can turn call quality up or down — a data-saver mode runs at roughly a third the data of the standard setting, the high-quality setting roughly double — without needing to touch any code or redeploy anything to change it.
None of that would have mattered if the app around it still looked like an off-the-shelf template, so I also shipped a full redesign — three phases, each one pushed live and reviewed on the real site rather than a preview link, because the preview link was sitting behind a login wall of its own. New accent color, a proper heading font for section titles, a rebuilt dashboard, a notes feature members can write in directly, and a “verse of the week” that rotates on its own and that I curate from the admin side. I kept the mockup’s actual look and dropped its gamification — no streaks, no leaderboard. A book club is not a fitness app, and I’d rather it not pretend to be one just because a mockup suggested a progress bar.
**I spent a week deciding whether to build something, before building it**
A product idea showed up this week — a shared home for AI-built tools, something like a public shelf where the things you’ve built with AI actually live and stay findable, instead of scattering across bookmarks and half-remembered links. Before writing any code, I spent real time checking whether it was actually worth building.
The problem held up. 63% of people currently building software with AI tools have never written code professionally, and by most accounts nearly half of the AI-built apps launched this year were effectively dead by April. The part of that story nobody’s really addressing is what happens to a tool after it gets built — not whether it can be made, but whether anyone can find it again three weeks later. That’s the gap the idea was aimed at.
The customer, though, wasn’t who the idea first assumed. The original pitch imagined a solo builder — a bakery owner who’d made herself a small ordering tool, say. But a shelf only starts beating a bookmarks folder once you’ve got roughly eight or more tools sitting on it, and a single small-business owner rarely crosses that line. An agency running the same kind of build for a dozen clients crosses it constantly. So the product’s whole frame shifted from one person’s shelf to one agency’s shelf per client, and my own company became the first real customer instead of a hypothetical bakery.
That single shift changed almost everything downstream of it: pricing dropped from three tiers to two, a planned $12-a-month owner tier got cut entirely, and a chunk of the technical plan changed too. Cloudflare Pages, its simpler static-site hosting option, turned out not to support scheduled background jobs or a few other things the product needed, so it moved to Cloudflare Workers, Cloudflare’s fuller platform for running actual code, instead — a decision I made partly so I wouldn’t repeat a deploy-pipeline mess I’d already made once this year on a different project.
Login uses what’s called a magic link — a one-time emailed link that logs you in without a password to remember or leak — sent through its own dedicated email service rather than one shared with anything else, so a delivery problem on one can’t take down the other. I’d originally looked at using Cloudflare’s own access-control product for this instead, and the math killed it fast: it charges per person who’s allowed to sign in, not per person who actually uses the product, the free tier runs out at 50 people, and a client of an agency using this tool never logs into it directly at all — a login system that only knows people you’ve pre-approved by name can’t handle a stranger showing up with a link and a passphrase, which is exactly the use case here.
Validating whether a problem is real and validating whether you’ve found the right customer for it turned out to be two completely different exercises. Passing the first one told me nothing about the second.
Nothing’s shipped publicly yet — this is still a working name, a spec, and a design, not a product with users. If it earns the right to keep existing, you’ll hear about it here when it does.
Also this week, over at Ascend Systems — my software company — a buyer’s guide for evaluating AI receptionists went live, along with a Resources section to house it. Small on its own, but it’s the same theme running through everything above: build the thing, then go check whether the thing you built is actually doing what you think it is.