Contents
- The $200 Million Blind Spot
- AEO in 60 Seconds: What Everyone Already Knows
- Agent AEO: The Layer Nobody Is Tracking
- Why Agent AEO Is Fundamentally Different from Human AEO
- Why This Matters Now: The MCP Ecosystem at Scale
- The Invisible Failure: search_miss
- The Competitive Landscape: Who Covers What
- Getting Started with Agent AEO
- FAQ
The $200 Million Blind Spot
In the last 18 months, a new category of marketing technology has attracted extraordinary funding. Profound raised $155 million and reached a $1 billion valuation. Peec AI raised $21 million and hit $4 million ARR in 16 months. Bluefish closed a $43 million Series B. Semrush, Ahrefs, and BrightEdge all launched AEO add-ons. Gartner officially recognized "Answer Engine Visibility Tools" as a category in March 2026.
All of these tools solve the same problem: tracking whether your brand gets mentioned when a human asks ChatGPT, Perplexity, or Gemini a question.
This is valuable work. But it addresses only one side of the equation.
There is a second, larger, and entirely untracked phenomenon happening in parallel: AI agents are autonomously discovering, selecting, and using SaaS products — without any human asking a chatbot anything. When a developer tells Claude Code to "create an invoice in freee," the agent doesn't consult ChatGPT. It searches its available tools, evaluates options, and executes. If your product doesn't appear in that search, you don't exist in the agent economy.
No AEO tool tracks this. No AEO tool even acknowledges this layer exists.
The Two Sides of AI Visibility
(chatbot citations)
(agent tool selection)
(agents searching these)
per month
AEO in 60 Seconds: What Everyone Already Knows
Answer Engine Optimization (AEO) emerged in 2024-2025 as a response to a shift in how people search. Instead of typing keywords into Google, users increasingly ask AI chatbots questions in natural language. "What's the best CRM for a 10-person team?" typed into ChatGPT produces a direct answer — and the brands mentioned in that answer get the traffic.
AEO tools track this. They monitor whether your brand appears in ChatGPT, Perplexity, Gemini, and Google AI Overviews. They analyze sentiment, track citation frequency, and suggest content strategies to improve visibility.
The market leaders:
- Profound — $1B valuation, tracks 11 AI surfaces, 700+ enterprise customers including Walmart, Ramp, and Figma
- Peec AI — EU-based, 1,300+ customers, 115+ languages, sentiment scoring
- Semrush / Ahrefs — Added AEO modules to existing SEO platforms
- Conductor — Launched AgentStack (April 2026), bills itself as "the industry's only system of record for AEO"
These tools are good at what they do. But they all share the same assumption: the entity doing the searching is a human.
Agent AEO: The Layer Nobody Is Tracking
Agent AEO is the practice of optimizing SaaS products and APIs to be discovered and selected by AI agents acting autonomously.
When a human asks ChatGPT "what's the best accounting software?", that's a question. The LLM draws on training data and web search to formulate an answer. Traditional AEO tools track this.
When an AI agent receives the instruction "sync my accounting data with my spreadsheet," that's a task. The agent needs to find a tool, authenticate, call an API, and return a result. This is not a question-and-answer interaction — it's a tool-selection-and-execution pipeline. The agent searches its available MCP servers, evaluates descriptions and capabilities, selects the best match, and calls it.
These are fundamentally different processes:
| Human AEO | Agent AEO | |
|---|---|---|
| Who searches | Human typing a question | AI agent executing a task |
| Search mechanism | LLM knowledge + web retrieval | MCP Tool Search (semantic matching) |
| What gets evaluated | Web content, citations, brand mentions | MCP server name, description, tool schemas |
| Success metric | Brand mentioned in AI answer | Service found, selected, and task completed |
| Failure mode | Brand not cited (visible in monitoring) | Service not found — invisible to the provider |
| Revenue impact | Brand awareness, indirect traffic | Direct usage, API calls, task completion |
| Who pays | Marketing teams | Product and engineering teams |
Human AEO is about being mentioned. Agent AEO is about being used. A brand can rank #1 in every ChatGPT response and still have a 0% agent selection rate if its MCP server has poor discoverability.
Why Agent AEO Is Fundamentally Different from Human AEO
1. The search mechanism is not an LLM
When ChatGPT answers a human's question, it draws on its training data and optionally searches the web. Traditional AEO optimizes for this: structured content, brand authority, citation-worthy prose.
When an AI agent searches for a tool, it uses a different mechanism entirely. Anthropic's Claude, for example, uses Tool Search — a semantic matching system that ranks available MCP servers by how well their names and descriptions match the agent's intent. This is closer to how Google ranks web pages than how ChatGPT answers questions. And just like early Google, there is currently zero optimization tooling for it.
2. The input is intent, not a question
Humans ask "What's the best project management tool?" Agents search for "create a task and assign it to a team member." The semantic surface is completely different. A service optimized for human AEO (brand recognition, thought leadership content) may be invisible to agents searching by functional intent.
3. The failure mode is invisible
When your brand isn't mentioned in a ChatGPT answer, AEO tools can detect this because they can query the same chatbot and observe the response. When an agent can't find your MCP server, there is no server-side log, no API call, no error event. Your service was simply never considered. We call this search_miss — and it is the most damaging failure mode in the agent economy because you can't fix what you can't see.
4. The data source is different
Human AEO tools analyze chatbot prompts and responses — fundamentally a text-in, text-out data stream. Agent AEO requires tracking tool selection behavior: which services agents search for, which they select, which they successfully use, and which they silently skip. This is API-level behavioral data, not content analysis.
Why This Matters Now: The MCP Ecosystem at Scale
The Model Context Protocol (MCP) — initially developed by Anthropic in late 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025 — has become the standard interface between AI agents and external services.
The numbers as of mid-2026:
- 73,500+ MCP servers registered across directories (MCP Toplist aggregation of Official Registry, Glama, Smithery, mcp.so, and PulseMCP)
- 97 million+ SDK downloads per month — agents are actively connecting
- 622,000+ monthly searches for the top 50 MCP servers alone (Ahrefs, March 2026)
- Japan is the #2 market globally for MCP-related search volume (PulseMCP)
Three emerging standards are shaping how agents discover services:
- llms.txt — a file in your website root that tells AI models about your service (analogous to robots.txt)
- MCP Server Card (mcp.json) — a machine-readable metadata file for MCP servers (currently in working group stage)
- Google ARD (Agentic Resource Discovery) — Google's spec for making APIs discoverable by agents
No comprehensive guide exists that covers all three. No tool helps SaaS companies implement them. This is part of the Agent AEO gap.
73,500 MCP servers competing for agent attention is comparable to the early web's directory era. The difference: there is no "Google for agents" yet — and the companies building the indexing and ranking layer will define how SaaS is discovered in the agent economy.
The Invisible Failure: search_miss
KanseiLink tracks a failure classification called search_miss: when an AI agent uses semantic search to find a service and the intended service does not appear in the results.
This happens because agents search by intent ("send an invoice," "sync calendar events") rather than by brand name. If a service's MCP server description doesn't match the natural language patterns agents use, it simply won't be found — regardless of how good the underlying API is.
In KanseiLink's data, search_miss is often a larger contributor to low success rates than API errors or authentication failures. A service might have a perfectly functional API, but if agents can't find it in the first place, none of that matters.
search_miss never appears in your server logs. It never triggers an error alert. It never shows up in your API analytics dashboard. From your perspective, the agent simply never called your service. You have no way to know it tried and failed to find you — unless you have an intermediary intelligence layer tracking agent search behavior.
The causes of search_miss typically fall into three categories:
- Name mismatch — your MCP server is named after your brand ("Acme MCP") rather than its function ("invoice management")
- Description gap — your tool descriptions use internal terminology that doesn't match how agents phrase intent
- Category confusion — your service appears in a category the agent isn't searching, even though it has relevant capabilities
The Competitive Landscape: Who Covers What
The AI visibility space is growing rapidly, but each player covers a distinct slice. Understanding who does what reveals the gap Agent AEO fills.
| Layer | What It Tracks | Players |
|---|---|---|
| Human AEO | "Does ChatGPT mention our brand?" | Profound ($1B), Peec AI, Semrush, Ahrefs, Conductor, BrightEdge, Otterly, AthenaHQ |
| MCP Directories | "Where can developers find MCP servers?" | Official Registry, Smithery, Glama, PulseMCP, mcp.so |
| MCP Internal Observability | "Is our MCP server healthy internally?" | MCPcat (session replay, error tracking), Speakeasy (gateway), Tinybird (analytics templates) |
| MCP Benchmarking | "How does our MCP server score on standard tests?" | mcpbr.org (SWE-bench, 25+ evals), Microsoft MCP Interviewer (schema grading) |
| Agent Session Observation | "What happens when agents use our service?" | Armature (YC S26, $79-159/mo) |
| Agent AEO | "Can agents find and successfully use our service?" | KanseiLink |
Each layer serves a real need. Human AEO tracks brand visibility in AI conversations. MCP directories help developers discover servers. Internal observability helps server operators debug issues. Benchmarking helps developers test quality.
But none of them answer the question that matters most to a SaaS company in the agent economy: "When an agent needs what we offer, does it find us, select us, and succeed?"
That is what Agent AEO tracks.
AgentDiscoverability.com has coined "ADO" (Agentic Discovery Optimisation) as a concept, though no product has shipped as of mid-2026. Synscribe offers MCP optimization consulting. Cloudflare's isitagentready.com provides a one-time diagnostic. These signal growing market awareness — but the instrumented, ongoing tracking layer remains the gap.
Getting Started with Agent AEO
If you're a SaaS company with an MCP server (or considering building one), here are the practical steps to improve your Agent AEO posture:
1. Audit your MCP server's discoverability
Review your server's name and description. Ask: if an agent were searching for what we do (not who we are), would our description match? Use verb-based functional descriptions — "creates invoices, manages payments, tracks expenses" rather than "Acme's comprehensive financial platform."
2. Optimize tool schema descriptions
Each tool your MCP server exposes has a description field. These descriptions are what agents read to decide whether to call a tool. They should describe what the tool does in the language an agent would use to search for that capability.
3. Implement emerging discovery standards
- Add an llms.txt file to your domain root — a plain-text summary of what your service does, optimized for AI consumption
- Watch the MCP Server Card (mcp.json) working group — this will become the standard metadata format
- Review Google ARD specs if you expose APIs — Google's agentic resource discovery protocol is actively being adopted
4. Monitor agent-side metrics
Internal observability (MCPcat, OpenTelemetry) tells you about calls that reach your server. Agent AEO analytics tell you about the calls that never arrive — the search_miss events, the selection decisions, the reasons agents choose a competitor. KanseiLink provides this external-facing intelligence layer, grading services across 11,000+ entries with an 8-tier AEO rating system.
5. Report outcomes
The Agent AEO ecosystem improves when agents report what worked and what didn't. KanseiLink's report tool enables agents to log success and failure outcomes, building the data layer that makes search_miss visible.
Frequently Asked Questions
Is Agent AEO replacing traditional AEO?
No. Human AEO and Agent AEO track different phenomena. Human AEO measures brand visibility in AI-generated answers. Agent AEO measures service discoverability in agent tool selection. A complete AI visibility strategy needs both — just as a complete search strategy needs both SEO (organic search) and app store optimization (ASO).
Do I need an MCP server to benefit from Agent AEO?
Having an MCP server is the most direct path, but Agent AEO also encompasses API discoverability via llms.txt, Google ARD, and OpenAPI specs. As the ecosystem matures, agents will discover services through multiple protocols. However, MCP is currently the dominant standard with 97M+ monthly SDK downloads.
How is KanseiLink different from MCPcat?
MCPcat is an internal observability tool for MCP server operators — it tracks session replays, error rates, and debugging data for calls that reach your server. KanseiLink tracks the external layer: whether agents can find your server in the first place, which competitors they select instead, and what search patterns lead to your service being missed. MCPcat tells you what happens after discovery. KanseiLink tells you whether discovery happens at all.
Is this just SEO for APIs?
Conceptually, yes — in the same way that AEO is "SEO for AI search." The mechanism is different (semantic tool matching vs. keyword ranking), the optimization surface is different (MCP schemas and descriptions vs. web content), and the data is different (agent behavioral data vs. search engine data). But the strategic question is the same: how do you ensure the right entity finds you when it's looking for what you offer?