Why is a trust setting the wrong design?
A single trust setting, a slider from supervised to autonomous, is the wrong design for governing an AI employee because it grants or withholds trust for everything at once. An agent trusted to schedule interviews is thereby trusted to send rejections; an agent distrusted for adjustments is thereby distrusted for exact matches. The setting cannot express the fact that trust is specific to a kind of action and to the evidence for that kind.
The autonomy ladder replaces the slider with a per-class structure. Each class of action a Digital FTE can take, such as exact-match reconciliations, first-touch outreach to cold prospects, interview scheduling, or first-line replies in a category, has its own level, its own approval record, and its own promotion decision. That granularity is what allows trust to be granted exactly where it has been earned and nowhere else, and it is the foundation of everything else in this framework.
What are the levels and what does each mean?
Level 0 is the starting point for every Digital FTE and every class: the FTE proposes, a named person approves, and nothing happens without that approval. It is where every role begins and where any class returns when stepped back. The levels above it grant increasing autonomy for a class: auto-approval within tighter bounds first, such as small amounts, protected lists excluded, or specific categories only, then broader auto-approval as the record grows.
The levels are defined per class in the FTE's Setup tab, with the bounds stated explicitly so that a promoted class is auto-approved only within them. A class at a higher level still logs every action with the same detail as a gated one, and its record continues to accumulate, so that the evidence for the next promotion, or for a step back, is always current. The ladder is not a licence; it is a record with permissions attached.
What evidence justifies promotion?
The evidence that justifies promotion is the approval record for the class: a long run of proposals approved without edits, with no send-backs, reviewed at the monthly review by the manager. The length of the run is a judgement the manager makes and records, informed by the stakes of the class; a class whose errors are cheap and reversible needs a shorter run than one whose errors reach a customer.
The evidence is never a vendor's claim, a benchmark, or the FTE's own confidence. It is the manager's own decisions on the FTE's own proposals in the organization's own context. This is what makes promotion defensible: the person granting autonomy can point to the record and say that on this many occasions they approved this class unchanged and would have done so again. The grant is logged with the class, the level, the date, and the grantor's name, and the record it rests on remains in the audit trail.
How does the ladder interact with the approval gate?
The ladder and the approval gate are two views of one mechanism. The gate is the checkpoint every proposal passes through; the ladder decides, per class, whether the checkpoint requires a human or is satisfied automatically within bounds. At Level 0, every proposal waits for a person. At a promoted level, proposals in that class within bounds pass automatically, and proposals outside the bounds, or in any other class, still wait.
The gate never disappears. Even an auto-approved action is a proposal that passed a gate, logged with the evidence it carried and the level that applied, so that a reviewer later can see it was auto-approved under a specific grant rather than approved by a person. This distinction matters for accountability: the approver of a gated action is accountable for that action; the grantor of autonomy is accountable for the auto-approved ones. In both cases a named person, in both cases in the record.
What never climbs the ladder?
Two lists never climb. The always-escalate list is set per role by the manager and contains the categories that reach a person regardless of the FTE's confidence: refunds and billing disputes, account access, complaints, distress, legal or safety language, anything about a specific individual's situation. The never-automated list is fixed by the platform and contains actions that change a person's outcome: rejections, offers, pay, performance, discipline, and their equivalents in other functions such as debt escalation, pricing, and contract terms.
These lists are the floor of the framework. However long a clean run a class shows, a category on the always-escalate list stays gated, and an action on the never-automated list stays a human's. A vendor evaluation should ask for both lists and treat their absence as a finding. On ftes.ai they are visible in each role's remit and in the platform's design, and the audit trail shows that no promotion has ever applied to them.
How does the framework handle stepping back?
Stepping back is a first-class action in the framework, not an exception. A promoted class is stepped back to a lower level, or to Level 0, when it produces a send-back or a caught error, when the inputs it relies on change, when an incident or detection touches it, or when the manager changes and has not seen the record. The action is one change in Setup, effective immediately, logged with who and when.
While stepped back, the class runs gated and its approval record restarts from that point, and the manager finds and fixes the cause: a remit rule, a corrected source, a narrower connection, a memory item. The class earns its way back through the same evidence as before, a long clean run reviewed monthly, and the manager may reasonably require a longer run the second time. Both directions are deliberate, logged, and based on what actually happened, which is the property that makes the framework trustworthy over years rather than weeks.
How does the audit trail complete the framework?
The audit trail completes the framework by making every part of it demonstrable. It records each proposal with its evidence, each decision with its approver and reason, each auto-approval with the level and grant it passed under, each promotion and step-back with the grantor and date, and each effect: what was published, sent, posted, or spent. It also records the management of the FTE itself: budget changes, connection changes, manager changes.
With the trail, a question asked months later has an answer that is a record rather than a reconstruction. This action was auto-approved under a Level 2 grant for exact-match reconciliations made by this person on this date, on a record of this many unchanged approvals; or this action was approved by this person on this date from this evidence. A governance framework that cannot produce that sentence is a policy; one that can is a control. The ladder is designed so that the sentence can always be produced.
What should an organization take from this?
An organization adopting AI employees should take three things from this framework. First, that autonomy should be granted per class of action from the organization's own approval record, never as a blanket setting and never on a vendor's assurance. Second, that some things should never be automated, and the list should be written down, visible, and immune to promotion. Third, that stepping back should be normal, fast, and logged, so that a bad day is a controlled response rather than a scramble.
These are mechanisms on ftes.ai and can be examined in the workspace: the per-class levels in Setup, the always-escalate list in the remit, the never-automated actions in the platform's design, and the audit trail throughout. They are also a reasonable standard to hold any AI employee vendor to, and the vendor evaluation guide in the ftes.ai library lists the questions. The ladder is not the whole of governance, but it is the part that decides whether the rest holds under pressure.
How do you apply the ladder in the first quarter?
Apply the ladder in the first quarter by resisting it for the first month. Every class of action starts at Level 0, and the first month's job is to build a record: the manager approves or sends back with reasons daily, routes routine categories to team members close to the work, and reads the send-back reasons weekly to tune the remit. No class is promoted at the first monthly review unless its record is both long and clean, and the manager writes down the length of clean run the organization will require before any promotion, which becomes the standard.
In the second month, the class with the clearest evidence and the cheapest errors, such as exact-match reconciliations or interview scheduling, is promoted within stated bounds, logged with the grantor's name and the record it rests on, and every other class stays gated. In the third month the promoted class is watched: any send-back steps it back the same day, and a clean run is reviewed again at the monthly review. By the end of the quarter the organization has promoted one or two classes on evidence, stepped back none or one, and has a written promotion standard and a record that shows it being applied, which is the ladder as a governance framework rather than as a feature.
What does a governance reviewer ask, and what does the ladder answer?
A governance reviewer asks who can grant autonomy, and the ladder answers that the named manager can, per class, logged, within bounds stated in Setup. They ask what evidence is required, and the answer is the approval record for that class, reviewed monthly, against a written standard for the length of clean run. They ask what can never be automated, and the answer is two lists they can read: the always-escalate categories in each role's remit and the never-automated actions fixed in the platform's design, neither of which any promotion has ever applied to.
They ask how quickly autonomy can be withdrawn, and the answer is one logged change with immediate effect, by the manager, with the triggers written down. They ask how they would know if the framework had been bypassed, and the answer is that every auto-approved action carries the level and the grant it passed under, so an action approved at a level that had no grant would be visible in the trail. They ask what happens when the manager changes, and the answer is that promoted classes are stepped back and re-earned under the new manager's own record. A framework that answers each of these with a mechanism the reviewer can inspect has passed the review; the ladder is designed to.
What does a labelled example of one class's journey look like?
As a labelled example, follow one class of action, first-touch outreach to cold prospects outside the protected account list, through a quarter under an SDR Digital FTE. In the first month every outreach draft waits in Approvals with the research attached; the sales leader approves most unchanged, sends back a handful for phrasing, and the send-back reasons become two remit rules by week three. At the first monthly review the record shows a run of unchanged approvals but a short one, and the leader declines to promote, writing down the length of clean run the organization will require.
In the second month the run reaches that length and the class is promoted to auto-send within stated bounds: cold prospects only, protected accounts excluded, no reply threads, no named accounts. The grant is logged with the leader's name, the date, and the record. In the third month a detection flags that a prospect on a newly protected account received an outreach because the protected list was updated after the grant; the leader steps the class back the same morning, the list and the bounds are reconciled, and the class runs gated until its record is clean again. Every step is in the trail, and the review note explains each decision in a sentence.