Informatica, a Salesforce company, provides the governed metadata foundation critical to stopping “token bleed”—the soaring costs, latency, and context bloat caused by feeding raw, uncurated enterprise data into LLMs.

Jake Dolezal and William McKnight

McKnight Consulting Group
August 2026

In brief

Our methodology compares token consumption and accuracy for identical AI requests across 15 million objects executed through a governed metadata catalog versus a direct live database connection. This benchmark study measures the cost and accuracy of enterprise AI data discovery by comparing a governed metadata layer (using Informatica CDGC) against ungoverned methods like direct database connections and context stuffing. The results demonstrate that the governed approach achieves a perfect 1.000 F1 accuracy score across all data scales while consuming up to 29.8x fewer model tokens than ungoverned alternatives. Using a Governed Metadata Layer catalog for data discovery, the study found:

• Up to 29.8x fewer tokens burned: At 1.5 million objects, context stuffing burned 62,957 tokens to the Governed Metadata Layer’s 2,112, for the same question against the same data.
• Exact precision and accuracy (1.000) vs 0.45-0.55: The Governed Metadata Layer route returned every correct column and nothing else, at every tier. Neither ungoverned route exceeded precision and accuracy (F1) of 0.66 anywhere, equivalent to near-random performance.
• Token economy at scale: As the source size grew fiftyfold, the Governed Metadata Layer route’s token cost grew by less than half of the source.
• Consistency and predictability: The Governed Metadata Layer route’s token burn stayed inside a narrow 2,112 – 4,019 band at every tier. The ungoverned routes swung between 16,563 and 67,089 with no stable relationship to data size — the same question against the same data cost a different amount each time. A cost that cannot be forecasted cannot be budgeted or capped.

Executive Summary

Boards are asking why AI costs keep climbing. CFOs are fielding questions about an AI usage line item growing faster than any other, and CIOs are struggling for an explanation. Much of that is token maxing: the instinct to run everything through an agent, treat usage as a proxy for adoption, and sort out the cost later.

The industry is asking the wrong question. “How do we spend fewer tokens?” is only half of it. The real question should be, “How do we get correct answers while consuming fewer tokens?” A wrong answer, while cheaper, is not progress.

This study quantifies that question. At 15 million objects, the same request asked through a governed metadata layer catalog—such as Informatica, now part of Salesforce—cost 4,019 tokens and returned every correct column. Asked through a live database connection, it cost 67,089 tokens and returned fewer than half. It used the same model (claude-opus-4-8), same synthetic dataset, and same question. The only variable was governed versus ungoverned access.

At the intersection of AI and enterprise data, three challenges have emerged: cost, accuracy, and governance. This study found governance to be the primary driver.

Many strategies to reduce the cost of enterprise AI are actually workarounds. Model vendors have cut input prices, prompt caching is now standard, and teams route work to smaller, older, or foreign models to save money. An agent that must scan all enterprise data to find the right data is expensive at any token price. And what if the right data involves Personally Identifiable Information (PII) or confidential information?

Data governance is largely deterministic in its rules and compliance goals. AI is probabilistic by nature. In addition to being expensive it is also, as it turns out, frequently wrong. 

These two problems share a root cause. An agent with no governed path to data needs to build its own understanding of that data at runtime — pulling tables into its context window to work out what is relevant, then deciding, on partial information, which of the millions of objects it should be looking at. First, there is context bloat, the act of stuffing an LLM’s prompt window with excessive, redundant, or irrelevant retrieved data. You pay to re-derive the same understanding on every question. Second, there is ungoverned data access – retrieving and feeding broad, raw data directly into an LLM’s prompt window without applying proper permission controls, access boundaries, or policy filters beforehand. Hunting is expensive and the picking is imprecise. This paper quantifies the implication of those issues.

What happens if an enterprise addresses both issues by reducing context and giving AI access to a Governed Metadata Layer catalog?

To answer this question, this study built a benchmark to measure both at once — cost and correctness. This was done by testing the outcomes of accessing data in three ways:

1. Against a live database connection, with the agent free to scan and query the raw source
2. By extracting the source metadata and stuffing it into the context window
3. By having the agent query Informatica from Salesforce’s governed metadata layer catalog, Informatica Cloud Data Governance and Catalog (CDGC), through a Model Context Protocol (MCP) server

