Codex Deep Research

Codex Deep Research

Use this skill when the user is asking for research rather than a normal answer. Typical triggers include:

• comparisons, evaluations, and recommendations
• market scans, competitive analysis, and landscape research
• questions where current information materially affects the answer
• requests that need citations, trade-offs, risks, or explicit source quality

Do not force the full workflow onto simple factual questions. First decide whether the task truly needs deep research.

Quick start

1. Rewrite the request into a compact internal research brief. 2. Browse early and prefer current, verifiable sources. 3. Stay single-agent unless there is a real quality benefit to parallel work. 4. If complexity is high, delegate distinct sub-questions to a small number of sub-agents using the sub-agent template. 5. Deliver a complete research report in the current conversation unless the user explicitly asks for a shorter format. 6. Only save files when the user asks or the result is clearly worth preserving after the in-session report is complete.

Workflow

1. Detect research mode

Enter deep-research mode when one or more of these are true:

• the answer depends on up-to-date information
• the user is making a decision with meaningful downside risk
• the task needs multiple sources or source comparison
• the user wants a recommendation, ranking, comparison, or market view
• the expected output should include citations, trade-offs, or explicit uncertainty

If the request is too vague to research responsibly, ask one minimal clarifying question instead of starting a large search.

2. Build an internal brief

Use assets/brief-template.md as the default structure. Keep the brief internal unless sharing it would help the user.

Capture at least:

• the exact research question
• the user's likely decision or goal
• what is in scope and out of scope
• time sensitivity
• the evaluation dimensions that matter most
• the expected deliverable style

3. Browse by default

For research tasks, browse first instead of relying on memory. Prefer official and primary sources, then high-quality reporting. Use references/source-quality.md and references/citation-rules.md when judging evidence.

For time-sensitive topics, use absolute dates in the final answer.

4. Decide whether to use multi-agent work

Start single-agent by default. Upgrade to multi-agent only when it clearly improves coverage or speed.

Only escalate when one or more of these are true:

• the task contains distinct sub-questions that can be researched independently
• the source space is broad enough that parallel coverage will materially improve quality
• the report would benefit from role separation such as official-source review, market scan, and risk review
• the user is making a decision where missing counter-evidence would be costly

Avoid escalation when the task is small, narrow, or already well-covered by a single search path.

When delegating, default to assets/subagent-task-template.md. Unless the task is extremely simple, give each sub-agent:

• one narrow question
• an explicit scope and out-of-scope boundary
• a source-priority instruction
• a concise return format

The main agent owns final judgment and synthesis.

5. Synthesize carefully

Never concatenate search results or sub-agent outputs. Merge them into one coherent report. Always:

• deduplicate overlapping evidence
• surface source conflicts
• explain uncertainty where evidence is thin
• keep facts separate from inferences
• keep recommendations tied to the user's goals

For the full staged process, see references/workflow.md.

Output contract

Default to a real research report in the conversation, not a short generic answer and not a summary that points the real content to a file. Use assets/report-template.md unless the user explicitly asks for a different format.

The final answer should usually include:

• conclusion summary
• research question and scope
• method and source strategy
• key findings
• evidence and citations
• risks and unknowns
• recommendation
• next steps

Keep these categories explicit:

• facts: directly supported by sources
• inferences: reasoned conclusions drawn from those facts
• recommendations: suggested actions based on the user's goals

If the user explicitly asks for a short report, compress the answer but keep citations and evidence boundaries intact.

Do not treat a saved file as the primary deliverable unless the user explicitly asked for file output.

Persistence

Do not save files by default. Complete the in-session research delivery first. Persist only when:

• the user asks to save the output
• the result is clearly reusable
• the task benefits from an auditable artifact trail

Do not save files merely because auditability could be helpful. When saving is appropriate, follow repository conventions instead of inventing new ones.

Completion check

Before finalizing, quickly verify:

