LLM Behavior Optimization: A Mental Model for How LLMs Actually Choose (For Marketers)

LLMs do three things: recall, retrieve, infer. They’re more likely to recommend you when you’re legible, eligible, and extractable across all three.

Between February and April 2026, three connected ideas landed in the same place at the same time for me. They weren’t planned as a stack. They came out of the work: a string of fetch-tool failures, a conversation with a stubborn AI, a disambiguation campaign, a new service I was testing in my consultancy, and a content session that ran 80 minutes longer than expected.

What they add up to is a mental model for LLM behavior optimization: how machines find, evaluate, and choose who to recommend, and what you do about each layer. I’m still testing it. But it’s formed enough to help if you’re a practitioner trying to figure out where AI visibility actually fits.

There are two maps here, describing the same system from two angles. The first is what the machine does: recall, retrieval, and inference. The second is what it needs to believe about you while it’s doing it: legibility, eligibility, and extractability. The behaviors are the terrain. The conditions are the destination.

Read straight through for the full picture, or jump to wherever you’re most stuck.

The AEO gap we sense, but misidentify

I’d venture a bet that a lot of AEO strategy is really SEO tactics with new dashboards. The outcomes get tracked in AI visibility tools now, or in AI features bolted onto legacy SEO tools. The underlying logic hasn’t changed much.

And SEO has earned its reputation. FirstPageSage puts thought-leadership SEO at roughly $9 back for every $1 spent. The return on AEO? Largely undocumented. We don’t have years of historical data to build repeatable processes from yet. We’re figuring it out.

The vocabulary alone tells the story. The same discipline gets called GEO, AEO, GSO, LLMO, or AI visibility, depending on who’s writing. The tools changed. The dashboards changed. The strategic logic, for most practitioners, stayed the same. (Visibility Engineer: that’s what I started calling myself once it was clear I wasn’t a content marketing coordinator anymore.)

Here’s the big problem. Search engines and large language models don’t behave the same way. Same query, same browser, same person, different systems, and you can get a different answer every time.

In the absence of historical data and transparency, the only stable anchor is behavior. So engineer visibility around behaviors: your ideal customer’s, and the LLMs they use to find you. There are three.

The three LLM behaviors

Understanding these is the difference between optimizing for one thing and optimizing for the whole system.

Recall: what the machine already knows

The machine answers from what it already knows. No search, no real-time pull. This is parametric knowledge: information baked into the model during training. It shapes how the machine understands the world, recognizes entities, and forms default answers. When a machine knows who you are without looking you up, that’s recall doing its job.

Recall is the long game, and it lags. What got encoded reflects the world as it was at some point before the model shipped. Sometimes way before.

That gap isn’t a fixed window. It depends on the industry. In stable industries, a six-to-twelve-month lag is manageable. In fast-moving ones (tech, finance, anything disrupted in the last eighteen months), training data may be encoding a world that no longer exists. For the developer-side version of this, Firecrawl’s breakdown of training vs. retrieved vs. live web data is worth the read.

So you manage recall through probability, not precision. Show up consistently in the kinds of sources training data pulls from, so when the next training cycle runs, there’s a reasonable chance your ideas get encoded. You can’t control what gets in. You can raise the odds.

Retrieval: what the machine goes out to find

The machine goes out and finds a current answer in real time. This is the layer most AEO advice already teaches: be crawlable, be findable, be structured in a way machines can parse.

But retrieval carries more weight than most practitioners give it, especially in fast-moving industries. When training data encodes a lagging version of reality, retrieval becomes the correction layer. It’s how the machine updates what it thinks it knows. And the machines lean hard on fresh material.

Retrieval is also where personalization happens. When someone asks an AI to recommend something and the answer feels tailored to them, that’s retrieval. Which matters a lot if you’re trying to show up in “best of” and “recommend me” queries. Those aren’t about who ranks highest. They’re about who has the most relevant signal for that user, at that moment, in that model.

That’s SO important to understand. The answer isn’t static. It’s constructed fresh every time. That’s the generative in generative AI.

Inference: what the machine builds when it decides it already knows

The machine decides it already knows enough and constructs an answer without retrieving anything. No error message. No flag. Just an answer, accurate or not, assembled from what it’s already holding. This is the most dangerous behavior because it’s the most invisible. The machine isn’t broken. It made a judgment call.

Inference is also a diagnostic. What the machine invents when it decides not to look tells you exactly where your foundation is weakest:

The mirror shows you where the leak is.

