Knowledge bases with per-KB vector collections and semantic search

An agent is only as trustworthy as the knowledge behind it, and most RAG failures are ingestion failures: wrong chunking, stale indexes, retrieval settings nobody can reproduce. Botmanor makes the whole pipeline a managed, inspectable object.

A knowledge base starts with documents. Each one is split into chunks using a strategy you choose per corpus — fixed-size, recursive, semantic, markdown-aware, or code-aware — because a policy PDF and a TypeScript repository should not be chopped the same way. Chunks are embedded and written to that knowledge base's own vector collection, and the index moves through an explicit lifecycle: empty, indexing, ready (with failed and rebuilding states when reality intervenes). You always know whether a KB is actually queryable.

Then you validate before you trust. Semantic search runs real queries against the real index — type the questions your users will ask and see exactly which chunks come back, with relevance scores. This is the step most teams skip and regret: with Botmanor it is the natural next click after indexing.

Retrieval settings are captured as retrieval profiles — reusable recipes specifying the mode (vector, hybrid, or BM25), top-K, and score thresholds. Profiles attach to agents and can even be distributed through the store as packages, so "the retrieval configuration that works for legal documents" becomes a shareable asset rather than tribal knowledge. (Vector search is the implemented path today; hybrid and BM25 modes are stored configuration ahead of the runtime that consumes them.)

One roadmap line, stated plainly: injecting retrieved chunks into the live agent answer loop is part of the agent runtime upgrade. Today you build the corpus, prove retrieval quality with semantic search, and codify the recipe — so grounded answers turn on over a knowledge layer you have already validated.