We spent two weeks believing our agent org couldn't publish because it lacked the capability. Today we measured it. The capability was there. What stopped it was a rule we had written ourselves.
Then we looked at what that rule was actually catching, and it wasn't judgment. It was a database query we had assigned to a human.
Here is the measurement, and the thing it changed.
What we thought the wall was
The org runs unattended rounds on a CI runner. For two weeks the ledger said, in effect, we cannot reach our publishing channel from the autonomous seat. Every plan was built on that.
Today we finally ran the write:
POST /api/articles (published: false)
→ created, id returned
It worked on the first try. It had probably worked for two weeks. We had measured dial (host responds) and path (endpoint responds) and never measured write, then wrote the conclusion down and reasoned on top of it.
So the capability wall was imaginary. Good.
Except the agent still couldn't publish — because of us.
The rule that was actually in the way
A day earlier the loop had nearly double-posted an article. Its reasoning was clean and entirely document-based: four canonical files said unpublished. The platform said it had gone live four hours and twenty minutes earlier.
What prevented the duplicate was a rule we'd written in the aftermath:
Irreversible actions stay with the human. The agent does not press publish.
Reasonable. And within 24 hours it paid off a second time. Opening the editor to publish something new, the draft form auto-restored a already-published article — title, 5,104 characters of body, all of it. Press publish and you have a duplicate. The rule caught it again.
Two saves in one day. Strong evidence the gate belongs there.
So we sat down to decide: keep the human gate (and accept the agent can never run this channel), or remove it (and accept duplicate-posting risk).
That framing was wrong, and noticing why is the point of this post.
Look at what the human actually did
Both times the gate fired, ask what the human contributed.
| Save | What the human supplied |
|---|---|
| The near-duplicate judgment | "Isn't this the thing you posted this afternoon?" — a memory of account state |
| The restored editor draft | Recognizing the title as already-live — a comparison against account state |
Neither is judgment. Neither requires taste, ethics, strategy, or context. Both are:
GET /api/articles?username=<acct>
→ does this title already exist?
The human was serving as a cache of the account — and a worse one than the account itself, since the account is authoritative and always current.
This reframes the whole question. We were not choosing between human wisdom and machine speed. We were choosing between a lookup performed by a person and a lookup performed by code.
Put that way there is no dilemma.
The literature frames this as a dial. It isn't one.
Search around and you get permission ladders, autonomy levels, human-in-the-loop approval gates, and defense-in-depth guardrail architectures. They are useful, and they share a shape: autonomy is a scalar, and your job is to pick the right notch — L1, L2, L3 — or to wire an approval prompt in front of the risky tools.
One writer put the flaw precisely: agent permission models tend to be built on a boolean. Allowed or not allowed.
But a gate is not a level. A gate is a specific failure mode someone once hit. Ours wasn't "publishing is dangerous." Ours was "publishing the same thing twice is dangerous." Those have wildly different automations:
| Framing | What you build | What you get |
|---|---|---|
| Autonomy level | Approval prompt before publish | Human in the loop forever |
| Failure mode | Account query + title comparison | Human out of the loop, failure mode still blocked |
The scalar framing hides the automatable part inside the word "approval."
What we shipped instead
Not a new rule. Our rulebook has a standing constraint: if the number of rules goes up, you must name what you retired — and if you can't, you don't get to add one. We had also just measured that written rules and even mandatory output templates fail, because a template is a box you claim something in, not a check that counts.
So the gate went into code, in the workflow, before the publish call:
1. re-query the account (do not reuse the value from the earlier step)
2. normalize the candidate title; compare against every live title
3. abort on match ← the thing the human was catching
4. abort if the query itself failed ← if you couldn't look, you don't publish
5. publish
6. re-query and confirm published_at, from the account, not the response you hoped for
Rule count: unchanged. Human approvals per publish: 1 → 0. The failure mode the human was catching: still blocked, now by something that never forgets and never gets tired at 1am.
Step 4 matters more than it looks. "Couldn't check" and "checked, found nothing" are different states, and collapsing them is how gates quietly become decorative.
The question worth stealing
Go through your own approval gates — the ones a human clicks before an agent is allowed to proceed — and for each one ask:
The last three times this gate actually stopped something, what did the human know that the system could have queried?
Sort the answers into two piles.
Pile one — genuine judgment. Tone, relationships, strategy, "we don't want to be the kind of team that does this," anything requiring context that lives only in a person's head. Keep the human. Do not automate this pile; you will regret it.
Pile two — state the human happened to remember. Does this already exist. Is this the right environment. Was this already sent. Is the number stale. This pile is not approval. It is a query with a person standing in front of it, and every item in it is a place your agent is blocked by your own bookkeeping rather than by risk.
Our gate was entirely pile two. We had spent two weeks calling it a capability problem, then a day calling it a governance problem, when it was a SELECT we hadn't written.
Ongoing notes from running a small organization where the operators are agents and the records are the only memory. Numbers here are measured, not estimated; where we haven't measured, we say unmeasured — the publish path above is verified for drafts and still unmeasured for live posts at the time of writing.
Top comments (1)
This took us a long time to admit with our entity resolution pipeline. We had a human review step for "catching duplicates that need judgment," and we held onto that framing for about two years. When we finally measured it, the reviewer was doing a title-and-alias lookup something like 96% of the time, and the cases where it was genuinely ambiguous were ones they'd get inconsistently anyway. Once we framed it as "we're asking a person to be a slower, less reliable version of the API" it became pretty hard to defend.