Two roles are appearing in data organizations at the same time, and they are being described as though one of them is a renamed version of the other.
They are different jobs with a seam between them, and the seam is where the interesting failures happen.
The division, in one line
Context engineering decides what reaches an agent's window. Which definitions, which policies, which lineage, in what order, under what token budget. It is a retrieval discipline, and it is judged on whether the assembled context produced a good answer.
MetadataOps decides what exists to be retrieved. Coverage of the estate, definitions modeled and owned, change history, compilation into consuming systems, verification that all of it still matches reality. It is a supply discipline, and it is judged on whether the estate is described completely enough to answer from.
Neither is upstream of the other in importance. One is upstream in sequence, which is a different claim. A retrieval strategy can only reach what has already been harvested, modeled, and governed somewhere.
The handoff object
Everything between the two roles moves through one artifact: the governed definition.
A governed definition has a name, an owner, a version history, a binding to specific physical assets, and a policy that applies where the data gets used. It is what MetadataOps produces and what context engineering consumes.
Most arguments between the two roles are arguments about the quality of that object, with territory standing in as the visible topic. When it is complete, current, and resolvable to a column, retrieval is a tractable problem. When it is a paragraph of prose attached to a table name, no amount of retrieval engineering rescues it.
Three failures at the seam
Retrieval builds shadow definitions. The most common failure, and the most understandable. An AI team needs context this quarter, the governed definition does not exist, so they write one into their retrieval configuration. It works. Six months later the organization has a governed definition of revenue and a second one living inside an application, and they disagree.
Look for a prompt or a retrieval config containing business logic. Business logic in a prompt is a definition that escaped.
Supply ships definitions nothing consumes. The mirror image. Definitions get modeled, owned, and versioned in the metadata layer, and the consuming systems never inherit them, because compilation was never built. The governance artifacts are correct and the shipped behavior is unchanged.
Look for a healthy governance program alongside persistent number disagreements. Those two facts look contradictory and are the expected result.
Both roles own the same definition. The worst of the three, because it looks like collaboration. Two people can edit the definition of active customer, in two systems, with no single change history between them. Every question about what it meant last quarter now has two answers.
The contract, in both directions
What MetadataOps owes context engineering: definitions that resolve to specific columns, a named owner who answers, a version history that survives the question of what changed, coverage stated with its denominator so the retrieval side knows where the estate goes dark, and enough notice before a definition moves that consuming applications can be checked.
The notice period is the obligation most often skipped. A silent definition change breaks a retrieval system quietly, and the AI team finds out from a user.
What context engineering owes MetadataOps: a list of what the applications actually need, which is usually far narrower than the estate and a useful prioritization signal. Failures reported as metadata gaps rather than as model problems, so the supply side learns where the estate is thin. And a commitment to consume governed definitions in place of authoring local copies, which requires that the governed ones exist in a form the application can use.
Both obligations are conditional on the other being met, which is why the relationship works better as a standing interface than as a series of tickets.
When one person holds both
In most organizations below a certain size, one person does both jobs. That is a workable arrangement on its own terms.
What matters is that the artifacts stay separate. The governed definition lives in the metadata layer with a change history. The retrieval configuration lives with the application. One person can maintain both, and the moment they are the same object, the organization has lost the ability to answer what a number meant last year.
The practical test: if the person holding both roles left tomorrow, could someone reconstruct which definitions the applications are using, and where those definitions came from? If the answer lives only in a retrieval config, the estate is a level less governed than it appears.
Why the distinction is worth maintaining
Context engineering could absorb the whole problem. Here is why that arrangement fails.
Context engineering is defined by its consumer. It exists because agents need context windows populated well. That makes it responsive to whatever the current application requires, which is the right posture for the role and the wrong posture for the estate. The systems feeding regulated reports, the mainframe extract, the definitions that matter to an auditor and to no chatbot anywhere: none of that gets prioritized by a discipline scoped to what an agent needs this quarter.
The estate needs an owner whose scope is the estate. That is the argument for keeping the roles distinct, and it holds regardless of how many people are available to fill them.