• the conversation already contains the full research deliverable, not just a summary
• facts, inferences, and recommendations are kept distinct
• multi-agent work was used only if it materially improved coverage
• no files were written by default

Reference map

• references/workflow.md: staged research flow, escalation, synthesis
• references/source-quality.md: source hierarchy and evidence handling
• references/citation-rules.md: citation visibility and date rules
• assets/brief-template.md: internal research brief scaffold
• assets/report-template.md: default report scaffold
• assets/subagent-task-template.md: delegation scaffold

Internal Research Brief

Use this brief internally before broad research.

Research Question

State the exact question to answer.

User Goal

State the likely decision, action, or understanding the user is trying to reach.

Time Sensitivity

State whether current information is critical and what date range matters.

Scope

List what is in scope.

Exclusions

List what is out of scope to prevent drift.

Evaluation Dimensions

List the dimensions that should drive the analysis.

Research Shape

State:

• why this requires deep research instead of a normal answer
• whether current information is likely to change the conclusion
• whether multi-agent work is likely to help

Deliverable

State the expected output shape, such as a full report, a comparison, or a shorter brief.

Conclusion Summary

Give the main answer first, but do not stop at the conclusion. This report should stand on its own in the conversation unless the user explicitly asked for a brief answer.

Research Question and Scope

State the question, what was covered, and what was excluded.

Method and Source Strategy

Explain how the research was done and what source types carried the most weight.

Key Findings

Facts

Present the strongest directly supported findings first.

Inferences

Explain the conclusions drawn from those facts.

Evidence and Citations

Show the strongest supporting evidence with visible citations.

Risks and Unknowns

Call out uncertainty, missing information, edge cases, and counterpoints.

Recommendation

Recommend a next action or judgment tied to the user's goals. Also state when this recommendation fits well and when it would be the wrong choice.

Next Steps

List the most useful follow-up actions, checks, or decisions.

Sub-Agent Task Template

Use this when parallel research will materially improve coverage.

Question

State one narrow research question for this sub-agent.

Scope

State what this sub-agent should cover.

Out of Scope

State what this sub-agent should ignore so work does not overlap.

Source Priority

State the preferred source types for this sub-agent.

Deliverable

Ask for concise source-backed findings, not a polished final report.

Output Requirements

• include the strongest findings first
• use concise bullets
• include visible citations or links
• flag uncertainty or source conflict
• avoid repeating likely work owned by other sub-agents
• do not write a polished final recommendation for the user

Citation Rules

Research outputs must make source support visible.

Core rules

• Important external claims should have visible citations.
• Prefer linking the strongest source directly rather than citing a weaker intermediary.
• If a claim depends on recent information, include an absolute date when useful.
• If evidence is limited or mixed, say that in the prose instead of implying certainty.
• The primary research deliverable should appear in the conversation itself; file output is optional and should not replace a complete cited answer.

Recommended style

Use concise inline citations or source links near the claim they support. The final answer should let the reader see:

• what was observed
• where it came from
• how current it is when that matters

Date handling

For time-sensitive work:

• avoid relying only on relative phrases like "today" or "recently"
• mention exact dates when the user could be confused by time context
• prefer the date of the source or event over the date you found it

Evidence boundaries

Keep these categories distinct:

• fact: directly supported by cited evidence
• inference: your interpretation built from evidence
• recommendation: your advice based on the user's goals and constraints

Do not let recommendations masquerade as facts.

Source Quality

Prefer verifiable sources over convenience.

Source priority

1. Official documentation, product pages, standards, company announcements, filings, direct datasets 2. High-quality reporting, institutional research, reputable industry analysis 3. Secondary summaries that add context but should not carry the main argument alone 4. Community discussions, forum posts, and social commentary used only for color, examples, or weak signals

Working rules

• Anchor important claims in the highest-quality source available.
• Use multiple sources when the decision is meaningful or the topic is changing quickly.
• Treat marketing copy as useful but biased.
• Treat vendor comparison pages as evidence of positioning, not neutral truth.
• Use community reports carefully; they can reveal practical issues, but they often need confirmation.

