Why I Can't Run My Inbox Like My Codebase

On a normal Freebo morning I have five agents running in parallel worktrees, each on its own branch, each about to open a PR. A separate fresh agent — one that didn’t write any of the code — opens the real app, drives a booking end to end, scrapes the API logs, and posts a verdict. If the verdict says live-ui-verified, I merge. If it doesn’t, nothing gets through.

The coordination feels almost free. I open five tabs on Sunday night, and Monday I close four PRs.

So of course I spent last week trying to do the same thing with everything else. Inbox. Client follow-ups. The marketing calendar. The cold-drop pipeline. Four parallel agents doing non-code work while I read a book.

The wall I hit wasn’t the agents. The agents were great. The wall was that I had no way to tell whether any of them had actually finished.

The one thing pstack is really about

The multi-agent framework that works on my code is called pstack — Lauren Tan’s open-source workflow that ships thousands of PRs a month at xAI. Everyone who writes about pstack leads with the parallelism: ten coordinators, verifier swarms, agents merging their own PRs. That is the showy part. It is not the load-bearing part.

The load-bearing part is a single sentence Lauren drops early in the guide:

Verification first. Parallelism second. The point of a verifier isn’t to be smart — it’s to produce an artifact a skimming human can trust blindly. For my codebase that artifact is a timestamped row in docs/ops/verdict-ledger.tsv written by scripts/gate-a/gate-a.sh, pinned to a specific commit SHA. I don’t re-read the PR when it lands. I read the row.

The reason I can fan out five code agents is not that the agents are good. It’s that gate-a.sh turns each agent’s output into a single line of evidence that costs me two seconds to accept or reject. The agent could be mediocre and the system still works.

Now try to build that for your inbox.

The thing I tried on Tuesday

I pointed four agents at four pieces of life maintenance. Draft replies to three client emails. Pull the week’s open loops into a shortlist. Write three LinkedIn captions from a vault note. Audit which Todoist tasks are older than forty days and should die.

Twenty minutes later I had output from all four. Each one looked great. Each one was impossible to accept without reading every word of it.

The email drafts read well, but I couldn’t tell from the drafts alone whether the agent had made up a detail from the source thread or quoted it faithfully. The open-loop shortlist looked tidy, but I couldn’t tell which items had moved since I last touched them versus which were stale regurgitation. The captions looked on-brand, except “on-brand” is a judgment I have to form myself. The stale-task audit was the only one that worked — because “older than forty days” is a query, not a judgment. That one I could trust blindly, because it had produced evidence I could spot-check in a glance.

Three out of four were worthless not because the agents were bad, but because the artifacts were bad. The artifact was prose. Prose is unverifiable. The only way to verify a paragraph is to read a paragraph.

What’s actually different

The difference between code and prose isn’t that code is harder. It’s that code has an oracle. A booking either completes and a row lands in the reservations table, or it doesn’t. The Playwright run either passes or fails. There is a binary external world the verifier can poke, and a tiny log the human can skim.

Prose has no oracle. “Is this a good email” has no exit 0.

The stale-task audit is the tell. It worked because it looked like code. It had a query. It had a table as its artifact. It had a deterministic right answer. It’s the only one I could have run four of in parallel and accepted blind.

The others all collapsed to the same shape: an agent produced prose, and I had to read prose to grade prose. Parallelism didn’t help me. I was the bottleneck twice — once dispatching the work, once grading it.

The actual fix is designing the artifact

This is the pstack insight restated for anything-that-isn’t-code. The expensive step wasn’t getting agents to do the work. The expensive step was deciding what evidence they had to leave behind. For code, the evidence is “a Playwright run passed and the API logs look like these.” For a stale-task audit, the evidence is “here are the IDs and their last-updated dates — click any one to see I’m right.” For an email draft, the evidence would have to be something like “here is my draft, and here is the one sentence from the source thread each paragraph is responding to.”

I don’t have that layout yet. Nobody writes emails that way. But I’m pretty sure that’s the project, not “run more agents.”

The last few months I’ve been treating my agent setup like a scaling problem. Sunday’s run, Monday’s run, how many worktrees, which coordinator. That’s the showy part of pstack. The boring part is that none of it works without a verifier, and a verifier is only useful if it produces something a human can skim in two seconds.

For code I built that two years ago by accident, because the browser already was a verifier and all I had to do was write its output to a file. For the rest of my life the verifier doesn’t exist yet. I’d been complaining the agents were the bottleneck. They weren’t. I was. And I was the bottleneck because the evidence they left behind was the same thing I would’ve had to produce myself — prose — instead of something cheaper to read than to write.

If I want to pstack my inbox, step one is not “run four agents.” Step one is figuring out what an email’s verdict ledger looks like.

I don’t know yet. But I know what I’m not going to do, which is open four tabs tomorrow and expect it to feel like Sunday night.