Ask the same question about your brand across four different AI engines, and you will probably get four different answers. One answer is current and cites your last page. Another describes a position you retired from 18 months ago and cites nothing at all. A third routes everything via a competitor’s comparison station. Same brand, same issue, four representations, and the gaps between them aren’t random noise you can brush off as a pattern quirk. They are structural and once you can see the structure you can plan around it.
I made my point in “When training data threshold becomes a ranking factor» in which your brand now lives two different memory systems at once. One is parametric memory, knowledge integrated into a model during training and then frozen until the next training session. The other is retrieval, content retrieved the moment someone asks for it. This article was about what the distinction means in terms of timing. This one is about the part I deliberately left for its own treatment, which is that engines don’t rely on these two memories in the same way, and that difference is what actually shapes where your brand appears and how it reads when it gets there.
Each engine has a memory posture
Let me give it a name, because naming it makes planning easier. An LLM memory posture is its lean by default: when you ask it something, does it look for a live fetch, or does it respond from what it already has in its settings? Platforms are categorized into two broad camps, and the camp an engine falls into determines almost everything about how your content reaches a user through that surface.
On one side are the engines that retrieve almost all queries. Perplexity is the clearest case; it performs a live web search on virtually any question and displays its sources by design rather than as an exception. AI Previews and Google’s AI Mode also rely on recovery, but with a problem worth understanding: These surfaces are served by the same crawler that powers the organic resultsrelying on the main search index rather than Gemini’s parametric memory. The token that Google offers to control the training of models, Google extendedhas no effect on what appears in search or its AI features. So, on persistent recovery engines, your visibility is first and foremost a recovery question and barely a parametric question.
On the other side are the engines that decide by query. ChatGPT, Claude, Microsoft Copilot, and the Gemini app all make a judgment call on each question: answer from settings or fetch. Claude’s web search functions as a tool that the model chooses to invoke when he decides the question needs it. Copilot is web-based only when enabled and has quick benefitsand when an administrator disables web grounding, it reverts entirely to internal model training. This last detail is the bridge that brings us back to “Stop treating AI visibility as a single problem,” where recovery was one of three layers a team must govern. Here’s that layer from the inside: On an engine decided by a model, whether recovery even happens can be an issue. setting in someone’s admin consolenot an ownership of your content.
And the posture isn’t even stable within a single engine. A ChatGPT clickstream study revealed the share of sessions that triggered a web search. oscillating between approximately 15 and 66% across the study window, moving as the underlying models were updated. The same question you asked in March could be answered from memory, and in April go live to the web, without anything changing on your end. Posture is a moving target, which is exactly why you need to measure it rather than assume it.
Recovery has ceased to be a single step
Even when an engine recovers, recovery is no longer a clean action, and this is where many older optimization instincts quietly break down. The single-pass model, in which a system takes your query, retrieves the first handful of matching pages, and generates, has given way to agentic retrieval that plans and executes many subqueries before responding. A question that the user typed becomes a fan of the questions the system asks on their behalffrom a few to several dozen. You are no longer optimizing just for the question in the search box. You optimize the invisible questions generated by the engine to satisfy it.
There’s a second-order problem above, and it’s worth stating clearly even if it deserves its own piece someday. Being put into context is not the same thing as being used well. The research that first documented how models use long context unevenly is now almost ten years old, and current models have largely solved the simple version, finding a fact buried in a long document. What remains unreliable is the hardest thing: integrating multiple scattered signals into a single coherent picture. Your brand is never a simple fact. Its representation depends on the engine that gathers your pages, reviews and third-party covers that are in different places in the retrieved material and then assembles them correctly. This assembly step always results in losses, which means that “we are retrieved” and “we are accurately represented” can both be measured and may disagree.
Timing has become a lever you didn’t used to have
Parametric memory introduces a variable that simply didn’t exist in the traditional SEO era: the training window. You cannot change what a template already contains in its settings. Publishing a fix today doesn’t change the version of your brand encoded in a model that completed training last summer. The only thing that changes parametric memory is a new training run, which means that the useful question is not how to correct what the model already believes, but what the model will learn about you when it next trains, and whether the right version of your story is the one it will find.
This is less hopeless than it seems, for two reasons. First, parametric memory is not a black box over which you have no influence. Models learn the version of a fact that appears consistently and corroborated by numerous sourcesSo the job is to make the accurate version of your story redundant, the version that’s hard to miss when the crawlers come. It’s a long game measured in template generations rather than page edits, but it’s a game you can play. Second, the pace of training is no longer a slow annual event. Major vendors now offer frequent point releases, each carrying its own thresholdso that the parametric layer updates in steps that you can actually aim for rather than a single distant horizon. Some of the inconsistencies that teams continue to report, the same engine giving different answers on different days, is this in action: one day the question was retrieved from the settings, the next day it triggered the fetch, and the two layers didn’t tell the same story.
A workflow to know where you really stand
Today you can do this by hand, without special tools, which is kind of the point. If you understand both memories you can read what any engine does with your brand. Call him memory posture audit.
- Choose queries that pay. It’s not about your brand name per se, but the questions a buyer actually asks where you need to appear: questions about categories, questions about comparisons, questions framed around a problem. A handful, linked to income.
- Run each on a deliberate spread. At least one permanent recovery engine and at least two model-decided engines, using identical wording each time, so the only variable is the platform.
- Read the posture, not just the response. Quotes are the tell-all. The sources cited directly mean that the recovery has been triggered; a confident response without sources came from parametric memory. On the engines chosen by the model, ask each question twice, once with a simple wording and once with a recency cue like “last” or “current”, and see if the second version switches the engine into recovery. This reversal is the posture that reveals itself.
- Sort what’s wrong by the memory that produced it. Outdated facts without citation indicate a parametric problem. The complete absence, or represented by a competitor’s page on an engine that has clearly performed a recovery, indicates a recovery-selection problem. In the result, the two can appear almost identical. It’s not the same fault.
- Fix the layer that is actually brokenbecause the patches are not transferred:
- A parametric problem cannot be edited directly. You influence the next training window by putting consistent, substantiated, explorable content in place now, so the correct version of your story is the one that is learned.
- A problem in retrieval is the work of research and selection: answer the distribution sub-questions directly, structure your pages for clean retrieval, and strengthen corroboration between third-party sources so that your version is the one assembled in the answer.
- Date it and repeat. Posture is not stable, so a spot audit is a snapshot, not a finding. Put it on a cadence, at least quarterly.
Which leaves the question to consider
Most teams driving AI visibility work hard on one memory system and treat the other as if it doesn’t exist, usually without ever deciding which one they chose. The discipline that this requires is small to describe and uncomfortable to practice: for each engine that matters to you, know its posture, know what memory your mark has on it, and know if it is the layer that you would have chosen on purpose.
It is the question of the memory layerand most teams can’t yet answer it, which in itself is the diagnosis. It also explains why a single AI visibility score is a category error. A number that combines parametric position and recovery position into a single digit averages two things that move independently, reward different work, and fail in different ways. You can’t manage what you’ve flattened. The literacy that matters now is the ability to separate the two layers in your head and ask yourself, each time, which one you are actually looking at.
If you’ve run a version of this on your own brand, I’d love to know what you found, especially when a platform surprised you. Leave a comment or contact us.
And if you want a longer argument for why visibility, trust, and auto-readability become the same problem, that’s what my book is about, The machine layer.
More resources:
This article was originally published on Duane Forrester decodes.
Featured image: Summit Art Creations/Shutterstock
