The Seven Gates an AI Agent Has to Clear Before It Writes to Production

What makes a gate a gate?

An artifact. A condition that must be true before an autonomous action is allowed to touch a system of record, plus the specific thing a reviewer can look at to confirm it.

That is the difference between a gate and a checklist. "Human oversight is in place" is a sentence; "the approval rule, the queue it writes to, and the named operator who clears it" is a gate. One of them survives a busy Tuesday, an audit, and a change of staff.

I wire these gates into the systems I ship, and I have also reviewed agent deployments that skipped them. The pattern is not that teams are careless — it is that they clear the gates that are interesting (model quality, prompt design) and skip the ones that are administrative, and the administrative ones are what turn a pilot into an incident. Seven gates, in the order I would clear them.

Every gate is an artifact, not an intention. If nobody can point at the thing that proves a gate was cleared, the gate is a hope with a checklist next to it.

Gate 1 — The action register

The artifact: one table listing every action the agent can take against a system of record, with its blast radius, its owner, and whether it is reversible.

Blast radius has three useful sizes: a draft nobody acts on yet, an internal record a colleague will use, and an external commitment a customer or supplier will see. The register exists because the answer to "what can this thing do" is usually longer than the team's mental list, and the external-commitment rows are the ones that need every other gate.

Skipped when: the agent's capabilities grow by adding tools, and the register is written once at the start and never again. It is the only gate whose artifact is systematically out of date by month three.

Gate 2 — Per-action authorisation

The artifact: the scopes the agent actually holds, printed from the identity provider, next to the scopes the workflow needs.

Three properties make this gate real. The agent's credentials are narrower than the human who approved the workflow — an agent inherits one decision, not a person's authority. They are scoped per action, so revoking a tool is a configuration change rather than a rotation of everything. And no credential is shared between environments, tenants or agents, because a shared credential makes the run record unattributable exactly when you need it.

Skipped when: the fastest path to a working demo is to paste the admin key the developer already had. That key then lives in production, and every incident afterwards has an unresolvable question at the centre of it: who did this?

Gate 3 — The evaluation set, with a stated denominator

The artifact: 60 to 120 recorded cases with documented correct outcomes, the scoring rule, and the measured confidently-wrong rate per 100 runs.

Accuracy is the wrong acceptance number on its own, for a reason worth stating plainly: a system that abstains on everything it does not understand is safer than one with a higher accuracy that is confidently wrong on the cases where it matters. The gate requires the failure count, not just the success rate — and the failure count has to come from your traffic rather than the vendor's demo set.

Skipped when: the pilot ran on happy-path data and the evaluation set is the demo script. Mining cases from production logs is how the set gets built without inventing anything, and measuring quality without a lab is how it stays cheap to rerun after every model change.

Gate 4 — The approval rule, matched to risk

The artifact: for each row in the action register, the condition that sends the case to a human, the queue it lands in, the person accountable, and the time they have.

A gate that routes everything to a person removes the labour cost it was meant to remove; a gate that routes nothing lets confident errors reach customers. The useful middle is a written rule with real thresholds in it — "review when the discount exceeds fifteen per cent, or the customer is in the top revenue decile, or the model's own confidence is below the calibrated band" — and a named owner for each queue. Designing a human-in-the-loop that works covers where those thresholds belong and how to keep the review to fifteen seconds per case.

Skipped when: "the operator can always check it in the UI" is treated as the control. That is availability, not a gate: nobody is accountable for checking, and no case is guaranteed to be checked.

Gate 5 — The run record

The artifact: a per-run entry with the input as received, the prompt and model version, the tool calls with arguments, the decision, which gate applied, and any human override — joinable to your own identifiers.

The test is a single question: pick a run from ninety days ago and reconstruct what happened, without the vendor's console. If that takes an engineer and a support ticket, incident investigation will not happen, and a system nobody can investigate gets switched off — which is how automation quietly dies rather than being repaired. AI workflow observability is the design; here it is only the acceptance condition.

Skipped when: logs exist but are per-service, timestamped in three time zones, and not joinable to a task id. Volume of logs is not a run record.

Gate 6 — The failure plan

The artifact: the kill switch, the rollback path, the queue drain, and the person who is paged — each with the command or the console location written down.

For each failure class in the register, the plan answers four questions: how does the agent stop, what happens to work already in flight, how is a wrong write corrected, and who decides. The plan is not a document about resilience; it is a set of tested switches, and a kill switch that has never been pulled is a hypothesis.

Skipped when: rollback means "we would restore the database", which nothing in the workflow is designed to survive.

Gate 7 — The cost ceiling

The artifact: the maximum cost per run and per day, the behaviour at the ceiling, and the alert that fires before it.

Two failure modes, both real. A retry loop can spend a month's inference budget in a night, and an agent that decides to be thorough can call forty tools per case without anybody noticing until the invoice. The ceiling is also a safety mechanism rather than a finance mechanism: a workflow that stops at a cost limit has failed visibly, which is better than one that keeps working at the wrong scale.

Skipped when: the spend is small enough that nobody thinks it matters. The ceiling is cheapest to install on day one and most expensive to retrofit after the first spike.

What does each gate cost to clear?

Days, not quarters. That is worth saying out loud in a room where "governance" is treated as a programme with a steering committee, because none of this requires one — it requires an owner and a date.

How does this map to the compliance frameworks?

If the seven artifacts exist, most of a vendor questionnaire, an ISO 42001 control set, or an AI Act readiness review is answered by pointing at a file rather than writing a new document: the register covers inventory, the authorisation scopes cover access control, the evaluation set covers testing, the run record covers traceability, the failure plan covers incident response. That is not a legal opinion and it is not a certification. It is an observation from filling in these questionnaires: the answers are artefacts, and a team that has been running the system properly has already produced them. The compliance question enterprise AI keeps getting wrong is the longer version of that argument.

What has to be true of the gate itself?

Four properties, and a gate missing any of them is decoration.

It is in the write path. A dashboard that shows what happened is monitoring. The gate is the code between the decision and the write, and if it is not there, nothing is being prevented.

It fails closed. An unreachable gate must block the action rather than allow it. A gate that times out into permission is a gate that will be bypassed by the first network partition — and it will be discovered by the same event that made it matter.

It is testable. There must be a way to trigger the gate deliberately and observe the refusal, in staging, on the day of handover. If the only evidence it works is that no incident has happened yet, it has not been tested.

It is logged. Every gate decision goes into the run record, including the ones that allowed the action. "The system was permitted to proceed" is the entry an investigation needs most.

The sheet

Copy this into the release ticket; each row is closed by a link to the artifact, not by a tick.

Seven rows, and the deployment is not "ready" until each has a link next to it. The gates that get skipped are always four and six — oversight and failure — because they are administrative and the demo does not depend on them. Those are also the two that decide whether a system that works today is still running in a year, or has been switched off by the person who inherited it.