Allocation is not benefit: how to account for work when AI agents join it

When an AI agent takes on part of someone’s work, the first question is usually “how much work did it take?” The second is “so what did we gain?” Most business cases answer the second by arithmetic on the first: the agent does 20% of the work, so we save 20% of the cost, or gain 20% of the capacity. That arithmetic is where agentic business cases go wrong. Accounting for work offsets properly means keeping several quantities apart that are easy to collapse into one.

Labor is not capacity

FTE is a labor-input measure. It says how much human effort is required — 1.0 FTE is 40 hours a week — not how much work gets done. A person at 1.0 FTE might handle 100 cases a week; that is their service capacity, and it is measured in units over time. When an agent takes over part of someone’s work, the hours they no longer spend on it are released human capacity. Work can move the other way too, or between agents: when a faster agent takes over work another agent was doing, the capacity released is digital, not labor, and it has no payroll effect — it matters only if the freed agent can serve other work or is paid per unit.

Agents have execution capacity, not FTE

FTE is a unit of paid human time. An agent is a production resource with a different cost function, reliability curve and constraint profile. Putting both in FTE is how you get “1.3 FTE of AI” and a plan that cannot be staffed, budgeted or operated. An agent has digital execution capacity: work delivered over time, say 300 cases a week. It has an operating cost, per unit or per period. It joins the work as a participant and takes a share of it.

Any total that adds people and agents together belongs in units of work, never in FTE. A person at 100 cases a week and an agent at 300 make a station with 400 cases a week of theoretical capacity — not 4 FTE, 1.3 FTE or any other hybrid number. And even that 400 is theoretical: it adds up only if this station is the constraint and the extra work can leave it.

Separate the quantities

Each line represents a different quantity. None should be inferred mechanically from another. They are related — released capacity follows from a change in allocation, station capacity from the participants and the design of the work, throughput from demand and the bottleneck — but each has to be worked out on its own terms.

Substitution and augmentation move different things

Take one case: an agent takes over five hours a week of a person’s work.

• Substitution. The agent takes on work the person owned — a whole task end to end, or part of one; which is a design choice. A claims handler working 40 hours a week hands the agent the 8 hours of first-pass triage: those hours are no longer required as human labor on that work, and the requirement drops from 40 to 32 hours, 1.0 to 0.8 FTE. The modeled labor cost falls by the displaced amount, subject to the headcount policy the organization sets. The agent brings its own execution capacity, bounded by what it can actually deliver: units per hour, processing time and how many it handles at once.
• Augmentation. The person stays and their salary stays, and the agent opens capacity. Where the station’s limit then sits is a design decision, not a given. If the person stays inline on every unit, each unit takes less of their time, capacity rises, and they remain the limit. If the design moves the person to reviewing, or to handling only the exceptions, the agent carries the flow and the station is bounded by the slower of the agent and the review. Either way, the agent releases five hours of human capacity while contributing its own digital execution capacity — and that capacity has to be realized as something: more throughput when there is demand and no other station binds, otherwise higher quality, fewer errors, shorter cycle time or another effect. Released time is slack until a realization path exists; if none does, the agent ran and the payroll did not move. Augmentation therefore has two sides: what the agent now delivers, and what the person’s freed time is redeployed to.

The benefit is not only throughput

Throughput is often the most visible and easiest benefit to measure and realize. If an agent allows a workflow to process more orders, cases, claims, reviews or transactions with the same people, the effect is easy to see.

But throughput is only one source of value. Agents can also create substantial value by improving the work itself: fewer errors, fewer failures and exceptions, less rework, higher accuracy and quality, shorter cycle times, better service levels, greater consistency, and lower operational or compliance risk. In some workflows these improvements matter more economically than additional volume.

Labor savings are another distinct benefit, and they belong to substitution. When an agent augments, the person stays and so does their salary; the time the agent frees is not a saving but capacity that has to be realized. And the cost side moves too: agents bring operating expense, and they bring new work — someone reviews their output, escalations need handling, and failures need recovering.

Where the accounting is easiest to misuse

• Theoretical capacity is not additive. If review, approval, fulfillment or the customer sit downstream, agent output becomes work in progress. Verification is often the real bottleneck: execution scales, judgment does not.
• An agent’s rate is conditional, not a stock. “300 cases a week” holds under a given mix, exception rate, model and tool reliability, latency and human checkpoints. Change the mix and the number moves. A bursty 8% exception tail can lower the station’s net capacity if handling exceptions is slower than the original human path.
• New human work appears. Review, exception handling, workflow operations, monitoring and governance are not rounding error. Model the residual load after substitution and the new overhead after augmentation. Substitution almost never removes the whole role, because accountability does not transfer with execution.
• Task share is not residual load. Agents usually take the clean slice; people keep the exceptions, the judgment and the regulated sign-off. Moving 20% of the tasks does not move 20% of the difficulty.
• Do not double-count. The same displaced work cannot be booked as both extra throughput and labor savings unless volume actually rose and headcount actually fell or was redeployed.
• Quality is signed. Agents can cut errors and rework. They can also add confident wrong answers, silent misses and new failure modes when the work shifts. Quality, failure and risk are effects that can move either way, not guaranteed upside.
• Keep three ledgers, then translate. Work units delivered; human labor cost, driven by FTE; agent operating cost — inference, tools, orchestration, oversight. If finance needs an “avoided FTE” number, derive it as a labeled scenario from those ledgers rather than entering the agent as FTE in the first place.

Allocation tells you who does the work. It does not tell you the benefit.

Moving 20% of someone’s work to an agent does not automatically mean 20% more throughput, 20% lower cost or 20% better quality. It only establishes who performs the work. Each consequence has to be worked out in turn:

allocation → capacity → throughput → economics → quality and risk effects

Nor does allocation tell you the constraint, or whether the benefit was captured. A benefit that is real but cannot yet be quantified should be recorded as unmeasured, not as zero — and unmeasured is also not a figure that belongs on an ROI slide.

This is the accounting Bot0 is built on: people in FTE and hours, agents in execution capacity, totals in units of work, and labor, capacity, throughput, quality, failure, rework, cycle time, service level, risk and agent operating cost modeled as separate things rather than inferred from who does the work. The failure mode to avoid is treating 300 cases a week as a fixed endowment and unmeasured quality as free value.