Three research tools my agents replaced in 45 minutes

Researching 162 companies with Claude Code agents: a swipe tool instead of listing-site filters, an A to F reputation score instead of Glassdoor, and a fifty-line Puppeteer service instead of a screenshot API.

8 min read

Updated

In this article · 7 sections

Agents researched 162 companies for me and replaced three tools along the way. The whole stack took about 45 minutes and two cups of tea to build and run.

The work was ordinary business research: who are these companies, what do they use, how are they regarded, and who should I contact? An agency building a prospect list needs the same answers. A database gives you names, but names alone don't tell you whether a company meets your brief.

Two of us, both software engineers, worked on two MacBooks connected to one shared code-server. At peak, ten Claude threads were running: some researching companies, some building features, some debugging. It felt like pair programming, but with two people directing ten parallel streams across different problems. Everything ran locally, so there was no deployment pipeline or infrastructure to manage.

Across five layers and six research rounds, three tools dropped out:

  • Listing-site filters, replaced by a fit score and a keyboard-driven review tool.
  • Glassdoor's headline rating, replaced by an A to F reputation score built from several signals.
  • A hosted screenshot API, replaced by about fifty lines of Puppeteer.

But the first batch of research was almost useless.

Finding companies wasn't the difficult part

Three parallel agents found 101 companies in ten minutes, searching startup databases and company sites. They returned names, locations, one-line descriptions, funding stages and rough fit scores.

The companies were real. The locations and funding information were accurate. But a description like "AI music discovery" gave me nothing to decide on. Was the product real? Did anyone use it? Could the company survive the next 18 months?

I'd automated collection, but comprehension was still my problem, so finding the names quickly left me with 101 companies I didn't understand well enough to judge.

I used Claude Code to run the research workflows: take a written brief, search the web, inspect company sites and produce structured output. I reviewed what came back, because the agents could chain several steps on their own but their output still needed supervision.

I built custom skills, reusable workflows I could invoke like functions. The discovery skill searched, evaluated, scored fit, checked reputation and wrote to three synchronised stores: TypeScript for the review tool, markdown for detailed dossiers and CSV for analysis. Three parallel agents could research 20 to 28 companies each in a single pass.

Over six rounds, including deliberately niche searches, the agents evaluated hundreds of candidates and surfaced 162 companies scoring at least 3/5 against the brief. But I still needed a way to make decisions about them.

One card at a time exposed the gaps

Listing sites can give you ten thousand results without any of them being right. Their filters recognise keywords, but they don't know the difference between the thing you want and something that merely sounds similar.

I built a Tinder-style review tool inside the existing Next.js monorepo instead. It used React components, the existing Tailwind setup and a JSON file read through an API route, with zero new dependencies.

Each card showed a company name, location, fit score badge and notes, with a logo from Google's free, keyless favicon API. Arrow keys recorded yes, no or maybe. Backspace undid a decision, with full history. A progress bar tracked the reviewed count and running yes and maybe totals.

One company at a time was easier than a spreadsheet of 101 options. But the interface also made weak research impossible to ignore. How could I confidently swipe a card that said only "Music rights management", scored 3/5? Was it a three-person startup on angel money or a profitable company with 200 people?

Every hesitation was a data gap, and every maybe pointed to a missing signal. The review tool therefore showed me exactly where the research was thin, which is what the next layers were built to fill.

After I'd reviewed 48 companies by hand, my decisions showed patterns I hadn't written into the brief. Anything rated D or F on reputation got an immediate no, and whole categories got consistent answers. We applied those patterns to the 96 companies I hadn't reviewed, classifying them in minutes with my own logic. The tally reached 144 reviewed: 50 yes, 14 maybe and 80 no.

Reputation needed more than a star rating

Fit told me whether a company matched the brief. Reputation told me whether it looked safe to deal with. A company could score 5/5 on fit but still have rolling layoffs or financial trouble.

Three parallel agents, each with a batch of companies, searched Glassdoor reviews, layoff trackers, news and forums. They looked at review trends rather than just the number, layoff history, CEO approval over time, press coverage and financial stability. Every company with enough public evidence received an A to F rating. Strong reviews, no recent layoffs, positive press and visible staff advocacy supported an A; major scandals, mass layoffs or financial distress pointed towards an F. Most landed between B and C, where you read the detail before deciding.

I didn't want Glassdoor's headline number making the decision. An Originality.ai study of Glassdoor reviews found that AI-generated reviews for S&P 500 companies rose 376.3% from 2022 to 2024, from 6.18% to 29.45% of reviews: nearly one in three.

One company on the list had a 4.7 rating, but its acquisitions had ended in mass layoffs. The reviews came from the people who stayed, not the people let go: survivorship bias in star-rating form.

Fit and reputation stayed on separate axes as a result. High fit with high reputation meant priority, while high fit with low reputation meant a warning. Several apparent yeses ended up rated D or F once the wider picture came in. A high score alongside recent mass layoffs worried me more than a moderate score with stable staff.

