Unit economics for an agentic product should be modeled as cost per completed task, built from a formula with your own measured variables — not benchmarked against a published industry figure, which will not reflect your specific task complexity, model choice, or failure rate. The formula, not any single number it produces, is the reusable artifact for planning and pricing.
Why Agentic Products Have Different Unit Economics Than Traditional SaaS
Traditional SaaS unit economics are relatively stable: the marginal cost of serving one more customer on a fixed-infrastructure product is small and largely decoupled from how intensively that customer uses the product. Agentic products break that assumption. The cost of serving a customer scales with usage intensity — how many tasks they run, how complex each task is, how many tool calls and model turns it takes to complete, and how often it needs to retry after a failure.
This means two customers on the same subscription tier can have dramatically different cost-to-serve, purely based on how they use the product — one running short, simple tasks and one running long, multi-step workflows with heavy tool use. A unit economics model that doesn't account for this variance risks a pricing structure where your most usage-intensive customers are effectively subsidized by your least intensive ones, with margin looking healthy in aggregate while individual accounts are unprofitable.
Building the Cost-Per-Task Formula
Rather than starting from a target margin and working backward, start from the cost drivers and build up:
Cost per task = (model cost per task) + (tool call cost per task) + (retry cost per task) + (allocated platform overhead per task)
Each term should be its own sub-formula built from variables you can actually measure:
- Model cost per task = (average tokens consumed per task, input and output separately) × (rate per token for the model or models used). If the product routes across models, this needs to be a weighted average across the routing distribution, not a single model's rate.
- Tool call cost per task = (average tool calls per task) × (average cost per tool call, which varies by tool — a search call and a code execution call are rarely priced the same).
- Retry cost per task = (retry rate) × (average cost of a retried attempt). A task that fails and retries twice before succeeding costs roughly three times the cost of a single successful attempt — model this explicitly rather than assuming every task succeeds on the first try.
- Allocated platform overhead per task = (total platform and tooling cost for the period) ÷ (total tasks in the period). This spreads fixed costs across task volume, which means overhead per task falls as volume grows — a relevant dynamic for early-stage products with low task counts.
See FinOps for AI Agents: Controlling Token and Tool Costs for the attribution discipline that makes these variables measurable in production rather than estimated once and left stale, and Model Routing: Cost and Quality Tradeoffs for how routing decisions feed directly into the model cost term.
Margin as a Function of Task Mix, Not Just Price
Once you have cost per task, margin per task is straightforward: (price or allocated revenue per task) − (cost per task). But the more useful analysis is margin sensitivity — how much margin moves as the underlying drivers shift.
Consider each driver as a lever and ask what happens to margin if it moves:
| Driver | What moves it | Effect on cost per task |
|---|---|---|
| Model choice | Routing more tasks to a larger, more capable model | Increases model cost per task |
| Task complexity | An increase in average turns or tool calls per task | Increases both model and tool call cost |
| Retry rate | A degradation in first-attempt success rate | Increases retry cost, potentially compounding |
| Context length | Longer conversation or document context per task | Increases token consumption per task, often non-linearly |
| Task volume | Growth in total tasks per period | Decreases allocated overhead per task (fixed costs spread further) |
A unit economics model that only reports current margin misses the point. The value is in rerunning the model against a worse-case scenario for each driver — what does margin look like if retry rate rises, if a model price changes, if task complexity creeps up as customers find new use cases for the product. Planning against the sensitivity range is more useful than planning against the point estimate under today's conditions.
A Worked Illustrative Example
The following uses made-up numbers purely to demonstrate how the formula composes — treat no figure here as representative of any real product.
Suppose a task averages T input-plus-output tokens at blended model rate R, makes an average of K tool calls at average cost per call A, has a retry rate of X (meaning a fraction X of tasks require one additional attempt), and platform overhead allocates to a per-task figure of H.
Cost per task ≈ (T × R) + (K × A) + (X × (T × R + K × A)) + H
If your priced or allocated revenue per task is P, margin per task is P − [that cost]. The exercise worth running is not computing this once, but recomputing it under a stress scenario: what if X doubles because a model update degrades first-attempt accuracy, or what if T grows because customers start feeding the product longer documents. The formula tells you which term to watch.
Pricing Implications
If cost per task varies materially across customer segments — because of task complexity or usage pattern differences — a flat per-seat or flat per-task price risks systematically mispricing the product. Two common responses, in increasing order of pricing sophistication:
- Segment-level pricing — different price tiers for customer segments with materially different measured cost-to-serve, based on observed usage patterns rather than assumed ones.
- Usage-based pricing components — a base fee plus a metered component tied to the actual cost drivers (tasks, tokens, tool calls), which lets price track cost more directly than a flat fee can.
Neither eliminates the need for the underlying cost model — usage-based pricing still requires you to know your cost per unit of the metric you're charging for, or you'll set a rate that doesn't protect margin. See Spend Attribution Per Agent and Showback for the internal-facing version of this same attribution problem, applied to allocating agent costs across internal teams rather than pricing them to external customers.
Common Questions
How often should the unit economics model be recalculated?
Whenever a material input changes: a model swap or price change, a shift in the customer base's usage pattern, or a product change that alters average task complexity (a new capability that increases tool calls per task, for instance). Treat it the same way you'd treat a financial model tied to a volatile input — rerun it on a defined cadence and immediately after any known driver change, not just annually.
Should retry cost be modeled as a bug to fix or a permanent cost line?
Both, at different time horizons. In the model, it's a cost line, because retries happen even in a well-tuned system. Operationally, a rising retry rate is a signal to investigate — is the increase driven by task complexity growth, a model regression, or an upstream integration issue — because retry cost compounds and is usually the most fixable driver in the formula.
Does this apply the same way to an internal agent deployment as to an externally sold agentic product?
The formula structure is the same, but the "price" side differs. For an internal deployment, the relevant comparison is cost per task against the outcome value the task produces — see Measuring the ROI of AI Agents for how to define that outcome value. For an externally priced product, the price side is what you charge, and margin is the direct commercial question.
What Good Looks Like
- Cost per task is modeled as a formula with measured variables, not copied from a published figure.
- Margin sensitivity is analyzed against stress scenarios for each cost driver, not just reported as a current-state point estimate.
- Pricing accounts for measured variance in cost-to-serve across customer segments rather than assuming uniform cost.
- The model is rerun whenever a material driver changes, not left static after initial construction.
- Retry rate and task complexity are tracked as operational metrics that feed directly back into the cost model.