How do you score AI adoption from the outside?

Best move: count what the stack exposes to the network, then normalize it. Do not grade the pitch deck.

Why it works: AI infrastructure loads clients, calls named APIs, and publishes machine-facing files. The product needs those signals to run, so they survive minification and outlast the marketing copy.

Key takeaways

• An outside-in AI adoption score is a normalized count of distinct signal groups that fire, not a subjective read of a company’s messaging.
• Bassethound’s ai_readiness score divides the number of distinct signal groups hit by six and caps the result at 1.0.
• The score resolves into a three-state verdict: shipping, experimenting, or none.
• A machine-facing endpoint (MCP, a .well-known AI file, or a technical llms.txt) forces a shipping verdict on its own, even below three signal groups.
• Server-side or fully proxied AI components stay invisible to an external scan, so the score is a floor, not a ceiling. Bassethound reports the gaps.

What signals feed an outside-in AI adoption score?

An outside-in score reads from the AI stack a domain exposes to the network. Bassethound groups that evidence into signal categories, and each category that fires counts once toward the score.

The categories: model providers (Anthropic, OpenAI, Gemini, Cohere, Mistral), AI SDKs (the Anthropic SDK, the OpenAI SDK, the Vercel AI SDK), orchestration frameworks (LangChain, LlamaIndex, Haystack, CrewAI), vector stores (Pinecone, Weaviate, Qdrant, Chroma, Milvus), and LLM observability (Helicone, LangSmith, Langfuse). Customer-facing AI widgets count too (Intercom Fin, Sierra). So do the machine-facing publications: an llms.txt file (classified as the standard content variant or a technical variant), an exposed MCP endpoint, and .well-known AI files.

A company loading the OpenAI SDK, calling a Pinecone host, and publishing an llms.txt file lights three distinct groups. That is enough on its own to cross the shipping threshold. Ten model-provider references in one bundle still count as one group, because breadth inside a category does not prove more adoption than depth. The score rewards range across the stack, not repetition within a slice of it.

How does the score become a verdict?

The raw score is a fraction: distinct signal groups hit, divided by six, capped at 1.0. A domain that lights four groups scores 0.67. One that lights every group Bassethound tracks still tops out at 1.0.

The verdict compresses that number into three states you can act on. A domain earns shipping if it publishes a machine-facing endpoint (an MCP server, a .well-known AI file, or a technical llms.txt), or if three or more signal groups fire. It earns experimenting when at least one group fires but the shipping bar is not met. It earns none when nothing fires.

The machine-facing shortcut matters. A team that stands up an MCP endpoint or ships a technical llms.txt has built infrastructure for machines to consume, not humans to read. That is a stronger commitment than loading a single SDK, so it clears the shipping bar on its own, even at a low group count. The three-group path exists for teams whose adoption is broad but human-facing. Both routes land on the same verdict, from different evidence.

What can an outside-in score never see?

Plenty. The score measures what a domain reveals to an unauthenticated reader, and a well-built AI backend can reveal almost nothing.

Bassethound runs a static crawl plus optional JavaScript rendering. That surfaces server-rendered SDK imports, API hostnames in client code, published machine files, and widgets that mount in the browser. It does not surface a model call that happens entirely server-side, a vector query behind your own API gateway, or an orchestration layer that never ships a byte to the client. If your AI runs through a reverse proxy under your own domain, the trail can go cold.

So the score is a floor, not a ceiling. A none verdict means no signals reached the surface, not that no AI exists behind it. Bassethound reports these gaps in the dossier rather than papering over them, because a confident wrong answer is worse than a marked unknown. Read a low score as “nothing visible from outside,” and treat the verdict as evidence of exposure, not proof of absence.

How is this different from a company’s self-reported AI claim?

A self-reported claim costs one line of copy. “AI-powered” on a homepage requires no model, no SDK, and no infrastructure. An outside-in score ignores that line and reads the stack underneath it.

The gap between the two is the whole point. A company can write “built on AI” for free, but it cannot fake a loaded Pinecone client, a live MCP endpoint, or a published technical llms.txt without building on them. Those signals are load-bearing. They exist because the product needs them to run, which is why they are expensive to fake and pointless to fake.

This inverts the usual trust order. A high self-reported claim paired with a none verdict reads as AI-washing. A modest claim paired with a shipping verdict reads as a team that ships more than it markets. The score does not tell you what a company says about its AI. It tells you what the company had to build to make the AI work.

What does the icp_signal add on top of the score?

The score measures adoption. The icp_signal translates that into whether the company is worth your time.

Bassethound emits an icp_signal of hot, warm, or cold alongside the ai_readiness score and verdict. Adoption and fit are not the same axis. A team shipping AI in production might be a perfect prospect for one seller and a poor one for another, depending on what you sell. The verdict answers “do they build with AI.” The icp_signal answers “do they match the profile you are hunting.”

In practice you read them together. A shipping verdict with a hot signal is a lead worth a warm intro. A shipping verdict with a cold signal is a well-built company you have no angle into. An experimenting verdict with a hot signal is a team early enough to shape. Because both come back in one keyless call, you can score and qualify a domain in the same pass, without stitching two tools together.

Bassethound perspective

Here is the line we will defend: a homepage keyword scan is not an AI-readiness score, and neither is a self-reported maturity survey. Both measure what a company is willing to say. Only the stack measures what it built.

Most tools in this space grade the story. They crawl for “AI-powered” and “GenAI” in the marketing copy, or they ask a sales contact to rate their own maturity on a five-point scale. That rewards the loudest marketer and the most optimistic respondent, which is backwards. The teams shipping the most AI are often the quietest about it, because they are busy building instead of blogging.

We also hold that one machine-facing endpoint outweighs a dozen “AI-first” headlines. An MCP server or a technical llms.txt is infrastructure a team stood up for machines to consume. You do not ship that by accident, and you do not ship it for the pitch deck.

The honest cost of our position: we miss AI that never touches the client. We would rather return a marked unknown than a confident guess. A score you can trust has to admit what it could not see.

Sources

• Model Context Protocol: https://modelcontextprotocol.io
• llms.txt proposal: https://llmstxt.org
• LangSmith documentation: https://docs.smith.langchain.com
• Pinecone documentation: https://docs.pinecone.io
• Helicone documentation: https://docs.helicone.ai