Ranganathan’s Five Laws Apply to Your AI
Yes, it's another metaphor. Sorry.
Your AI agent is only as good as its library.
The library is the (often messy) collection of prompts, documents, tools, memories, policies, APIs, search results, text files and previous conversations from which the harness tries to assemble enough understanding to act.
S. R. Ranganathan saw this shape of problem of organizing information nearly a century ago. In 1931, he published The Five Laws of Library Science:
Books are for use.
Every reader his book.
Every book its reader.
Save the time of the reader.
The library is a growing organism.
They sound like aphorisms, but they are closer to a design specification for information access. They also describe the design challenges of modern AI context stacks surprisingly well.
Books are for use
The book version: a library is not good because it owns books. It is good because readers can use them.
The context version: an AI system is not good because it has capabilities like RAG, crafted prompts and specific tools. Those things only matter if they improve the work the model does.
A retrieval system that returns seventeen vaguely relevant chunks may score well when tested individually and still make the model worse. A memory system that surfaces every past conversation about a customer may technically succeed while burying the one fact that matters. A tool description may be accurate and still encourage the model to call it at the wrong moment.
The question is not “did the context exist?”, it’s instead “did the agent do better work because of it?”.
Every reader his book
The book version: different readers need different books. A physicist, a journalist and a schoolchild asking about quantum mechanics should not all be sent to the same shelf.
The context version: different models, users and workflows need different context.
A coding assistant, support bot, sales copilot, security analyst and compliance reviewer should not receive the same context package. They are doing different jobs, and have different risk profiles.
A coding assistant needs interfaces, invariants and recent changes. A support bot needs entitlement, known issues and escalation rules. A compliance reviewer needs policy, exceptions and audit trail.
We often expect one agentic system to serve multiple needs and rely on the model to do the filtering. We give them the same pile of books (the same tool list, the same memory strategy, the same retrieval and so on).
That works while the library is tiny. It fails once the system grows.
An AI system with access to twenty MCP servers does not need twenty server descriptions on every task. It needs routing. Which tool is relevant? Which source of truth applies? Which memory matters? Which policy constrains action?
A passive list of available contexts is not enough. AI systems need context routing by user, task, intent and risk.
Every book its reader
The book version: a book that exists but cannot be found has effectively ceased to exist. Cataloguing is not administration. It is how the book finds the reader who needs it.
The context version: useful information inside your organisation is worthless to the model if the model cannot discover it at the point of need.
The runbook is in a wiki. The policy exception is in a Slack thread. The customer-specific behaviour is in a support ticket. The design rationale is in an ADR. The safe way to perform an operation is buried in a tool description written for platform engineers.
The information exists, but the model cannot find it.
This is mostly a vocabulary problem. The user asks about “cancelling an account”. The system knows about “subscription termination”, “offboarding”, “churn workflow” and “account closure”. They are the same thing. The model sees four separate shelves and picks the closest one, which may not be the right one.
In a human organisation, this gap is bridged by the person who has been around long enough to know that “the new auth flow” in Slack, “JWT validation layer” in the codebase, and “identity boundary” in the design doc are all the same things. That person is not on call when your agent is running at 2am (or they are and they are exceedingly grumpy).
The catalogue needs to do that work instead. Synonyms, ownership, source-of-truth markers, provenance and most importantly the connections between them.
Save the time of the reader
The book version: the reader’s time is precious. A library fails if the right book exists but takes an hour to find.
The context version: save the model’s tokens.
If you work with Claude Code without a tight AGENTS.md it’s easy to see this in action. Any query will spawn tool calls to find that information resulting in huge numbers of tokens being consumed.
Tool descriptions show the same pattern. A delete_record tool ships with the internal API doc (parameter types, error codes, retry semantics, the lot!). But what the model actually needs to know (“this is destructive and irreversible; prefer archive_record unless the user explicitly asks for deletion”) is nowhere in the description.
And it’s not just about cost. Every unnecessary token consumes context window. Every bloated description makes the model do secondary work before the real work.
The model may technically have the answer and still fail because the answer is buried under sludge. Correct but bloated context is still bad context.
If the tool, RAG system or memory system is returning more than it needs then it risks creating distraction. The test for this is simple: remove the context. If the model doesn’t give worse answers, it was waste.
The library is a growing organism
The book version: a library is never finished. Its collection grows. Its readers change. Its classification scheme must adapt to subjects the original cataloguer could not predict.
The context version: your AI system is never finished either.
The prompts you write today encode assumptions about how your tools work, what your data looks like, and what your users need. Those assumptions will become false. APIs change. Products pivot. New edge cases emerge that nobody anticipated. A retrieval strategy tuned for fifty documents quietly degrades when the corpus reaches five thousand.
The harder problem is that the decay is invisible. The model doesn’t throw an error when it acts on a stale policy. It just gives a confidently wrong answer.
In a real library, the cataloguer has a job. They weed the collection, update classifications, retire obsolete material, and decide what the library needs to acquire next. AI context systems rarely have an equivalent. The system prompt was written once. The tool descriptions shipped with the feature and were never revisited, and the memory layer accumulates without pruning.
This is why context systems need ownership and instrumentation. Someone (or something) has to notice when the vocabulary has drifted or when a tool description no longer matches the tool. That is not a one-time task. It is the ongoing work of tending the library.
The point (if there is one)
Context systems are hard. System performance is a function of model, prompt and library.
The library is currently a hodgepodge of individual technologies (RAG, tools, MCP, memory, conversation history, prompts, skills, connectors and I’m sure many more) with no coherent organization.
These can all be improved individually, but they are just individual books of information in a larger system. The real opportunity is to design the library1.
That means cataloguing, routing, vocabulary control, provenance, freshness, pruning, circulation policy and ownership of the whole experience by which an AI system finds what it needs to act.
When an AI system retrieves the wrong document, invokes the wrong tool, ignores the policy, uses stale information or fills the context window with noise, that is not (always) a model failure, it’s often a library failure.
The counterargument to this would be hey, models are SO smart now that they can find the needle in the haystack. Even if that becomes true, the curation of the library still feels important in order to get other aspects of performance (cost, time to answer).
So writing proper (AI optimized) documention still remains the bottleneck.