Knowledge Bases & RAG

A knowledge base is a collection of documents you upload. Its contents are chunked, embedded, and indexed so an agent can search them by meaning rather than by keyword — and answer from your material instead of from the model’s training data. This is a different system from memory. Memory is what the agent has learned about a conversation or a user. Knowledge is what you gave it to read.

​

The pipeline

Documents are extracted to markdown, split into chunks, embedded, and stored in a per-account vector collection. Chunking is token-based and sized against the embedding model’s capacity, with a small overlap between adjacent chunks so a sentence spanning a boundary is not lost. Chunks below a minimum size are not embedded on their own. Which embedding model is used is an account-level indexing setting rather than a fixed platform property. New accounts start on text-embedding-3-small. The vector dimension follows from the model you are on.

​

Two ways an agent reaches knowledge

This is the distinction that matters when you configure an agent, and the two are independent.

​

Attach the knowledge base to the agent

List knowledge bases on the agent, and relevant chunks are retrieved and injected into context automatically at the start of each run. The agent does not decide to search; the search happens. Defaults for that automatic retrieval: at most 10 chunks, with a minimum relevance score of 0.15. A per-knowledge-base max_results can lower the cap. Use this when the material is always relevant — product documentation for a support agent, policies for a compliance assistant.

​

Bind the Knowledge Retrieval capability

Bind KnowledgeRetrieval and the agent gets three tools it can call when it decides to: search, list, get_by_id — namespaced knowledge_search, knowledge_list, knowledge_get_by_id. Use this when lookups are occasional and the agent should choose the query.

​

Both together

They compose. Attached bases give every turn a baseline of context; the capability lets the agent go looking for something specific on top of that. A common shape is to attach the one base that is always relevant and bind the capability for everything else.

​

Reranking

Vector similarity gets you close. It also confidently returns things that are about the right topic but do not answer the question. Reranking adds a second pass: fetch more candidates than you need, then have a small model order them against the actual query and keep the top slice. Reranking can be overridden per account and per knowledge base. A knowledge base that leaves it unset inherits the account setting, which in turn inherits the platform setting. The trade is latency and a small model call per search. For a support agent answering from policy text it is usually worth it; for a high-volume lookup where the top vector hit is reliably right, it may not be.

​

What semantic search buys you

The embedding puts the question and the passage near each other in vector space even when they share no words. That is the whole trick, and it is why chunk boundaries matter: a chunk that mixes three topics embeds to the average of three topics and matches none of them well.

​

Managing knowledge bases

In the Portal, Knowledge Bases is its own section. Create a base, upload documents, and ingest runs in the background — the Portal receives a live hint when it completes. Removing a document removes its chunks from the index.

​

Costs

Indexing and storage are metered. See Pricing.

​

Practical guidance

---

Next: Tool Presentation — controlling how many tools a model sees.