The Anatomy of a Research Prompt.

I wrote a research prompt recently that I keep coming back to. It asks Claude to prove or disprove a go-to-market strategy, and nearly each line maps to something we teach in our client trainings. Here it is, with the strategy redacted, and why each part is there.

The prompt

/goal I'd like you to try to prove or disprove the [REDACTED] strategy found here: [REDACTED]

Deeply research at least 5 companies in each channel, maximum of 10 in each. Please store your methodology for searching companies in a search methodology MD file with a decision log section that identifies where you tried something and decided to adjust the approach so that we can learn from the iterations in the future without repeating the exercise.

Please use subagents with the appropriate model for the task to optimize clean context windows, latency, and cost of the job, but don't over-optimize at the expense of quality.

Please cite your references and then, for each company, deploy a clean sub-agent to evaluate each company's references for accuracy.

Create a folder for each company you choose and save the evaluation, the reason it was chosen, and evidence of the cited references from the evaluation.

It asks a question that can come back no

"Prove or disprove" gives the model permission to tell me I'm wrong. Without it, I'm asking a tool that wants to please me to go find support for something I already believe.

We spend real time on this in trainings. A model working a long task is trying to answer the last thing you asked, and when it runs low on context it fills the gap with something that sounds right. Ask it to prove a strategy and it will find you proof. Ask it to prove or disprove, and a weak channel has somewhere to land.

It sets a floor and a ceiling

At least 5 companies per channel, no more than 10. The floor keeps it from calling a strategy proven off two good examples. The ceiling keeps it from reading 40 companies, burning tokens, and handing me a pile I won't review.

It also tells the model when it's done. In training we say that if you don't describe what good looks like, the model makes it up. A range is the simplest version of that.

It writes down the dead ends

The methodology file is markdown on purpose. Markdown is the model's version of a Word doc: same content, none of the formatting overhead, so it takes a fraction of the context window. One of our transcript jobs cost $30 a day. Converting each transcript to markdown before processing dropped it to $3, with the same output.

The decision log is the part I care about most. Research write-ups usually show the path that worked. I want the turns it took and why: the search that returned junk, the source it stopped trusting, the filter it added halfway through. We run our own operating context the same way. Settled knowledge lives in one file, and a change log records what moved and why. The next person to run this starts from the log and skips the dead ends.

It splits the work and picks the model per job

Each turn in a chat resends the whole conversation. As it grows, the model holds on to the beginning and the end and starts dropping the middle, and that's where hallucinations hide. I learned this on my own AI daily brief. It was reading about 40 sources in one session, and one morning I clicked a link that didn't exist. Too much work in one context window. The fix was splitting it into subagents, each with a small, clean job.

Up to 10 companies per channel in a single session would hit the same wall. Subagents give each company its own context window.

The model line is about cost and speed. Searching and pulling pages is lighter work than judging whether a source supports a claim, so they don't need the same model. "Don't over-optimize" is in there on purpose, though. In our trainings we tell people to run the bigger model and not worry about tokens yet. A cheap run that gets the answer wrong costs more than it saved.

Cite your sources, then check with a clean subagent

We call these the magic words in our trainings, and we repeat "clean subagent" until people are tired of hearing it.

If you tell Claude to check its work in the same chat, it re-reads all the context that led to the mistake. It's like asking your junior analyst to check their own spreadsheet. A clean subagent is a second analyst. It gets the claims and the sources, nothing else, and starts fresh.

Citations are what make the check possible. With a source on each claim, the subagent can open the link and confirm the page says what the claim says. If it can't find the source, you've found your hallucination. After the broken-link morning, my daily brief now has a clean subagent click each link and confirm the title and summary match.

One per company isn't cheap, and we don't put a clean subagent on everything. We use them when the answer has to be right. A strategy call qualifies.

One folder per company

Folders are how we scope context. When you're working for one client, you don't want another client's details leaking into the answer, so the work happens in that client's folder and nowhere else. The same rule keeps company A's evidence out of company B's evaluation.

The folders are also the audit trail. Each one holds why the company was picked, what the checker found, and the evidence behind it. Our agentic coding pipeline works the same way: each agent writes its output to a shared specs folder, and a separate judge grades it before the next step runs. When someone asks why a company is in the set, I can open the folder and show them.

What I'd add next time

A definition of proof. The prompt says prove or disprove but never says what evidence counts, so the model sets its own bar. The next version gets a line spelling out when a channel counts as proven, like a minimum share of companies showing the same result, measured the same way.

A script for any scoring math. When the model does math, it's doing math in its head. Python is the calculator. If I'm comparing channels, the numbers should come out the same on every run.