How do you qualify a prospect by their AI stack?

Best move: rank prospects by the AI signals their front end loads and serves, not by what their homepage claims.

Why it works: a real AI stack costs an engineering team a sprint and is pointless to fake, so it separates companies building agents from companies writing about them.

Key takeaways

• Qualifying by AI stack means fingerprinting the signals a domain exposes (model providers, SDKs, orchestration, vector stores, observability, MCP endpoints, llms.txt), then mapping them to an ICP tier.
• Bassethound scores ai_readiness as the count of distinct signal groups hit, divided by six and capped at 1.0.
• The verdict is shipping when a machine-facing endpoint is present or at least three signal groups fire, experimenting when one fires, and none when the crawl finds nothing.
• A published MCP endpoint or a technical llms.txt is a stronger buying signal than any headline, because it is written for machines and built by engineers.
• Purely server-side or fully proxied AI can stay invisible, so Bassethound reports a none verdict as no visible AI, not no AI.

Which AI signals predict a qualified prospect?

Bassethound’s AI-readiness layer fingerprints a fixed set of signals from the outside. 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). Embedded AI widgets (Intercom Fin, Sierra). And machine-facing files: llms.txt, MCP endpoints, .well-known AI files.

Not every signal carries the same weight. A model provider in a script tag tells you someone wired an LLM into the product. A vector store tells you they built retrieval, which is expensive to build and pointless to fake. A served MCP endpoint tells you they want machines to call them, the strongest tell of all. Rank by how far down the stack a signal sits: infrastructure beats a chatbot bubble, and a served endpoint beats infrastructure.

The signals cluster into groups, and Bassethound counts distinct groups rather than raw hits. A site loading three OpenAI scripts still scores as one provider group. That keeps a noisy vendor from inflating a thin stack, and it keeps the score honest when you run it across a whole list.

How does an AI-readiness score map to an ICP tier?

The score is mechanical. Count the distinct signal groups a domain hits, divide by six, cap at 1.0. On top of the score sits a verdict. Shipping means a machine-facing endpoint (MCP, .well-known, or a technical-grade llms.txt) is present, or at least three signal groups fire. Experimenting means at least one group fires. None means the crawl found nothing visible.

The verdict drives an icp_signal of hot, warm, or cold. A shipping domain with a served endpoint is hot: it has the budget, the engineering, and the intent to integrate. An experimenting domain is warm: real interest, an unfinished build, a conversation worth having. A cold domain shows no budget and no build, so it does not earn a rep this quarter.

This is the part manual research gets wrong. A human reads a homepage, sees “AI-powered,” and scores it hot. The homepage is marketing. The stack is truth. By scoring the groups a domain loads and serves, you rank a list by how ready each account is to buy, not by how loud its copy is. Same schema every row, so the sort is trivial.

What does a machine-facing endpoint tell you that a homepage cannot?

A homepage is written for humans and tuned by marketing. A machine-facing artifact is written for code and tuned by engineers. That gap is the qualification.

Three artifacts matter. An MCP endpoint means the company built a way for agents to call its product, which few companies do before they have a real AI roadmap. A technical llms.txt (the kind that lists API routes and structured docs, not a marketing blurb) means someone is optimizing for machine consumption. A .well-known AI file signals the same intent at the protocol layer. Bassethound classifies llms.txt as standard or technical for this reason: the technical variant is a far stronger tell.

Any one of these flips the verdict to shipping on its own, no matter how thin the rest of the stack looks, because the intent is unambiguous. A company that exposes an endpoint for machines to consume has decided its future includes agents. That is the account you call first. A homepage claim costs a copywriter an afternoon. An endpoint costs an engineering team a sprint, and no one ships one to look good in a demo.

How do you avoid false negatives from server-side AI?

You accept that you cannot see everything, and you design around it. Bassethound reads a domain by static crawl plus optional JavaScript rendering. That surfaces client libraries, script hostnames, served files, and rendered widgets. It does not surface a model call that runs on a backend the browser never touches, or a stack hidden behind a full proxy.

So a none verdict is not proof of no AI. It is proof of no visible AI. Bassethound reports that distinction in the dossier’s gaps rather than papering over it, because a confident false negative is worse than an honest unknown. A rep who trusts a fabricated cold skips a real buyer.

Handle it two ways. First, treat none as low-priority, not disqualified, and re-check on a cadence, since server-side stacks often expose a widget or an llms.txt later. Second, weight the positive signals you do get. A visible vector store or a served endpoint is high-confidence, because those are hard to hide by accident. Absence is soft evidence. Presence is hard evidence. Qualify on the hard evidence and hold the soft evidence loosely.

Can you run this qualification at list scale?

Yes, and that is the point. Bassethound is stateless and read-only, and needs no key of yours. You pass a domain, you get the five-layer dossier back in one call, and nothing about the previous call changes the next. No crawl to schedule, no state to manage.

That shape fits a list. Point it at every domain in a lead export and you get an ai_readiness score, a verdict, and an icp_signal for each, in the same schema every time. Sort by icp_signal, work the hot rows first, drop the cold ones, and re-run the middle next quarter. The AI-readiness layer arrives correlated with the other four layers (tech stack, infrastructure, firmographics, security), so you qualify on AI intent and account fit in the same pass instead of stitching four tools together.

The stateless design matters for trust as much as speed. Because Bassethound only reads, it never touches the prospect’s systems and leaves no trace beyond a normal page fetch. You are reading public surface, the same bytes any browser would load. That keeps a large qualification run cheap, repeatable, and clean.

Bassethound perspective

Intent-data vendors sell you “AI intent” scored from content: press releases, job posts, homepage copy, review-site mentions. We think that signal is mostly noise. A company that publishes a blog post about AI has told you what its marketing team wants you to believe. A company that loads Pinecone, serves an MCP endpoint, and ships a technical llms.txt has told you what its engineers built. Those are different companies, and the second one is worth a rep’s Tuesday.

So Bassethound qualifies on the stack, and only the stack. We will not score a prospect up for saying “AI-first” in a headline, and we will not score one down for a quiet marketing page when the front end is loading a vector client. We would rather return an honest none (with a note that we could not see the backend) than a confident tier we invented. Vendors who sell intent-by-content will call this too narrow, because narrow is inconvenient for a data business priced per signal. We think narrow and true beats broad and fabricated. Qualify on what a company built, not on what it announced.

Sources

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