What makes a company count as shipping AI?

Best move: count the machine-facing surfaces a company exposes, not the AI language on its homepage.

Why it works: shipping AI leaves infrastructure. An MCP endpoint, a technical llms.txt, or three independent stack signals are expensive to stand up and pointless to fake.

Key takeaways

• Bassethound’s shipping verdict fires on one of two conditions: a machine-facing endpoint is present, or at least three distinct signal groups fire.
• A machine-facing endpoint (an MCP server, a .well-known AI file, a technical llms.txt) counts as shipping on its own, because it exists only to serve automated agents.
• Below the shipping bar the verdict steps down: one or two signal groups mean experimenting, zero means none.
• The ai_readiness score is the count of distinct signal groups hit divided by six, capped at 1.0, so it is a coverage measure, not a quality grade.
• Detection is a static crawl plus optional JS rendering, so purely server-side or proxied AI can stay invisible, and Bassethound flags those gaps rather than guessing.

What are the two conditions that trigger the shipping verdict?

Two conditions, and either one is enough. The first is a machine-facing endpoint. If Bassethound finds an MCP server, a .well-known AI file, or a technical llms.txt (as opposed to the standard, human-oriented variant), the verdict is shipping regardless of anything else. The second is breadth. If three or more distinct signal groups fire, that also clears the bar on its own. The logic is OR, not AND. A company can reach shipping with one MCP endpoint and no detectable SDK, or with three stack signals and no endpoint at all.

Keep the two conditions separate, because they answer different questions. The endpoint test asks whether a company exposes AI to other machines. The breadth test asks whether a company runs enough AI infrastructure that three independent parts of the stack leak at once. Below both, the verdict steps down: one or two groups is experimenting, zero is none. This is a threshold model, not a vibe. You can reconstruct any verdict from the raw signal list, which means you can argue with it. That is the point.

Why does a single machine-facing endpoint count as shipping?

Because a machine-facing endpoint has one audience: other software. A human never types a .well-known AI path or reads a technical llms.txt. An MCP server exists so an agent can call your tools. Publishing one means a company decided its AI surface is stable enough to hand out an address for. That is a production decision, not a demo.

Contrast that with a chat widget or an SDK import. Those can ship behind a coming-soon flag, sit in a staging branch, or load on one unlinked page. An endpoint is live or it is not. Bassethound also splits the two llms.txt flavors here rather than treating them as equal. The standard file is a curated map for human-facing answer engines, and plenty of marketing sites now publish one. The technical variant points machines at real capability, so it counts as an endpoint while the standard file counts as a softer signal. Classification is the work, and Bassethound does it instead of rewarding any llms.txt equally. The endpoint condition stays narrow by design. It rewards companies that moved past experimentation into serving automated consumers, and it refuses to inflate that with cosmetic files.

Which signal groups does Bassethound count toward the threshold?

The AI-readiness layer fingerprints several independent groups. 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). It also watches for llms.txt, MCP endpoints, and .well-known AI files as machine-facing signals.

Each of these is a group, not a single vendor. Loading two OpenAI libraries still counts once. That grouping is what keeps the threshold honest. Three distinct groups firing means AI shows up in three different parts of the stack, which is hard to fake and hard to hit by accident. A company running a model provider plus a vector store plus observability lands at three groups, scores 0.5, and clears the shipping bar on breadth. You cannot game that by stacking five model SDKs, because they collapse into one group. The distinct-group rule is the difference between measuring an AI stack and counting import statements.

How does shipping differ from a high ai_readiness score?

They measure different things and they can disagree. The score is coverage: distinct groups hit over six, capped at 1.0. The verdict is a threshold plus the endpoint override. A company with one MCP endpoint and nothing else scores low (one group, roughly 0.17) yet reads as shipping, because the override fires. A company with two strong groups scores 0.33 and reads as experimenting, however polished those two are.

So do not treat the score as a synonym for the verdict. Use the verdict to sort companies into tiers (shipping, experimenting, none). Use the score to rank within a tier, because it tells you how deep the stack goes. Alongside both, Bassethound emits an icp_signal (hot, warm, cold) that folds the AI-readiness read together with the rest of the five-layer dossier for prioritization. If you are building a target list, the three fields do separate jobs. The verdict tells you who is in production. The score tells you how far in. The icp_signal tells you who to call first. Reading all three at once is the difference between a list and a queue.

What can make a shipping company look like it is not?

Detection is a static crawl with optional JavaScript rendering, and it reads what the front end exposes. Anything fully server-side stays dark. A company can run Claude behind its own API, keep every model call on the backend, proxy vector search through a first-party endpoint, and present a front end with zero third-party AI signatures. That company ships AI, and Bassethound may score it none.

The same holds for AI reached only after login, or gated behind a feature flag your crawl never trips. Bassethound does not paper over this. It reports the gap: which layers it reached, which it could not, and why the read might understate reality. Treat a none verdict on a company you suspect ships as a prompt to look deeper, not proof of absence. Honest external detection names its blind spots, and a fully proxied AI stack is the largest one. The failure mode of every outside-in scanner is a false none on a company that keeps its AI backend private. Bassethound’s answer is not to pretend it can see through the proxy. It is to tell you where the view ends.

Bassethound perspective

Most AI-adoption scanners grade on vocabulary. Find an OpenAI script tag or a chat bubble, mark the company “uses AI,” move on. We think that bar is wrong, and we set ours higher on purpose. A single vendor script is a purchase, not a product. Shipping means a company either exposes AI to other machines (an MCP endpoint, a technical llms.txt) or runs enough of a stack that three independent groups leak at once. One chat widget clears neither test, and it should not.

This is the line a competitor will fight, because a looser definition inflates their coverage numbers and makes every website look AI-ready. Ours makes fewer companies count, and the ones that do are worth the call. We would rather return experimenting with a reason than hand you a shipping verdict that falls apart on the first sales call. Digby sniffs the infrastructure, not the copy. When the trail is thin, we say so, and we tell you which layer we could not reach.

Sources

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