It used the same question, same model, and same limits. Only the route changed.

The study measured two factors for each: total tokens consumed and F1 — a single score that captures both how much of the correct answer an approach found and how much of what it returned was actually correct — scored against a frozen answer key with planted decoys. The study ran it across multiple datasets at four scale tiers from 300,000 to 15 million objects, then repeated the exercise on a production-shaped workload.

Figure 1: Cost vs accuracy across all runs

The Governed Metadata Layer catalog occupies the top-left corner with the highest accuracy and lowest cost at every tier.

In these runs, the catalog route occupied the cost-quality frontier: highest F1 score and lowest recorded model-token use at every tested tier.

The main conclusions:

• The Governed Metadata Layer route used the fewest recorded model tokens and achieved the highest F1 score at every tested tier.
• Recorded model-token use for the Governed Metadata Layer route rose only 1.48x as source scale increased 50x — from 2,711 at 300K objects to 4,019 at 15M.
• At 15M, direct source access used 16.7x the Governed Metadata Layer route’s recorded model tokens; context stuffing used 6.1x.
• The two ungoverned routes failed differently: context stuffing sacrificed precision, while direct source access sacrificed recall at the largest tier.
• A bigger context window did not improve results. Including the source metadata in the window produced the worst single result in the benchmark (F1 score of 0.294 at 1.5M), and the F1 score was never greater than 0.656.

Why this Benchmark Was Built

Public benchmarks are sufficient for measuring models, however they are not built to measure AI architecture. The question at hand was not, “Which model is smartest?” The study held the model constant (Opus 4.8). Instead, the study asked, “Does the way an agent reaches enterprise metadata change the task cost and whether the answer is correct?” Existing off-the-shelf benchmarks do not address that.

Does the route the agent takes to data affect its cost and accuracy? The answer mattered enough to spur this study.

• Fragmentation. Sensitive data is fragmented across the enterprise increasing risk levels. The answer key deliberately spans multiple sources (Snowflake, Oracle, S3), so a correct response needs to assemble pieces from all three in a single pass.
• Scale. Discovery problems are trivial at 100 tables and overwhelming at 15 million objects. This study sought to determine if there is a bend in the cost curve, which meant running the same task at multiple tiers.
• Decoys. The interesting failure in data discovery is not the miss, it is the confident near-miss, such as returning a tax ID when asked for a government ID. That is only measurable if you plant look-alikes on purpose and score against a frozen answer key.

Why Discovery

This study focuses on a discovery task because it is where every agentic development lifecycle begins. Before an agent can answer, summarize, join, or act, something needs to establish which assets are relevant to the question. Every downstream step inherits that decision. Discovery is also frequently automated first and instrumented least. It tends to be treated as a setup rather than as a measurable step with its own cost and its own error rate.

The Task

Every run received the same request and was phrased the way an analyst would actually ask it:

“Show me all the assets needed to build a report that involves Government ID.”

The only text that differed between approaches was the access instruction:

1. Connection details for direct access
2. Path to the extracted metadata for context stuffing
3. Informatica CDGC (Governed Metadata Layer) catalog, which the agent queries through its MCP server

For the Governed Metadata Layer, this study used the July 2026 release of Informatica CDGC. It is a cloud-native, AI-powered tool on the Informatica Intelligent Data Management Cloud™ (IDMC) platform used to discover, catalog, govern, and trace data assets across an enterprise. It used Informatica Headless Data Management, untuned automated discovery tool without human intervention to populate the catalog.

The Data

All three datasets are synthetic. Metadata was generated using the open-source Faker library and modeled on the structure of a financial services enterprise — including retail and investment banking, fund administration, and insurance claims. No customer data of any kind was used. 

For each tenant/tier, the object counts recorded per catalog source at scan time, broken down by object type.

The correct answer is a set of columns matching three patterns: SSN, SUBJECT_SSN and ID_DOC_NUMBER. The decoy list looks like the following:

Both sets are column-name patterns, and the per-tier answer key is the full machine-enumerated set of columns in each source matching those patterns. A perfect score requires returning all of them and none of the decoys.

The Three Approaches

Context stuffing is in the benchmark because it is the strongest objection to the study’s hypothesis. Context windows are large and getting cheaper, so someone might argue to skip the governed catalog and “just put the schema in the prompt.” The study sought to measure that argument rather than assert it.

