The last approval gate for agents: whether to keep it is the FDE's call

On 24 September Jeremy Canale submitted a paper to arXiv with an intriguing title: “The Last Human Gate”. The content is highly technical: a framework for replacing, task by task, the work done at governance gates with agents, rule engines and evidence services. The person tasked with connecting all of it is the FDE.

The question the paper asks is the same one a client will put to you in your first working session: which steps still need a human signature, and which can a machine handle? Get it wrong in one direction and the agent stalls in an approval queue. Get it wrong in the other and a risky action runs without anyone noticing.

The paper’s value therefore lies less in the framework than in the way it separates two things that are usually treated as one.

The evaluation uses DGF-Bench, with 300 synthetic projects and 899 scoreable runs, each run being one model on one project. It adds an evidence audit and 135 repeated runs to distinguish correct decisions from reliable execution.

An agent that answers correctly once is not enough; it has to answer correctly on the 135th run too.

Some gates cannot be removed yet, and that is good news

The most notable detail is a limitation the paper itself acknowledges: a document-based counterexample shows that some gates cannot be decided from the information available. For such a gate, the problem lies not with the agent or the rule engine but with input data that is not yet sufficient to automate the step.

Those gates cannot be removed yet, and the FDE is the person who identifies them before anyone promises a client “full automation”.

Practitioners look at the same problem more simply. Alejandro Rioja, a practitioner writing on his personal blog, reviews the approval queue every month and removes any gate that shows 95% same-day approvals with 0% modifications.

Rioja also removes gates when no one can approve within the SLA, replacing them with an audit trail: a gate where the reviewer simply clicks through protects no one; it only slows the agent down.

His test for keeping a gate is equally simple: if you would not want a new hire to do the task without checking first, the agent needs a gate. Airia, a vendor in this space whose advice should therefore be read with some caution, expresses the same idea as policy: approval authority should be proportionate to the risk of the action.

The FDE’s job is turning criteria into code

Airia’s strongest point, and the place where FDE work begins, is that gate trigger conditions must be machine-readable and enforced at the execution layer, not merely stated in a prompt. Picture a line in a system prompt saying “ask a human before deleting data”: that is not a gate.

A gate is code that blocks an action until a signature arrives, with a log of who signed and when.

Canale’s paper assigns the FDE precisely the job of connecting agents, rule engines and evidence services.

Read through the eyes of someone doing the deployment, that connecting work cannot avoid two questions: what counts as sufficient evidence for each gate, and whether the agent repeats the same decision consistently. These are exactly the two things the paper’s evaluation measures.

Factory’s case study on ZenML describes the same shift: FDEs there do not do professional services, but move from operating software directly to maintaining and managing the system that produces software.

For a developer who wants to move into this role, the skill worth practising is not prompting. Take an internal workflow with an approval step, measure the same-day approval rate and modification rate over a month, then write the trigger conditions as policy code rather than instructions.

On a CV, a line such as “removed three rubber-stamp gates and kept two high-risk gates, with data” says more than any agent certification.

The last gate will not disappear. It will simply change keepers: from the person who clicks approve to the person who decides which gates deserve someone clicking.