Contextual Agentic

Lab

What Will AI Agents Cost Us? A Business Case Calculator

Start with your headcount, finish with a defensible number. Cost per successful outcome — and why people, not tokens, usually dominate the bill.

Runs in the browserIntermediate

25 minutes with your own numbers; five minutes to see the shape·Chapter 17 — Evaluation, reliability, observability and replay; Chapter 20 — The enterprise model portfolio

What actually operates

These controls run for real. They are the point.

  • Demand from headcount — People times adoption times tasks per person per day. Adoption is separated out on purpose, because licences bought is not people using it, and that single factor moves the answer more than most price differences.
  • Token volume per attempt — The prompt grows as each step appends the last result, so every step is charged its own prompt rather than the first one's. Cached input is counted separately from fresh input.
  • Reliability compounding — A step that succeeds p of the time succeeds p to the power of n over n steps. Retries are modelled as expected attempts under a limit, and whatever fails every attempt becomes an escalation.
  • Availability in series — The model endpoint, the gateway, the policy decision point and the system of record multiply. Four components at three nines is not three nines, and the composite is shown as minutes lost per month.
  • Cost per successful task — Total monthly spend, including the people who finish what the system could not, divided by tasks that actually succeeded. Cost per token and cost per task both flatter a platform that fails cheaply and often.

What is simulated

Stand-ins. Nothing here touches a real system.

  • Every price — There are no vendor rates in this lab. The fields start empty and the worked example below uses round illustrative figures, clearly marked, so the shape is visible before you have your own quotes.
  • Step success rate — The default of 98% is a placeholder to make the arithmetic visible. It is not a measurement of any model, and using it as one would be the single biggest error you could make on this page.
  • Availability figures — Placeholders, not published commitments. Replace each with your own contracted or measured number.
  • The platform rows — Deployment routes, not suppliers. Which vendor sits behind a chosen shape is decided on residency, commitments and support, which this page cannot see.
  • People costs — Minutes per escalation and the loaded hourly rate are yours. The defaults are round numbers chosen to be obviously round.
Boundaries
  • This is a teaching model of a decision, not a prediction of your costs. It is educational material only.
  • It is not financial, procurement, legal or professional advice, and it is not a substitute for a quote or a business case your finance function has reviewed.
  • No figure here is a vendor price, a benchmark result or a service-level commitment. Nothing on this page ranks or endorses any supplier.
  • Numbers produced here should not be quoted to a board, a supplier or a customer as an estimate of anything. Use them to find which question to ask next.

Cost it against your own rates

Pick a size and a route, type in the rates you have actually been quoted, and see what a month costs — and how much of it exists only because the system is not reliable.

Nothing you type leaves this page. The calculator runs entirely in your browser: no rate, no headcount and no result is sent anywhere, stored on a server or logged. The only copy kept is in your own browser until you clear it.

The Boundaries stated above apply to every number this produces. The five routes are shapes of commercial arrangement, not products, and no supplier is ranked or endorsed.

The arithmetic behind the answer

One tested module produces every figure: demand from headcount, tokens per attempt, reliability compounded over steps, availability composed along the chain, the deterministic shell priced beside the model it wraps, and the people who finish what the system could not. Cost per successful task is the only figure worth comparing — cost per task and cost per token both reward a platform that fails cheaply and often.

Most AI cost calculators multiply tokens by a price. That number is real, and it is almost never the number that decides anything. This one starts from your headcount, models what fails, and reports the only figure that settles an argument: what one successful task costs.

