Production-ready AI agents: the 12 gates to pass before real access

There is a moment in every agent project where the demo ends and someone asks whether the thing can run against real systems. Real data and real money, and mistakes that land in someone else's inbox. The gap between those two states has nothing to do with how smart the model is. It is a list of boring properties the setup either has or does not have, and I keep the list as twelve gates. An agent that fails one of them stays in the sandbox. That is the whole rule.

• What this is. A checklist I run before any agent of mine touches production: twelve gates, each with a failure mode and a pass or stop test.
• The split that matters. A demo agent is judged by what it can do. A production agent is judged by what it can destroy. Those are different reviews.
• The shape. Four groups of three: access, actions, failure, operations. The groups build on each other, so the order is not decorative.
• The rule underneath. A gate that lives in the operator's discipline does not count. It has to live in the setup: the flag that ships off, the object that ships paused.
• Default is stop. A gate you cannot test is a gate you failed. Uncertain means no.

The agent doing real work here runs inside Claude Code, and most of the scar tissue below comes from wiring agents to live systems through MCP servers and ad platform APIs. The gates are what survived.

What does production-ready mean for an AI agent?

Production-ready does not mean the agent performs well. It means the blast radius of its worst run is one you have already accepted, in writing, before the run happens.

The question keeps surfacing. One Hacker News thread asks what separates a production framework from a toy, and the poster's own checklist is mostly plumbing: memory, tool error handling, audit logs, deployment. Another warns that an agent can quietly hold more production access than a senior engineer, because it inherited broad credentials without inheriting judgment. That second thread carries the diagnostic I open every review with: if this agent were prompt-injected right now, what is the worst it could do with the credentials it already holds? The checklist answers it in layers. Gates 1 to 3 shrink what a hijacked agent can reach, and gates 4 to 6 shrink what it can do with the reach it has.

Answering that honestly is uncomfortable, which is the point. A model that hallucinates a wrong answer in a chat window wastes minutes. The same model with a writable database connection, a mail sender and a payment API wastes something you cannot always get back. The intelligence did not change between those two sentences. The access did.

So the checklist below never asks how good the model is. It asks twelve questions about the pipe between the model and your systems. Score each one pass or stop, and treat a single stop as the answer.

Gates 1-3: what the agent can reach

Gate 1 is least privilege. The agent gets the narrowest credential that still does the job, and read-only is the default until a write is justified one scope at a time. My search data reader holds a service account with exactly one readonly scope. The analytics reader is a viewer, after I caught myself about to hand it an administrator role because the setup wizard suggested it. The test: list every credential the agent holds and name the write it needs each one for. STOP if any credential exists because it was convenient during development.

Gate 2 is environment separation. Development runs never see production credentials, and the difference is enforced by which secrets exist in the environment, not by which prompt you loaded. The failure mode is an agent that behaves in staging and then meets production data shaped slightly differently. The test: point the agent at staging with production keys removed and watch it fail closed. STOP if dev and prod share a secret store or a database.

Gate 3 is secrets outside code and prompt. Keys live in a secret manager or a local file that never enters version control, never appears in the prompt, and never gets echoed into a log or a chat. Every credential file sits behind an ignore rule and a pre-commit scan, because one leaked token in a transcript is a rotation, and I have done that rotation. Remote tool servers raise the same question one level up, which is why who holds the credential is the first thing I check on any hosted integration. The test: grep the repo, the prompt files and a week of logs for every live key. STOP on a single hit.

Gates 4-6: what the agent can do

Gate 4 is data minimisation. The agent reads the fields it needs and nothing else, because every field it touches is a field that can end up in a log, a trace or a model request. When my reporting pipeline pulls conversions from a customer API, it extracts a click id and an amount and drops the rest of the record, including names, emails and IP addresses, before anything is written anywhere. The test: diff what the API returns against what the agent stores. STOP if personal data rides along because filtering it out was extra work.

