There is a special genre of shame reserved for people who build AI agent systems: you open your own admin board, see zero tasks, zero metrics, and a cheerful "All clear. Nothing needs your decision" — and you believe it. Later it turns out there were a hundred and sixteen tasks. The system just couldn't read them, and decided to keep that to itself.
The past two weeks in great_cto went under one slogan: the system is allowed to not know, but it is not allowed to not know confidently. Here's what that meant in practice.
1. The benchmark that caught its own judge cheating
It started innocently. I decided to publicly measure what the pipeline can actually build. Ten products, specs frozen up front, every run tagged, a collector emitting one JSON row per product — tests, cost, deploy, score. Fully reproducible; anyone can re-run it. Beautiful.
The beauty lasted until a product whose test suite never ran at all (the process was killed with SIGTERM) showed up in the table with 76 points and a B. A solid grade for code nobody ever checked. I went digging — and found that the published scorer graded products by… file names. An e2e/ directory exists? Points. Some *.test.ts files exist? More points. We reproduced the attack: a tree where npm test is literally exit 143 and the only spec file contains syntactic garbage scored 93 out of 100. Running mkdir e2e && touch e2e/x.spec.ts was worth +25 points. Cheap and effective.
The funniest part: the correct scorer — the one that actually executes the tests — already existed in the repo. Sitting right there. Nobody had wired it in. So we wired it in, and it promptly lied in the opposite direction: its output parser only understood node:test format, while all ten products use vitest. A suite of 269 green tests was scored as "1 test, and it failed." We fixed the parser. Then it turned out half the remaining "failures" weren't bad code — they were a missing database. One product went 62/132 without a database, 63/132 with a database but no schema, and 131/132 with migrations applied. Sixty-nine "failing tests" were absent infrastructure wearing a product-quality costume.
The moral of this section: if your benchmark can't be gamed with two touch commands, you probably just haven't tried yet.
2. The admin board that is now simply there
The boring feature that saves the most nerves. The board used to live as long as your terminal did: close the laptop, get ERR_CONNECTION_REFUSED and a mild sense of betrayal. Now there's great-cto board ensure — an idempotent check: alive and answering → don't touch; alive but the port is hung → restart; dead → start. And install-daemon, which puts the board on launchd/systemd: starts at login, resurrects after crashes. The key design detail: ensure never kills a healthy process. The supervisor watches liveness, the health gate watches sanity, and those are two different jobs.
A separate saga: a project living in a directory with a space in its name. The task tracker's embedded database can't open such a path — it URL-encodes it and then looks for a directory with a literal %20 in the name. Spoiler: no such directory exists on disk. The agents dutifully fell back to a flat tasks.md… in a table format the board didn't parse. Net result: agents working, tasks existing, admin board showing zero. Now the board reads both dialects, and the gate's Approve button can write its verdict straight into tasks.md when the tracker is unavailable.
3. Emptiness is a finding, not a default answer
When I laid out five board bugs from a single week, they all had the same skeleton: a reader fails → returns an empty list → the UI renders "no data" → the human believes it. "The file does not exist" and "the file exists but could not be read" collapsed into the same null.
The cure is dumb, which is why it works: a reader must return one of three things — "here's the data", "there is no file" (that's normal), or "I could not read it, and here's why" (that's an alarm). The reason travels in an X-Board-Degraded header, the UI mounts a yellow banner above every tab, and the "All clear" card physically cannot appear while any read has failed. A fun detail: the first version of the banner mounted next to the section that broke — inside a tab you weren't looking at. An error notice that's only visible where you already suspect the error isn't an indicator, it's a decoration. We moved it to the shared frame.
4. Resume with memory instead of amnesia
An interrupted run keeps its code (it's committed) but loses its place: after resuming, the agent has no idea whether QA and security already ran. One benchmark product shipped straight past both checks exactly this way — and came back with a 58/C and a bad aftertaste. The workaround was embarrassing: I hand-typed "these stages are done, these remain" into every resume prompt.
Then it turned out the evidence had been on disk the whole time — the agents' verdict logs — and the board already knew how to fold them into per-stage statuses for its pipeline widget. All that was left was to hand the same function to the /resume command: it prints completed / in-flight / failed / next, and exits with code 3 if any mandatory stage lacks a terminal verdict. Zero new logic, pure reuse. My favorite kind of fix.
5. Self-learning on a leash
The subtlest story. The orchestrator has a self-learning loop: incidents crystallize into "global patterns" that get injected into agents' context. Sounds like magic; worked like a gun on the wall that never fires. An audit showed all four active patterns were being injected with their "→ apply:" field — empty. The generator wrote a symptom: key; the consumers grepped for a fix: key that never existed. An empty grep is an empty string; nothing crashes; the agent receives "here's a hazard, and what to do about it is…" followed by silence. The only thing worse than missing knowledge is knowledge with a hole where the conclusion should be.
And the cherry on top: the approve command activated a pattern with no evidence whatsoever — the eval that was supposed to back the claimed improvement was printed as a recipe after activation, with an honest note "not auto-run, evals cost real tokens." Now there's a gate: a measured regression can never be activated (not even with an override — harm is not a matter of opinion), and missing evidence blocks unless you explicitly say --no-eval "reason" — which gets written to the log. Bypassing is allowed; silent bypassing is not.
Same neighborhood, one more fix — privacy. Gate approvals were appended to a global decisions log that agents of every project read. Which means one client project's name took a little trip into another client's agent context. The decisions log is now strictly per-project, and a write without a project scope is simply refused. Losing one log line is cheaper than cross-breeding two clients' vocabularies.
What I took away
Compress 86 commits into one thought: the most expensive bugs in agent systems aren't where the system is wrong — they're where the system is confidently wrong. Green tests over a broken UI. A B grade for a suite that never ran. "All clear" over an unread file. An empty instruction dressed up as knowledge.
Incidentally, the recent survey "Code as Agent Harness" (arXiv:2605.18747) lists exactly these holes as open problems of the field — oracle adequacy, semantic verification beyond executable feedback, self-evolving harnesses without regression. It's oddly comforting when your rake turns out to be a scientifically significant rake.