> ## Documentation Index
> Fetch the complete documentation index at: https://docs.os.default.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Deep Research
> Send an agent to research the live web from a workflow and return structured, typed results.
The **Deep Research** node sends a research agent to the live web and returns what it finds as
structured fields. It is powered by [Parallel](https://parallel.ai), a web research engine built
for AI agents.
Use it when the answer is not in your CRM and not in an enrichment provider's database — a
company's growth priorities, the roles on its careers page, whether its site has a live pricing
page.
Add the node in the **Workflows** builder with **Add Node**.
Deep Research is in beta. If you do not see it in the picker, contact support.
## Deep Research or AI Prompt?
The [AI Prompt](/workflows/steps-ai) node and the Deep Research node both take a prompt. They do
different jobs.
| Node | What it works with | Use it to |
| ----------------- | ------------------------------ | ---------------------------------------------------------------------------------------- |
| **AI Prompt** | Data the workflow already has. | Summarize, classify, rewrite, or extract from trigger data and earlier nodes. |
| **Deep Research** | The live web. | Find net-new information that is not in your workflow data or your enrichment providers. |
AI Prompt returns in a few seconds. Deep Research browses real web sources, so a run takes
longer — from several seconds for a narrow question to noticeably longer for a broad one. Plan
node order with that in mind.
## Configure the node
| Field | What it does | How to use it |
| ------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Provider** | The research engine. | Fixed to **Parallel**. |
| **Research prompt** | The research ask, in natural language. | Write what to find, where to look, and how to answer. Type `{{` to insert workflow data or to create an output variable. |
| **Output schema** | The structure of the result. | Read-only. Default generates it from the output variables you declare in the prompt. |
## Output variables
Output variables are how the node returns data. Each one becomes a typed field in the result,
and a value later nodes can pick from the variable picker. The node requires at least one.
In **Research prompt**, type `{{` and select **Create output variable**.
Give it a clear name, such as `fitVerdict`, and a type: **String**, **Number**,
**Boolean**, **URL**, or **Currency**.
In the prompt, state exactly what the variable must contain. For a fixed set of answers,
list the permitted values: "Set `fitVerdict` to exactly one of: `Strong Fit`,
`Disqualified`, `Human Check`."
Later nodes pick each variable directly — write it to a CRM field, include it in a Slack
message, or branch on it with a **Multi-Branch** node. You're done.
The result contains exactly the variables you declared. If the agent returns a declared field
with the wrong type, or misses one, the node reports a failed result instead of passing bad
data downstream.
## Branch on the outcome
A common pattern is a research verdict that routes the workflow. Declare a String variable for
the verdict, constrain it to a fixed set of labels in the prompt, and add a **Multi-Branch**
node after Deep Research with one branch per label.
Keep the branch that matches nothing pointed at a safe path, such as human review. Research
output comes from a language model, so an unexpected value should route somewhere deliberate
rather than fall through.
## Best practices
**Use Deep Research for niche data, not standard firmographics.** Fields with a known home —
funding stage, employee count, LinkedIn URL, founding year — come faster, cheaper, and more
consistently from an [enrichment provider](/workflows/steps-enrichment). Save the research
agent for questions only the live web can answer.
**Be specific.** Research agents perform best on narrow, well-defined questions. Say what to
find, which sources count, and what shape the answer takes. A prompt that asks for one thing
precisely beats a prompt that asks for twenty things loosely.
**Declare more variables instead of one big text answer.** Each typed variable pins down part
of the answer and leaves the agent less room to improvise. A single freeform summary invites
drift; ten narrow fields constrain it.
**Avoid ambiguous asks.** A variable like "recent news" has many possible shapes and sizes.
Constrain it: which time window, what counts as news, how many sentences, what to return when
there is nothing.
**Standardize the format in the prompt.** State character limits, permitted labels, and the
exact fallback value for "not found". Results depend on publicly available web information, so
a workflow that needs a consistent downstream format needs a precise prompt and a defined
output schema — then a test with representative inputs.
**Test before you scale.** Run the workflow's **Test** mode on a handful of representative
records and read the results in the [run logs](/workflows/run-logs) before pointing real
traffic at it.
**Place it with latency in mind.** In a form-triggered workflow that shows a scheduler, a
research node between the submission and **Display Scheduler** delays the booking page by the
length of the research run. If you research before scheduling to qualify or route, keep the
prompt narrow; otherwise run research after the meeting is booked.
## When it fails
If the research request fails, the node does not stop the workflow. It returns a failed result
and the run continues, the same way the [AI Prompt](/workflows/steps-ai) node does. A later
**Multi-Branch** node can react to the failure.
The [run log](/workflows/run-logs) records the result of each research run, including why a
run failed.
## Learn more
Parallel documents its research engine, task types, and processing behavior in the
[Parallel docs](https://docs.parallel.ai).