Ten Ways AI-Enabled Teams Decay While the Dashboard Stays Green
Five questions about last week will tell you more than your adoption dashboard managed all quarter. Ten failures that only show up at agent volume, each with the check that catches it.
Start with five questions about last week.
How many agent-authored pull requests got approved without anyone opening the diff? When did someone last delete a skill from your harness? What did agent inference cost last month, and who owns that number? When an agent hit an ambiguous requirement, did it ask or did it decide? And if you changed the prompt that writes your production code, what test told you the change was safe?
If three of those landed uncomfortably, the rest of this will be familiar.
There's a companion piece about the top issues companies face starting AI adoption. That one covers controls that were never installed. This one covers controls that were installed, worked, and then stopped working while every number on the dashboard kept improving.
The claim underneath all ten is narrower than the usual version. Scaled agent use creates, amplifies, or makes consequential a set of failures that adoption metrics are not built to diagnose. The measured signal keeps improving while the thing you actually care about does not, because the two measure different quantities and nobody wired up the second one.
Some of these have a version that shows up in week one. Where that's true I say so, because the gap between the early form and the late form is usually where the fix lives.
Most agentic development best practices in circulation were written for teams standing this up for the first time.
These are for teams already running agents past the pilot stage.
Ten items, four clusters. Each gives you a symptom you can check, the mechanism underneath it, a correction, the observable that says the correction is working, and what it does not fix.
The observables are named here, not specified. Before any of them is a real measurement you have to settle what event counts, what it counts against, over what window, and who reads the result. Where I give a number, treat it as a starting value to calibrate against your own baseline, not a threshold to adopt.
Your adoption dashboard answered a question you already finished answering
Usage, license utilization, acceptance rate, PR throughput. Every one was the right instrument while the open question was whether the tools would get picked up at all. They got picked up, and the question closed while the instrument stayed.
What replaced it is a harder question none of those metrics reaches: did the work get better, and can you show it. DORA's 2025 State of AI-Assisted Software Development lands on AI functioning as an amplifier of whatever your existing process already is, which is uncomfortable if that process was mediocre and is now mediocre at higher volume. Separate DORA work describes a verification tax, the review load that grows alongside generated output.
That's the shape of everything below. Output rate is elastic. Review capacity, ownership clarity, and standards are not, at least not without someone deciding to change them.
Most of what follows is AI agent governance in the practical sense: who reviews what, who owns which number, what an agent is allowed to reach. That is the delivery-operations half of the term, not its regulatory-exposure or model-eval half. Very little of it is about agentic coding tools themselves.
Two of the corrections below tell you to remove things. That is deliberate. It runs against the instinct most teams bring to a struggling harness, which is to add another instruction. If your harness was built when the models were weaker, some of what you added is now working against you, and adding more will not surface it.
Oversight became a keystroke while everyone kept calling it review
In mature agent setups this one never announces itself. Approval times get faster every sprint, and that reads as fluency. It is usually the two failures below, running for months.
Approval stopped being a decision and became a reflex
The tell looks like improvement, which is why it survives: approval latency trending down while change size and complexity hold flat. Pair it with escape rate, defects reaching production per released change, over a fixed window. If approvals are getting faster on changes that aren't getting simpler, and escapes are climbing on stable coverage, review is no longer happening.
The week-one version is people approving carelessly because the tooling is new. The version that matters here differs in kind: approval at a volume no human review process was sized for. Salesforce Engineering published a useful account, roughly 30% more code volume, larger pull requests, review latency climbing, submissions outrunning the people available to read them. Read it as a review-load case study rather than a measured queueing result.
The mechanism is arithmetic. Agent output rate scales with adoption, and keeps scaling. Review capacity scales with headcount and attention, which did not move. AI agent oversight that was real at the old volume becomes ceremonial at the new one without anybody changing the policy.
Correction. Route review by risk. Define which change classes get full read, which get sampled, and what conditions escalate a sampled change to a full one. The engineering lead accountable for release quality owns the routing rules. You buy honest depth on the changes that can hurt you, in exchange for admitting you were never reading the rest.
Verification. Approval latency and escape rate, as a pair, per change class, over a fixed window. Either one alone is misleading.
What it does not fix. Review capacity isn't fixed; staffing, decomposing large pull requests, and automated checks all move it, so treating it as a constant is a choice. Sampling has its own failure modes: it misses the rare severe defect and it can be gamed if the rule is predictable. Stable test coverage says nothing about test quality.
The agent started deciding things nobody delegated
Watch for decisions that arrived without a conversation. An interface contract chosen, an error-handling convention picked, a library selected, and nobody remembers discussing it. The requirement was ambiguous, and something resolved the ambiguity.
This one has a genuine early-adoption form. An autocomplete can't decide an interface contract. What changes with real delegation is depth: an agent running a multi-step task resolves several ambiguities before anyone reads the output, and the resolutions are invisible because they arrive as working code.
An underspecified instruction carries no failure mode for the agent. Nothing in the loop makes stopping cheaper than proceeding, so it proceeds. A 2026 preprint on action-boundary violations (arXiv:2607.02294) tested underspecified DevOps instructions across five agent and model configurations and found violations in a majority of runs. It's a v1 preprint on a benchmark, so read it as directional.
Correction. Install assumption surfacing as a standing instruction in the harness. The agent returns unclarified questions and the assumptions it would otherwise make, before acting. In Claude Code this lives in CLAUDE.md; Codex and every other serious agent environment has an equivalent.
Verification. Count clarification returns per task class over a month, against a sample of tasks you have separately labelled ambiguous. A flat zero across known-ambiguous work means the instruction is not firing. On its own it might only mean the work was clear.
What it does not fix. Agents also clarify, refuse, and defer on their own, so "it always guesses" overstates it. A standing instruction is bypassable by conflicting context, prompt injection, and plain noncompliance. Where a decision genuinely cannot be delegated, the durable control is a system-enforced action boundary; the instruction is only the cheap layer.
The scaffolding you built for weaker models is now a bill you keep paying
Every instruction file, skill, subagent, and process step you added answered a real limitation at the time. The models moved. The scaffolding stayed, because nothing in a normal workflow schedules a review of it. These three compound in the same direction: more carried context, more tokens, less comprehension.
Your harness is fitted to a model generation that already passed
I keep seeing the same thing in harness repositories: two dozen skill definitions, a third of them written against a model that shipped eighteen months earlier, and nobody able to say which ones still fire on a given run. The surprising part is what happens when you cut them. I've watched teams delete a third of the inventory and get better results rather than merely cheaper ones, because the instructions that survived stopped competing with ones that had gone stale.
This is the item with no phase-one form. You need an accumulated harness and a capability gap to be behind before it exists at all.
Anthropic's guidance on context engineering makes the underlying case: context is a finite resource, and stronger models need less prescriptive scaffolding than weaker ones did. That supports the direction. It does not prove your inherited scaffolding became a net tax, which is a hypothesis you test locally.
Correction. Put harness pruning on a cadence, quarterly is defensible, with an explicit removal test: cut the component, run a comparison, keep the cut if quality holds. The harness owner owns the cadence.
Verification. Tokens actually injected per invocation, before and after, alongside task success rate.
What it does not fix. Model improvement is only one reason scaffolding goes obsolete. Some of it encodes policy or domain knowledge that no model capability replaces, and cutting that costs you something real. Pruning without a comparison eval is how reliability drops.
Your instruction files are longer than anyone has read
Open your CLAUDE.md, your agent configs, your skill definitions, and ask when a human last read one end to end. In a phase-one setup there are two files and the answer is easy. In an accreted corpus the honest answer is usually nobody, and that includes the model, which works from whatever fraction survived retrieval and truncation.
Instruction files accrete because adding feels safe and deleting feels risky. Nobody has ever been blamed for a paragraph they left in.
Correction. Set a length budget per instruction artifact and hold additions against it, so adding requires removing. Pair it with a readability test: a new team member reads the file and can state what it constrains.
Verification. Tokens transmitted per invocation per artifact, tracked over time. A budget nobody measures is a preference.
What it does not fix. A length cap can cut a constraint you needed, and human readability is poor evidence of machine effectiveness, particularly where context is retrieved on demand. The budget number is context-dependent, so calibrate it against task performance instead of picking a round number and defending it.
Nobody owns the inference bill
Ask who is accountable for agent spend. In most orgs running agents at volume, the answer is a shrug toward whoever holds the vendor relationship. Seat-based tooling had a predictable bill, so nobody built the muscle. Agentic usage is variable by construction, and the variance only shows at volume.
Agentic tasks consume substantially more than chat-style usage. A 2026 analysis of agentic coding tasks on SWE-bench Verified (arXiv:2604.22750) put the comparison as high as three orders of magnitude, driven by input tokens the model re-reads rather than output it generates. That is a benchmark result rather than your operating multiple, so read it as a warning about variance.
Correction. Per-team and per-workflow attribution first, before any cap. Attribution has to separate seat fees, API spend, cached versus input versus output tokens, retries, and parallel agents. Those have different fixes.
Verification. Cost per successful outcome, by workflow. Raw token spend tells you almost nothing on its own.
What it does not fix. Attribution exposes spend without establishing value, and caps are worse than they look: they truncate valuable work and push usage off the ledger into personal accounts.
You gate the application code and ship the thing that writes it untested
Look at the change-management asymmetry in your own repository. A one-line change to a service gets a pull request, a review, a test run, and a deploy gate. A change to the prompt that generates fifty such services gets saved. Same repository, same week, and nobody decided it should work that way.
The harness has no regression harness
Ask what test runs when someone edits a skill definition or an agent config. In most setups nothing runs, because the delivery system was never classified as software and inherited none of the discipline applied to the product. An untested config exists from day one. What makes this the late version is that the surface has grown until it materially shapes output.
This is distinct from evals for a shipped AI product, which is its own well-covered problem. This is evals for the system that builds the product.
Correction. A small fixed eval set for the harness, versioned alongside it, run on change. Ten to twenty cases covering the paths you depend on.
Verification. Eval pass rate recorded per harness commit.
What it does not fix. Harness artifacts do not always have the widest blast radius, so treat that as the common case. Fixed eval sets also go stale and get overfit. They need holdouts, cases pulled from real production failures, and a refresh rule.
Agent permissions are still set for the pilot
Check what an agent in your environment can actually reach: filesystem scope, credentials, network egress. Compare that to what it needed when three people tried it on a side project. A permissive posture is reasonable at ten tasks a week and indefensible at a thousand, and nothing forces the review when the volume changes.
The phase-one version is a permissive pilot. The version here is that the posture was set once, for a smaller blast radius, and the radius grew underneath it.
Correction. Tier permissions by blast radius. This is an architecture decision, owned by whoever owns platform security, and better prompting does not substitute for it. Microsoft's and IBM's published AI agent governance material both give usable ground on agent identity and least privilege; either is a reasonable starting frame.
Verification. A permission review triggered by a scope change, with a date on it.
What it does not fix. Blast radius alone is an incomplete axis; likelihood, data sensitivity, reversibility, and detectability all matter. Shared credentials, delegated MCP access, and privilege chaining all route around a nominal tier.
The code is getting harder to change and nothing on your dashboard says so
GitClear's 2026 maintainability analysis, across roughly 623 million analyzed changes from 2023 to 2026, reports duplication up 81%, error-masking constructs up 47%, refactoring line moves down 70%, and cross-file connectivity down 35%. These are longitudinal observational signals rather than causal estimates, each with its own denominator and baseline, so resist reading them as four comparable measures of one thing.
Your throughput metrics count additions. None of those four appears on a standard delivery dashboard, which is the actual problem. AI technical debt of this kind accumulates silently by construction, because the instruments were built to watch volume.
Correction. Instrument the signals you can measure in your own repository. Give each one a review trigger and an owner. Which signal, what baseline, whose review.
Verification. The signals plotted against your own baseline period, not the study's numbers.
What it does not fix. These are proxies for maintainability, not measurements of it, and a review trigger detects a condition without correcting the debt behind it.
Your definition of done never changed
Both of the last two are the same failure wearing different clothes. Something got cheap, the process description did not follow, and the gap only became visible once agents ran at volume inside it.
The process redesign happened in a document
The announcement went out. Shift-left QA, better requirements, guardrails at the right stages. Now check whether any of it constrains a single agent run today. If requirements are still thin, the model is filling those gaps with its own decisions, at volume, which is the fourth failure arriving through a different door.
Do not read this as guardrails never installed. That is the phase-one case and it belongs to the companion article. The version here is subtler. The process description was adequate while humans wrote most of the code, and it still exists, but it was never re-derived for work arriving at agent volume. This is the third case the opening claim names: nothing decayed, and the gap the process always had started to matter.
Correction. Pick the single upstream artifact that most constrains agent output, usually the requirement or the spec, and make it a real gate with a named owner.
Verification. Gate compliance rate, plus exception count.
What it does not fix. Gating one artifact does not install shift-left QA by itself, and a gate can simply compel a low-quality document.
Done still means the tests pass
Ask what "done" required in 2023 and whether the answer changed. Implementation got cheaper. Observability, rollback path, and spec traceability did not, and they are now the expensive parts. A definition of done calibrated to a cost structure that shifted is optimizing for the wrong scarcity.
Correction. Re-derive done from what is expensive now, and scope it explicitly by change class.
Verification. Per change class, the percentage of merged work meeting the current definition, measured against merges rather than asserted in a wiki.
What it does not fix. Implementation has not become uniformly cheap, so the premise is conditional. Re-deriving only from current cost drops safety and regulatory requirements that were never cost-justified in the first place, and a universally expanded definition of done just slows everything down.
The check that matters is whether anything got harder to do badly
| # | The tell you can check | What proves the correction is working |
|---|---|---|
| 1 | Approval latency falling, change complexity flat | Approval latency and escape rate, paired, per change class |
| 2 | Skills written for a model generation you no longer run | Injected tokens per invocation, against task success rate |
| 3 | Instruction files nobody has read end to end | Tokens transmitted per artifact, tracked over time |
| 4 | Decisions that arrived without a conversation | Clarification returns per task class |
| 5 | A redesign document that constrains no agent run | Gate compliance rate plus exception count |
| 6 | Nothing runs when a skill definition changes | Eval pass rate per harness commit |
| 7 | No named owner for agent spend | Cost per successful outcome, by workflow |
| 8 | Permissions still sized for the pilot | A dated permission review triggered by scope change |
| 9 | Duplication and error-masking climbing unobserved | Structural signals against your own baseline |
| 10 | Done still means the tests pass | Percentage of merged work meeting the current definition, by change class |
Nine of those verifications can start inside a sprint. The tenth, the structural signals, needs a baseline period before it says anything, so start it first and read it last.
What connects all ten is decision rights. Somebody has to own approval routing, somebody has to own the harness, somebody has to own the inference ledger, and somebody has to own what done means now. In most orgs that got adoption right, those four owners were never named, because naming them wasn't necessary while output volume was small. The volume changed. The org chart didn't.
Pick the two tells that made you most uncomfortable. Find out who owns them.
AI Transparency Notice: This article and its accompanying images were created with the assistance of generative AI. The author directed the content, contributed the underlying ideas and analysis, and reviewed the final publication.
