How I Use Claude for Research

This is the second post in a six-part series on how I use Claude as an executive pastor: for research, for prompt and context engineering, for running operations, and for building software. After the opener on ground rules, research comes next because it takes the least setup and it's where most people begin.

On August 9, I asked Claude to audit a reference file I keep on AI platform facts: model names, release dates, technical limits. One of the agents working on the audit came back with a warning. Two release dates in my file, it said, looked fabricated. My local copies of the vendor documentation didn't mention them.

The dates were correct. I opened Anthropic's live release notes and both were there. If I had taken the report at face value, I would have deleted two true facts from a file that other tools depend on. I would have done it on the word of an AI that was confident about something it could not see.

That moment is the whole post in miniature. Claude is fast, tireless, and genuinely useful for research. It is also not a source. It's a research assistant, and research assistants need supervision, a filing system, and a standard for what counts as evidence.

Mosaic Northeast Ohio has about 750 people on a Sunday, about 1,500 who call it home, and 11 full-time staff. I carry executive responsibility for finance and IT, and I've recently stepped into a role helping manage our ministerial staff, our Adult Ministries, and our small groups ministry. Nobody on our staff has "research" in their job description.

The questions still come. In the last year alone, I've had to answer some version of these:

A larger church might have a strategy staffer or a consultant on retainer for questions like these. Most churches our size do one of two things. They decide on instinct and a few blog posts from other churches, or someone loses a week to reading. I've done both. Neither is good stewardship.

There's a second problem specific to church operations. The literature is thin. There is a lot of practitioner material and very little evidence. Plenty of people will tell you how to build a volunteer pipeline. Very few have measured whether their way works. Any research method that can't tell those two apart will hand you confident advice built on anecdotes.

The shift that made Claude useful for research was deciding what job it has. It doesn't hold the truth. It finds, sorts, summarizes, and challenges. I decide what's true. That division of labor comes down to four rules I hold myself to.

The fourth rule is the one most people skip, and it's where most of the value is.

Three examples from the past year show the pattern. Each one is a different kind of research.

This fall I drafted a leadership pipeline for Mosaic. It has seven scope levels, running from volunteering on a team to leading the organization. The draft made four specific design bets: apprenticeship instead of cohort programs, a named developer for every person, promotion based on observed next-level behavior, and sign-off from one level up.

I didn't ask Claude whether the pipeline was good. That question invites flattery. I asked it to take each design choice and sort it into one of three buckets: supported by the evidence, contradicted by it, or untested. Then I named the sources I wanted on the table: the leadership pipeline model from Charan, Drotter, and Noel; Foppen and van Saane (2023); Bridgespan (2014); Spreitzer (2006); and church practitioner material from Aubrey Malphurs, Mac Lake, and others.

The "untested" bucket turned out to be the most useful. It told me where I was making a judgment call, not following evidence, which is exactly what I need to say out loud when I present this to our staff. The draft is now at version 0.2, with three trainings built around it.

Before we overhauled our Planning Center database, Claude and I compiled a best-practices reference, dated April 15, 2026. Every topic in it follows the same structure: what the consensus is, what's specific to Planning Center, and the sources behind both. It covers data quality, field standards, membership categories, and more.

That reference became the measuring stick for everything after it. Our audit findings and our overhaul plan both point back to it. When someone asks why we're changing how we record membership, I can show them the standard and where it came from, instead of saying "Claude told me."

The most developed example is a knowledge base I keep on prompting and AI agent design. It's my reference for the next post in this series, and it's built on a structure I'd recommend for any research topic you'll return to.

Every file gets a tier:

File names follow one pattern, so I can tell what a file is without opening it:

Every primary source also carries a status: CURRENT, UNVERIFIED (more than 90 days since anyone checked it), or STALE (replaced by something newer). I later added a second marker for how complete the capture is (FULL, PARTIAL, or METADATA-ONLY). Some vendor sites resist clean extraction, and a file can be current but incomplete. I want to know which.

The rule that holds it together: archive, never delete. When a source is replaced, the old version moves to the archive with its capture date. If I ever need to know what the documentation said in June, I can find out.

In August I ran a full refresh. Claude worked through the index, sent parallel agents out to capture sources, and had each one write its file directly to disk. Thirty-six files were captured or re-captured, ten superseded versions were archived, and three known gaps were closed. When sources disagreed, the disagreement went into the index as an open item. It was not quietly resolved by whichever agent happened to see it.

Under all three examples sit a few habits that catch most problems:

This would be a sales pitch if I stopped here. Claude gets research wrong in predictable ways, and knowing the patterns is most of the defense.

It's confidently wrong about software. In May, I was setting up automatic transcription for meeting recordings with MacWhisper, an app on my Mac. Claude checked the app's command-line help, didn't see an option for labeling speakers, and told me the feature wasn't available. Its plan was a custom workaround: a scheduled background job, a transcription script, and a third-party transcription service.

That seemed like a strange oversight for a mature app, so I pushed back. One search of the vendor's documentation settled it. Speaker labeling was built into the transcription models, and the app already had a watch-folder feature that solved most of the problem. We were about to build infrastructure for something the app already did. Now, any "this tool can't do X" claim gets checked against current documentation before we build anything.

It believes your own documents. In April, my daily briefing flagged an exchange it had read as a mistake. The exchange described our fiscal year as running September through August. One of my context files said it ended in July. The briefing recommended I correct the exchange.

It was right. My file was wrong. Claude had treated an internal document I wrote as ground truth, and it almost had me correcting something that was right. Internal files are sources too, and they drift like any other source. When a claim rests on a single internal document, it gets confirmed with a person before anyone acts on it. And when the file is wrong, the file gets fixed the same day.

Some sources are out of reach. Depending on the environment, Claude can't always retrieve full research papers. Paywalls and PDF restrictions get in the way. In my knowledge base, four papers are still waiting for me to download them by hand. A summary of a paper's abstract is not a reading of the paper, and I mark those files as incomplete.

It fills gaps. Ask for five examples when only three exist, and you may get five. The fix is the same as rule three: make "I couldn't find this" an acceptable answer, and say so in the prompt.

I would have built the filing system on day one. My early research lives in chat histories I'll never search. I'd also write down the rules of evidence before the first serious research session, not after the first mistake. And I'd put a date on everything. An undated fact is a liability, because you can't tell when it went stale.

You don't need my setup to use this approach. You need a prompt that sets the rules, and a folder that keeps the results.

Here's a research prompt you can adapt. Paste it at the start of a conversation and fill in the brackets:

The last line matters more than it looks. Agreeing on the questions first prevents the most common research failure: a well-written answer to the wrong question.

Then keep the results. A simple version of my tier system works for any church:

Add a date and a source to every file, and review the A1 files every quarter. That's enough to start.

Claude made research possible for a church our size. The discipline around it makes the research trustworthy. You need both, and only one of them comes in the box.

Next in this series: prompt engineering, and why I've mostly stopped thinking about prompts and started thinking about context.