> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Deep Research node

> Research a question across the open web with a budgeted, multi-pass agent, and file the cited result into a knowledge base.

export const release_0 = "5.12"

<Badge color="blue" icon="cloud">SaaS · {release_0}</Badge>

<Info>
  **Available on SaaS with FlowX.AI {release_0}.** This feature is live on managed (SaaS) deployments now. Self-hosted deployments will receive it with the next LTS release family.
</Info>

## Overview

The **Deep Research** node investigates a question across the open web and files a cited report into a Knowledge Base. It is a budgeted, multi-pass agent: it plans the work, sends sub-researchers to search and read pages, grades what they bring back, and keeps going until the budget runs out or it has enough to report.

Unlike a [Custom Agent](./custom-agent-node), you do not write the method. The research prompt is built into the node, so you describe the subject and the node decides how to pursue it.

<Info>
  **The result always lands in a Knowledge Base.** Research is filed as text so retrieval nodes and other agents can reach it later. A rendered document is optional, and off by default.
</Info>

***

## Adding a Deep Research node

Open your workflow in **Integration Designer**, then pick **Deep Research** from the **AI Agents** group in the left node panel, alongside **Custom Agent** and **Intent Classification Agent**.

***

## Configuring the node

<ParamField path="researchQuestion" type="string" required>
  What the node should investigate. Bind workflow data with `${...}` placeholders, and add any standing guidance you want the node to follow.

  **Example:**

  ```
  Research ${topic}. Prefer primary sources.
  ```

  There is no **Instructions** field on this node. The research method itself is built in, so this field carries the subject and your guidance, and nothing about how to search.
</ParamField>

<ParamField path="researchDepth" type="string">
  How far the node fans out, chosen from four options.

  **Default:** `Standard`

  **Quick**, **Standard** and **Deep** apply budgets tuned by the platform, shown under the control as a summary such as `24 passes · 6 tool calls per sub-researcher`:

  | Depth        | Passes | Tool calls per sub-researcher |
  | ------------ | ------ | ----------------------------- |
  | **Quick**    | 12     | 4                             |
  | **Standard** | 24     | 6                             |
  | **Deep**     | 48     | 10                            |

  **Custom** replaces the summary with two fields you set yourself:

  | Field          | What it controls                                                                                  |
  | -------------- | ------------------------------------------------------------------------------------------------- |
  | **Passes**     | How many model calls the whole run may make. More passes let the node dig further, and cost more. |
  | **Tool calls** | How many searches and page fetches each sub-researcher may make before it has to report back.     |

  <Note>
    **The number of sub-researchers is always the node's decision.** It is not a setting, on any depth.
  </Note>
</ParamField>

<ParamField path="sources" type="object">
  Which parts of the open web the node may read. Leave both lists empty to allow anything.

  Open **Manage lists** to edit them:

  | List           | Effect                                                            |
  | -------------- | ----------------------------------------------------------------- |
  | **Allow only** | When set, the node may read **only** these domains.               |
  | **Deny**       | Domains the node must never read, even when no allow list is set. |

  <Warning>
    **An allow list is a hard restriction. Nothing outside it is read.** An over-strict list yields no sources and fails the node.
  </Warning>

  Each list holds up to **50** entries and takes either mode:

  * **Static** — type hostnames such as `reuters.com`. Anything that is not a hostname is rejected, and a duplicate is refused with `Already in the list`.
  * **Dynamic** — bind a single `${...}` expression that resolves to the whole list, such as `${allowedDomains}`. Anything past the first 50 entries is ignored at runtime.
</ParamField>

<ParamField path="storeResponse" type="object" required>
  Where the report is indexed so retrieval nodes and other agents can reach it. All three fields are required.

  | Field               | Description                                                                           | Default          |
  | ------------------- | ------------------------------------------------------------------------------------- | ---------------- |
  | **Knowledge Base**  | The Knowledge Base to write into. **Store** stays locked until you pick one.          | —                |
  | **Write mode**      | **Append Content** adds to what is there, **Replace** overwrites it.                  | `Append Content` |
  | **Store**           | The store inside that Knowledge Base.                                                 | —                |
  | **Metadata values** | Optional metadata attached to what is written. Shows `No metadata values` when empty. | —                |

  <Warning>
    **Check the store name.** An unrecognised name creates a new store rather than failing, so a typo produces a second store that looks empty instead of an error you can see.
  </Warning>
</ParamField>

<ParamField path="generateReport" type="boolean">
  Renders the research as a document in addition to filing it as text, and lets you choose the format and where it lands.

  **Default:** `false`

  The research is always filed as raw text for the Knowledge Base, so turning this off does not lose the result. Turn it on when someone needs a document to read.
</ParamField>

<ParamField path="subResearcherModel" type="string">
  The model the sub-researchers use, set on the **AI Model** tab.

  **Default:** `Same as orchestrator`

  A cheaper model here is the usual way to make a wide fan-out affordable, since the sub-researchers do most of the calls.
</ParamField>

<ParamField path="responseKey" type="string" required>
  The key the node's output lands under in workflow state.

  **Default:** `responseKey`
</ParamField>

<Note>
  This node has no **Request timeout** setting. The shared timeout does not apply to it, so the control is not shown rather than shown and ignored.
</Note>

***

## Related resources

<CardGroup cols={2}>
  <Card title="Custom Agent node" icon="robot" href="./custom-agent-node">
    Agents where you write the instructions and attach the tools
  </Card>

  <Card title="Knowledge Base overview" icon="database" href="./knowledge-base-integration/knowledge-base-overview">
    Where the research is filed, and how to retrieve it
  </Card>
</CardGroup>


## Related topics

- [FlowX.AI 5.12.0 Release Notes](/release-notes/v5.x/v5.12.0-september-2026/v5.12.0-september-2026.md)
- [Integration Designer](/5.9/docs/platform-deep-dive/integrations/integration-designer.md)
- [Custom Agent node](/5.9/docs/platform-deep-dive/integrations/custom-agent-node.md)
- [Reporting plugin](/5.9/docs/platform-deep-dive/plugins/custom-plugins/reporting/reporting-overview.md)
- [SOAP System](/5.9/docs/platform-deep-dive/integrations/soap-system.md)