Company search

The capability contract describes the public input and result. This page preserves reusable workflow details. It does not define a second input or result contract.

Product behavior

Company Search answers which companies match a description, supported account filters, or supplied identities. It returns selectable company references and observed display fields. It does not enrich, score or write CRM records. The Companies surface carries selected refs into Company Enrich or People Search through a separate user action.

The earlier enrich: True default is superseded. Search has no enrich, enrich_fields or depth parameter. Sonar remains a legacy surface during migration; it is not the new capability's product name.

Execution stages

The workflow has two paths. A request that supplies companies runs the waterfall tool. Every other request runs the finder Agent.

company.search capability (root workflow)
  -> supplied companies?
       yes -> waterfall tool (tool id `company.search`)
                -> resolve supplied identities
                -> check the cache, then eligible providers in cost order
                -> merge duplicates, apply deterministic filters and the limit
       no  -> finder Agent (gpt-5.4) with company.search_exa
                -> write a checklist of hard requirements and a reject list
                -> write limits: the requirements one fact can check
                -> write Exa queries from the description and the filters
                -> check each company against the checklist; reject a contradiction
                -> check the final list against the checklist again
                -> answer domains, summaries, evidence and unconfirmed requirements
           -> company.compile_results
                -> read each domain from the company cache
                -> drop a company whose cached fact contradicts a filter or a limit
                -> put the companies with the fewest unconfirmed requirements first
                -> build the frozen output; the model-written summary becomes the company description field
  -> persist tenant-owned Run output

The public sources are supplied and provider_discovery; a caller may request both. provider_discovery is one product source, not a request to use one provider. The supplied-only tool keeps its unmetered grant.

Sources

company.search_exa writes each company it finds to the company cache. The compile step reads every row from the cache, so each fact comes from Exa. Only the summary comes from the model. A domain the cache does not hold counts as unresolved. Exa company search answers the head office, the employee count, the founding year, the latest funding round with its date and amount, the total funding and the annual revenue in US dollars. It also answers highlights: page text that Exa selects for the query. The round, its date, the amount and the revenue reach the cache in canonical form. The total funding and the highlights reach the Agent only. The model does not know today's date, so the tool also states the age of each round in months. Exa company results carry no industry. The Agent judges an industry from the description, and no code check reads it. The finder Agent rejects agencies, directories, investors, universities and acquired companies, unless the request asks for them. A request runs one path, never both. The workflow ceiling is 450 cents. The Agent path spends at most 150 cents, its own Agent ceiling. The waterfall path spends at most 400 cents, the ceiling of the waterfall tool.

Identity resolution

Use the shared domain normalization rule. Use company LinkedIn when a valid company has no domain. A company name is evidence, never a deduplication key. Conflicting canonical keys require an explicit conflict result. An unresolved row stays visible in diagnostics. Do not silently drop a domainless company that has a valid LinkedIn identity. Search returns canonical IDs only when known. It does not create an Intelligence row merely to obtain a selectable ref.

The gate

The waterfall path has a deterministic gate. The gate applies supported filters to the merged observations. Discovery sources may fill the remaining target before this gate.

The finder Agent path has a code check in company.compile_results. It reads the cached facts of each company the Agent selected. It drops a company when a fact contradicts a filter the caller set, or a limit the Agent wrote. The limits are the head office country, the latest funding round, the age of that round in months, the employee count, the annual revenue in US dollars and the founding year. The age limit reads intel_companies.funding_date. A limit that code cannot read does not apply. A missing fact never drops a company. Customer group and business type have no stored fact, so only the Agent checks them. Keep a row when a field is unknown and report unknown_filter_value. Drop a row only when an observed value contradicts a filter. Record filter_mismatch and funnel counts. A row with unknown size does not become a verified size match. The closed filter contract rejects unsupported values. Free-text descriptions can also guide the semantic providers without becoming a verified filter.

Deduplication, gates and result limits use stable ordering. A replay cannot choose a different winning observation. Keep per-source status and unresolved counts when one source fails. Total source failure is not a successful empty roster. The design scenarios cover these cases.

Reuse from Signals

Signals owns signal research and scoring. It may pass discovered candidates through the supplied search source. It then calls Company Enrich explicitly when fields are needed. This composition preserves signal discovery without adding a web source or automatic enrichment to Company Search.

Legacy diagram

The diagram below records the superseded automatic-enrichment design. Its enrichment step, four-source claim and trailing scoring path are not the current contract.