How Much Human Review Does an AI Agent Need?

Two companies published opposite answers to the same question this month, five days apart, and both were reported as capability news. Snowflake now routes any agent-proposed change to sensitive data through a five-stage workflow that requires a human to approve before anything executes. Perplexity says it has handed an agent its production systems and checks in far less often than it used to. Read together, they look like a disagreement about how much to trust a model. They are better read as a disagreement about which step deserves the gate.

Snowflake requires explicit human approval before an agent-proposed governance change executes. Perplexity reports checking in far less often on an agent running production systems.

What did each company actually ship?

Snowflake put a human in the path and made the path formal. Its Intent-Driven Governance preview automates the classification of sensitive columns and the deployment of masking policies, and any governance change an agent proposes runs through five named stages before it takes effect. Each step “produces an artifact that requires human approval before it gets executed.”¹ A team can leave the workflow at any stage and finish by hand, so the automation is optional and the approval is not.

Perplexity went the other way and said so plainly. In an OpenAI customer story, cofounder Johnny Ho describes trusting GPT-6 Astra with “full end-to-end systems” and checking in far less often than with earlier models.² The account has the agent writing communications, editing live software, and monitoring production systems directly.

Neither company published its reasoning. That absence is why these look like a contradiction instead of a design choice, and it is why nobody covering either story put them next to each other.

Are Snowflake and Perplexity in conflict?

Snowflake and Perplexity are mostly not in conflict, and seeing why means asking what each agent is actually allowed to touch. Snowflake’s gate sits on a specific class of action: a change to who can see which data. That change is hard to undo in the only sense that matters, because an exposure cannot be recalled once it has happened. Approving it is cheap and the failure is expensive.

Perplexity’s looser posture covers a different population of actions. Writing code, opening changes, running monitoring and drafting communications are all things you can inspect afterward and revert. Checking in less often on work that leaves a reviewable trail is a reasonable trade, and it is not the same bet Snowflake declined to make.

The two postures would genuinely diverge in one place, which is an agent pushing a change into a live production system. Neither company addressed that case directly, so read what follows as my extension of each stated position rather than their policy. Snowflake’s approval requirement covers data governance and would, extended, argue for approving the push first. Perplexity’s account describes software delivery as precisely the check-in they now do less of. Everything else, both would treat about the same way.

What is the rule for gating irreversible steps?

Put the gate at the irreversible step, not at the smart step. That line is not mine and it is not new: it descends from the one-way door and two-way door distinction Jeff Bezos set out in 2015, where an irreversible choice earns slow deliberation and a reversible one earns speed, and agent-safety writing has been applying it to gates for a while.

What it does here is reconcile two announcements that read as a contradiction, because it asks about the action rather than about the model performing it.

What it corrects is a common and expensive instinct. Faced with an agent, teams tend to gate the impressive part, which is the model deciding something, because that is where the anxiety lives. Reasoning is cheap to check afterward and cheap to discard, so a gate there buys very little and slows everything. The write is where the money is: the moment an action leaves a trace someone else depends on.

Because reversibility is a property of the action rather than of the model, it makes a far more concrete test than trust. Can you look at what happened and undo it without a conversation? Then a gate is a tax. Does the action publish, delete, charge, expose or deploy? Then approval is worth the friction regardless of how good the model has become, because the model’s quality changes the probability of a bad write and never changes its cost.

Does gating the irreversible step hold up in a publishing pipeline?

Gating the irreversible step is the rule my own publishing pipeline already runs on, which is the only reason I trust it enough to write down here. Three gates enforce it, each one placed at a write and none of them at a decision, and each one costing almost nothing on the days it does not fire.

Before any push to a repository lands, a hygiene check has to pass against the exact commit going out. Not the last commit that passed, not the working directory, the one going out. Publishing is the irreversible step on a site where every push rebuilds and deploys, so that is where the block belongs.

The builder and the reviewer are always separate agent instances, never the same one grading its own output. That one gates judgment instead of a write, and it earns its place for a narrower reason: an agent asked to check its own work reliably agrees with itself, so the review costs real tokens and returns almost nothing.

Irreversible steps get a two-stage commit, where the action is prepared, shown, and then executed as a separate decision. This week that changed a sequence rather than catching a failure, which is the more honest and less dramatic thing a gate usually does. An article was finished before the interactive component it needs existed, and an article missing that component fails the deploy check.

Since the daily automated publish runs that same check, filing the draft in its normal place would have broken the next morning’s publication. So it was held outside the content collection until the component was built, then moved in. Nothing ever went red. The cost of the irreversible step was legible in advance, so the order of work changed instead, and that is what a gate placed correctly buys you.

What should you take from Snowflake and Perplexity’s disagreement?

Stop asking how much you trust the model and start asking what the action costs if it is wrong. The first question has no stable answer, because it moves with every release and with how your week has gone. The second is a property of the action and holds still.

Then write the gate where the answer is expensive. Snowflake did that for data exposure. Perplexity did it, implicitly, by keeping its loosened supervision on work that leaves a reviewable trail. Both look defensible from inside that frame, which is a better outcome than deciding one of them is reckless.

The version of this that goes wrong is a team gating everything, discovering the approvals are theater because nobody reads them, and then removing the gates entirely. Reversibility tells you which few to keep, and keeping few is what makes the remaining ones get read.