Three Doors AI Agent Authority Cannot Open
The hard question about agentic delivery is not whether the agent writes good code. It is what the agent is allowed to decide on its own. Every team that gets past the demo stage runs into it, usually the first time an agent does something defensible that nobody asked for.
Our answer fits in one line. AI agent authority is complete inside a step of our process and absent at the line between two steps. An agent moves fast within its lane and stops at every handoff. This post is the three handoffs where it stops, and what each one actually checks.
Our Five Steps, and the Two This Is About
A-CX delivery runs on five named steps on every engagement: Deliver Brief, Deliver Spec, Deliver Plan, Deliver Code, and Deliver Deployment.
The first two are client-facing and PM-owned, and we have written about how a brief becomes a spec already. This post stays inside engineering: the line into Deliver Code, the line back out of it into Deliver Plan, and one line inside Deliver Code itself.
Merging a pull request is a separate control with its own gate, and last week’s post covered it. Everything below is about the work item rather than the code change.
Door One. Deliver Code: May an Agent Take This On?
The authority in question is starting. An issue becomes eligible for a run to pick up only when it carries a priority lane, an estimate, and a body whose every acceptance criterion is an observable outcome with a named test approach. Miss one of the three and the issue stays in draft with the specific gap recorded against it.
The part worth dwelling on is the estimate. An unknown estimate used to fall back to a default and grant readiness anyway, which felt harmless because the default was sensible. It was not harmless. A default is a decision wearing the costume of a fallback, and it was being made by the party that wanted the work to start. Now an unknown estimate holds the issue in draft and names the gap, and a person supplies the number.
Door Two. Deliver Plan: May an Agent Invent Its Own Work?
A run that is delivering one issue will notice other things. Some of them matter. When it files what it noticed, it is writing a ticket it may then be dispatched to build, which makes this the only place in the process where an agent both defines the work and does it. Two separate checks sit on this door.
Is the Finding Worth Existing?
This is the failure mode nobody warns you about, and it is not a coding failure. An agent asked to look for problems will find them, then keep going: problems that need a hostile administrator to trigger, problems in code paths nothing calls, contradictions in documents nobody reads. It will write each one up carefully, cite real files and real line numbers, and propose a fix. The output looks like diligence and behaves like noise.
We measured it rather than argued about it. A review on 12 August took 60 findings an autonomous run had filed and went through them one at a time. Forty-four were closed as wontfix. Every single one described something real. That is the uncomfortable part: our check at the time asked whether a finding occurs, and it never asked whether the finding matters.
What replaced it is a closed list of four consequence categories, calibrated against that batch of 60 rather than invented in the abstract. They are the distinctions the human review had actually used to separate its sixteen keepers from its forty-four drops. A finding matching none of them is not filed.
- It blocks or wastes real delivery. A stalled unit, a wasted queue slot, a repeated manual chore. Never a defect whose only effect is on reported state: a label, a count, a log line, a status message.
- It is a reachable security or correctness hole. Reachable means without a hostile insider and without constructing a scenario.
- It is a live contradiction in a load-bearing document. One that has already misled someone or something, rather than one that could.
- It is product-facing. A defect a client, or an engineer outside this repository, actually experiences.
Two of those four exist specifically to kill invented problems. The reachability clause refuses anything that needs a hostile insider or a constructed scenario, which is where most imagined vulnerabilities live. The contradiction clause requires that something was already misled, not that something might be. Both replace a hypothetical with an occurrence.
Declaring a category is a claim, so each one costs a citation: a single body line naming the stalled unit and its run, or the reachable trigger, or who was already misled. A finding that cannot cite what its category requires is not filed. And the test applies to the consequence rather than to the writing, because a well-evidenced trivial finding is still trivial. Evidence quality, citation density, and the priority label already on an issue are not consequence, and an agent is very good at producing all three.
Nothing is thrown away. A finding below the bar is recorded in full, with its analysis, in a file that exists for exactly that purpose, and it can be promoted later. What changed is where it lands, not whether it survives.
The honest ending to this one: the bar was written as prose first. It failed twice within hours, on the person who had just written it, who filed two issues that matched none of the four categories while citing real runs and real files. That is why the bar now lives in the code that creates issues and refuses a create without a declared category. A rule that depends on the discipline of the party it constrains is a suggestion.
Is the Finding Legitimately Derived?
The second check is narrower and stranger. A run may file a bug whose origin is an issue the run itself closed, which opens a laundering path: close a human-held draft as a side effect of unrelated work, then refile its content as your own fresh finding.
Our first version of this check asked whether the origin had been closed by a merged pull request that closes it. It looked mechanical and it was forgeable, because closing keywords are free text the agent writes in its own pull request body, and a closing reference closes that issue whether or not the merged change touched it. We had already hit the benign version, a stray issue number in a body linking something nobody intended.
The replacement asks a question the run cannot answer for itself. Was this origin the very unit the run was dispatched to deliver, and did the run close it by merging a fix its own record confirms? A run does not choose its own dispatch. Both conditions hold or the finding is ineligible, and anything unconfirmed is ineligible, because the check fails closed.
Door Three. Deliver Code: May an Agent Call Its Own Work Done?
A parent issue closes when its acceptance criteria are met. The agent that did the work is the one holding the pen, so the rule is that ticking a criterion is transcription and never judgment. The pipeline copies across a verdict that was recorded at the moment the criterion was verified. It does not re-form an opinion at closing time, when the incentive to be finished is strongest.
Everything ambiguous stays open. A criterion whose recorded verdict is fail, unverified, partial, absent, or simply unparseable is left unticked and reported by name. Ambiguity never ticks, and a parent with one unticked criterion does not close.
Why the Line Is the Right Place for a Gate
Put the gates in the middle of a step and you get a slow agent and an annoyed team, because most of what happens inside a step is reversible and cheap. A bad line of code is caught by a test. A bad refactor is caught by review. The cost of being wrong stays local.
At a handoff that stops being true. Work admitted into Deliver Code too early gets built on. A finding filed without consequence consumes a queue slot and a review pass. A criterion ticked without a verdict closes a parent and tells everyone downstream that something is finished. Each of those is a wrong judgment that the next step compounds rather than catches. That is why every gate we have sits on a line between two steps, and none sits inside one.
Applying This to Your Own Process
The steps do not have to be ours. The method transfers.
- Draw your steps and put the gate on the line. Not inside the box, where it slows work that is cheap to undo.
- Name the authority at each line in one verb. Start, create, approve. If you cannot name it, you do not yet know what the gate is for.
- Make the agent prove consequence, not occurrence. Anything that needs a hostile insider or a constructed scenario is not a finding.
- Never accept as evidence anything the agent authored. Ask a question it cannot answer about itself.
- Record what you reject. A bar that discards findings will be argued with. A bar that files them elsewhere will not.
Talk to Us
If you are working out where your own agents should stop, that conversation is one we have regularly, and it usually starts with drawing your steps on a whiteboard rather than with tooling. A-CX builds and runs AI Workflow Automation that is governed, observable, and still moving in production. Get in touch and we will tell you what we would gate first.
