Someone on your sales team pasted an assistant's answer into Slack. It names four companies in your category, yours is not one of them, and the question that follows is always the same: why them and not us? The honest first answer is that nobody outside the provider can tell you with certainty, because the function that selects and orders those names is not published, not inspectable, and not stable over time. What you can do is separate the three routes a brand name can take into an answer, because they behave differently, they update on different clocks, and only some of them respond to anything you do.
That separation is the whole point of this post. Once you can tell which route produced a name, "why them and not us" stops being a mystery and becomes a set of narrower, answerable questions.
What actually happens when you ask an assistant for a recommendation
From the outside, a recommendation looks like one event. Internally it is at least two: the system decides what material to condition the answer on, then it writes prose from that material. Those steps can be separated in time, in infrastructure, and in what influences them.
Sometimes the material is nothing but the model's own parameters. Sometimes the system runs a search, fetches documents, and reads them before writing a word. Sometimes it calls a tool that returns structured records. Often it is a blend, and the blend is not disclosed to you at the moment you read the answer.
Three practical consequences follow. First, the same assistant can produce a name for two different reasons on two different days. Second, "our brand appeared" and "our page was read" are separate events that a screenshot cannot distinguish. Third, any claim about how this works has to be pinned to a specific assistant, a specific model version where the provider exposes one, and a specific date. Provider behaviour changes without announcement, so an undated statement about mechanism has a short shelf life. Everything described below reflects publicly documented provider behaviour as of this post's publication date, and should be re-verified against current documentation before you rely on it.
No one outside a provider can see the ranking function that orders brand names in an answer. Anyone who tells you otherwise is describing a guess, a correlation, or a sales pitch.
Source one: what the model absorbed during training
A language model has read an enormous amount of text and encoded statistical structure from it. When you ask for the best options in a category and the system does not fetch anything, the names come from that encoded structure. This is recall, and it is the oldest and least controllable of the three routes.
Recall has recognisable fingerprints. Facts are confidently stated and sometimes out of date. Company descriptions match how a brand was positioned some time ago rather than how it is positioned now. Products that launched recently are missing entirely, and products that were discontinued are still listed. There are no links.
Two things follow for anyone trying to be present in recall. The first is timing: material has to exist, be widely repeated, and be crawled well before a training cutoff to have any chance of showing up, which means the feedback loop is measured in model generations rather than in weeks. The second is that you cannot address it directly. There is no submission form for a training corpus, no request that adds you, and no tactic that anyone can honestly claim will place you there. What is plausible is much duller: consistent, unambiguous, widely repeated public information about who you are and what you sell gives a model more consistent material to encode. That is a reason to fix your entity basics, not a promise about outcomes. We cover the distinction between recall and fetching in more depth in why some answers never update.
Source two: what it retrieves live at answer time
The second route is retrieval. The system issues one or more queries against a search index, gets back candidate documents, fetches some of them, and conditions its answer on the text it read. The brand names in the reply are then substantially a function of which documents were retrieved, which is a function of the query the system wrote for itself, not the question you typed.
That last point is where most intuition breaks. You asked for the best project management software for a small agency. The system may have searched for something narrower, something broader, or three different phrasings at once. The documents that come back are what the answer is built from, and you have no visibility into the intermediate query.
Retrieval is the route most exposed to things you control. Whether your pages are reachable by the relevant crawlers, whether their content is present in the served HTML, whether the specific claim a reader needs is stated plainly in a passage rather than implied across a page, whether a third-party listicle that does mention you is itself retrievable: all of that sits inside the retrieval path. None of it is a lever with a guaranteed effect, and anyone offering one is selling something we would not buy.
Retrieval also has the fastest clock. A page published this month can enter a retrieval path without waiting for a model to be retrained. This is the main reason the same brand can be absent from an assistant's unsourced answer and present in its sourced one on the same afternoon.
Source three: tools, connectors, and structured lookups
The third route is a tool call. Rather than reading web pages, the assistant asks something for structured data: a search API, a shopping or product feed, a maps or business listing, a connected enterprise data source, a code interpreter, a first-party index. Whatever comes back has its own inclusion rules, its own freshness cycle, and its own owner.
This route is easy to overlook and increasingly consequential, because the selection has already happened before the model sees anything. If a product feed does not carry your SKU, no amount of writing will put it in an answer built from that feed. If a business directory has your category wrong, the assistant inherits that error and states it fluently.
The practical move is to work out which upstream sources plausibly feed the answers you care about in your category, and to check your own records in each of them the way you would check a listing. That is unglamorous, verifiable work, and it is often the fastest correction available. Which tools any given assistant calls, and when, varies by assistant and by surface, and should be checked against current provider documentation rather than assumed.
Which of these you can influence, and how directly
Here is the same material as a decision aid. "Influence" below means a plausible causal path, not a promised result.
| Route | Typical fingerprint | How fast it can change | What you can actually do | Honest limit |
|---|---|---|---|---|
| Training recall | No links, confident, sometimes stale | Model generations | Make public information about your entity consistent, unambiguous, and widely repeated | No submission path, no control, effect unmeasurable on your timeline |
| Live retrieval | Linked sources, current facts, sometimes shallow | Days to weeks | Crawler access, served HTML, plainly stated claims, presence in third-party pages that are themselves retrievable | Selection still happens inside an index you do not run |
| Tools and connectors | Structured, uniform, listing-shaped | Depends on the source | Correct and complete your records in the upstream sources that feed your category | Inclusion rules belong to the source owner, not to you |
Two cautions belong with that table. It is a model for reasoning, not a measured attribution of any specific answer. And the routes blend, so a single answer may draw on all three at once.
What this means for measuring your visibility
The most common measurement error in this category is treating "our name appeared" as one thing. It is at least two.
Appearing in the answer means the assistant said your name in its prose. It tells you the brand was available to the system from some route, and nothing about which.
Being cited as a source means a link to your property was attached to the answer. That is a claim about retrieval, and it is a different and narrower event. A brand can be named constantly and cited never, which usually indicates recall or a third-party page doing the work. A brand can be cited without being recommended, when your page is used as evidence for a statement about someone else.
Report them as separate metrics. Collapsing them into one number produces a figure that goes up and down for reasons nobody can explain later, which is exactly the sort of number that gets an entire measurement programme cancelled.
Two further rules follow directly from the mechanism. Record the assistant, the surface, and the model version wherever the provider exposes one, because a mechanism claim without a version and a date is not reproducible. And never let one answer stand as a measurement, because the route taken can differ between two identical questions asked minutes apart. If you want the side-by-side of these differences, see how each assistant sources an answer; the broader mechanism material lives on the AI search fundamentals hub.
In Plain English
Brand names get into an AI answer three ways: the model remembers them, the system looks them up right now, or a tool hands them over. Remembering is slow and outside your control. Looking up is fast and touches things you own. Tools depend on whoever owns the data. Most answers mix all three, and nobody outside the provider can see how the mixing is decided.
This helps most if you are the person who has to explain to a leadership team why a competitor is named and you are not. Use it before you interpret any AI-visibility number, so you know what the number is counting. The next step is to check whether your brand appears at all, across more than one assistant and more than one run, and to keep "named in the answer" and "cited as a source" in separate columns from the very first spreadsheet.
Ready to see where you stand? Run the free AI Visibility Check for a sampled, multi-model snapshot with an honest confidence range.
Primary-source verification
Checked July 28, 2026. The operational and factual guidance above was reviewed against the primary references below. Provider features, prices, policies, interfaces, jurisdictions, and account-specific results can change; recheck the controlling first-party document and your own account or measured data before acting.
- Google Search: AI features and your website - How Google describes eligibility, preview controls, and appearance in its AI search features.
- Google: common crawlers and special-case user agents - Current Googlebot and Google-Extended identities and controls.
- OpenAI: overview of OpenAI crawlers - Current GPTBot, OAI-SearchBot, and ChatGPT-User descriptions and publisher controls.
- Anthropic: web-crawler controls - Current ClaudeBot, Claude-SearchBot, and Claude-User descriptions and controls.
- Perplexity: crawler and user-agent documentation - Current PerplexityBot and Perplexity-User descriptions and controls.
- Google Search: structured-data introduction - Supported structured-data behavior and validation guidance.