Your Agent Needs a Librarian
Once you accept that agents are writing into your workflow and predicting forward from whatever context they have, the next question is the one most product operations teams don't have an answer to:
Who owns the context?
Not the model. Not the prompt. The context. The bundle of documents, relationships, policies, and tribal knowledge the agent reads when it acts. In most enterprises right now, that bundle is curated by accident — whatever someone uploaded, whatever the connector happens to grab, whatever the wiki currently says. If your agent's context is curated by accident, your agent's output is also curated by accident.
When the Connectors Came On
For a long time, the only way to get real context into ChatGPT or Copilot at work was to upload files manually. Restrictive, but the surface area was something I controlled. Then the enterprise connectors flipped on, and the surface area became everything I could touch on the corporate network.
The problem showed up fast. There was no clean way to tell either tool "only use these files" or "only look in this corner of the org." It behaved like a glorified keyword search across whatever it could see. I'd ask a question about my own product suite, and the system would pull back files from completely unrelated parts of the business. Sometimes from areas I had no working connection to at all. I could see why it was reaching for those files. The keywords lined up. The relationships, in any meaningful sense, did not.
Two things became obvious. The token bill was burning through volume on retrieval that wasn't useful. And the cleanup work was now mine. The system handed back answers that looked coherent, blended on context that should never have been touching, and the only way to catch the bad blends was to already know enough about the underlying material to spot them.
That isn't a scalable position to be in. And it points at the more general lesson: having access to content is very different from being able to work that content into a useful response. In some ways, broad access without curation is more dangerous than no access at all. It creates quiet context leakage that's harder to spot than a model guessing without information, because the answer looks plausible right up until you check it against the source.
The Role Nobody Is Hiring For Yet
There's a function missing from most teams that have already shipped an agentic feature. Call it context curation. Call it the librarian. The shape is the same regardless of name.
Someone owns deciding what fits together. What doesn't. What is unrelated and should never be retrieved as if it were. What needs to be updated when conditions shift. What needs to be retired. How retrieval should work when the agent reaches in. Whether the canonical version of a thing is the wiki, the database, the Slack thread, or the doc someone saved to their desktop.
That's a job. It's not part-time prompting. It's not "we have a Slack channel for AI questions." It's the operations layer underneath every agentic workflow, and it has two distinct phases that most teams collapse into one.
Setup. Getting the context in. Taking what currently lives in people's heads and across scattered systems, and turning it into something an agent can read without inventing relationships that don't exist.
Ongoing maintenance. Keeping it true. The world shifts. Decisions get made. Reorgs happen. Without continuous upkeep, the agent is operating on yesterday's company, which means it predicts forward into a state that doesn't exist anymore.
Most teams budget for the first phase and pretend the second one will happen organically. It won't.
The Industry Has Several Answers, Each Pitched as the Answer
There's no shortage of approaches on the market right now. Each is pitched, by the people selling it, as the way to solve agentic context. Andrej Karpathy has made the loudest case lately for wiki-style narrative context, and the case is strong. Narrative carries the why of a decision, which structured data alone cannot reproduce. The trouble is that no single approach holds up across every shape of knowledge a real company actually has.
| Approach | Strong at | Weak at |
|---|---|---|
| Knowledge graphs / semantic databases | Structured data, tables, well-defined entity relationships | Narrative, tacit knowledge, "why" context |
| RAG with vector search | Chunked source material, mid-volume corpora | Retrieval pulling adjacent-but-unrelated content |
| Wiki-style narrative context | Stories, skills, instructions, the "why" behind decisions | Source content getting buried as the wiki scales |
| Long-context dumps | Small, well-bounded contexts | Cost, signal-to-noise, anywhere with volume |
Each one solves a real problem. None solves all of them. Treating any single approach as the answer is how teams end up with context that fails in exactly the way the chosen approach is bad at.
The knowledge-graph teams find out the model still confabulates the narrative. The wiki teams find out the source content disappears the moment the wiki grows past a few thousand pages. The RAG teams find out their vector search is happily pulling unrelated documents that look similar. The long-context teams find out their tokens bill scales faster than their adoption.
Hybrids Are the Honest Answer
What I'm experimenting with personally is a hybrid. Wikis for the storytelling and the tribal knowledge layer. Structured metadata and semantic search on top, so retrieval can reach into a wiki that's grown well past what fits in a context window. Knowledge graphs for tables, systems, and entities with clean relationships. The narrative tells the model why. The structure tells it where to look.
That isn't a finished framework. It's a working hypothesis. The point isn't the specific stack I'm running. The point is that single-approach context architectures are going to fail under load, and product operations teams need to own mixing the approaches deliberately rather than picking one because a vendor said to.
The other thing the hybrid forces: it makes the librarian role explicit. Hybrid architectures have seams. Seams have to be maintained by someone who understands both sides. That someone needs to exist on your team chart before your agentic features hit anything that costs money to be wrong about.
What Product Operations Should Be Standing Up
A short list of what this role actually does, on real teams, on real timelines:
- Owns the canonical map. Decides which system of record is the source of truth for each kind of knowledge, and which is downstream.
- Decides what gets retrieved together. Documents that should never co-occur in an agent's context window need to be tagged, separated, or routed through different retrieval paths.
- Sets the freshness contract. Every piece of context has a half-life. Someone has to decide which contexts get reviewed monthly, which quarterly, which on event-trigger only.
- Curates the narrative layer. The wiki has to be written like it's being read by an agent who has never met your team. Because increasingly, it is.
- Owns the failure log. Every time an agent invents a relationship or pulls unrelated context, that's a curation signal. Someone has to feed it back into the architecture.
That's a real job description. Most orgs don't have anyone in that seat yet.
The Question Your Roadmap Has to Answer
The librarian is the role nobody is hiring for yet, and the role every product operations team is going to need by the end of next year. The choice is whether you stand it up before your agentic features start writing the wrong things into production, or after.
Who in your organization owns what your agents read?
Get AI strategy updates in your inbox.