Deep research

Deep research is appropriate when the answer depends on multiple independent facts, recent public signals, ambiguity resolution, or comparison across many candidates.

When to use it

• Company identity, stage, funding, and employee-scale verification.
• Account lookalikes that must match both workflow and commercial maturity.
• Buyer mapping across multiple functions.
• Person research requiring identity resolution and current-role checks.
• Claims that need several source layers rather than one search result.

Let the model route

Do not force a specific database or search backend in the prompt unless your product has a real policy requirement. Describe the evidence you need and permit the relevant source families.

{
    "prompt": "Deeply research these nine customer accounts. Verify identity, current stage, employee scale, funding, recent signals, and stage-matched lookalikes. Cite every material claim and state what could not be verified.",
    "sources": ["people", "public_web"],
    "max_acu": 3.2,
    "max_output_tokens": 24000
}

Budget deliberately

The budget is a ceiling, not a target. Increase it when the task has more entities, stricter evidence gates, or a broader search space. Keep a lower ceiling for simple lookups and interactive turns.

Stream long jobs

For work that may run for minutes, request text/event-stream. The connection receives progress and keepalive frames while the agent works, then the final text, artifacts, usage, and optional structured result.

Design graceful uncertainty

A reliable deep-research result should be allowed to say:

• a signal is current but no dated event was found;
• stage is inferred from several indicators rather than confirmed;
• a POC changed companies;
• a candidate failed the evidence gate;
• a field is unknown and should remain null.