Skip to content

An Agent With Write Access Is an Outage Waiting for a Schedule

Autonomous agents are good at proposing changes and bad at being trusted with them. The whole design problem is putting a reviewable boundary between the two, and most setups skip it because the boundary is inconvenient.

The pitch for an autonomous content pipeline is straightforward and mostly correct: an agent can check hundreds of records against their sources far more often than a person will, and it never gets bored on record 180.

The part that gets skipped is what happens when it is confidently wrong on record 180 — and it will be, because confident wrongness is the characteristic failure of the technology rather than an occasional lapse.

Blast radius is the only design question that matters

Everything else is tuning. The question is: when this agent is wrong, what is the largest thing it can damage before a human sees it?

Three arrangements, in increasing order of how much sleep they cost:

Write access to production. The agent edits live data. A bad inference is live immediately, there is no diff, and if the change overwrote a field you may not be able to say what it used to be.

Write access to a staging system. Better, but the promotion step is usually automatic or nearly so, and the diff — if there is one — is between two database states, which nobody reads.

Write access to a branch. The agent opens a pull request. Nothing it does is visible to a reader until a person merges it. Its total blast radius is one branch in one repository.

The third one is not a workflow preference. It is the only arrangement where being wrong is cheap, and cheap wrongness is the thing that makes autonomy viable at all.

What a good diff looks like

“Open a pull request” is necessary and not sufficient. A 400-file pull request from a bot gets rubber-stamped, and a rubber-stamped review is a review that did not happen.

The properties that make a machine-authored change actually reviewable:

One record per file. A change to one conference is one file in the diff, next to its own context. If corrections are batched into a single data file, every review is a review of a 4,000-line JSON blob.

The evidence in the same hunk as the change. If the record carries an append-only log of what each check found, then the correction and the note explaining it land in the same diff. A reviewer can see that they agree. Split them across two files and they are two hunks that can disagree — and a partially-applied change gives you a log claiming something the record does not say.

Schema validation as a gate, not a suggestion. The branch does not merge if it does not validate. This is what makes a review a review of judgement rather than of syntax.

Refusals encoded as constraints. The rules that matter most are the ones about what the agent must not do, and those belong in the schema where they are checked, not in a prompt where they are advice.

The rule that came out of a real corruption

Here is the one that is easy to get wrong and expensive to unwind.

A verification agent asked to make a dataset “complete” will complete it. Given a city with no state, it will supply a state. Given a location string, it will parse a country out of it. Given a missing venue, it will find something plausible.

Every one of those is an inference presented as a fact, and it is indistinguishable in the data from a fact that was actually checked. Portland is in Oregon, unless it is the one in Maine. A blanket pass to “fix” dates will move dates that were correct.

The rule, stated absolutely: an absent field is honest; a guessed one is corruption.

That is enforceable. Require every field to be evidenced or absent. Type your sources — official, secondary, aggregator — and refuse to let a record claim more confidence than its own sources support:

evidenceStrength "official-source" requires a source with role "official"

Now “verified against four listing sites that copied each other” is not representable, and the agent cannot produce it however confident it is.

Separate who said it from how strong it is

A single status: verified | provisional | suspect field conflates two independent questions: who asserted this and what the evidence actually supports.

They vary independently. An organiser-asserted record can still be uncorroborated — they said it and nothing else confirms it. A pipeline-asserted record can rest on the organiser’s own site. Collapsing them into one axis means the strong case and the weak case render the same word.

Two fields, two vocabularies. It costs nothing and it makes the second-order rule above expressible.

Where autonomy actually pays

Not in writing. In checking.

An agent that proposes a correction with sources attached, on a branch, against a schema that refuses guesses, is doing the highest-value work available: noticing that something changed. A conference moved. An edition was cancelled. A record has been unverified for nine months. Those are exactly the facts a consumer cannot discover for themselves and exactly the facts that go stale silently.

Give it that job, take the merge button away, and the failure mode goes from “your dataset is quietly wrong” to “somebody has a pull request to read”. That is a trade worth making every time.

Keep reading

More on AI

Every vertical on this site carries its own writing, its upcoming events and its answers on one page — and the whole archive is available as a feed with a real publication date on every item.