The job stops being writing documents people read. It becomes owning the context agents run on. Here is the shift, the economics, and the fight these teams are quietly losing.
For years, content and knowledge teams wrote documents for humans to read. That reader is changing. On many enterprise help sites, AI agents are now close to half the traffic, reading on a person's behalf. The artifact that mattered, the knowledge base article, is becoming the wrong unit of work.
The new unit is the context product: structured, governed, machine-readable knowledge that an agent consumes, with an owner, a version, an expiry, and a test. The economics flip in the team's favor and against it at the same time. A good article once helped one reader. A good context product makes every agent correct at once. A stale one makes every agent wrong at once.
The uncomfortable part: across the companies fighting over who owns the enterprise context layer, the contenders are the platform team and the data-governance team. The content and knowledge team is barely in the room. This paper argues that is the real risk, and that the survival move is to stop shipping prose and start owning structured ground truth.
The reader assumption that every content team was built on is breaking. The page is no longer written only for a human who skims it. It is written for a model that parses it on the human's behalf.
Measured traffic already shows it. On enterprise documentation sites, analyses of agent traffic put AI readers at roughly 45% of documentation visits, with the projection that half of doc traffic in the near term is not human at all. A help center now has two jobs: help the person, and help the model reading for that person. Most content was built for only the first.
This is why the provocation going around, the death of the knowledge base, is half right and half wrong. The KB article as a human-only artifact is dying. The knowledge base as the governed source an agent must ground on is becoming more important, not less. The work is to reformat knowledge so it serves both readers at once.
Five disciplines sit under this banner, and each has a real lineage worth respecting before we change it.
The through-line: these teams already do structure, governance, and lifecycle. The AI era does not ask them to learn a new craft from scratch. It asks them to point the craft at a machine reader.
A document is prose a human interprets. A context product is structured knowledge a machine can resolve: typed, tagged, related, and governed. The engineering consensus across independent platforms is blunt. Feed raw prose or PDFs to a model and you get hallucinations. A specification is no longer a paragraph. It is a data type with validation rules, meaning, and relationships.
Structured authoring is the practical bridge. The discipline of content engineering, which predates the current hype, described content that is atomic, structured, and reusable so machines can use it to serve humans. Vendors report large gains from structured over unstructured content for AI, though the specific figures are self-reported and should be read as direction, not proof. The platform-neutral version is simpler. If content is not structured, tagged, and governed, the model underneath will not perform, no matter how good it is.
Stop thinking in pages and start thinking in products. Each important piece of knowledge becomes a unit with a clear definition, a named owner, a version, an expiry date, and a test that proves an agent answers correctly from it. That is the same move data teams made when they turned tables into governed data products.
This is the part that turns a cost center into leverage. A knowledge base article helped whoever happened to read it. A governed context product is consumed by every agent that touches the domain, so a single correct definition makes the whole fleet correct at once. Govern the knowledge once, and every connected agent inherits the same policy-enforced foundation.
The same lever has teeth in the other direction, and this is the argument that should move a board. A stale article used to mislead one reader who might know better. A stale context product is inherited by every agent, each repeating the same wrong answer with no signal that it is wrong. The cost of staleness is multiplied by the number of agents. One analysis found stale embeddings can degrade retrieval accuracy by around 20% with no uncertainty flag, and that deployments lose adoption three to six months after launch as content rots underneath them.
Three labels are converging on this work. Content engineering, the oldest, frames content as structured data for machines. Context engineering, popularized in 2025 by Tobi Lutke and amplified by Andrej Karpathy, then formalized by Anthropic, frames the job as giving a model the right information in the right form at the right time. Knowledge engineering, which KPMG calls the key to agent value, frames it as encoding human expertise so machines can use it.
The demand is real. Cognizant announced plans to deploy a thousand context engineers over the coming year, with its CEO arguing that in the LLM era the lever is context. Read that as a signal of direction, not a settled headcount, and treat the attached accuracy claims as vendor self-report. The honest caveat: the discipline is real, but the durability of any single job title is not yet proven, and the popular claim that knowledge managers are simply being relabeled as context engineers is not supported by hiring evidence yet. What is clear is the underlying move: knowledge work becomes the work of making expertise machine-usable.
Page views and ticket deflection measured a human audience. They do not measure whether an agent grounded its answer in your content. The metric stack that does has genuine cross-vendor agreement:
Two cautions. First, retrieval accuracy alone explains only about 60% of end-to-end quality, so measure the whole chain, not just search. Second, do not declare page views dead. The credible guidance is to add these AI-era measures on top of reach and engagement, not to replace them. Content now gets tested like code, with golden sets and gates that block a change that breaks agent answers.
If knowledge is infrastructure, it has to be governed like infrastructure. The practical pattern emerging across the field:
Leading teams are starting to treat wrong answers as a content and governance failure, not a model defect. Restricting agents to validated, owned sources is how they cut them. The fix lives in the content layer, which is exactly where these teams already work.
Here is the argument that should make every content and knowledge leader sit up. Across the serious writing on who owns the enterprise context layer, the contenders named are the platform and AI team and the data-governance team. The content and knowledge team is conspicuously absent from the running. Enterprise context is being described as the new platform lock-in, something that needs platform ownership because it is not portable the way a model endpoint is.
The displacement is not hypothetical. Companies have quietly cut technical-writing roles after mandating generative AI for documentation. The counter-case is just as real: a model is only as good as the context it is given, and someone has to build the templates, the information architecture, the structure, and the rules that the agent consumes. Both can be true. The teams that keep shipping human-only prose get cut. The teams that turn their knowledge into structured, owned, tested, machine-callable products become the people who own the most valuable asset in the company.
So the move is not to defend the old artifact. It is to claim the new one. The content and knowledge function has the craft the context layer needs, structure, governance, and lifecycle, that neither the platform team nor the data team has in the same depth. The fight is winnable. It is just not being fought yet.
Drawn from 2024 to 2026 sources across industry bodies, research firms, academic papers, trade press, and clearly-flagged vendor material. Vendor numbers are flagged and read as ceilings.
Email this paper to your inbox, with the illustration and an editable document version attached.