What problem does the operating model solve?
The Digital FTE operating model solves the problem of running AI that acts on a business's behalf without a person watching every action and without anyone being able to say who decided what. General AI tools multiply a person's output but own nothing; autonomous agents own outcomes but are hard to trust. The model sits between them: a worker that owns a function, proposes rather than acts, and reports to a named manager.
It is the model ftes.ai is built on, and this whitepaper describes it in full: the role, the workspace, the approval gate and autonomy ladder, the memory, the economics, and the management cadence. Each part is a mechanism in the product rather than a principle, and each is described as it works. No statistics are cited, because none are needed to describe a mechanism, and none are invented.
How is a Digital FTE defined as a role?
A Digital FTE is defined by a remit: what it owns, what it escalates, and what it never does. It owns a job function, such as search visibility for a website, reconciliation for a ledger, first-line resolution for a helpdesk, or screening for a talent pipeline, inside the systems the organization already runs, through scoped connections. It escalates a fixed list of categories to a person regardless of confidence. And it never performs a fixed list of actions, such as anything that changes a person's employment outcome, at any autonomy level.
The remit is written at hiring, in a first-run wizard that pre-fills everything the platform already knows and asks only for what is new to the function, and it is refined from the approval record. The role's accountability is expressed as targets: an explicit contract, per item, with a status and evidence, proposed by the FTE and approved by the manager. A role is the same platform mechanism with a different remit; a Finance Controller FTE and a Recruiter FTE differ in what they own, not in how they are governed.
What is the workspace and why does its shape matter?
The workspace is where a manager reviews a Digital FTE as a direct report. It has a sticky identity header showing the role, its status, a strip of key measures, and the count of items waiting on the manager, over a fixed set of tabs: Today, with the morning brief; Approvals, with every human checkpoint and its evidence; Pipeline, with work in progress by stage; Library, with the portfolio the role owns; Targets, with the accountability contract; Performance, with honest measurement and a monthly review; Missions, for bounded pushes; Memory, the Brand Brain; and Setup, with model tier, budget, autonomy, and integrations.
The shape matters because it encodes the relationship. The FTE reports in the first person; the manager reviews, approves, and decides. Waiting-on-you items come first because they block the work. Evidence is attached to every claim because trust is verified rather than assumed. If the platform cannot measure something, the workspace does not show it. A role may rename or drop a tab with a reason, but the standard is that every Digital FTE gets a manager-grade workspace rather than a tool interface.
How do the approval gate and the autonomy ladder govern action?
The approval gate is the mechanism by which every action a Digital FTE wants to take is a proposal that waits for a named person. Nothing publishes, sends, posts, or spends without approval until that specific class of action has been promoted. Each proposal carries its evidence: the documents behind a match, the sources behind a draft with its fact-gate result, the scorecard behind a ranking, the article behind a reply. The approver approves, edits, or sends back with a reason, and the decision is logged with their name.
The autonomy ladder is the mechanism by which trust is granted per class of action from the approval record. Every FTE starts at Level 0, everything gated. When a class such as exact-match reconciliations or interview scheduling shows a long run of unchanged approvals, the manager may promote it to auto-approve, leaving every other class gated. Promotion is logged, reversible with one change, and never available for the always-escalate list or the never-automated list. The two mechanisms together mean accountability always sits with a named person: the approver for gated actions, the person who granted autonomy for promoted ones.
How does memory work and why is provenance the key?
Memory is the Brand Brain: everything the Digital FTE knows about the business it works for, in the Memory tab, with every item showing its provenance. Items come from onboarding, from documents the manager provides, from connected systems, or from patterns the FTE inferred from approvals, and each is labelled accordingly. The manager reviews it fully at hiring, corrects items as proposals reveal errors, and confirms it quarterly when the workspace prompts.
Provenance is the key because it makes memory checkable. An inferred rule can be confirmed or replaced with an explicit one; a fact from a document can be traced; a wrong item can be found and fixed, and the fix propagates to every FTE working on that property. Memory is per property, so an FTE managing two websites holds two, and it is shared across roles on the same property, so a correction is made once. Nothing the FTE believes is hidden from the manager, which is the difference between a memory and a black box.
What are the economics of the model?
The economics are metered work from one organization wallet. A plan buys a block of tokens; every Digital FTE the organization hires draws from the same wallet; there is no per-seat or per-role charge. Drafting, fact-checking, measuring, briefing, running missions, and proposing consume tokens; reading the workspace and approving proposals do not. Usage is reported per FTE, so cost per outcome can be computed per role from tokens consumed divided by outcomes in Targets.
Spend is governed by four controls: the wallet, per-FTE and per-mission budgets inside it, a hard stop that pauses every FTE when the wallet is empty so nothing runs on credit, and spend visible against budget in the morning brief. Model tier is chosen per FTE with honest labels for cost and capability, and organizations with their own provider agreements can bring their own key, which changes who is billed for model usage and whose provider terms apply, and nothing else. The result is a budget line with a hard ceiling that follows the work, compared on cost per outcome rather than cost per seat.
What is the management cadence?
The management cadence is daily, monthly, and quarterly. Daily, the manager reads the morning brief in about five minutes: what is waiting on them, what happened yesterday against targets with misses stated, what the FTE detected, and spend against budget; then approves, edits, or sends back with reasons. Monthly, the manager reads the FTE's first-person performance report, checks targets against evidence, reads the send-back reasons grouped by category, looks at cost per outcome, and decides three things: whether the targets are right, whether the remit needs changing, and whether any class should move on the autonomy ladder. Quarterly, the manager confirms the Brand Brain and reviews connections.
Each decision is recorded with its evidence. Over a year, the record shows how the delegation matured, and it is what a successor manager inherits. Stepping autonomy back is a normal part of the cadence, triggered by a send-back in a promoted class, a change in inputs, an incident, or a change of manager, and a class earns its way back the same way it was promoted. The cadence is ordinary management practice applied to a worker whose every action leaves a record.
How do the parts fit together on a bad day?
On a bad day, when something a Digital FTE did should not have happened, the model's parts fit together as an incident response: stop, by stepping the class back or pausing the FTE, one logged action; trace, by reading the audit trail for the proposal, its evidence, who approved or whether it was auto-approved, when, and what effect it had; fix, by correcting the cause in the remit, the connection, the source, or the autonomy grant; and record, by logging what happened and what changed.
Every step is a workspace action or a reading of a record that already exists. The credentials can be revoked from one place; the wallet bounds the maximum that could have been spent; the trail shows who decided. The test of an operating model is whether it holds under pressure without anyone having to reconstruct events from memory, and this one is designed so that the record is built as the work happens rather than written afterwards.
What does the model claim and not claim?
The model claims that an AI employee can be run as an accountable direct report: that its actions can be gated, its evidence shown, its autonomy earned and revoked, its memory inspected, its cost bounded, and its performance reviewed honestly, all through mechanisms rather than policy. It claims that the same mechanisms serve every role, and that a manager who has run one Digital FTE can run the next from the first morning.
It does not claim that AI employees replace people. Judgement, relationships, and every decision about a person remain human, by design and permanently. It does not claim to be free of error; the approval gate and fact gate exist because models are confidently wrong sometimes. It does not claim certifications it does not hold or results it has not measured. What it offers is a way of working with AI that a finance leader, a security reviewer, and a manager can each examine and find to be what it says. That is the operating model, and the rest of the ftes.ai library describes each part in depth.
How do you apply the model in 30 days?
Apply the model in 30 days with one role and a written record. In week one, choose the function with the clearest evidence and the longest likely approval history, such as reconciliation, scheduling, or first-line support; record its baseline from two weeks of the team's time; run the first-run wizard to write the remit, the always-escalate list, and the targets; connect the tools with scoped credentials; and review the Brand Brain in full. In week two, read the morning brief daily, approve or send back with reasons, and route routine categories to the team member closest to the work.
In week three, read the send-back reasons grouped by category and make the remit rules they point to, and correct any Brand Brain item a proposal revealed as wrong. In week four, hold the first monthly review from the Digital FTE's own report: check targets against evidence, read usage and cost per outcome, decide whether any single class has a record clean enough to promote, and write the decisions down with the date. By day 30 the organization has a role with a remit, a manager, a record, and a first governance decision, which is the operating model in miniature and the foundation every later role inherits.
What objections does the model meet, and what are the honest answers?
The first objection is that the approval gate makes the manager a bottleneck. The honest answer is that it does in the first weeks, deliberately, and that the cost falls as routine categories are routed to team members and promoted from a clean record; a gate whose cost never falls is one nobody has managed. The second is that a model can still be wrong. The honest answer is yes, which is why the fact gate blocks unsourced claims, every proposal carries evidence, and the always-escalate and never-automated lists keep the highest-stakes decisions human at every level.
The third is that metered pricing is unpredictable. The honest answer is the wallet: the maximum exposure in any period is the block already purchased, budgets bound spend inside it, and an empty wallet pauses work rather than running on credit. The fourth is that the organization will become dependent on a vendor. The honest answer is that the audit trail, the confirmed memory, and the targets record are the organization's, credentials can be revoked from one place, data deletion can be requested, and a bring-your-own key puts model usage on the organization's own agreement. None of these answers claims the objection is baseless; each names the mechanism that addresses it.