Production Agent Gate: Six Controls That Turn a Weekend Build Into an Auditable Operation

The gate is the product

An agent is not production-ready because it can do a useful task. It is production-ready when the organization can show auditability: what it may touch, what it may spend, when it must stop, what it did, how to undo it, and who responds when it fails.

The initial agent lacked limits, records, and human approval gates. It could reach too far, leave no trace, and act before a person could say no.

The fix was not another feature. The following week went to governance work rather than capability.

Production agents fail in the gaps between capability and operational controls. The model may be strong. The workflow may be useful. The risk is still the same: an automated actor with reach, cost, and consequences. The gate exists to make those consequences explicit.

Six controls that make an agent auditable

1. Permissions. Define the boundary before the agent runs. Name the systems, tables, operations, and out-of-scope requests it must respect. It is a boundary.
2. Spend caps. Put a hard ceiling on model calls, data egress, storage, and downstream actions. The cap should be visible to the operator and enforceable by the system. If the agent can keep working after the budget is gone, it is not governed.
3. Human approval gates. Put explicit intervention points where the agent stops and waits for a human rather than proceeding because proceeding was technically possible. It is a stop condition.
4. Observability. Make every action leave a durable record that outlives the session.
5. Rollback. Design the undo path before the first run. If a change cannot be reverted, it needs a stronger approval gate or a different design. Rollback is not cleanup. It is part of the permission model.
6. Incident response. Name the owner, the alert, the escalation path, and the stop condition. An agent incident is not a model problem until a human has decided it is. The response plan should cover a runaway action, a missing approval, and a budget breach.

What to do before you ship

1. Write the permission map. List every system, table, operation, and external call the agent may use. Mark everything else out of scope. Review the map with the team that owns the affected data.
2. Set the spend ceiling. Choose the limit, the meter, and the kill switch. Test that the agent stops when the ceiling is reached. Confirm the operator can see the remaining budget before the agent acts.
3. Choose the approval gates. For each high-risk action, decide who approves, what evidence they see, and how long the request can wait. If no one can approve, the action should not be available.
4. Build the log. Capture the request, the decision, the action, the result, and the identity of the actor. Make the record durable enough to survive a postmortem. A log that disappears with the session is not a log.
5. Test rollback. Run the agent against a staging copy. Force a bad action. Prove the undo path works. If the undo path depends on a person remembering a step, it is not reliable.
6. Run the incident drill. Simulate a runaway action, a missing approval, and a budget breach. Confirm the team can stop the agent and explain what happened. The drill should end with a written note: what failed, who stopped it, and what changed.

Agent governance is not a setup task. It is recurring work that belongs in the budget, not only a one-off build cost.

The production gate is simple. If you cannot show the limits, the spend cap, the approval point, the log, the rollback path, and the incident owner, the agent is not ready. Ship the controls first. Then ship the agent.