AI agents can take real work off operations teams, and most companies are right to move quickly. The decisions worth slowing down for are the few that cannot be taken back. For those, a control has to sit in front of the agent and decide before it acts. A dashboard behind the agent, however good, only tells you afterwards.
Fast teams are fast because they can fix fast
The best product teams ship often, and they are not careless about it. They can afford to move quickly because the cost of a mistake is small and short. Ship on Tuesday, watch the dashboards, patch on Wednesday. The monitoring is the safety net, and for most software it is enough, because a bad release can be rolled back before much harm is done.
That habit is now moving into operations. Agents answer customers, process refunds, update records, approve requests and move money between systems. The teams building them come from software, so they bring software’s safety net with them: logs, traces, evaluation suites, alerts, a dashboard that turns red when something drifts.
All of that is useful. The question this post deals with is narrower. For which decisions is a safety net that catches problems afterwards the right control, and for which ones does the control need to come first?
Not every decision has a Wednesday
Some decisions can be undone cheaply. A support reply with the wrong tone, a ticket routed to the wrong queue, a summary that missed a point. If an agent gets one of these wrong, you see it in the morning and fix it. Monitoring is the right control, and adding friction in front of the agent would cost more than it saves.
Other decisions leave the building the moment they are made. A refund is paid. A discount is promised to a customer in writing. A supplier payment is released. A customer record is changed by someone who was never allowed to change it, and the old value is gone. Fixing these is slow, expensive or impossible, and sometimes it means explaining to a customer, an auditor or a regulator why it happened at all.
Every company already knows which decisions fall in the second group, even if it has never written the list down. You can see it in how human teams are organised. Some actions need a second approval. Some are allowed only for certain roles. Some have a limit above which a manager signs. Those rules exist because someone decided, usually after a bad day, that this particular decision should be checked before it happens and not after.
When an agent takes over that work, the rule does not go away. The question is whether it still sits in front of the decision.
Gates and dashboards do different jobs
Auditors have had words for this for decades. A preventive control stops something wrong from happening. A detective control finds it after it has happened. Both belong in a well-run process, and neither replaces the other. A second signer on a payment is preventive. A monthly reconciliation that spots a payment nobody approved is detective.
For AI agents, the same split looks like this.
| Dashboard (detective) | Gate (preventive) | |
|---|---|---|
| When it runs | After the agent acts | Before the agent acts |
| What it answers | What did the agent do? | Is the agent allowed to do this, here, now? |
| What it needs | Logs, traces, metrics, alerts | The rule itself, in a form a machine can check |
| What a failure costs | Time to notice, plus the cost of undoing it | A blocked or escalated action |
| Best for | Reversible, high-volume, low-stakes decisions | Irreversible decisions, limits, permissions, approvals |
| What it produces | A report | A decision, and a record of why it was made |
The last row matters more than it looks. When a dashboard flags an exception, the record shows what happened. When a gate makes a decision, the record shows which rule was applied, which version of that rule was in force, and why the action was allowed or stopped. The first is a receipt. The second is evidence.
A human team does not need this explained. The person who signs off on a large payment knows they sit in front of the decision. No one would accept a process where the payment goes out and the signer is emailed a summary the next morning. Yet that is roughly what an agent with monitoring and no gate amounts to.
Why so many agents end up with only a dashboard
Nobody sets out to build an agent without a gate. It happens for ordinary reasons.
The first is the order of work. A team builds the agent, gets it doing useful things in a demo, then adds observability so it can see what the agent does in testing. By the time anyone asks about controls, the observability is already there, and it looks like control. It shows every step, it alerts on anomalies, and it produces reports that risk and compliance teams can read.
The second is where the rules live. The rule that says a refund above a certain amount needs a manager is written in a policy document, repeated in a training deck, maybe enforced in one system and not in another. To put that rule in front of an agent, someone has to find the current version, agree on what it means and turn it into something a machine can check. That is slow, unglamorous work, so the rule often ends up as a sentence in the agent’s prompt instead.
A rule in a prompt is guidance. The model reads it and usually follows it, but nothing outside the model checks that it did before the action goes through. Prompt guardrails and output filters help, and they are worth having. They are still part of the agent. A gate is something the agent has to pass, run by something other than the agent.
The third reason is that it mostly works. An agent with good monitoring and a well-written prompt will get the large majority of decisions right. The problem is that the decisions that matter most are the ones where “the large majority” is not the standard anyone signed up for. Nobody would accept a payment approver who follows the limit most of the time.
What a real gate needs
A gate is not just an approval step bolted onto the agent. To work, it needs four things.
The rule, written down once. The gate has to check against something specific: the refund limit, the roles allowed to edit a customer record, the discount a rep may give alone. That rule has to be the approved version, held in one place, not the copy in a prompt or the version someone remembers. If the policy says one thing and the team does another, that gap has to be settled before the gate can enforce either.
A version and an owner. Rules change. Limits go up, roles are reorganised, a regulator issues new guidance. The gate needs to know which version of the rule is in force today, and someone needs to own changing it. Otherwise the gate keeps enforcing last year’s limit with complete confidence.
A decision before the action. The gate sits on the path between the agent’s proposal and the system that carries it out. It returns one of three answers: allow, stop, or send to a person. It does this every time, the same way, whatever the model happened to generate.
A record of why. Every decision the gate makes is recorded with the rule and the version it applied. That record is what lets you answer the question that stalls so many agent projects: how do we know it followed our rules? With a gate, the answer is a lookup, not a reconstruction.
How to sort your agent’s decisions
You do not need a gate on everything. Most of what an agent does belongs behind a dashboard, and gating it would only slow the work down. The job is to find the few decisions that need to be checked first. A working session with the process owner, someone from risk and the team building the agent can do it in an afternoon.
- List what the agent can change. Not what it can read or say, but what it can do: pay, refund, approve, update, send, delete. Each action is a candidate.
- Ask how each one is undone. If a wrong decision can be reversed in minutes at no real cost, a dashboard is enough. If undoing it means a customer conversation, a clawback, a correction filed with someone outside the company, or it cannot be undone at all, mark it.
- Find the rule a person follows today. For every marked action, there is almost always an existing limit, permission or approval in the human process. Write down where it lives and who owns it. If you find two versions, that is the first thing to fix.
- Decide the gate’s answer for each case. Allow below the limit, stop outside the permission, send to a person above the limit. Keep it as simple as the human rule it replaces.
- Keep the dashboard for everything. Gated actions still need monitoring. The gate decides; the dashboard shows how often it said yes, no and escalate, and where the rules may need changing.
The picture usually ends up looking like the grid below. Most actions sit on the left, where speed matters most and mistakes are cheap. A handful sit on the right, and those are where the gate earns its place.
Three fair objections
“A gate will slow the agent down.” For the actions it guards, a little. Checking a rule that is already written in a form a machine can read is a lookup, not a meeting. The real slowdown comes from the cases the gate sends to a person, and those are cases a person was supposed to see anyway. Meanwhile, every action that is not gated runs at full speed, and the team can let the agent do more of them, because the risky few are covered. That is the real trade: the gate is what lets you move fast on everything else.
“We already have a human in the loop.” Often the human is reviewing a report after the fact, or approving a queue of items without the rule in front of them. That is a dashboard with a person reading it. A human in the loop is a gate only when the action waits for them, and only when they are checking against the current rule. If the loop is at the end of the day, it is detective, however careful the reviewer is.
“Our rules are too messy to encode.” Some are, at first. In most companies the rules for the handful of irreversible decisions are already the clearest ones, because they were written after something went wrong. Start there. The exercise of finding them usually turns up a few conflicts and stale versions, and fixing those is valuable even before any agent goes live.
Where Factify fits
This is the problem Factify is built for, so read this section knowing we are not neutral. We think about it in three steps.
Take the rules a company already has, in policies, procedures and the systems that run them, and turn them into one approved, versioned rulebook with an owner for each rule. Conflicts between versions are surfaced and settled here, before any agent depends on them.
Put those rules in front of the agents that act on them. Each proposed action is checked against the rule in force at that moment, and is allowed, stopped or sent to a person. The check runs outside the model, so it gives the same answer every time.
Record every decision with the rule and version behind it, in a form an auditor, a regulator or a customer can read. When someone asks how you know the agent followed your rules, the answer is already written.
The dashboards stay. Factify adds the gate in front of them for the decisions that need one.
Want to see where your agent’s gates should go? Bring one of your processes and we will walk through it with you.
Book a sessionFrequently asked questions
What is the difference between preventive and detective controls for AI agents?
A preventive control checks an agent’s action against a rule before the action happens and can stop it or send it to a person. A detective control, such as monitoring, logging or alerting, finds problems after the action has happened. Both are needed; they cover different risks.
Is AI agent observability enough for governance?
For reversible, low-stakes actions, often yes. For actions that cannot be undone, such as payments, refunds, approvals or changes to customer records, observability tells you what went wrong but cannot stop it. Those actions need a preventive control in front of the agent.
Are prompt guardrails a preventive control?
Only partly. Rules written into a prompt guide the model, and output filters can catch some problems. Both run inside or around the model itself. A gate runs outside the agent, checks the action against an approved rule, and gives the same answer every time.
Which agent decisions should be gated?
Start with actions that change something outside the agent and are hard to undo, and that a human process already controls with a limit, a permission or an approval. Most agent actions do not need a gate.
Does a gate replace human review?
No. A gate allows routine actions, stops ones that break a rule, and sends the cases in between to a person. Human reviewers see fewer, better-chosen cases, with the rule in front of them.