Unit Economics: Sensitivity and Roadmap

Security and governance closure established the evidence required before the system can be released. This lesson evaluates the cost of operating the system after release. Evaluate the capstone business case using cost per successful task against explicit quality and operational service level objectives (SLOs). Do not rely on average cost per request from the nominal success path. Define success using the same criteria applied at production acceptance: combine a KPI from the intake brief, such as completion or containment, with quality SLOs such as factuality, policy compliance, and escalation correctness, and operational SLOs such as time to first useful answer.

Price the routing policy and degraded modes that will actually run in production. A task that routes to a smaller model, falls back to a larger model, retries retrieval, invokes tools, and then escalates to human review is not an exception to write off. Treat it as a first-class branch of the system with a measurable rate and a measurable cost. Build the model from controllable levers: token volume, context growth, fallback rates, agent step counts, retry limits, and human review rates. These are architecture decisions you can bound by policy and measure with telemetry and evaluation gates, not unpredictable costs to shrug off.

Cost per successful task as a priced execution policy

Define cost per successful task as the expected cost of running the task policy, divided by the probability that the task meets the success criteria. This framing forces the model to count both spend and yield. An inexpensive path that frequently fails the quality SLO produces a higher cost per successful outcome once retries, fallbacks, or escalations get counted ...