What should a search API return to an agent?

An agent can find a convincing result and still be unable to defend the answer it writes from it. A title and URL identify a lead. A passage gives the agent something to inspect. Neither establishes that the page is authoritative for the question, that the passage is complete, or that it was true on the date the user cares about.

That makes a search API response an evidence handoff, not an answer. We checked the published Search contracts of Valyu, Exa, and Parallel on 25 September 2026 and inspected one live Valyu response for its field names. The three code examples are raw JSON request bodies, not cURL commands, SDK calls, or captured provider responses; authentication headers are omitted. They compare documented output shapes and integration decisions; they are not matched-query tests of relevance, latency, or price. We did not make live Exa or Parallel API requests.

Disclosure: Search for Agents is produced by Valyu. Its Search API is one of three examples here; the same source-verification requirements apply to all three.

First decide what the agent has to prove

Suppose an agent needs to identify the original specification for HTTP semantics. A search for “RFC 9110 HTTP Semantics” may return the RFC Editor's copy of RFC 9110, another page quoting it, or a summary. The result with the best excerpt might be useful for discovery. To answer which document is the specification, the agent should still open the RFC Editor's record and identify RFC 9110, rather than promoting a result title or ranking position into authority.

The same separation matters for a changing page. A result's publication date describes one possible property of the source; it does not tell us when the agent fetched its text or when a policy described inside it took effect. Those latter dates need their own fields in the application, even when the search provider returns useful metadata.

An agent-ready handoff needs five pieces:

Need	Minimum usable information	What still needs checking
Source identity	Resolving URL, title, and provider result ID if available	Whether the page is the original record and whether its URL still serves the same content
Evidence	Extracted page text or a relevant excerpt	Whether the exact claim appears in context rather than only in a generated summary
Provenance	Provider source classification and available author or publication metadata	Which organization issued the underlying statement, not merely which index found it
Time	Any source publication date	The application's fetch time, the source version, and the effective date of the claim
Execution state	Request identifier, warnings or error status, and available usage information	Whether a source failed, content was truncated, or the response is incomplete

These are requirements for the consumer of search, not a claim that any single vendor returns every field in this table.

Example 1: Valyu returns content with source and cost context

The Valyu Search reference describes a POST /v1/search request with a query and controls such as search_type, max_num_results, and response_length. A result has an id, title, url, extracted Markdown content, a source identifier, source_type, price, and length. Fields such as publication_date, doi, and relevance_score depend on the result and search mode; an agent must allow missing dates rather than fill them in.

For the RFC Editor question, the documented request shape permits:

{
  "query": "Find the RFC Editor's RFC 9110 HTTP Semantics specification",
  "search_type": "web",
  "max_num_results": 3,
  "response_length": 2000
}

At the response level, tx_id identifies the operation, results_by_source counts source categories, and total_deduction_dollars reports spend. We checked those field names against the quickstart and a live web-search response. The response included a crawl_date on that occasion, but the documented result contract we inspected does not require it. Our agent would still record its own fetch timestamp.

Valyu's content can save an immediate page fetch, but the documented response_length limit can truncate that text. If the decisive sentence falls beyond the returned portion, absence from content is not evidence that the source lacks it. A source_type of paper or website describes the kind of result; it does not certify the paper's conclusion or the website's authority.

The API reference also documents HTTP 206 for a processed search when some sources failed or no results were found. A 206 alone does not tell the agent which happened: inspect the returned results and error or warning fields before claiming the search was complete, empty, or unusable.

Example 2: Exa makes the evidence view a request choice

Exa Search takes a query and returns results with metadata such as id, url, title, and publishedDate when available. Its Search guide recommends asking for contents: { highlights: true } when the agent needs passages; contents.text requests the broader cleaned page body. Search results contain what was requested under contents, so a link-only response should not be treated as though a passage was verified.

For the same task, this request asks Exa to include passages:

{
  "query": "RFC Editor RFC 9110 HTTP Semantics",
  "numResults": 3,
  "contents": { "highlights": true }
}

Exa includes a top-level requestId and a costDollars object. Its Search reference describes that cost as an endpoint-dependent estimate, not necessarily the final billed amount. The requestId makes a call traceable, while the result's id or url identifies a discovered page; neither is an immutable snapshot of what the page said.

For changing pages, contents.maxAgeHours controls how old cached extracted content may be before Exa attempts another fetch. Exa explicitly distinguishes that setting from a publication-date filter. Setting a low maximum age addresses one form of stale extraction; it does not guarantee that a new fetch succeeds or make an old underlying claim current. Exa's Contents guide also says a separate Contents request can check per-URL statuses when fetching specified pages.

Example 3: Parallel starts with excerpts and request warnings

The current Parallel Search endpoint uses POST /v1/search with search_queries and an optional natural-language objective. Its documented result fields include url, title, publish_date (which can be null), and an excerpts array. The response includes search_id, session_id, and optional warnings and usage fields. session_id can carry context across later Search and Extract calls; search_id refers to this search, not to a version of a source document.

Parallel represents that task with short queries and an optional objective:

{
  "search_queries": ["RFC 9110 HTTP Semantics"],
  "objective": "Find the RFC Editor's original RFC 9110 specification."
}

The migration guide is explicit about a tradeoff: Search returns compressed excerpts rather than complete page bodies and does not provide a per-result relevance score. If the agent needs a wider passage, the Extract API has a separate full_content field and per-URL errors. Preserve the ranked order rather than manufacturing a score from position, and inspect warnings before assuming every requested constraint was honored.

Parallel's publish_date, like the dates in the other examples, is source metadata when available. It is not the timestamp of your application receiving the answer. The agent still needs to attach that timestamp and reopen the original source if a compressed excerpt leaves out the qualification that changes the meaning of a claim.

Do not normalize away the differences

An application may want one internal record format, but a flat score and a snippet field would erase important distinctions. Valyu's extracted content, Exa's requested highlights or text, and Parallel's default excerpts are different views with different completeness guarantees. The dollar fields are not directly comparable either: Valyu reports total_deduction_dollars, Exa describes costDollars as estimated, and Parallel exposes usage metrics. None makes a claim more credible simply because the call cost more.

Keep the raw provider response alongside a small normalized evidence record: provider and request ID; source URL and any document identifier available; returned excerpt or text; which content view was requested; any publication date; the application's retrieval time; warnings, partial failures, or per-URL errors; and a pointer to the exact passage checked on the original page. Set unknown fields to unknown. Do not transform a missing publication date into today's date, or treat a provider's request ID as a document ID.

Before the agent cites anything, ask whether it can reopen the URL, locate the claimed passage, and state which source and date govern the answer. If it cannot, the search response is still a useful lead—but the claim has not passed verification. The web-result investigation shows that boundary in a live source dispute; the evidence-first evaluation brief explains how to check the resulting answer independently.

Method note: API field names and request behavior above were checked against each provider's published documentation on 25 September 2026. One Valyu response shape was also inspected directly. Exa and Parallel examples describe documented interfaces, not observed results from live calls; no claims about relative retrieval quality are made.