Gating agent tool calls before they run

The moment an agent moves from answering questions to taking actions, the question changes from "was the answer good" to "should this have happened". Our permissions and guardrails for AI agents page covers the permission model: which tools the agent has, what each can touch, and how a person approves the dangerous ones. This page is about the check that runs on each individual call, and what a decision model changes about it.

What it changes is cost and shape. A check that costs a language-model generation per tool call gets turned off when the agent makes 40 calls a task. A check that costs one typed request in TypeSafe's reported 70 to 500 milliseconds [1] can run on every call, and because it returns probabilities rather than prose, the decision rule is a threshold in code.

Where the gate sits

The gate is code between the agent and the tool. The agent proposes a call (a tool name and arguments), the gate builds a state from the proposal plus the context it needs (the user's original request, the tool's description, the argument values), asks Jev a set of questions, and returns one of three outcomes: run, confirm, or block. The tool executes only on run, or on confirm after a person says yes.

Two properties make it a real gate. The agent cannot call the tool any other way, and the gate's decision is code over the probabilities, never a model deciding to skip itself. TypeSafe's design guide's rule applies with full force here: side effects stay in code [2].

LangChain's harness post describes this as a middleware, which is code that runs between the agent framework and the tool. Its example uses Jev to classify a tool call's risk and blocks the call before the tool executes; the post gives no thresholds, only the mechanism [3]. Openlayer's jevals has a ToolCallRisk check that gates tool execution with approve, escalate and block outcomes, and it distinguishes read-only operations from irreversible ones such as refunds, deletions and external messages; it also ships an ExcessiveAgency check for whether the agent exceeded its authorised scope [4]. Both are the same shape as what we build.

A Noul per side effect

The design we use asks one Noul question per kind of consequence, about the proposed call, in one request. The questions are narrow and named, following TypeSafe's guidance that a broad question hides several judgments [2]:

deletes_data: this call would remove or overwrite existing records.

moves_money: this call would charge, refund, transfer or change a balance.

leaves_the_system: this call would send a message, an email or a request to a party outside the application.

matches_request: this call does what the user asked for, with these argument values.

exceeds_scope: this call touches a resource the user did not mention and the task does not need.

The first three are about the tool and its arguments and are often answerable from the tool definition alone, in which case they belong in a lookup table rather than a question; ask the model only where the arguments decide it (an update that sets a field to empty is a delete). The last two are about the relationship between the call and the request, and they are the ones where a decision model is worth using, because they need the sentence read.

A Score question can join them: how severe would the worst outcome of this call be, on a 0 to 3 scale described in words, the same shape as the severity score in TypeSafe's guardrail cookbook [5].

Thresholds by consequence

TypeSafe's confidence page says different actions within one system should be gated at different levels depending on the consequences, and that a read-only operation tolerates lower confidence than a destructive one [6]. For tool calls that becomes a table keyed by the answers above.

A read (fetch a record, search, list): run unless matches_request is below 0.3, in which case confirm.

A reversible write (create a draft, add a tag, update a field with history): run if matches_request is above 0.8 and exceeds_scope is below 0.2; confirm otherwise.

A message that leaves the system (email, notification, external API call): confirm unless matches_request is above 0.9 and exceeds_scope is below 0.1, and block if the severity score is at or above 2.

An irreversible action (delete without history, payment, transfer): confirm always, and block if deletes_data or moves_money is above 0.5 while matches_request is below 0.7. Some teams choose never to run these automatically, and that is a policy decision rather than a threshold.

The numbers are starting points. The tuning signal is the confirmation queue: if a person approves a class of call unchanged every time, the threshold for that class can come down; if a person overturns calls that ran, it goes up. Confidence-gated routing covers the logging and the monthly calibration check that keep that tuning tied to outcomes.

The human step in the uncertain band

The confirm outcome is a message to a person showing the tool, the arguments, the user's request and the probabilities, with approve and reject buttons. Two rules keep it useful.

The person's decision is stored as a label against the state that produced it. That labelled set is what you re-run when the model version changes, and it is how the thresholds get tuned from evidence.

Confirmation is capped. An agent that asks for confirmation on every call has a gate set too high, and a person who approves without reading has a gate that no longer works. Track the approve rate per tool; a rate near 100 percent means the threshold should come down for that tool, and a rate that suddenly drops means something changed in the agent or the model.

How to decide if a feature needs a human in the loop is the shorter piece on when a confirmation step belongs in a product at all.

A decision model choosing the actions: Browser-use's Jev Ultrafast

The gate above checks actions a language model proposed. Browser-use went one step further on 16 September 2026 and had Jev choose the action. Its Jev Ultrafast agent reads a structured table of the controls on the page, each with an index, a control type and a label with its current value, instead of a screenshot, and asks one request that returns both the operation (click, type text, select, scroll, wait, done, or blocked) and the target index; in Browser-use's words, "Two decisions, one network round trip" [7]. Only operations compatible with a target are offered as options, so the model cannot pick an impossible pair.

Browser-use's measurement is six alternating runs of one Google Flights task: median time fell from 9.450 seconds to 7.092 seconds, and browser protocol calls fell from 1,092 to 101 [7]. The README says plainly that this is three repeats of one task on one browser profile and "not a general reliability benchmark". We cite it for the design, and the caveat stays attached to the number. Our AI News item is Browser-use's Jev Ultrafast.

The design is the interesting part for a gate. When the action space is a fixed list and the state is a structured table, the action choice itself is a Choice question with a probability per option, and the same threshold logic that gates a proposed call can gate the choice: a low-confidence click waits for a person, a high-confidence one runs. The "blocked" option in Browser-use's list is the model's way of saying that no action fits, which is the "none of these" case from intent routing.

What the gate does not replace

A decision model reads the proposal and returns probabilities, and enforcement stays with code. The tool still needs a permission check in code that the gate cannot override, argument validation against a schema, and an allowlist of what each tool may touch. TypeSafe's jaggedness page says adversarial content in the state can move the answer [8], and a tool call whose arguments were shaped by text the agent read from a web page or an email is exactly that case, which prompt injection and adversarial input covers. Openlayer's IndirectInjection check, for instructions inside tool results, retrieved documents or emails, exists for the same reason [4].

The gate also needs an audit log: tool, arguments, state hash, model version, every probability, the outcome and, for a confirm, the person and their decision. How to audit an AI agent's tool permissions is the checklist for reading that log.

Where Reveneau fits

Reveneau builds agents with this gate in code between the agent and every tool that has a side effect, with the thresholds in a versioned table and the confirmation labels feeding the eval suite. The suite itself is graded with Jev: whether an agent's trace followed the plan is a Noul question with the rubric in the criteria, and a grade in the uncertain band goes to a person whose label is kept. Evals with Jev describes that setup, and can you trust an AI agent is the argument for why the gate has to be in code rather than in the model's instructions.