How do you measure whether a company is AI-ready?

Best move: count the AI infrastructure a site exposes, not the AI claims it makes.

Why it works: running AI in production means loading SDKs, calling model APIs, and standing up vector stores and machine-facing endpoints. Those signatures are hard to fake and cheap to read.

Key takeaways

• AI-readiness is measurable from the outside by fingerprinting the AI infrastructure a domain loads and calls, not by scanning its homepage copy.
• Bassethound groups signals into families: model providers, AI SDKs, orchestration frameworks, vector stores, LLM observability, and machine-facing endpoints (llms.txt, MCP, .well-known).
• The ai_readiness score is the count of distinct signal groups hit divided by six, capped at 1.0.
• The verdict has three states: shipping (a machine-facing endpoint is present, or at least three signal groups fire), experimenting (at least one fires), and none.
• A separate icp_signal (hot, warm, cold) translates the same evidence into buyer intent, so a scored list of domains can be ranked directly.

What signals tell you a company is AI-ready?

Six families, each independent. Model providers are the base layer: Anthropic, OpenAI, Gemini, Cohere, and Mistral leave their API hostnames and client code. AI SDKs sit on top: the Anthropic SDK, the OpenAI SDK, and the Vercel AI SDK ship recognizable packages. Orchestration frameworks (LangChain, LlamaIndex, Haystack, CrewAI) signal that a company chains calls rather than making one-off requests. Vector stores (Pinecone, Weaviate, Qdrant, Chroma, Milvus) mean retrieval is in play, which is expensive to stand up and pointless to fake. LLM observability (Helicone, LangSmith, Langfuse) tells you someone is watching cost and quality in production, a strong maturity tell.

The last family carries the most weight: machine-facing endpoints. An llms.txt file (classified standard or technical), an MCP endpoint, or a .well-known AI file means the company built for machine consumers on purpose.

Each family a site hits counts once. The point is breadth. A site that loads a model provider and nothing else is early. A site with a provider, a vector store, and observability is running a real pipeline. Bassethound reads all six in one pass and returns which fired, so you see the shape of the stack, not just a yes or no.

How do you turn those signals into a score?

Count the distinct signal groups that fire, divide by six, and cap the result at 1.0. A domain that hits two families scores 0.33. One that hits five scores 0.83. Hitting more than six groups still caps at 1.0, because past a point extra breadth stops changing the decision.

Counting groups, not individual tools, is deliberate. A company that loads three different vector stores is not three times as ready as one that loads a single store. It has made one architectural choice. Grouping keeps a noisy front end from inflating the number, and keeps the score comparable across sites with different bundle sizes.

The score is a summary, not the whole answer. Bassethound returns it alongside the raw list of which groups fired and the verdict, so you can audit the number yourself. A 0.5 backed by a model provider, a vector store, and observability is not the same 0.5 as one built on a chat widget and two SDKs. Read the components, then trust the score.

What separates shipping from experimenting?

The verdict collapses the evidence into three states. None means nothing AI-related fired. Experimenting means at least one signal group is present, so the company is loading something but you cannot yet tell how deep it goes. Shipping is the state that matters, and it has two independent triggers.

The first trigger is a machine-facing endpoint: an MCP endpoint, a .well-known AI file, or a technical llms.txt. Any one of these flips the verdict to shipping on its own, because standing up an endpoint for machine consumers is a deliberate engineering act, not a snippet you paste into a template. The second trigger is breadth: three or more distinct signal groups firing. A company running a model provider, a vector store, and observability is operating a pipeline, whether or not it published an endpoint.

Either path is enough. The design reflects a belief that depth and intent both count, and that you should not need a company to announce its AI strategy to know it has one. Experimenting and shipping look similar on a homepage. They look different in the stack.

Why measure from the outside instead of just asking?

Because self-report measures marketing, not engineering. Ask a company if it is AI-ready and you will hear yes, because saying yes is free. The infrastructure tells the truth. Loading a vector store, wiring an orchestration framework, or exposing an MCP endpoint costs engineering time, and spending it on a demo makes no sense.

Outside measurement is also fast and neutral. You do not need a sales call, a questionnaire, or vendor cooperation. Bassethound reads any domain keyless, in one call, and returns the same five-layer dossier for a prospect, a competitor, or your own site. That symmetry matters: you can score a list of a thousand domains the same way you score one, then rank them by the icp_signal (hot, warm, cold) that the AI-readiness layer produces.

The tradeoff is that outside measurement sees only what reaches the client. It cannot read a private roadmap or a server-side model call. That is a real limit, covered below, and Bassethound reports it rather than papering over it. What you gain is evidence you can verify yourself, on any domain, without asking permission.

What can outside measurement miss?

Anything that never touches the browser. Detection is a static crawl plus optional JS rendering, so it reads loaded scripts, called hostnames, and published files. A purely server-side inference call, a model request routed through the company’s own proxy, or an internal tool behind auth leaves no client-side trace. None of those show up, and a low score can mean hidden rather than absent.

This is why the verdict is not a verdict on the company. A ‘none’ result says Bassethound found no outside evidence, not that no AI exists. A heavily proxied stack can run serious production AI and still read as quiet from the edge.

Bassethound handles this by reporting gaps honestly. When JS rendering cannot reach a component, or when a signal is ambiguous, the dossier says so instead of guessing. That keeps the score trustworthy: you know what was checked and what could not be reached. For high-stakes calls, treat a low score on a known-technical company as a prompt to look closer, not as a final answer. The measurement is strong on what it can see and explicit about what it cannot.

Bassethound perspective

Most AI-readiness scores are self-report dressed as measurement. They ask the buyer to rate themselves, or they run NLP over a homepage and count how many times “AI” appears. Both measure the marketing budget, not the engineering. We think that is backwards.

Here is the conviction a competitor will dispute: one technical llms.txt or a live MCP endpoint tells you more than a dozen model-provider hits. Loading the OpenAI SDK is table stakes now, and half the internet does it. Publishing a machine-facing endpoint means a team decided that machines, not just people, are legitimate consumers of their product, and engineered for it. That intent is rare, and it correlates with the companies worth talking to.

So Bassethound weights the verdict toward machine-facing endpoints and treats breadth as the fallback path, not the headline. We also refuse to fake certainty. When the crawl cannot see behind a proxy, we say so. A readiness number you cannot audit is worse than no number, because it launders a guess into a metric. Read the stack, weight intent, admit the gaps. That is a measurement you can act on.

Sources

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