Modeling Agentic Technical Debt and Stochastic Tax:... | AI Research

What the paper is about

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.

What it covers

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 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 or model accuracy. 3 Definitions and Boundary Conditions Let w ∈ 𝒲 w\in\mathcal{W} denote a workflow, such as accounts payable, customer support routing, or sales operations. Let t 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 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. 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. 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 Recurring operating burden of stochastic agent behavior Economic metaphor Debt principal Tax or operating charge paid with use Time pattern Builds up over time Paid per period, run, release, workflow, or transaction Where it appears Prompts, context, tools, schemas, memory, routing, orchestration, observability, platform coupling Evaluation, monitoring, retries, escalation, revalidation, latency, token/context cost, security and guardrail work Main question What choices are making future change harder? What recurring burden do we pay to operate behavior safely? Managerial response Refactor, standardize, version, document, redesign, govern Measure, budget, set thresholds, automate checks, triage high-tax workflows Can it be eliminated? It can be reduced, sometimes materially It can be reduced, but need not vanish under current agentic architectures Relationship Can amplify Stochastic Tax May reveal symptoms of Agentic Technical Debt , but is not reducible to Agentic Technical Debt 4 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 w in period t t , define the debt-component vector 𝐝 w , t = ( d w , t c ​ t ​ x , d w , t t ​ o ​ o ​ l , d w , t m ​ e ​ m , d w , t o ​ r ​ c ​ h , d w , t o ​ b ​ s , d w , t p ​ l ​ a ​ t ) , d w , t i ∈ [ 0 , 1 ] . \mathbf{d}{w,t}=\left(d^{ctx}{w,t},d^{tool}{w,t},d^{mem}{w,t},d^{orch}{w,t},d^{obs}{w,t},d^{plat}{w,t}\right),\qquad d^{i}{w,t}\in[0,1]. (1) Each component d w , t i d^{i}{w,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. 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 Prompt and context complexity make future changes hard to reason about and test. Tool and schema debt Unversioned tools, malformed tool calls, missing parameter checks, undocumented connectors Agents act through tools, so weak contracts increase future validation and integration cost. Memory and state debt Stale memory, unclear write rules, missing retention policies, state inconsistencies Persistent state lets past errors influence future behavior. Orchestration and routing debt Long serialized chains, fragile routing logic, excessive handoffs, unclear fallback paths Multi-step workflows can compound errors and raise redesign cost. Observability and governance debt Missing traces, weak golden sets, unclear ownership, no release gates Lack of observability makes future changes expensive and risky. Platform-coupling debt Tight dependence on a model, vendor API, safety policy, or connector without abstraction 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 ] [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 X , shortcut intensity Q Q , and inverse governance ( 1 − G ) (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 p ​ l ​ a ​ t V^{plat} and exposure E E . For component i i , define d w , t + 1 i = Π [ 0 , 1 ] ​ [ ( 1 − ϕ i ​ R w , t i ) ​ d w , t i + α i ​ X w , t i ​ Q w , t i ​ ( 1 − G w , t i ) + ζ i ​ V w , t p ​ l ​ a ​ t ​ E w , t i ] . d^{i}{w,t+1}=\Pi_{[0,1]}\left[(1-\phi_{i}R^{i}{w,t})d^{i}{w,t}+\alpha_{i}X^{i}{w,t}Q^{i}{w,t}(1-G^{i}{w,t})+\zeta{i}V^{plat}{w,t}E^{i}{w,t}\right]. (2) The terms in Equation 2 have the following meaning: • d w , t i d^{i}_{w,t} is the current debt score for component i i in workflow w w .

• R w , t i ∈ [ 0 , 1 ] R^{i}{w,t}\in[0,1] is normalized remediation effort for component i i , such as refactoring prompts, versioning tools, improving tests, or clarifying ownership. • ϕ i ≥ 0 \phi{i}\geq 0 converts remediation effort into debt reduction.

• X w , t i ∈ [ 0 , 1 ] X^{i}_{w,t}\in[0,1] is change pressure on component i 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 t . High pressure forces edits to be made faster than they can be cleanly absorbed.

• Q w , t i ∈ [ 0 , 1 ] Q^{i}_{w,t}\in[0,1] is shortcut intensity, meaning the fraction of changes made through local patches rather than systematic redesign.

• G w , t i ∈ [ 0 , 1 ] G^{i}_{w,t}\in[0,1] is governance maturity. Stronger versioning, tests, schemas, ownership, and observability reduce new debt creation.

• V w , t p ​ l ​ a ​ t ≥ 0 V^{plat}_{w,t}\geq 0 is platform volatility, such as changes in model behavior, vendor interfaces, safety policies, or connector APIs.

• E w , t i ∈ [ 0 , 1 ] E^{i}{w,t}\in[0,1] is exposure to platform volatility. A decoupled workflow has lower exposure than a workflow tightly coupled to one model or vendor. • α i \alpha{i} and ζ i \zeta_{i} translate local change pressure and platform volatility into debt growth. • Π [ 0 , 1 ] ​ [ ⋅ ] \Pi_{[0,1]}[\cdot] truncates the value to the unit interval. Analytically, this equation captures persistence, accumulation, remediation, and platform-driven 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 R , reducing Q Q , increasing G 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: D w , t + 1 = Π [ 0 , 1 ] ​ [ D w , t + Δ w , t a ​ c ​ c − Δ w , t r ​ e ​ m ] . D_{w,t+1}=\Pi_{[0,1]}\left[D_{w,t}+\Delta^{acc}{w,t}-\Delta^{rem}{w,t}\right]. (3) Here Δ w , t a ​ c ​ c \Delta^{acc}{w,t} is newly accumulated workflow-level debt during the period and Δ w , t r ​ e ​ m \Delta^{rem}{w,t} is workflow-level 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. 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 D w , t = Π [ 0 , 1 ] ​ [ ∑ i ∈ ℐ ω i ​ d w , t i + ∑ i < j ω i ​ j ​ d w , t i ​ d w , t j ] . D_{w,t}=\Pi_{[0,1]}\left[\sum_{i\in\mathcal{I}}\omega_{i}d^{i}{w,t}+\sum{i<j}\omega_{ij}d^{i}{w,t}d^{j}{w,t}\right]. (4) Here D w , t ∈ [ 0 , 1 ] D_{w,t}\in[0,1] is the normalized Agentic Technical Debt index, ℐ \mathcal{I} is the set of debt components, ω i ≥ 0 \omega_{i}\geq 0 are component weights, and ω i ​ j ≥ 0 \omega_{ij}\geq 0 are coupling weights. A dashboard can report 100 ​ D w , t 100D_{w,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 ω i ​ j = 0 \omega_{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 P w , t A ​ T ​ D = ∑ i ∈ ℐ c ¯ i r ​ e ​ m ​ d w , t i + ∑ i < j c ¯ i ​ j c ​ o ​ o ​ r ​ d ​ d w , t i ​ d w , t j + c ¯ w , t r ​ e ​ t ​ e ​ s ​ t . P^{ATD}{w,t}=\sum{i\in\mathcal{I}}\bar{c}^{rem}{i}d^{i}{w,t}+\sum_{i<j}\bar{c}^{coord}{ij}d^{i}{w,t}d^{j}{w,t}+\bar{c}^{retest}{w,t}. (5) P w , t A ​ T ​ D P^{ATD}{w,t} is the estimated debt principal in dollars. c ¯ i r ​ e ​ m \bar{c}^{rem}{i} is the estimated cost to fully remediate component i i , c ¯ i ​ j c ​ o ​ o ​ r ​ d \bar{c}^{coord}{ij} is the coordination premium created by coupled liabilities, and c ¯ w , t r ​ e ​ t ​ e ​ s ​ t \bar{c}^{retest}{w,t} is the testing and revalidation cost required after remediation. This model is useful in 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 w in period t t , let N w , t N_{w,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, S ​ T ¯ w , t = 1 N w , t ( C w , t e ​ v ​ a ​ l + C w , t m ​ o ​ n ​ i ​ t ​ o ​ r + C w , t r ​ e ​ t ​ r ​ y + C w , t e ​ s ​ c ​ a ​ l ​ a ​ t ​ e + C w , t r ​ e ​ v ​ a ​ l ​ i ​ d ​ a ​ t ​ e + C w , t l ​ a ​ t ​ e ​ n ​ c ​ y + C w , t t ​ o ​ k ​ e ​ n + C w , t s ​ e ​ c ​ u ​ r ​ i ​ t ​ y ) . \begin{split}\overline{ST}{w,t}=\frac{1}{N{w,t}}\Big(&C^{eval}{w,t}+C^{monitor}{w,t}+C^{retry}{w,t}+C^{escalate}{w,t}+C^{revalidate}{w,t}+C^{latency}{w,t}\ &+C^{token}{w,t}+C^{security}{w,t}\Big).\end{split} (6) In Equation 6 , C w , t k C^{k}{w,t} is the total cost in category k k during period t t . This expression is appropriate for a managerial dashboard because it reports a unit cost: the recurring burden per completed transaction. To populate the dashboard, however, each C w , t k C^{k}{w,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 k Measurement approach Typical data source Evaluation and test maintenance Model calls, judge calls, test infrastructure, expert review time Evaluation logs, test records, reviewer hours Monitoring and observability Dashboard cost, trace storage, alert review, routine operations time Observability tools, log storage, incident queues Retry and repair Extra model calls, extra tool calls, self-repair loops, manual repair work Agent traces, tool-call logs, retry counters Escalation and exception handling Escalated cases times average handling time and labor rate Ticket queues, approval logs, operations records Revalidation after change Retesting and approval after model, prompt, tool, policy, or context changes Release records, model-version logs, validation plans Latency and delay Excess latency relative to target times delay cost, plus SLA or abandonment cost Latency dashboards, SLA records, conversion or productivity estimates Token, compute, and context processing Expected tokens per transaction times unit cost, plus compute and tool-call charges Model bills, token logs, context retrieval logs Security and guardrail maintenance Security flags, input/output guardrail reviews, adversarial test updates Security logs, guardrail logs, red-team records 5.2 Total and Average Stochastic Tax Let T ​ S ​ T w , t TST_{w,t} denote total stochastic tax for workflow w w in period t t . Let 𝒦 \mathcal{K} denote the eight cost categories in Table 3 . Then T ​ S ​ T w , t = ∑ k ∈ 𝒦 C w , t k . TST_{w,t}=\sum_{k\in\mathcal{K}}C^{k}{w,t}. (7) The per-transaction tax reported on a dashboard is S ​ T ¯ w , t = T ​ S ​ T w , t N w , t . \overline{ST}{w,t}=\frac{TST_{w,t}}{N_{w,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, 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 U w , t U_{w,t} Positive count or index Adoption or usage exposure, such as transactions, active users, teams, or distinct usage contexts. In the simulation, U = N U=N . S w , t S_{w,t} Positive count or index Surface area, such as tools, connectors, context sources, permissions, APIs, or external systems. H w , t H_{w,t} Positive count Workflow horizon, measured as the number of dependent agentic steps or the effective depth of the action chain. A w , t A_{w,t} [ 0 , 1 ] [0,1] Autonomy and action criticality: 0 = advisory, 0.5 = approval-required, 1 = direct execution in external systems. Θ w , t \Theta_{w,t} [ 0 , 1 ] [0,1] 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 A and Θ \Theta 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 operating-exposure amplifier. The baseline floor is what the workflow would cost at zero Agentic Technical Debt and at reference operating conditions. The debt amplifier, Φ k ​ ( D w , t ) \Phi_{k}(D_{w,t}) , is a function of D w , t D_{w,t} and captures the effect of accumulated Agentic Technical Debt . The operating-exposure amplifier, Ψ k ​ ( U w , t , S w , t , H w , t , A w , t , Θ w , t ) \Psi_{k}(U_{w,t},S_{w,t},H_{w,t},A_{w,t},\Theta_{w,t}) , captures adoption, surface area, workflow horizon, autonomy, and inherent model variability. For each category k k , define C w , t k = ( F k + V k ​ N w , t ) ⏟ baseline floor ⋅ Φ k ​ ( D w , t ) ⏟ debt amplifier ⋅ Ψ k ​ ( U w , t , S w , t , H w , t , A w , t , Θ w , t ) ⏟ operating-exposure amplifier . C^{k}{w,t}=\underbrace{\left(F{k}+V_{k}N_{w,t}\right)}{\text{baseline floor}}\cdot\underbrace{\Phi{k}(D_{w,t})}{\text{debt amplifier}}\cdot\underbrace{\Psi{k}(U_{w,t},S_{w,t},H_{w,t},A_{w,t},\Theta_{w,t})}_{\text{operating-exposure amplifier}}. (9) The variables and parameters in Equation 9 are:

• F k ≥ 0 F_{k}\geq 0 is the fixed or semi-fixed cost of category k k in a period, such as maintaining an evaluation suite or observability pipeline.

• V k ≥ 0 V_{k}\geq 0 is the baseline variable cost per completed transaction in category k k .

• N w , t N_{w,t} is completed transactions.

• D w , t D_{w,t} is the normalized Agentic Technical Debt index from Equation 4 .

• U w , t U_{w,t} , S w , t S_{w,t} , H w , t H_{w,t} , A w , t A_{w,t} , and Θ w , t \Theta_{w,t} are the operating-exposure variables defined in Table 4 . • Φ k ​ ( ⋅ ) \Phi_{k}(\cdot) and Ψ k ​ ( ⋅ ) \Psi_{k}(\cdot) 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 ​ ( D w , t ) = 1 + β k ​ D w , t , β k ≥ 0 , Φ k ​ ( 0 ) = 1 . \Phi_{k}(D_{w,t})=1+\beta_{k}D_{w,t},\qquad\beta_{k}\geq 0,\qquad\Phi_{k}(0)=1. (10) The coefficient β k \beta_{k} is the debt sensitivity of category k k . If β r ​ e ​ t ​ r ​ y = 2.5 \beta_{retry}=2.5 , then moving from D = 0 D=0 to D = 1 D=1 multiplies retry-related cost by 3.5 3.5 , holding other drivers fixed. Larger values of β k \beta_{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 \beta_{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 increa