A note on industry resistance. Not every machine responds to retrieval signals the same way in every industry. LLMs apply more scrutiny in high-stakes categories: health, finance, legal, safety. The bar for eligibility is structurally higher there. So you’re tracking two variables at once: how fast the industry moves (how much retrieval has to make up for stale training data), and how resistant the machine is to being influenced in that space (how high the eligibility bar sits).

The three retrieval failures

This is where behavior problems become visible. Two of these announce themselves. One doesn’t.

Failure 1: The page is too dynamic to crawl. Fix the page.

The AI tried to read your page and couldn’t parse it. Too much JavaScript, too much content assembling itself in real time. The crawler sees the skeleton, not the finished page.

I’ve seen this many times. A brand pays a web developer who’s great at design but doesn’t know search, and the site they build can’t generate organic traffic. Your messaging, services, and proof only get seen if you tell people to go look. The data shows it, too: you’ll be top-heavy with branded searches, leaning on being in the room, outbound, and paid ads, because the site is mostly invisible to the machine.

The fix is structural: simpler architecture, static rendering, less visual complexity. A page that looks great in a browser but means nothing to a crawler is not a visible page.

Failure 2: The site blocks bots. Fix the mirror.

The AI tried to reach your page and the site turned it away, on purpose. Major publications do this. Some platforms do it by default. When it happens, the AI doesn’t stop looking. It mirrors: it builds an answer from whatever else on the web has covered, cited, or summarized you. Press mentions, partner pages, external profiles. Those become the answer.

If what’s out there is thin, outdated, or wrong, that’s what someone gets. The AI doesn’t stop to correct. It mirrors what’s there and delivers it confidently. Fixing the mirror means building and maintaining that secondary layer on purpose, so when the machine can’t reach you directly, what it reaches for is still accurate.

Failure 3: The machine thinks it already knows. Fix the signal.

Man, this one annoys the heck out of me. Because it doesn’t announce itself. The AI doesn’t throw an error. It just answers, confidently, from inference instead of retrieval. It looked at the URL, the context of the question, what it already knew about the topic, and decided it had enough. Sometimes it’s right. Often it isn’t. I’d credit this behavior for a lot of the moments people swear the machine is hallucinating.

The fix isn’t a page fix. I thought it had to be, at first. It’s not. And it isn’t a clever prompt to force the machine to check, because your buyer doesn’t search that way. The fix is the signal. And “fix” is a misleading word, because you won’t fix it completely. Too many moving pieces. But you can plan for it. The machine’s confidence comes from how much accurate, corroborated information about you exists across the web. Build enough of that in the right places, and the machine is more likely to check before it assumes.

The three visibility conditions

This is the destination map: where you’re trying to land.

I used to describe these as tiers, each one unlocking the next, with recommendability at the top. My thinking changed in May 2026. They work more like a flywheel. Strengthen one and you raise the floor on the others. Let one slip and the others follow.

Legibility: can the machine identify you without visiting your website?

This is entity infrastructure. My bread and butter, and why I formalized the Minimum Viable Knowledge Graph as a repeatable process. Your name, role, and expertise, consistent across every platform and profile. Schema markup that tells machines how to categorize you. A canonical bio on a domain you own that everything else points back to and agrees with.

When multiple sources say the same thing about you, machines build that picture with confidence. When sources conflict, machines hedge. “She claims.” “According to their website.” “Details may vary.” That’s the machine telling anyone who asks: I’m not sure who this person is right now.

Legibility mostly shapes recall. Remove a major authority signal and the machine doesn’t fail at retrieval. It reverts to whatever version of you it encoded before that signal existed. That’s a legibility problem showing up as a recall failure.

Failure mode: You build for eligibility and extractability, earn mentions, optimize content, and the machine credits it to someone else, or to a fragmented version of you. The work doesn’t compound. It leaks.

Eligibility: does the machine consider you credible enough to include?

A machine can identify you perfectly and still leave you out. Legibility tells it who you are. Eligibility tells it whether you belong in the answer. This is the proof layer: third-party press, guest articles on credible publications, podcast appearances, documented client outcomes, and consistent publishing on the same topics over time. One article is a claim. Twelve articles over eighteen months is a pattern the machine reads as expertise.

The structural tool here is Google’s E-E-A-T. MVKG gives legibility a shape. E-E-A-T gives your corroboration strategy one.

The machines don’t mainly learn about you from your website. They learn from what other people publish about you. The secondary layer isn’t supplementary. It’s load-bearing.

