How do you find companies that are building with AI?

Best move: start from the deployed stack, not the pitch deck. Fingerprint what each domain loads and exposes, and let the signals sort builders from talkers.

Why it works: companies that ship AI have to load real client code and call real endpoints, and those signatures survive minification. Marketing claims cost nothing and prove nothing.

Key takeaways

• You find AI builders by fingerprinting deployed signals (model SDKs, orchestration, vector stores, LLM observability, machine-facing endpoints), not by scanning marketing copy.
• Bassethound scores each domain by counting distinct signal groups, out of 6, capped at 1.0, then returns a verdict of shipping, experimenting, or none.
• A machine-facing endpoint (MCP, a .well-known AI file, or a technical llms.txt) alone earns a shipping verdict, because it proves the company built for agents on purpose.
• The dossier is keyless, stateless, and read-only, so you can loop a domain list into a prioritized adopter list without provisioning access.
• Purely server-side or fully proxied AI stays invisible to outside-in detection, and Bassethound reports those blind spots as gaps rather than scoring them as absence.

What separates a company building with AI from one that just markets it?

Marketing pages say “AI-powered.” That phrase costs nothing and proves nothing. A company that ships AI has to load real code and call real endpoints, and those leave a trail. Model-provider SDKs (Anthropic, OpenAI, Gemini, Cohere, Mistral) show up in loaded scripts. Orchestration frameworks (LangChain, LlamaIndex, Haystack, CrewAI) carry recognizable client names. A vector store (Pinecone, Weaviate, Qdrant, Chroma, Milvus) is backend infrastructure that costs money to run and is pointless to fake. LLM observability (Helicone, LangSmith, Langfuse) means someone is watching tokens in production. The strongest tell is a machine-facing endpoint: a live MCP server, a .well-known AI file, or a technical llms.txt. Those exist so agents can consume the site, which means the company built for the AI-native web on purpose. Bassethound scores each domain by counting distinct signal groups, out of 6, capped at 1.0, then assigns a verdict. Three or more groups firing, or any machine-facing endpoint present, reads as shipping. One group is experimenting. Nothing is none. You get a fact about the deployed stack, not a paraphrase of the homepage.

How do you turn a domain into a build-with-AI verdict?

Run the domain through the AI-readiness layer and let the signal count decide. Bassethound crawls the site, renders JavaScript when the signals call for it, and fingerprints each group it can reach. The score is the count of distinct groups hit, out of 6, capped at 1.0. The verdict maps intent, not vanity. A site earns shipping when a machine-facing endpoint is present (MCP, a .well-known AI file, or a technical llms.txt) or when at least three signal groups fire. It earns experimenting when at least one fires. It earns none when the crawl comes back empty. The endpoint rule matters. A company that stood up an MCP server did work a marketing team cannot fake, so one such signal outranks three buzzwords. The verdict is deterministic, so the same domain returns the same answer, and you can diff two crawls over time to watch a company move from none to experimenting to shipping. That progression is often the buying window, because the jump to shipping is when a team goes from a prototype to something it has to fund and maintain.

How do you go from one domain to a list of AI-forward companies?

Bassethound is stateless and per-domain, so a list is a loop. Start with a domain set: your CRM, a conference attendee export, a funding-round scrape, a directory of a category you sell into. Call the analyze step on each domain. Keep the ones whose verdict is shipping or experimenting, and sort by ai_readiness score and icp_signal. Because each call is keyless and read-only, you run the whole list without provisioning access or worrying about write side effects. The output per domain is structured: the score, the verdict, the specific signal groups that fired, and the ICP signal. That structure is what makes the list actionable. You are not left with “this company might use AI.” You get “this company loads the OpenAI SDK, runs Pinecone, and exposes an MCP endpoint, verdict shipping, icp_signal hot.” Rank the shipping-and-hot rows to the top and you have a prioritized outbound list built from deployed evidence rather than intent-data guesswork.

Which AI adopters does outside-in detection miss?

Honest answer: the ones that keep everything on the server. Bassethound reads what the front end loads and calls, plus static files and endpoints. A company that runs its model calls entirely server-side, behind its own API, exposes no client SDK. A fully proxied setup, where every third-party call routes through a first-party domain, hides the vendor names. A closed product behind a login wall shows only its marketing shell to an unauthenticated crawl. In each case the AI is real and the outside-in signal is thin. Bassethound does not paper over this. It reports the gaps in the dossier: what it reached, what it rendered, and what it could not see. That honesty is the point. A false “none” you treat as fact is worse than a labeled gap you can go verify by hand. So read a low score on a company you suspect is AI-heavy as a prompt to look closer, not as a verdict that they build nothing. The tool measures the observable surface, and it tells you where that surface ends.

How do you rank the list by ICP fit?

Use the icp_signal. Each domain comes back tagged hot, warm, or cold, so a raw detection list becomes a queue. The ai_readiness score tells you how much AI a company ships. The ICP signal tells you whether that pattern matches who you sell to. A vector-store vendor selling to teams building RAG wants domains that load an orchestration framework and a vector store. An observability vendor wants domains already running a model provider but no LLM observability, since that gap is the pitch. The same crawl serves both, because the signal groups are itemized, not collapsed into a single number. Two domains can tie at a 0.67 score and still split on fit: one loads LangChain and Pinecone (your buyer), the other runs an Intercom Fin widget and a technical llms.txt (a support deployment, not your buyer). Sort hot before warm, break ties by score, and work the top of the list first. Then re-crawl on a cadence. A company that flips from experimenting to shipping just entered its build phase, which is often when budget appears.

Bassethound perspective

Intent-data vendors will sell you “AI adoption” signals pulled from job posts, funding rounds, press releases, and web-traffic co-occurrence. We think most of that is noise dressed as signal. A req for an ML engineer tells you a company wants to build with AI, not that it has. A funding headline tells you a company has money, not a stack. Those signals lag the real work by quarters and reward the companies best at publicity. The durable signal is the deployed stack. A loaded Pinecone client, a live MCP endpoint, an OpenAI SDK in the bundle: the company voted with its build, and faking that vote is expensive and buys nothing. Our conviction, which the intent-data crowd will dispute, is that a running vector store is worth more than ten hiring signals and a press mention combined. We would rather return a smaller, harder list of companies whose code proves they ship than a large soft list of companies whose marketing says they might. Bassethound reads the stack. When it cannot see the stack, it says so, and it never launders a guess into a fact.

Sources

• Model Context Protocol specification: https://modelcontextprotocol.io
• llms.txt standard: https://llmstxt.org
• Pinecone documentation: https://docs.pinecone.io
• Anthropic API documentation: https://docs.anthropic.com
• OpenAI platform documentation: https://platform.openai.com