The agent returned $52.4M for Q3 net revenue. The board deck said $49.1M. Both numbers came out of the same warehouse, on the same afternoon, from two teams in the same building.
The AI team spent the next week on retrieval. They tuned the chunking, rewrote the system prompt, and added a re-ranking step. The number moved to $51.8M, which was wrong in a new way.
Retrieval was working the whole time. It found every definition of net revenue that had been written down anywhere in the estate. There were four of them, with no record of which one the finance close actually runs on.
The failure was in the supply of definitions, not in the retrieval of them.
Retrieval can only reach what someone already collected
Context engineering has a clear job: decide what goes into the window. Which definitions, which policies, which lineage, in what order, under what token budget.
It's real work and it's getting better fast. It also inherits a hard ceiling from upstream, because an agent can only assemble context that exists somewhere in collected, governed form.
The upstream job is a different discipline. Harvest the estate, model the concepts, version every change, compile the result into the systems that consume it, and verify that all of it still matches reality.
Practitioners have started calling that work MetadataOps, and the name fits. It has a build, a test, a deploy, a diff, and a rollback.
The quality of the supply is measurable, on five dimensions, and most estates fail on at least three. That measurement sets the ceiling on any grounding claim.
Coverage and resolution set the first two ceilings
Coverage is the share of the estate that has harvested metadata at all. The whole estate, which includes the mainframe extract feeding the regulatory report and the stored procedure last touched in 2019.
Enterprise estates are stubbornly heterogeneous: databases, transformation code, BI tools, and cloud platforms, legacy through current. The denominator has to include all of it, or the coverage number describes the slice someone chose to count.
Resolution is how deep the record goes. Table-level lineage tells an agent that a report touched a table. Column-level lineage tells it which field, through which transformation, from which source.
Table-level passes a demo and fails an agent. When the question is which of four revenue columns the close actually uses, table-level has nothing to say.
Lineage inferred from run logs only shows what ran
Derivation is the third dimension, and it is the one that breaks audits.
Observability-style tooling infers lineage by watching execution. It reports what ran during the observation window. Jobs that didn't fire that month leave gaps, and jobs that fired for other reasons produce false positives.
Parsed lineage comes from the code artifacts that define the transformation chain: SQL, Python, Informatica PowerCenter mappings, SSIS packages, stored procedures, COBOL copy books. It records what the code will do, whether or not the job ran this month.
The difference shows up the day someone asks where a number came from. A parsed answer points at a line of code. An inferred answer points at a probability.
A definition with no owner is a coin flip
The last two dimensions are freshness and governance state.
Freshness is whether the record matches the live estate today. A catalog maintained by hand describes the estate as it was on the last day someone had time to update it. Active harvesting keeps the record moving with the systems it describes.
Governance state is whether each definition has an owner, a version history, a policy applied where the data gets used, and a binding to a real physical asset. This is where four written definitions of net revenue become one governed definition with three deprecated predecessors and a date on each.
An operated estate puts its definitions under version and configuration management across dev, test, and production. Every change is logged, attributed, timestamped, and reversible, which means the question "what did net revenue mean in Q2 2023, and what changed since" has an answer that takes seconds.
Score the estate before you tune the prompt
Coverage, resolution, derivation, freshness, governance state. Five dimensions, each one a measurable fact about the metadata itself.
The boundary matters here. These five measure whether the description of the estate is complete, deep, derived, current, and governed. Fixing bad values in the data itself is a different discipline with different tooling.
Score those five before the next round of retrieval tuning. Teams that do usually find the wrong answer traces to a gap they could name in an afternoon.
Then close the gaps in order. Coverage first, because everything downstream inherits it. Resolution next. Derivation after that, since it determines whether the first two can be trusted.
Once definitions are governed, they can be compiled directly into the native formats of the databases and BI tools that consume them, so the agent and the dashboard read the same definition from the same source.
The role this work creates
Somebody has to own the five dimensions, and in most organizations that ownership is currently split across four teams and held by none of them.
Gartner brought the Metadata Management Magic Quadrant back in November 2025 after five years dark, on the reasoning that data and analytics leaders who fail to reach metadata maturity risk AI failure. That's the same argument arriving from the analyst direction.
The job has a scope. Harvest, model, version, compile, verify, with a clear list of what falls outside it. It has a leveling path, and the tell between an engineer and a senior engineer is whether they can give you the coverage number with its denominator.
Start with the score. Pick your three highest-value business metrics, trace each one back to source, and write down where the record goes dark on each of the five dimensions. That document is the beginning of the roadmap, and it's also the strongest headcount argument available for the role that owns it.