The Hidden Costs of Probabilistic Autonomy
When deploying AI agents in production, we often treat unexpected costs as a monolithic problem. We see higher token bills, increased latency, or more human interventions. We lump them under "AI is expensive." But when using agents in business workflows, these costs stem from two different sources. They come from the messy design choices we make during development and the inherent unpredictability of the models themselves.
To manage these systems, we must distinguish between "Agentic Technical Debt"—the accumulated liability from rushed design—and "Stochastic Tax"—the recurring cost of managing non-deterministic (unpredictable) behavior. This paper proposes a formal framework to decouple these two. It allows engineers to see if a rising bill is a signal to refactor code or a side effect of scaling usage.
The Question
How can an organization precisely measure, simulate, and budget for the disparate costs of system complexity versus system randomness? The research seeks to move beyond vague concerns about "AI overhead." It aims for a structured model that differentiates between remediable engineering failures and the unavoidable operating burdens of probabilistic reasoning. The goal is a "dashboard-ready" decomposition of costs. This enables a team to determine if a spike in expenditure is caused by accumulating design debt or by shifts in the operating environment, such as increased adoption or higher model variability.
Why The Old Answer Was Incomplete
Historically, the industry has relied on the "technical debt" metaphor. This describes how shortcuts accelerate delivery while increasing future maintenance. While this worked for deterministic (predictable) software, it failed to account for agentic AI. In traditional systems, a bug is usually reproducible. In agentic systems, the "bug" might be a probabilistic deviation in a multi-step reasoning chain.
Practitioners often conflate all operational overhead with either bad engineering or model inaccuracy. This leads to misdirected remediation. Teams might spend weeks refactoring prompts to solve a cost problem actually driven by increased user adoption or model drift. There was no formal way to express that even a "perfectly" engineered agent incurs a cost simply because it is stochastic. As the authors note, the old view lacks a way to separate the "principal" of accumulated design liability from the "flow" of recurring operating taxes.
What They Did
The researchers developed a mathematical framework to model these two phenomena as a "stock" and a "flow." They define Agentic Technical Debt as a stock. This is a cumulative liability residing in areas like prompt versioning, tool schemas, and memory management. To model its evolution, they introduced a recurrence relation [Equation 2]. This accounts for local change pressure, shortcut intensity, and platform volatility.
To address the flow, they modeled Stochastic Tax as a recurring burden. This burden comprises eight distinct cost categories. These include retries, escalations, and token processing. Crucially, they did not treat this tax as a flat rate. They built an "operating-exposure amplifier" [Equation 11]. This is an exponential function that scales the tax based on variables like adoption, surface area (the number of tools), and autonomy (the criticality of the agent's actions).
The authors validated the framework using a numerical illustration. They used a hypothetical accounts-payable agent. They ran four comparative scenarios crossing low/high adoption with low/high debt [Table 7]. They also performed a sensitivity sweep. This isolated the impact of the debt index on per-transaction costs .
What They Found
The simulation reveals that the distinction between debt and tax has massive implications for unit economics. The authors report that scaling an agentic system can reduce the per-transaction stochastic tax. This happens by amortizing (spreading out) fixed costs like monitoring and evaluation .
However, accumulated debt acts as a drag on these economies of scale.
Specifically, the study found that scaling a low-debt system reduces per-transaction tax significantly. In their accounts-payable example, scaling from low to high adoption in a low-debt environment reduced the tax from \$1.81 to \$0.75 per transaction. In a high-debt environment, that same scaling only brought the tax down to \$1.08 [Table 8]. This delta represents the efficiency lost to technical debt.
Furthermore, the authors demonstrate that a "nonzero baseline" exists .
Even when Agentic Technical Debt is zero, the Stochastic Tax remains positive. This is because the system is inherently probabilistic. Finally, they show that debt behaves as a multiplier. At a high-adoption operating point, moving from zero debt to maximum debt nearly doubles the per-transaction stochastic tax .
What This Changes
If this framework is adopted, the conversation around AI ROI shifts. We move from asking "Is this agent profitable?" to "Are we losing margin to debt or to scale?"
First, it changes how we prioritize engineering sprints. Instead of treating all "AI issues" as equal, teams can use the decomposition to decide on investments. They can choose to refactor (to reduce the debt principal) or improve observability (to manage the stochastic flow). If the tax is rising but the debt index is flat, the problem is likely scale or model drift.
Second, it provides a realistic roadmap for budgeting. The model separates the "baseline tax" from the "debt-amplified tax." This helps CFOs set accurate expectations for scaling costs. They can anticipate that while total costs will rise with adoption, the per-unit cost should trend downward if debt is managed.
Finally, it highlights a new category of risk: "platform-driven debt." The model incorporates platform volatility. This means an upstream change to a model provider's API can increase technical debt instantly. This happens even if internal code remains unchanged.
The immediate next step for any team shipping agents is to implement the "first-cut" measurement rules. Start by logging token usage, retry counts, and escalation rates. Map these to actual dollar amounts. Once you have raw data, you can begin calibrating your own $\beta$ (debt sensitivity) coefficients.