How to use this, in order 1. **Pick the size nearest your organisation.** It sets headcount, adoption and tasks per person per day. Adoption is people actually using it, not licences bought. 2. **Enter a loaded hourly rate.** Salary plus on-costs divided by productive hours. Your finance team has this number, and one rate runs through the whole page. 3. **Pick a route and enter your own quoted rates.** The page ships no prices. Until you enter them it will not produce a number. 4. **Set steps per task and the step success rate.** Measure the success rate on fifty to a hundred of your own real tasks. A benchmark score is not a success rate. 5. **Read the headline.** Cost per successful task, and who is paying it. If the people share is large, reliability is your lever, not the token price. 6. **Open "Does it pay?"** Enter the minutes a person spends on one task today. Time a sample of real tasks; do not estimate from memory. Add the one-off build cost if you have it. 7. **Read the break-even step success.** That is the pass mark for a pilot. 8. **Change one thing at a time.** The sensitivity table shows which lever is worth pulling first.
How demand is worked out from headcount A request rate is a guess wearing a decimal point. Headcount is not: > people × adoption × tasks per person per day → tasks per month Adoption is the term that gets dropped, and it moves the answer more than most price differences. Four hundred people at 45% adoption doing six tasks a day is 22,680 tasks a month — not 50,400.
Why reliability, not price, drives the bill A step that works 98% of the time is not a task that works 98% of the time. | Steps in the task | First pass | After 2 attempts | Escalations a month | |---|---|---|---| | 1 | 98.0% | 100.0% | 9 | | 3 | 94.1% | 99.7% | 78 | | 5 | 90.4% | 99.1% | 209 | | 9 | 83.4% | 97.2% | 627 | | 12 | 78.5% | 95.4% | 1,051 | | 15 | 73.9% | 93.2% | 1,550 | | 20 | 66.8% | 89.0% | 2,506 | *No prices are involved in that table.* Ten times the steps buys eighty-four times the escalations. This is the one-to-five trap as arithmetic: adding agents multiplies steps, and reliability compounds against every one of them.
Where a month's money actually goes The figures below are **illustrative** — round numbers at an invented rate, shown so the shape is visible before you have your own quotes. Replace every one of them. | | Monthly | |---|---| | Model tokens | $4,532 | | The deterministic shell | **$0.00** — 0.000% of the model spend | | People finishing what failed (627 escalations) | **$31,833** | | **Total** | **$36,365** | | Cost per task | $1.60 | | **Cost per successful task** | **$1.65** | | Chain availability | 99.750% — 109 minutes down a month | **The people cost seven times the tokens.** Eighty-nine per cent of that bill exists only because the system is not reliable. Every token-price comparison optimises the small number.
What actually changes the answer | Change one thing | Cost per successful task | Change | |---|---|---| | One point **better** per step | $1.04 | **−37%** | | One point **worse** per step | $2.60 | **+58%** | | Two more steps per task | $2.09 | +27% | | Half the prompt tokens | $1.62 | −1.8% | One percentage point of step reliability is worth roughly **twenty times** more than halving your prompt. Prompt compression is the optimisation everyone reaches for first and it is, at this scale, almost noise.
From cost per task to ROI and a project outcome **What the page works out.** Every task gets finished one way or the other: the system completes it, or it escalates and a person does. So the fair comparison is simple. > net a month = what the same tasks cost today − what this route costs all in > > return = net ÷ what it costs to run · payback = one-off cost ÷ net a month Cost per successful task is a stricter yardstick, because it divides by fewer tasks. Use it to compare routes with each other. Use the net figure to decide whether to do the project at all. **Which lever to pull first.** Use the sensitivity table, but expect this order: 1. **Step reliability.** One point per step is worth roughly twenty times halving the prompt. Fix the weakest step: tighten the tool contract, add the missing context, put an evaluation set behind it. 2. **Minutes per escalation.** Hand the person the evidence and the proposed action, not a blank ticket. Cutting a failed task from eighteen minutes to ten changes the largest line on the bill. 3. **Steps per task.** Every step compounds against you. Remove steps before adding agents. 4. **The route.** Compare routes on cost per successful task, with your own measured success rate for each. 5. **Adoption.** It scales net benefit only if each task already saves money. Pushing adoption on a route that loses money per task loses more money. 6. **Prompt size.** Last. It is the first thing everyone optimises and, at this scale, almost noise. **From the number to a project outcome.** Do not promise the headline saving. Promise a pass mark you can measure: > On *N* real tasks over *W* weeks, steps succeed at least *X*% of the time, no more than *Y*% need a person, and cost per task stays under *Z*. *X* is the break-even step success from this page. Fund the pilot against that sentence, give it one named owner, and expand only when it is met. If the pilot misses, the page tells you what each missing point costs. **Four ways this goes wrong.** - **Freed hours are not cash.** They are capacity. They become savings only if spend elsewhere (overtime, contractors, hiring) actually falls. - **A baseline from memory.** Someone remembers a task taking thirty minutes. Time twenty of them. - **Counting licences as users.** Adoption moves the answer more than most price differences. - **Leaving out the running costs.** Evaluation, monitoring and maintenance recur. Put them in the capacity or per-seat field, not in your head.
The five routes, and what each costs on a quiet week Five deployment routes, each with a different **cost shape** — what you pay when the work does not arrive, and what you pay when it does: | Route | Shape | What you pay on a quiet week | |---|---|---| | Frontier model, called directly | per-token | nothing | | Frontier model through a cloud platform | per-token plus platform | the platform and seat charges | | Open-weight model, serverless endpoint | per-token | nothing | | Open-weight model, self-hosted | capacity | all of it | | Small model, fine-tuned for the task | capacity or per-token | depends how you bought it | **The rows are routes, not suppliers, and the cells start empty.** Published rates change without notice; a calculator that quotes a stale one is wrong with a decimal point. You enter your own quotes, so the ranking is of *your* numbers. Which vendor sits behind a chosen shape is decided on residency, existing commitments and support — things this page cannot see. For the self-hosted row, size the cluster in [Open-weight economics](/labs/open-weight-economics/) first and bring the monthly capacity figure across.
The trap this lab exists to show A route with **half the token price and two points worse per step** is cheaper per token and more expensive per outcome. That is not a hypothetical; it is a test in the model, and it fails the build if it ever stops being true. So when you compare, compare cost per successful task. Everything else rewards whichever platform fails quietly.
Read this before you quote any of it The boundaries stated at the top of this lab apply to every figure here. Beyond them, one thing is worth repeating because it is the single largest error available on this page: the field that decides the answer — your step success rate — is a measurement you have to take in your own system on your own tasks. A benchmark score is not that measurement, and substituting one will change the answer by more than any price you enter.