arXiv:2605.27320v1 [cs.AI] 26 May 2026
Modeling Agentic Technical Debt and Stochastic Tax: A Standalone Framework for Measurement, Simulation, and Dashboarding Muhammad Zia Hydari School of Business, University of Pittsburgh Pittsburgh, Pennsylvania, USA [email protected] Raja Iqbal Ejento.ai Seattle, Washington, USA [email protected] Narayan Ramasubbu School of Business, University of Pittsburgh Pittsburgh, Pennsylvania, USA [email protected] Abstract Agentic AI systems combine probabilistic reasoning with delegated action through tools, context, memory, orchestration, and external workflow integration. This note develops a formal and managerially usable model that distinguishes Agentic Technical Debt from Stochastic Tax. Agentic Technical Debt is a stock of accumulated design and governance liability. Stochastic Tax is a recurring flow of operating burden that arises when stochastic agents are used in business workflows. The two constructs are related, but they are not the same: debt can amplify the tax, while the tax can remain positive even when debt is minimized. The note starts from a compact dashboard expression, expands it into a fuller structural model, defines all variables and parameters, shows how each cost category can be estimated from operational data, and illustrates the framework with an accounts-payable simulation and companion spreadsheet.
1
1
Purpose and Core Intuition
The purpose of this note is to make two constructs precise enough to support measurement, simulation, and dashboarding. Both constructs concern the management of agentic AI systems, but they answer different questions. Core distinction Agentic Technical Debt is the accumulated liability created by expedient agent design and governance choices. Stochastic Tax is the recurring cost of keeping stochastic agent behavior within acceptable operating bounds, and its rate can move with debt, usage, surface area, autonomy, and model variability. The distinction is most naturally expressed as a stock-flow distinction. Agentic Technical Debt is a stock because it accumulates over time through choices about prompts, tools, context, memory, routing, observability, and platform coupling. It can be paid down through refactoring, standardization, versioning, documentation, and governance. Stochastic Tax is a flow because it is paid repeatedly as the organization operates an agentic workflow. It appears in evaluation, monitoring, retries, escalation, latency, token and context processing, guardrails, security checks, and revalidation. This distinction also clarifies why the term Stochastic Tax is useful. Interest on technical debt disappears when the debt is paid off. Stochastic Tax need not disappear when Agentic Technical Debt is minimized. Even a carefully governed agentic workflow can impose a positive operating burden because probabilistic systems can vary across runs, act through tools, depend on context, and encounter new edge cases as adoption expands. Debt can raise this burden, but it does not create the burden from nothing.
2
Conceptual Background
The technical-debt metaphor originated in software engineering to describe how shortcuts can accelerate near-term delivery while increasing future maintenance cost (Cunningham, 1992). Later empirical work showed that technical debt can be measured through concrete liabilities and linked to remediation cost, operational disruption, and system longevity (Ramasubbu et al., 2015). Machine-learning systems expanded the debt metaphor beyond code to include data dependencies, hidden feedback loops, pipeline entanglement, and undeclared consumers (Sculley et al., 2015). Foundation models and agentic systems extend the problem again because probabilistic outputs are no longer confined to prediction. They can guide tool calls, retrieve or write memory, trigger external actions, and revise plans across multi-step workflows (Bommasani et al., 2021; Yao et al., 2022). Traditional software systems are often deterministic: a defect may be expensive to fix, but it is usually reproducible. Predictive ML systems introduce probabilistic outputs, but the model is often embedded as a single inference component in a larger deterministic workflow. Agentic AI systems operate as control loops. They plan, call tools, condition on retrieved context, write or read memory, and act in external systems. This creates a distinctive managerial problem: the organization must govern probabilistic action, not only code quality 2
or model accuracy.
3
Definitions and Boundary Conditions
Let w ∈ W denote a workflow, such as accounts payable, customer support routing, or sales operations. Let t denote a time period, such as a week, month, or release cycle. Many of the same architectural surfaces appear in both definitions. Context handling, orchestration, memory, and tool routing can accumulate debt when teams make expedient choices; the same surfaces can also generate Stochastic Tax because probabilistic execution varies across runs even when the design is disciplined.
3.1
Agentic Technical Debt
Definition. Agentic Technical Debt is the accumulated liability created when an agentic system is assembled, modified, or governed through expedient choices that make future change, validation, explanation, or control more costly than necessary. The unit of liability is not only code or data. In agentic systems, debt also resides in instructions, context, state, tool contracts, action authority, and the governance routines that make future changes safe. This liability can appear in some of the following places, including: • Context and prompt debt: long, inconsistent, or poorly versioned prompts; unstructured context; unclear retrieval rules; conflicting instructions. • Tool and schema debt: unversioned tools, fragile tool-call schemas, undocumented connectors, inconsistent error handling, weak contracts between agents and tools. • Memory and state debt: unclear write permissions, stale memory, weak state management, unclear retention policies, inconsistent memory retrieval. • Orchestration and routing debt: brittle sequential chains, ad hoc routing logic, poorly specified escalation paths, untested workflow branches. • Governance and observability debt: missing traces, weak golden sets, incomplete tests, insufficient monitoring, unclear ownership of prompt and tool changes. • Platform-coupling debt: tight dependence on a particular model, vendor, safety policy, or connector interface without abstraction, versioning, or revalidation discipline.
3.2
Stochastic Tax
Definition. Stochastic Tax is the recurring operating burden of keeping stochastic agentic behavior within acceptable bounds in a business workflow. The tax arises from the inherently probabilistic nature of agentic AI systems, not only from engineering shortcomings, and it can persist even if all technical debt were paid down. The relevant managerial question is
3
therefore not whether the tax can be made to vanish, but which portion is an unavoidable cost of operating stochastic action and which portion is amplified by remediable debt. This tax is distinct from the general operating burden of enterprise systems. ERP systems impose review delays, approval queues, and override workflows, but those costs are largely deterministic and predictable. Stochastic Tax is specifically the variable burden introduced by non-determinism, namely the cost that exists because the same semantic input need not produce the same execution path. Stochastic Tax typically appears in the following recurring cost categories: • Evaluation and test maintenance: building and refreshing eval suites, running model or judge calls, and reviewing outputs as the workflow changes. • Monitoring and observability: collecting traces, storing logs, maintaining dashboards, reviewing alerts, and investigating anomalous runs. • Retry and repair: paying for additional model calls, tool calls, self-repair loops, and manual repair when the first execution path fails or becomes ambiguous. • Escalation and exception handling: routing uncertain or risky cases to humans and absorbing the labor cost of review, approval, or correction. • Revalidation after change: retesting the workflow after model, prompt, tool, context, policy, or vendor changes. • Latency and delay: absorbing the cost of slower or more variable execution, especially when multi-step workflows create tail latency. • Token, compute, and context processing: paying for longer prompts, larger retrieved context, repeated calls, model usage, compute, and tool-execution charges. • Security and guardrail maintenance: updating input and output controls, reviewing security flags, maintaining guardrails, and testing new attack patterns.
4
Illustrative boundary example Suppose three users ask a general-purpose agentic assistant the same semantic question and need the same semantic answer. The model is strong and the surrounding scaffolding is mature. All three users may receive semantically similar outputs, but the number of intermediate reasoning steps, tool calls, retries, and tokens consumed can differ across the three runs. That cost variability is Stochastic Tax: it arises from probabilistic execution, not from an error made by any of the users. By contrast, if one user has built a project with conflicting system prompts, undocumented connectors, and unclear context rules, that user is also carrying Agentic Technical Debt. The debt can be paid down by cleaning up prompts, versioning connectors, and documenting context policies. The tax can be reduced, but under current agentic architectures it cannot be assumed to disappear. A smaller version of the same distinction appears when an agent searches the web before consulting a document that the user already uploaded. If the search fails because the article is paywalled and the agent then falls back to the uploaded document, the extra routing step is part of the stochastic operating burden. If the project repeatedly misroutes because its instructions and context hierarchy are poorly specified, that is also evidence of agentic debt. The term Stochastic Tax carries two meanings, both of which the model preserves. First, it is a tax incurred because the system is stochastic: probabilistic outputs, fallible tool calls, and a continuously expanding surface of edge cases create an operating burden that cannot be designed away under current agentic architectures. The model represents this reading through a baseline floor: even when agentic debt is set to zero, some evaluation, monitoring, guardrails, and exception handling remain. Second, the tax is itself stochastic: its rate moves period to period as debt accumulates or is paid down, as adoption expands, as surface area grows, and as underlying event rates fluctuate. A team cannot quote next quarter’s stochastic tax the way it quotes a lease payment. The formal model below makes both readings operational: the baseline floor captures the first, while the amplifiers and event-rate dependence capture the second. Table 1 summarizes the distinction.
5
Table 1: Comparing Agentic Technical Debt and Stochastic Tax Dimension
Agentic Technical Debt
Stochastic Tax
Basic idea
Accumulated liability from expedient design and governance choices Debt principal
Recurring operating burden of stochastic agent behavior Tax or operating charge paid with use Paid per period, run, release, workflow, or transaction Evaluation, monitoring, retries, escalation, revalidation, latency, token/context cost, security and guardrail work What recurring burden do we pay to operate behavior safely? Measure, budget, set thresholds, automate checks, triage high-tax workflows It can be reduced, but need not vanish under current agentic architectures May reveal symptoms of Agentic Technical Debt, but is not reducible to Agentic Technical Debt
Economic metaphor Time pattern
Builds up over time
Where it appears
Main question Managerial sponse
Prompts, context, tools, schemas, memory, routing, orchestration, observability, platform coupling
What choices are making future change harder? re- Refactor, standardize, version, document, redesign, govern
Can it be elimi- It can be reduced, sometimes materinated? ally Relationship
4
Can amplify Stochastic Tax
Modeling Agentic Technical Debt as a Stock
A useful model of Agentic Technical Debt must do two things. First, it must identify the components of debt that managers can inspect and remediate. Second, it must represent debt as persistent. A brittle prompt, undocumented connector, or unclear memory rule does not vanish merely because the next transaction succeeds.
4.1
Debt Components
For workflow w in period t, define the debt-component vector
tool mem orch obs plat dw,t = dctx w,t , dw,t , dw,t , dw,t , dw,t , dw,t ,
diw,t ∈ [0, 1].
(1)
Each component diw,t is normalized between 0 and 1. A value near 0 means the component is well controlled. A value near 1 means the component creates severe future-change, validation, or control liability. Table 2 gives observable indicators for each component.
6
Table 2: Operationalizing Agentic Technical Debt Components Component
Observable indicators
Why it belongs in the debt model
Context and prompt debt
Prompt length growth, conflicting instructions, unversioned prompt edits, context-source sprawl Unversioned tools, malformed tool calls, missing parameter checks, undocumented connectors Stale memory, unclear write rules, missing retention policies, state inconsistencies Long serialized chains, fragile routing logic, excessive handoffs, unclear fallback paths Missing traces, weak golden sets, unclear ownership, no release gates Tight dependence on a model, vendor API, safety policy, or connector without abstraction
Prompt and context complexity make future changes hard to reason about and test.
Tool debt
and
schema
Memory and state debt Orchestration routing debt
and
Observability and governance debt Platform-coupling debt
Agents act through tools, so weak contracts increase future validation and integration cost. Persistent state lets past errors influence future behavior. Multi-step workflows can compound errors and raise redesign cost. Lack of observability makes future changes expensive and risky. External changes can force internal revalidation or redesign.
Equation 1 is useful in practice because it gives the team a debt register. Each component can be scored from operational evidence, for example on a 0 to 5 scale and then normalized to [0, 1]. The score need not be perfect to be useful. Its value comes from being repeated consistently over time and connected to remediation actions.
4.2
Debt Accumulation Dynamics
The next step is to model how a debt component changes over time. A component should decline when remediation is effective. It should rise from two sources: local change activity that the team accrues directly, and external shocks that the team absorbs from the platform. The local channel accrues debt only when there is something to change, the changes are made expediently, and governance is not strong enough to absorb them safely; we capture this with three multiplicative factors: change pressure X, shortcut intensity Q, and inverse governance (1 − G). The platform channel accrues debt only when the platform itself changes and the workflow is exposed to that change; we capture this with two multiplicative factors: platform volatility V plat and exposure E. For component i, define h
i
plat i i i diw,t+1 = Π[0,1] (1 − ϕi Rw,t )diw,t + αi Xw,t Qiw,t (1 − Giw,t ) + ζi Vw,t Ew,t .
The terms in Equation 2 have the following meaning: 7
(2)
• diw,t is the current debt score for component i in workflow w. i ∈ [0, 1] is normalized remediation effort for component i, such as refactoring prompts, • Rw,t versioning tools, improving tests, or clarifying ownership.
• ϕi ≥ 0 converts remediation effort into debt reduction. i • Xw,t ∈ [0, 1] is change pressure on component i: the rate at which changes are demanded (prompt edits, new tools, new context sources, policy changes, or workflow changes) relative to the team’s clean-change capacity during period t. High pressure forces edits to be made faster than they can be cleanly absorbed.
• Qiw,t ∈ [0, 1] is shortcut intensity, meaning the fraction of changes made through local patches rather than systematic redesign. • Giw,t ∈ [0, 1] is governance maturity. Stronger versioning, tests, schemas, ownership, and observability reduce new debt creation. plat • Vw,t ≥ 0 is platform volatility, such as changes in model behavior, vendor interfaces, safety policies, or connector APIs. i • Ew,t ∈ [0, 1] is exposure to platform volatility. A decoupled workflow has lower exposure than a workflow tightly coupled to one model or vendor.
• αi and ζi translate local change pressure and platform volatility into debt growth. • Π[0,1] [·] truncates the value to the unit interval. Analytically, this equation captures persistence, accumulation, remediation, and platformdriven shocks. Practically, it tells a manager what to measure: change pressure, shortcut intensity, governance maturity, remediation effort, and exposure to external change. It also identifies levers. The team can reduce debt by increasing R, reducing Q, increasing G, or lowering platform exposure through abstraction and versioning. The full equation is useful for diagnosing where debt comes from. For numerical exploration, however, managers often need a lighter recurrence that exposes only the amount of debt accumulated and the amount remediated during a period. The simulation and companion spreadsheet therefore use the following simplified per-period net-change rule: h
i
rem Dw,t+1 = Π[0,1] Dw,t + ∆acc w,t − ∆w,t .
(3)
rem Here ∆acc w,t is newly accumulated workflow-level debt during the period and ∆w,t is workflowlevel remediation. This is the form used in the companion spreadsheet’s Time_Series sheet. It is a simplification of Equation 2, not a competing model.
8
4.3
Aggregating Debt into a Workflow Index
Managers need a workflow-level score in addition to component-level scores. A simple weighted average is often sufficient, but agentic components can interact. For example, prompt brittleness is more damaging when tool schemas are weak, and ungoverned memory is more damaging when routing is unclear. To capture this coupling, define X Dw,t = Π[0,1] ωi di
w,t +
X
ωij diw,t djw,t .
(4)
i<j
i∈I
Here Dw,t ∈ [0, 1] is the normalized Agentic Technical Debt index, I is the set of debt components, ωi ≥ 0 are component weights, and ωij ≥ 0 are coupling weights. A dashboard can report 100Dw,t as a 0 to 100 debt score. The interaction term is optional for a first implementation. A team with limited data can set all ωij = 0 and later add interactions once it observes that specific component pairs raise remediation cost or operating burden.
4.4
Debt Principal in Dollars
The index in Equation 4 is useful for tracking, but a financial view may require an estimated debt principal. If the team can estimate remediation costs, define AT D Pw,t =
X
c̄rem diw,t + i
i∈I
X
c̄coord diw,t djw,t + c̄retest ij w,t .
(5)
i<j
AT D Pw,t is the estimated debt principal in dollars. c̄rem is the estimated cost to fully i coord remediate component i, c̄ij is the coordination premium created by coupled liabilities, and c̄retest is the testing and revalidation cost required after remediation. This model is useful in w,t practice because it translates an abstract score into a planning estimate: how much effort would it take to pay down the liability?
5
Modeling Stochastic Tax as a Flow
A useful model of Stochastic Tax must connect a dashboard-ready expression to observable operating drivers. This section starts with a compact average-cost expression, then expands each cost category into structural drivers that can be estimated, simulated, and implemented in a spreadsheet.
5.1
From Dashboard Expression to Structural Expansion
For workflow w in period t, let Nw,t denote completed transactions. Average stochastic tax per transaction can be expressed as recurring cost categories divided by completed transactions. In the expanded eight-category form used here, 1 retry latency monitor escalate revalidate + Cw,t ST w,t = C eval + Cw,t + Cw,t + Cw,t + Cw,t Nw,t w,t
security token + Cw,t + Cw,t
. 9
(6)
k In Equation 6, Cw,t is the total cost in category k during period t. This expression is appropriate for a managerial dashboard because it reports a unit cost: the recurring burden k per completed transaction. To populate the dashboard, however, each Cw,t must be connected to observable drivers. The structural model below provides that expansion. Table 3 lists the eight cost categories used in the model.
Table 3: Cost Categories for a Stochastic Tax Dashboard Cost category k
Measurement approach
Typical data source
Evaluation and test maintenance Monitoring and observability
Model calls, judge calls, test infrastructure, expert review time Dashboard cost, trace storage, alert review, routine operations time Retry and repair Extra model calls, extra tool calls, self-repair loops, manual repair work Escalation and excep- Escalated cases times average tion handling handling time and labor rate Revalidation after Retesting and approval after change model, prompt, tool, policy, or context changes Latency and delay Excess latency relative to target times delay cost, plus SLA or abandonment cost Token, compute, and Expected tokens per transaction context processing times unit cost, plus compute and tool-call charges Security and guardrail Security flags, input/output maintenance guardrail reviews, adversarial test updates
5.2
Evaluation logs, test records, reviewer hours Observability tools, log storage, incident queues Agent traces, tool-call logs, retry counters Ticket queues, approval logs, operations records Release records, model-version logs, validation plans Latency dashboards, SLA records, conversion or productivity estimates Model bills, token logs, context retrieval logs Security logs, guardrail logs, red-team records
Total and Average Stochastic Tax
Let T STw,t denote total stochastic tax for workflow w in period t. Let K denote the eight cost categories in Table 3. Then T STw,t =
X
k Cw,t .
(7)
k∈K
The per-transaction tax reported on a dashboard is ST w,t =
T STw,t . Nw,t
(8)
Equations 7 and 8 separate total budget burden from unit economics. Total tax may rise with adoption even while per-transaction tax falls because fixed evaluation, monitoring, 10
and governance costs are spread over more transactions. This distinction is important for managers because a scaled agent can look more expensive in total dollars while becoming more efficient per transaction.
5.3
Scales for Operating Drivers
Before specifying the structural form, the operating drivers need clear scales. Table 4 defines the variables used in the operating-exposure amplifier. Table 4: Operating-Exposure Variables and Scales Symbol
Scale
Interpretation
Uw,t
Positive count or index
Sw,t
Positive count or index
Hw,t
Positive count
Aw,t
[0, 1]
Θw,t
[0, 1]
Adoption or usage exposure, such as transactions, active users, teams, or distinct usage contexts. In the simulation, U = N . Surface area, such as tools, connectors, context sources, permissions, APIs, or external systems. Workflow horizon, measured as the number of dependent agentic steps or the effective depth of the action chain. Autonomy and action criticality: 0 = advisory, 0.5 = approval-required, 1 = direct execution in external systems. Model or platform variability: 0 = stable behavior under fixed tests, 0.5 = moderate run-to-run or version drift, 1 = high variability or rapid provider-side change.
These scales make the coefficients interpretable. A manager can score A and Θ consistently across workflows even when the exact engineering measures differ.
5.4
Cost-Category Structural Form
Each cost category has three drivers: a baseline floor, a debt amplifier, and an operatingexposure amplifier. The baseline floor is what the workflow would cost at zero Agentic Technical Debt and at reference operating conditions. The debt amplifier, Φk (Dw,t ), is a function of Dw,t and captures the effect of accumulated Agentic Technical Debt. The operating-exposure amplifier, Ψk (Uw,t , Sw,t , Hw,t , Aw,t , Θw,t ), captures adoption, surface area, workflow horizon, autonomy, and inherent model variability. For each category k, define k Cw,t = (Fk + Vk Nw,t ) · Φk (Dw,t ) · Ψk (Uw,t , Sw,t , Hw,t , Aw,t , Θw,t ) .
|
{z
baseline floor
}
|
{z
}
debt amplifier
|
operating-exposure amplifier
The variables and parameters in Equation 9 are: 11
{z
}
(9)
• Fk ≥ 0 is the fixed or semi-fixed cost of category k in a period, such as maintaining an evaluation suite or observability pipeline. • Vk ≥ 0 is the baseline variable cost per completed transaction in category k. • Nw,t is completed transactions. • Dw,t is the normalized Agentic Technical Debt index from Equation 4. • Uw,t , Sw,t , Hw,t , Aw,t , and Θw,t are the operating-exposure variables defined in Table 4. • Φk (·) and Ψk (·) are normalized amplifiers defined below. Analytically, Equation 9 makes the floor visible. The model cannot accidentally say that operating cost is zero when debt is zero. Practically, the equation gives managers a way to ask whether a rise in cost is coming from more usage, a larger surface area, longer workflows, greater autonomy, external variability, or accumulated debt.
5.5
Debt Amplifier
The simplest useful debt amplifier is linear: βk ≥ 0,
Φk (Dw,t ) = 1 + βk Dw,t ,
Φk (0) = 1.
(10)
The coefficient βk is the debt sensitivity of category k. If βretry = 2.5, then moving from D = 0 to D = 1 multiplies retry-related cost by 3.5, holding other drivers fixed. Larger values of βk are plausible for retry, revalidation, and evaluation because brittle prompts, weak tool schemas, and poor observability tend to appear first in those categories. Smaller values may be plausible for categories that are more infrastructure-driven, such as baseline monitoring. The practical value of βk depends on calibration. A team can begin with expert estimates, but the debt-amplified decomposition should be treated as a scenario estimate until the team has observed enough periods, incidents, releases, or remediation interventions to update the values.
5.6
Operating-Exposure Amplifier
The operating-exposure amplifier captures the fact that Stochastic Tax can rise even when Agentic Technical Debt is unchanged. More adoption means more users, prompts, edge cases, and exception opportunities. More surface area means more tools, context sources, permissions, and possible attack vectors. Longer horizons make cascading errors more likely. Higher autonomy increases the need for control. Greater model variability raises the need for evaluation and revalidation. Let U0 , S0 , H0 , A0 , and Θ0 denote reference operating values. A coherent positive form is
Ψk (Uw,t , Sw,t , Hw,t , Aw,t , Θw,t ) = exp γ U ln k
Uw,t Sw,t + γkS ln U0 S0
Hw,t + γkH ln + γkA (Aw,t − A0 ) + γkΘ (Θw,t − Θ0 ). (11) H0
12
Here γkU , γkS , and γkH are elasticities with respect to adoption, surface area, and horizon. For example, γkU = 0.10 means that a tenfold increase in U multiplies category-k cost by approximately 100.10 , holding other drivers fixed. γkA and γkΘ are semi-elasticities for the bounded scores A and Θ. The exponential form guarantees that Ψk > 0 without imposing an arbitrary floor. At the reference values, Ψk = 1. For dashboard implementation, teams can start with only U and S if data are limited, then add H, A, and Θ as the measurement program matures.
5.7
Three Properties Built Into the Model
The model encodes three properties that clarify why Stochastic Tax is not simply interest on Agentic Technical Debt. Three properties of the model P1. Nonzero baseline. When Dw,t = 0, Φk (0) = 1, but T STw,t remains positive if at least one category has Fk + Vk Nw,t > 0. A zero-debt agentic workflow still carries stochastic tax. This is the formal statement of the first meaning of Stochastic Tax: the tax exists because the system is stochastic, not because the workflow is badly engineered. P2. Debt amplification. If βk ≥ 0, then k ∂Cw,t = (Fk + Vk Nw,t )βk Ψk (·) ≥ 0. ∂Dw,t
Accumulated debt raises category cost. Debt amplifies the tax; it does not create the tax from nothing. P3. Independent operating-exposure channel. If any operating-exposure coefficient is positive, then Stochastic Tax can rise even when Dw,t is unchanged. Adoption, surface area, workflow horizon, autonomy, and model variability can each raise the tax independently. P2 and P3 formalize the second meaning of Stochastic Tax: the tax rate itself moves with debt, operating exposure, and the event rates that those drivers influence. A useful implication follows. If a team pays down Agentic Technical Debt but still observes a rising Stochastic Tax, this is not necessarily a failure of debt remediation. It may mean the system is being used more widely, exposes more tools and data sources, or operates with higher autonomy. The dashboard should therefore decompose observed tax rather than treating every increase as evidence of debt.
5.8
Baseline and Debt-Amplified Tax
The conceptual dashboard decomposition is 0
D
ST w,t = ST w,t + ST w,t , 13
(12)
where
0
ST w,t = ST w,t | Dw,t = 0, D
0
ST w,t = ST w,t − ST w,t .
(13) (14)
0
ST w,t is the baseline stochastic tax, or the tax associated with operating a stochastic, toolusing workflow at the current level of adoption, surface area, horizon, autonomy, and variability. D ST w,t is the debt-amplified tax, or the additional burden associated with accumulated Agentic Technical Debt. This decomposition is conceptually important, but it should not be overinterpreted before 0 calibration. Computing ST w,t requires values for βk . Those values are usually not directly observed. A manager should therefore report the decomposition as a calibrated estimate, with sensitivity ranges, until the organization has learned βk from history, interventions, or expert judgment.
5.9
Calibrating Debt Sensitivities
A feasible way to calibrate βk is to compare periods or workflows with materially different debt scores while holding operating exposure approximately constant. Define the normalized observed category cost k Zw,t =
k Cw,t . (Fk + Vk Nw,t )Ψk (Uw,t , Sw,t , Hw,t , Aw,t , Θw,t )
(15)
k = 1 + βk Dw,t . With two observations t1 and t2 , Under Equation 9, Zw,t
βbk ≈
k k Zw,t − Zw,t 2 1 , Dw,t2 − Dw,t1
Dw,t2 ̸= Dw,t1 .
(16)
In practice, a team might estimate βbk after a refactoring sprint that lowers tool/schema debt, after a prompt rationalization project, or across comparable workflows with different debt scores. If such observations are not available, βk should be treated as an expert prior and stress-tested in the spreadsheet. The decomposition in Equations 12 to 14 becomes more decision-ready as these estimates improve. Other parameters can be estimated with the same pragmatic discipline. The fixed terms Fk and baseline unit costs Vk can come from accounting allocations, model bills, observability invoices, labor rates, and logs at a reference operating point. The exposure coefficients γ can be updated from before-after observations when adoption, surface area, horizon, autonomy, or model variability changes materially while other drivers remain approximately stable. Unit costs such as ctok and clat t w,t can come from provider pricing, internal compute charges, j labor-cost models, SLA penalties, or business estimates of delay. Event rates such as qw,t can be read from traces, incident queues, security logs, and escalation records. This keeps the model feasible: teams can begin with approximate but transparent assumptions, then replace them with observed estimates over time.
14
6
Estimating Cost Categories from Operational Data
The structural model explains and forecasts category costs. A dashboard also needs meak surement rules for estimating each Cw,t from logs, invoices, tickets, and labor records. These measurement equations produce the same quantities as the structural model when calibrated to the same drivers; they differ in inputs. The structural form asks, “what should the cost be, given debt and operating exposure?” The measurement layer asks, “what did the cost actually amount to this period?” A general direct-measurement expression is obs,k k Cw,t = Fw,t +
X
k,m xk,m w,t pw,t .
(17)
m∈Mk obs,k Here Fw,t is an observed fixed or allocated cost for category k, Mk is the set of measured resource types in that category, xk,m w,t is the observed quantity of resource m used in category k,m k, and pw,t is the unit price of that resource. Examples include model calls, reviewer hours, storage volume, security analyst time, tool calls, and escalated tickets. For rate-based categories such as retry, escalation, and security flags, a convenient special case is j j = Nw,t qw,t cjw,t , (18) Cw,t j where j is an event type, qw,t is the event rate per transaction, and cjw,t is the average cost per event. For example, escalation cost can be estimated as transactions times escalation rate times average handling cost. Token and context-processing costs can often be measured directly from model logs: token Cw,t = Nw,t
E[T okw,t ] tok compute ct + Cw,t . 1000
(19)
E[T okw,t ] is expected tokens consumed per transaction, ctok is the blended cost per 1,000 t compute tokens, and Cw,t captures additional compute, retrieval, or tool-execution charges not included in the token price. In the structural model, the baseline value of this expression at reference operating conditions is absorbed into Ftoken + Vtoken N . Latency cost can be measured relative to a target: latency ∗ Cw,t = Nw,t clat w,t E [(Lw,t − Lw )+ ] .
(20)
Here Lw,t is observed latency, L∗w is the target latency for workflow w, (x)+ = max(0, x), and clat w,t is the business cost of one unit of excess delay. As with token cost, the structural parameter Vlatency absorbs the expected reference-condition cost, while the observed measurement equation is used to populate and recalibrate the dashboard. Table 5 links each category to a practical measurement rule.
15
Table 5: Practical Measurement Rules for Cost Categories Category
First-cut measurement
Common pitfall
Evaluation
Test runs, judge calls, and reviewer hours times unit costs Allocated observability cost plus alert review hours
Forgetting maintenance of the test set itself. Allocating shared monitoring cost inconsistently across workflows. Counting retries but ignoring self-repair loops that still consume tokens. Treating escalations as failures even when they are appropriate controls. Charging all revalidation to the model rather than the workflow that required it. Using average latency while ignoring tail latency. Ignoring context retrieval and repeated calls. Treating guardrails as one-time implementation rather than recurring maintenance.
Monitoring
Retry and repair
Retry count times incremental model/tool cost plus repair labor
Escalation
Escalation rate times average handling cost
Revalidation
Retest hours and calls after model, prompt, tool, context, or policy changes Expected excess latency times business delay cost Token logs, model bills, retrieval charges, and tool-execution cost Flag review time, red-team updates, guardrail calls, and security operations effort
Latency and delay Token, compute, and context Security and guardrails
The measurement layer and structural layer should be used together. Observed category costs provide the dashboard numbers. The structural model explains why those numbers change and supports simulations of what could happen if debt, adoption, surface area, horizon, autonomy, or model variability changes.
7
Numerical Illustration: Accounts-Payable Agent
The simulation below illustrates the model with a hypothetical accounts-payable agentic workflow. The workflow extracts invoice fields, checks vendor identity, validates payment terms, applies policy rules, and schedules payment. It uses several tools and context sources, produces traces, and escalates exceptions to a human queue. The calibration is illustrative. It is designed to be plausible enough for managerial reasoning, not to estimate a universal industry benchmark.
7.1
Cost-Category Calibration
Table 6 reports the primary cost parameters. Vk is baseline variable cost per transaction. Fk is fixed monthly cost. βk is the debt amplifier. The γ columns are operating-exposure sensitivities. All dollar values are monthly and illustrative. 16
Table 6: Cost-Category Parameters for the Accounts-Payable Simulation Category k
Vk
Fk
βk
γkU
γkS
γkH
γkA
Main intuition
Evaluation
0.010
200
1.2
0.12
0.08
0.08
0.12
Monitoring
0.005
350
0.4
0.10
0.06
0.04
0.06
Retry and repair
0.040
0
2.5
0.07
0.05
0.12
0.10
Escalation Revalidation
0.120 0.002
80 400
1.0 1.8
0.08 0.10
0.06 0.12
0.10 0.12
0.18 0.10
Latency and delay
0.030
50
0.8
0.05
0.05
0.18
0.15
Token, compute, and context Security and guardrails
0.200
0
0.6
0.03
0.08
0.12
0.08
0.008
150
0.3
0.15
0.18
0.05
0.20
Fragile systems need more test and reviewer effort. Trace volume and alert triage rise with scale. Brittle prompts and schemas produce malformed calls. Exceptions need human review. Model, tool, and policy changes need retesting. Long chains and retries create delay. Large context and repeated calls raise compute cost. More tools and users expand attack surface.
The corresponding γkΘ values are 0.15, 0.08, 0.12, 0.08, 0.20, 0.10, 0.08, and 0.12 for evaluation, monitoring, retry and repair, escalation, revalidation, latency and delay, token/context, and security/guardrails, respectively. The companion spreadsheet exposes all parameters as editable cells.
7.2
Four-Scenario Comparative Statics
The first simulation uses a 2 × 2 design: low versus high adoption crossed with low versus high debt. Holding other variables constant makes the interpretation clean. It shows what scale does when debt is low, what debt does when adoption is low, and what happens when scale and debt meet. Table 7: Scenario Inputs Scenario
N
D
U
S
H
A
S1: Low adoption, low debt S2: High adoption, low debt
1,000 10,000
0.10 0.10
1,000 10,000
5 15
4 4
0.40 0.40
S3: Low adoption, high debt S4: High adoption, high debt
1,000 10,000
0.60 0.60
1,000 10,000
5 15
4 4
0.40 0.40
Description Carefully governed pilot. Scaled with disciplined governance. Pilot with accumulated debt. Scaled with accumulated debt.
All four scenarios set Θ = 0.30. This keeps the example focused on adoption, surface area, and debt.
17
Table 8: Stochastic Tax Under the Four Scenarios Scenario S1: Low adoption, low debt S2: High adoption, low debt S3: Low adoption, high debt S4: High adoption, high debt
Total TST
ST per tx
Baseline per tx
Debt-amplified per tx
$1,810 $7,520 $2,634 $10,799
$1.81 $0.75 $2.63 $1.08
$1.65 $0.69 $1.65 $0.69
$0.16 $0.07 $0.99 $0.39
Three patterns are visible in Table 8. First, the tax is positive even at low debt. Second, adoption can reduce per-transaction tax by amortizing fixed evaluation, monitoring, and governance costs. In the low-debt case, scaling from S1 to S2 reduces per-transaction tax by about $1.06. Third, debt steals some of these economies of scale. Scaling from S1 to S4 reduces per-transaction tax by only about $0.73. The difference, roughly $0.33 per transaction, is a useful managerial number: it is the per-transaction saving that accumulated debt prevents the team from capturing.
Per-transaction stochastic tax by scenario $2.63
ST per transaction ($)
2.5 2.0
$1.81
1.5 $1.08
1.0
$0.75
0.5 0.0
S1
S2
S3
S4
Figure 1: Per-transaction Stochastic Tax across the four scenarios.
18
Baseline and debt-amplified ST Baseline ST Debt-amplified ST
ST per transaction ($)
2.5 2.0 1.5 1.0 0.5 0.0
S1
S2
S3
S4
Figure 2: Baseline and debt-amplified Stochastic Tax by scenario. The baseline component remains positive when debt is set to zero.
7.3
ATD Sensitivity Sweep
The second simulation isolates the debt channel. It holds adoption, surface area, horizon, autonomy, and model variability fixed at the high-adoption operating point and varies D from 0 to 1. This answers a practical question: if our debt score rises by 0.1 at the current scale, how much will per-transaction tax increase? Table 9: Sensitivity of Stochastic Tax to the Agentic Technical Debt Index at High Adoption D
Total TST
ST per tx
Change vs. D = 0
0.00 0.25 0.50 0.75 1.00
$6,864 $8,504 $10,143 $11,783 $13,423
$0.69 $0.85 $1.01 $1.18 $1.34
– +24% +48% +72% +96%
At D = 0, the per-transaction tax is still $0.69. This is the nonzero floor. At this operating point, the relationship is approximately linear because the debt amplifier is linear. The local slope is managerially interpretable: it is the expected per-transaction increase in Stochastic Tax for a unit increase in the debt index, holding other operating conditions fixed.
19
ATD sensitivity at high adoption 1.3 ST per transaction ($)
1.2 1.1 1.0 0.9 0.8 0.7 0.0
0.2
0.4
ATD index D
0.6
0.8
1.0
Figure 3: ATD sensitivity sweep at a fixed high-adoption operating point.
7.4
Twelve-Month Dynamic Paths
The third simulation shows how governance changes the path. Both workflows start at the same debt level and the same high-adoption operating point. Path A accumulates more debt than it remediates. Path B remediates more debt than it accumulates. For this illustration, we use the simplified debt dynamics in Equation 3. Path A uses acc ∆ −∆rem = 0.06−0.02 = +0.04 per month. Path B uses ∆acc −∆rem = 0.03−0.07 = −0.04 per month. The companion spreadsheet exposes all four rates as editable inputs. Table 10: Twelve-Month Evolution of Agentic Technical Debt and Stochastic Tax per Transaction Month
Path A: D
Path A: ST
Path B: D
Path B: ST
0 3 6 9 12
0.10 0.22 0.34 0.46 0.58
$0.75 $0.83 $0.91 $0.99 $1.07
0.10 0.00 0.00 0.00 0.00
$0.75 $0.69 $0.69 $0.69 $0.69
By month 12, the accumulation path pays about $0.38 more per transaction than the governance path. At 10,000 transactions per month, that is about $3,804 per month, or roughly $45,649 per year, for one workflow. The point is not that the illustrative dollar values are universal. The point is that the model turns a vague concern about debt into a dashboard quantity that can be tracked, simulated, and governed.
20
Dynamic paths: accumulation versus governance Path A: accumulation Path B: governance
1.05
ST per transaction ($)
1.00 0.95 0.90 0.85 0.80 0.75 0.70 0
2
4
6 Month
8
10
12
Figure 4: Dynamic paths for an accumulation regime and a governance regime.
8
From Model to Dashboard
The model supports a managerial dashboard that answers four recurring questions. 1. Is operating burden stable, rising, or concentrated? Track T STw,t and ST w,t by workflow and period. 2. Is rising tax explained by adoption, surface area, autonomy, variability, or debt? Decompose changes in tax across drivers rather than treating every increase as debt. 3. Is debt accumulating or being paid down? Track Dw,t and its six components over time. 4. Which intervention is appropriate? Use the decomposition to distinguish refactoring decisions from operating-control decisions. Table 11 gives a minimal dashboard design.
21
Table 11: Dashboard Fields per Workflow per Period Field
Definition
Managerial use
Dw,t
Track debt stock and trigger governance review above threshold.
T STw,t
Composite Agentic Technical Debt index in [0, 1], often reported as 0 to 100 Debt scores for context, tools, memory, orchestration, observability, and platform coupling Total stochastic tax for the period
ST w,t
Tax per completed transaction
Component scores diw,t
0
ST w,t
D
ST w,t
Driver indicators Calibration status
Baseline tax when D = 0 at current operating exposure
Identify the remediation target.
Budget item and operating-cost allocation. Compare unit economics across workflows. Set expectations for debt-paydown benefits, subject to calibration uncertainty.
Debt-amplified tax
Estimate avoidable burden associated with accumulated debt, after βk values are calibrated. Adoption, surface area, horizon, au- Diagnose whether tax growth is due tonomy, variability to scale, complexity, or debt. Expert prior, before-after estimate, Prevents the dashboard from overstatregression estimate, or validated es- ing precision. timate
The dashboard should also display category diagnostics such as token cost per transaction, retry rate, escalation rate, P95 latency, security-flag rate, and revalidation hours after changes. These signals help managers move from measurement to action. If token cost rises while debt is flat, context-management or retrieval strategy may be the right target. If retry and revalidation costs rise together with tool/schema debt, refactoring interfaces may be more important. If total tax rises while per-transaction tax falls, the system may be scaling responsibly.
9
Implementation Guidance
A practical implementation can proceed in seven steps. 1. Define workflow boundaries. Specify where the workflow begins and ends, such as invoice intake to payment scheduling. 2. Score the debt stock. Score the six debt components using evidence from prompts, tools, traces, tests, release records, and governance artifacts. 3. Collect operating signals. Capture token use, retry rate, escalation rate, latency, security flags, evaluation effort, monitoring effort, and revalidation work. 22
4. Convert signals into dollars. Use token prices, labor rates, delay costs, tool-call charges, and allocated fixed costs. 5. Calibrate the structural parameters. Estimate Fk and Vk from accounting and logs. Estimate γ values from scale, surface, horizon, autonomy, and variability changes. Treat βk as an expert prior until the team has before-after or cross-workflow evidence. 0
6. Estimate the baseline with uncertainty. Calculate ST w,t by setting Dw,t = 0 only after choosing a calibrated or sensitivity-tested set of βk values. 7. Use the decomposition for decisions. Treat baseline tax as an operating reality to manage and debt-amplified tax as a candidate for remediation. The model is feasible because it does not require perfect causal identification before it becomes useful. A dashboard can begin with observed costs and expert-calibrated parameters, then improve as the organization observes releases, incidents, growth, and remediation efforts.
10
Limitations and Extensions
This framework is intended for conceptual clarification and managerial measurement. It is not a universal metric. Several limitations should be acknowledged. First, cost attribution can be imperfect. Evaluation, monitoring, and security costs are often shared across workflows. Managers should use transparent allocation rules and avoid false precision. Second, the causal effect of Agentic Technical Debt on Stochastic Tax may be difficult to identify without interventions, redesigns, or controlled comparisons. The βk coefficients should therefore be treated as calibrated estimates, not directly observed truths. Third, rare but severe failures may not be well represented by average costs. A dashboard should include tail-risk indicators in addition to average tax. Fourth, some organizations may intentionally accept a high baseline tax in regulated or safety-critical settings because stronger evaluation, monitoring, and human review are prudent. Fifth, functional forms may need adjustment. Some systems may exhibit thresholds, nonlinear cascades, or saturation effects that the linear debt amplifier does not capture. Sixth, the model in this note treats ST w,t as a deterministic function of its drivers, even though underlying event rates such j as qw,t are random variables. A natural extension is to model ST w,t as an expected value with a variance derived from event-rate distributions, which would let the second meaning of Stochastic Tax be displayed as a confidence band on the dashboard rather than a point estimate. These limitations do not weaken the usefulness of the model. They clarify how it should be used. The model is a disciplined accounting and governance lens, not a replacement for managerial judgment.
11
Conclusion
Agentic Technical Debt and Stochastic Tax are best modeled as distinct but connected properties of agentic systems. Agentic Technical Debt is the stock of accumulated design 23
and governance liability. Stochastic Tax is the flow of recurring operating burden created by stochastic action in real workflows. Debt can amplify the tax, but the tax also arises from adoption, surface area, workflow horizon, autonomy, and inherent model variability. The model in this note makes that distinction operational. It gives managers a debt index, a cost-category structure, a baseline versus debt-amplified decomposition, a calibration path for the difficult βk parameters, and a simulation approach that can be implemented in a spreadsheet dashboard. This is why tax is a better metaphor than interest: interest suggests a rate paid on a fixed debt principal, whereas Stochastic Tax includes a persistent baseline and a rate that can move with debt, usage, surface area, autonomy, and the stochastic event process itself.
References Cunningham, W. 1992. The WyCash portfolio management system. In Addendum to the Proceedings on Object-Oriented Programming Systems, Languages, and Applications, 29–30. Ramasubbu, N., Kemerer, C. F., and Woodard, C. J. 2015. Managing technical debt: Insights from recent empirical evidence. IEEE Software 32, 2, 22–25. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., and Dennison, D. 2015. Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems, 28. Bommasani, R., Hudson, D. A., Adeli, E., Altman, R., von Arx, S., and others. 2021. On the opportunities and risks of foundation models. arXiv preprint arXiv:2108.07258. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., and Cao, Y. 2022. ReAct: Synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629.
A
Full Simulation Parameters
Reference values used in the simulation are U0 = 1,000, S0 = 5, H0 = 4, A0 = 0.40, and Θ0 = 0.30. Table 12 reports all amplifier coefficients, including γkΘ as a column. Table 12: Full Cost-Category Parameters
Category Evaluation Monitoring Retry and repair Escalation Revalidation Latency and delay
γkU
γkS
γkH
γkA
γkΘ
0.010 200 1.2 0.12 0.005 350 0.4 0.10 0.040 0 2.5 0.07 0.120 80 1.0 0.08 0.002 400 1.8 0.10 0.030 50 0.8 0.05
0.08 0.06 0.05 0.06 0.12 0.05
0.08 0.04 0.12 0.10 0.12 0.18
0.12 0.06 0.10 0.18 0.10 0.15
0.15 0.08 0.12 0.08 0.20 0.10
Vk
Fk
βk
24
Vk
Fk
βk
γkU
γkS
γkH
γkA
γkΘ
Token, compute, 0.200 and context Security and 0.008 guardrails
0
0.6
0.03
0.08
0.12
0.08
0.08
150
0.3
0.15
0.18
0.05
0.20
0.12
Category
B
Equations in One Place
For reference, the central model consists of the following equations:
tool mem orch obs plat dw,t = dctx w,t , dw,t , dw,t , dw,t , dw,t , dw,t ,
(Debt components)
h
i
plat i i i diw,t+1 = Π[0,1] (1 − ϕi Rw,t )diw,t + αi Xw,t Qiw,t (1 − Giw,t ) + ζi Vw,t Ew,t , (Debt dynamics)
X Dw,t = Π[0,1] ωi di
w,t +
i
X
ωij diw,t djw,t ,
(Debt index)
i<j
k Cw,t = (Fk + Vk Nw,t ) Φk (Dw,t )Ψk (Uw,t , Sw,t , Hw,t , Aw,t , Θw,t ),
Φk (Dw,t ) = 1 + βk Dw,t ,
Ψk (·) = exp γ U ln k
(Cost category) (Debt amplifier)
Uw,t Sw,t Hw,t + γkS ln + γkH ln U0 S0 H0
+ γkA (Aw,t − A0 ) + γkΘ (Θw,t − Θ0 ), T STw,t =
X
k Cw,t ,
ST w,t =
k∈K 0 D ST w,t = ST w,t + ST w,t .
C
T STw,t , Nw,t
(Exposure amplifier) (Total and average ST) (Baseline plus debt-amplified ST)
Companion Excel Spreadsheet
The companion Excel spreadsheet implements the same notation and model as this note. It is designed to let readers change reference values, category parameters, scenario inputs, and dynamic-path assumptions while seeing how the stochastic-tax dashboard responds. The spreadsheet contains: • README: a concise explanation of the spreadsheet’s purpose and notation. • Parameters: editable reference values, cost-category parameters, six ATD components, scenario inputs, and dynamic-path inputs. • Scenarios: formula-driven category-cost calculations for the four scenarios.
25
• Summary: total and per-transaction tax, baseline tax, debt-amplified tax, and key computed insights. • ATD_Sensitivity: a sweep from D = 0 to D = 1 at a fixed high-adoption operating point. • Time_Series: the accumulation and governance paths using the simplified debt dynamics in Equation 3. • Data_Dictionary: definitions of all symbols used in the spreadsheet. • Dashboard: a compact managerial view of scenario results and key performance indicators. The spreadsheet is intended for exploration, not as a universal benchmark. Managers should replace the illustrative parameters with their own token prices, labor rates, event rates, observed category costs, debt scores, and calibration assumptions.
26