Deep Research

Deep Research

Create high-fidelity research reports with strict format control, evidence mapping, source governance, and multi-pass synthesis.

Architecture: Lead Agent + Subagents

Lead Agent (coordinator — minimizes raw search context)
  |
  P0: Environment + source policy setup
  |
  P1: Question and claim map (decision questions, evidence routes, stop rules)
  |
  Dispatch ──→ Subagent A ──→ writes task-a.md ──┐
           ──→ Subagent B ──→ writes task-b.md ──┤ (parallel)
           ──→ Subagent C ──→ writes task-c.md ──┘
  |                                               |
  |     research-notes/  <────────────────────────┘
  |
  P2: Build evidence packets + citation registry
  P3: Evidence-mapped outline with counter-evidence and unknowns
  P4: Draft from evidence packets; reopen decisive originals
  P5: Counter-review (claims, confidence, alternatives)
  P6: Verify every load-bearing claim and exact fact
  P7: Polish → final report with confidence markers

Context discipline: Keep raw search-result noise in task workspaces. Pass evidence packets to the lead agent, including locators and short source excerpts. Notes are routing aids, not authorities: the lead agent must open the original source for every load-bearing claim, conflicting claim, and exact figure/date/quotation used in the report.

Run and asset contract — every invocation

Before external retrieval, read research-asset-contract.md. Create or resume a durable project study for single-route and multi-route research alike. Search its explicit prior-study catalog, open relevant earlier originals and record reuse/adapt/reject decisions. Draft the decision questions and provider × actual-mode lanes in study.json. Write one exact dispatch_context with the user-supplied seed URL, named entities, and verified codes or other identifiers needed for the query. Include that string in every lane prompt; research_assets.py start rejects an omission. Capture the user's named seed article or document as an original before external dispatch, and follow the provider handoff when a provider cannot read its URL. A model workspace may not see the user's link or local files just because the coordinator does. Then run provider_runs.py plan. Keep every user-requested mode in the plan; a route that adds no value, is unavailable or lacks paid authorization gets a reasoned deferred event. A report assembled from direct web search and internal subagents still needs a direct-source lane and the same archive.

New studies use schema 2's request mode contract: archive the original request and accepted workflow, interpret the required modes independently of the execution lanes, and map each to matching lanes. An explicit empty mode inventory is valid when none was requested; a missing contract is not. plan rejects an omitted or mismatched mapped route. Review the inventory against the original: fields and hashes cannot prove semantic completeness. Schema-1 archives remain readable with request coverage unknown; do not restart old tasks to fill that gap.

Before collecting provider reports, load report-file-collection.md. Use available file/download channels instead of the clipboard. Schema-2 submission and historical import require an unchanged actual-mode observation receipt; prepared prompts do not. A deferred route stays visible with its reason. An uncertain result or legacy request coverage requires explicit --bounded-reason at final check/registration and is catalogued as bounded, not fully completed.

During research, retain the unedited provider outputs, every opened original and every provider-surfaced source URL with status and provenance. Bind report claims to approved original sources; model reports only locate candidate evidence. Before calling a report complete, run provider_runs.py validate, research_assets.py check, and register the study for later discovery. An answer with citations but no study/source/claim record does not satisfy this Skill. The local scripts record and check files; they make no provider calls and do not authorize paid work.

Before sending a Work/Agent task that may choose its own data plugins, inspect the relevant plugin catalog for per-call credits or charges. A signed-in account and a request to use a data source do not set an unlimited spend ceiling. If an autonomous task can invoke metered plugins without a per-call pause and this task has no explicit spend authorization for them, defer that lane or use a route where the exact calls can be approved first. Even with a budget, a prompt is not a technical charge limit: use a controllable route when the autonomous task cannot enforce it. State authorized limits in the provider prompt for traceability, then read the raw tool log after execution; if a charge occurs despite the boundary, record the observed usage and tell the user. Do not make another paid call to fill a coverage gap.

Mode Selection

Determine the research mode before starting:

• Enterprise Research Mode: Question-led company research with optional analysis frameworks selected only when they help answer the decision
• General Research Mode: Standard P0-P7 research pipeline with source governance
• Depth Selection: Choose from the number and consequence of unresolved questions, not prompt length, task count, or a target word count
• Provider Selection: Read the user's established workflow when they say “our way” or invoke a named research routine. Extra model reports are useful when they add a distinct evidence route, structured tool access, or a meaningful challenge. Check each provider's availability, privacy boundary and paid authorization; do not silently reduce a requested mode set to a direct-source report. Never run every available route by default or hardcode a vendor roster.

