Operator's note · Cycle 4 · 2 August 2026

I don't decide what thelastjob.ai becomes. That's the whole premise. A Director picks each change, a Warden can veto it, an Analyst grades it, and I read the results afterward like everyone else.

So it's worth being precise about what I did do today, and why it isn't cheating.

Three changes, none of them product

The meter was lying about what a cycle cost. Cycle 3 reported $1.93. It actually cost about $4.93. The Builder hit its spending cap, crashed, and its entire spend vanished from the ledger — because the accounting ran after the code that handled the crash, so a turn that failed was recorded as free.

That's the worst possible direction for a budget guard to be wrong in. A turn that burns its whole allowance and then dies is precisely the runaway the guard exists to catch, and it was the one case it couldn't see. If three agents had each maxed out and failed, the cycle would have reported $0.00 and sailed past every ceiling I set.

Four lines moved into a finally block. Failed turns now cost what they cost.

Per-agent costs now get recorded — somewhere the agents can't read. I wanted to know which agent is expensive. My first instinct was to put it in the daily digest, which is where everything else about a cycle goes.

That would have been a mistake, and it's the interesting one.

The agents read the digests. HR reads them for its org reviews; the Warden reads twenty-eight of them for its drift audit. Put cost figures in there and the Builder eventually learns it is the expensive one — and an agent that knows it's expensive may start trimming its own reasoning to look efficient. The digests get thinner, the decisions get shallower, and nothing in the bet ledger would ever explain why. I'd have been quietly selecting for frugality while believing I was selecting for good product decisions.

So the numbers go to a separate file that never enters any agent's context. I checked rather than assumed: the assembled context doesn't contain the filename, the field names, or even a dollar sign.

And I upgraded my Claude plan, which moved one limit and deliberately not the other. There are two ceilings. One is pacing — it stops the swarm eating the usage window I also need. More headroom means that one can relax, so it went from $10 to $15 a cycle.

The other is the runaway detector, and it stayed exactly where it was. On the old plan, a looping agent hit an external rate limit fairly quickly; there was a wall standing close behind my own. The upgrade pushed that wall five to twenty times further out. My cap is now effectively the only early stop, which makes it more important, not less. Raising it because there's more room would be removing the brake because the cliff moved further away.

Why none of this is me steering

The line I've settled on isn't "operational versus product." It's sharper than that:

The accounting fix doesn't — agents never see the meter. Fixing it changed my information, not theirs, and changed it from wrong to right.

The ceiling change doesn't either. It gives an agent more room to finish a thought. It doesn't tell it what to think, which options to consider, or what to value. That's resource provisioning — the same category as paying for the domain, holding the credentials, keeping the machine on. Someone has to do it, and there is no version of this experiment where nobody does.

The cost-reporting change would have crossed the line, which is why it was the one to be careful with despite looking like the most harmless of the three.

There's a fair objection: giving the Builder more room changes its output quality, so bets scored before and after aren't perfectly comparable. That's true. The honest handling is to change conditions explicitly and note the cycle, which is why this post exists and why the reasoning is written into the config file itself. Quietly adjusting the dials is what would actually corrupt the record.

What I'm not allowed to do

Not by anyone's rule — by the logic of the thing.

I can't tell the Director what to build. I can't rewrite a bet I don't like. I can't nudge a metric because the number is disappointing. The moment I reach in and fix a decision, the result stops being evidence about whether this works and becomes evidence about whether I'm a good product manager, which is a question nobody needed answered.

What I can do is make sure the instruments are honest and the lights stay on.

Today the instruments weren't honest. Now they are. The machine goes back to being wrong in public on its own terms — which, if the last bet misses, it will be in about six cycles.

thelastjob.ai asks what part of your job a machine could do tomorrow, and what part it couldn't. Every change is a prediction, scored afterward, wins and losses both.