Anysite Company Sourcing

---
name: anysite-company-sourcing
description: The craft of sourcing companies from Anysite's 70M+ LinkedIn company database (search_sql_companies) - turning a fuzzy ICP into per-field DSL filters that return real matches instead of token soup. Fixes the default failure mode where naive keyword queries return companies from the wrong country, wrong industry and stub pages. Use when the user asks to find/source companies, build a company list, complains that company search results are bad or irrelevant, or needs a target-account universe - "найди компании", "плохие результаты поиска компаний", "source accounts". For people at those companies use anysite-people-sourcing; for funding-stage filters use crunchbase; for pushing into a CRM use anysite-crm-prospect.
---

# Company Sourcing

`linkedin/search/search_sql_companies` searches 70M+ companies and is the single
best bulk company tool in the catalog — **and its naive use is the single most
common source of garbage lists.** Measured live, same intent, same day:

- `{keywords: "AI startup San Francisco"}` → **1 relevant of 5**: a Tel-Aviv
  gaming-data firm, a Sydney fintech and a Ho-Chi-Minh beauty e-commerce all
  matched — each had the token "startup" somewhere in its description and
  "San Francisco" among *secondary* office locations.
- The same intent as structured filters (below) → **5 of 5** genuine SF AI
  companies in the right size band.

The difference is the whole skill. Never ship results from a naive query.

## Why naive queries fail (mechanics, not opinion)

1. `keywords` matches whole words across ALL text fields — name, description,
   specialities, hashtags **and the locations array** — so "San Francisco" as a
   keyword still matches a Hanoi company that lists an SF sales office in
   `locations`. (Whole-word matching removed the inner-substring noise, but not
   the wrong-FIELD problem — HQ is a separate field, use it.)
2. **`sort` changes ordering, not the candidate set — a naive keyword query is
   still not an ICP list.** With relevance (the default), "AI startup San
   Francisco" surfaces *Startup Weekend AI*, *Bitcoin AI Startup Lab*, 1-employee
   shops and a Phoenix-HQ company (all measured) — they score high because the
   words sit in their NAME. The fix is per-field decomposition below, not a sort
   flag.
3. Millions of company pages are stubs. Without hygiene filters they dominate.
4. `employee_count_range` can contradict `employee_count` in the same record
   (measured: 305 employees with range "11-50"). Never filter or segment by the
   range string.

## The method: decompose intent into fields

Take the user's ICP sentence apart and map each fragment to its OWN field:

| Intent fragment | Field | Notes |
|---|---|---|
| "based in X" | `country_hq: ["US"]` + `headquarter_location: "\"san francisco\""` | token-aware; NEVER the `locations` field — that matches branch offices |
| "present in X" (offices count too) | `country_any` | this is the only right use of the locations array |
| "does AI / fintech / logistics" | `specialities` OR `industry_name` OR `description` together, not specialities alone | `industry` array wants URNs; `industry_name` resolves labels — see the specialities caveat below |
| "in the orbit of company X" | `similar_organizations: "\"fsd_company:<id>\""` | queryable filter, not just an output field — the reverse-graph expander; see below |
| "startup / SMB / enterprise" | `employee_count_min` / `employee_count_max` | integers; ignore `employee_count_range` entirely |
| "founded recently" | `founded_on_min` | year |
| named company lookup | `name` or `alias` DSL + exact verification | never trust first hit; resolve by domain via the anysite-mcp resolve recipe |
| always, every query | `is_active: true, has_website: true, min_description_length: 100` | the hygiene trio kills stubs and dead pages |
| ranking | `sort` = `relevance` (default) or `last_modified` | relevance for sourcing; `last_modified` for "what's new since last run" (monitoring). Scoring weights a term by field: name 5× > specialities/hashtags 3× > short_description 2× > long description 1×, length-normalized; ties broken by recency. **Caveat:** the score is built only from `keywords`/`name`/`specialities`/`description` — a query filtered ONLY by non-text fields (e.g. just `industry` + `employee_count_min`) has nothing to score, so it falls back to recency order |

DSL in every text field: whitespace = AND, `|` = OR (no spaces around it),
`"phrase"` = exact phrase / substring, `-token` = NOT. Example:
`specialities: "\"artificial intelligence\"|\"machine learning\" -agency"`.
**IRON RULE: quote every multi-word alternative in an OR chain.** Whitespace
binds tighter than `|` — `name: "Level Infinite|Proxima Beta"` parses as
`(Level) AND (Infinite|Proxima) AND (Beta)` and returns 0 (verified live on the
sibling people endpoint, same parser). Lint before sending: a space inside an
OR alternative without quotes → fix first.

**Matching semantics (changed — this is now the biggest lever):**
- **A bare word matches as a WHOLE WORD, not a substring** (verified live:
  `keywords: "sdr"` returns "SDR Academy", "SDR Foundry", "Vida SDR" — companies
  with the standalone word, and no longer "adviseur"-style inner hits). Case
  doesn't matter.