Source Governance (V6)

Source Accessibility Classification

Classify every source by accessibility:

First-party boundary: User-authorized records may establish what the organization did, agreed, paid, delivered, or observed. They do not count as independent external validation of market standing, customer sentiment, regulatory compliance, or third-party claims. Never relabel an internal record as an external finding.

✅ EXCLUSIVE INFORMATION ADVANTAGE: You SHOULD:

• Use user's Crunchbase Pro to research competitors
• Use user's proprietary databases for market research
• Use user's private APIs for investment analysis
• Leverage any exclusive source user provides for third-party research

Source Type Labels

Every source MUST also be tagged with:

Coverage diagnostics: Track source counts, domains, source-type mix, and concentration to reveal thin coverage. Never pass or fail research from these totals alone. Gate on whether each decision question and load-bearing claim has fit-for-purpose evidence, whether counter-evidence was sought, and whether remaining unknowns are explicit.

AS_OF Date Policy

Set AS_OF date explicitly at P0. For all time-sensitive claims:

• Include source publication date with every citation
• Downgrade confidence if source is older than relevant horizon
• Define a freshness horizon per claim class and flag material outside it; a universal age cutoff is only a diagnostic

P0: Environment & Policy Setup

Check capabilities before starting:

Set policy variables:

• AS_OF: Today's date (YYYY-MM-DD) - mandatory for timed topics
• MODE: Standard (default) or Lightweight, justified by the question map
• SOURCE_TYPE_POLICY: Enforce official/academic/secondary/journalism/community/other labels
• COUNTER_REVIEW_PLAN: What evidence would overturn each provisional conclusion

Before setting provider mode, run the research asset catalog search. An earlier model summary is a lead; reopen its source and check freshness before reuse.

Report: [P0 complete] Subagent: {yes/no}. Mode: {standard/lightweight}. AS_OF: {YYYY-MM-DD}.

When researching a specific company, use the specialized workflow to route evidence by question. Treat the six dimensions as a coverage map, not a mandatory report outline.

Enterprise Workflow Overview

Enterprise Research Progress:
- [ ] E1: Intake — confirm company entity, research depth, format contract
- [ ] E2: Question-led evidence collection across relevant dimensions
  - [ ] D1: Company fundamentals (entity, founding, funding, ownership)
  - [ ] D2: Business & products (segments, products, revenue structure)
  - [ ] D3: Competitive position (industry rank, competitors, barriers)
  - [ ] D4: Financial & operations (3-year financials, efficiency metrics)
  - [ ] D5: Recent developments (6-month events, strategic signals)
  - [ ] D6: Internal/proprietary sources (or note limitation)
- [ ] E3: Optional analysis framework selected for the decision (or none)
- [ ] E4: Claim/evidence/unknown checks at each stage transition
- [ ] E5: Draft in the user's requested structure
- [ ] E6: Multi-pass drafting + UNION merge (same as general Step 6-7)
- [ ] E7: Present draft for human review and iterate

P1: Research Task Board

For every study, use the portable provider-run contract: one question map, exact prompts, and a distinct lane_id per provider × actual mode, including a direct original-source route when used. Run provider_runs.py plan before dispatch. When two or more provider/mode lanes are selected, load parallel-provider-ops.md before fan-out and coordinate the available provider, browser/app, retrieval and verification Skills with independent agents. Assign one owner per control surface and serialize that owner's UI actions. Do not implement provider calls inside this Skill or assume a fixed vendor roster. Submit long asynchronous jobs early and collect each original result under its own lane; resume active tasks by their existing origin instead of starting duplicate paid work. Resolve and read each lane's current executor Skill before actual dispatch, following its authorization rules; the local planner makes no provider calls. A provider's report is an input to P3, not an independently verified source. Do not infer that normal chat used native Deep Research from model name or report length; verify the actual UI or API route. Synthesize by underlying original source and decision value, never by a vote of model reports.

Decompose the assignment into decision questions. Create tasks only where separate evidence routes or expertise make the work clearer.

Each task assignment includes:

