Relevance AI: How to Connect Your Data as Knowledge

An agent that does not know your prices, your policies, or your product will improvise, and it will do so confidently. Knowledge is how you stop that. It is also the feature people configure fastest and wrongest, usually by pouring in everything they own and hoping retrieval sorts it out.

The mental model that helps is this: knowledge is a table, not a folder. Rows and columns, searchable, editable, and shareable across agents. Once you picture it that way, most of the configuration decisions answer themselves.

What is Knowledge in Relevance AI?

It is their retrieval augmented generation layer, which is a long way of saying the agent looks something up before it answers instead of relying on what the model already learned. Their documentation describes it as processing your documents, extracting the information, and making it searchable for agents.

The important property is that one knowledge base can serve many agents and tools. Update it once and everything reading it sees the new version, with no rebuild and no retraining. That is why it is worth structuring properly on day one rather than treating it as a dumping ground.

Where can the data come from?

Their documentation describes four ways to create a knowledge base, and they suit very different kinds of information. Pick by how the source changes over time, not by what is quickest to click.

• An empty table you fill in: you define the columns and enter the rows yourself. Best for small, high value facts such as pricing rules or escalation policies, where you want every word deliberate.
• Uploaded files: their documentation lists formats including CSV, PDF, Excel, JSON, and audio. Best for documents that already exist and rarely change.
• A website: you enter URLs and configure crawl settings such as depth and which pages to include. Best for public documentation and product pages you own.
• A synced integration: their documentation lists integrated knowledge sources including Google Drive, SharePoint, and Notion. Best when the source of truth already lives somewhere your team edits daily.

Create a knowledge base and attach it

1. Decide what question this knowledge answers — One knowledge base per subject beats one for everything. If you cannot name the questions it should answer, you are not ready to load it.
2. Open Knowledge and choose Create Knowledge — This is where you pick between an empty table, uploading files, crawling a website, or connecting an integrated source.
3. Set it up according to the source — An empty table needs columns defined before rows. Uploads need the files and any parsing options. A website needs the URLs and the crawl settings, including how deep to go.
4. Name it for what it contains — The name ends up in front of the agent when it decides where to look. Support Policies is a useful name, Knowledge 2 is not.
5. Open the agent and go to its Knowledge section — Knowledge is attached from the agent's own configuration, where you select which knowledge bases it can reach. An agent can hold more than one.
6. Choose add all to prompt or allow the agent to search — This is the decision that matters most, and it is covered in detail below. Their documentation frames it as small and simple versus large and complex.
7. Ask the agent five real questions — Use questions where you already know the correct answer, including one the knowledge does not cover. What the agent does with that last one tells you whether it will invent an answer under pressure.

That last step is the one people skip, and it is the only one that tells you the truth. An agent that answers four questions correctly and invents the fifth is more dangerous than one that fails all five, because you will trust it.

Add all to prompt, or let the agent search?

This is the fork in the road, and their documentation is direct about it. Adding everything to the prompt puts the whole knowledge set in front of the agent on every run. Allowing the agent to search means it queries the knowledge through a tool and gets back only what matched.

• Add all to prompt: suited to small, simple sets, and it needs no extra configuration. The agent cannot miss a fact because the fact is always in front of it. The cost is that everything is in front of it every single time.
• Allow agent to search: suited to large or complex sets, and it scales. The agent searches when it decides it needs to, which is more economical and introduces the possibility of it searching badly or not at all.

Their documentation notes that knowledge shows up in the agent configuration as either a tool or a variable, depending on which route you chose. That is worth knowing when you go looking for it later and cannot find it where you expected.

None of these decisions is difficult in isolation. They just have to be made, per knowledge base and per agent, before the thing is dependable. That is the honest shape of any builder platform, and it is the reason a first knowledge setup takes longer than people plan for.

This is the seam we designed away at Sistava. Rather than building a knowledge base and then choosing a retrieval mode for it, you point an AI Employee at what it should know and it works out how to hold it. The question you answer is what the employee needs to know, not how the lookup should be configured.

How does the agent find the right row?

Their documentation describes three retrieval approaches. Semantic search matches on meaning, so a question phrased differently from the source still finds it. Hybrid search adds keyword matching on top, which helps with exact terms like product codes. Filtered retrieval narrows results using metadata attributes before searching at all.

Their guidance on capacity is the part worth internalising. They note that large knowledge bases are supported, but that performance comes from relevant, well structured information rather than sheer volume. In practice that means one clear row per fact beats a long document containing the same fact somewhere in paragraph nine.

Their step catalogue also separates searching from fetching. There is a knowledge search step that uses retrieval, and a get knowledge step that returns information without it. When you know exactly which rows you want, retrieval is overhead rather than help.

How do you keep the knowledge current?

Sync it from where it already lives, or write to it from a tool. For Google Drive, their documentation describes adding it from the Knowledge section of the agent builder, authenticating the account, and selecting the specific files the agent should read.

Two concrete numbers from that page are worth planning around. Agents fetch data from the selected Drive files every fifteen minutes, and the file size limit is fifty megabytes, with larger files producing an error. Their documentation also notes that if fetching keeps failing, reconnecting Drive is the first thing to try.

The knowledge tables are writable as well as readable. Their step catalogue includes inserting rows, updating existing rows, and deleting rows, so a tool can record what an agent learned rather than losing it at the end of the task. There is also an enrichment option that runs a tool across the rows of a table to add generated columns, which is how you turn a raw list into something with a summary or a score attached.

If your data already flows through an automation platform, that route works too. Relevance AI publishes an upsert action on Zapier that writes into a knowledge table, which is useful when the system of record is somewhere with no direct integration.

What are the limits and gotchas?

• Volume is not the goal: their own guidance favours relevant, well structured information over maximum size. Uploading everything you own usually makes retrieval worse, not better.
• Drive files are capped at fifty megabytes: anything larger errors rather than being truncated, so a single oversized export can silently be the reason your agent knows nothing about a topic.
• Sync is periodic, not instant: with a fifteen minute fetch interval on Drive files, an agent can answer from a version of a document that is a few minutes stale. That matters for prices and availability.
• Crawl depth is a decision: when you build knowledge from a website, the depth setting decides whether you captured your documentation or also captured your careers page and your blog archive.
• Check retention on tables you rarely touch: their documentation carries a page on inactive table deletion, so if you keep a knowledge base you almost never open, confirm their current policy rather than assuming it sits there forever.
• Searching costs Actions: an Action is counted whenever an agent runs a tool, and knowledge search is a tool. An agent that searches three times per answer costs three times as much as one that searches once.

Credit where it is due, the knowledge layer here is one of the more thoughtful parts of the platform, particularly the fact that it is a table you can write back into rather than a static upload. The work is in the decisions around it. At Sistava we took those decisions off the table entirely, because we think most people want an AI Employee that knows the business, not a retrieval configuration they have to tune. If you enjoy tuning it, the platform rewards you for it.

Sources

• Relevance AI documentation, Create knowledge
• Relevance AI documentation, Find and use knowledge
• Relevance AI documentation, Integrated knowledge sources
• Relevance AI documentation index of all pages
• Relevance AI documentation, Pricing
• Zapier, Gmail and Relevance AI integration, listing the upsert data action