Kernel Memory: Microsoft's Archived RAG Indexing Service and What It Actually Ships

The gap Kernel Memory targets: documents that need to be asked questions

The problem is not search. It is that a pile of files (meeting transcripts, business plans, whatever a team already stores) has no queryable form, so an LLM cannot ground an answer in it or point back at the source. Kernel Memory's README frames the project as a multi-modal AI service specialized in indexing datasets through custom continuous data hybrid pipelines, with support for retrieval augmented generation, synthetic memory, prompt engineering and custom semantic memory processing. The audience named in the description is users, teams and applications, and the integration targets are Semantic Kernel, Microsoft Copilot and ChatGPT plugins. That is a specific audience: .NET developers building assistants, or teams standing up a document question-answering endpoint, who want citations rather than a chat transcript. The README also states the system enables natural language querying for answers from indexed data complete with citations and links to the original sources. Citations are the point. An answer without a pointer to the grounding document is not useful in a business context, and the API returns them by design.

The ingestion pipeline: extract, partition, embed, store

The README describes the default documents ingestion pipeline in four numbered steps. First, extract text by automatically recognizing the file format. Second, partition the text into small chunks ready for search and RAG prompts. Third, extract embeddings using any LLM embedding generator. Fourth, save embeddings into a vector index such as Azure AI Search or Qdrant. That is the whole architecture in miniature, and the repository's lambda architecture diagram is the visual version of it. Two details matter more than the summary. The pipeline is described as continuous and hybrid, which is the project's framing for combining retrieval over embeddings with other processing rather than treating vector search as the only retrieval path. And tags are a first-class part of ingestion, not a query-time afterthought: the C# example attaches AddTag calls for user, collection and fiscalYear to a Document, and the Python example sends the same tags as a form field on the upload request. The README says the example shows how to safeguard private information by specifying who owns each document and how to organize data for faceted navigation using tags. Faceted navigation and access control are different requirements that share one mechanism here, which is worth noticing before you rely on it for either.

Three deployment shapes and the config keys that drive them

Kernel Memory ships as a web service, a Docker container (kernelmemory/service on Docker Hub), a plugin for ChatGPT, Copilot and Semantic Kernel, and a .NET library for embedded applications. The Aspire example in the README is the clearest look at configuration. It adds the container and sets environment variables with a double-underscore separator: KernelMemory__TextGeneratorType set to OpenAI, KernelMemory__DataIngestion__EmbeddingGeneratorTypes__0 set to OpenAI, KernelMemory__Retrieval__EmbeddingGeneratorType set to OpenAI, and KernelMemory__Services__OpenAI__APIKey set to your key. Note that ingestion and retrieval have separate embedding generator settings, and that the ingestion key is an indexed collection (EmbeddingGeneratorTypes__0) while retrieval takes a single value. That asymmetry is a real configuration surface: mixing embedding models between ingestion and retrieval is a way to get answers that do not match the indexed vectors. Embedded use is shorter. The README shows a KernelMemoryBuilder chained with WithOpenAIDefaults reading OPENAI_API_KEY from the environment, then Build<MemoryServerless>(). Client access from C# uses MemoryWebClient pointed at a URL such as http://127.0.0.1:9001, and the Python example POSTs multipart form data to /upload with documentId and a tags list.

What the retrieval API returns, and why token reporting is in the README

AskAsync takes a question and an optional filter. The README's second example passes filter: MemoryFilters.ByTag("user", "devis@contoso.com") and describes that as a way to implement security filters. Answers include citations and, per the README, all the information needed to verify their accuracy, pointing to which documents ground the response. The README also documents a token usage report on generated answers, with a sample loop printing ServiceType, ModelName, ModelType, ServiceTokensIn and ServiceTokensOut, and a sample output line showing Azure OpenAI gpt-4o with 24356 input tokens and 103 output tokens. Treat that number as an illustration of the report's shape, not as a benchmark: it is one printed example in the documentation, not a measured cost model. The reason token reporting earns space in the README is that RAG prompts are input-heavy. A large retrieved context dominates the bill, and the report is the only way to see it per request. If you are evaluating this project, the token report is one of the more practically useful pieces of the API, because it makes the cost of a retrieval configuration visible without instrumenting the pipeline yourself.

The limitation that overrides everything else: archived and unsupported

The README opens with a caution block stating this is an archived research project, that the code serves as a learning resource and not production software, that it should be used with caution and at your own risk, and that no support is provided. It repeats the point later: the code serves as a demonstration and is not an officially supported Microsoft offering. The repository metadata confirms the archived state. This is not a maturity caveat you can plan around with a support contract. It means no security patches, no compatibility guarantees with the LLM and vector store SDKs the pipeline depends on, and no answer to a bug report. There is a second, quieter limitation in the design. Tag-based filtering is described as the mechanism for safeguarding private information, but the README does not state where that filtering is enforced. If filters are applied when assembling the prompt rather than when querying the index, a misconfigured caller can retrieve text it should not see. The documentation does not resolve this, and I am not going to claim it does. Anyone considering tag-based access control here has to read the retrieval code at their pinned version and confirm the enforcement point.

Where a plain vector database is the better answer

If your requirement is storing embeddings and running similarity search, a vector database used directly is the smaller and better-maintained choice. Qdrant, which Kernel Memory lists as a supported index, is a server you can run and upgrade on its own schedule; it has no opinion about chunking, prompts or citations. Kernel Memory's value sits above that layer: format detection, partitioning, embedding orchestration, tag metadata and the RAG prompt assembly that produces an answer with citations. The difference in approach is that a vector database returns nearest neighbours and stops, while Kernel Memory returns a generated answer plus the sources behind it, and owns the pipeline that produced both. The trade is control. With a vector store you write the chunking and the prompt yourself, which is more work but leaves every decision visible and testable in your codebase. With Kernel Memory you inherit a pipeline whose partitioning behavior and filter enforcement you did not write, in a repository that will not be updated. If your team already has a retrieval stack, adding Kernel Memory means maintaining a second one.

Licence, upgrades, and the real maintenance bill

The licence is MIT, and the README links the LICENSE file. MIT is permissive: it allows use, modification and redistribution with the copyright notice and permission notice retained. That is the extent of what can be said here; whether your organization's policy treats an archived Microsoft research project differently from any other MIT dependency is a question for your own review, not a legal conclusion this article can supply. On upgrades, the release history shows date-stamped package versions in the 0.98 series, with packages-0.98.250508.3 published in May 2025 and two releases in March 2025, and the last push to the default branch in June 2026. The version numbering signals pre-1.0, so API changes between releases are a live possibility rather than a theoretical one. The maintenance cost is therefore not a subscription or a support fee. It is the cost of forking or vendoring the code you depend on, tracking the upstream LLM and vector store SDKs yourself, and re-verifying the pipeline when those dependencies move. That is a real engineering line item, and it is the number to compare against writing the ingestion pipeline in-house.

Editorial conclusion

Adopt Kernel Memory only if you want a readable reference for how an ingestion pipeline, tag-based filtering and citation-bearing RAG answers fit together, and you are willing to vendor the code and own it yourself. Do not adopt it as a supported dependency for a production service: the README states plainly that it is an archived research project with no support, and the repository has been archived. Before committing, verify two things in the source at your chosen tag: how the pipeline handles a document that fails at the embedding step, and whether the tag filters you need are applied at index time or only at query time, because those determine whether your access boundaries hold.

Official sources

1. Issues
2. License: MIT
3. microsoft/kernel-memory on GitHub
4. README
5. Releases