What exactly is an approval gate?
An approval gate is a control that holds a proposed AI action until a person decides whether it happens. The distinction that matters is between holding and notifying: a gate blocks the action, while an alert merely tells you about an action that already happened.
On ftes.ai the gate sits on everything that leaves the company. A Digital FTE can research, draft, analyse, and plan freely inside its remit, but publishing an article, sending a message, or spending budget waits in an approvals queue until a manager approves it.
Why does a gate make broad scope safer than narrow scope?
An approval gate makes a broad remit safer than a narrow one without a gate, which is counter-intuitive until you look at the blast radius. Without a gate, the only safe scope is trivial, because every mistake lands directly on a customer, a ledger, or a budget.
With a gate, the worst outcome of an ambitious proposal is a rejected proposal. That changes the calculation entirely: you can let the system attempt genuinely useful work, because the failure mode is wasted compute and a send-back rather than a published error or an unwanted charge.
What has to be inside a gate for it to work?
A working approval gate presents four things: the proposed action, the reasoning behind it, the evidence supporting that reasoning, and a preview of exactly what will happen. Remove the preview and you are asking someone to sign for something they have not seen.
For an article that means the piece rendered as it will publish, with its sources. For a payment it means the amount, the recipient, and the matched documents. For an advertisement it means the creative, the audience, and the daily cap. The rule is that the approval screen should contain everything a reasonable reviewer needs to say no for a specific reason.
- The action, stated plainly and specifically
- The reasoning: why the system believes this is the right action now
- The evidence: sources, matched records, or measurements behind the reasoning
- A true preview of the result, not a description of it
How do you keep gates from becoming rubber stamps?
Gates become rubber stamps when every action carries the same weight, so the fix is to tier them by risk. A reply drafted in an approved house style and a first payment to a new vendor should not arrive in the same queue with the same urgency.
Tiering concentrates attention where judgement changes the outcome. Low-risk, high-volume, repeatedly approved actions can be promoted to run automatically inside explicit limits. Novel, outward-facing, or expensive actions keep their gate permanently. The measure of a healthy system is that send-backs still happen and carry specific reasons.
Who should hold the gate?
The person at the gate should be whoever is accountable for the outcome, not whoever is most available. Routing approvals by availability produces quick decisions from people who do not carry the consequence, which quietly dissolves the control while leaving its appearance intact.
In practice the function owner holds content and operational gates, the budget holder holds financial ones, and anything affecting an individual — a rejection, an offer, a refund outside policy — goes to someone with the authority to make that call. The audit trail then records that person by name, which is what makes the decision defensible months later.
When should a gate be removed?
A gate should be removed for a class of action only after that class has been approved repeatedly without amendment, and only within limits that are written down. The evidence for removal is the approval history itself: if the last several dozen instances were approved unchanged, the system has learned the standard for that specific class.
Removal should be narrow and reversible. Promote one class of action, keep the limits explicit, and keep the audit trail. The ability to step autonomy back down matters as much as the ability to grant it, because circumstances change and a control you cannot reinstate is not really a control.
What does an approval gate look like in the ftes.ai workspace?
In the ftes.ai workspace the approval gate is the Approvals tab: every proposal a Digital FTE has made and not yet had decided, each with its evidence attached. A proposed reconciliation match shows the bank line, the invoice, and the fee schedule that explains any difference. A proposed page shows its sources and the fact-gate result. A candidate shortlist shows the scorecard and the evidence per score. An escalated ticket shows what was asked, what was found, and a suggested next step.
The manager approves, edits, or sends back with a reason, and each decision is logged with their name and the time. The count of waiting items sits in the workspace header and at the top of the morning brief, because unapproved proposals block the work. A gate that lived in an email thread or a chat channel would have none of this: no evidence attached, no reason recorded, no count of what is waiting. The tab is the gate made visible, which is what lets a manager keep it without it becoming the bottleneck.