Enterprise deep research: requirements to settle before you buy

A deep research tool takes a question, runs many searches, reads many pages and returns a long report full of citations. In a demo, the report is the impressive part. Inside a company, the report is the least of it. What matters is where the question went, which sources were allowed to answer, whether a reviewer can check every claim, who approved the run, what it cost, and whether anyone can reconstruct all of that six weeks later. This guide sets out those requirements, describes what good looks like for each, and ends with questions you can put to any vendor, including the one you already use.

A different purchase from a personal research tool

An individual using a research assistant accepts the defaults. An organization cannot, because research questions carry context: the name of a target company, an unreleased product, a patient population, a pending legal matter. The question is sensitive before any answer exists. The output travels too. It lands in an investment memo, a regulatory submission or a board deck, where an unsupported sentence becomes the company's sentence.

That moves the centre of the evaluation. Answer quality still matters, and you should test it on your own questions; the general guide to choosing a deep research API covers that side. An enterprise selection, though, is mostly about controls. Tools on the market fall into three broad groups: model providers that expose a research mode through their API, search providers that built a research endpoint on top of their own index, and workspaces where research is one governed task among several. The same questions apply to all three. If you are still deciding whether to buy at all, read build a research agent or buy deep research first.

Data boundaries: where the question and the report travel

Trace one research run from end to end and write down every place the data goes. The question leaves your network and reaches the vendor. The vendor derives search queries from it, often sending them to third-party engines. It fetches pages, so the target sites see requests. It may store the question, its intermediate notes and the final report.

For each hop, establish:

• Retention. How long are questions, notes and reports kept, and can you shorten that or have them deleted on request?
• Training use. Are your questions or outputs used to improve the vendor's models or services, and is the default on or off?
• Subprocessors. Which third parties see the derived queries? A query the agent rewrote can still contain the name you meant to keep private.
• Isolation. Is one team's work separated from another's, and one customer's from the next? Can a project boundary inside your organization be enforced rather than merely labelled?
• Location. Where is the work processed and stored, and does that match your contractual obligations?

Get these answers in writing and in the contract, not on a sales call. Your security team will have its own checklist; these are the research-specific items it tends to miss.

Source control: deciding what may answer

Open-web research treats every page that ranks as a candidate source. That is rarely what a regulated team wants. A pharmacovigilance question should draw on regulators, registries and peer-reviewed literature rather than forum posts; a credit analyst may want filings and the company's own disclosures ahead of commentary. Good tools let you say so before the run starts.

• Allowlists and blocklists by domain or source type, set per project or per question, not only globally.
• Internal documents as sources, cited the same way as web pages and visible only to people entitled to see them.
• Behaviour when the allowed sources are silent. The tool should report the gap instead of quietly widening the search to sources you excluded.
• Licensing. Who is responsible for paywalled or licensed material, and does the tool respect logins rather than working around them?

A practical test: run a question whose answer exists only on a source you excluded. The correct result is an honest statement that the allowed sources did not answer it. The note on deciding which sources may answer a question goes further.

Citations a reviewer can actually check

A footnote is not evidence. A long report with dozens of numbered links can still contain claims no linked page supports, links to pages that say something else, and links that were generated rather than retrieved. The reviewer's job is to check meaning, and the tool should make that job short.

Ask for citations at passage level: the claim, the quoted passage that supports it, the page address and the date it was retrieved. Ask whether the tool keeps supported findings apart from questions it could not answer, or blends both into confident prose. Then test it. Take ten claims from a sample report, open every cited page and mark each claim supported, partly supported or unsupported. Repeat on several reports, because one good report proves little. A sample acceptance criterion for the pilot: every factual claim in the summary links to a quoted passage, and every sub-question left unanswered is listed as open.

Approval and audit

Deep research looks read-only, but a run can do more than read. It may sign in to a data provider, export a dataset, schedule a recurring run, call another agent or send the result to a distribution list. Each of those deserves a decision by a named person before it happens. One pattern works well: approve the plan itself. The question, the steps and the permitted sources are reviewed before execution, and the run cannot drift beyond what was approved. If the question changes halfway, a new plan is drafted rather than the old one stretched.

Later, someone will ask how a conclusion was reached. The audit trail should let them replay it: the original request, every search and fetch, the sources read, each decision and who made it, and the final output. Ask whether your reviewers can read that trail inside the product, or only export raw logs for an engineer to interpret. The note on what an agent audit trail should record lists the fields worth insisting on.

Cost and time bounds

A deep research run decides for itself how many searches and page reads it needs, which makes cost hard to predict. Enterprise use needs bounds that actually hold: a per-run limit on wall time and tool calls, a spending cap per day or per team, and a defined behaviour when a limit is hit. The right behaviour is to stop and say so, returning what was found and what remains open. The wrong one is to keep going and bill afterwards, or to produce a confident report from half the evidence without flagging that it is partial.

Price the unit that matters: a completed, reviewed research task, not a single call. A cheap run that takes an analyst an afternoon to verify is not cheap. See put a ceiling on agent spend for how to set those limits.

Where GoCux fits

GoCux is a company workspace in which agents do research under rules your team sets. It does not read the open web by itself: web material arrives through an authorized browsing or export step and keeps its original page address and retrieval date. A research plan states the question, the ordered steps and a source allowlist. Creating the plan only records a draft; a person approves it before it runs, and execution cannot reach past it. An allowlist left empty permits no source at all. Findings backed by a quotation are stored apart from questions no source answered.

Each piece of work runs as a work order with a scope, acceptance criteria and bounds on wall time and tool calls, and it waits in an awaiting-decision state before consequential actions such as sending something out, exporting data, scheduling work or putting another agent to work. Work, memory, files and credentials stay within the company boundary. Credits are spent under a daily cap, and at the ceiling work stops and says why. Requests, decisions, tool runs and outcomes form one trail your reviewers can read in the workspace; the governance page has the details. Run your own security review, as you would for any vendor.

Questions to ask any vendor

1. Where are questions, intermediate notes and reports stored, for how long, and can we have them deleted?
2. Are our questions or outputs used for training or service improvement, and what is the default?
3. Which third parties receive queries derived from our questions?
4. Can we restrict sources per project, and what happens when the allowed sources have no answer?
5. Can internal documents serve as sources, and who can see them?
6. Does every claim link to a quoted passage with a retrieval date?
7. Are unanswered questions reported separately from findings?
8. Which actions beyond reading can a run take, and which of them pause for a person?
9. Can we approve a plan before it runs, and can execution go beyond it?
10. Can our reviewers read the full trail of a run without engineering help?
11. What bounds exist per run and per day, and what happens at the limit?
12. When a dependency is unavailable, does the tool say so, or return a thinner report as if it were complete?

Then run a short pilot on past questions whose answers you already know, write the acceptance criterion in advance and check the citations by hand. If the vendor's written answers and the behaviour you see in the pilot disagree, trust what you saw.