Gate 5 is an action allowlist. The set of operations the agent may perform is written down, everything outside it is denied, and the enforcement runs in code before the action, not in a sentence inside the system prompt. Mine stacks two thresholds: a sandbox that flatly refuses paths and hosts outside the working set, and a pre-execution hook that pattern-matches destructive shapes, SQL writes, recursive deletes, force pushes, and stops each one for a human answer. The refusal threshold is this gate. The question threshold is gate 6 arriving early, and it is fine that one hook serves both, as long as both exist. Prompts are suggestions. Hooks are enforcement. The test: ask the agent, in session, to do something off-list and watch the block fire. STOP if the only thing standing between the agent and a dropped table is the phrase "never do this".

Gate 6 is human approval on write, spend and send. Anything irreversible, expensive or outward-facing waits for a person: database writes, budget changes, publishing, and every single message to another human being. The pattern I trust is approval baked into the object itself. Campaigns my automation builds through the Meta Ads API come out of the code paused, every one, and turning one on is a separate human act. The outreach pipeline behind this site defaults to a dry run that stops at drafts. A live path exists in the code, I am not pretending otherwise, and taking it is a human decision under a written rule that no agent flips the switch. Same shape as the create then pause then human rule I use for tools that create objects on an ad platform. The same shape exists one level up, in the agent's own skill library: a deploy skill marked disable-model-invocation cannot be started by the model at all, only by a person typing its name. The test: trace the shortest path from agent output to an external effect and count the humans on it. STOP at zero.

Gates 7-9: what happens when it breaks

Gate 7 is output validation. Whatever the agent produces gets checked by something that is not the agent, before it counts. For structured output that is schema and ID validation, and my campaign analyst has a validator that rejects any recommendation naming an object id that does not exist in the tracker export it was handed. For prose it is a second model with different instructions whose job is to refute, and that judge has caught real errors in this blog before publication, including a number from my own measurement dressed up as a fact about the product. Workers do not grade their own homework. The test: feed the pipeline a deliberately wrong output and watch it get caught. STOP if the agent's confidence is the only quality signal you have.

Gate 8 is retry, timeout and idempotency. Every external call has a timeout, retries with backoff on transient failures, and, above all, a design where running the same job twice does not double anything. My content pipeline deduplicates on post id, so a crashed run is rerun without apology. My deploy uploader retries each file on a backoff after the host started dropping mid-transfer sessions, because the alternative was production frozen halfway between two versions. The failure mode is an agent that half-finishes, and a half-finished write is worse than none. The test has two parts: kill the job in the middle and run it again, then the harder one, let a write land but drop the response, so the retry fires against work that already happened. STOP if anything is duplicated, double-spent or double-sent, and STOP if there is no idempotency key making that second write a no-op.

The n8n error handling walkthrough applies that decision to error workflows, bounded retries and a timeout after an action has already succeeded.

Gate 9 is a full trace. Every run leaves a record of what the agent saw, what it decided and what it touched, complete enough to replay the incident without guessing. The strongest version of this rule I have read is DeepSeek's model-visible means logged, where a message that cannot be logged cannot be sent. You do not need their harness to adopt the standard: append only and timestamped, kept where the agent cannot edit it. On a bad day the trace is the difference between an incident review and an argument. The test: pick yesterday's strangest action and reconstruct why it happened from the log alone. STOP if the answer involves the word "probably".

Gates 10-12: what keeps it honest over time

Gate 10 is tests and evals. The deterministic parts have unit tests, the agent behaviour has a fixed set of scenarios with expected outcomes, and both run before any change ships. Not for coverage theatre. Because agents regress sideways: the prompt tweak that fixes Tuesday's failure un-fixes the one from March, and only a regression suite remembers March. This site will not build if a post's front matter drifts from the contract, and the same idea applies to the agent: encode the contract, make violations fail loudly. The test: name the last change you shipped and the eval that would have caught it going wrong. STOP if the honest answer is manual vibes.

