Claude Code for outbound: build a lead research agent

Claude Code can read a list of companies, open their public pages, and write a short research note and one specific observation per lead into a file. Build it in four steps: input, research, writing, review. Keep it to public information, have a person read the output before any message is sent, and use Sellinger through MCP or the API when you want the sending, replies, limits and suppression to be handled for you.

Research is the part of outbound that people dislike most and that an AI does well: reading a website, finding the one thing that matters, writing it in a line. This tutorial builds a small version of it, shows where it stops, and says when it is better to hand the rest to a platform.

What does a lead research agent do?

For each company on a list it answers three questions:

1. What does this company do, in one sentence, in plain words?
2. Is there a recent public event that gives a reason to write: a hire, a launch, a post, a new market?
3. What is one specific observation a person could make in a first message?

The output is a row in a file, not a message. A person reads the row, and decides whether to use it. That separation keeps the agent's mistakes from reaching a prospect. It also fits our own finding: on our own LinkedIn outbound, openers that state an observation out-replied openers that ask a question by 10 to 15 points. See observation openers beat questions. The agent's job is to find the observation.

How do you build it in four steps?

Step 1: input. A CSV with a company name and a website, and optionally a person's name and title. Keep it to 20 rows while you test.

Step 2: research. For each row, Claude Code opens the website's home page, about page and news or blog page, and reads them. It should only use what is on those pages or on pages they link to. It writes the findings to a notes file with the URL of each source.

Step 3: writing. From the notes, the agent writes two things per lead: a one sentence summary and one observation line, written the way a colleague would say it. It must quote the source line it used.

Step 4: review. A person opens the file and marks each row as use, edit or skip. Anything marked use goes into your outreach tool. Nothing is sent from the research step.

A short instruction file works well. A sample of what it should say:

• Use only text from the company's own site and pages linked from it.
• For each claim, give the URL and the line you read.
• If you cannot find a recent event, write "no event found". Do not guess.
• Write the observation in one sentence, with no flattery and no pitch.
• Never write a number you did not see on the page.

What guardrails does it need?

A model that is asked for a fact will sometimes supply one. The guardrails exist for that.

• Sources on every claim. If a row has no source line, it is rejected.
• A "no event found" option. Without it, the agent invents an event to be helpful.
• A small sample first. Read all 20 rows by hand and count how many observations are wrong. If more than one or two are, change the instructions.
• Public information only. Do not log in to sites, do not scrape private profiles, and do not store personal data you do not need. Work contact details are personal data under GDPR when they name a person, and a lawful basis is needed to use them. See is cold email legal.
• A person approves before sending. This matters more than any other rule.

What can it not do?

Be clear about the limits, because they are where DIY projects stall.

• It does not send safely. Daily limits, quiet hours, a suppression list, opt outs, replies in the right language and account safety are all separate work. Our post on what DIY outbound breaks first lists them.
• It does not hold the conversation. A reply at 02:00 needs an answer, and a follow up needs a schedule.
• It does not know which lists work. On our own account a list built from an intent signal replied at 54.6% and one from a Sales Navigator search at 21.7%. A research agent improves the message, not the audience.
• It forgets. Without a store of past conversations, it will write to someone you already spoke to.

If you want the full picture of building your own, read automate LinkedIn yourself with n8n, Claude or Python and build or buy an AI SDR.

When should you connect Sellinger instead?

When the research is working and you want the rest handled. Two ways to connect:

• MCP. A hosted connector with 43 tools lets Claude read your leads, campaigns, conversations and analytics, and act on them, with approvals. Connecting takes four clicks. See what MCP is for sales and the MCP recipes, such as find new prospects.
• API and webhooks. A REST API with webhooks, from the Full Stack bundle up, so your Claude Code script can push researched leads and observations into Sellinger and read results back. API keys are stored only as SHA-256 hashes, can be revoked or set to expire, and carry limits. Start with the quickstart.

The split that works: Claude Code does the research and drafts the observation. Sellinger sends, follows up, answers replies, stops on an opt out and books the meeting.

What does it cost to run?

We make no claim about model prices, which change often, so check your provider's page. The cost that matters is your own time: a few hours to build the first version, an hour a week to read the output and fix instructions, and the time you spend on the things the script does not do. Our estimate for the time side of a platform is about five hours a week for a small team, and a DIY stack adds the work of keeping every part running. The posts on the real cost of owning an AI SDR and on building or buying have the full comparison.

A sensible path is to build the research step yourself, because it is small and teaches you what a good observation looks like, and to buy the parts that are boring and risky.

A checklist

• [ ] The agent reads only public pages and quotes its source for every claim.
• [ ] "No event found" is an allowed answer.
• [ ] I read all 20 rows of the test run and counted the errors.
• [ ] A person approves before anything is sent.
• [ ] I know what I am not building: sending, replies, limits, suppression.
• [ ] I decided whether to push the notes into a platform by API or MCP.