Why do AI employees need their own economics?
AI employees need their own economics because neither of the two familiar models fits. Software is priced per seat because humans operate it, and the value delivered depends on what those humans do, which the vendor cannot see. Salaries are fixed because people are paid for their time, whatever they produce in it. An AI employee does the work itself, on its own cadence, in proportion to what is asked of it, and the honest unit for that is the work.
This whitepaper sets out the economics as they operate on ftes.ai: the pricing unit, the spend controls, the budget line, the cost of ownership, the measures of productivity, the calculation of payback, and the framing of the headcount decision. It uses the platform's own mechanisms as its facts and labelled arithmetic as its examples. It contains no statistics about savings, because any such statistic would be either invented or someone else's, and the model's central claim is that the numbers should come from the organization's own record.
What is the pricing unit and why?
The pricing unit on ftes.ai is a token, the unit in which language models measure the text they read and write, and a plan buys a block of tokens for the whole organization. Every Digital FTE the organization hires draws from that one wallet; there is no per-seat charge for the people who manage them and no per-role charge for the FTEs themselves. Work consumes tokens: drafting, fact-checking, measuring, running missions, writing the morning brief. Using the workspace does not: reading, approving, and changing settings are free, because no model work happens when a human reviews what was already produced.
The unit is work because that is what the buyer receives. It makes a plan comparable to capacity rather than to licences, and it makes the cost of each role visible, because usage is reported per FTE. A finance leader can see what the Finance Controller FTE consumed in a month and set it against what it reconciled; a marketing leader can see what the Search Visibility FTE consumed and set it against what it published and how that ranked. Cost per outcome, per role, is the number the unit is designed to produce.
How is spend bounded?
Spend is bounded by four controls that are features of the pricing model rather than policies layered on it. The wallet is the plan's block, one per organization, topped up only by the plan cycle or an explicit permissioned purchase. Per-FTE budgets set in each role's Setup tab, and per-mission budgets set when a bounded push is launched, bound spend inside the wallet; an FTE that finishes under budget stops. The hard stop pauses every FTE when the wallet is empty, so nothing runs on credit and the maximum exposure in any period is the plan.
Visibility is the fourth control: spend against budget appears in the morning brief every day, with a warning as any limit approaches, and mission spend is shown against the mission budget. External platform spend that a role controls, such as an ad budget managed by a Performance Ads FTE, has its own separate budget and is billed by that platform, not by the plan. Plan changes and top-ups are permissioned to owner and admin roles and logged in the audit trail, so the governance of the AI line meets the standard applied to any other budget line.
What is the total cost of ownership?
The total cost of ownership is the plan plus the human time the worker needs to be managed well. Approval time is the largest recurring component: minutes per proposal while a class is gated, adding up to hours per week for an active role in its early months, falling as the approval rate rises and routine classes are promoted on the autonomy ladder. Setup time is front-loaded in the first month: connecting tools with scoped credentials, writing the remit and escalation rules, confirming the Brand Brain, and reading early proposals closely.
Smaller recurring items are integration upkeep when a tool changes, and governance time each cycle for budget review, autonomy decisions, and reading the FTE's monthly report. Send-backs are the honest measure of editing time: a proposal approved unchanged costs the minutes to read it; one sent back costs the reading, the reason, and the review of the revision. A high send-back rate in a category is a cost signal that usually points to a remit needing tightening. A total cost that omits any of these is incomplete, and the budget planning guide in the library treats each as a line.
How is productivity measured?
Productivity is measured by three things and not by task count, because activity is cheap and a hundred drafts nobody uses is a hundred tasks and no value. The first is outcomes against targets: the explicit contract in the Targets tab, each item with a status and evidence, such as transactions reconciled, tickets resolved at first line, candidates shortlisted and time to shortlist, pages published and their citation presence. The second is approval rate: the share of proposals approved without edits, with send-backs and their reasons, which shows whether the work is right and how much human time it costs.
The third is cost per outcome: tokens consumed by the role over a period divided by the outcomes recorded in Targets over the same period, converted at the plan's rate. As a labelled example, if a role consumed a given number of tokens in a month and delivered a given number of outcomes, the cost per outcome is the first divided by the second; the organization fills in its own numbers from the workspace. Honest reporting includes targets missed and metrics unmeasured; the ftes.ai performance view is built on the rule that if the platform cannot measure it, the UI does not show it.
How is payback calculated without inventing inputs?
Payback is calculated from measured inputs only. Before a pilot, the organization records the baseline: the hours spent on the tasks the Digital FTE will own, by whom and at what cost; the outcomes produced; and the quality measures available, such as days to close or first-line resolution rate. After two full cycles, because the first includes setup, it measures the outcomes in Targets, the tokens per role from usage, the human hours on approval and governance, and the same quality metrics by the same method.
The arithmetic is then labelled and simple. Monthly value equals the baseline cost of the outcomes the FTE now produces, valued conservatively at what they cost before. Monthly cost equals the role's share of the plan from usage plus human hours at their rate. Setup cost equals month-one human hours at their rate. Payback in months equals setup cost divided by monthly value minus monthly cost, once that difference is positive. If it is not positive after two cycles, the role is not paying back on this remit, and the send-back reasons and usage per role are where to look. Every input traces to a record, which is what makes the result something a finance leader can audit and defend.
How should the headcount question be framed?
The headcount question should be framed as an allocation of work rather than a replacement of people, because a role is a bundle of different kinds of work and an AI employee suits some kinds and not others. Judgement, relationships, and every decision about a person stay on the headcount line, and the platform permanently gates them anyway. Repetitive evidence-based work, such as matching, screening against criteria, drafting from sources, monitoring, and reporting, can move to a metered AI line. The usual near-term result is a team redeployed toward judgement rather than a team reduced.
Where a role was going to be added for repetitive work, the AI line can absorb that work instead, and that is the case where it genuinely substitutes for a hire; it should be assessed on the same recorded basis. The comparison framework in the library puts hire, agency, AI employee, and doing nothing on the same five dimensions: cost structure, spending ceiling, ramp, control, and what happens at the end. The AI employee is the only option with a hard ceiling and the only one whose record, memory, and audit trail remain the organization's when the arrangement ends. It is not always the right answer; judgement-heavy work still points to a person. The framework is for finding out which work points where.
What is the model's honest position?
The model's honest position is that the economics of digital labor are favourable where the work is repetitive and evidence-based, uncertain where it is not, and knowable only from the organization's own record. It refuses to publish savings percentages because they would be fiction. It insists on a recorded baseline before any pilot, two full cycles before any conclusion, conservative valuation of outcomes, and a total cost that includes the human time. It provides the mechanisms that make those measurements possible: usage per role, outcomes with evidence in Targets, approval rates with reasons, and a first-person monthly report that states misses and unmeasured items.
A finance leader evaluating AI employees should hold every vendor to the same standard: show me the unit, show me the ceiling, show me the usage per role, show me how I would measure cost per outcome from my own data, and tell me what you cannot measure. Vendors who answer with a savings statistic have not answered. The economics of digital labor are not a promise; they are a method, and the method is what this whitepaper has described. The rest of the ftes.ai economics cluster covers each part in depth.
How do you apply the economics in the first two cycles?
Apply the economics in the first two cycles by recording before you spend. Before the first proposal, take two weeks of the team's time on the function's tasks, sorted by task, with the outcomes produced and the quality measures you have; this is the baseline without which no later number means anything. Choose the smallest plan block that fits one role, because there is no separate trial tier, and set a per-FTE budget inside it. Log the manager's setup hours in week one and approval minutes daily thereafter.
At the end of the first cycle, read usage for the role and the outcomes in Targets, but draw no conclusion, because the cycle included setup and remit tuning. At the end of the second cycle, fill in the labelled arithmetic: monthly value from the baseline cost of the outcomes now produced, valued conservatively; monthly cost from the role's share of the plan plus logged hours; setup cost from month-one hours; payback from the difference. Size the next block from the two cycles' usage. Whether the result is a payback date or a diagnosis, it is a number a finance leader can audit line by line, which is what the economics were for.
What objections does the economic model meet, and what are the honest answers?
The first objection is that metered pricing invites runaway cost. The honest answer is the wallet with its hard stop, per-FTE and per-mission budgets inside it, and daily visibility; the maximum exposure in any period is the block already bought, which is a tighter ceiling than a salary or a retainer offers. The second is that the human time is hidden. The honest answer is that it is not hidden in this model; approval, setup, and governance hours are lines in the total cost of ownership, logged from the first week, and their fall over time is one of the results.
The third is that the vendor will not state a return. The honest answer is that a vendor's return statistic would be either invented or someone else's, and that the model instead gives the mechanisms, usage per role and outcomes with evidence, from which the organization computes its own. The fourth is that this is just replacing people with software. The honest answer is that the work sort decides, that judgement and decisions about people stay human by design, and that the usual result is a redeployed team plus a metered line rather than a smaller team. Each answer is a mechanism or a method, which is the only kind of answer the economics of digital labor should give.