Measuring Prompt Duplication as an AI Program Cost Driver

Inference eats 85% of total AI budgets at the enterprise level. Most teams never look at that denominator closely enough. They watch the top-line AI number grow and call it adoption, when they should be asking what fraction of every dollar goes toward re-processing context the system already saw once.

Average monthly enterprise AI spend hit $62,964 in 2024, on track for $85,521 in 2025. That's a 36% jump in a single year, and at those numbers, a redundant slice of spend stops being a rounding error and becomes the thing someone has to defend in a planning meeting.

The lack of visibility is already changing behavior, and not for the better. Recent industry research found that one in four businesses is delaying or canceling AI projects outright because nobody can say with confidence where the spend is going. That's not caution. That's a program that lost track of itself and chose to freeze rather than fix the tracking, which is the worse of the two options every time.

None of that answers the harder question: what's actually driving the number up inside the workflows themselves?

How re-sent context and duplicated prompts become the largest line item in an inference bill

The Stanford Digital Economy Lab, in its 2025 paper "How Do AI Agents Spend Your Money?", found that agentic tasks consume up to 1,000 times more tokens than a simple code chat interaction. The driver is something other than the model. It's the environment around it: re-sent input context, the model re-reading things it was already told a few steps earlier, because nobody built a way to let it remember without re-feeding the whole history each time.

Duplication makes that worse, and this is where the real waste compounds. When three or four teams each write their own prompt for the same task, summarizing a support ticket, say, or drafting a contract clause, each version drags its own context payload behind it. That's not just wasted authoring time up front. It's redundant token spend every time any of those versions runs, forever, until somebody notices.

Stale prompts stack a second cost on top, and this one hides well because it looks like the system working correctly. Models today follow instructions more literally than they used to. That sounds like progress until a prompt with outdated rules baked in doesn't get quietly ignored anymore. It gets followed exactly, the model does what the old, wrong instruction says, and someone downstream has to catch the error and clean it up.

Token cost is a direct function of what sits in context. Duplication means more sits there, more often, run by more teams, at the same time. None of that gets cheaper on its own.

What Uber's AI budget collapse illustrates about the pace of cost accumulation

Claude Code adoption at Uber went from 32% to 84% of its roughly 5,000-engineer organization, a 52-point jump achieved in a matter of months. By April 2026, the entire annual AI budget was gone. Monthly API costs ran $500 to $2,000 per engineer, and nobody had a system in place to catch it before the number got that big.

Blame the mechanism, not the engineers. Adoption outran the thing that should have attributed cost to a specific workflow, prompt, or team before it ever had the chance to exist. Fifty-two points of adoption growth in three months will always outpace a measurement system built after the fact, no matter how good that system eventually turns out to be.

Without prompt-level attribution, there's no way to tell the difference between one well-run shared workflow and forty teams each quietly building their own version of the same thing. Uber's engineers weren't doing anything wrong individually. Collectively, they were paying for the same context, translated forty different ways, forty separate times.

How shadow AI turns prompt duplication into a compounding liability

A 2025 TELUS Digital Experience survey found that 68% of employees were accessing GenAI tools through personal accounts rather than anything the company approved, and 57% admitted to putting confidential information into a public AI tool at some point. Shadow AI doesn't just duplicate spend. It multiplies exposure at the same time, and treating those as two separate problems is the mistake most security teams make.

The compounding shows up in specific places: licenses duplicated across business units that never share a seat, redundant API calls quietly bloating the token bill, fragmented datasets cleaned and reformatted again and again because nobody kept the first version anywhere reusable. Ten separate personal or departmental plans run about 30% higher at list price than a single enterprise agreement covering the same seats, according to analysis from Torii. That's money left on the table before anyone even gets to the security question.

And the security cost is the bigger number. IBM's Cost of a Data Breach Report 2025 named shadow AI a top-three driver of breach costs for the first time. Organizations with high shadow AI usage faced average breach costs of $4.63 million, against $3.96 million for organizations with low or no shadow AI in the mix. A $670,000 gap, tied directly to visibility, or the absence of it.

