Agent Knowledge

Knowledge is what grounds an agent in your own content. Connect a Knowledge Base in the Designer, then retrieve from it in workflows with a Semantic Search node. Observatory shows what was retrieved and where the agent fell short.

Go to Designer > Knowledge to get started.

Connecting a Knowledge Base

A Knowledge Base (KB) sits at the Workspace level, where multiple agents can share it. Connect a KB to a specific agent in the Designer and make its articles available for retrieval in the agent's workflows.

1

Open the Agent's Knowledge

Go to Designer > Knowledge.

2

Pick the Knowledge Base

Select Connect KB and choose from the Workspace KBs not already connected. If the KB you need doesn't exist yet, select Add New Knowledge Base to create one.

3

Sync the Agent

Select Update Agent Knowledge. New articles only become retrievable after the sync.

Once connected, the KB appears in the table.

The default reply mode comes in two flavors:

Updating Agent Knowledge

A connected Knowledge Base doesn't reach the agent automatically. The Update Agent Knowledge button runs a sync that brings the agent up to date with every connected KB. You need to sync whenever:

• Add, edit, or remove an article in a connected KB

• Re-sync a source

• Connect or disconnect a KB

Syncing is fast but not instant. Until it runs, the agent keeps answering from the previous version of the content.

Synced

The agent retrieves the latest articles from every connected KB.

Needs Sync

Connected KB changes since the last sync are not yet available to the agent.

Disconnecting a Knowledge Base

To stop an agent from retrieving from a Knowledge Base, select the Unlink action. To remove several at once, select the rows and choose Disconnect Selected from Bulk Actions.

The KB itself stays in the Workspace and can be reconnected later. After disconnecting, run Update Agent Knowledge again so the agent rebuilds its retrieval index without the removed sources.

Using Knowledge in a Workflow

Connecting a KB makes its content available to the agent, however retrieving from it at runtime is the workflow's job. Every question the agent answers from your content passes through a workflow with a Semantic Search node somewhere inside it.

Most builders set knowledge retrieval up the same way:

1. Rewrite the question

2. Search the KB

3. Draft the answer

Adapt each step to your use case. Add tag filters, branch on the result, or skip steps your agent doesn't need.

Rewriting the Query

User questions rarely match the wording in your KB. A first-time user might write in a different language, drop product names, or paraphrase a feature in their own words. A follow-up only makes sense in the context of the previous turn. Sending that message straight to the index loses recall.

A query-rewrite LLM solves this. Place an LLM node before the Semantic Search node and instruct it to rephrase the user's message into a search-ready query, using the conversation so far as context.

What you typically configure on the rewrite LLM:

Searching with Semantic Search

The Semantic Search node retrieves the closest-matching articles from the connected KBs and stores them in a variable that downstream nodes can read. It is the only retrieval primitive that the console exposes inside workflows; everything else (reasoning, drafting, deciding when to fall back) happens in surrounding LLM and Flow Control nodes.

Drafting the Answer

The Semantic Search node returns raw articles. Whether that becomes an answer, a follow-up question, or a graceful fallback is the response LLM's job. Place a second LLM node after the Semantic Search node and feed it both the rewritten query and the retrieved sources.

A few things builders commonly do at this stage:

Reporting Missed Questions

When the response LLM decides the retrieved sources don't cover the question, route the workflow through a Missed Question node. The node logs the question so you can review unanswerable topics later and either add the missing content to a KB or build an explicit answer in the workflow.

Verifying in Observatory

Every retrieval that runs in a workflow leaves a trail in Observatory. Open a session and walk through the interaction log to see what the agent actually retrieved and how the surrounding LLMs handled it.

Three signals are worth checking:

Retrieved Sources

Each Semantic Search node logs an entry in the interaction list with two sections:

• Request: the query sent to the index, maxResults, and any tag filters (filterByTags, includedTags, excludedTags)

• Response: numResults plus the full retrieved list in examinedCorpusStr, where each article shows its id, title, body, group, language, and tags

Use this entry to confirm the rewrite produced a clean query, the expected article came back, and the tag filters did what you intended.

Variable Values

The session page lets you follow every workflow variable as the conversation progresses. Inspect the rewritten query, the retrieved sources, and any other variables both before and after each turn to verify the rewrite LLM produced a clean query and the response LLM had the right inputs to draft from.

Missed Questions

When the workflow routes to a Missed Question node, the question is recorded at Observatory > Sessions > Missed Questions. Review the list to spot topics the agent couldn't answer, then add the missing content to a KB.

Best Practices

• Rewrite the query before searching: A clean, KB-shaped query lifts recall more than tweaking the maximum allowed results

• Tag from day one: Include and exclude tag filters are the easiest way to scope retrieval as your KBs grow

• Sync after every KB change: A connected KB whose content changed but whose agent wasn't updated still returns the old articles

• Always handle Cannot Answer: Route the response LLM through a Flow Control branch that catches "no good source" and asks a follow-up or hands off. Silent hallucination is worse than a graceful fallback.