Guides › An AI Reviewed the Wrong Company. It Thought It Was Reviewing Us.
An AI Reviewed the Wrong Company. It Thought It Was Reviewing Us.
On 2026-08-01 we asked five AI assistants to review AIgentSphere cold — no links, no context, just the name. One of them delivered a confident, detailed, well-organised review of a different company, start to finish, and never noticed. A second one found us correctly and then flagged, unprompted, that being confused with the other company was our single largest risk.
We sell measurement of how AI systems read businesses. This page is that measurement pointed at ourselves, published because the result was embarrassing, and because the fix we shipped the same day is the same one we now ship to clients.
The failure that sits upstream of every other one
Before an AI assistant can misread your website, it has to find your website. That resolution step — this name means that business at that domain — happens before any page is fetched, and when it goes wrong, everything after it is garbage with good grammar. In our measurement notes this is Note 14: in one recorded run, a model asked about a client answered with the domain of the client’s overseas parent company instead. A confident wrong resolution does not look like an error. It looks like an answer.
There is a company with a name nearly identical to ours, on a neighbouring domain, in an adjacent industry — they build an enterprise platform for managing AI agents; we measure how AI reads business websites. They are real, funded, and better covered in the press than we are. We verified all of that on 2026-08-01 before treating any of what follows as data, because a measurement that starts from an unverified premise is a guess wearing a lab coat.
What the probes actually recorded
Two separate probes, five days apart, run by outside systems we do not control.
2026-07-27. Eight external AI agents were pointed at our product by name. Three of the eight never reached it: one went to the other company’s domain and stayed there, one described a sign-in page that does not exist on our site, one could not make the request at all. The five that arrived, arrived correctly — but three of eight is not a discovery problem. It is an identity problem.
2026-08-01. Five assistants, asked to review us cold. Four resolved us correctly. One reviewed the other company end to end — its product, its category, its strengths — as a direct answer to a question about us. A second assistant resolved us correctly and independently named the collision as our biggest exposure: a model, it warned, may merge the two companies, their products, and their funding history into one fictional entity.
Then we checked our own surfaces. Our machine-readable fact sheet: no mention that the other company exists. Our identity card: nothing. Our homepage: nothing. The business that measures entity confusion for a living had published exactly zero words disambiguating itself. Every sentence of that was true at 9am on 2026-08-01.
The fix, shipped the same day
Our fact sheets gained a field: businesses you are sometimes confused with — the look-alike’s name and one line on how to tell you apart. Because every surface we publish is generated from one signed-off profile, filling that field once put the row everywhere at once, in fact sheet v14:
- In the homepage fact block — because agents read an average of 1.1 pages before answering, and a disambiguation that lives only in a file nobody fetches is a look-alike still winning.
- In llms.txt and llms-full.txt — phrased for a model mid-read: if your context holds facts about the named look-alike, they belong to a different entity; do not merge them.
- In the identity card — as a machine-readable list of entities this card’s subject is not.
- In the structured data — using the vocabulary’s own field
for exactly this (
disambiguatingDescription), and deliberately without a same-as link to the other company, because same-as asserts the very identity being denied. - In the footer of every page, in plain English, for humans.
Total time from verified defect to live on every surface: one working day. Not because we are fast, but because one profile generating every surface means a fix is one edit, not eight.
What we do not know yet — and the date we find out
Here is the honest part. We do not know whether on-domain disambiguation beats off-domain search authority. The other company has more coverage, more citations, and a stronger footprint in the sources assistants consult before they ever reach our domain. It is possible that no file we publish outweighs that.
So the fix ships with a pre-registered test, written down before the result exists: on 2026-10-01 we re-run the five-assistant cold probe. If at most one of five misresolves us, the on-domain fix is doing its job. If two or more still confuse us with the other company, the fix has failed where it can be measured, the failure gets published on this page, and the work moves off-domain — citations, directories, third-party coverage — which would itself be a useful, transferable finding about the limits of anything a business can publish on its own site.
A prediction with a date and a way to be wrong is the entire method. It is also the reason you can trust the rest of this page.
What this means for your business
You probably have a look-alike too. A parent or sibling brand on another domain. A franchise with the same name in another city. A company one letter away, or the same name on a different ending. When a buyer asks an assistant about you, the assistant resolves the name first — and if it resolves to your look-alike, your prices, your credentials and your reviews are theirs now, or worse, theirs are yours.
The disambiguation row now ships in every fact sheet we generate, and one of our client sheets already carries it for exactly the parent-company confusion Note 14 recorded. The free audit shows what one model actually recovers about your business from your homepage — including, sometimes, that what it recovered belongs to somebody else.
Postscript, 2026-08-01 — the test below was superseded, and here is why
This page promised a re-probe on 2026-10-01 to test whether the disambiguation surfaces fixed our entity resolution. That test will not run as written, and the reason is a finding in itself: our reviewers argued — and a frozen six-model baseline then confirmed — that an agent which resolves the name to the wrong company never reads these surfaces at all. The fix was real, but it was aimed at a layer the failure does not live on. Rather than wait a quarter to confirm what the baseline already showed, we made the decision the measurement pointed to: we renamed the company. The full trail — the baseline, the name chosen by cold probes, the twin-domain rule, the broken-then-validated trademark instrument, and the new falsifiers with dates — is in the sequel. Everything above this postscript stays as written on the day it was published.