Agentic technical debt: a governance framework for AI agents

Every team that has shipped an agentic AI workflow knows the pattern: a prompt patch here, a retry wrapper there, a memory hack that fixes Tuesday’s bug and creates Thursday’s. The system works — until it doesn’t, and nobody can explain why the agent called the wrong tool or looped five times on a request that used to complete in one.

A research paper from the University of Pittsburgh and Ejento AI, forthcoming in Communications of the ACM (October 2026), puts a name and a measurement framework on this problem. It introduces agentic technical debt — the accumulated liability when prompts, memory, tool schemas, orchestration graphs, and control policies are patched together faster than they can be validated and governed — and stochastic tax, the recurring operating cost of keeping probabilistic agent behavior within acceptable bounds.

The distinction matters. Debt is a stock that grows over time. Tax is a flow you pay on every transaction. Confusing the two leads to the wrong fix: you refactor when you should be monitoring, or you monitor when you should be redesigning. Knowing which layer of your agent is failing — the reasoning loop or the structural harness around it — determines which one you are dealing with.

Key takeaways

• Agentic systems accumulate technical debt through five specific mechanisms: autonomy, semantic ambiguity, stochasticity, persistent state, and latency amplification.
• Stochastic tax — the per-transaction cost of evaluation, retries, escalation, and monitoring — is a separate, recurring expense that does not shrink by refactoring alone.
• Five governance controls (golden-set evaluation, tool schema contracts, model gateways, graduated autonomy, and workflow redesign) make both debt and tax visible and manageable.
• The goal is not eliminating stochasticity but bounding its cost and making it auditable.

From hidden technical debt to agentic technical debt

The idea that ML systems carry hidden maintenance costs is not new. In 2015, Sculley et al. published “Hidden Technical Debt in Machine Learning Systems” at NeurIPS — a paper that has shaped how the industry thinks about production ML ever since. Its central observation: only a tiny fraction of a real-world ML system is the model itself. The rest is data pipelines, configuration, serving infrastructure, feature stores, and monitoring glue. That paper gave us the vocabulary of pipeline jungles (data-preparation logic that becomes an unmaintainable tangle of scrapes, joins, and intermediate files), glue code (the massive supporting infrastructure around the model), hidden feedback loops (where a model’s output silently influences its own future training data), and the CACE principle — changing anything changes everything, because entangled features make isolated changes impossible.

The agentic technical debt framework explicitly builds on Sculley’s foundation, but argues that agents introduce failure modes that the 2015 model did not anticipate. A predictive ML system takes an input and returns a score. An agent reasons over multiple steps, calls tools, writes to databases, and adapts through memory. A single prompt determines which tool is called, which record is modified, and which customer receives a decision. This couples probabilistic output to real-world consequence — a pairing absent in Sculley’s framework.

The parallels — and the gaps — become visible when you line up the concepts:

• Pipeline jungles → orchestration jungles. Sculley’s data-preparation tangles have an agentic counterpart: multi-agent workflows where sequential handoffs, shared state, and retry wrappers become so intertwined that modifying one agent requires revalidating the entire chain.
• Glue code → prompt wrappers and retry logic. The supporting infrastructure around an ML model becomes the prompt patches, fallback chains, and error-handling shims around agent calls — what is now called the harness in modern agent architecture. These are often written under deadline pressure and never revisited.
• CACE principle → semantic ambiguity. Feature entanglement in ML means changing one input changes the output in unpredictable ways. In agentic systems, the equivalent is natural-language instruction: move one clause in a system prompt and the agent stops calling a tool it used to call reliably. There is no compiler to catch the regression.
• Hidden feedback loops → persistent state. A predictive model’s output can silently corrupt its training data over time. An agent’s memory does something analogous in real time: a decision that was correct at write time gets encoded into state that influences future actions long after the context has changed.
• Configuration debt → tool schema drift. Sculley warned about the accumulating cost of hard-to-reason-about configuration parameters. In agentic systems, the equivalent is tool schemas, model parameters, and orchestration graphs that interact in ways no single team member fully understands.

