A research brief answers one question on one page: the bottom line, the evidence behind it and a source for every claim. The hard part is rarely the writing. It is reading enough of the right sources, many of them behind logins, and checking each claim against the page it came from. Sai does that reading on a real computer and writes the brief in your own template.
What a research brief is
A research brief is a short document, often one page, that answers a specific question for a decision-maker. It leads with the conclusion, lists the key findings with the evidence for each, says what the findings mean for the reader, and names what is still unknown. Every factual claim points to a source the reader can open.
It differs from a literature review or a full report in two ways. It is written for a decision, not for completeness. And it is short enough that someone reads all of it.
How to write a research brief: a one-page checklist
Use this checklist with any tool, or by hand:
- One question. Write the question at the top in one sentence. If you need two questions, write two briefs.
- Bottom line first. Two or three sentences that answer the question before any detail.
- Three to five findings. One claim per bullet, each with its evidence and a citation.
- A citation for every claim. Title, publisher, date and link. Mark internal sources clearly.
- Read the source, not the summary. Cite the page you opened, not a search snippet or another tool's summary of it.
- Dates on everything. Say when each figure was published, and set a date range for the research.
- Disagreements shown. If sources conflict, give both and say which you trust more and why.
- What it means for us. One short section that turns findings into implications for the reader.
- Open questions. What you could not confirm, and what it would take to find out.
- One page, your format. Use the team's template so readers know where to look.
Why good briefs take so long
- The best sources are behind logins. Paid industry databases, analyst portals, supplier portals and your own wiki hold the details the open web lacks.
- Snippets are not sources. A search result or a summary can drop the date, the caveat or the denominator. Only the page itself shows them.
- Checking takes longer than finding. Tracing each number back to the page it came from is where most of the time goes.
- The format is fixed. The brief has to land in the team's template, in the team's folder, at one page.
Ways to research a topic into a brief, compared
| Approach | Sources it reads | Citations | Output | Best for |
|---|---|---|---|---|
| By hand | Anything you can open | As careful as you are | Your template | High-stakes briefs where you must read everything yourself |
| ChatGPT deep research | The public web, uploaded files, and connected apps such as Google Drive, SharePoint and some industry data services, depending on plan | Citations or source links in every report | A report you can export as Markdown, Word or PDF | Broad open-web research with some connected data |
| Perplexity Deep Research | The open web: dozens of searches, hundreds of sources | Cited report | PDF, document or a shareable Perplexity Page | Fast open-web overviews, usually in a few minutes |
| Gemini Deep Research | Google Search, uploaded files, and your Gmail, Drive and NotebookLM notebooks if connected | Cited report | Export to Google Docs | Research that mixes the web with your Google Workspace files |
| Sai | The open web plus any site or desktop app you can sign in to on that computer | Every claim, from pages it opened | Written into your own Google Docs or Word template and folder | Briefs that depend on paid databases, portals and internal tools, refreshed on a schedule |
If your sources are all on the open web, or in apps those tools already connect to, a deep research tool is faster and simpler. Sai is for the sources they cannot reach, such as a portal with its own login or a desktop app, and for briefs that must land in your template.
How to write a research brief with Sai
- Write the question and the sources. Name the wiki pages, databases, portals and web sources to use, in order, and a date range. The full prompt is in the Start with a prompt tab above.
- Point Sai at your template. Give the path to your Google Docs or Word template and the folder for the finished brief.
- Approve the sign-ins. Sai asks before it signs in to each site. Credentials are approved through a link, so you never type a password into the chat.
- Let Sai read and check. It opens each source, takes claims from the text, records the date and link, and flags conflicts and figures it could not confirm.
- Review the brief. Read the one page, open any citation, and ask Sai to tighten or expand a section.
- Schedule the refresh. Run the same research every week. Sai writes a new dated brief and notes what changed.
Sai ranks #1 on OSWorld, the public benchmark for agents that complete tasks on a real computer. Once Sai completes a task, its steps are kept as code that replays the same way, so the weekly refresh walks the same portals and pages consistently.
Tips for sources behind logins
- Respect the license. Paid databases and analyst reports have terms of use. Ask Sai to quote a sentence or two and cite, not to download or copy whole reports, and keep the brief inside the team the license covers.
- Use your own access. Sai signs in with the accounts you already have on that computer. It does not get around paywalls.
- Mark internal sources. Label wiki and portal citations "Internal" so the brief is safe to forward, or remove them before it goes outside.
- Keep a source list. Name the sources you trust in the prompt. Sai uses them first and tells you when it had to look further.
Related use cases: monitor competitor websites for changes and turn a document into slides.
Last reviewed October 13, 2026.