Corroboration strategy also has to account for who the client actually is. Traditional authority signals (VC funding, Crunchbase listings, research budgets, mainstream press) are structurally out of reach for a lot of the founders who most need visibility. That’s not a personal deficit. It’s a structural gap. For them, compensating signals aren’t a workaround. They’re the strategy: Notion Marketplace listings, Amazon author pages, local press, industry association citations, podcast networks, community platforms.

Eligibility mostly shapes inference. When the machine decides it knows enough to answer without looking, the secondary layer is what it reaches for. Strong corroboration, accurate inference. Thin corroboration, wrong mirror.

Failure mode: The machine knows who you are but hedges. “According to their website.” “The company states.” Unconfirmed claims rarely get recommended. They get footnoted.

Extractability: is your content in a form the machine can actually use?

Eligibility earns you a seat at the table. Extractability decides whether you get called on. Where legibility’s lever is MVKG and eligibility’s is E-E-A-T, extractability’s lever is content architecture itself: how you build, structure, and name what you publish.

In practice, that means definitional snippets: named concepts defined in two clean sentences. Answer-first structure, because content that buries the answer in paragraph four tends to get passed over for content that leads with it. And named frameworks, because a named concept with a definition makes you the definitional source. The machine is more likely to cite you by name when the concept comes up.

That study is one of the clearest pieces of evidence we have that how you write changes whether you get used. In that study, the old SEO habit of stuffing keywords actually hurt.

This is the layer most AI visibility advice skips. It assumes that if you’re visible and credible, you’ll be recommended. Not necessarily. You can be legible, eligible, and still not extractable, because your content was written for people who scroll and skim, not machines that extract and cite. Extractability is buildable, auditable, and repeatable. That’s what makes it the right lever.

Failure mode: The branded search trap. Strong on branded queries, thin or missing on unbranded category queries. The machine knows you. It trusts you. But when it builds an answer to a question you should own, it reaches for someone whose content it can actually use.

How it all connects

This is where the two maps become one system.

Legibility shapes what the machine recalls. A weak entity foundation means recall can fail before any other behavior kicks in.

Retrieval shapes how that recall gets interpreted. What the machine finds either confirms or complicates what it already knows. Strong retrieval signals reinforce accurate recall. Weak ones leave the machine leaning on whatever it encoded, which may be badly out of date.

Those two together feed extractability. Whether the machine pulls you into an answer depends on whether it knows you accurately and whether it found content it could actually use.

And inference is the pressure test for the whole thing. Weakness anywhere in the chain sets it off. So what the machine invents isn’t just a failure to manage. It’s information.

The diagnostic: where are you stuck?

Find the bottleneck before you build anything. Optimizing for the wrong condition wastes money and produces results that don’t compound. Three tools give you the full picture.

MVKG health scoring (proactive). The Minimum Viable Knowledge Graph scorecard maps your entity structure across its five nodes and shows where it’s thin. A weak entity structure is the best predictor of inference failure. Run it before strategy starts.

Inference output analysis (reactive). Ask the machine about the brand with web search turned off. What it builds from memory alone tells you what’s encoded, what’s missing, and what it’s getting wrong.

Hedge signal mapping (confirmatory). Track the language AI systems use when they talk about the brand. Hedging is the machine’s confidence score, made visible. Where the hedging shows up tells you which condition the machine doesn’t trust yet.

Blind spot accounting

Every machine has a knowledge cutoff. Every industry has a velocity. Where those two diverge is where strategies fail.

Before the work begins, estimate two things: how far the machine’s knowledge lags behind current reality in this specific industry, and how resistant the machine is to being corrected in this specific space.

Blind spot accounting isn’t a fully formed methodology yet. But it’s a real diagnostic step: probe the machine’s knowledge for the relevant topics, estimate the lag, and build retrieval signals specifically to cover what the machine doesn’t know it doesn’t know. The goal isn’t an all-knowing machine. It’s making sure that when the machine reaches for information about this brand, what it finds is current enough to be useful and accurate enough to be trusted.

A visibility strategy built without accounting for the machine’s blind spots is a strategy built on an incomplete map.

The through-line

Three retrieval failures tell you what’s breaking. Three LLM behaviors tell you what you’re optimizing for. Three visibility conditions tell you where you’re going.

Each one is a different altitude of the same system, and each has its own deep dive. They’re meant to be read in order, and they all build on the piece that started it: the canonical bio, the first brick every other layer rests on.