AEO Gets You Into the Answer. ADO Gets You Into the Action.

A developer asks ChatGPT which payments API to use, and answer engine optimization decides whether your product appears in the reply. Twenty minutes later the same developer points a coding agent at your docs and says "integrate it" — and a different set of files decides whether that integration ships. The first moment has a maturing playbook, with vendors, benchmarks, and a body of practice. The second is where the workload actually lands, and it runs on artifacts most API teams have never shipped.

Most teams searching for an answer engine optimization API playbook are asking about the first moment. This article covers the second — the discipline starting to be called agent discovery optimization, or ADO — and why an API that wins the answer can still lose the integration.

What AEO does well — and where it stops

AEO — answer engine optimization — is the practice of structuring content so that answer engines like ChatGPT, Perplexity, and Google's AI Overviews retrieve it, trust it, and cite it when a person asks a question. Its close sibling GEO (generative engine optimization) extends the same idea to any generative surface. The discipline is real and its techniques are sound: answer-first page structure, clean entity definitions, consistent naming, machine-extractable claims, content that a retrieval system can quote without reassembling it from fragments.

AEO's jurisdiction is the answer surface. Its unit of success is the citation: your brand named in the reply, your page linked as the source. For an API company, that means AEO decides whether "Which email API should I use?" surfaces your product at all — a battle worth winning, and one the AEO tooling ecosystem measures well.

The citation is also where AEO's jurisdiction ends. The reply names your API; the person accepts the suggestion; an agent opens your documentation and starts working. Everything from that point forward — whether the agent can find your machine-readable spec, load your docs without executing JavaScript, learn your auth model, and recover from its first 429 — sits outside what AEO measures or improves. An API that wins the answer and fails the fetch loses the workload to whichever alternative the agent can actually operate.

The agent's task loop — where selection happens

Watch what an AI agent actually does with a task like "send a transactional email when a user signs up." The loop looks roughly like this: interpret the goal, pick a capability (an API, an MCP server, a library), fetch that capability's public documentation, construct requests against what it understood, execute, and handle whatever comes back. Selection happens twice — once when the capability is chosen, and again, silently, when the agent decides whether what it fetched is usable enough to keep going.

The fetch step is less forgiving than most teams assume. Agents typically read your docs over plain HTTP, without executing JavaScript — so a docs site that renders beautifully in a browser can arrive as an empty shell. Access, meanwhile, is mostly a solved problem: 80% of the APIs in the Discry Index corpus have an AI-crawler-friendly robots.txt and 65% publish a sitemap . The door is open. What's missing, far more often, is the map: the artifacts that tell an agent which of your hundreds of pages matter and how to act on them.

When the map is missing, the agent reconstructs it by trial and error. This is the moment DevRel teams already see in their support queues: a developer asked Cursor or Claude Code to integrate the API, the agent guessed at endpoints that don't exist, and the resulting ticket blamed the API. Coding agents are the first mass agent-readers of API documentation, and every scaffold attempt is an agent reading your docs in anger.

This is the gap ADO names. Agent discovery optimization is the emerging practice of shipping the machine-legible artifacts that let an agent find, load, and act on your API from its public surface — the API-side counterpart to what AEO does for content, and part of what people mean when they search for SEO for agents. The acronym is younger than the practice: the artifacts below already have specs, adopters, and measurable pass rates.

The ADO artifact checklist

Each artifact here is a discovery signal Discry checks on every API in the Index — the adoption figures come from the current corpus.

llms.txt — a curated, plain-text index at your docs root that tells agents which pages matter and in what order (spec, glossary). It is the map for the small-context reader: with it, an agent loads your three canonical guides; without it, it samples a 400-page site and hopes. 64% of the corpus ships one , which makes it the most-adopted agent-specific signal — though presence and quality are different checks, and a bloated or stale llms.txt routes agents badly. Our full guide to llms.txt covers what a good one contains, and the examples gallery shows real ones. Its companion llms-full.txt — the entire docs surface as one loadable file (glossary) — sits at 31% adoption .

OpenAPI spec — the machine-readable contract for your endpoints (spec, glossary). This is the oldest artifact on the list and still the highest-return one: it is the difference between an agent constructing requests from a parsed schema and an agent inferring parameter names from prose. Only 54% of the corpus publishes one an agent can find and parse — a striking figure for a format that predates the agent era by a decade.

AGENTS.md — the brief that tells a coding agent how to build on your system: conventions, auth setup, the golden-path example, the known gotchas (spec, glossary). Adoption sits at 30% , and the gap runs through famous names: Cloudflare passes the check while Stripe — which ships both an llms.txt and an OpenAPI spec — does not. See AGENTS.md for APIs for what to put in one, and the gallery for live examples.

MCP manifest and registry listing — the Model Context Protocol is how agents consume an API as callable tools rather than documentation, and it has two discovery signals. A manifest at .well-known/mcp.json (glossary) makes your MCP server discoverable from your own domain; at 5% adoption it is the rarest signal we check — Resend is one of the few that passes. A listing in a public MCP registry (glossary, example registry) is far more common at 76% . Registry listings can be published by third parties; the manifest lives on your own domain, which makes it the stronger signal of intent.

Agent-legible error docs — the artifact that keeps the loop alive after the first failed call. Agents recover from errors exactly as well as the error response format is documented: a structured error body, the meaning of each code, and explicit retry and backoff guidance turn a dead end into a handled branch. There is no single file to ship here — this is documentation content, and Discry measures it on the comprehension side of the methodology rather than as a discovery signal. It belongs on the ADO checklist anyway, because the agent that discovered you will hit an error within its first dozen calls.

Where the two disciplines compound

The encouraging part: the work overlaps more than the two names suggest. Answer engines cite pages they can extract cleanly — answer-first structure, stable headings, content that survives being quoted out of context. Agents comprehend docs with exactly the same properties. A docs page rewritten so a retrieval system can lift the answer is also a docs page an agent can act on; an llms.txt that routes agents to your canonical guides also concentrates the pages answer engines learn to trust. Structured, extractable content is the shared substrate. AEO and ADO diverge in what they measure, and converge in what they reward.

The divergence still matters for how you verify the work. AEO tools tell you whether you were cited; they say nothing about whether an agent that acted on the citation succeeded. Agent-readiness — whether agents can find and understand your API from its public documentation surface — is the property ADO exists to produce, and it is what Discry measures: unlike docs platforms and checklist scanners, Discry independently tests real models against your public documentation and benchmarks the results across APIs. The pillar guide to agent-readiness covers the full picture, and the prioritized checklist sequences the fixes.

If you have already invested in AEO, the sequencing question answers itself. The citation you won is an agent's next fetch. Ship the map before the traffic arrives.

What grade does an AI agent give your API? Discry your API — free — 60 seconds, no signup.