The same local business appears in one chatbot’s answer and disappears from another. You run one visibility playbook across the book, watch the result move in one place and hold in the next, and read the difference as randomness. It is not random. Each platform retrieves a business through a mechanism of its own, and no single fix moves all of them at once. The shift that put your clients’ customers in front of a chatbot is the moved buying moment; the retrieval underneath it is what Found by AI is about, and what this piece opens.
TL;DR
One retrieval mechanism per chatbot, one golden rule keyed to each, and each rule switched on only where that chatbot’s score falls below the panel median. That is the design, and it is the break from a single cross-chatbot rule set. The six platforms the engine covers read a business in ways that do not agree, which is why one playbook applied evenly moves some replies and leaves others untouched.
The same business, found by one chatbot and not another
Take one client: a bakery with a current Google Business Profile, steady reviews, and a site that answers the query a nearby customer types. The local results page finds it. One chatbot carries it in the reply it assembles; a second does not. Nothing about the business changed between those two replies, and nothing in your tooling reports which one the client just lost.
The cause is structural rather than a bug to chase. A chatbot reply is not the local ranking carried across. Each platform assembles what its own retrieval step pulls in, and those retrieval steps do not agree with one another. That mismatch is why one playbook, applied evenly across the book, moves some replies and leaves others exactly where they were.
How each chatbot reads a business
The engine covers six platforms, and each holds a golden rule of its own. The record states a retrieval mechanism for three of the six.
| Chatbot | What the record carries |
|---|---|
| ChatGPT | no mechanism carried |
| Perplexity Sonar | crawls in real time and weights freshness |
| Google Gemini | the only chatbot natively connected to Google Maps and Google Business Profile |
| Le Chat Mistral | no mechanism carried |
| Claude | no mechanism carried |
| Meta AI | not available in the EU in the Meta-app-integrated version |
The table is deliberately incomplete, and that is the honest state of the record. For ChatGPT, Le Chat Mistral, and Claude, the source names no mechanism, so this piece states none. What it does carry is the decision that each of the three still holds a rule of its own.
The three mechanisms that are carried point in different directions. Perplexity Sonar rewards whatever changed recently over what has been stable, because its crawl runs in real time and weights freshness. Gemini’s edge is not a crawler at all: it is the only one of the six wired natively into the two surfaces where a local business already keeps its own data current.
Meta AI’s limit is reach, not retrieval. In its Meta-app-integrated version it is not available in the EU at all, a constraint the record attributes to the General Data Protection Regulation (GDPR) rather than to anything the business owner controls.
One golden rule per chatbot
The decision is one golden rule per chatbot, each keyed to the mechanism above and each switched on only when that chatbot’s average score is significantly below the panel median. Actions are prioritized before broader optimizations, so a platform-specific rule does not displace a fix every platform needs.
The activation itself is a fixed comparison, not a judgement call: the rule fires when (median_score - model_score) / median_score > 0.3, computed in Python before anything reaches the model.
What I rejected is a single cross-chatbot rule set. The reason is that each platform’s citation and retrieval behavior differs, so one shared list would optimize for an average that no platform is. One playbook for all six would fit none of them well.
Activation depends on a panel median, and the instrument that computes it across a book of clients is its own subject .
Where the golden rules sit in the cascade
The per-chatbot rule is Set 4 of a four-set cascade. The backbone is 22 rules, generic to specific:
- Set 1 applies to every platform.
- Set 2 addresses local results specifically.
- Set 3 addresses AI chatbots specifically.
- Set 4 holds one golden rule per chatbot.
The engine applies the sets in decreasing priority, so an unmet universal recommendation outranks a per-chatbot adjustment. A gap in Set 1 is addressed before a Set 4 rule is reached, and the order repeats the same way on every run.
Nothing about that order is left to the model. Before a request is sent, the payload builder replaces every placeholder it can resolve from the client’s own report data and configuration; only the contextual ones it cannot resolve are passed on. The message then carries the pre-ranked Part 1 and Part 2 lists in a fixed order, and the instruction not to reorder or add rules is explicit. Code decides the cascade and the ranking; free text is the only layer left open.
What the per-chatbot approach does not solve
Three boundaries hold, and each one matters before you hand the practice to a client.
- The trigger is relative. The rule fires on a chatbot’s score against the panel median, so a platform below that line is acted on even when its absolute visibility is decent, and one sitting exactly on it is left alone even when it could improve. Relative is what makes the measure comparable across clients; it is not proof that the business appears.
- Meta AI’s absence in the EU is a reach limit, not a fix. No per-chatbot rule changes where the platform is offered to consumers.
- The per-chatbot rule is one layer of a four-set cascade. It targets each platform’s mechanism; it does not guarantee the business appears in that platform’s answer.
I state this at the design’s level, not as a measured result. All three records behind the piece are narrated from the rule file rather than read off a completed run, so I claim the design and its recorded status, never a measured ranking or a success rate.
The action your agency hands the business owner
A per-chatbot fix only counts if it reaches the person who can do it. When a chatbot’s score drops below the panel median, what comes back is one rule keyed to that platform’s mechanism, scoped to an action the non-technical owner can carry out themselves. The discipline that keeps an action deliverable to that owner is what turns a set of per-chatbot fixes into an offer you can run across the book. That discipline is the standard a client’s recommendations are held to.
The operator behind this stack, and the trade-offs I accepted to run it, are on the about page. If your offer is local visibility and you want a per-chatbot fix the business owner will actually carry out, let’s talk.