How can you tell if a company's AI is real or just marketing?

Best move: read the stack the site loads and the endpoints it publishes, not the words on the homepage.

Why it works: real AI is infrastructure. Using a model, a vector store, or an agent framework means loading its client and calling its API, and those signatures survive minification while marketing copy leaves none.

Key takeaways

• Real AI leaves infrastructure signatures (model SDKs, vector-store clients, orchestration frameworks) that a marketing page cannot fake for long.
• A machine-facing endpoint (MCP, a .well-known AI file, or a technical llms.txt) is the single strongest proof a company built for agents rather than for headlines.
• Bassethound scores ai_readiness as the count of distinct signal groups that fire, out of six, capped at 1.0.
• The verdict is rule-based: shipping needs a machine-facing endpoint or at least three signal groups, experimenting needs one, and none fires when nothing does.
• Server-side or fully proxied AI can stay invisible to an outside crawl, and Bassethound labels that gap instead of guessing past it.

What signals separate shipping AI from marketing AI?

Talk is cheap and leaves no trace in the page bundle. Code does. Bassethound’s AI-readiness layer looks for five kinds of evidence. 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). LLM observability (Helicone, LangSmith, Langfuse). Then it checks machine-facing surfaces: an llms.txt file, an MCP endpoint, a .well-known AI file, and support widgets like Intercom Fin or Sierra.

Each of those is a signal group. A homepage that says ‘AI-powered’ with none of them behind it is marketing. A site that loads the OpenAI SDK, calls a Pinecone index, and publishes an llms.txt is running something real. The count of distinct groups is the tell. One group is a hint. Two is a lead. Three or more is a pattern that is hard to fake and pointless to fake, because none of it renders anything a human visitor will thank you for. You do not load a vector-store client to impress a prospect. You load it because your product needs one.

Why is a machine-facing endpoint the strongest tell?

An MCP endpoint, a .well-known AI file, or a technical llms.txt is not a widget you bolt on for a launch tweet. It is a decision to serve machines: to let agents read your docs, call your tools, and negotiate with your systems. Companies that publish one have thought about an agent-native future and shipped toward it. That is why Bassethound treats any single machine-facing endpoint as sufficient for a ‘shipping’ verdict, with no signal-group threshold required.

Contrast that with a chat bubble. An AI widget is real signal, but it is also the easiest thing to buy off the shelf, so on its own it lands at ‘experimenting,’ not ‘shipping.’ A machine-facing endpoint costs engineering attention and returns nothing to a human visitor, which is why its presence is credible.

The llms.txt classification matters here too. Bassethound separates a standard llms.txt (a curated index pointing LLMs at your content) from a technical one (a machine-readable surface built for programmatic use). The technical variant weighs heavier, because it signals build intent rather than a marketing checkbox. A file written for crawlers is cheaper conviction than an endpoint written for agents.

Can a company hide a real AI stack from an outside crawl?

Yes, and being honest about that is the point. Bassethound runs a static crawl plus optional JavaScript rendering. That reaches what a browser loads: client SDKs, script hostnames, initialization code, and published endpoints. It does not reach a purely server-side pipeline. If a company calls OpenAI from its backend, proxies every model request through its own domain, and renders only finished text to the page, the AI stack can stay invisible from the outside.

So a ‘none’ verdict means ‘no external signal,’ not ‘no AI.’ Bassethound reports that gap in the dossier instead of papering over it. This cuts both ways for you. A confirmed signal is strong evidence of real AI. An absent signal is weak evidence of absence.

Treat ‘shipping’ as a near-certain positive and ‘none’ as inconclusive until you have inside information. Any tool that claims certainty from a cold outside crawl is overselling, because the crawl cannot see server-only code. Bassethound scopes its claim to what it can observe and tells you where it went blind. That honesty is what makes the positive signals worth trusting. A verdict that names its own limits is worth more than one that pretends it has none.

What does the ai_readiness score measure?

The score is boring by design. Count the distinct signal groups that fire, divide by six, cap at 1.0. Model provider, AI SDK, orchestration, vector store, observability, machine-facing surface. Hit four of the six and you score about 0.67.

It is not a confidence percentage. It is not a quality grade. It is not a ranking of how good the AI is. It measures the breadth of externally visible AI infrastructure, and nothing more. That restraint is a feature. A single opaque number that blends ‘how advanced’ with ‘how likely’ invites you to trust a guess you cannot inspect.

A signal-group count stays auditable. You can see which groups fired and which stayed dark, then decide what that means for your use case. Pair the score with the icp_signal (hot, warm, or cold) when you are qualifying accounts, and with the raw signal list when you are running diligence. The number orients you in a second. The evidence underneath it is what you act on, and Bassethound hands you both in the same call.

How do you read shipping vs experimenting vs none?

Three verdicts, one rule set. ‘Shipping’ fires when a machine-facing endpoint (MCP, a .well-known AI file, or a technical llms.txt) is present, or when three or more signal groups fire. It means the company built AI into how the product works or how it talks to machines. ‘Experimenting’ fires when at least one signal group hits but the shipping bar is not met: a lone SDK, a single vector store, a chat widget. It means AI is in the building but not yet load-bearing. ‘None’ fires when nothing external surfaces, which you should read as ‘invisible from here,’ given the server-side blind spot.

For sales, the verdicts map roughly onto the icp_signal. A company already spending on AI infrastructure is a shorter conversation than one that is not, so shipping trends hot and experimenting trends warm. For diligence, let the verdict set your skepticism: trust shipping, probe experimenting, and go get inside data before you act on none. The verdict is a starting posture, not a final judgment on the company. It tells you how much weight the outside signal can bear.

Bassethound perspective

Reading a homepage for the word ‘AI’ is worse than useless. It inverts the signal. The loudest marketers are often the thinnest builders, and the teams shipping the most real AI say the least about it on the front page. That is the conviction some competitors will dispute: the AI-washing scanners that grade a company by counting buzzwords are measuring the opposite of what they claim.

The stack does not lie. A vector-store client, an orchestration framework, an MCP endpoint. These take engineering effort and return nothing to a marketing team, which is why they are trustworthy. The strongest single tell is an endpoint built for machines that a human visitor will never see. You do not ship that for applause. You ship it because you decided agents are part of your future.

Bassethound is built to read the stack, not the story, and to tell you where the stack goes dark rather than fill the gap with a confident guess. A crawl that admits its blind spots is one you can believe when it fires. That is the whole bet: signal over sentiment, honesty over certainty.

Sources

• Model Context Protocol specification: https://modelcontextprotocol.io
• The /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