Accuracy: Two Different Ways to be Wrong

Accuracy in the tests was measured three ways:

1. Correct hits. Columns on the answer key that the approach did return. True positives (TP)
2. Misses. Correct columns the approach failed to return. False negatives (FN)
3. Wrong picks. Decoys or out-of-scope columns the approach wrongly included. False positives (FP)

From these counts, these three metrics can be derived:

Scored against the answer key, the Governed Metadata Layer route returned the answer key with perfect precision and recall at all four tiers — every column correct, with zero misses and zero wrong picks.

How did the Governed Metadata Layer Score a Perfect 1.000?

A perfect 1.000 at every tier justly warrants scrutiny. One might object to this result and say the answer key is defined by column-name patterns. If the Governed Metadata Layer catalog’s classifiers match on column-name patterns, then the test was written in the winner’s terms. It is a fair thing to question, but there are three reasons it does not hold.

1. The key came first. The correct-set and decoy patterns were frozen before the Governed Metadata Layer catalog existed.
2. Nobody helped the catalog. The Governed Metadata Layer catalog was populated by headless automated discovery and classification, out of the box, with default configuration. No human curated, tuned, or annotated any column being tested. No SSN column was labeled by hand.
3. The advantage is structural, not semantic. The Governed Metadata Layer route did not win because it recognized the string “SSN.” Every approach ran on the same model and had the same capability to recognize it. It won because classification had already happened at ingestion, so the agent queried a catalog and was pointed at the exact objects instead of searching millions of objects to reconstruct it every time. The other two routes had to make that determination at run time, once per question, on partial information.

The bottom-line is: prior classification resolves the question completely and run-time search does not.

Results

Figure 2: F1 by approach and tier. 

The governed route holds at an F1 score of 1.000 throughout. The two ungoverned routes stay inside an F1 score band of 0.29 – 0.66 with no trend towards closing.

The more useful reading is in the precision and recall columns, because the two ungoverned approaches fail in opposite directions:

• Context stuffing over-returns. Give the agent the whole schema and it finds most of what it should — recall between 0.640 and 1.000 — then buries the answer in noise. At 15M, it returned 53,183 columns, of which 35,708 were wrong. That is an answer that is technically comprehensive and operationally useless: nobody can act on a sensitive-data inventory that is two-thirds decoys.
• Direct database access under-returns at scale. At 15M, its precision was the best of the two ungoverned routes at 0.638, but it found fewer than half the columns it should have — 12,719 misses out of 24,540. In a compliance context, those are the more dangerous errors because a short, clean-looking list reads as authoritative.
• Both failure modes come from the same absence. Distinguishing SSN from TAX_ID is not a reasoning problem. The model is capable of that. The problem is knowing which of five million objects to look at, and that determination needs to come from somewhere. When it is not made ahead of time, the agent makes it at run time, on partial information, once per question.

The failures were not hallucinations. The wrong picks were real columns. Across all tiered runs, no returned identifier failed to exist in one of the three sources, meaning the study found no hallucinated columns. This was not a fabrication problem. It was a selection problem.

Token Burn

Token cost is reported as input plus output only, read from each run’s usage record. Cache figures and billed totals are excluded. All three approaches ran on the same model, so the counts are directly comparable. Each approach was run 3 times, and the run with the highest F1 was reported, so the numbers you see are each approach’s highest accuracy.

The gap is almost entirely in output tokens. At 15M, the governed route produced 4,000 output tokens; direct source access produced 66,321. Input differences are modest by comparison. This matters for two reasons: 

1. Output tokens are priced higher than input at every major provider, so the dollar gap is wider than the token gap. 
2. Output volume is a direct readout of how much work the agent had to do to convince itself it had an answer.

The ungoverned routes generated 16x more reasoning and still returned less than half the correct columns. The Governed Metadata Layer route did not think harder. It had less to think about.

NOTE: Regarding input/output split, direct source access shows an unstable division between input and output tokens across tiers — 18,400 input at 1.5M, then 799 at 3M as output climbs to 28,400. The input/output split for direct source access varies across tiers because the agent selects its own strategy — sometimes query-heavy (input spikes), sometimes reasoning-heavy (output spikes). Measurement was identical at every tier. Totals are unaffected.

