A RAG-based sales-policy agent is grounded in the company's policy documents. A sales rep asks about discount approval limits. The agent retrieves a passage from a 2022 version of the policy and answers based on it. The policy has been updated twice since — the limits the agent quoted are wrong. The reps make discount commitments that management later overrides.
What's the architectural fix?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Document staleness is a metadata problem, not a retrieval-quality problem. The retriever may correctly return a document that was the most relevant match by similarity — but if it's the 2022 version of a policy that's since been updated, that's a versioning failure. The fix is to attach effective-date metadata at indexing time, surface it in retrieved passages, and require the agent to prefer the most recent applicable version when it sees multiple. The retriever doesn't know about staleness; the architecture has to.
Embeddings determine retrieval quality, not version selection. Re-training doesn't prevent the retriever from returning an old document — it just changes how documents are matched.
Retrievers rank by relevance, not recency. A 2022 policy passage may be more similar to the query than a 2024 version (if the language is closer). Without explicit version handling, the retriever has no reason to prefer the current version.
A blanket "policy may have changed" is generic noise that users learn to ignore. Specific provenance — "this answer is based on the policy effective March 2024" — is dramatically more useful and forces the system to actually surface dates.