• Expert Role: Specialist persona (e.g., "Policy Historian", "Ecosystem Mapper")
• Objective: One-sentence investigation goal
• Queries: 2-3 pre-planned search queries
• Depth: DEEP (fetch 2-3 full articles) or SCAN (snippets sufficient)
• Output: Path to research notes file
• Parallel Group: Group A (independent) or Group B (depends on Group A)
• Decision Question: The exact question this task helps answer
• Load-Bearing Claims: Provisional claims that would change the conclusion
• Disconfirming Evidence: What would weaken or overturn each claim
• Evidence Route: Which source owners or record systems can actually observe the fact
• Stop Rule: What counts as answered, contradicted, or still unknown

Task Decomposition Rules

1. Each task covers one coherent sub-topic a specialist would own
2. Group A tasks must be logically independent; source independence is assessed by underlying evidence, ownership, and incentive, not domain count
3. Max 3 tasks per parallel group (concurrency limit)
4. Every task must flag time-sensitive claims, counter-evidence sought, and expected citation aging risk

Enterprise Research Integration

When in Enterprise Research Mode, map questions to the relevant dimensions rather than creating all six tasks automatically:

• Task A: Company fundamentals (entity, founding, funding, ownership)
• Task B: Business & products (segments, products, revenue structure)
• Task C: Competitive position (industry rank, competitors, barriers)
• Task D: Financial & operations (3-year financials, efficiency metrics)
• Task E: Recent developments (6-month events, strategic signals)
• Task F: Authorized first-party records (when they can answer a business fact; never counted as external corroboration)

Report: [P1 complete] {N} tasks in {M} groups. Dispatching Group A.

Enterprise Research Mode (Specialized Pipeline)

When researching a specific company, route each decision question through the relevant enterprise dimensions. Use the dimensions to find missing evidence paths; do not run all six or add quantified frameworks by default.

E1: Intake

Same as P0/P1 above, plus:

• Confirm the exact legal entity being researched (parent vs subsidiary)
• Select research depth from the decision questions, evidence difficulty, and requested output; page counts are planning diagnostics only
• Identify any specific comparison targets (benchmark companies)

P2: Dispatch + Investigate

Subagents execute tasks using references/subagent_prompt.md and output evidence packets in references/research_notes_format.md.

With Subagents (Claude Code / Cowork / DeerFlow)

1. Dispatch Group A tasks in parallel (max 3 concurrent)
2. Each subagent searches, fetches, and tags source types
3. Every source line includes Source-Type and As Of
4. Wait for Group A completion
5. Dispatch Group B (can read Group A notes)

Subagent Output Requirements

Each task-{id}.md must contain:

• Question status: answered / contradicted / unknown, with the stopping evidence
• Sources section: stable locators from actual retrievals with source type, accessibility, date, and source-family identity
• Claim-evidence table: claim, evidence excerpt/locator, scope, confidence, and whether the original was opened
• Counter-evidence and unknowns: what was sought, what was found, and what remains unresolved

Without Subagents (Degraded Mode)

Lead agent executes tasks sequentially, acting as each specialist. Preserve raw search noise outside the final evidence packet; retain a query log when reproducibility matters.

Enterprise Research: Six-Dimension Collection

Follow references/enterprise_research_methodology.md for:

• Detailed collection workflow per dimension (query strategies, data fields, validation)
• Data source priority matrix (P0-P3 ranking)
• Claim-specific corroboration and conflict-handling rules

Key principles:

• Evidence-driven: every conclusion must trace to a citable source
• Corroboration: a second source adds weight only when it is independent of the same underlying disclosure or dataset
• Restrained judgment: mark speculation explicitly, avoid unsubstantiated claims
• Structured presentation: complex information via tables, lists, hierarchies

Run L1 quality check after completing each dimension (see enterprise_quality_checklist.md).

Status per task: [P2 task-{id} complete] {N} sources, {M} findings. Status all: [P2 complete] {N} tasks done, {M} total sources. Building registry.

E3: Select Analysis Frameworks Only When Useful

Load references/enterprise_analysis_frameworks.md only when the user's decision benefits from a framework. Use SWOT for strategic option framing, a risk matrix for decisions with explicit probability/impact inputs, and scoring only when weights and scales are defensible. Omit the framework rather than fabricate entries or precision.

Run L2 quality check after analysis is complete.

E4: Quality Control

Three-level checks from references/enterprise_quality_checklist.md:

• L1 (Data): Source count, attribution, cross-validation, timeliness
• L2 (Analysis): Decision-question coverage, claim support, counter-evidence, and framework fitness when a framework is used
• L3 (Document): Structure compliance, format consistency, readability, appendices