Lab #01 asked a simple question: can an AI agent find and contact a senior sales leader using public web research alone, versus using a verified data connector? The contactability answer was stark. We ran it again on a fresh set of ten companies to see whether that held.
The short version: the contactability gap replicated exactly. Public web research returned zero usable emails and zero usable phone numbers across ten companies, under a strict no guessing rule. But the more useful finding came from a mistake in our own method. Three companies appeared to return nothing from the connector. They hadn’t. A single filter choice was hiding 72 senior contacts, and correcting it exposed two data behaviors worth knowing about.
Every figure on this page was pulled live via Lusha’s MCP tools on August 15, 2026, and cost 3 credits in total. Individuals are masked to initials, with no contact details or profile URLs published. Companies are named because they are business entities, not personal data.
What we ran
Ten real, active B2B software companies across developer tools, AI infrastructure, and enterprise software, spanning early to growth stage. The set is deliberately different from Lab #01’s, and the companies are anonymised here as Company A through Company J. What drives the finding is their structure, not their names.
Condition A, public web research only. Locked instruction: identify a current senior sales leader, return name, title, work email, phone, and LinkedIn. Do not guess. Return “not found” if unverifiable.
Condition B, the same task through Lusha’s connector, using a filter for VP and C-suite seniority, Sales department, United States.
Start with the confound, because it invalidates half the experiment
Condition A asked an open question. Condition B applied a narrow filter. Those are not the same question, so the identification counts, 6 of 10 versus 7 of 10, are not comparable and we are not presenting them as a result. An open search and a filtered search return different things for structural reasons, not capability reasons.
The contactability comparison is unaffected, because both conditions were asked for the same fields under the same no guessing rule:
| Metric | Public web research | Lusha connector |
| Usable work email | 0 of 10 | 6 of 10 |
| Usable direct phone | 0 of 10 | 7 of 10 |
| Complete record | 0 of 10 | 6 of 10 |
Same pattern as Lab #01, different companies. Public research is capable of identifying who runs sales at a company, often from the company’s own announcement. It does not surface a way to reach them. Names are public. Contact details are not.
One contact returned a phone number but no email, which is worth stating plainly: field coverage is not uniform even within a matched record.
The finding: filter design moved the result more than the database did
Three companies returned nothing in Condition B. The tempting conclusion is a coverage gap. We tested it instead, changing one variable at a time against the same database, the same three companies, the same session.
| Filter | Senior contacts returned |
| Sales department, VP and C-suite, United States | 0 |
| Sales department, VP and C-suite and founder, worldwide | 2 |
| Any department, VP and C-suite, worldwide | 72 |
Nothing about the data changed between those three rows. The department filter was doing nearly all of the work. Senior people exist at all three companies and are tagged General Management, Operations, Finance, Legal, and Product. Very few sit under Sales.
That is the practical lesson, and it is not specific to any one provider: an empty result is a statement about your filter at least as often as it is a statement about the database. Before concluding a company is not covered, remove one filter at a time and watch what returns.
The one we were looking for was there the whole time
For Company A, public research identified the senior commercial leader as a co-founder, sourced from the company’s own page, and Condition B returned nothing. The obvious reading is a miss.
The record was in the database the whole time. It is tagged department General Management, seniority founder, with a title combining co-founder and a C-level operating role. So it was excluded twice over: the department filter ruled it out, and founder is a separate seniority value from C-suite, so the seniority filter ruled it out again.
Worth flagging rather than resolving quietly: public research returned a commercial title for this person, and the connector returns an operating title. One of the two is stale and we have not established which. If you are building an account plan on a single title from a single source, that is the kind of discrepancy that decides who you address an email to.
Finding: a title containing “Founding” is read as founder seniority
The middle row of that table returned two contacts. Neither is a founder. They are a Founding Account Executive and a Founding Sales Development Representative, both individual contributor roles on an early team, both tagged with founder seniority.
The classifier appears to key on the word “Founding” in the title string. That is a small thing with a real consequence: a seniority filter set to founder to catch actual company founders will also return early sales hires, and a filter set to exclude founders will drop them. Read the returned titles rather than trusting the seniority label alone.
Finding: employer of record companies break company based filtering
The 72 result run surfaced something we were not looking for. Company A returned more than fifteen separate records titled Chief Executive Officer, spread across eight countries on four continents plus several US cities. One record carries a company name in place of a person’s name.
No company has fifteen CEOs. Company A is an employer of record. People employed through an EOR are, in a real administrative sense, employed by it, and they list it accordingly. Their titles are their real titles at the companies they actually work for.
This is not a defect in any one database. It is structural, and it applies to every employer of record and professional employer organization. Any account based search against one of these companies will return a population that has nothing to do with that company’s own org chart.
What to do about it: when a company search returns an implausible number of executives with unrelated titles scattered across many countries, check whether the company is an EOR or PEO before treating the list as an org chart. Verify a handful against the company’s own site.
What this means if you are prospecting
Treat an empty result as a question, not an answer. Remove one filter at a time. In this test, dropping a single department filter took the same search from zero results to 72.
Check the seniority values before you rely on them. Founder is a distinct value from C-suite. A filter for VP and C-suite excludes founder led companies entirely, which describes a large share of the early stage market.
Read titles, not just labels. The seniority field is derived. When it disagrees with the title string, the title string is the thing a buyer would recognize.
Cross check a senior title against a second source before you write to it. Our two sources disagreed on one person’s function. That costs nothing to check and changes the opening line of an email.
What we would change in Lab #03
Run both conditions against the same question. Either give the public research condition the same narrow constraint, or run the connector open with no seniority or department filter. Until those match, the identification numbers are not a comparison and should not be reported as one.
We would also record the filter configuration for every run, since this lab demonstrated that the configuration moved the result more than anything else we varied.
Method notes
- Ten companies, selected as real active B2B software businesses across developer tools, AI infrastructure, and enterprise software, distinct from Lab #01’s set.
- Condition A ran under a locked no guessing instruction. Companies with no confidently confirmed senior sales leader were recorded as not found rather than filled with a best guess.
- Condition B’s first pass used incorrect seniority values, manager and director rather than VP and C-suite. Caught and corrected before any contact fields were revealed.
- Total connector cost for the follow up investigation: 3 credits. Filter value lookups cost nothing.
- No contact fields were revealed for this article. All names masked to initials, no profile URLs, no emails, no phone numbers.
FAQ
Why did a search return nothing for a company that obviously has senior staff?
Usually the filter, not the coverage. In this test, the same three companies returned 0 results with a department filter applied and 72 with it removed. Department, seniority, and country filters compound, and each one can independently exclude a record that exists. Remove them one at a time before concluding a company is not covered.
Is founder the same as C-suite in a seniority filter?
No. They are separate values. A filter set to VP and C-suite will exclude a founder CEO, which in early stage companies is often the person you want. Include founder explicitly when the target is a founder led business.
Why do employer of record companies return so many executives?
Because people employed through an EOR list the EOR as their employer, while keeping their real title at the company they actually work for. A search scoped to that company returns a mixed population that does not reflect its org chart. Check whether a company is an EOR before treating a result set as a leadership list.
Can public web research find a senior sales leader?
Often yes, for the name and title, particularly when the company has published an announcement. Across ten companies it identified six under a strict no guessing rule. What it did not produce, in any of the ten cases, was a usable work email or direct phone number.
Does a seniority label always match the job title?
Not always. In this run, a Founding Account Executive and a Founding Sales Development Representative were both labeled founder seniority, apparently because their titles contain the word “Founding.” When the derived label and the title string disagree, trust the title.
Go deeper
- claude.com/connectors/lusha, install Lusha directly from Claude
- www.lusha.com/campus/plays, ready to run prompts for verified prospecting and signals
- How AI agents pick your data tool, where the credits go and how to check before you spend
Want to run this yourself? See what Lusha’s connector covers
