Research workflows with Claude Code

Doing real research — competitor audits, market scans, technical evaluations, policy reviews — is the slowest, most error-prone part of most knowledge work. Claude Code doesn’t eliminate the work. It changes the shape of it. This is the exact pattern I use when I need to understand something new in an afternoon instead of a week.

The problem this solves

If you have ever been asked “what’s the competitive landscape for X?” or “give me a quick read on this 200-page compliance document” or “figure out whether this vendor’s claims hold up,” you already know the problem. The work isn’t hard intellectually. It’s just a lot of reading, followed by a lot of summarizing, followed by a lot of writing something coherent out the other end. A good research task takes a full day. A great one takes a week. And the deadline is usually Monday.

Traditional AI chat tools help at the margins. You can paste a document into ChatGPT or Claude and ask for a summary. That’s useful, but it’s one step in a ten-step process. The bigger bottleneck is the breadth of the task — the fifty browser tabs you need to open, the ten companies you need to compare, the six reports you need to reconcile. That’s where a chat window runs out of room and a coding agent starts to shine.

Claude Code is that coding agent. It’s the same model you might be using in a chat window, but running in a different mode — one where it can open files, fetch pages from the web, run local tools, and dispatch focused subagents to chew on pieces of a problem in parallel. Those capabilities turn it from a fancy search box into something closer to a research team of one.

Why Claude Code beats a chat box for research

Three structural differences explain the whole shift.

It can read and save files

In a chat window, every answer is ephemeral. You paste something in, you get a response, and both evaporate when you close the tab. In Claude Code, the agent reads from and writes to real files on your computer. Research it gathers today is still there tomorrow. I can ask it to pull competitive intel from a dozen sources into a Markdown file, then come back a week later and ask it to update just the sections that have changed. The work compounds.

It can fetch the web

Claude Code can pull a URL, read the page, and incorporate what it found into its analysis — without me opening a browser. That sounds like a minor convenience until you realize it removes the biggest time sink in research: the context-switch between “reading the source” and “writing the summary.” The agent does both in the same breath. I describe the question, it pulls the pages, and I get a synthesized answer with the source URLs inline for verification.

It can run other agents

This is the move people miss, and it’s the whole reason research workflows go from “mildly faster” to “unrecognizably faster.” Claude Code can spawn focused subagents — little task-scoped versions of itself — and run them in parallel. Each one is responsible for one slice of the problem. One subagent reads every page of your competitor’s site. Another does the same for a second competitor. A third does web searches for recent coverage of both. While I’m pouring coffee, they’re all working. When they finish, the main agent stitches the findings together into one report.

You cannot do this in a chat window. You physically cannot have three conversations at once in ChatGPT and have them cooperate at the end. Claude Code makes that the normal way to work.

The three-part pattern

Every research session I run follows the same three-part shape.

Part 1: Frame the question

Before any searching happens, I write down what I’m actually trying to learn. Not the search query — the decision the research is supposed to inform. “I’m evaluating whether we should build or buy an X, and I need to know who the three leading vendors are, what they cost, and which one would fit a 50-person professional services firm.” That’s a frame. “Competitors to X” is not.

I feed the frame to the agent as the first message. It shapes everything that comes after. A well-framed question produces focused research. A badly framed one produces a generic dump.

Part 2: Dispatch the work in parallel

Once the frame is clear, I ask the agent to propose a research plan: which sources, which subagents, which questions each one should answer. I read the plan. If it’s missing a competitor I know about, I add it. If it’s researching the wrong metric, I correct it. Then I tell it to run the plan, and it dispatches parallel subagents to do the legwork.

This is the step where the time savings actually happen. The same research that would take me eight hours of sequential reading takes the agents about ten minutes of parallel reading. I am effectively a research manager for a team of specialists who work at the speed of the internet.

Part 3: Synthesize and verify

When the subagents report back, the main agent produces a unified output — usually a Markdown document in my second brain — that merges findings, flags contradictions, and lists sources inline. I read it. I open the sources for anything that will make it into a decision I care about. I correct anything off. Then I file it.

Verification is the step where my judgment earns its keep. The agent is fast and often right. But “often right” is not “always right,” and research that’s going into a real decision has to be spot-checked by someone who knows what good looks like. That someone is me. If I skip this step, I’m shipping the agent’s confidence instead of my own — and as Module 2 of the Foundations pillar explains, the model has no internal sensor for whether it’s making things up.

Parallel subagents: the real move

Let me linger on this because it’s the single most valuable pattern in the entire workflow.

A subagent is a focused instance of the agent, spun up with a single scoped task and its own small context window. It runs independently from the main conversation. When it finishes, it reports back. The main agent can dispatch several at once and wait for them all.

Here’s why this is so useful for research. A single agent trying to do a 40-tool competitive audit will burn through its context window and start dropping details. A coordinator agent that dispatches 40 small subagents — each responsible for one tool — doesn’t have that problem. Each subagent only has to understand one tool. The coordinator only has to synthesize 40 short summaries, not 40 long pages. The whole thing stays fast and focused.