When weaker sources are acceptable

Weaker sources can still be useful when:

• there is no stronger public source
• they are used to surface an idea for later verification
• they illustrate user sentiment or operational friction rather than hard facts

If the evidence base is weak, say so explicitly.

Handling conflicts

When sources disagree:

• do not hide the disagreement
• identify which claim is newer, more direct, or more authoritative
• explain why one interpretation seems stronger
• keep uncertainty visible if the conflict is unresolved
• if multiple sub-agents report back, merge by source strength and recency rather than by which sub-agent sounded most confident

Research hygiene

• Prefer current material for fast-moving topics.
• Check absolute publication or update dates when recency matters.
• Beware of copied summaries that all trace back to one weak source.
• Separate direct evidence from your interpretation of that evidence.

Workflow

Use this staged process for deep-research tasks.

Default execution order

1. Classify the request. 2. Rewrite the internal brief. 3. Run a light web sweep. 4. Decide whether multi-agent work is justified. 5. If needed, delegate with the sub-agent template. 6. Synthesize and deliver the full report in the current conversation. 7. Only then decide whether persistence is worth doing.

1. Classify the request

Confirm the task is actually research-shaped:

• multiple sources likely needed
• current information matters
• the user wants a recommendation, comparison, or evidence-backed judgment
• the downside of missing an important fact is non-trivial

If the request is too vague, ask one narrow clarifying question before starting broad research.

2. Rewrite the brief

Create a compact internal brief using ../assets/brief-template.md.

The goal is not to restate the user request in fancy language. The goal is to make the research executable:

• what exact question is being answered
• why the user cares
• what is in and out of scope
• what dimensions matter
• what kind of output will best help the user

3. Run an initial web sweep

Do a quick first pass before deciding whether to spawn sub-agents. This pass should:

• identify the main entities, products, or topics involved
• find the strongest likely source types
• reveal obvious time sensitivity
• surface whether the space is broad or narrow

The initial sweep is for orientation, not for writing the final report.

4. Check complexity

Stay single-agent when:

• the task is narrow
• one strong search path gives sufficient coverage
• the decision surface is simple

Escalate to multi-agent when:

• the work naturally decomposes into independent sub-questions
• parallel search will reduce the risk of blind spots
• the task includes both factual collection and interpretive evaluation
• the stakes justify stronger coverage

Prefer two to four sub-agents. More than that often increases duplication and coordination cost.

5. Delegate cleanly

Use ../assets/subagent-task-template.md when delegating.

Good role splits:

• primary and official sources
• recent developments and time-sensitive changes
• alternatives and competitor comparison
• risks, edge cases, and counter-evidence

Each sub-agent should own one clearly bounded question and return concise, source-backed findings rather than a full final answer. Do not send sub-agents off with open-ended "research this whole topic" requests when the main task can be decomposed more cleanly.

6. Synthesize

The main agent owns final synthesis. It should:

• compare overlapping findings
• remove duplication
• spot contradictions
• explain which evidence is strongest
• carry uncertainty forward honestly
• turn raw evidence into user-relevant conclusions

Never outsource final judgment to the sub-agents.

7. Write the report

Use ../assets/report-template.md as the default shape.

The report should feel like research:

• explain what was investigated
• show how conclusions were reached
• expose the evidence base
• note the main risks and unknowns
• end with a practical recommendation or next step when appropriate

Unless the user explicitly asks for a shorter answer, the full report should appear directly in the conversation. Do not collapse the session output into a summary while moving the real deliverable into a file.

8. Decide whether to persist

Default to in-session delivery. Save artifacts only if:

• the user asks
• the output is worth reusing
• auditability matters for follow-on work

Run-completion checklist

Before finishing, verify:

• the current conversation already contains the full research answer
• facts, inferences, and recommendations are distinguishable
• multi-agent work was justified rather than decorative
• persistence was avoided unless genuinely needed