What Sculley’s framework did not need to account for — because traditional ML systems did not have it — is autonomy. A predictive model does not decide what to do next. An agent does. That principal–agent gap, and the stochastic tax it generates, is the core addition that the agentic technical debt framework contributes.

Worse, the standard prototyping workflow accelerates the problem. Teams patch prompts, add wrappers, and serialize handoffs before interfaces and policies are stabilized. Each local fix increases coupling among prompts, tool schemas, memory, and safety checks. Compose multiple agents into a larger workflow and the surface area for brittle orchestration expands with every node. As Databricks observed, the core agent loop is roughly 1% of production work — the other 99% is deployment, security, evaluation, monitoring, and context management.

Five mechanisms that drive debt accumulation

The paper identifies five recurring patterns. Recognizing which ones dominate your system tells you where to intervene.

Autonomy

The wider the gap between what you intended and what the agent actually does, the more you spend on oversight. In practice this shows up as review queues that grow faster than the team can clear them, and escalation paths that exist on paper but fire so often they become background noise.

Semantic ambiguity

A prompt that works reliably on one model version may break on the next, or behave differently when a provider adjusts safety filters. Version-controlling prompt text is easy; version-controlling its behavioral effect is not. Teams discover regressions in production, not in CI.

Stochasticity

Identical inputs can yield different plans, tool calls, or execution traces on successive runs. Reproducibility — the foundation of traditional testing — is no longer guaranteed. A test suite that passed yesterday can fail today with no code change.

Persistent state

A customer preference stored in one agent’s context may contradict a policy update another agent received — and neither agent knows. Memory that drifts out of sync across agents, or goes stale between sessions, is one of the hardest forms of agentic debt to detect because the symptoms surface far from the cause.

Latency amplification

A suboptimal LLM call costs seconds. Chain several together in a sequential workflow and the tail latency compounds into retries, timeouts, and cascading failures. Users experience this as unpredictable response times — fast most of the time, then inexplicably slow.

What is stochastic tax and why it changes your response

The five mechanisms above describe how debt accumulates. Stochastic tax is a different beast entirely — it is what you pay even after you have paid down the debt.

Traditional technical debt is a stock — a pile of design shortcuts that make future change harder. You pay it down by refactoring. Stochastic tax is a flow — a recurring per-transaction cost that exists because the same input to an LLM need not produce the same execution path. Sculley et al. did not need this concept because a trained ML model, given the same input, produces the same output. Agents do not. Even a perfectly governed agentic workflow still generates evaluation, monitoring, retry, escalation, and revalidation costs on every run. You cannot refactor your way to zero tax. You can only manage it.

A companion paper formalizes this with a measurement model and simulation framework. It defines stochastic tax as “the recurring operating burden of keeping stochastic agentic behavior within acceptable bounds in a business workflow.” The key insight: debt can amplify the tax, but the tax remains positive even when debt is minimized.

Think of it like owning a car. Technical debt is the deferred maintenance — the worn brake pads and the check-engine light you are ignoring. Stochastic tax is fuel, insurance, and tolls. Even a brand-new, perfectly maintained car still costs money every time you drive it. Ignoring the brake pads (debt) will make your insurance (tax) more expensive, but fixing them does not make fuel free.

How to measure it

The paper proposes a per-transaction metric:

Average stochastic tax = (evaluation + monitoring + retry + escalation + revalidation + latency + token + security costs) / completed transactions

Making this number visible is the first step toward controlling it. A production observability stack that tracks stochastic tax per workflow lets you compare agents, detect regressions after a model update, and decide where redesign is worth the investment.

To put the numbers in perspective: according to Atlan’s analysis, agent workflows consume roughly 19x more model tokens than simple inference — before accounting for tool fees, retrieval, observability, human review, or rework. Production costs run 5–15x higher than prototype costs. Most of that multiplier is stochastic tax: the overhead of running a non-deterministic system reliably.

Two scenarios that illustrate the difference

Debt scenario: A prompt with conflicting instructions causes intermittent tool-call failures. The fix is structural — rewrite the prompt, add a schema contract, or move the constraint into a deterministic check. This is debt you can pay down.

