--- title: "Memory for a knowledge base assistant" description: "Memory for a knowledge base assistant: how an answer over internal documentation reaches the revision in force today, cites the article behind it, and reports when the documentation does not cover the question." canonical: https://past.dev/use-cases/knowledge-base last-updated: 2026-10-16 --- # Memory for a knowledge base assistant Source: https://past.dev/use-cases/knowledge-base An assistant over internal documentation answers questions the handbook already covers: how to run a deployment, what the expense policy allows, which runbook applies. Memory for a knowledge base assistant has to reach the revision in force today rather than the one it replaced, cite the article behind an answer, and say when the documentation does not cover the question. This page describes what that takes. ## What you are building An assistant over the documentation a company has already written: the internal handbook, runbooks, help centre articles, onboarding material, policies. The reader is an employee or a customer who wants an answer rather than a list of pages to read. This is the application most teams reach for a vector store to build. A vector store is a good retriever and a poor librarian: it will find passages that resemble the question, and it has nothing to say about which of them is still true. See [vector database vs memory](/vector-database-vs-memory) for the storage comparison. ## Why memory decides whether it works - **The retired article answers first.** The 2023 page and the 2026 revision are both indexed and both relevant. Nothing in a similarity score records that one replaced the other. - **Documentation contradicts itself across pages.** Two runbooks describe the same procedure differently because one was updated. Retrieval returns both and the model picks. - **Coverage gaps are answered anyway.** The question is reasonable, the documentation does not cover it, and a fluent answer is produced from adjacent material. In an internal handbook that becomes policy nobody wrote. - **One system, many names.** A service called by its project name in the runbook, its repository name in onboarding and its display name in the help centre is one thing described three ways. ## What past.dev provides - **Revisions ordered by date.** The current procedure is the one supported by the most recent evidence, and the revision it replaced keeps its date rather than competing with it. See [fact supersession](/glossary/fact-supersession). - **Citations back to the article** and the sentence within it, so a reader can open the page rather than trusting a paraphrase. - **Evidence for grounded answers.** Your application assesses whether the returned sources support an answer and abstains when they do not. - **Entity resolution across pages**, so a service, a team or a system named three ways answers as one thing. - **Audience filtering inside the search**, so an assistant shared with customers does not reach an internal runbook. Audiences are configured through the API or the console. ## Cost and accuracy Ingestion is metered by payload size and recall is not metered, so a handbook that has grown for a decade costs about the same per question as one written this year, and questions can be asked freely rather than rationed. Re-running a documentation sync is free where content has not changed, because ingestion is idempotent by content hash, so a nightly job can be simple and still be correct. On accuracy, the two properties that decide this use case are supersession and abstention. An assistant that quotes a retired procedure sends somebody to do the wrong thing, and one that invents a policy creates a rule the company did not write. The returned sources let your application check freshness and support before it answers. Measured results are on [benchmarks](/benchmarks). ## Getting there 1. Send each article, runbook and policy to `POST /api/v1/ingest` with the date it was written or last revised. 2. Re-send on every edit. A revision creates a new version and supersedes the previous one, which keeps its date. 3. Set an `audience` where a document is internal only, so a customer-facing assistant cannot reach it. 4. Call `POST /api/v1/recall`, pass the returned evidence to the model, and apply an explicit sufficiency policy so unsupported questions receive an abstention. ## Frequently asked questions ### How is this different from putting the handbook in a vector store? A vector store retrieves passages that resemble the question. It has no record of which revision replaced which, so a retired article competes with its replacement on similarity alone. Replacing a source id updates the memory that depended on it. Recall returns dated evidence; the application assesses whether that evidence answers the question. ### What happens when we edit a page? Send it again. The new content becomes the current revision and the previous one keeps its own date, so the current procedure answers today and the earlier one remains available for a historical question. ### Can one assistant serve employees and customers? A data point names an audience slug, and reads respect the requested identity and its audiences. Manage audiences in the console or with the API, and derive the identity from the authenticated user. ## Related - [Productivity](https://past.dev/use-cases/productivity) - [Customer support](https://past.dev/use-cases/customer-support) - [Vector database vs memory](https://past.dev/vector-database-vs-memory) - [Benchmarks](https://past.dev/benchmarks) - [Quickstart](https://past.dev/docs/memory-api/quickstart)