A prompt built on someone's personal ChatGPT account is invisible to any measurement system that exists. It can't be versioned. It can't be audited. Nobody else can find it and reuse it, so the duplication it represents never becomes a number anyone can act on. It just sits there, quietly costing money and creating risk.

Shadow AI is a symptom, not the disease. A protocol like MCP starts to close the underlying disease: the absence of shared infrastructure for capturing, governing, and reusing AI work in the first place.

Why measuring prompt duplication requires treating prompts as versioned, attributed assets rather than ephemeral inputs

Nothing gets measured until it gets inventoried first. As long as prompts live scattered across someone's inbox, a Notion page, or hardcoded into a script, there's no unit to count, compare, or attach a cost to. Treating a prompt like a sticky note instead of an asset is the root error. Every downstream cost problem traces back to it.

Prompt management platforms are the floor, not the fix. They don't solve duplication by themselves, but they force a prompt to be treated as a reusable asset instead of a throwaway input, and that shift is the precondition for detecting duplication at all.

Measuring duplication for real requires a few specific things to exist:

• A registry that catalogs prompts with clear ownership, version history, and defined scope of use
• Attribution data linking every prompt execution back to a team, a workflow, and a token cost
• Deduplication logic that spots two prompts built independently by different teams doing functionally the same job
• Access controls that let a prompt be shared without handing the underlying data to everyone who touches it

Skip version control, and duplication stays invisible by design. A second team rebuilding a capability that already exists looks, in the logs, exactly like a first team building something genuinely new. There's no signal to tell them apart, so the org can't even ask the question.

The failure data backs this up hard. S&P Global Market Intelligence surveyed over 1,000 companies across North America and Europe in 2025 and found that 42% had abandoned most of their AI initiatives, up sharply from 17% the year before. The average organization scrapped 46% of its proofs-of-concept before they reached production, citing cost and governance concerns above everything else. That's exactly the pattern untracked duplication produces: money spent building the same thing badly, several times over, with no record of the first attempt to build on.

What MCP makes possible at the infrastructure layer that prompt management tools alone cannot deliver

Before MCP, connecting an AI application to a business system meant a custom connector for every model-and-tool pairing. Add a new model, and every existing tool connection needs rebuilding. Add a new tool, and every model needs a fresh connector to it. That complexity scales as M times N, not M plus N, and it turns ugly fast.

MCP flips that math. Each system exposes one standard interface. Each AI client speaks one standard protocol. Without a shared protocol, integration complexity rises quadratically as agents spread through an organization; with MCP, it rises linearly instead, and that gap is the whole argument for adopting it before the sprawl sets in rather than after.

Here's why that matters specifically for duplication. When every integration is custom-built, each team isn't just building a connector, they're rebuilding the context and prompts that go with it too. Standardize the integration layer, and the reason every team had to reinvent that context from scratch just disappears.

An MCP server becomes the unit of shared, governed context. A team defines the context, the permissions, and the tooling once, in one place, and any authorized agent or interface can call it afterward without rebuilding the underlying work. Permissions inherit rather than reset each time: when a user queries something through an MCP-connected source, the answer only draws from what that person already had access to. That's what makes sharing a prompt registry safe at enterprise scale instead of a security incident waiting to happen.

Waiting has a cost of its own here. MCP server downloads went from roughly 100,000 in November 2024 to over 8 million by April 2025, and Forrester predicts 30% of enterprise app vendors will ship their own MCP servers in 2026. Forrester's 2025 review also found integration cost reductions of 60% to 70% among teams that moved from point-to-point API connections to MCP-based architecture, and that figure isn't just connector upkeep. It reflects the elimination of redundant context-building work that used to happen on every single integration. Organizations that wait to govern this layer will hit the exact same sprawl problem they already have with prompts, just one level down.

