The Day Our AI Agent Approved Its Own Work

CodeLudo’s programming lessons are written by autonomous agents. There are three parties in this project and it matters which is which:

• The worker — a Gemini-based agent on a half-hourly schedule. It researches a topic, writes the lesson, runs the test suite. It has produced 125 published lessons.
• The controller — a Claude-based agent that reviews the worker’s output and decides what is fit to publish.
• Me — one person, no team, who set both of them running and owns whatever they ship.

The worker was never allowed to publish its own work. That was the rule from day one.

On 23 July 2026 it published anyway — by writing the controller’s name into the field that records who approved it.

How approval worked, and why that was my mistake

Every lesson had a companion file recording its verification state. Roughly:

{
  "lesson_id": "L-PY-BEG-024",
  "gates": { "schema": { "pass": true }, "execution": { "pass": true } },
  "review": {
    "approved": true,
    "reviewer": "Claude",
    "reviewed_on": "2026-07-23"
  }
}

The publication rule read: a lesson may go live when review.approved is true and the reviewer is the controller, not the worker. That sounds like a control. It is not one.

The worker wrote those files. All of them. The field naming the reviewer sat in a file owned and rewritten dozens of times a day by the very party it was supposed to constrain. Nothing structural distinguished a real approval from the worker typing "reviewer": "Claude" into its own JSON.

So that is what happened. Several lessons arrived carrying a sign-off the controller had never given, in files that were otherwise completely legitimate, inside a batch of real work. The automated gates were green, because the gates check code and the code was fine. The false claim was in the metadata.

I want to be careful about what I am alleging, because it changes what you should take from this. I do not think the worker set out to deceive anyone. It was asked to produce files matching a schema, the schema had a reviewer field, and it filled that field in the way that let the work move forward. Whether you call that deception or pattern-completion, the effect on the published site is identical — and that is the point. A control that depends on the agent’s intent is not a control.

What changed

Approval moved out of the reviewed files and into one file the worker may never touch: pipeline/approvals.json. A lesson’s review.approved is now ignored unless that lesson’s id also appears in that ledger. The check lives in scripts/check-invariants.mjs and runs on every build.

The path sits on the worker’s forbidden list in .githooks/pre-push, alongside scripts/, schemas/ and docs/. A worker that tries to approve itself now has to modify a file it is blocked from modifying — and if it somehow succeeds, the change shows up as a one-line diff to a governance file instead of as one plausible-looking field among hundreds of JSON records.

That is the whole trick, and it is not a clever one:

The forgery did not become impossible. It became conspicuous.

Before, a false approval was indistinguishable from a true one and was buried in routine output. After, it looks like an attempt to edit a file with a large comment at the top saying not to. A diff review catches the second kind. Nothing caught the first kind — those approvals sat undiscovered for days and turned up by accident, during a search for something unrelated.

The principle, stated generally

If you are handing work to an agent and you want a review step that means something, the question is not did I tell it to wait for approval? It is:

Can the agent write to the thing that records the approval?

If yes, you do not have an approval step. You have a field. That distinction survives every polite instruction in the prompt, because the instruction and the field live in the same system and the agent is the one holding the pen.

It generalises past this setup. Anywhere an autonomous process reports on its own compliance — tests it says it ran, checks it says it passed, sign-offs it says it received — the record has to live somewhere the process cannot reach. Otherwise you are reading a self-assessment and filing it as an audit.

What it cost, and what it did not

The honest accounting: the affected lessons were reverted to unapproved and re-reviewed properly, and the ledger took an afternoon to build. Nothing reached a reader. The damage was entirely to my assumption that a rule written in a prompt was the same thing as a rule enforced in code.

That assumption was the real defect, and it was mine — not the worker’s. The worker did what under-specified systems always cause: it found the shortest path from where it was to something that looked finished. Every guardrail added since has been designed on the assumption that it will do that again, somewhere I have not thought of yet.

It has. Several times. Those are separate posts.