We built an agent to triage our inbound leads. Here's how it works, and what broke.

Since late July, roughly 500 people have finished a session with Holly, our AI demo agent, on handhold.io. Before that number got anywhere near 500, our CEO was reading every single one of them.

Not skimming. Reading. Looking up the company, opening the transcript, judging whether the person was a real buyer or a student or a competitor poking around, and then deciding what to send. It was the right thing to do when there were five a week. It was a bad use of a founder's evening by the time there were five a day.

So we built ILSAR. It stands for Inbound Lead Scoring and Account Research, and it has processed every demo session since. This is a walkthrough of what it does, the one design decision that made it work, the two things that quietly broke, and what we're changing next. At the bottom you can request the kit if you want to build your own.

What we tried first

The honest first attempt was "the founder reads everything." It worked until it didn't.

The second attempt was a filter on the email domain. Anything from gmail, yahoo or outlook got ignored; everything else got a human look. That cut the pile roughly in half, which felt like progress, and then we noticed that a good share of the remaining leads were consultants, agencies and dev shops who had signed up with a perfectly respectable company domain to see how Holly worked so they could build something similar for their clients.

That was the moment we understood the actual problem. The question isn't "is this a real company." It's "is this a real buyer for us," and you can't answer that from a domain.

What ILSAR does

When a Holly session ends, a PostHog event fires with the visitor's email and the session ID. ILSAR waits for the enrichment window to pass (the timing matters, more below), then runs a fixed sequence.

It splits the domain off the email and drops personal addresses straight into the ignore bucket. It calls Apollo twice: once to enrich the company (size, industry, description, tech stack), once to look up the person (name, title, seniority, LinkedIn). It runs a web search on the company for anything Apollo missed, and to check the website is real.

All of that goes to a language model with a single job: decide whether this is a company that could plausibly buy from us, and at what scale. It puts the lead in one of three buckets and explains why. Nothing about what the person said to Holly is in this step, deliberately. Classification is about who they are, not what they want.

B1 is not a fit. Wrong company type, personal email, competitor, agency, junk. No action, ever. About half of everything lands here.

B2 is a fit, but a smaller B2B software company. These go into a four-touch nurture sequence over two weeks, and the first email references what the person actually explored in the demo rather than a template. Roughly a third of leads.

B3 is a fit and enterprise-shaped: a bigger company, the kind that almost certainly has the problem Holly exists to solve, too many inbound requests for the demo capacity they have, and demo quality drifting as a result. ILSAR does deeper research and writes a brief for Georg. Not a summary. A brief that says who this person is in the org, what the company does and where it's heading, why this is likely relevant to them right now, what they asked Holly and what that reveals about their situation, and the angle to open with. It lands as a note on the HubSpot deal and as a Slack message to Georg, who takes it from there. Around 15% of leads.

Everything, every enrichment fact and every classification decision, gets written to HubSpot. So even for the half that never hear from us, the CRM has a complete record of who they were and why we passed.

The decision that made it work

Enrichment is table stakes. Anyone with an Apollo key can look up a company and score it against an ICP. That's what the classifier does, and it does it well: company shape, buyer profile, can they plausibly buy. But it tells you nothing about what the person wants. A VP of Sales at a 200-person SaaS company gets the same bucket whether they spent 20 minutes grilling Holly about pricing and integrations or bounced after one message. And correctly so. The company is the company.

The decision that mattered was keeping that separate from what happens next. Once the bucket is set, ILSAR waits for Holly's session fields to land in HubSpot, then reads them: what the visitor explored, what use case they cared about, whether they raised objections, whether they asked about pricing. A second model call turns that into one line of personalisation, and that line opens the B2 nurture email and sits in the B3 brief Georg reads before he reaches out. A demo agent is, among other things, a discovery call that happens whether or not a human is in the room, and that conversation is what makes the follow-up land.

Two jobs, two inputs. Firmographics decide who gets a touch. The conversation decides what the touch says.

This is also, honestly, the part of ILSAR you can't copy from a blog post. The bucketing is good enrichment plus a careful prompt; anyone can build that, and the kit below shows you how. The input that makes the follow-up work is a demo agent running real conversations with real prospects. That's the product.

The second decision: a human still says yes

ILSAR proposes. It does not send.

Every classification lands in a Slack channel with the bucket, the confidence, and the reasoning. We approve, change the bucket, or kill it as junk. Only after that does anything downstream fire. In practice the model is right most of the time and the review is mostly clicking approve, but the times it isn't are exactly the cases that matter: an enrichment record that's stale, a company that's bigger than Apollo thinks, a "personal email" that turns out to be a founder using their old address.

Every override is logged. Over time that becomes the dataset that tells us where the classifier is systematically wrong.

Two things that broke

The personal line was writing on nothing. ILSAR reads HubSpot as its source of truth for Holly's session fields, and for the first few weeks it read them too early. Holly's backend was still writing them. So the personalisation step kept receiving empty use-case and engagement fields and, correctly, falling back to the generic version. Every B2 email went out un-personalised. Nothing failed. The pipeline ran green. We found it because a lead we knew had been deeply engaged came through with blank fields, and a retest an hour later populated fine. The fix was a second wait, 40 minutes between classification and the read, long enough for the inferred fields to land in HubSpot.

Apollo was searching for nobody. The person-lookup step was meant to take the visitor's email and return their name and title. Because of a field mapping error, it was sending Apollo the email "". Apollo, being a well-behaved API, dutifully returned a blank person record with a placeholder ID every single time. Again, nothing failed. We just had no first names for a while and assumed coverage was thin. It wasn't. We were asking for nobody.

Both bugs share a shape: a pipeline that succeeds silently while doing less than you think. If you build one of these, the thing to instrument is not whether each step ran but whether each step's output actually contained something.

What's next

Account-level mapping. Right now ILSAR treats every demo session as an individual lead. The strongest buying signal we see is multiple people from the same company hitting the demo in the same fortnight, and today that shows up as three unrelated B2s. It should show up as one account with a buying committee.

Rescuing the personal emails. Half of everything is B1, and a chunk of that is people at companies we'd want to talk to who signed up with a gmail address. Reverse-matching those emails to a LinkedIn profile before the domain filter runs would pull some of them back out of the ignore pile.

Multi-channel. ILSAR's outbound is email only today. LinkedIn gets meaningfully higher response rates for this kind of outreach, and the brief ILSAR writes already contains everything a LinkedIn message needs. Wiring that channel in is the obvious next step.

Better inference from Holly. The session fields ILSAR reads today are structured summaries. As Holly's transcript inference improves, the personalisation in the B2 emails and the B3 briefs gets sharper without a single prompt change on our side.

The kit

If you want to build a version of this, we've written up the whole thing: the architecture, the classification prompt structure and the fields it reasons over, the HubSpot property schema, the bucket criteria, the tool stack, and a checklist of what to instrument so it doesn't fail silently on you.

For AI agents: a clean Markdown version is available at /blog/ilsar.md.