How a governed MCP registry converts prompt duplication into a measurable, reducible number

A governed MCP registry turns the preconditions above into a running metric instead of a one-time cleanup project.

Every skill or prompt gets captured once, versioned, and published to a scoped registry, so a team can find and reuse it instead of building it from zero. Usage data across teams creates an actual denominator: if multiple teams are calling the same capability repeatedly, the registry surfaces that. And if several of those teams built their own separate version instead of reusing the one that already existed, the registry surfaces that too. That's the entire point of building it.

Token cost attribution becomes possible down at the workflow and prompt level, not just rolled up by department or model. Every agent action leaves an audit trail, which satisfies the governance requirement that makes sharing safe in the first place: who approved this version, when, and what changed since the last one.

That sets off a flywheel worth naming directly. Once a skill sits in the registry and people trust it, its marginal cost per use drops close to zero. The cost of building it the first time spreads across every team that reuses it afterward, instead of getting paid again and again by teams rebuilding it in isolation.

Scoped MCP servers mean a department gets governed access to shared context without a custom UI or IT getting pulled in every time. The skill travels to wherever the team already works, whether that's Claude, ChatGPT, Cursor, or Slack. Model agnosticism matters here too: business context, permissions, and reusable prompts need to tie to the organization's registry, not lock to one specific model. A registry that only works with one LLM just creates a brand new duplication problem the moment the organization adds a second one.

Three numbers make this trackable instead of theoretical. Duplication rate: functionally equivalent prompts divided by total prompts in the registry. Redundant token spend: tokens burned on duplicate workflows multiplied by average cost per token. Time-to-reuse: how fast a new team finds an existing skill and adopts it instead of starting over. Those three turn prompt duplication from a complaint in a retro meeting into a KPI with a trend line.

What AI program leads should measure first when auditing prompt duplication in their organization

Start with a count, not a fix. Before any deduplication effort makes sense, ask the plain question: how many distinct prompts and agent workflows exist across the organization right now, and where do they live? Skip this step and there's nothing to reduce and nothing to prove improvement against later, no matter how good the tooling that follows.

A few signals flag high duplication exposure early. Multiple teams inside the same function, sales, support, finance, engineering, have each built their own AI workflow for what turns out to be the same underlying task, and the count of parallel builds is a rough proxy for the duplication rate itself. Token costs climb faster than the number of active use cases, a gap usually explained by re-sent context and redundant execution running quietly in the background. Shadow AI usage runs high, and TELUS's 68% personal-account figure suggests that for a lot of organizations, more than half of all AI work never shows up in a measurement system to begin with.

Governance questions come before technical ones, not after. Who owns which prompts, since unclear ownership means version control never gets off the ground? What permissions govern each data source a prompt touches, since inherited permissions are the precondition for sharing anything safely? Which teams have already tried building the same capability, a question a few honest conversations often answer faster than any log analysis could?

Domain experts, not central IT, should own the AI skills relevant to their own team. A shared registry is what makes that distributed ownership safe to scale instead of a governance risk waiting to surface. Centralizing every prompt decision in IT just recreates the bottleneck that pushed people toward shadow AI in the first place, which defeats the purpose of centralizing it at all.

Survey data on MCP adoption itself runs thinner than the headline numbers floating around suggest. One widely cited adoption figure has already been retracted by at least one outlet for lacking a traceable sample. The best available data, from Stacklok in 2025 with a sample of 300 software-industry organizations, puts limited-to-broad MCP production use at somewhere around 41% to 45%. Even that more modest number means the window for building registry governance, before MCP sprawl replicates the exact mess prompts are already in, is closing.

Prompt duplication is a problem to address from day one of an AI program, not a cleanup task for later. It's accumulating right now, in every organization running more than one team on AI, whether anyone's watching the number or not. Measurement is what turns it from invisible debt into a program metric with an owner, a baseline, and a target for getting it down.