Agents and Knowledge

A Knowledge Base only affects what an Agent knows once you bind it. In the Agent Builder's Knowledge section, check off one or more of your project's Knowledge Bases — everything else on this page configures how the Agent actually uses them at run time.

Agentic RAG

Default: on.

• On — the Agent gets one search tool per bound Knowledge Base and decides for itself, per turn, whether and which one to call. Each tool is named after the KB (e.g. a KB called "Equipment Manuals" becomes a search_equipment_manuals tool the model can invoke with a query), so with several KBs bound, the model can search only the relevant ones instead of everything at once.
• Off — no tool-calling. Every bound KB's top results for the incoming message are retrieved and injected straight into the Agent's context automatically, on every turn.

Agentic RAG on is the better default for an Agent with more than one KB, or where knowledge is only sometimes relevant to a given question. Turn it off for an Agent that should always ground every answer in its KB(s), or when you'd rather not rely on the model deciding to search.

Per-Knowledge-Base settings

Expand a checked KB to configure it individually — these apply whether Agentic RAG is on or off:

• Max results — how many chunks this KB returns per search. Default 10, range 1–50.
• HyDE Retrieval — default off. When on, the Agent first asks its own model to write a short hypothetical answer to the query, then searches the KB using that hypothetical answer instead of the raw query. This often finds better matches for short or vaguely-worded questions, at the cost of one extra model call per search. If the hypothetical-answer step fails for any reason, the search silently falls back to the raw query rather than failing the turn.

Metadata filtering

Default: off. When on, each generated search tool also accepts a filters argument, and the model can supply exact-match constraints against the KB's metadata fields (the built-in and custom fields you set up in Creating a Knowledge Base) — for example, narrowing a search to one document by name. This only has an effect with Agentic RAG on, since it's the model supplying the filter through a tool call; the always-inject path (Agentic RAG off) never filters.

Failure behavior

A Knowledge Base search that fails (the service is unreachable, times out) never fails the Agent's run — it's treated as "no results found" and the Agent continues without that context.

Via the public API

None of this configuration is exposed on the Agent run endpoints — it's set once in the Agent Builder and applies automatically every time that Agent runs, whether triggered through Studio or through POST /agents/{agentId}/run. A caller using the public API doesn't need to know or do anything differently for a knowledge-grounded Agent versus a plain one.