Ask the same question about your brand on four different AI engines, and you will likely get four different answers back. One answer is current and cites your latest page. Another describes a positioning you retired 18 months ago and cites nothing at all. A third routes the whole thing through a competitor’s comparison post. Same brand, same question, four representations, and the gaps between them are not random noise you can wave away as a model quirk. They are structural, and once you can see the structure, you can plan around it.
I made the case in “When the Training Data Cutoff Becomes a Ranking Factor” that your brand now lives in two different memory systems at once. One is parametric memory, the knowledge baked into a model during training and then frozen until the next training run. The other is retrieval, the content pulled in fresh at the moment someone asks. That piece was about what the distinction means for timing. This one is about the part I deliberately left for its own treatment, which is that the engines do not lean on those two memories the same way, and that difference is what actually shapes where your brand shows up and how it reads when it gets there.
Every Engine Has A Memory Posture
Let me give the thing a name, because naming it makes it easier to plan against. An LLM’s memory posture is its default lean: When you ask it something, does it reach for live retrieval, or does it answer from what it already holds in its parameters? The platforms sort into two broad camps, and which camp an engine sits in determines almost everything about how your content reaches a user through that surface.
On one side are the engines that retrieve on nearly every query. Perplexity is the clearest case; it runs a live web search on essentially every question and shows its sources by design rather than as an exception. Google’s AI Overviews and AI Mode also lean on retrieval, but with a wrinkle worth understanding: Those surfaces are served by the same crawler that powers organic results, drawing from the core Search index rather than from Gemini’s parametric memory. The token Google offers to control model training, Google-Extended, has no effect on what appears in Search or its AI features. So on the always-retrieve engines, your visibility is a retrieval question first and a parametric question barely at all.
On the other side are the engines that decide per query. ChatGPT, Claude, Microsoft Copilot, and the Gemini app all make a judgment call on each question: answer from parameters, or go fetch. Claude’s web search runs as a tool the model chooses to invoke when it decides the question needs it. Copilot grounds against the web only when it is enabled and the prompt benefits, and when an administrator switches web grounding off, it falls back to the model’s internal training entirely. That last detail is the bridge back to “Stop Treating AI Visibility as One Problem,” where retrieval was one of three layers a team has to govern. Here is that layer from the inside: on a model-decided engine, whether retrieval even happens can be a setting in someone’s admin console, not a property of your content.
And the posture is not even stable inside a single engine. One clickstream study of ChatGPT found the share of sessions that triggered a web search swinging between roughly 15 and 66% across the study window, moving as the underlying models were updated. The same question you asked in March might answer from memory, and in April, reach for the live web, with nothing changed on your end. Posture is a moving target, which is exactly why you have to measure it rather than assume it.
Retrieval Stopped Being A Single Step
Even when an engine does retrieve, getting retrieved is no longer one clean action, and this is where a lot of older optimization instinct quietly breaks. The single-pass model, where a system embeds your query, grabs the top handful of matching pages, and generates, has given way to agentic retrieval that plans and runs many sub-queries before it answers. One question the user typed becomes a fan of questions the system asks on their behalf, anywhere from a couple to dozens. You are no longer optimizing only for the question in the search box. You are optimizing for the invisible questions the engine generates to satisfy it.
There is a second-order problem layered on top, and it is worth stating plainly even if it deserves its own piece someday. Being pulled into the context is not the same as being used well. The research that first documented how models use long context unevenly is most of a decade old now, and current models have largely solved the simple version, finding one fact buried in a long document. What stays unreliable is the harder thing: integrating several scattered signals into one coherent picture. Your brand is never a single fact. Its representation depends on the engine gathering your pages, your reviews, and third-party coverage that sit in different places in the retrieved material, then assembling them correctly. That assembly step is still lossy, which means “we are getting retrieved” and “we are being represented accurately” can both be measured, and can disagree.
Timing Became A Lever You Did Not Used To Have
Parametric memory introduces a variable that simply did not exist in the traditional SEO era: the training window. You cannot edit what a model already holds in its parameters. Publishing a correction today does nothing to the version of your brand encoded in a model that finished training last summer. The only thing that changes parametric memory is a new training run, which means the useful question is not how to fix what the model already believes, but what the model will learn about you the next time it trains, and whether the right version of your story is the one it will find.
This is less hopeless than it sounds, for two reasons. First, parametric memory is not a black box you have no influence over. Models learn the version of a fact that shows up consistently and corroborated across many sources, so the work is to make the accurate version of your story the redundant one, the version that is hard to miss when the crawlers come through. That is a long game measured in model generations rather than page edits, but it is a game you can play. Second, the training cadence is no longer one slow annual event. The major providers now ship frequent point releases, each carrying its own cutoff, so the parametric layer refreshes in steps you can actually aim at rather than a single far-off horizon. Some of the inconsistencies teams keep flagging, the same engine giving different answers on different days, is this in action: one day the question pulled from parameters, the next it triggered retrieval, and the two layers were not telling the same story.
A Workflow To Find Out Where You Actually Stand
You can run this by hand, today, with no special tooling, which is rather the point. If you understand the two memories, you can read what any engine is doing with your brand. Call it the memory posture audit.
- Pick the queries that pay. Not your brand name on its own, but the questions a buyer actually asks where you need to appear: the category questions, the comparisons, the problem-framed ones. A handful, tied to revenue.
- Run each one across a deliberate spread. At least one always-retrieve engine and at least two model-decided ones, using identical wording every time, so the only variable is the platform.
- Read the posture, not just the answer. Citations are the tell. Live cited sources mean retrieval fired; a confident answer with no sources came from parametric memory. On the model-decided engines, ask each question twice, once in plain evergreen phrasing and once with a recency cue like “latest” or “current,” and watch whether the second version flips the engine into retrieval. That flip is the posture revealing itself.
- Sort what is wrong by which memory produced it. Stale facts with no citation point to a parametric problem. Absent entirely, or represented through a competitor’s page on an engine that clearly did retrieve, points to a retrieval-selection problem. In the output, the two can look almost identical. They are not the same defect.
- Fix the layer that is actually broken, because the fixes do not transfer:
- A parametric problem cannot be edited directly. You influence the next training window by getting consistent, corroborated, crawlable content in place now, so the correct version of your story is the one that gets learned.
- A retrieval problem is findability and selection work: answer the fan-out sub-questions directly, structure your pages for clean extraction, and strengthen corroboration across third-party sources so your version is the one that gets assembled into the answer.
- Date it and repeat. Posture is not stable, so a one-time audit is a snapshot, not a finding. Put it on a cadence, quarterly at the least.
Which Leaves The Question Worth Considering
Most teams optimizing for AI visibility are working hard on one memory system and treating the other as though it does not exist, usually without ever having decided which one they picked. The discipline this asks for is small to describe and uncomfortable to practice: For each engine that matters to you, know its posture, know which memory is carrying your brand there, and know whether that is the layer you would have chosen on purpose.
That is the memory-layer question, and most teams cannot answer it yet, which is itself the diagnosis. It also exposes why a single AI visibility score is a category error. A number that collapses parametric standing and retrieval standing into one figure is averaging two things that move independently, reward different work, and fail in different ways. You cannot manage what you have flattened. The literacy that matters now is the ability to hold the two layers apart in your head, and to ask, every time, which one you are actually looking at.
If you have run a version of this across your own brand, I would like to hear what you found, especially where a platform surprised you. Leave a comment or reach out.
And if you want the longer argument for why visibility, trust, and machine-readability are becoming the same problem, that is the subject of my book, The Machine Layer.
More Resources:
This post was originally published on Duane Forrester Decodes.
Featured Image: Summit Art Creations/Shutterstock
