Prompt Asset Depreciation: The Maintenance Schedule Your AI Team Doesn't Keep

Engineering leaders are comfortable with the idea that code rots. Dependencies need updating, infrastructure has lifecycle management, certificates expire on a calendar nobody disputes. Yet the prompt repository gets treated as a write-once-read-many artifact — even though it defines how your product talks to a probabilistic engine that ships behavior changes every six weeks.

The system prompt tuned six months ago against the model that was current then is still in production. The few-shot examples chosen against a tokenizer that has since changed are still being injected on every call. The reranker prompt was tuned against an embedding endpoint the vendor deprecated last quarter. Nobody scheduled a review. Nobody is going to.

This is not a hypothetical failure mode. When one team migrated their prompt suite — meticulously stabilized against GPT-4-32k — to GPT-4.1 and GPT-4.5-preview, only 95.1% and 97.3% of their regression tests passed. A 3-5% silent quality regression is not a rounding error in production; at any non-trivial scale it is a customer-visible degradation that nobody on the team intentionally shipped. And those are the teams that even had a regression test suite. The median team's "regression test" is whatever vibes the on-call engineer formed during the last incident.

The category we are missing is prompt asset depreciation: a maintenance discipline that treats every production prompt as a depreciating asset with a known lifespan, not a constant.

The Three Decay Modes Nobody Tracks

A prompt does not need to be edited to silently degrade. There are at least three independent decay vectors, and most teams have telemetry for none of them.

Model drift under your feet. The provider ships a checkpoint update. Refusal style changes. JSON formatting changes — the model that used to emit {"foo": "bar"} now sometimes emits ```json\n{"foo": "bar"}\n```, and the parser that handled the first format catches a low-volume exception that nobody routes to a human. Your API still returns 200. Your latency dashboard still looks fine. The slow-moving curve is a quality regression that compounds over weeks.

Tokenizer churn raising the bill. A vendor swaps tokenizers between minor versions. The same English prose that tokenized to 1.0x last month tokenizes to 1.3x this month — or in adversarial cases, 3x. Your few-shot examples, your boilerplate system prompt, your boilerplate output instructions all suddenly cost more, and the cost regression is invisible in your aggregate dashboard because traffic also grew.

The world moved while the prompt didn't. Last quarter's product rules referenced a tier you no longer offer. Last quarter's few-shot example demonstrated calling a tool whose schema has since changed. The prompt is still passing eval because the eval was frozen at the same time the prompt was. Both are out of sync with reality.

The pattern in all three: the prompt is correct as of the day it was written and incorrect as of today, and nothing in the team's calendar marks the gap.

The Maintenance Discipline That Has to Land

The fix is not glamorous. It is the same discipline you already apply to certificates, dependency upgrades, and runbooks — extended to a class of asset most teams haven't named yet. Four primitives:

Every production prompt has an owner. Not "the AI team" — a person. If the person leaves, the prompt enters a review queue automatically; orphaned prompts are the load-bearing components nobody can explain, and they are the ones that fail loudest when the model finally changes underneath them.

Every prompt has a last-reviewed date and a revalidate-by date. Default the revalidation interval to one quarter. Some prompts (high-traffic, customer-visible, financially-relevant) should be tighter. Some (internal tooling, low-stakes summarization) can be looser. The point is not the specific number — it is that "should we revalidate this?" stops being a vibe and becomes a date that comparison operators can decide.

Drift is a number, not a vibe. Between the last review and now, run the same eval against the current production model. The delta is your evidence. If it's flat, log it and move on. If it's negative, you have a forensic question — is it the model, the prompt, the eval judge, or upstream input distribution? — and you have it before a customer raises a ticket.

A depreciation runbook routes overdue prompts. Tooling flags any prompt whose revalidate_by has passed and routes it to a review queue with a stated SLA. Most companies already have this pattern for expiring secrets and certificates; the same scheduler can run prompts.