Tax scenario: A well-governed workflow that still requires per-transaction evaluation, monitoring, and occasional human escalation. The system is sound, but probabilistic execution has a floor cost. You manage it with dashboards, budgets, and thresholds — not with a refactor.

The orchestration jungle

The paper describes an insurance workflow where specialized agents for auto, home, and life policies were chained sequentially. Each agent added latency. Each handoff introduced a failure point. Modifying one agent required revalidating the entire chain.

The design was logically sound and operationally expensive. The economic solution was not another prompt patch but a structural redesign — converting the sequential chain into a parallelized directed acyclic graph where independent agents run concurrently.

This pattern, which the authors call the orchestration jungle (echoing the pipeline jungle from Sculley et al.), is one of the most common debt traps in production agentic systems. If your workflow is a long chain of agents passing state to each other, every link in the chain is both a latency penalty and a change-propagation risk. Loop engineering design patterns like circuit breakers and bounded execution exist precisely to contain these failure cascades.

Five governance controls

The paper maps each accumulation mechanism to a specific governance control. If you are building an AI governance program from scratch, these five controls are where to start.

1. Golden-set evaluation and trace-level diffing

Maintain a versioned set of critical intents and edge cases. Before any deployment, run the agent against these inputs and diff the execution traces — not just the final outputs — against a known-good baseline. This catches behavioral regressions that output-only testing misses.

2. Tool schema contracts and deterministic checks

Treat tool interfaces like APIs with enforced contracts. Standards like the Model Context Protocol give agents a uniform way to discover and call tools — but the schema still needs validation on both sides. Validate inputs and outputs before and after every tool call. Move constraints that can be expressed deterministically (format validation, policy rules, range checks) out of the prompt and into code.

3. Model gateway and versioned registry

Abstract the foundation model behind a gateway that standardizes prompts, tool schemas, and response formats. When a provider updates a model or changes safety behavior, the gateway absorbs the change without forcing application rewrites. Pair it with a versioned registry of agents, prompts, and policies.

4. Graduated autonomy

Not all actions carry the same risk. The paper proposes a traffic-light model:

• Green actions (classifying tickets, routing requests) run autonomously — they are reversible and low-impact.
• Yellow actions (scheduling payments, modifying records within a threshold) proceed only within explicit limits or downgrade the agent to proposer mode.
• Red actions (writing to production databases, changing ERP master data) remain human-authorized by default.

When monitoring signals cross a threshold — a spike in retries, an unfamiliar tool-call pattern — the system can automatically downgrade autonomy, route to a more reliable model, or trigger a circuit breaker until revalidation completes. This graduated approach aligns with frameworks like the Digital Apprentice, which argues that autonomy should be “earned, not assumed” — promoted per-skill when evidence supports it, and demoted automatically when quality degrades.

Singapore’s Model AI Governance Framework for Agentic AI — the first government-issued framework specifically for agentic systems — codifies a similar four-level taxonomy and introduces Agent Identity Cards for standardized capability disclosure.

5. Workflow graph redesign

When stochastic tax is high and climbing, the answer may not be better prompts but a different graph. Sequential handoffs that could be parallel, agents that retry when a deterministic check would be faster, memory that is shared when it should be scoped — these are structural problems that monitoring alone cannot fix.

What this means for teams building with agents

If you are deploying agentic AI in production, three questions from this framework are worth asking today:

1. Can you distinguish debt from tax in your system? If your retry rate is high, is it because the prompt is fragile (debt) or because the task is inherently uncertain (tax)? The remediation is different.

2. What is your stochastic tax per transaction? If you cannot answer this, you cannot forecast operating cost, compare workflows, or detect regressions after a model change.

3. Is your autonomy graduated or binary? A system where the agent either runs freely or gets shut off entirely is missing the middle tier where most production value lives.

The full paper — Governing technical debt in agentic AI systems — is available on arXiv and will appear in Communications of the ACM in October 2026. For teams looking to build these governance instincts from the ground up, the Data Science Dojo LLM bootcamp covers agent architecture, tool orchestration, guardrails, and the production patterns that keep stochastic tax under control.