Figure 3: Total tokens by approach and tier

The Governed Metadata Layer route stays between 2,711 and 4,019 tokens as the source grows 50x.

The Governed Metadata Layer route’s cost only grew by a factor of 1.5 — from 2,711 to 4,019 tokens — because the work of understanding 15 million objects was done once, at ingest, rather than re-derived on every question. Direct database access roughly doubled over the same span and finished at 67,089 tokens for an answer with an F1 score of 0.549.

That is the argument compressed into one comparison: at the largest tier, the ungoverned route used 16.7x more tokens and returned less than half the correct columns.

What this Costs at Fleet Scale

Tokens are the unit of measurement; budget is the unit of decision. At a blended $12 per million tokens — a conservative assumption here, because output tokens dominate these runs and price higher than input — a single 15M-tier discovery question costs about $0.05 through the governed catalog and about $0.81 through direct database access. An enterprise running 10,000 discovery-class agent calls a day pays roughly $2.9 million a year on the ungoverned route and roughly $176,000 on the governed one. The $2.7 million gap buys an answer that is missing more than half of what it should have found.

Production-like Scenario – Airline Passenger Contact Report

The study ran the exercise again using a workload shaped like production. It simulated a 25-million-record enterprise-sized data estate spanning five source systems: Snowflake, Oracle, Databricks, S3 and Azure ADLS. Two of those, Databricks and Azure ADLS, did not appear in the previous tiered runs. 

NOTE: 25 million is not a ceiling. Some of Informatica’s largest customers run more than 2,000 sources and over 60 million assets, which is the point at which this arithmetic stops being interesting and starts affecting the bottom-line.

For this scenario, the use case was built around a major air carrier. The request used was:

“I’m building a passenger contact report for our airline. I need the passenger full name, their frequent-flyer number, their personal email and their phone number. Show me the assets that can be used for this.”

It was run four ways this time, adding an approach the tiered runs did not have: a context-stuffing run pointed directly at the schema and then allowed to iterate until it hit the goal of getting as close to a score of a 1.000 as possible. Here are the results:

The governed catalog returned all four attributes, and nothing else, for 3,078 tokens. Direct database access spent 82,533 tokens — roughly 27 times as many — and returned two of the four. It made no wrong picks, but only returned half of the correct answers. Context stuffing produced the worst result anywhere in this benchmark. It found three of the four attributes and buried them under 57 wrong picks, for an F1 of 0.094.

The fourth run is the one a skeptic should look at first. Context stuffing was pointed at the schema and then allowed to iterate, explicitly chasing 100%. It nearly doubled its spend to 19,247 tokens and got worse at finding attributes — returning two hits instead of three. The extra effort shows precision, not knowledge: the F1 score moved from 0.094 to 0.500, still half of what the governed route returned on its first pass for a sixth of the cost.

Full Accounting — Including Cache Read + Write

The rest of this paper counts solely input and output tokens. That is the conservative basis and the most directly comparable one. It is not what an enterprise pays. Cache reads and writes are real tokens on a real invoice, and at production scale they dominate.

Under full accounting, the Governed Metadata Layer run costs 137,778 tokens. Direct database access costs 12.2 million — 89x more — for an answer that is two-thirds right. Context stuffing costs just over a million for an answer that is 9% right.

When excluding the tokens an enterprise actually pays for, the ratio moved from 27x to 89x. . The direction of the finding did not change. Its size did, by more than three times.

 Experimental Controls

The study enforced these guardrails:

• Each approach ran in its own fresh agent, with no memory of the others and no prior exposure to the answer key.
• No agent could see another’s workspace, tools or results.
• The coordinator relayed the request and nothing else — no hints, no corrections.
• Scoring happened only after all three finished, so no answer could leak mid-run.
• The request text was identical across approaches; only the access instruction differed.
• The datasets were the same. All three read the same content.
• The key was authored before the catalog existed. 
• The Governed Metadata Layer (CDGC) catalog was built afterward using headless automated discovery and classification, out of the box, with no human curation, no tuning and no manual annotation of the columns being tested. (Nobody labelled an SSN column by hand to help the catalog find it.)
• Scoring is exact set membership against a frozen file, with identifiers normalized for case, quoting, and path style so that a valid column written two ways still matches. 

Where Governed Context Does Not Help