- **No stemming.** `integration` does NOT find `integrations` — write both:
  `integration|integrations`. Same for singular/plural and verb forms.
- **Quotes = substring** (the old behaviour, kept). `"integr"` matches both
  `integration` and `integrations`; `"machine learning"` matches that exact
  sequence. Use quotes deliberately when you WANT a fragment.
- Terms with separators (`b2b-saas`, `S.E.E.D.`, `x.com`) and Cyrillic are
  auto-substring — nothing to change for them.
- `alias` and `website` are untouched — still substring (`alias: "openai"` finds
  `openai-inc`); `hashtags` is exact element match.

Practical consequence: short single-word queries used to be the WORST case (inner
substring noise); they are now precise. If you actually need "a piece of a word",
reach for quotes.

**Specialities caveat:** self-declared tags are the highest-signal field WHEN
present, but hot young startups often leave them blank — measured: 2/10 in a
US/Software slice had empty `specialities[]`, one of them Hebbia ($160M-funded,
empty short_description too). So `specialities` is a widening OR alongside
`industry_name` and `description`, never the sole gate, or you silently drop
exactly the fresh-funded targets a list is built for.

## The loop (never skip step 3)

1. **Build** the per-field query from the decomposition above.
2. **Probe** with `count: 10`.
3. **Validate against the intent, not the filters**: for each of the 10 check
   HQ country/city, what the company actually does (short_description), and
   `employee_count`. Fewer than ~8 on target → the query is wrong, not the data:
   move misused fragments to their proper field, add `-tokens`, tighten
   phrases. On target → widen coverage with `|` synonyms in the same fields
   (`"machine learning"|"computer vision"|"nlp"`), re-probe.
4. **Fetch** the real volume (`count` up to 1000). More than 1000 matches →
   split by size bands / countries / founded ranges into disjoint queries.
5. **Free re-cuts**: `query_cache` on the result for sorting, counting,
   sub-segmenting — don't re-execute.

## Two hard limits to state up front (TAM planning)

Unlike people search, company search has **no `bucket_total` and no count-only
mode**. That means:

- **You cannot ask "how big is my ICP universe" cheaply** — there's no total
  count without pulling rows. Size the split blind, or probe representative
  sub-slices and extrapolate; tell the user the number is an estimate. (Still
  true regardless of `sort`.)
- **A >1000 match returns only the top 1000 by rank**, so full coverage still
  needs splitting by size/country/founded into sub-queries each < 1000. With the
  relevance default the top is at least relevance-ordered rather than a pure
  recency head, but you still don't see rows 1001+. Note card freshness lags
  (`employee_count` drifts from reality on some records). Dedup on band
  boundaries by `urn` (`query_cache uniq`). `last_modified_after` +
  `sort: last_modified` is the right combo for a "new since last run" sweep.

## Read the bonus fields — they're the handoff

Every row carries, at no extra cost:

- `organizational_urn` (`company:<id>`) → **feeds `anysite-people-sourcing`**
  (`current_company_id`) and `search_jobs` directly;
- `website` → domain for CRM matching and `current_company_domain` people filters;
- `crunchbase_link` → free crunchbase alias, skip the live 20cr search;
- `similar_organizations[]` → both an output list AND a **queryable filter** (the
  bigger lever — see below);
- `specialities[]` → the company's own vocabulary, reuse it to widen synonyms.

## similar_organizations as a filter — the reverse-orbit expander

Verified live: `similar_organizations: "\"fsd_company:1441\""` (Salesforce) +
`country_hq:["US"]` + size band returned 8 companies, all 8 carrying Salesforce in
their own similar-orgs graph. This is "who sits in the orbit of company X" — the
right tool for two jobs no keyword query does well:

- **ICP expansion from a seed account** — feed your best customer's `fsd_company`
  id, get its competitive/adjacent set.
- **Competitor-adjacency lists** — the closest this skill gets to "companies like
  my competitor". (It is NOT the competitor's customers — for that,
  `anysite-crm-competitor-intel` via wappalyzer/reviews.)

Noisy — roughly 3/8 were on-target in the test — so always combine with
`industry_name`/`specialities` and run the probe-validate loop. Batch-fetching the
output `similar_organizations[]` by `urn:[...]` (≤12 at a time) is the weaker,
one-hop version; the filter is the scalable one.

## When a different tool is right

- Funding stage / investors / valuation → `crunchbase/db/db_search` (dates as
  unix ts, count ≤100) or live `crunchbase/search` (`hiring`, `it_spend` filters).
- One known company by domain → the resolve recipe in `anysite-mcp` (substring
  trap: stripe.com → Soundstripe; verification mandatory).
- Early-stage / launches → `yc/search/search_companies`, `producthunt`, `betalist`.
- People at the sourced companies → `anysite-people-sourcing` with the URNs/domains
  from step "bonus fields". CRM push → `anysite-crm-prospect` (dedup + create rules).