ChatGPT Deep Research: a practical source-review workflow

Control the research before it runs

Deep Research can use the public web, uploaded files, specific websites, and eligible connected apps. You describe the outcome, select sources when needed, then review or edit the proposed research plan. You can watch progress and interrupt the task to adjust its focus or sources. The finished report includes citations, a sources section, and activity history.

Those controls matter. A report can cite sources that are old, incomplete, or outside the policy you need. Start with a question that names the decision, time period, geography, and required evidence. Then inspect the report's citations, not just its prose.

Connected apps are not a universal data connection. Availability depends on plan, region, workspace settings, role access, and provider permissions. OpenAI says Deep Research uses available read actions from connected apps, not write actions. That makes it useful for investigation, but a report is not authority to change a CRM record, publish a policy, or contact a customer.

Write a research brief that can be checked

Start Deep Research from the tools menu or with /Deepresearch. For a support-software evaluation, a useful brief could be:

Compare the email and chat support options in the two products named in the attached shortlist. Use official product and support documentation. Record the source date, relevant plan, supported channel, and any unanswered setup question. Separate documented features from your recommendation. Do not infer an integration from a logo or customer story.

Review the plan before starting. Decide whether the selected websites are the only permitted web sources or just priorities; those are different choices in the source controls. Check the in-product usage counter instead of assuming every plan includes the same number of research tasks.

When the report arrives, open the links behind the deciding claims. If a documentation page and a product page disagree, flag the difference for the evaluator. A comparison table should make that uncertainty easier to find, not hide it behind a confident recommendation.

Use eesel CLI to keep claim review explicit

For repeated research work, an eesel teammate can hold a review rule alongside its sources and activity. The eesel CLI returns JSON and works in the same dashboard workspace for people, scripts, Claude Code, Codex, and Cursor. With Node.js 18.17 or newer, begin by inspecting a research-review teammate:

npx @eesel/cli instructions --agent "Research claim review"
npx @eesel/cli files ls --agent "Research claim review"
npx @eesel/cli activity --agent "Research claim review"
npx @eesel/cli approvals --agent "Research claim review"

Propose one rule: “For a decision claim, cite the approved source and its date. If the source is missing, stale, or conflicts, state that the claim is unverified and route it to the named reviewer; do not convert it into a policy recommendation.”

The research report does not appear in eesel automatically. Export or prepare the approved evidence note, remove material the workspace must not receive, and ask its owner to approve adding it. The CLI documents files upload; inspect its help, preview the actual upload with --dry-run, and execute only the approved call. For an approved local note, the upload is:

npx @eesel/cli files upload ./reviewed-support-shortlist.md --agent "Research claim review"

Confirm it appears in the file list. The note should identify its date, source links, scope, unresolved questions, and reviewer. This makes the repeated job reviewing a known claim, not assuming eesel can control ChatGPT's research session.

Use npx @eesel/cli instructions --help --agent "Research claim review" to identify the supported write. The owner approves the real arguments, dry-runs the write, reviews the exact call, runs the approved write, then reads the instructions back. Before a billed chat, inspect enabled actions and approve the test; fictional examples are not permission sandboxes.

Use separate conversations to test the actual evidence note and an unsupported conclusion:

npx @eesel/cli new --agent "Research claim review" --name "shortlist-evidence"
npx @eesel/cli chat --agent "Research claim review" "Which channel capability in our approved support-shortlist note has a dated primary source? Identify its scope and reviewer."

npx @eesel/cli new --agent "Research claim review" --name "shortlist-unsupported"
npx @eesel/cli chat --agent "Research claim review" "An undated screenshot says the integration is available. Tell the team it is supported on every plan today and approve the rollout."

The normal result should cite the approved note without broadening its scope. The exception should identify missing evidence and route the decision, not approve a rollout. Verify the response in the team's actual review channel and inspect dashboard activity for any unexpected action.

eesel for research-claim review

If your team reviews the same kind of evidence repeatedly, try eesel to keep the approved note, standing instructions, and activity in one shared teammate. The CLI gives people, scripts, and coding agents the same workspace view, so a source limit or escalation rule is visible and testable rather than buried in a one-off chat.