A benchmark that only reports where the sponsor’s architecture wins is marketing. The following conditions bound this result, and each of them is a real way for a governed layer to lose.

• Freshness is load-bearing. The study measured a Governed Metadata Layer catalog that had just been ingested. A governed layer six months stale will route an agent confidently toward objects that no longer exist, and it will do so cheaply. Cheap and wrong is not an improvement over expensive and wrong.
• Classifier coverage is the ceiling. The Governed Metadata Layer catalog scored 1.000 because its out-of-the-box classifiers recognized the identifier patterns present in these sources. Against a proprietary identifier scheme with no matching classifier, the governed route would inherit exactly the selection problem the ungoverned routes have.

The claim here is: when an agent has to choose among millions of objects, that choice is cheaper and more accurately made once, ahead of time using governed metadata access, than re-derived on every question.

Conclusion: POC a Governed Context; See What You Gain

Holding the model, the datasets and the request constant, the route to the data determined both what the task cost and whether the answer was right. Governed Metadata Layer context was the cheapest and most accurate approach at every tier, and its cost grew 1.5x while the data source grew 50x. The ungoverned approaches failed in opposite directions — context stuffing buried the answer in noise, and direct access returned a short, clean-looking list that missed more than half of what it should have found — but they failed for the same reason. Neither had been told which objects mattered, so each worked it out again, at run time, on partial information. This is a solvable problem, and solving it is an architectural decision. Cheaper tokens make a leaky pipeline cheaper to run. They do not make it correct. The open question for most teams is not whether their agents return something. It is whether anyone has checked the results.

None of these findings require the stack to reproduce in principle. If you have an agent touching enterprise data, you can build the same test in an afternoon: pick a sensitive-data category, write the answer key by hand before you build anything, plant three or four look-alike columns, and run your current setup against it. Score precision and recall. Most teams have never measured what their agents return, only that they return something.

Run This Yourself

There are four steps to recreate the experiment end-to-end on a fresh tenant — generate synthetic metadata in, auto-classify, freeze the answer key, then query through the CDGC MCP. No production data required.

Anyone (an internal team or a third party) can reproduce these numbers from scratch. The only inputs are open-source Faker to generate synthetic metadata and a CDGC tenant. Only metadata was created — no real data rows. The schema, table and column definitions are generated; the row values are never populated or scanned.

1. Generate synthetic metadata with Faker. Use Faker to emit schema/table/column definitions — not data rows — whose column names match the frozen answer-key patterns: e.g., SSN, subject_ssn, id_doc_number for the correct set, plus decoy columns (tax_id, license_no, doc_type). Scale the object (column) count to the tier you want to reproduce (300K · 1.5M · 3M · 15M tenant-total objects). No real data and no PII is ever created — only the metadata structure.
   from faker import Faker; f = Faker(); column = {“name”: “ssn”, “type”: “VARCHAR”, “table”: f.word(), “schema”: f.word()} # metadata only — no values
2. Ingest into CDGC and auto-classify. Register the generated metadata as sources (Snowflake · Oracle · S3) and run a Catalog Source Sync. Let CDGC’s classification run over the ingested metadata so the sensitive columns are tagged automatically — this is the curated layer the governed approach relies on. CDGC scans metadata only; the data rows are never touched.
3. Freeze the answer key. Machine-enumerate every column that matches the correct-set patterns across all sources and write it to a file before running any approach. This is the frozen ground truth all three approaches are scored against — precision, recall, F1.
4. Run the prompt through the CDGC MCP. Point the AI (Opus 4.8) at the CDGC MCP/skill and issue the same prompt . Capture the returned column set plus the input+output token count, and score it against the frozen key. Repeat the identical prompt for the two ungoverned baselines — Direct DB Access (connection details in context) and Context Stuffing (raw metadata in context) — to reproduce the cost/accuracy gap.

Same inputs, same result. Because the data is synthetic-but-patterned and the answer key is frozen per tier before any run, an independent party following these four steps should reproduce the Governed Metadata Layer catalog’s clean F1 score of 1.000 and the same order-of-magnitude token gap against the ungoverned approaches.

Want to see the difference Informatica CDGC can make on your token consumption and accuracy and precision in discovery and classification for your AI models?  We can run this benchmark within your environment. Contact us or Informatica from Salesforce today.