The rule of thumb I use: if you can describe the research as “do X for each of Y things,” it’s a parallel subagent job. Reviewing a list of documents. Summarizing a set of competitors. Checking a dozen pages for a specific claim. Any task shaped like “repeat this analysis N times” is a job for parallel subagents, not one long linear chat.

A real example: auditing 40 AI tools

Here’s a research job I actually ran. I was evaluating the market for cross-platform content-aggregation tools — things that scrape TikTok, X, YouTube, and summarize what matters. I wanted to know if anything in that space was under $20 a month, whether any of them actually worked, and where the market gaps were.

A week-long version of that task looks like: open forty browser tabs, read forty landing pages, cross-reference twenty reviews, write a comparison table, draft a competitive memo.

The version I actually ran looks like this. I framed the question: “I want to build a personal TikTok and X digest. Before I build, I need to know if it already exists, under $20 a month, for non-technical users. Audit the landscape and tell me if there’s a gap.” Claude Code proposed a research plan: dispatch parallel subagents against named categories (aggregators, summarizers, scraping APIs, browser extensions), have each one surface tools, pricing, and capability, and consolidate findings into a Markdown note in my vault.

I approved the plan. The subagents ran. Ten minutes later I had a structured document in my second brain covering forty tools across seven categories, with pricing, a capability matrix, and the agent’s own conclusion about where the gaps were. I read it, verified the top five tools directly (I always spot-check the ones that would move a decision), and had enough clarity to go build my own tool by that afternoon.

That whole sequence used to be a week of work. It took me a coffee and an hour of reading.

The prompts I actually run

The framing prompt

I need to make a decision about [decision]. Before you search anything, help me frame the research. What are the three to five questions we need answers to in order to make this decision well? Push back if my framing misses something an experienced person would check.

Why: this is the difference between “research the topic” (useless) and “research the decision” (useful). Framing is the whole game.

The plan-first prompt

Propose a research plan. What sources should we hit, what subagents should we dispatch in parallel, and what specific question each subagent should answer. Don’t do the research yet. I want to review the plan before the agents run.

Why: if the plan is bad, the research is bad. A two-minute review of the plan saves an hour of re-running.

The dispatch prompt

Plan approved. Run it. Dispatch subagents in parallel. Save findings into Business/Research/[topic].md in the vault. Include source URLs inline. Flag any contradictions between sources explicitly.

Why: it specifies where the output goes (so the work compounds), what format (so it’s reviewable), and what to do about conflicts (so contradictions don’t get silently smoothed over).

The spot-check prompt

Which three findings in this report are the most load-bearing for the decision? For each of those three, re-read the source, quote the exact sentence you based the finding on, and tell me if you still stand by the claim.

Why: it forces the agent to re-verify the parts that actually matter. I always run this before I act on research.

What breaks

The agent invents sources

Every LLM, including the one powering Claude Code, will occasionally cite a URL or author that does not exist. The fix: when you see a source inline, click it. If it 404s, the finding attached to it is suspect. Treat source verification as part of the workflow, not an optional nicety.

Parallel subagents lose context

A subagent only knows what you told it when it spun up. If you forgot to give it a key constraint — “only tools under $20/month” — it will happily return a $200/month tool as relevant. The fix: front-load every subagent dispatch with the frame. Say it twice if you have to.

The web gets in the way

Some sites block web scraping entirely. Some require a login. Some load their real content in JavaScript that a fetch can’t execute. When that happens the agent will tell you it couldn’t read the page, and you’ll need to paste the content in manually or go a different route. Don’t expect the agent to bypass paywalls or captchas — that’s not what the tool is for.

The summary is too smooth

Research summaries can read so cleanly that you forget they’re compressing a lot of disagreement. The fix is explicit instruction: “flag any contradictions between sources.” Without that, the agent will reconcile disagreements silently, which is exactly the wrong thing. You want to see the disagreement, not have it smoothed away.

Your turn: a 30-minute research scan

Pick a real question you’ve been meaning to research. Not a toy one — something you’d actually act on if you had the answer. A vendor evaluation, a market scan, a policy review, a comparison of two approaches.

1. Write the decision frame in one sentence. Not “research X.” The decision X will inform.
2. Open Claude Code and describe the frame. Ask it to propose a research plan before doing any searching.
3. Read the plan. Add anything it missed. Remove anything that wastes subagent time.
4. Approve the plan and let it run. Walk away for ten minutes. Get coffee.
5. Come back and read the output. Open two or three sources directly to spot-check.
6. Ask for the three most load-bearing findings. Re-verify those before you act on anything.
7. Save the final output to a real location in your notes — so the next time someone asks the same question, you have a document to update instead of a new project to start.

If the whole thing takes you more than thirty minutes, the scope was too wide. Trim it and try again. Research with an agent is a skill — the skill is knowing how to frame the question. You get better at that the same way you get better at anything: by framing a lot of questions.

Next workflow

Your second brain with Claude Code + Obsidian

→