A European enterprise software company’s platform gives each customer a private, per-account knowledge base built from documents they upload, which the platform’s AI can then answer questions against. Braindoos redesigned the retrieval layer behind that feature.
Vector storage moved from a single-process index — built by chunking and embedding uploaded documents into one flat file per knowledge base, distinguished from every other customer’s data only by its file path — to a managed vector database with native, collection-level multi-tenancy, where each knowledge base is provisioned as its own tenant under a key the application itself generates deterministically. In the same change, ownership of chunking strategy and the per-query retrieval limit moved from being fixed inside the retrieval service’s own code to being configuration the calling application owns: validated through an administrative interface, stored per knowledge base, and passed to the retrieval service at both indexing and query time — with the retrieval service’s own defaults applied only when a caller supplies nothing.
The transition happened in place, inside the same module the earlier implementation lived in, rather than as a parallel rewrite: the application’s live entry points route to the new implementation only.
This account describes an architecture and an ownership change, not a performance outcome — no claim about speed, scale, cost or reliability is made anywhere in it. What it demonstrates is the kind of retrieval-layer redesign that gives the calling application direct, validated control over parameters that used to live only inside the retrieval service’s own code.