The piece that scales this beyond a checklist is ownership of the system itself. Someone has to maintain the registry, run the cadence, and chase the owners of overdue prompts. Call this the prompt steward — part librarian, part ML engineer, part product manager. The role is structurally distinct from the engineers shipping new features, because the new-feature engineer's incentive is to ship the next thing, not to revalidate last quarter's thing. If you don't fund this role explicitly, it falls onto whoever happens to debug the next incident, which means it falls onto nobody until something breaks.

A "prompt-of-the-week" forcing function is the lightweight version: the AI on-call rotation includes revalidating one prompt past its threshold each week. It does not replace a steward, but it keeps the queue from going entirely unread.

The Cost Frame Leaders Don't Surface

Engineering leaders ask for the cost of maintenance budgets and reject them. They almost never ask for the cost of not maintaining, because nobody bills it monthly. Three line items that should be on the slide:

Silent quality regressions compound. A 3% drop on the eval suite this quarter does not feel like a fire. Two more model upgrades and a reranker swap later, you are 8% below where you were a year ago, and nobody can point at the commit that did it because no commit did it.

Token consumption drifts upward. Models get better at instructions but verbose by default; tokenizers churn; the team adds a few defensive lines to the system prompt after each incident and never removes them. Your token spend per task grows 10-20% a year against a flat user base, and the line item is invisible against general traffic growth.

The portability tax compounds quarterly. Every quarter a prompt remains pinned to a specific provider's tics — JSON-mode quirks, refusal-style assumptions, stop-sequence handling — the cost of switching providers grows. When the cheaper model arrives, the team that hasn't been maintaining for portability discovers the migration is a quarter of work, not a config change.

The discipline pays for itself the first time it converts a six-week migration into a one-week migration. It pays for itself a second time the first time it catches a silent regression before a customer does. The hard part is funding it before either of those things has happened in a memorable way.

The Org Failure Mode

Most teams that get this wrong don't get it wrong technically. They get it wrong organizationally. The platform team owns the prompt registry. The product team owns the prompts. Neither team owns the maintenance, because maintenance is a verb and registries are nouns. The result is a pristine versioning system whose contents have not been touched since the feature launched.

The pattern that works in practice is some version of: the platform team owns the infrastructure (registry, eval runner, scheduler that flags overdue prompts), the product team owns the content (the actual prompt and its eval), and a named steward owns the cadence (chasing owners, escalating overdue items, ratifying sunset decisions). Three roles, all named. The moment any of them is "the team's responsibility" instead of a person's, the cadence dies inside two quarters.

The other failure mode is the orphaned-prompt problem. Engineers leave. Features get deprioritized. The prompt is still in production because nobody has a reason to remove it and removing it is not on anyone's quarter. A sunset path — explicit retirement of prompts whose feature has been deprioritized or whose owner has left without a successor — is part of the same discipline. A prompt that nobody owns is not an asset; it is a liability whose ownership defaulted to whoever is on-call when it breaks.

What the Realization Actually Says

The framing I want engineering leaders to internalize: a prompt is a dependency on the state of the world at the time of authorship. The model behavior, the tokenizer, the product rules, the upstream tools, the user distribution — all of these were one specific configuration the day the prompt was written. The world has moved. If the prompt has not been revalidated against the world that exists now, you do not know whether it still works; you know it did work, on a day that has passed.

That sentence is identical in shape to the one we already accept about code dependencies, security patches, and certificate expirations. The reason teams haven't extended it to prompts is not that the analogy is weak — it is that prompts are text in a config file, they look free to keep around, and they degrade silently in a way that does not fire pagers. None of that is an argument against the discipline. It is an argument for instrumenting the silence.

The teams that will own the next decade of AI product work are not the ones with the cleverest current prompts. They are the ones with the boring schedule that says: every quarter, every prompt, every owner, every eval delta. Boring is the point. Boring is what depreciation looks like when you have actually budgeted for it instead of accepting it as a balance sheet of invisible technical debt with a rate of accrual nobody reports.