The entity problem: recognised before cited
Refreshed for current answer engines; the original analysis from the time is preserved exactly as written.
Most advice about AI visibility jumps straight to "how do I get cited?" — and skips the prior question that decides everything: does the AI even know who you are? Engines reason about entities, not strings of text. If your brand is not a clear, recognised entity, there is nothing for a citation to attach to.
the short answer
Before an AI can cite you, it has to recognise you as a specific entity — not just a string of characters, but a concrete thing with attributes, distinct from others that share your name. Engines do this with entity recognition and linking against a knowledge graph (Wikidata, Google’s). If you are described consistently everywhere and anchored with an identifier, you are a legible entity the AI can cite. If you are ambiguous, it gets you wrong — or skips you.
key takeaways
- Before it can cite you, an AI has to recognise you as a specific entity — to know your brand is one concrete thing, distinct from others that share the name.
- Engines understand "things, not strings" (Google, 2012): they identify the mention (entity recognition) and link it to a canonical ID (entity linking) in a knowledge graph like Wikidata or Google’s.
- Disambiguation resolves ambiguity (same name, different entities) and merges variants and synonyms, tying your content to a shared web of facts.
- If your brand is not a clear, consistent entity — described the same way everywhere, recognisable in the graph — an AI cannot cite you confidently, or it describes you wrong.
- The entity layer is the invisible foundation of AI visibility: recognition comes before citation.
recognition comes before citation
The order is the lesson. Consistent signals — one name, one coherent description, a stable identifier — resolve into a recognised entity, and only a recognised entity is eligible to be cited. Skip the left of this diagram and the right cannot happen: an AI will not cite a brand it has not first managed to identify.
Why this is the work underneath the work
Almost everything else written about AI visibility assumes the entity is already solved. Advice to add statistics, earn mentions, structure your answers — all of it presupposes that when a credible source names you, the system knows which "you" is meant. For well-established brands that assumption usually holds, which is why the entity layer is easy to overlook. But for a great many companies it does not: the name is shared, the description has drifted, the profiles disagree, and the result is that all the downstream optimisation lands on an entity the system is unsure about. Effort spent earning citations for a fuzzy entity leaks away, because the system cannot confidently route the credit to you. Solving the entity first is what makes the rest of the work pay off.
It is also the most durable layer to invest in, because it changes slowly and compounds. Engines, interfaces, and ranking signals churn constantly; the fact of being a clearly defined, consistently described entity does not go out of date when the next model ships. A brand that is unmistakable — one name, one current story, anchored in the graphs systems trust — carries that clarity into every engine that comes along, because they all, in their own way, are trying to understand the same real-world things. That is why we treat the entity layer as foundation rather than tactic: get it right and you have built something that keeps working; leave it ambiguous and every later effort is quietly taxed by the system’s uncertainty about who you are. It is the least visible part of AI visibility, and the part most worth getting right first.
The entity layer, in three parts
How engines came to understand entities, why ambiguity costs you, and how to make yourself a legible entity. Open each layer for the part that changes how you think about being found.
01 Things, not strings
More than a decade ago, search shifted from matching strings of text to understanding entities — the real-world things those strings refer to. The phrase "things, not strings" captured it: a query is no longer just letters to find on a page but a reference to a specific entity with attributes and relationships. Two steps make this work. Entity recognition spots that a mention in text refers to some entity at all; entity linking, or disambiguation, maps that mention to a single canonical record — an identifier in a knowledge base such as Wikidata or a search engine’s own graph. Once a system has resolved your brand to a specific entity, it can reason about you: what category you are in, what you make, how you relate to other known entities. A generative engine answering about your field is doing exactly this — operating on entities it has recognised, not on raw text. Which means the first question is not how well you are described, but whether you have been resolved to a clear entity at all.
02 Why ambiguity costs you
The failure modes of the entity layer are quiet but expensive. The first is non-recognition: if nothing in the system’s knowledge resolves to a clear entity for your brand, an AI has no stable thing to attach a citation to, and you are simply absent from answers that should include you. The second is conflation: when another organisation shares your name, weak disambiguation lets the system merge you, and an AI may confidently hand the other entity’s attributes — or its problems — to you. The third is staleness: if your entity record reflects an outdated identity, the system keeps describing you as what you used to be. A company that grew from one thing into another, but never updated how it is described across authoritative sources, will find the AI repeating the old framing, because that is what the graph still holds. None of these is about the quality of any single page; they are about whether the world, in aggregate, has a clear and current picture of what you are. Ambiguity does not just lower your visibility — it lets the system get you wrong.
03 How to be a legible entity
Becoming a clear entity is unglamorous and entirely within reach. It starts with consistency: name yourself the same way everywhere, and describe what you do in terms that agree across your site, your profiles, the press, and any reference sources — because every contradiction is a reason for the system to stay uncertain. Where you can, give the graph hard anchors: structured identifiers that point at your canonical entity, and accurate entries in the public knowledge graphs that systems trust to validate what they have recognised. Keep those current as you change, so your entity does not lag your reality. And make your distinguishing facts explicit — category, location, who you serve — so that if a namesake exists, the system has what it needs to keep you separate. None of this is a trick; it is the patient work of making yourself unmistakable, so that when an AI reaches for an entity to cite, it finds one clear, current, well-anchored version of you. That groundwork is the kind of thing the AC Group has helped clients lay for {years} years, long before anyone called it the entity layer.
A quick way to see where you stand
You do not need special tools to find out whether you are a clear entity; you need to look the way a system would. Ask a few of the AI tools to describe your company, plainly: what you do, who you serve, how you differ from competitors. Then read the answers against three questions: did it identify the right organisation at all, or blur you with a namesake; is the description current, or two pivots out of date; and does it match across tools, or does each one tell a slightly different story? The gaps you find are not random — they are the places where your entity is unclear, and they point straight at the work.
Then do the same audit on the sources themselves. Line up how your homepage, your main profiles, your reference entries, and recent press each describe you, and look for the contradictions: a different one-line summary here, an old category there, a name rendered three ways. Those discrepancies are exactly what keeps a system uncertain, because it has no single account to settle on. The fix is rarely dramatic — it is the patient reconciliation of your own descriptions until they agree, the correction of stale entries, the addition of a clear identifier where one is missing. It is unglamorous maintenance rather than a campaign, but it is the maintenance that makes everything downstream legible. Do this once properly and revisit it when you change, and you turn a fuzzy string into a brand a system can recognise, describe, and cite — which is the order in which all the rest has to happen.
The entity layer: quick answers
How is an "entity" different from a keyword?
A keyword is a string of characters; an entity is a thing in the world that a string might refer to. "Mercury" is one keyword but at least three entities — the planet, the element, the Roman god — and a search system that treats it as a string cannot tell which you mean, while one that treats it as entities can. That shift, often summarised as "things, not strings," is more than a decade old: it is why a search for a company can return a panel of facts about that specific organisation rather than ten pages that happen to contain its name. For your brand it matters because an AI answering a question about your category is reasoning about entities — your company as a distinct thing, with attributes and relationships — not matching the letters of your name. If the system has a clear entity for you, it can describe and cite you; if it only has a fuzzy string, it has nothing stable to attach a citation to. The keyword era asked whether your name appeared on the page. The entity era asks whether the system knows what your name denotes.
Do I need a Wikipedia or Wikidata entry?
It helps, but the deeper requirement is consistency, of which an entry is one strong expression. Knowledge graphs like Wikidata are among the trusted places systems use to validate the entities they identify, so an accurate, well-maintained entry gives the graph a clean record to anchor on — a canonical identifier, a stable description, links out to other facts about you. That is genuinely valuable. But an entry alone, contradicted by a homepage that describes you differently and profiles that each tell a slightly different story, does not resolve the ambiguity; it adds another voice to the noise. So the honest answer is that the goal is not "get a Wikidata entry" as a box to tick, it is "be describable as one coherent entity across every authoritative source," and an entry is most useful when it agrees with everything else. If you can only do one thing, make your descriptions consistent everywhere; if you can do two, add the structured entry that ties them together.
What if another company shares my name?
Then disambiguation is your central problem, and you have to give the system enough signal to tell you apart. Shared names are exactly what entity linking exists to resolve — the same way it separates "Jordan" the country from the person from the shoe — and it does so by leaning on the surrounding facts: your category, your location, your relationships to other known entities, your identifiers. The risk when a namesake exists is not just being missed but being conflated: an AI confidently attributing the other company’s attributes, or failings, to you. The defence is to make your distinguishing facts loud and consistent — what you do, where, for whom, under which identifiers — so the graph can keep the two entities separate. Vague, generic self-description is dangerous here, because it gives the system nothing to tell you apart by, and the more established namesake tends to win the ambiguous mention by default. Specificity is not just good copy in this case; it is how you avoid being merged into someone else.
Isn’t this the same as schema markup?
Schema markup is one tool for the entity problem, not the whole of it, and conflating the two leads people to mark up a page and assume the job is done. Structured data — including identifiers that point a machine at your canonical entity — is a clear, direct way to tell a system "this page is about this specific entity, here is its stable ID," and it genuinely helps disambiguation. But the entity layer is the broader fact that the system is trying to know what you are, and it draws on far more than your markup: how the press names you, how reference sources describe you, whether your accounts and profiles agree, whether your story is consistent over time. You can have flawless schema and still be a muddled entity if the world describes you three different ways, and you can be a well-understood entity with modest markup if every source agrees on who you are. Markup is the part you control most directly and should absolutely get right; it is necessary, frequently helpful, and not sufficient on its own.
A note on sources and timing
This is written in July 2024, and it deliberately leans on ideas that are not new. Entity recognition and disambiguation have been studied since the early 2000s; the "things, not strings" shift and Google’s Knowledge Graph date to 2012; Wikidata has been the largest open knowledge graph for years. We have applied those established concepts to the question of AI visibility rather than reporting any fresh measurement, because the foundational point does not depend on new data: generative engines reason about entities, so being a clear entity precedes being cited. We have not reached for the later vendor analyses and platform-specific findings about exactly how each AI system resolves entities, because those came afterward and would misdate a July 2024 view. What is solid is the structure of the problem, and it is one the AC Group has worked on under other names — identity, disambiguation, consistency — across 27 years, because being unmistakable was always the ground on which authority was built.