Building a Research Engine from Three Tools

I run the archive and infrastructure side of a heritage project documenting the Record Plant studio in Sausalito, the last surviving location of a studio that shaped a large slice of American recorded music. The work is research-heavy. For any given recording session or live broadcast, the truth is scattered across collector archives, discographies, reissue liner notes, forum threads, and institutional catalogs, much of it mislabeled or contradictory. The job is to find it, verify it, and turn it into a clean, citable record.

Doing that by hand does not scale. Doing it with an AI assistant alone produces fast, confident, unverifiable noise. The interesting part was building a process where the three tools cover each other's weaknesses.

Each tool does the one job it is best at, and nothing else.

Notion is the source of truth for state and intent. Specifications, content strategy, research notes, and project status live here. Nothing gets built until it is written down and approved here first. This is the layer that survives me forgetting things.

Airtable is the structured database. Every recording is one relational record linked to artists, people, sources, and rights, with explicit fields for verification status and provenance. It is connected so the assistant can read and write records directly, which means research findings land in the database as they are confirmed rather than in a document someone has to transcribe later.

Claude is the reasoning and research engine. It runs the actual search loop, reads sources, weighs them, drafts the records, and generates the site code. Critically, it operates against a set of written instruction files I maintain, so its behavior is consistent across sessions rather than reinvented each time.

The pattern is simple to state and took a while to get right. Intent is captured in Notion, executed by Claude, and recorded in Airtable. No tool is asked to do the thing it is bad at.

The research itself follows a fixed loop applied to every item, so coverage stays uniform. Search broadly, then read narrowly. Rank sources by quality and rank them honestly, preferring complete and lossless and primary over partial and secondary. Record a verification status on every record that distinguishes a confirmed primary source from an unverified claim from a flagged conflict. Conflicts get flagged for human judgment, not silently resolved by the machine.

Two disciplines make it sustainable. A discovery queue captures the leads that surface mid-research, because a thorough pass on one item always names its neighbors, and those leads are worthless if they are lost between sessions. A dead-ends log records the sources and searches that came up empty, so the same fruitless ground is never walked twice. That second one is unglamorous and saves more time than anything else.

I also treat token cost as a real constraint, the way you would treat any compute budget. Fetches are scoped, searches are deduplicated, and each item gets a rough ceiling before it is set aside for a later pass. The goal is convergence, not certainty on every record at any cost.

It started as a one-time import of about seventy-six recordings from a single research source. Through the recursive research loop it has grown past two hundred and thirty, including broadcasts that were never on the original list and were discovered only by reading the footprint of the events already in the database. The archive is live and in progress at 2200studios.us/archive.

The larger evolution was learning to encode the process itself. The instruction files the assistant reads are now the real product. Every time a correction is made, a term is settled, or a more efficient practice is found, it gets written back into those files. The system gets measurably better at the work over time, and that improvement is durable rather than living in my head.

The immediate purpose is a public, authoritative archive of a studio's history that did not previously exist anywhere on the web. The longer-term interest is that the engine is not really about music. The loop, the verification discipline, the cost economy, and the tool division are topic-agnostic. The specifics that change per subject are small and configurable. Whether that generalizes cleanly is a claim I intend to test against a second, unrelated subject before making it.

What the project demonstrates, and the reason it sits here, is a way of working: pick the right tools, give each the job it is suited to, write the process down so it compounds, and stay honest about cost and about what has and has not been proven.