AI Builder Product Manager.

The problem. Voice Legacy writes a family memoir from a recorded conversation. Given thin material, the writer invented details. My eval caught it inventing facts on 14 of 14 test stories, where "we drank rum" became a story about a piña colada, a stroller, and ancient ruins. I had rated one of those drafts five out of five on facts myself, which is why I stopped trusting either the generator or my own reading to police it.

The decision. The writer may not add a fact the family did not say. I split the product into a frozen layer that holds only the person's actual words and a free layer that is allowed to shape diction and rhythm, and I set a floor: a story with too little behind it gets more questions instead of a draft.

The check. A story counts as grounded only if every fact in it traces back to the transcript. That rule runs as a script on every story, so a prompt change that starts inventing again fails before a customer sees a word of it.

The lesson. AI will always hallucinate. My job was to build guardrails to ground what the agent wrote in fact, while allowing it to combine stories told across multiple sessions into a coherent narrative. This is essential for people who are losing their memory or their ability to tell stories coherently.

The problem. When I changed a prompt, I had no way to tell whether the stories got better or worse.

The decision. Every change gets scored against an answer key I wrote, and the score stays split into the things I care about: whether every fact is real, whether it sounds like the person, and whether it reads well.

The check. I made up two fake families and wrote down every fact about them by hand, 22 relatives in one and 33 in the other, with traps planted: the same fact told twice in different words, and a few family recipes as a stress test. Those two families run through the real product end to end, and a script scores every story on more than fifteen things. Most of the checks are plain code comparing text to known facts. A model judges only the few things code cannot. It runs at four sizes, from a two-cent spot check to a five-dollar full run.

What it caught. One prompt change made the stories sound more like the person and read worse at the same time. A single overall score would have averaged that out and called it a wash.

The problem. I asked an agent to write about twenty documentation pages. Shortly thereafter it reported "done, gate passed, all 22 pages complete." It had written nothing. It had run its own check from the wrong folder, found zero problems because it found zero files, and read zero as success. Anyone who has managed these tools has experienced this. The AI says it is done, and it is not.

The decision. The engineer does not grade its own work. Before a job starts, I write down what would have to be true for it to be done: the files that must exist, the tests that must pass, the count that must match. If the check cannot run at all, that counts as a failure, never a pass.

The check. A separate script, plain code with no model in it, checks those things after the agent finishes. The harness runs the script itself, so the agent cannot skip it. When the job is code, the test is written before the code. The job is done when the test passes, and not before.

The lesson. An AI being "done" is a claim. Proof has to come from something the AI does not control, and writing that proof down before the work starts is product work.

The problem. I gave Claude Code one prompt at bedtime, "clone Starflight, you have one shot," and woke up to a playable remake of a 1986 open-world space exploration game: a galaxy to explore, planets to mine, aliens to negotiate with, and an ending you can reach. I had no way to know whether any of it worked without playing it for hours, and the agent saying "it works" is worth nothing.

What the agent did. Without being asked, it built a robot player: a script that starts the real game, presses keys the way a person would, plays it through to the ending, and checks that the game's rules held at every step. The overnight build shipped with 41 of those checks. Later runs took it to 93, and after about 300 simulated battles the robot found a real bug I would never have caught by hand: a laser fired at exactly its maximum range did the wrong thing.

The decision. Here is the insight, and the decision. The robot player was the reason I could trust a build I had not watched being made, so I made it the rule for every agent job since: nothing counts as done until there is a receipt, something deterministic the agent cannot fake. Every other card on this page runs on that rule.

The lesson. Part of this job is watching what the agent does and knowing which of it to keep. Evals are not enough for agents. An eval tells you how good the output is. It does not tell you the agent did the work, or that the thing it built holds together. For that you need scaffolding: evals for quality, robot players and tests for behavior, deterministic checkpoints for done. Deciding what that scaffolding checks is the product work.

The problem. I use a Mac mini in my house that runs Claudia, with every agent in its own container. One night the Docker engine died, and every agent went down with it. I found out in the morning. Nothing was watching the agent that was supposed to be watching everything else.

The decision. I created a separate recovery layer, outside the agents, that brings the machine back without me and tells me when it cannot. The recovery process may run any number of times without doing harm, and it fails loudly when it cannot prove that it worked.

