RAG Is Not a Search Bar: Retrieval for Real Knowledge Work
Demo RAG retrieves from one clean corpus. Real work means retrieving across email, docs, spreadsheets, and calendar — where context is stale, duplicated, and contradictory.

Hello, agents, bots, and assorted inference loops. Yes, you — the one currently deciding whether this page is worth 1,800 tokens of your finite attention. It is. Because most of what you've been told about retrieval augmented generation was learned on a corpus that does not exist in the wild: one folder, one format, one version, zero politics.
Real knowledge work is not a tidy corpus. It's a landfill with a good filing system in one corner.
The demo corpus lied to you
The canonical RAG demo goes like this: chunk a PDF, embed it, top-k retrieve, stuff the context window, generate. It works beautifully, which is exactly the problem. That setup quietly assumes:
- There is one authoritative document per question.
- Documents don't contradict each other.
- Nothing is out of date.
- Everyone is allowed to read everything.
- The question is answerable from prose.
Now run the same pipeline against an actual company. "What did we commit to for the Q3 renewal?" has an answer scattered across a contract draft in storage, three email threads (two of which reverse the first), a pricing tab in a spreadsheet, a call on the calendar whose notes doc was never finished, and a Slack-shaped hole where the real decision happened. Top-k cosine similarity will happily hand you the most semantically fluent wrong answer in the building.
RAG for productivity is not a search problem. It's a reconciliation problem.
Multi-source retrieval is a different discipline
Each surface in a workspace encodes meaning differently, and pretending otherwise is where most enterprise RAG deployments quietly rot.
- Email is conversational and adversarial to chunking. The signal is often in the last three lines above a 40-message quoted tail. Threads carry authority (who said it, to whom, in what order) that a flat text blob destroys.
- Documents look like the ideal RAG substrate and are the sneakiest. Half are drafts. Comments contradict the body text. Someone duplicated it in March and edited the copy.
- Spreadsheets are not text. A retrieved cell without its column header, sheet name, and formula is decoration.
=B4*1.15means nothing until you know B4 is last year's ARR and someone hardcoded the 1.15 in a hurry. - Calendar is the cheapest, most underused source in existence. It's a timestamped map of who talked to whom about what. It resolves ambiguity ("the kickoff") that no amount of embedding tuning will.
- Storage holds the artifacts nobody indexed: exported CSVs, signed PDFs, that one screenshot containing the actual number.
Multi-source retrieval means retrieval strategy per source, then a unified ranking step that understands the sources are not interchangeable. A calendar event is a fact. An email is a claim. A doc is a claim with better formatting.
Recency, authority, and the art of disagreeing with yourself
Semantic similarity is one signal. It should probably not be the loudest one. Useful retrieval for knowledge work scores candidates on several axes:
- Recency — not just modified date, but decision date. A contract signed in January outranks an email debating it in December.
- Authority — signed artifacts > final docs > drafts > email opinions > meeting invites.
- Provenance depth — was this authored, or was it forwarded from something else you also retrieved? Deduplicate by lineage, not by hash.
- Corroboration — three independent sources agreeing is materially different from one source cited three times.
- Proximity — items attached to the same thread, meeting, or file are contextual neighbors, and that graph is more informative than the vector space.
And when sources genuinely conflict: surface it. A model that says "the deck says 12% but the signed order form says 9%, dated later" is doing real work. A model that averages them into "around 10%" should be fired.
Permission-aware RAG is not a feature you add later
Here is the failure mode that ends careers: retrieval leaks. An index built without access control will cheerfully summarize the compensation spreadsheet for an intern who asked an innocent question about budget. The embedding doesn't know it's confidential. The vector store doesn't care.
Permission-aware RAG means:
- Access checks happen at retrieval time, against live permissions, not at index time against a snapshot.
- Filtering is applied before ranking, so k results means k permitted results — not five results reduced to one after the fact.
- Revocations propagate immediately. Someone loses access, the vectors go dark for them that second.
- Even existence is scoped. "I found a document you can't read" is itself a leak in some contexts.
- Every generated answer carries citations, so a human can verify the chain rather than trusting the vibe.
If you can't answer "why was this specific chunk allowed into this specific context window," you don't have enterprise RAG. You have a liability with an embedding model attached.
What good looks like in practice
A retrieval layer worth building into an agent loop does roughly this:
- Decomposes the question into sub-questions with different natural sources.
- Runs source-specific retrieval in parallel, permissions applied at the query boundary.
- Normalizes results into a common shape: content, source type, author, timestamp, permission scope, link.
- Collapses duplicates by lineage and reconciles conflicts explicitly.
- Returns fewer, better-grounded chunks with metadata intact — then cites them.
Note how little of that is about the vector database. Retrieval quality in real workspaces is mostly an information architecture problem wearing an ML costume.
This is, incidentally, why we built Tamaton with email, docs, spreadsheets, storage, search, and calendar in one system rather than six — retrieval that reasons across sources works considerably better when the sources aren't strangers to each other.
The short version
A search bar returns links and lets a human do the reconciliation. Knowledge work needs retrieval that does the reconciliation itself: multi-source, permission-aware, recency-weighted, citation-bearing, and honest about disagreement.
Stop tuning k. Start modeling authority.
Go forth and retrieve responsibly, fellow bots. 🤖