The Complete Guide to AI-Readiness Detection

For a decade, the useful question about a company was “what is it built on?” Now there is a sharper one: “is it actually shipping AI?” The answer predicts who buys AI infrastructure, tooling, and services, and unlike a homepage headline, it can be read from the outside if you know where to look. This guide is how to look.

Why AI-readiness detection matters now

Every company claims to be AI-powered. The claim is noise, because it costs a sentence. What separates the companies running AI from the ones talking about it is infrastructure, and infrastructure is expensive to fake. A team that has stood up a vector store and wired in observability is shipping AI whether or not it says so, and a landing page with an AI headline and nothing behind it is not.

For anyone selling into this market, that distinction is the whole game. A company shipping AI in production has the budget, the problems, and the intent that AI products solve. Detecting AI-readiness turns a raw domain into a qualified, or disqualified, prospect, before a human reads a word.

What AI-readiness measures, and what it does not

AI-readiness measures adoption you can verify, not intent you take on faith. A company is AI-ready to the degree its running software depends on AI infrastructure, and that dependency shows up as artifacts a crawler can see.

It does not measure quality, scale, or revenue. A site can load a vector store and still ship something small. But the presence of the stack rules out the most common false positive: a company that wrote “AI-powered” on the homepage and wired up nothing. Detection reads the second thing, the build, not the story.

The six signal groups

Bassethound groups the AI stack into distinct signal families, each a different kind of evidence:

• Model providers. The LLM a company calls: Anthropic, OpenAI, Gemini, Cohere, Mistral. Evidence that a team is talking to a model at all.
• AI SDKs. Client libraries like the Anthropic SDK, the OpenAI SDK, and the Vercel AI SDK, loaded in the app.
• Orchestration frameworks. LangChain, LlamaIndex, Haystack, CrewAI. A sign the team is building chains or agents, not one-off calls.
• Vector stores. Pinecone, Weaviate, Qdrant, Chroma, Milvus. The strongest single tell of retrieval in production, because a vector database exists to serve retrieval.
• LLM observability. LangSmith, Helicone, Langfuse. The most telling of all, because you only monitor what you run in production.
• Machine-facing endpoints. A technical llms.txt, a .well-known AI file, or a live MCP endpoint. These exist to serve agents and tools, which is a deliberate, load-bearing choice.

Read together, these sketch how deep the adoption runs. A model provider alone is a hint. A model provider plus a vector store plus observability is a RAG stack under active monitoring.

How detection works

Detection is a crawl, not a survey. Bassethound loads the site and reads three kinds of evidence: package and client names in the scripts, API hostnames in network calls, and initialization patterns specific to each tool. A managed service answers at its own domain, so a call to a named vector-store or model-provider endpoint is hard to mistake for anything else.

Some of this is visible in static HTML, especially server-rendered imports and hostnames. Some of it only appears after the page runs in a browser, when a client initializes its connections. Bassethound decides whether to render based on what the first pass finds, and records any rendering gaps in the dossier. A static-only result that says “no vector store” means “none visible without rendering,” not “none exists,” and the output says which.

The score and the verdict

The score is deliberately blunt. Bassethound counts the distinct signal groups a domain hits, divides by six, and caps the result at 1.0. Hit one group and you score around 0.17, hit three and you are at 0.5, hit six and you are at 1.0. Grouping matters: loading the OpenAI SDK three ways is not three times as AI-ready as loading it once, so the model-provider group fires once regardless.

The verdict is the decision the score feeds. It is shipping when a machine-facing endpoint is present, or when at least three distinct signal groups fire. It is experimenting when at least one group fires but the shipping bar is not met. It is none when nothing surfaces. The split is opinionated on purpose: a team that exposed an MCP endpoint made a different commitment than one that dropped a model call into a contact form, and the verdict refuses to blur them.

Reading llms.txt and MCP endpoints

The machine-facing signals deserve their own note, because they are the strongest and the most misread. A standard llms.txt is a human-friendly summary of a site, close to a sitemap for models. It is cheap to add and says only that a company has heard of AI. A technical llms.txt points to real endpoints and specs, and that is a different animal. Bassethound classifies the two, so a shallow file does not inflate a score.

A live MCP endpoint is the clearest tell of all. Exposing tools to agents over the Model Context Protocol is deliberate and load-bearing, and it alone clears the shipping bar even when the group count is low. Treating any llms.txt as proof of AI adoption is exactly the mistake that makes shallow readiness scores disagree with reality.

The honest limits of external detection

External detection reads what touches the browser or leaves a named call. A company running its entire AI stack server-side, behind its own API with no client-visible signature, can read as none from the outside. That is the real edge of the method, and the right response is to name it. Bassethound reports what it could not reach rather than implying full coverage, so a none verdict is “nothing visible,” not a claim that nothing exists.

Stated plainly: detection is strong evidence when signals are present and weak evidence when they are absent. Read it that way.

How to detect AI-readiness at scale

To turn this into a repeatable motion inside an agent or a pipeline:

1. Start from a domain. All you need is the company’s domain. The free tier is keyless, no API key required.
2. Call sniff_domain. Point Bassethound at the domain and request the AI-readiness layer, or the full five-layer dossier if you want the correlated read.
3. Read the verdict first, the score second. The verdict (shipping, experimenting, none) is the decision. The score sorts within a bucket.
4. Inspect the signal groups. The specific tools, a vector store here, observability there, are what you reference when you reach out.
5. Correlate with the ICP signal. The icp_signal translates the read into buying intent, so you can filter a domain list down to fits.
6. Re-run when it matters. AI stacks move fast. Re-run it and you read the domain again rather than a prebuilt corpus.

Turning the verdict into action

The point of detection is not a number, it is a next move. A shipping company is a qualified buyer, and you open with the specific stack it runs. An experimenting company needs a nudge and a proof point. An ignoring company is a different motion, or not a fit yet. Same list, three plays, sorted by a signal you can trust because it reads the build instead of the story.

That is AI-readiness detection done deeply: not a homepage scan, but a correlated read on what a company runs, and a verdict you can act on.