AEO for agencies, adding it to a retainer

The short answer: Add answer engine optimisation to a retainer as a fixed monthly run of the same prompt set plus a named list of fixes, not as a visibility score with a target attached. Price the re-runs, because re-running is the work. Put the engines' own volatility in the contract. If you sell a number, you will spend month four arguing about a move you did not cause.
Most agencies already hold the two things this work needs: access to the client's site and a reason to be in the room every month. What usually goes wrong is the shape of the offer, not the delivery.
Why the retainer shape matters more than the tactics
An answer is generated per request rather than served from a stored position. In our own audit runs, two identical prompts minutes apart have come back citing different pages, which is the behaviour this section is built on. Our runs cover five engines and we cannot see inside any of them, so treat that as something to confirm on your client's category rather than a law. Where it holds, it breaks the reporting habit a search retainer is built on, because there is no stable position to chart. A line that wobbles on its own invites the client to read noise as performance, in both directions.
So the unit you sell cannot be the chart. It has to be the run plus the fix. A run is a fixed prompt set, executed on a schedule, with the evidence kept. A fix is a specific change to the client's site or their presence elsewhere, dated, so that the next run can be read against it. That is a defensible invoice. A score with an arrow next to it is not.
This is also the cleanest way to explain the practice internally. The naming argument over AEO vs GEO vs SEO eats a lot of agency meeting time and decides nothing. What decides things is whether somebody owns the three layers of access, identity and corroboration, which is the same question as who owns AEO inside a company on the client side.
Establish the noise floor before you promise anything
Here is a check worth running in week one, before the first report goes out.
Take twenty prompts from the client's category. Run all twenty on one engine. Wait ten minutes, change nothing, run all twenty again. Record whether the client was named each time. The difference between the two passes is your noise floor for that engine and that set, measured on that day.
On the client sets we have run as part of our own audits, that same-day difference has usually not been zero, and on thin categories it has been large enough to swallow a month of honest work. We are not publishing a figure for it. Those runs are a convenience sample of the categories that happened to hire us, not a representative survey, and a floor is specific to one engine, one prompt set and one day, so our number would not transfer to your client anyway. Measure it yourself. Whatever number comes back, it becomes the rule for the rest of the engagement: a month on month movement smaller than the noise floor is not a result and does not go in the headline of a report. Say that out loud in the kickoff and write it into the first deck. You are giving up a convenient story and buying back every awkward conversation in month four.
A bigger prompt set narrows the floor, which is the real argument for scale. Our own audit uses about 45 prompts across five engines, run with retrieval on and off, for exactly that reason. The sample audit report shows how the evidence is attached to each finding, which is the part a client will later ask you to justify.
The access check almost nobody runs
Two pieces of engine documentation, read together, produce a billable finding on a surprising number of sites.
The first is Google's snippet control. Google documents that nosnippet on a page "will also prevent the content from being used as a direct input for AI Overviews and AI Mode", and that max-snippet limits how much of the content can be used the same way, with max-snippet:0 behaving like nosnippet. We have found those rules left in place on client sites, carried over from an old publisher deal, a legal review, or a template nobody had opened since. We have not counted how common that is across the web. Pull the robots meta tag and the X-Robots-Tag header on every page type the client has, not just the home page. It takes a morning, and on the engagements we have run it has more than once been the highest value finding of month one.
The second is the split between crawling agents and user-triggered agents. OpenAI's bot documentation, read on 12 October 2026, lists four agents, and the two that matter here do different jobs: OAI-SearchBot surfaces sites in ChatGPT's search features, while ChatGPT-User fetches a page because a person asked, and OpenAI notes that robots.txt may not apply to it. Perplexity documents the same division, with PerplexityBot indexing and Perplexity-User supporting user actions, and states that this fetcher generally ignores robots.txt. Those are the two engines whose documentation draws the line explicitly. We have not read the other engines' docs for an equivalent split, so do not assume the pattern holds beyond the two cited here.
The failure mode falls out of that. A client whose security team blanket-blocked "AI bots" has usually blocked the indexing agents and left the user-triggered ones alone. The brand then appears when somebody already knows its name and types it, and vanishes from every generic question in the category. From the client's seat this looks like a content problem. It is a firewall rule. Diagnosing it correctly in month one is worth more to the relationship than a quarter of writing.
While you are there, check what the documentation does not ask for. Google's AI features page states that no special optimisations are necessary and that there is no special schema.org structured data you need to add in order to appear in these features. That is Google's guidance about Google's surfaces, and it says nothing about the other engines. That is a useful sentence to have at hand when a client arrives with a list of things a vendor told them to implement.
A retainer scope that survives the first quarter
Sell three month blocks, each with a different centre of gravity.
Month one, access. Crawler and firewall rules, snippet directives, render path, redirect chains, response times for the templates that carry the answers. This is unglamorous and it is where the recoverable loss concentrates. It is also the only part with a quick feedback loop, which is what buys you months two and three.
Months two and three, identity. Consistent naming across the site, the schema, the directories and the profiles that link back. Resolve contradictions between the pricing page, the product page and whatever a partner site says. In the answers we have read back during audits, a loose or contradictory identity tends to produce a hedged mention, and a hedge reads to a client as absence. That is a pattern we have observed in our own runs, not something any engine documents.
Ongoing, corroboration and the run. The fixed prompt set, re-run on schedule, plus whatever third party coverage is realistically in reach. This layer is the slowest and the least controllable, so it should be the part of the scope with the softest language.
Staff it off your existing bench. The access block is a technical SEO task with new rules. Identity is a structured data and content ops task. Corroboration is digital PR. The genuinely new skill is running the prompt set the same way twice and resisting the urge to tidy it between runs.
What to vary by client, and what never changes
Vertical changes the prompt set and the evidence bar, not the method. Regulated categories carry a review step that eats calendar time, which is the main lesson from AEO for fintech: the fix is often ready weeks before it is allowed to ship, so your plan needs the compliance queue in it. Commerce clients push the work towards feeds and product data. Local and professional services push it towards third party listings. The map of those differences sits in AEO by industry, and it is a sensible thing to read before you write a scope for a vertical you have not served.
What does not change: the prompt set is fixed before the work starts, the evidence is kept, and the report says what was run, when, and on which engines.
Honest limits
Three things to say to a prospect before they sign, because they will find out anyway.
Attribution is genuinely weak. In the client analytics we have had access to, most of this traffic arrives with little or no usable referrer, so you can show that a brand is named more often and you cannot cleanly tie that to revenue. We can only speak to the properties we have seen, and absence of a referrer in those logs is not proof that the surfaces we have not measured behave the same way. Agencies that promise last-click style reporting here are writing a cheque the plumbing cannot cash.
Durability is unknown. Engines can change retrieval behaviour without announcing it, and a fix that held for a quarter can stop mattering. We cannot see a retrieval pipeline from the outside, so we infer change from our own repeated runs rather than observing it directly. Re-running is not padding the invoice. It is the only way anyone finds out.
And the floor is real. On a thin category with a small prompt set, you may spend a month inside the noise. The professional answer is to widen the set and lengthen the window, not to pick the engine that flattered you this week.
Two more caveats sit under the claims above. The noise floor claim rests on our own audit runs, which are a sample of client categories rather than a census, and we deliberately publish no figure for it. The access section is sourced to Google, OpenAI and Perplexity documentation only, checked on 12 October 2026, so it says nothing about how Copilot, Grok, Claude or any other engine handles the same directives.
FAQ
What should the first month actually deliver? An access report with the directives and crawler rules listed page type by page type, a fixed prompt set agreed with the client, and a baseline run with its same-day noise floor recorded. No score, no target.
How do I price it without a benchmark? Price the run count and the fix capacity, the way you would price a retained engineering block. The client is buying a repeatable measurement and a queue of changes, not a position.
Can I resell a tool's dashboard as the deliverable? You can, and you will own every number in it. A dashboard with no evidence underneath tells a client that something moved, not why, and not what to do next. If you use tooling, keep the raw evidence yourself so a finding can be argued with.
What goes in the contract? Name the engines in scope, the prompt set size, the run cadence, and a clause saying engine behaviour can change without notice. State that movement inside the measured noise floor is not reported as a result. Avoid any committed target.
Do I need to build the practice before selling it? Run it on your own agency site first. It is a free client, it is a vertical you understand, and you will hit the access problems yourself before you hit them in front of somebody who is paying.
Sources
All four documentation pages were opened and checked on 12 October 2026.
- Google Search Central, robots meta tag, data-nosnippet and X-Robots-Tag specifications: developers.google.com/search/docs/crawling-indexing/robots-meta-tag
- Google Search Central, AI features and your website, for the statement that no special optimisations and no special schema.org structured data are necessary: developers.google.com/search/docs/appearance/ai-features
- OpenAI, bots and crawler user agents, for the four documented agents and the note that robots.txt rules may not apply to ChatGPT-User: developers.openai.com/api/docs/bots
- Perplexity, crawler documentation for PerplexityBot and Perplexity-User, including the note that the user fetcher generally ignores robots.txt: docs.perplexity.ai/guides/bots
- Our own audit runs, about 45 prompts across five engines with retrieval on and off. These are a convenience sample of the clients who hired us, not a survey, and the method above is repeatable without tooling.