Can AI-readiness be used as an ICP filter?

Best move: filter on the stack a prospect runs, not on what its sector or headcount implies.

Why it works: AI-readiness is an observed property of the front end, so a verdict and an ICP signal give you a sortable field that firmographics cannot fake.

Key takeaways

• AI-readiness becomes an ICP filter the moment you reduce a detected stack to two machine-readable fields: a verdict (shipping, experimenting, none) and an ICP signal (hot, warm, cold).
• The verdict is deterministic. “Shipping” fires when a machine-facing endpoint (MCP, a .well-known AI file, or a technical llms.txt) is present, or when at least three distinct AI signal groups hit.
• The ai_readiness score is a count of distinct signal groups (model providers, SDKs, orchestration, vector stores, observability, AI widgets) divided by six and capped at 1.0.
• AI-readiness predicts fit for an AI-native product better than industry or headcount, because it measures what a company runs rather than who it is.
• The filter is honest about blind spots. Server-side or fully proxied AI leaves no client trail, so a cold result is low-confidence absence, not proof.

What does an AI-readiness verdict measure?

The verdict collapses a lot of detection into one of three states you can filter on: shipping, experimenting, or none.

Underneath it, the AI-readiness layer counts distinct signal groups that fire on the domain. Model providers (Anthropic, OpenAI, Gemini, Cohere, Mistral). AI SDKs (Anthropic SDK, OpenAI SDK, Vercel AI SDK). Orchestration frameworks (LangChain, LlamaIndex, Haystack, CrewAI). Vector stores (Pinecone, Weaviate, Qdrant, Chroma, Milvus). LLM observability (Helicone, LangSmith, Langfuse). AI support widgets (Intercom Fin, Sierra). Each group that fires adds one to the count.

The score is that count divided by six, capped at 1.0. The verdict then reads the same evidence with a rule you can reason about. “Shipping” means a machine-facing endpoint is present (an MCP endpoint, a .well-known AI file, or an llms.txt classified as technical), or at least three signal groups fire. “Experimenting” means at least one group fires. “None” means the crawl found nothing.

That is what makes it a filter and not a vibe. You are not eyeballing a homepage. You are sorting a list on a field with a defined threshold, which means two people running the same domain get the same answer.

How does the ICP signal map to a filter?

Alongside the verdict, the layer emits an icp_signal with three values: hot, warm, cold. That is the field you sort a list on.

Think of the verdict as the technical truth and the ICP signal as the go-to-market read on it. Hot lines up with strong, machine-facing evidence a company builds with AI. It is the account you route to a rep this week. Warm covers the early stack: a provider SDK loaded, maybe one framework, nothing wired for machines yet. That account belongs in a nurture track, not the trash. Cold means the crawl surfaced nothing to act on.

The value of a three-value signal is that it maps cleanly onto how a pipeline already works. Hot goes to outbound now. Warm goes to a sequence that revisits in a quarter. Cold drops out of the AI-native motion. You do not need a data-science project to use it. You need one column you can filter and one you can sort, and the layer hands you both.

Because the signal derives from the same evidence as the verdict, it stays auditable. When a rep asks why an account scored hot, you point at the endpoint or the signal groups that fired, not at a black-box propensity model.

Why filter on AI-readiness instead of firmographics?

Firmographics answer “who is this company.” Industry, headcount, funding, region. Useful, and completely blind to whether a company runs the stack your product depends on.

Two companies can share an industry code, a headcount band, and a funding stage, and one ships a retrieval pipeline on Pinecone and LangChain while the other has never loaded a model SDK. Firmographic filtering treats them as identical. An AI-readiness filter separates them, because it reads the front end for the exact signatures that predict fit.

This matters most for AI-native sellers: infra, observability, eval tooling, agent platforms. Your buyer is defined by behavior, not by SIC code. A vector-store vendor cares that a prospect already embeds and queries at scale. An observability vendor cares that LLM calls exist to observe. Headcount tells you none of that.

The other advantage is freshness. Firmographic records lag reality by weeks or quarters. An AI-readiness read reflects the live site at crawl time. When a company ships an MCP endpoint or swaps in a new provider SDK, the signal moves with the deploy, not with the next data refresh. You are filtering on the present tense.

Use firmographics to bound the universe. Use AI-readiness to rank inside it.

What does this filter miss, and how do you account for it?

Detection is a static crawl plus optional JS rendering. That reaches a lot, and it does not reach everything.

Anything that runs purely server-side stays invisible. If a company calls Anthropic or OpenAI from its backend and never ships an SDK to the browser, the client-side read finds no provider signal. Fully proxied setups behave the same way: traffic routed through a first-party gateway hides the vendor hostname. In both cases the honest answer is “not observed,” not “not present.”

Bassethound reports these gaps rather than papering over them. A cold result carries less certainty than a hot one, because absence of a client-side signal is weaker evidence than presence of one. Treat cold as “no client-side trail found,” and treat it as a reason to look closer on high-value accounts, not to discard them outright.

The practical rule: filter aggressively on hot, because presence is strong evidence, and treat cold as low-confidence on your top-of-list targets. A machine-facing endpoint, an SDK signature, or a named API hostname is expensive to fake and pointless to fake, so when it fires you can trust it. The failure mode of this filter is a false negative on a server-side shop, not a false positive on a company that ships nothing. Design your workflow around that asymmetry.

How do you run this across a whole list?

The layer is keyless on the free tier, stateless, and read-only, which is what makes list-scale filtering practical.

One call takes a domain and returns the full five-layer dossier, AI-readiness included. There is no key to rotate and no session state to carry between calls. You feed domains in, you get verdicts, scores, and ICP signals out. Because every call is independent, you can fan out across a list without worrying about ordering or shared state.

The workflow is short. Start with a firmographic list to bound the universe. Run each domain through the read. Keep three columns: verdict, ai_readiness score, and icp_signal. Sort on the ICP signal, break ties on the score, and route hot to outbound, warm to nurture, cold to a closer look before you drop it.

Read-only matters here too. The filter never touches the prospect. It observes the public front end and correlates the signals, so nothing you run leaves a footprint on the target. You are qualifying accounts from the outside, at the pace your list demands, on evidence you can point a rep at.

Bassethound perspective

Intent vendors sell “AI-readiness” scores built from job postings, press mentions, funding rounds, and web-visit surges. We think that is measuring the noise and calling it the signal. A company hiring an ML engineer is not ready. A company that shipped a retrieval pipeline is. Those are different facts, and the second one is the only one that predicts whether your product fits.

Our conviction, which the intent-data industry is built to dispute: a hiring signal or a press hit is a proxy for readiness, and the running stack is the readiness. When Bassethound scores an account hot, it is because an MCP endpoint answered, or a vector-store client loaded, or three signal groups fired together. That is evidence you can inspect, not a propensity number you have to trust.

We would rather return a smaller, harder list than a large, soft one. So we filter on what the front end loads and calls, we cap the score at the six groups we can verify from outside, and we flag what a static crawl cannot see. An ICP filter is only worth running if you can defend every hot account to the rep who has to work it. That is the bar we build to.

Sources

• Model Context Protocol specification: https://modelcontextprotocol.io
• llms.txt proposal and format: https://llmstxt.org
• Pinecone documentation: https://docs.pinecone.io
• LangChain documentation: https://python.langchain.com