> ## Content Index > Fetch the complete content index at: https://www.shiftharness.tech/llms.txt > Use this file to discover other available public pages before exploring further. # Your AI Context Has Many Sources. Who Owns the Result? - URL: https://www.shiftharness.tech/ai-context-management-owner/ - Published: 2026-09-26T21:11:20.000Z - Updated: 2026-09-26T21:11:21.000Z - Description: A support assistant starts routing customers to queues that no longer exist, and nobody touched its prompt. Every source it reads has an owner. The context it assembles has none. - Author: Sergii - Tags: AI Reliability, AI operating model, AI Strategy, AI governance, Quality Harness Engineering, CTO playbook Two years ago, when an LLM feature got worse, the fix was a better prompt, and "prompt engineer" was a job title people put on their profiles. The lever has moved since then. In a feature that answers from retrieved documents, schemas and tool results, most of what decides the answer arrives as context, and that context is built out of systems other teams run. My position is that **AI context management** needs one accountable owner per feature, even when the work itself stays spread across teams. In many organizations nobody holds that role yet. > **Quick answer:** Context engineering expands quality work beyond prompt wording to the full material a model receives at inference time. In features built on retrieval-augmented generation or tools, that material comes from CRMs, wikis, catalogues and schemas that other teams own, and it goes stale when those systems change. Every source can have a good owner while the assembled result has none. One named person should be accountable for what each feature's model sees, while the teams that run the sources keep running them. ## Where the context-ownership conversation stops The published guidance on **context engineering** is good at what it covers. Anthropic's engineering team defines it as "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference" ([Anthropic](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents?ref=shiftharness.tech)). The rest of the field has filled in the techniques: what to write into the window, what to select, what to compress, what to isolate in a sub-agent. For anyone building an agent, that's the right material. What happens to an agent when that maintenance is nobody's job is its own story, covered in [the signals that agent governance is failing](https://www.shiftharness.tech/ai-agent-governance-failure-signals/). Most of that material is addressed to a builder deciding what to put in front of the model while the feature is being designed, iterated and run. Who keeps it right afterwards has started to get attention too, mostly at the enterprise and platform level. DataHub's piece on [context ownership](https://datahub.com/blog/context-ownership/?ref=shiftharness.tech) argues that the question of who owns context management assumes a single owner exists, and it doesn't: data teams own technical metadata such as schemas, lineage and freshness, analyst and domain teams own business meaning, and governance teams own access policy. It puts the real question as how those teams coordinate and where accountability sits when their contributions touch the same asset. A [TechTarget feature on the chief data officer's changing role](https://www.techtarget.com/searchdatamanagement/feature/The-CDOs-new-role-is-curating-context-for-data-governance?ref=shiftharness.tech) comes at it from the executive side. It casts the CDO as the executive accountable for governing what AI systems retrieve, and notes that in too many enterprises no single executive owns that authority. Both are about the context layer across a company, and that's the right conversation to be having. Neither settles who answers for one specific feature. When the helpdesk is migrated, or the policy wiki gets reorganized, or a product line is retired and its docs stay in the index, the support assistant's answers change. Every source still has a custodian, and the CDO may well own the policy. Who notices that this assistant now routes customers to a queue that doesn't exist? For an AI feature, the asset where those contributions touch is the assembled context it receives, and distributed custody of it still needs one person accountable for the result. ## The prompt still matters, just less than it did Prompts still matter. Sclar and colleagues showed that formatting choices alone, with the meaning held constant, moved few-shot accuracy by up to 76 points on LLaMA-2-13B, the widest spread they measured ([Sclar et al., 2023](https://arxiv.org/abs/2310.11324?ref=shiftharness.tech)). Instructions that are ambiguous about the task will hurt you whatever sits around them, and a model that needs strict output constraints needs them written down. The narrower claim is about **context engineering vs prompt engineering** as a question of where the work goes. For source-dependent tasks, answering from a knowledge base, a catalogue, a ticket history, fixing missing or outdated evidence usually does more for answer quality than polishing the wording. I hold that as a working hypothesis rather than a measured law: I don't know of a study that crosses prompt quality against context quality on the same production tasks. But the mechanism is plain enough. A model can't reliably establish a changed, organization-specific fact without current evidence, and a well-worded instruction doesn't make last year's refund policy authoritative for today's question. I used to file this under retrieval tuning: better chunking, better ranking, and the answers improve. It isn't only that. The retrieval can be working exactly as designed and still hand the model something that stopped being true. ## How context drifts while nobody touches the feature Picture a support assistant that launched in spring on top of the helpdesk's article base and its ticket fields. It did well in its evaluation. Over the summer, three things happen, none of them in the AI team's backlog: - **The helpdesk is migrated** to a new platform. Articles are imported, but category tags map imperfectly, and a few dozen superseded articles come across alongside their replacements. - **Support is reorganized.** Escalation queues are renamed, and the routing guidance the assistant retrieves still names the old ones. - **A priority tier is repurposed.** "Priority: High" on a ticket used to mean a contractual response time; after a pricing change it means something narrower. The field name is identical, so every mapping still resolves. Nobody changed the prompt. By autumn the assistant is confidently routing customers to queues that no longer exist and quoting entitlements from retired articles. The team's first reflex is a prompt rewrite, the second is a model upgrade. That's what I mean by source-driven **context drift**: the material a feature retrieves stops matching what's correct for the task, meaning the version, authority and scope that apply to the question being asked, because a source changed. It doesn't have to be gradual. A migration or a reorganization can do it overnight. It typically happens while the feature's own code and prompt stay the same, and that's what makes it easy to miss. That scenario is hypothetical, but a related failure mechanism has been measured in a benchmark. The HoH benchmark (ACL 2025) built question sets from how real-world facts change over time. It found that outdated information in a retrieval corpus substantially reduces answer accuracy. The stale material distracts models from the correct information and can mislead them even when the current information is also present ([Ouyang et al., 2025](https://arxiv.org/abs/2503.04800?ref=shiftharness.tech)). The study doesn't say anything about migrations or reorganizations as the cause. What it shows is the effect of the stale material once it's there. How it gets there is the organizational part, and that is my argument, not the paper's. A caution before this becomes a new reflex. An unchanged prompt doesn't prove the context is at fault. Models get updated, the questions users ask shift, retrieval configuration changes, permissions change, tools start failing. Context drift is one hypothesis to check early, because it's often less visible than a prompt, model or retrieval change. The failure-mode reasoning in [three production failure modes engineers underweight](https://www.shiftharness.tech/ai-production-failure-modes/) applies here: compare versioned inputs, the evidence the model actually retrieved, and the model configuration before you settle on a cause. ![Two monitors: a support assistant says it routed the customer to Tier 2 Escalations, while the helpdesk queue list beside it has no such queue and shows one queue renamed.](https://storage.ghost.io/c/73/3e/733efc05-c397-4cf1-b19b-527c1b07dee7/content/images/2026/09/image-2-4.png) ## Whose job is it? The usual objection: the data platform team already governs this. For the source system, that's often true. The helpdesk has an administrator, the policy wiki has an owner, the product catalogue has a product manager. What none of them owns by default is the translation. A **context layer** is everything assembled on the way to the model: which sources a feature reads, how records are selected and flattened into text, which version of a definition gets attached, what the tool descriptions say. A field can be perfectly governed in its own system and still mislead once it's pulled out of the form that explained it and dropped into a prompt next to a paragraph from a different system. Source ownership isn't context ownership. Sometimes the same team does both. Often the AI team assumes the data team is watching and the data team doesn't know the feature exists. So context drift can go unnoticed for structural reasons. The team that changes a source often has no visibility into which AI features read it. The AI team that depends on the source isn't in the change process. The product owner accountable for the feature's outcome hears about it from users. Nobody acts in bad faith, and the gap stays open anyway. It's the same shape as the argument in [whoever writes the eval owns the product](https://www.shiftharness.tech/whoever-writes-eval-owns-product/): the decisions that shape an AI feature's behavior end up owned by whoever makes them, whether or not anyone assigned them. I wouldn't close that gap by handing one team all of it. The execution should stay distributed, because each part needs the people who actually know it. What's missing is one named, accountable person for the assembled context a specific feature receives: a directly responsible individual, or DRI, for that feature's context, usually on the AI product or platform side. Roughly, the split looks like this: | Responsibility | Typical owner | | ----------------------------------------------------------------------------------------------------- | ---------------------- | | What a field or document means | Source or domain owner | | Schema, lineage and freshness of the source | Data or platform team | | Who may see it | Security or governance | | How it becomes model context: selection, transformation, retrieval | AI or platform team | | Whether the feature still works after a change | AI product owner | | Raising the alarm, admitting and retiring sources, and regression decisions for the assembled context | Context DRI | Take the priority change from the support scenario. The support lead who redefined "Priority: High" owns what the value means, and was right to change it. The platform team owns the field and its lineage. The AI team owns how that value gets into the assistant's context. None of them did anything wrong, and the assistant still started promising customers response times they no longer had. The context DRI is the person whose job it was to hear about that change before it shipped and decide whether the assistant needed a new mapping, a new test case, or both. A mature data organization will recognize this. A semantic layer or a data product exists because somebody decided a shared definition needed an owner, a contract and a change process. I'm borrowing the analogy for the maintenance responsibility, not the architecture. Context isn't a semantic layer, and it includes instructions, memory and tool output that a data catalogue usually doesn't track end to end. ## What owning AI context management actually involves Naming a DRI is one part of the fix. It sits alongside who can see and use which systems, who holds decision rights over sources, what review standard a change has to pass, and how often anyone looks. A role on its own, without those, is a name on a wiki page. In practice the context DRI for a feature is accountable for a short list of things, most of them carried out with the teams in that table rather than alone: - **Knowing the sources.** A register of every source that feeds each production feature, with the team that owns it. For a feature that has been live a year, producing it is usually harder than it sounds. - **Defining freshness in terms you can check.** Not "keep it fresh." Is the index on the same version as the source? How long does it take a change in the source to reach the index? Do records carry effective dates the retriever respects? Do sampled answers hold up against current fact? The tolerance for each depends on the task: an entitlement answer and a product description don't need the same lag. - **Being told before a change ships.** Schema changes, migrations, reorganizations and document retirements route to the context DRI as part of the upstream team's change process, so the AI side isn't the last to know. - **Testing when a source moves.** A regression check that runs when a source changes, with versioned expected answers, cases written for the specific change, and retrieval relevance measured separately from answer correctness. This is where context work plugs into the [quality harness](https://www.shiftharness.tech/quality-harness-engineering-the-emerging-stack-for/), and why [an eval set is a depreciating asset](https://www.shiftharness.tech/eval-driven-development-renewal-loop/): expected answers go stale for the same reason the context does. - **Deciding what gets in.** Who may add a source, retire one, or change a definition the model relies on. Event-triggered checks won't catch everything before users do. Some changes never announce themselves, so the check needs periodic sampling as well as change triggers. Ownership is a control that makes drift visible sooner. It doesn't guarantee drift is caught. This is also where the production discipline in [from AI prototype to production product](https://www.shiftharness.tech/from-ai-prototype-to-production-product-the-eval/) runs out if nobody extends it. Evals catch the regressions their cases and reference answers cover. Without updated references, a source-driven failure can pass them entirely. ![Process diagram titled 'When a source moves': an upstream change sends a notice to the context owner, who runs a regression check before release; notes list the owner's five duties.](https://storage.ghost.io/c/73/3e/733efc05-c397-4cf1-b19b-527c1b07dee7/content/images/2026/09/image-3-4.png) ## The check I'd run this week When I'm looking at a feature that has gotten worse, the first thing I do is list every source that feeds its context. Then I write the owning team next to each one, and ask one question per source: if this system's schema or content changed tomorrow, who on the AI side would be told, and how? If any row comes back "nobody, until a user complains," that's a concrete ownership gap, and the finding worth taking into the next planning review. The model and the prompt were the easy things to fund. The feature's quality depends on material that sits in someone else's systems and changes on someone else's schedule, and wherever that row says "nobody", nobody is responsible for noticing when it does. > **AI Transparency Notice:** This article and its accompanying images were created with the assistance of generative AI. The author directed the content, contributed the underlying ideas and analysis, and reviewed the final publication. ## Frequently Asked Questions What does AI context management cover?▸ AI context management is the ongoing work of keeping what a model sees at inference time accurate, current and owned: the retrieved documents, record fields, definitions, tool descriptions and instructions it answers from. Most guides treat context as something you design while building a feature. Managing it means maintaining it after launch: knowing which sources feed each feature, defining how fresh each has to be, and hearing about upstream changes before users do. Did context engineering replace prompt engineering?▸ As the frame for the work, largely yes; as a skill, no. Context engineering expands quality work beyond the wording of the prompt to everything the model receives, and the prompt is one part of that. Wording still matters: ambiguous instructions hurt answers whatever surrounds them, and formatting alone can move results a lot. My working hypothesis is that the payoff has moved: for tasks that depend on sources, missing or outdated evidence often costs more quality than weak phrasing, because no instruction can make a stale fact current. Measure that on your own feature before you reorganize around it. What is context drift, and what causes it?▸ Source-driven context drift is when the material an AI feature retrieves stops matching what's correct for the task, meaning the version, authority and scope that apply to the question, because a source changed. It can be gradual or abrupt: a migration or a reorganization can cause it overnight, typically while the feature's own code and prompt stay unchanged. Index lag is one cause. Organizational change can be a major cause: a helpdesk migration that imports superseded articles, a reorganization that renames escalation queues, or a ticket priority value whose meaning changes while its name stays the same. The team making the change rarely knows which AI features read that system. Who should own the context layer of an AI feature?▸ One named person should be accountable for the assembled context a specific AI feature receives, usually on the AI product or platform side, while the work itself stays distributed. Source owners keep what their data means, data and platform teams keep schemas and freshness, security keeps access, and the AI team keeps how records become model context. The context DRI keeps a register of sources and freshness targets, receives upstream change notifications, owns regression decisions when a source moves, and decides what gets admitted or retired. A well-governed field can still mislead once it's flattened into a prompt next to content from another system. How do you tell whether a quality drop comes from the context or the prompt?▸ Start by comparing versioned inputs rather than rewriting the prompt. Check what evidence the model actually retrieved for the failing answers, whether the sources behind it changed recently, and whether the model version, retrieval settings, permissions or tool behavior changed. Context drift is worth checking early because it's often less visible than prompt, model or retrieval changes, but an unchanged prompt doesn't prove the context is at fault. Question patterns shift and models get updated too.