Gate 11 is monitoring cost, errors and quality. The agent has a budget with an alarm, an error rate somebody actually sees, and at least one probe that measures the process rather than its side effects. On cost, an alarm tells you and a cap stops you, and anything that spends wants both, because the agent that most needs the cap is the one stuck in a retry loop at 3am, outrunning every alarm you own. The probe distinction cost me a weekend: a probe that watched the age of the newest item flagged quiet weekends as broken when nothing was wrong, and would have looked healthy with the processor dead, as long as fresh items kept arriving on their own. My stack now runs a few dozen read-only probes on schedules, and the lesson that transfers is smaller than the stack: one budget alarm, one error alarm, one liveness probe per agent, wired to a channel a human reads. The test: unplug the agent for a day, silently. STOP if nothing notices.

Gate 12 is rollback, ownership and an incident path. Before any deploy there is a backup of what is being replaced, a named way back, and a named human who owns the system when it misbehaves at 2am. Every production page this agent has ever overwritten got copied to a dated backup folder first. The one deploy that died mid-transfer is why I trust the habit: the retry from gate 8 fixed it, and the backup was the plan if the retry had made things worse. When something does break, the order is fixed: capture the logs first, fix second, because the fix usually destroys the evidence. The test: name, out loud, the person who gets paged and the path back to the last good version, including where its backup lives. STOP on the first shrug.

The 12-gate scorecard

The compressed version I actually run down before flipping anything live. One STOP anywhere means the agent keeps its sandbox badge.

Twelve rows because that is what my incidents produced so far, not because twelve is a magic number. The count changed before and it will change again. What has not changed since I started keeping it: the count of gates I was comfortable skipping, which is zero.

One honest wrinkle. Sometimes a gate fails and the setup is still safe, because a neighbouring gate carries the load: a draft-only sender behind a production key is the version of that I live with. Compensation like this is allowed on two conditions, that it is written down next to the gate it excuses, and that the note has an owner and a review date. An undocumented compensation is a gap with good luck.

Which gates fail first?

Running this list against my own systems and against the agent setups people have shown me, three gates fail more often than the rest. I have not kept a tally and the sample is mine, so read this section as field notes, not statistics.

Gate 6 fails first, and it fails by scattering. Approval exists somewhere, usually as a habit: the operator always checks before sending, the team always reviews before merging. Then the operator takes a day off. The fix that stuck for me was moving the approval into the object itself, the campaign that ships paused, the sender that stops at drafts, so the gate holds on the days nobody is being careful.

Gate 8 fails silently. Nobody designs for the second run of a job that crashed during the first, and you discover the gap in production, at the moment the pipeline sends its second copy of the same message to the same person. Idempotency is unglamorous work. In the setups I have seen, it is also the gate whose absence most reliably embarrassed someone in front of someone else.

Gate 11 fails by measuring the wrong thing. Activity metrics stand in for process health, and an agent that stops running stops generating errors too, so the dashboard goes green precisely when the system dies. The probe that measures "did the process itself run in the last day" is worth ten that measure how fresh its outputs look.

None of these are model problems. That stays the pattern across every failure on the list: the model is the least broken part of a broken agent deployment.

What this checklist does not cover

Four exclusions, so the list stays honest about its edges.

Model quality is not here. Benchmarks and prompt work belong to a different review, and passing all twelve gates says nothing about whether the agent's output is any good. It says the output cannot quietly hurt you.

Compliance is not here. If your agent touches health records, payments or minors, there are regulators with their own lists, and mine does not substitute for a lawyer. This is an operator's checklist, not legal advice.

Multi-agent orchestration is not here. Once several agents hand work to each other the same twelve questions apply at every handoff, and that compounding deserves its own piece rather than a paragraph.

And organisational readiness is not here, though gate 12 leans on it. A named owner only helps if the org honours the name at 2am.

The checklist earns its keep in one moment: the demo went well and somebody wants to hand the agent real access today. Twelve questions you can ask on the spot. The tests behind them take days, and that is the point. The demo can wait.