Thesisshipping, experimenting, or ignoring AI
Every Company Is Shipping, Experimenting, or Ignoring AI
There are only three states that matter: shipping AI in production, experimenting with it, or ignoring it. You can tell which from the stack, and you should treat each one differently.
Most AI-adoption talk treats it as a smooth spectrum, which makes it useless. A spectrum gives you a vibe. What you need is a decision. From the outside, every company collapses into three states, and each one is both detectable and actionable: it is shipping, experimenting, or ignoring AI.
The three states
Shipping. The company runs AI in production. Its site exposes the infrastructure that only exists to serve real workloads: a model provider wired into the app, a vector store holding embeddings, LLM observability watching it, or a machine-facing endpoint like a technical llms.txt or a live MCP endpoint. Several signals fire together. This company built something and cannot afford to leave it unmonitored.
Experimenting. One signal, maybe two. A lone model SDK. A single vector store. An llms.txt and nothing behind it. Real, but early. The team is trying things, not running them.
Ignoring. Nothing surfaces. No stack, no endpoints, no signals. Whatever the homepage says, there is no AI infrastructure to find.
Why the line is detectable
The states are not a matter of opinion because production AI is expensive in a way experiments are not. Nobody stands up observability for a demo. Nobody exposes an MCP endpoint by accident. Those are deliberate, load-bearing choices, and they are the signals that separate shipping from experimenting. Bassethound draws the line exactly there: a machine-facing endpoint, or at least three distinct signal groups, means shipping. One signal means experimenting. Silence means none.
The honest limit is real and worth stating: a company running AI entirely server-side can read as ignoring from the outside, because there is nothing client-visible to fingerprint. The right response is to report the gap, not to pretend a missing signal is proof of absence.
Why the verdict beats a number
A readiness score is a sort key. It tells you which domains to look at first. But you do not act on a sort key, you act on a decision, and the three states are the decision. A shipping company is a qualified buyer for AI infrastructure and services, and you reach out about extending what they run. An experimenting company needs a nudge and a proof point. An ignoring company is a different motion entirely, or not a fit yet. Same list, three plays.
That is why the AI-readiness verdict, not just the score, rides at the top of the dossier, and why the icp_signal sits next to it. The number ranks. The verdict tells you what to say.
Frequently asked questions
Why three buckets instead of a score?
A score compresses a decision into a number you still have to interpret. The verdict names the decision: a shipping company gets a different message than an experimenting one. Buckets are what you act on; the score just sorts within them.
Can you really detect the difference from outside?
Largely, yes. Production AI leaves fingerprints that experiments do not: observability, a live MCP endpoint, several signal groups firing together. Bassethound reads those and draws the line.
What about companies running AI entirely server-side?
That is the honest edge. Fully server-side or proxied stacks can read as none from the outside. Bassethound reports what it could not see rather than pretending the absence of a signal is proof of absence.