Two broken services became fifty lines

I wanted a live website screenshot on each card, because a homepage tells you at once whether you're looking at a real product or a landing page untouched since the seed round.

I tried thum.io, but got "image not authorized". WordPress's mShots never loaded. Two services, both broken.

So I told Claude both screenshot services were broken and asked whether we could just build our own. In under two minutes we had a working Puppeteer screenshot API, on the first try.

About fifty lines launched headless Chrome, captured a 1280x800 screenshot and saved it to disk. Later requests got the saved image as a static file, so the first capture took a few seconds and every repeat was instant.

A lot of SaaS exists because building the thing yourself used to be too much hassle. But when the build costs two minutes of conversation, build versus buy flips. Every time a tool broke or fell short during the project, the answer was to build the replacement, and the replacement was usually better.

There is a fair argument against running your own screenshot service in production. But this was an internal research tool for 162 companies, running locally, and at that scope the complexity was trivial.

The evidence sat beside the decision

Under each card went the screenshot, the top five mentions from the free Hacker News search API from Algolia, and one-click links to Google News, LinkedIn, Glassdoor and GitHub. A company with no Hacker News mentions is invisible; one with twenty mentions and arguments in the comments tells a different story.

The results were cached in a JSON file, following the rule for the whole system: everything on disk, nothing in browser state.

Decisions went into decisions.json rather than localStorage. Company data lived in three synchronised files, screenshots in a local folder and Hacker News results in their JSON cache. Every piece of state could be versioned, diffed and read by other agents. That mattered with ten Claude threads running, since any one of them might need another's output.

A list still needs someone to contact

A company database is a phone book. It only becomes useful when you know who to call and what to say, so a second session of about another 45 minutes went on dossiers and approaches.

A deep-dive skill took a company name and researched recent news, the tech stack, two to five key contacts with LinkedIn profiles, pain points and possible angles. A second skill read the dossier and produced a plan: which channels, who to contact first and in what sequence. A third drafted messages in my voice, follow-ups included.

Each skill checked its prerequisites: a plan needed a dossier, and messages needed a plan. That chain took a company I'd never heard of to a personalised draft in about fifteen minutes of agent time.

We ran ten parallel agents across the 50 yes companies, in batches of three to seven. They finished 44 dossiers before hitting the API usage ceiling, and two follow-up agents completed the remaining six. Each dossier was the equivalent of a few hours of manual searching, compressed into minutes by agents that don't get bored or forget to check the engineering blog.

Every company on the list got its own page in the web app, with its profile, decision and dossier together. It felt like working from a CRM, but underneath it was still readable files the agents could use.

The bottleneck was our attention

The agents researched and built quickly, but we had to direct them, review their output, catch errors and decide what to research next. Two people meant twice the capacity to review and redirect, and more parallel threads still needed someone paying attention.

That judgement is what I teach a person or team in a day of running agents on their own business. Agents are fast and thorough, and they'll collect the signals and prepare an approach, but they don't know which company makes your gut uneasy. That layer is still human.

Research and sources

Checked 2026-10-18. Next review: 2027-04-18. Listings and availability can change.

  1. Claude Code overview

    Anthropic · Checked 2026-10-18 · Primary source

    Claude Code is the agentic tool that ran the research workflows and built the tooling.

  2. Next.js

    Vercel · Checked 2026-10-18 · Primary source

    Next.js is the React framework of the monorepo the swipe review tool was built in.

  3. 376.3% Increase in AI Glassdoor Reviews for S&P 500 Companies: 2022 to 2024

    Originality.ai · Checked 2026-10-18 · Primary source

    AI-generated Glassdoor reviews for S&P 500 companies rose 376.3% from 2022 to 2024, from 6.18% to 29.45% of reviews.

  4. thum.io screenshot API

    thum.io · Checked 2026-10-18 · Primary source

    thum.io is the hosted screenshot service tried first, which returned "image not authorized".

  5. Automattic/mShots

    Automattic · Checked 2026-10-18 · Primary source

    mShots is WordPress's website thumbnail and snapshot service, the second screenshot service tried.

  6. Puppeteer

    Google Chrome · Checked 2026-10-18 · Primary source

    Puppeteer is the library that drives headless Chrome, which the replacement screenshot service was built on.

  7. Hacker News Search API

    Algolia · Checked 2026-10-18 · Primary source

    Algolia's Hacker News search API is the free API the research panel pulled each company's top mentions from.

People and organisations mentioned

What are you building or trying to learn?

Got a list of companies your team researches by hand, one tab at a time? Tell me what you're trying to find out about them, and I'll tell you how I'd hand it to agents.

Build or learn with me
Doug SilkstoneFounder, builder & operator

I build and run businesses with a team of me plus AI agents. These articles draw on the methods I use across product, brand, design, outreach, sales, growth, support and operations, and the work I do with other businesses.

About me · More articles by Doug