A customer asks an AI to find the right supplier. A supplier asks how to become the recommended answer.
A good match satisfies both. A capable business that goes undiscovered is a missed opportunity for the customer too. But the two requests are not quite the same. One is asking for help choosing. The other is asking to be chosen.
AI visibility concerns whether and how a business appears in an AI-generated answer. It might be mentioned, cited, compared with alternatives or recommended. These are different outcomes. An assistant could use a company’s installation guide to answer a technical question without recommending that company for the job.
AEO—answer engine optimisation—and GEO—generative engine optimisation—are overlapping labels for work intended to improve this visibility.1 The question is not simply where a page appears, but what an assistant does with the information it finds.
Does making a business more visible also make the answer better?
Imagine a specialist whose website says little beyond “bespoke solutions”. It starts explaining the materials it works with, typical costs, delivery times and projects it can handle.
The company wants more customers. But these details also give an assistant something useful to work with. Instead of guessing what “bespoke solutions” covers, it can compare the company’s capabilities with what someone actually needs.
The website is not the only account available. AI search can also draw on reviews, product listings and discussions elsewhere.1 An assistant could compare those accounts, ask the customer what matters and explain why a less prominent supplier deserves consideration.
That could be useful for both sides. It could also mean leaving the business out.
Suppose the specialist publishes a six-week minimum lead time. That could support a recommendation for a planned project—and rule it out for someone needing delivery in three weeks. Fewer recommendations might mean better matching and fewer wasted enquiries.
The business wants to be chosen. The customer needs the assistant to remain willing to choose someone else.
This makes success harder to measure than a count of appearances might suggest. Microsoft’s AI Performance dashboard, for example, reports how often particular pages are cited. It explicitly distinguishes those counts from importance, ranking or placement.2 The figures tell a business something about its visibility. They do not, on their own, tell it whether the customer received better advice.
If appearances become the target regardless of suitability, the work can change. Explaining what a company does gives way to making it seem relevant to as many questions as possible. Google already warns against creating pages for numerous query variations primarily to manipulate rankings or AI responses.1
The distinction is not simply between marketing and something more worthy. Good marketing can make a useful business easier to understand. A paid introduction could reveal an excellent option. But payment is not evidence that the option fits.
If the assistant fails to keep those things separate, the customer has to do the filtering again: check the claims, understand the commercial relationships and look beyond the suggested shortlist.
The answer may be shorter without the decision becoming easier.
From being found to getting things done
The same question becomes more consequential when the assistant can act.
Instead of searching, comparing, exchanging emails and placing an order, someone might ask their device: “Find a suitable supplier, arrange it within this budget and let me know when it is done.”
That brings several different jobs into one request. Finding the business is only the beginning. The assistant also needs enough information to assess it, a way to contact it and permission to make whatever commitments follow.
Some foundations remain familiar. Clear descriptions, accurate business details and accessible web pages still matter. Google’s AI search features draw on its search index; special AI files are not a substitute for being crawled and indexed.1
Beyond that, a business can make its systems available for an assistant to use, rather than only publishing pages for it to read.
MCP, the Model Context Protocol, provides a standard way for AI applications to access tools and data. A supplier could use it to make a catalogue searchable or let an assistant check current availability. The assistant is then requesting information from a connected system, not merely relying on a description found online.3
Where a business runs its own agent, A2A, or Agent2Agent, provides a way for compatible agents to communicate. A customer’s assistant could send an enquiry to the supplier’s agent, which could work through the request using the supplier’s own information and systems.
The business can publish an Agent Card: a machine-readable description of what its agent can do and how to contact it. This helps compatible systems discover and use the agent. It does not automatically put the business into every assistant’s recommendations.4
The customer might see something quite different: a quote, product selector or booking form inside the conversation. MCP Apps already support interactive interfaces in compatible AI applications. These visible cards and forms are not the same thing as the Agent Cards exchanged between systems.5
The terminology can obscure a fairly practical distinction. One connection provides access to information or a tool. Another lets agents exchange requests. An interface lets the customer review details and make choices.
Connected to the right systems, a company’s agent could field enquiries, collect missing information, prepare quotes and arrange bookings. Commerce protocols add ways to handle checkout, payments and order or delivery updates.6
These are capabilities to build and connect, not benefits a business acquires simply by publishing a card. A description of a quoting service is not a working quoting service. And a working service still needs to be accessible to the assistant trying to use it.
There is no need to imagine all of this arriving as one complete replacement for the web. A customer’s request might involve ordinary search, a company website, a connected tool, an exchange between agents and a human approval. Different parts can develop at different speeds.
The result could be less work for the customer. But delegation still needs limits: how much can be spent, what can be agreed and when approval is required. There also needs to be a way to resolve mistakes, failed bookings or goods that never arrive.
The assistant may need a customer’s budget and requirements to compare suppliers. That does not mean each supplier needs the underlying conversation or the customer’s personal history. Sharing should match what the enquiry actually requires.
“Let me know when it is done” should reduce the customer’s work, not remove their control.
Making a business easier to deal with could help both sides. Yet it introduces another version of the original question: could an assistant favour a supplier because it is easier to buy from, rather than because it better meets the customer’s needs?
Convenience can be part of a good match. It should not become a substitute for one.
A useful name for this wider relationship is AI mediation: how an assistant helps someone discover, assess, choose and deal with a business. Visibility is one part of it. So are the evidence behind a recommendation, the available connections and the authority to act.
Seen this way, the developing field is about more than getting a company into an answer. It is about what happens between a customer’s need and a completed purchase—and whose interests are served along the way.
Commercial involvement could make that process more useful, not less. Businesses have information and capabilities that customers need.
The test is whether better information and better connections help a business get chosen—and help the assistant recognise when it should not be.
Sources
1 Google Search Central — Guidance on AI search visibility, AEO/GEO, indexing, external sources and content practices. Google for Developers
2 Microsoft Bing — Introducing AI Performance in Bing Webmaster Tools: what citation counts measure and what they do not.
3 Model Context Protocol — Introduction to connecting AI applications with tools and data. Model Context Protocol
4 A2A Protocol — Agent discovery, Agent Cards and communication between compatible systems. A2A Protocol
5 Model Context Protocol — MCP Apps and interactive interfaces inside supported AI applications. Model Context Protocol
6 Google Developers and Universal Commerce Protocol — Connecting agent workflows with commerce, payment authorisation and order updates. Google Developers Blog