Agent Surface

Retrievability

Search and Retrieval APIs

Exposing a documented query surface so agents can find your product's data instead of scraping it

Last verified 2026-10-29

Agents need a callable way to search or retrieve your product's data - support articles, catalog items, records, documents - that returns structured, attributable results. A search box built for a browser is not that surface: it returns HTML, not a contract an agent can call directly.

What a retrieval endpoint needs

  • A documented query parameter set. Free-text query, structured filters, sort order, and result shape belong in your spec, not only in UI behavior. See OpenAPI for Agents.
  • A stable result schema. Every result needs an identifier, a title or summary, enough content to be useful without a follow-up call, and a canonical URL or resource reference. Returning bare IDs forces the agent into N follow-up calls to resolve what it just found.
  • Relevance signals. If your endpoint ranks results, expose the score or rank alongside each item so an agent can compare the top result with the tenth. A relevance score is not calibrated confidence or a probability that the result is true. Document the metric behind it (for example , cosine similarity or a score), its direction (higher is better, or lower is), and whether scores are comparable across queries, or only within one result list. If you can't make that promise, expose rank instead.
  • A documented empty-result and no-match behavior. Distinguish "zero results because nothing matched" from "the query was invalid." An agent needs to know whether to retry with a broader query or stop.

Result shape example

{
  "results": [
    {
      "id": "doc_9f21",
      "title": "Rotating an API key",
      "snippet": "Go to Settings → API Keys → Rotate. The old key remains valid for 24 hours...",
      "score": 0.91,
      "url": "https://docs.example.com/api-keys/rotate",
      "updated_at": "2026-08-02T00:00:00Z"
    }
  ],
  "next_cursor": "eyJvZmZzZXQiOjEwfQ",
  "total_estimate": 47
}

Every field here answers a question the agent otherwise has to guess at: what did I find, how well does it match the query (by a score whose meaning you document), where did it come from, is there more, and how much more.

Structured versus free-text retrieval

Not every retrieval need is a search box. Agents often need typed queries over structured data: "orders placed after March 1 in status shipped." Expose this as filtered list endpoints or a query language (SQL-like, , or structured filter parameters) rather than forcing every question through a full-text search index that was tuned for prose. See Retrieval and Job Contracts for and response-schema mechanics that apply to both.

What not to duplicate here

Chunking prose so an agent can retrieve a self-contained answer from it is a content-authoring concern, covered in Content Structure. Building a vector index or pipeline to power semantic search over your own corpus is an implementation choice; the current best-practice patterns for that live in Agent Retrieval as inventory, not as a requirement of this dimension. The score covers whether the capability is reachable, documented, and returns agent-usable results; which retrieval technology sits behind it is out of .

On this page