Vector RAG — narrative evidence
Semantic search over unstructured documents: policies, manuals, guides, transcripts. The right tool when the user’s words and the document’s words differ but mean the same thing.
Ground answers in evidence
Agentic RAG for answers grounded in your knowledge
Upload PDFs, DOCX, Markdown, CSV, and text into a schema-scoped knowledge base. Your agents search it automatically while they reason — combining retrieved evidence with tools and memory, with no RAG plumbing on your side.
- agentic RAG
- AI knowledge base
- RAG agents
- knowledge base software
What is agentic RAG?
Classic RAG is a static pipeline: retrieve once, stuff the results into the prompt, answer. Agentic RAG puts retrieval inside the agent’s reasoning loop instead — the agent decides when to search, what to search for, and whether the evidence it found is enough, then combines what it retrieved with tool calls and memory before answering.
The practical difference: a static pipeline retrieves for every question, even the ones that need a tool call or a follow-up query instead. An agentic retriever searches again with a refined query when the first pass comes back thin, skips retrieval when the answer needs live data from an API, and cites the evidence it actually used. If you are new to the pattern, start with what AI agents are — agentic RAG is that reasoning loop applied to your documents.
No plumbing on your side
RAG agents that retrieve while they reason
You upload documents. The engine chunks them, embeds them, and exposes retrieval to the agent. That is the whole integration.
- Automatic retrieval. Agents search the knowledge base via vector similarity as part of their reasoning — you never orchestrate a retriever, ranker, or prompt-stuffing step in your application code.
- Per-schema isolation. Knowledge is scoped to a schema, so your support agent’s policy documents never leak into an unrelated agent system running on the same engine.
- Evidence plus action. The same reasoning loop that retrieves a warranty clause can then call a scoped MCP tool to look up the order it applies to — grounded answer, live data, one run.
- Visible lifecycle. Every document moves through uploading → indexing → ready, so operators can see exactly when new knowledge becomes retrievable.
This is the retrieval layer behind AI agents for customer service: answers drawn from approved policy and product documents instead of the model’s general training.
Ingestion
AI knowledge base formats: what you can ingest
Five document formats cover most of the knowledge a production agent needs. Uploads are chunked and embedded server-side.
| Format | Best for |
|---|---|
| Manuals, contracts, policy documents, and reports — the formats most institutional knowledge already lives in. | |
| DOCX | Working documents from your team: procedures, product specs, internal guides. |
| Markdown (md) | Engineering docs, wikis, and READMEs — structure-preserving and ideal for chunking. |
| CSV | Tabular reference data such as price lists, FAQs exported from other systems, or glossaries. |
| Plain text (txt) | Transcripts, exports, and anything else — the universal fallback. |
Documents are files you upload and control — an approved, versioned corpus rather than whatever a crawler found. When a source changes, re-upload and reindex; the engine re-chunks and re-embeds it through the same lifecycle.
Runs where your data already lives
Knowledge base software without a second database
Most RAG stacks bolt a dedicated vector store onto your architecture. SyntheticBrew stores embeddings in PostgreSQL via pgvector — the same database that already holds your sessions and configuration. One engine, one database, nothing extra to operate, back up, or secure.
- pgvector storage. Vector search runs inside PostgreSQL — self-hosted deployments keep every embedding on their own infrastructure.
- Bring your own embeddings. The embedding model is a first-class registry entry: point it at Ollama for fully local embedding, or at any OpenAI-compatible embedding endpoint.
- Reindex on demand. Dedicated reindex endpoints re-process documents when you change the corpus or switch embedding models.
Agentic RAG vs knowledge graph retrieval
Two retrieval modes, two kinds of questions. Production agents usually need both — SyntheticBrew runs them side by side on the same agent.
Knowledge graph — exact records
Typed, deterministic lookups over declared entities: IDs, prices, statuses, relationships. The right tool when an approximately correct answer is simply wrong. See knowledge graphs for LLMs.
Questions
Agentic RAG: common questions
What file formats can I upload to the knowledge base?
Five formats: txt, md, csv, pdf, and docx. Each upload moves through a visible status lifecycle — uploading, then indexing, then ready — so you always know when an agent can retrieve from a document. Web-page ingestion is not part of the pipeline; you upload files.
Which embedding models can I use?
Any you want. The embedding model is a first-class entry in the model registry, and you can serve it from Ollama for a fully local setup or from any OpenAI-compatible embedding endpoint. Vectors are stored in PostgreSQL via pgvector, so there is no separate vector database to run.
What happens when a document changes?
Re-upload it and trigger a reindex. The engine re-chunks and re-embeds the document through the same uploading → indexing → ready lifecycle, and agents retrieve from the fresh version once it reaches ready.
When should I use a knowledge graph instead of RAG?
Use vector RAG for narrative, unstructured documents where semantic similarity is the right match. Use a knowledge graph when the agent must return exact records — IDs, prices, statuses, relationships — where an approximate answer is a wrong answer. SyntheticBrew runs both on the same agent.
Keep exploring
Agentic RAG pairs with these capabilities
Ground your agents in your own documents
Upload a PDF, watch it reach ready, and ask the agent about it — in Cloud or on your own PostgreSQL. No retriever code, no second database.