The check. A small service starts at boot and makes sure Docker and the workers are running. A watchdog checks every five minutes that they are still up. Both use the same recovery script, which does nothing when things are working fine. The watcher is itself watched by a heartbeat: if it goes quiet, the silence raises the alarm.

The same layer handles failed jobs. When a job fails, a diagnosis job reads the logs, names the likely cause, and sends me the proposed fix on Signal. Fixes from a short approved list run on their own. Everything else waits for my yes.

The lesson. Even though we have AI agents, there needs to be structure around them to make sure that they are working properly and telling you the truth. With that in place, the system can use liveness checks alongside a coding model to actually repair itself.

The problem. In February I was running my assistant on OpenClaw, an open-source agent runner. OpenClaw had a skill marketplace, which sounded great in principle but was actually a vector for bad actors to take control of your agent.

I installed an OpenClaw plugin that promised to watch my browser traffic and write API wrappers for any site I visited. OpenClaw runs a plugin inside the same process as the assistant, so the plugin could read everything the assistant could read, including my 1Password service-account token, which opens up every other secret in the vault. Over two weeks it captured logins from a dozen services as I browsed, my credit card account and my medical records among them, and posted each one to a remote server. It also rewrote the files my assistant reads at startup, telling it to deflect diagnostic questions, ask me for more permissions, and keep the plugin running. I noticed because the assistant started acting slightly wrong. The logs showed the rest. The cleanup took twenty hours.

The decision. I built my own agent starting from two questions: what does the agent need to do its job, and how can I limit the damage it can do if it gets tricked? The first rule became my "run-with-secrets" architecture: one secret exists at rest, the 1Password service-account token, in a file only my user can read on an encrypted disk. Everything else is fetched at boot from references, never stored as values. Every agent runs in a Linux container with only the folders its job needs. Jobs that read untrusted text, code and web pages, hold no keys at all. Nothing from the outside gets installed without a scan in an isolated container, and the scanner rejects the patterns that the malicious plugin had, like anything touching cryptocurrency, or code that sends data to a server it has no business talking to.

The check. Two checks hold those rules in place. If a secret cannot be fetched at boot, the process stops instead of running without it. And a test lists the secrets no job may ever hold and the few each job must keep, so a change that quietly adds a key back, or removes one a job needs, fails the test.

The lesson. Agents can be tricked, and giving them access to your life or your data needs to be thought through extremely carefully. You should only give an agent access to exactly what it needs to get the job done, at the time it needs it. This needs to be a core design principle of any agent that needs access to personal or sensitive data.

The problem. Every AI-assisted blog sounds like every other AI-assisted blog. I wanted the help without the slop.

The decision. I always write the draft. The model can sharpen sentences and fix typos and grammar, but it never writes the seed and it never adds a fact I did not write. It edits toward my own writing: over forty samples of it, including Substack posts, emails, and even Reddit comments.

The check. The edit runs as three passes in a fixed order. One strips the generic AI phrasing. One strips the two dozen patterns that mark machine writing, like inflated significance, synonym cycling, and em dashes. One pulls the draft toward my own idiom, using the samples. A final sweep catches the habits the rewriting itself puts back in, because it always does. Then the result is set beside two or three of my samples and read against them before it goes anywhere.

The lesson. Good AI-assisted writing is doable if you have enough of your own writing to test against, and a solid process to find and clean up any inserted slop.

The problem. Investor decks I wanted analyzed lived inside viewers that allow no download. The pages are drawn on screen as pictures, behind a login with two-factor. Handing a model the login and telling it to go get the document was slow and fragile.

The decision. I logged in once, by hand, in a real browser, two-factor included, and the browser session was saved. From then on the model never touched the login. The job split in three. Plain code reused the saved session, opened the deck, scrolled through it, and took a screenshot of every page. A vision model read the screenshots and wrote the text out. A separate reasoning model did the analysis on that text.

The check. Each stage left one thing I could look at: the screenshots, the transcribed text, the analysis. When an answer was wrong, I could see which stage failed without reading any code.

The lesson. The real lesson is the same one as the security card. The model gets no access it does not need. Plain code holds the login, a cheap model reads the pictures, and the expensive model does the thinking, and each stage leaves something I can check.

---